Skip to main content
Serving Obvlo content through your primary domain consolidates SEO authority and ensures a seamless user experience. This guide covers configuration for Cloudflare Workers, NGINX, Apache, IIS, and Caddy.
This is the recommended way to run an Obvlo microsite. The examples below point at sites.obvlo.com, which renders each page on request, so anything you publish is live within seconds and new pages need no rebuild.Running WordPress? The WordPress plugin is this same proxy, packaged and pre-configured, and needs none of the configuration on this page. If you only want a single guide inside a page you already render, see the Embed API. Deployment modes compares every option.
A typical Obvlo content URL follows this pattern:
If your domain is still on prerendered delivery, the origin host is content.obvlo.com instead — everything else on this page is identical, including the path after the host. Substitute the host in both places each example names it: the URL it fetches, and the Host header it sends. Dynamic serving covers the switch and how to verify it.Take your configuration from the portal’s Integration tab rather than adapting an example by hand. It generates against the origin your domain is actually on, so the copy you paste is the copy that works.

SEO benefits

  • Consolidated authority — link equity and domain authority accrue to your primary domain rather than being split across subdomains.
  • Consistent URLs — search engine crawlers index a single URL structure, eliminating duplicate content risks.
  • Improved engagement signals — a unified domain reduces bounce rates and increases session duration.
  • Simplified analytics — all traffic flows through one domain, making attribution straightforward.
  • Performance control — edge caching improves page speed, a direct ranking factor.

General principles

These principles apply regardless of which reverse proxy you use. Path-based proxying — configure your proxy to forward requests from a specific URL path (e.g. /local-guides/) to your Obvlo content URL. You can also point a whole subdomain at Obvlo instead — see Mounting on a subdomain. Host header — the Host header sent to the Obvlo backend must be sites.obvlo.com. It always names the origin you fetch from, so on prerendered delivery both are content.obvlo.com instead — see the note above. Forwarded headers — include the following so the backend can identify the original client: SSL/TLS — the connection between your proxy and the Obvlo backend must use HTTPS.

Mounting on a subdomain

Every example on this page mounts Obvlo on a path of a domain that also serves your own content, which is the arrangement we recommend. The alternative is to give Obvlo a whole subdomain — say guides.yourdomain.com — where every address is an Obvlo page and there is nothing of yours to preserve. This is the quickest way to get a microsite in front of real traffic, because it needs no change to the server that runs your main site. It is what we suggest for a pilot.
A subdomain does not consolidate SEO authority the way a path does. Search engines treat a subdomain as related to but distinct from your primary domain, so link equity and page authority build up there rather than on the domain you actually care about. That is the whole reason the path mount is the recommendation — see SEO benefits above.Choose a subdomain when speed of setup matters more than compounding authority, and plan to move to a path mount if the pilot becomes permanent. Moving later means redirects, so it costs more than starting there.

Setting it up

  1. Create a DNS record for the subdomain pointing at the server or CDN that will run the proxy, and issue a certificate covering it.
  2. In the portal’s Integration tab, enter the subdomain on its own — https://guides.yourdomain.com, with no path after it.
  3. Tick This is a dedicated subdomain. The portal will confirm that every address on that hostname will serve Obvlo content, including its home page.
  4. Copy the generated configuration for your platform and apply it to that subdomain’s virtual host.
Everything else on this page applies unchanged: the same origin, the same Host header, the same forwarded headers, the same path after the origin host. The only difference is what the proxy matches on — the whole host rather than one path beneath it — and the portal writes that for you, which is why there is no separate set of examples here to copy.
The WordPress plugin cannot serve a whole subdomain. It proxies one path within a WordPress site, and a WordPress install with every route proxied has no home page of its own left to serve. Use one of the server configurations below instead.

Cloudflare Workers run JavaScript at the edge. Cloudflare handles SSL certificate provisioning and renewal automatically — no origin servers, load balancers, or certificate managers required. Request flow: Visitor → Cloudflare Edge (SSL + Worker) → Obvlo CDN

Prerequisites

  • A Cloudflare account (free tier is sufficient)
  • Your domain’s DNS managed by Cloudflare (nameservers pointed to Cloudflare)
  • Your Obvlo content URL (provided during onboarding)

Setup

  1. Add your domain to Cloudflare. Update your domain registrar’s nameservers to the Cloudflare nameservers shown in the dashboard.
  2. Create a DNS A record. Point your domain to 192.0.2.1 (a dummy address — the Worker intercepts traffic before it reaches any origin). Set proxy status to enabled (orange cloud icon).
  3. Create the Worker. Go to Workers & Pages → Create → Create Worker, select “Start with Hello World!”, deploy, then click Edit Code and replace the contents with the worker code below.
  4. Configure routes. Go to your domain → Workers Routes → Add Route. Add one route pointing at your Worker, matching your mount path with a trailing wildcard — for example yourdomain.com/local-guides*. Copy the exact pattern for your site from the portal’s Integration tab rather than typing it. The trailing * is required. Cloudflare matches a route pattern against the entire URL, query string included, so yourdomain.com/local-guides without the wildcard matches that one exact URL and nothing else. Every page beneath the mount — and the mount itself as soon as a visitor arrives with a ?utm_source=… on the end — would never reach the Worker, and would be served by your own origin instead. One route with the wildcard covers the whole mount; a pair like yourdomain.com/local-guides plus yourdomain.com/local-guides/* does not, because the first half still carries no wildcard.
  5. Verify. Visit your domain — Obvlo content should load with your domain in the browser address bar.

Worker code

Replace ORIGIN_BASE with your actual Obvlo content URL and PROXY_PATH with the path on your domain where the content should live.

Important Considerations

  • Trailing Slashes: In the Worker code, ensure ORIGIN_BASE does not end with a slash.
  • Path Stripping: The code above strips the PROXY_PATH before forwarding to Obvlo. This is necessary because the Obvlo backend expects requests relative to its own root, not your domain’s sub-folder.

What this gives you

  • Automatic SSL certificate management — zero configuration
  • No servers or infrastructure to maintain
  • Edge execution with sub-millisecond cold starts globally
  • 100,000 free requests per day on the free tier
  • Built-in DDoS protection and CDN caching

Web server configurations

Traditional web server setups require you to manage SSL certificates, server infrastructure, and updates yourself. For most use cases, the Cloudflare Workers approach above is simpler to operate.
Mount Obvlo content at a path, never at your domain root. Every example below uses /local-guides — substitute your own path. A root mount (location /, ProxyPass "/") sends your home page and every existing route to Obvlo, and the Obvlo portal will not generate a configuration for it.

NGINX

Add the following to your server block. Replace /local-guides with the path on your domain where the content should live, and the placeholder ids with your actual Obvlo content URL.
The trailing slash on both location and proxy_pass strips the /local-guides prefix and appends the remainder to the backend URL. The Host header must be sites.obvlo.com.

Apache HTTP Server

Enable mod_proxy and mod_proxy_http, then configure your virtual host:
ProxyPassReverse rewrites response Location headers so redirects use your domain. Set ProxyPreserveHost Off and explicitly set Host to sites.obvlo.com.

IIS (Internet Information Services)

IIS requires the Application Request Routing (ARR) module and URL Rewrite module. On Azure App Service, these are pre-installed. Enable the proxy:
  1. Open IIS Manager and select your server in the Connections pane.
  2. Double-click Application Request Routing Cache.
  3. Click Server Proxy Settings and check Enable proxy.
web.config — place this in your site’s root directory:
ARR automatically adds X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Host headers. Proxy timeouts are configured in the ARR server-level settings.

Caddy

Caddy handles SSL automatically via Let’s Encrypt:
Caddy automatically sets X-Forwarded-For and X-Forwarded-Proto.

CDN / edge providers

If you already use a CDN or edge platform, it can likely serve as your reverse proxy. The key requirements are the same across all providers: correct Host header, forwarded headers, and HTTPS to the origin.

Troubleshooting

Content not loading

  • Verify the Host header is set to sites.obvlo.com — this is the most common configuration error. It must match the origin the same rule fetches from, so use content.obvlo.com in both places if you are on prerendered delivery.
  • Confirm the full Obvlo content URL is correct, including the trailing path.
  • Test the origin URL directly, substituting your own origin host:

SSL certificate errors

  • Cloudflare Workers — ensure DNS records are proxied (orange cloud icon). Cloudflare manages certificates automatically.
  • Web servers — verify certificate paths and renewal configuration (e.g. Certbot cron jobs).
  • CDN providers — check origin SSL settings match your backend configuration.

The mount loads but every page under it returns your own 404

A route pattern with no trailing wildcard. It looks nothing like a routing fault from the outside, because the mount root itself works.
  • Check Workers Routes for your zone. A pattern such as yourdomain.com/local-guides matches that one exact URL; yourdomain.com/local-guides* matches the mount and everything beneath it. Add the *.
  • The give-away is that the mount root works while /local-guides/any-page/ does not — and that appending ?x=1 to the working URL breaks that too, because Cloudflare matches the query string as part of the URL.
  • The 404 you see is your own origin’s. An unmatched route is not an error: Cloudflare simply does not route to the Worker, so your origin answers instead, and nothing is logged on either side.

Cloudflare Worker not executing

  • Confirm the DNS A record has proxy status enabled (orange cloud, not grey).
  • Check Workers Routes — ensure the correct worker is assigned to your domain pattern.
  • Purge the Cloudflare cache: Caching → Configuration → Purge Everything.
  • Verify the worker was deployed by checking real-time logs in the Workers dashboard.