> ## Documentation Index
> Fetch the complete documentation index at: https://docs.obvlo.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Deployment modes
> The four ways Obvlo content reaches your domain, what each costs you to run, and why we recommend the reverse proxy to sites.obvlo.com.
Obvlo content always lives on **your** domain. What differs between modes is how it gets there, how quickly a change you publish becomes visible, and how much you have to operate yourself.
Every mode is set per domain, and every mode is reversible: switching does not migrate data, change your URLs, or invalidate anything you have already published.
**Start with the reverse proxy to `sites.obvlo.com`.** It is the mode we recommend for new and
existing sites, and the one we support best. Pages render on request behind a cache, so publishing is
live within seconds, new pages appear without a rebuild, and there is nothing to schedule or wait
for. If you run WordPress, the [WordPress plugin](/microsite/wordpress-plugin) is the same thing with
the configuration already done for you.
## The options
**Recommended.** Whole pages from `sites.obvlo.com`, through a proxy on your own server or CDN.
Publishing is live immediately.
The same reverse proxy, packaged as a plugin and pre-configured for your site. Nothing to
configure after activation.
One guide at a time, as an HTML fragment inside a page you already render yourself.
Whole pages built ahead of time and served from `content.obvlo.com`. The original mode, still
fully supported. [Switch to dynamic serving →](/microsite/ssr-proxy)
## Comparison
| | Reverse proxy | WordPress plugin | Embed | Prerendered |
| ---------------------------------- | ---------------------------------- | ------------------- | ------------------------------ | --------------------------------------- |
| **Recommended** | **Yes — default** | Yes, on WordPress | For one guide in your own page | Existing sites only |
| Origin host | `sites.obvlo.com` | `sites.obvlo.com` | `sites.obvlo.com` | `content.obvlo.com` |
| What Obvlo serves | Whole pages | Whole pages | A content fragment | Whole pages |
| Who renders the surrounding page | Obvlo | Obvlo | You | Obvlo |
| A published change is live | Within seconds | Within seconds | Within seconds | After a rebuild — 20–30 minutes or more |
| New pages appear | Automatically | Automatically | You add each placement | Only after the next rebuild |
| What you operate | A proxy rule on your server or CDN | A plugin | A snippet in your template | A proxy rule on your server or CDN |
| Setup effort | One config file | Upload and activate | Paste one snippet | One config file |
| Needs a rebuild to go live | No | No | No | Yes |
| Works without a build ever running | Yes | Yes | Yes | No |
## Pros and cons
Whole Obvlo pages served through a proxy rule you add to your own web server or CDN, fetching from
`sites.obvlo.com`.
**Pros**
* Publishing is live within seconds. There is no build to wait for and no window where the site and
the portal disagree.
* New pages are reachable as soon as they are published — you never have to remember to rebuild.
* All SEO authority accrues to your primary domain, and Obvlo renders the whole page, so structured
data, canonicals and hreflang are handled for you.
* Works on any stack: NGINX, Apache, IIS, Caddy, Cloudflare Workers, or most CDNs.
* Fully reversible. Repointing at `content.obvlo.com` is a two-line change.
**Cons**
* You need access to a web server or CDN configuration. If you cannot add a proxy rule, this mode
is not available to you.
* The `Host` header must match the origin. It is the most common setup error, which is why you
should paste the generated configuration rather than adapt an example.
* If you run your own CDN in front of Obvlo, its cache is yours to purge — a publish clears Obvlo's
cache, not yours.
[Set up a reverse proxy →](/microsite/reverse-proxy)
The same reverse proxy, delivered as a WordPress plugin with your site's origin, ids and mount path
already filled in.
**Pros**
* No server configuration at all. Upload, activate, done.
* Everything the reverse proxy gives you, including immediate publishing and new pages appearing on
their own.
* The download is generated for your site specifically, so there is nothing to substitute by hand
and nothing to get wrong.
* Deactivating the plugin hands the path straight back to WordPress.
**Cons**
* WordPress only. For any other stack, use the reverse proxy.
* Requests pass through PHP rather than your web server's proxy module, so it is marginally slower
than an NGINX or CDN rule on the same hardware.
* If you change the mount path in the portal, download the plugin again — the archive carries the
path it was built with.
[Install the WordPress plugin →](/microsite/wordpress-plugin)
A single guide returned as an HTML fragment and placed inside a page you build and render yourself.
**Pros**
* You keep complete control of the page: your header, footer, layout, navigation and analytics.
* No proxy and no server configuration — one snippet in your template.
* The server-side include variant puts the content in the HTML you send, so crawlers see it on the
first request.
**Cons**
* One guide per placement. You add each one, so it does not scale to a large or growing set of
pages the way the proxy modes do.
* You own the page, so canonicals, structured data and hreflang for it are yours to get right.
* Resolves against your published production content only.
[Use the Embed API →](/microsite/embed-api)
Whole pages built ahead of time and served as finished files from `content.obvlo.com`, through the
same kind of proxy rule.
**Pros**
* Serves static files, so response times are extremely consistent and there is no render in the
request path.
* Nothing renders on demand, so a traffic spike costs nothing extra.
* Well proven — this is how Obvlo microsites were originally delivered, and it remains fully
supported.
**Cons**
* A published change is not visible until the site is rebuilt and redeployed, which takes 20–30
minutes and longer for a large site.
* New pages do not exist until the next build, so publishing and going live are separate events you
have to track.
* The same proxy configuration burden as the reverse proxy, without the immediacy.
**On this mode the deploy is the publish, so the portal shows you no publish controls.** There is
no Publish button, no Preview or Production column and no publish action in the page menu,
because none of them could change what a visitor receives — only a rebuild can. Deploy the site
to make your saved changes live. Every other mode shows the publish controls, because on those
publishing is what puts a change in front of a visitor.
[Switch to dynamic serving →](/microsite/ssr-proxy)
## Where it mounts
The mode decides *how* pages are produced. A second, independent choice decides *where* they appear on
your domain — and it applies to the reverse proxy and prerendered modes alike.
| | Path on your main domain | Dedicated subdomain |
| ---------------------------------------- | ------------------------------ | ------------------------------ |
| Example | `yourdomain.com/travel-guides` | `guides.yourdomain.com` |
| **Recommended** | **Yes — default** | For pilots and trials |
| SEO authority | Accrues to your primary domain | Accrues to the subdomain |
| Touches your main site's configuration | Yes — one proxy rule | No |
| Needs its own DNS record and certificate | No | Yes |
| Your own pages on that hostname | Untouched | None — Obvlo serves everything |
| WordPress plugin available | Yes | No |
Obvlo serves one path, and every other route on the hostname stays exactly as it is.
**Pros**
* Link equity and page authority accrue to the domain you actually want to rank, which is the
single biggest reason to run a microsite at all.
* One URL structure for crawlers, one domain for analytics and attribution.
* Works with every mode, including the WordPress plugin.
**Cons**
* You need to add a rule to the server or CDN that serves your main site. In some organisations
that is the slowest part of the whole setup.
A hostname of its own — `guides.yourdomain.com` — where every address is an Obvlo page.
**Pros**
* Nothing on your main domain changes, and no existing route moves. Nothing you already serve can
break.
* The fastest way to get a microsite in front of real traffic: a DNS record, a certificate, and a
proxy rule on a host with nothing else on it.
* Ideal for a pilot, or where you cannot get a change made to the main site's configuration.
**Cons**
* Search engines treat a subdomain as related to but distinct from your primary domain, so
authority builds there instead of where you want it. This is the trade-off, and it is the reason
the path mount is the default recommendation.
* The WordPress plugin cannot do it — it proxies a path inside a WordPress site, and an install
with every route proxied has no home page left of its own.
* Moving to a path mount later means redirects, so it is cheaper to start on a path if you already
know the pilot will become permanent.
[Set up a subdomain mount →](/microsite/reverse-proxy#mounting-on-a-subdomain)
## Choosing
Three rules of thumb:
* **If Obvlo owns the whole page, use the reverse proxy to `sites.obvlo.com`** — or the WordPress
plugin, which is the same thing pre-configured. Choose prerendered only if you have a specific reason
to serve static files and can accept a rebuild before every change goes live.
* **If you own the page and want one guide inside it, use the Embed API** — and use its server-side
include rather than the client-side script if the guide is the reason the page should rank.
* **Mount on a path of your main domain unless you are piloting.** A dedicated subdomain is faster to
stand up and changes nothing you already serve, but the SEO authority accrues to the subdomain rather
than to your primary domain.
## What every mode shares
* **Your domain, your URLs.** Content is always served from a hostname you control, never from an Obvlo
one. SEO authority accrues to your primary domain in every mode — provided you mount on a path of it
rather than on a subdomain. See [Microsite overview](/microsite/overview) for why this matters.
* **The same content.** Modes change delivery, never what is published.
* **Multi-language support.** All configured languages are available in every mode.
* **Reversibility.** Switching is a configuration change on Obvlo's side plus, for the proxy modes, two
lines in your proxy configuration.
## Switching
Ask your account contact to change the mode for your domain. Then:
* **To the reverse proxy from prerendered** — repoint your proxy at `sites.obvlo.com` and update the
`Host` header to match. [Dynamic serving](/microsite/ssr-proxy) covers the exact change and how to
verify it.
* **To the WordPress plugin** — download it from the portal's **Integration** tab and activate it. You
can remove your old proxy rule afterwards.
* **To embed** — place the snippet from the **Integration** tab where you want the guide to appear. You
can leave your existing proxy in place while you try it.
The portal's **Integration** tab always generates configuration for the mode your domain is currently
in, so the copy you take from it is the copy that will work.
## Related pages
* [Microsite overview](/microsite/overview)
* [Reverse proxy](/microsite/reverse-proxy)
* [WordPress plugin](/microsite/wordpress-plugin)
* [Dynamic serving](/microsite/ssr-proxy)
* [Embed API](/microsite/embed-api)