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.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 — sayguides.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.
Setting it up
- Create a DNS record for the subdomain pointing at the server or CDN that will run the proxy, and issue a certificate covering it.
- In the portal’s Integration tab, enter the subdomain on its own —
https://guides.yourdomain.com, with no path after it. - Tick This is a dedicated subdomain. The portal will confirm that every address on that hostname will serve Obvlo content, including its home page.
- Copy the generated configuration for your platform and apply it to that subdomain’s virtual host.
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 (recommended)
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 CDNPrerequisites
- 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
- Add your domain to Cloudflare. Update your domain registrar’s nameservers to the Cloudflare nameservers shown in the dashboard.
-
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). - 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.
-
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, soyourdomain.com/local-guideswithout 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 likeyourdomain.com/local-guidesplusyourdomain.com/local-guides/*does not, because the first half still carries no wildcard. - Verify. Visit your domain — Obvlo content should load with your domain in the browser address bar.
Worker code
ReplaceORIGIN_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_BASEdoes not end with a slash. - Path Stripping: The code above strips the
PROXY_PATHbefore 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.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.
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
Enablemod_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:- Open IIS Manager and select your server in the Connections pane.
- Double-click Application Request Routing Cache.
- Click Server Proxy Settings and check Enable proxy.
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: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: correctHost header, forwarded headers, and HTTPS to the origin.
Troubleshooting
Content not loading
- Verify the
Hostheader is set tosites.obvlo.com— this is the most common configuration error. It must match the origin the same rule fetches from, so usecontent.obvlo.comin 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-guidesmatches 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=1to 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.