Reverse Proxy for a Blog in a Subfolder: SEO Setup

Short answer: A reverse proxy lets the main domain answer requests for a path such as /blog/ by fetching the pages from another system, so a blog on a different platform can live in a subfolder. It can work well for SEO, but only if the proxy passes the status codes through, the blog generates URLs, canonicals, sitemaps and links for the public address, redirects and caching are configured, and everything is tested with a crawler before launch. Done carelessly, it creates duplicate hosts, wrong canonicals and slow pages.

Many companies run their main site on one platform and their blog on another, often a content management system with better editing tools. The blog is then placed on a subdomain such as blog.example.com. As explained in the guide to blog subdomain versus subfolder, a subfolder is often easier to manage as one site. When the platforms cannot live together, a reverse proxy offers a way: visitors see example.com/blog/, while the content comes from somewhere else. This article explains the setup from the SEO side and lists the traps. It is written for site owners and the developers who will implement it.

How a reverse proxy works

A reverse proxy is a server that stands in front of other servers. When a request arrives for example.com/blog/some-post/, the proxy forwards it to the blog system, receives the answer and returns it to the visitor under the main domain. The visitor and the search engine never see the origin address. Proxies can be a web server such as Nginx or Apache, a content delivery network with routing rules, a load balancer or an edge worker. The choice affects speed and cost, but the SEO requirements are the same.

What matters is that the public address is the only address that exists in practice. Everything the blog sends back, from links to canonical tags and sitemaps, must be written for example.com/blog/, not for the origin host. If the origin host remains reachable and indexable, search engines may find two copies of every page, which leads to the problems described in the guide to duplicate URLs.

Configure the routing carefully

Route a clean path prefix to the blog and nothing more. Decide how the root of the blog, the trailing slash and the paths for images, scripts and the feed will work. Include the static assets in the same prefix or serve them from a clear separate path, and make sure they are not blocked. Pass the original host and protocol to the origin with the usual forwarding headers, so that the blog can build correct absolute URLs, and set the blog’s own site address to the public one.

Keep the paths consistent: if your site uses trailing slashes, make the blog do the same, as covered in the guide to www and trailing slash consistency. Avoid rewriting the path in a way that changes the part after the prefix, since that makes redirects and canonicals harder to reason about. If the blog must live under a different internal path, document the mapping and test it in both directions.

URLs, canonicals and internal links

After the routing works, check what the blog actually outputs. View the source of several pages and look for the canonical tag, the Open Graph URL, the previous and next links, the breadcrumb data, structured data and the links in the menu and footer. Any address with the origin host is a mistake. Many systems have a setting for the site address, and some need a rule to replace hard-coded addresses in older posts. A search and replace in the database may be needed for old content.

Make the main site’s navigation link to the blog with the public address and make the blog’s navigation link back to the main site. Keep the header and footer consistent, if you can, so that visitors do not feel they have left. Review the general canonical rules in the guide to canonical tags, and the common conflicts in the guide to conflicting SEO signals.

Status codes, redirects and errors

The proxy must pass the origin status code through unchanged. A missing post must return a 404 to the visitor, not a 200 with an error message, and a moved post must return the 301 redirect. Check also what happens when the origin is slow or down: some setups return a custom error page with a success code, which search engines treat as a soft error, as described in the guide to soft 404 errors. Configure a short timeout and a clear 5xx response so crawlers know to come back later; see the guide to website downtime.

If the blog used to live on a subdomain, set up 301 redirects from each old address to the new one, one to one, and avoid chains, as explained in the guide to redirect chains. Keep the origin from answering to the public at its own address: protect it with a login, an allow list or a redirect to the public address, and add noindex as a second layer of defence only if redirection is not possible.

Robots, sitemaps and feeds

The blog has its own sitemap, robots rules and feed, and they need to fit the main site. The robots.txt file that crawlers read is the one at the root of the main domain, so any rules for the blog must be included there, not in the origin’s own file. Make sure the sitemap of the blog lists public addresses and is referenced in the main robots.txt or in a sitemap index. Check that the feed address works under the prefix and that its links are public. See the guide to XML sitemaps and the guide to robots.txt.

Check the search console properties as well. A domain property covers the subfolder automatically, and a URL-prefix property for the blog path can give a separate view of its performance. Keep the old subdomain property for a while after the move to watch the redirects.

Caching, speed and security

A proxy adds a step, so speed can suffer. Place a cache in front of the blog for pages that do not change by user, set sensible lifetimes and make sure the cache respects the origin’s headers where appropriate. Avoid caching error pages for long, and avoid caching responses that contain personal data. Compress the responses and keep the connection to the origin fast, ideally in the same region. Measure the time to first byte for the blog before and after, as described in the guide to server response time, and check the caching headers with the guide to HTTP caching headers.

Be careful with cookies. If the main site sets cookies for the whole domain and the blog sets its own, make sure they do not interfere, and that the proxy does not strip the headers that the blog needs, for example for the login of editors. Protect the editing area so that it is not exposed through the public prefix without need.

Test before and after launch

Create a staging copy of the setup, block it from search engines and run a full crawl. Check that every page returns the expected status code, has one canonical to the public address, has no links to the origin host and appears in the sitemap. Test a sample of old addresses for redirects. Compare the number of pages before and after, the titles and the descriptions. After launch, crawl again, check the page indexing report in Search Console and watch the crawl statistics and server logs for errors; see the guide to the crawl stats report.

Prepare a rollback plan. If something goes wrong, you should be able to remove the routing rule and return to the earlier setup quickly. Keep the redirects and the old structure intact until the new one is stable. The planning of such changes is similar to a small migration, as covered in the guide to the site migration checklist.

Here is a short example. A company moved its blog from a subdomain to a subfolder through a proxy. The blog still generated canonicals with the old subdomain, and the origin remained public, so search engines saw both. After the team fixed the site address setting, redirected the old host to the public path and added the routes to the sitemap index, reports became clean and the blog’s pages appeared under the main domain.

A second example is a team that forgot that the proxy returned 200 for missing posts. A crawl found hundreds of soft errors within minutes, and the fix was a single rule to pass the origin status.

Site SEO AI Audit crawls your website and reports status codes, redirect chains, canonical tags, noindex, sitemap issues, broken links and page speed, so you can check the blog under its public address after a proxy setup. It does not configure your server. The first audit of up to 200 pages is free, and larger sites can see the pricing page.

The bottom line

A proxy is only an SEO win when the public address is the only one that exists, with correct status codes and canonicals.

FAQ

Is a reverse proxy better than a subdomain for SEO?

It can be easier to manage as one site, but it adds complexity. Both work when they are set up correctly.

Will search engines see that a proxy is used?

They see the public address and the responses. What matters is that those responses are correct and consistent.

What is the most common mistake?

Leaving the origin host public and letting the blog output canonicals and links with that host.

Where should robots.txt rules for the blog go?

In the robots.txt file at the root of the main domain, since that is the file crawlers read.

Does a proxy slow the blog?

It can, but caching and a fast connection to the origin usually offset it. Measure before and after.