Serve your Blesso blog under your existing website

TL;DR

• A reverse proxy keeps the blog at example.com/blog without moving the rest of your website.
• Blesso support prepares the blog for its final public URL. There is no customer-facing setting today.
• Vercel, Netlify, Framer, Cloudflare, AWS CloudFront, nginx, and Apache can route the path.
• Webflow and managed WordPress usually need Cloudflare or another edge proxy.
• Use blog.example.com when your website host cannot proxy a path safely.

This guide uses /news in every example. Replace it with your chosen blog path, such as /blog, /resources, /learn, or /tools.

The finished routing should look like this:

https://www.example.com/               -> your current website
https://www.example.com/pricing        -> your current website
https://www.example.com/news           -> Blesso
https://www.example.com/news/...       -> Blesso
https://www.example.com/newsroom       -> your current website

Before you change the website

Step 1: Choose the public URL

Choose the complete address readers should see. This guide uses:

https://www.example.com/news

Do not choose a path already used by the current website.

Step 2: Ask Blesso support to prepare the blog

Send the final public URL to Blesso support before configuring the website. There is no customer-facing public URL or reverse-proxy setting in Blesso today.

Support prepares the deployment for that path and gives you its hosted origin. You should then have these two values:

Public URL:     https://www.example.com/news
Blesso origin: https://your-blog-slug.revmozi.com/news

The public URL is what readers and search engines should see. The Blesso origin is the hosted address your proxy fetches behind the scenes.

Step 3: Check the Blesso origin

Open the origin in a private browser window. Confirm the blog index, one article, and one image load before changing the current website.

Do not continue if the origin is missing the chosen path. Ask support to correct the deployment first.

Step 4: Choose one routing method

Do not point the proxy back to the public URL. That creates a request loop. Always use the Blesso origin as the destination.

Do not create a redirect or iframe. A redirect moves the reader to the origin domain. An iframe gives search engines and analytics the wrong document.

Choose the setup that owns your traffic

Your content management system may not own the request path. The hosting platform or content delivery network usually does.

Use one method. Stacking Vercel, Cloudflare, and another proxy makes cache invalidation and failures harder to understand.

Each setup starts in the provider dashboard when the provider exposes a safe routing control. Netlify, nginx, and Apache require a file or server configuration for this job.

Vercel

Vercel calls this an external rewrite. It fetches the Blesso origin while keeping the public URL in the browser. Project-level routing lets you add the rule in the dashboard without editing the website or creating a deployment. See Vercel's reverse-proxy guide.

Step 1: Open the project's routing controls

Sign in to Vercel, open the website project, and select CDN. Open the project's routing rules.

Step 2: Add the exact blog path

Create a project-level route with these values:

Name:        Blesso blog index
Source:      /news
Syntax:      Path to Regexp
Action:      Rewrite
Destination: https://your-blog-slug.revmozi.com/news

The dashboard may call the source field Source Path. Choose Path to Regexp when it offers more than one syntax.

Step 3: Add the article and asset paths

Create a second project-level route:

Name:        Blesso blog pages
Source:      /news/:path*
Syntax:      Path to Regexp
Action:      Rewrite
Destination: https://your-blog-slug.revmozi.com/news/:path*

Replace the example hostname and /news in both rules. Keep the exact and wildcard rules together.

Step 4: Review route order

Place both Blesso rewrites before another project-level rule that could match /news. Project-level routes run after bulk redirects and before routes stored in the deployment configuration.

Remove any Vercel bulk redirect that matches /news or its children. Check that the application does not already use /news. Choose another blog path when removing the existing page, redirect, or middleware rule would break the website.

Step 5: Publish the routing changes

Review the pending changes, then select Publish. Vercel applies project-level routing changes without rebuilding or redeploying the website.

Step 6: Verify the production route

Open the production domain's /news, a real article, and one image or stylesheet. Confirm the address bar stays on the public domain. Then open /newsroom and confirm it still belongs to the existing website.

If the browser moves to the Blesso origin, the action is a redirect. Change it to Rewrite and publish again.

Step 7: Check caching after a Blesso update

Publish a small change in Blesso and confirm it appears on the public URL. If an old version remains, inspect the project's CDN cache settings and the origin's cache headers before purging the route.

Optional: Keep the routes in the repository

Teams that review routing changes through Git can use vercel.json instead of project-level dashboard routes. Do not configure the same rewrite in both places.

{
	"$schema": "https://openapi.vercel.sh/vercel.json",
	"rewrites": [
		{
			"source": "/news",
			"destination": "https://your-blog-slug.revmozi.com/news"
		},
		{
			"source": "/news/:path*",
			"destination": "https://your-blog-slug.revmozi.com/news/:path*"
		}
	]
}

Merge these entries with the existing file. Test the deployment preview before promoting it to production. See Vercel's rewrite reference for file-based configuration.

Netlify

Netlify turns a rule into a proxy rewrite when its status is 200. The browser URL remains unchanged. See Netlify's rewrite and proxy documentation.

Step 1: Find the publish directory

In Netlify, open Project configuration > Build & deploy. Note the configured publish directory.

Step 2: Find or create _redirects

Open the _redirects file inside that publish directory. Create the file if it does not exist.

Step 3: Add the proxy rules

Place these rules near the top of the file:

/news    https://your-blog-slug.revmozi.com/news    200!
/news/*  https://your-blog-slug.revmozi.com/news/:splat  200!

Replace the hostname and /news. The exclamation mark makes these rules win if the site already contains a file at the same path.

Keep the rules above a catch-all single-page application rule such as /* /index.html 200.

Step 4: Deploy the website

Run the normal Netlify deployment. Check the deploy log and confirm Netlify copied _redirects into the published output.

Step 5: Verify the production route

Open /news, one article, and one asset. Confirm the address bar stays on the public domain and /newsroom still reaches the existing website.

Step 6: Check rule order if it fails

If the browser changes to revmozi.com, the rule is redirecting instead of proxying. Confirm the status is 200, not 301 or 302.

If the current site's 404 page or application shell appears, move both blog rules above the site's wildcard rule and deploy again.

Framer

Framer Multi Site can rewrite a path to an external HTTPS origin without a separate proxy. It is the simplest Framer setup when the feature is available on your plan. See Framer's Multi Site rewrite guide.

Step 1: Confirm Multi Site is available

Open the Framer project and select Site Settings > Hosting. Confirm Multi Site appears for the project.

If it is unavailable, check Framer's current plan requirements before using an external proxy. Use the subdomain fallback when the plan does not support either method.

Step 2: Add the exact path rule

Open Multi Site, select Add, and choose External. Enter:

Path:   /news
Target: https://your-blog-slug.revmozi.com/news

Step 3: Add the wildcard rule

Add a second External rule:

Path:   /news/*
Target: https://your-blog-slug.revmozi.com/news/:1

The :1 value passes the part matched by * to the Blesso origin.

Step 4: Set the rule order

Put the exact and wildcard rules above broader rules that could match /news. A rewrite takes priority over a Framer page at the same path.

Step 5: Publish the Framer project

Publish the project. A saved Multi Site rule does not affect the live domain until the project is published.

Step 6: Verify the route

Open /news, one article, and one image. Confirm the browser remains on the Framer-connected public domain.

Blesso emits assets and links for the public path prepared during deployment. If an asset loads from / instead of /news, ask support to inspect the latest publish.

If metadata or asset paths use the Blesso origin, ask Blesso support to republish for the final public URL. Framer documents external proxy requirements in its reverse-proxy hosting guide.

Cloudflare

Use this method when Cloudflare already sits in front of the website. It also works as the edge layer for some Webflow and managed WordPress setups.

Use a Worker route, not a Worker Custom Domain. A route lets unmatched requests continue to the current website origin. Cloudflare requires the website DNS record to be proxied, shown as an orange cloud. See Cloudflare's Worker route requirements.

Step 1: Confirm the website works through Cloudflare

Open DNS in Cloudflare. Find the record for www.example.com or the apex domain used by readers.

Confirm its proxy status is Proxied. Then open the homepage and an existing inner page. Fix any SSL or origin problem before adding the Worker.

Step 2: Create the Worker

Open Workers & Pages, select Create, and create a Worker. Give it a name such as blesso-blog-proxy.

Step 3: Add the proxy code

Replace the starter code with:

const BLESSO_ORIGIN_HOST = "your-blog-slug.revmozi.com";
const BLOG_PATH = "/news";

export default {
	async fetch(request) {
		const incomingUrl = new URL(request.url);
		const isBlogRequest =
			incomingUrl.pathname === BLOG_PATH ||
			incomingUrl.pathname.startsWith(`${BLOG_PATH}/`);

		if (!isBlogRequest) {
			return fetch(request);
		}

		const upstreamUrl = new URL(request.url);
		upstreamUrl.protocol = "https:";
		upstreamUrl.hostname = BLESSO_ORIGIN_HOST;

		return fetch(new Request(upstreamUrl, request));
	},
};

Replace BLESSO_ORIGIN_HOST and BLOG_PATH. Do not include https:// or a path in the hostname value.

Step 4: Deploy the Worker

Select Deploy. The preview confirms that the script compiles. The production check happens through the website route.

Step 5: Add the website route

Open the Worker, then select Settings > Domains & Routes > Add > Route. Choose the website's Cloudflare zone and enter:

www.example.com/news*

Add a second route only if readers also use the apex domain directly:

example.com/news*

The route ends in * so it also matches query strings. The code performs the stricter path check, so /newsroom stays on the current website.

Do not add a www.example.com/* route for this Worker. That would put every website request through blog routing code.

Step 6: Verify the public website

Open the homepage, /news, one article, one asset, and /newsroom. The existing website must still own every unrelated path.

Step 7: Inspect Worker logs if it fails

Open Workers & Pages > blesso-blog-proxy > Logs. A missing request usually means the DNS record is not proxied or the route uses the wrong hostname.

AWS Amplify Hosting

Amplify Hosting supports external 200 rewrites. Amplify fetches the Blesso origin while the browser keeps the public URL. See AWS's Amplify reverse-proxy example.

Step 1: Open the Amplify application

Open AWS Amplify, select the application serving the public website, and confirm its production branch and custom domain.

Step 2: Open the rewrite editor

Select Hosting > Rewrites and redirects, then select Manage redirects.

Step 3: Preserve the existing rules

Copy the current JSON somewhere safe while editing. Do not remove framework or 404 rules already required by the website.

Step 4: Add the two blog rewrites

Add these objects near the beginning of the existing JSON array:

{
	"source": "/news",
	"target": "https://your-blog-slug.revmozi.com/news",
	"status": "200",
	"condition": null
},
{
	"source": "/news/<*>",
	"target": "https://your-blog-slug.revmozi.com/news/<*>",
	"status": "200",
	"condition": null
}

Replace the hostname and /news. Keep both rules above an SPA or 404 wildcard such as /<*>.

Step 5: Save the rules

Select Save. Amplify applies redirect and rewrite rules from top to bottom, so rule order is part of the configuration.

Step 6: Verify the route

Open the homepage, /news, one article, one asset, and /newsroom. The address bar must stay on the Amplify custom domain.

Step 7: Check the effective rule order if it fails

If the website shell or 404 page appears, move the two blog rules above the matching wildcard. If the browser moves to the Blesso origin, confirm both statuses are 200, not 301 or 302.

AWS CloudFront

Use this method when an existing CloudFront distribution already serves the website.

CloudFront sends the original path to the selected origin. The distribution therefore needs a new origin and two path behaviors. See AWS's cache behavior documentation.

Step 1: Open the active distribution

Open CloudFront in AWS. Select the distribution whose alternate domain name contains www.example.com or the public website hostname.

Confirm the distribution status is Enabled and the existing website loads before changing it.

Step 2: Add the Blesso origin

Open Origins, select Create origin, and enter:

Origin domain:           your-blog-slug.revmozi.com
Protocol:                HTTPS only
Origin path:             leave empty
Minimum origin TLS:      TLS 1.2

Do not enter https:// or /news in the Origin domain field. CloudFront sends the viewer path, including /news, to this host.

Step 3: Add the exact path behavior

Open Behaviors and create a behavior for:

/news

Select the Blesso origin and use these starting settings:

Viewer protocol policy:  Redirect HTTP to HTTPS
Allowed methods:         GET, HEAD, OPTIONS
Cache policy:            CachingDisabled
Origin request policy:   AllViewerExceptHostHeader
Compress objects:        Yes

Step 4: Add the child path behavior

Create a second behavior with the same settings:

/news/*

AllViewerExceptHostHeader lets CloudFront replace the public website host with the Blesso origin host. AWS explains this behavior in its origin request policy documentation.

Start with caching disabled. Blesso already publishes cacheable static assets. A second cache can keep old HTML live after a new publish unless your release process invalidates CloudFront.

Step 5: Wait for deployment

Save the changes. Wait until the distribution status returns to Deployed before testing it.

Step 6: Verify both origins

Open the homepage, /news, one article, one asset, and /newsroom. The homepage and /newsroom must continue to use the original website origin.

Step 7: Add caching only with invalidation

If you later enable caching, forward every query string used by the blog and invalidate /news* after each publish.

Webflow

Webflow does not provide a native rule that sends one production path to an arbitrary external website. Its current guidance says path-level routing needs Cloudflare Workers or another edge function. See Webflow's self-managed reverse proxy guide.

Step 1: Confirm the production domain in Webflow

Open Site settings > Publishing > Production. Confirm the public website domain is connected, published, and serving the current Webflow site.

Do not use the *.webflow.io staging domain as an origin. Webflow does not support that proxy arrangement.

Step 2: Follow Webflow's Cloudflare migration prompt

If Webflow shows a migration prompt, use the exact CNAME values provided there. Do not change the production record to cdn.webflow.com before Webflow instructs you.

Step 3: Validate SSL before enabling the proxy

In Cloudflare, leave the Webflow DNS record as DNS only. Wait until Webflow reports SSL: Active and confirm the website loads over HTTPS.

Step 4: Enable Cloudflare proxying

Change the record to Proxied in Cloudflare and set SSL/TLS mode to Full (strict). Confirm the homepage and one Webflow CMS page still work.

Step 5: Create the Blesso Worker

Complete Steps 2 through 5 in the Cloudflare section above. Use the same Webflow production hostname in the Worker route.

Step 6: Verify Webflow and Blesso together

Open the homepage, a Webflow CMS page, /news, one Blesso article, and /newsroom.

The Worker should intercept only /news and its children. Every other request should continue to Webflow.

Step 7: Recover from an SSL or redirect failure

If normal Webflow pages fail, disable the Worker route first. If they still fail, return the DNS record to DNS only and finish Webflow's domain validation before retrying.

WordPress

WordPress is the content system, not necessarily the traffic router. The correct method depends on who controls the server or edge network.

Managed WordPress

This includes WordPress.com, WP Engine, Kinsta, Bluehost, GoDaddy, and similar services.

WordPress permalink settings and redirect plugins cannot reverse proxy a path to Blesso. They can only make WordPress handle the path or redirect the browser.

Step 1: Identify the hosting company

Open the WordPress Site Health page or hosting dashboard and identify who controls the web server and DNS. WordPress alone cannot tell you which proxy options the host permits.

Step 2: Ask whether proxied Cloudflare DNS is supported

Ask the host this exact question:

Can this website use proxied Cloudflare DNS and a Cloudflare Worker route for /news* while WordPress continues serving every other path?

Do not change nameservers until the host confirms the supported setup.

Step 3: Choose the supported route

• If the answer is yes, move or confirm the domain in Cloudflare and complete every step in the Cloudflare section.
• If the host offers its own external reverse proxy, give it the routing contract from the custom server section.
• If neither is supported, use the subdomain fallback.

Step 4: Keep WordPress out of the blog path

Remove any WordPress page, permalink, or redirect plugin rule that owns /news. Do not install a PHP proxy plugin.

Step 5: Verify both systems

Open /wp-admin, the homepage, an existing WordPress post, /news, and one Blesso article. WordPress administration and existing content must remain unchanged.

PHP proxy plugins add application latency and commonly break caching, content types, large assets, and security headers.

Self-hosted WordPress on nginx

Step 1: Find the HTTPS server block

Connect to the server and find the nginx configuration whose server_name contains the public website domain.

Step 2: Add the blog locations

Add these blocks inside that server block:

location = /news {
	proxy_pass https://your-blog-slug.revmozi.com/news;
	proxy_ssl_server_name on;
	proxy_set_header Host your-blog-slug.revmozi.com;
	proxy_set_header X-Forwarded-Host $host;
	proxy_set_header X-Forwarded-Proto $scheme;
}

location ^~ /news/ {
	proxy_pass https://your-blog-slug.revmozi.com/news/;
	proxy_ssl_server_name on;
	proxy_set_header Host your-blog-slug.revmozi.com;
	proxy_set_header X-Forwarded-Host $host;
	proxy_set_header X-Forwarded-Proto $scheme;
}

Replace the Blesso hostname and /news in both blocks.

Step 3: Validate nginx

nginx -t

Do not reload nginx until this command succeeds.

Step 4: Reload nginx

systemctl reload nginx

The exact block prevents /newsroom from being sent to Blesso. nginx also needs proxy_ssl_server_name on for the hosted origin's TLS certificate. See the nginx proxy module reference.

Step 5: Verify WordPress and the blog

Open the WordPress homepage, /wp-admin, /news, one article, one asset, and /newsroom.

Self-hosted WordPress on Apache

Apache needs mod_proxy, mod_proxy_http, mod_ssl, and virtual-host access. Shared hosting often does not permit this in .htaccess.

Step 1: Confirm the required modules

Confirm mod_proxy, mod_proxy_http, and mod_ssl are enabled. Ask the server administrator when you do not control module loading.

Step 2: Find the HTTPS virtual host

Open the Apache virtual host for the public website domain. Do not place this configuration in WordPress .htaccess.

Step 3: Add the proxy mapping

Add this inside the HTTPS virtual host:

SSLProxyEngine On

RedirectMatch 308 ^/news$ /news/
ProxyPass "/news/" "https://your-blog-slug.revmozi.com/news/"
ProxyPassReverse "/news/" "https://your-blog-slug.revmozi.com/news/"

Replace the Blesso hostname and /news.

Step 4: Validate and reload Apache

Run the configuration test provided by the operating system, such as apachectl configtest. Reload Apache only after the test reports success.

The first rule normalizes /news to /news/ on the same public domain. The proxy rule then handles posts and assets without catching /newsroom.

Step 5: Verify WordPress and the blog

Open the WordPress homepage, /wp-admin, /news, one article, one asset, and /newsroom.

Apache documents this mapping in its reverse proxy guide.

Any nginx or custom server

Use the nginx configuration above when you control a virtual machine, container ingress, load balancer, or Kubernetes gateway that accepts equivalent route rules.

Step 1: Identify the public routing layer

Find the component that currently receives HTTPS requests for the website. Change that component rather than adding routing inside the application.

Step 2: Add the routing contract

Match exactly:       /news
Match descendants:   /news/*
Do not match:        /newsroom
Destination host:    your-blog-slug.revmozi.com
Destination path:    preserve the full incoming path
Destination scheme:  HTTPS

Preserve query strings. Send the Blesso origin hostname as the upstream Host. Do not rewrite HTML in transit.

Step 3: Validate the configuration

Use the gateway's configuration check or staging environment. Do not apply an unvalidated routing file directly to production.

Step 4: Deploy or reload the gateway

Apply the configuration using the platform's normal release process. Wait for every proxy or load-balancer instance to receive it.

Step 5: Verify both origins

Open the homepage, /news, one article, one asset, and /newsroom. Check the gateway logs if the request reaches the wrong origin.

Wix, Squarespace, and other managed website builders

These platforms generally do not expose an external reverse-proxy rule. Do not try to reproduce one with browser JavaScript or an iframe.

Step 1: Check the host's current documentation

Search the host's documentation for external rewrite or reverse proxy. A redirect feature is not enough.

Step 2: Ask whether an edge proxy is supported

Ask whether the custom domain can use Cloudflare or another supported edge network without breaking SSL, domain verification, or platform support.

Step 3: Use the supported edge method

If the host supports proxied Cloudflare DNS, complete every step in the Cloudflare section. Verify the existing website before adding the Worker route.

Step 4: Use a subdomain when path routing is unsupported

If the host does not support an edge proxy, stop. Complete the subdomain fallback instead of adding an unsupported workaround.

Step 5: Verify the existing builder site

Open the homepage, an existing inner page, the blog subdomain or path, and the host's editing or preview flow.

Subdomain fallback

Use a subdomain when the current host cannot proxy a path safely:

https://blog.example.com

Step 1: Ask Blesso support to change the public URL

Send https://blog.example.com to Blesso support. Ask support to republish the blog for the subdomain root and return the new origin or DNS instructions.

A blog built for /news should not simply be pointed at a root subdomain.

Step 2: Add the subdomain in Blesso

Then connect the subdomain using How to add a custom domain or subdomain.

Step 3: Add the DNS record

Add the exact record shown by Blesso at the DNS provider. Do not guess the target from examples in this guide.

Step 4: Wait for activation

Wait until Blesso reports that the domain is verified and active. DNS and certificate issuance can finish at different times.

Step 5: Verify the subdomain

Open the blog index, one article, one asset, and the sitemap. Confirm the old path on the main website no longer appears in navigation.

A subdomain is a sound fallback. It is better than a redirect, iframe, unsupported plugin, or proxy that serves stale pages.

Verify the complete route

Run these checks in a private browser window after the proxy is live:

Then inspect a published article:

• The address bar stays on www.example.com/news/....
• The response is 200, not a chain of redirects.
• The canonical URL uses www.example.com/news/....
• Social metadata uses the public URL.
• Internal article links remain under /news.
• No asset request returns the website's HTML fallback.

Submit https://www.example.com/news/sitemap.xml in Google Search Console and Bing Webmaster Tools. If you control the root robots.txt, add this line:

Sitemap: https://www.example.com/news/sitemap.xml

Troubleshooting

When asking Blesso support for help, include the public URL, Blesso origin, hosting provider, failing path, response status, and a screenshot of the route rule. Do not send passwords, API tokens, or private keys.