Skip to main content
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 is the same thing with the configuration already done for you.

​
The options

Reverse proxy

Recommended. Whole pages from sites.obvlo.com, through a proxy on your own server or CDN. Publishing is live immediately.

WordPress plugin

The same reverse proxy, packaged as a plugin and pre-configured for your site. Nothing to configure after activation.

Embed

One guide at a time, as an HTML fragment inside a page you already render yourself.

Prerendered

Whole pages built ahead of time and served from content.obvlo.com. The original mode, still fully supported. Switch to dynamic serving →

​
Comparison

​
Pros and cons

Reverse proxy — recommended

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 →
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 →
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 →

​
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 — recommended

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 →

​
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 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 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.