subdomain to subfolder migration
Consolidating a blog, docs or help center onto the main domain. Frequently the right call, frequently oversold, and always a full migration rather than a configuration change.
Primary riskEvery URL on the subdomain changes host at once, and the routing layer becomes a shared dependency between two platforms.
“Move your blog from a subdomain to a subfolder” is common advice, and it is generally correct. Consolidating content onto one hostname does concentrate signals, and Google does evaluate subdomains as related but somewhat separate properties.
What the advice usually omits is that this is a full migration. Every URL on the subdomain changes host. The engineering work is real and ongoing. And the benefit, while genuine, is gradual — it is not a switch that produces a visible step change next month.
Two questions decide whether it is worth doing: does the subdomain carry enough traffic and links to justify the risk, and will someone own the routing layer in two years when the person who built it has moved on?
The SEO part of a subdomain consolidation is straightforward — a redirect map and a canonical strategy. The hard part is serving content from a different platform under one hostname.
That means a reverse proxy, an edge worker, or an equivalent rewrite at the CDN. It introduces a shared dependency between two systems that were previously independent, and it introduces cache behavior that has to be designed rather than inherited.
Get the caching wrong and the failure mode is worse than an SEO problem. A misconfigured cache key on a proxied path can serve one user’s authenticated page to another. That risk belongs to engineering and security, and it is the reason this decision cannot be made on SEO grounds alone.
Platform independence.
Today, changing your docs or blog platform is a DNS change. After consolidation, it touches shared routing configuration on your primary domain. If you are on your third blog platform in four years, that cost is not theoretical.
This is why the honest answer is sometimes “leave it”. A subdomain with modest traffic, on a platform you expect to replace, is not worth the migration risk plus the permanent coupling. Saying so is more useful than repeating the general rule.
Segment Search Console by host before anything else. In software companies especially, the result is often surprising — documentation frequently out-earns the marketing site for organic entrances, which changes both the value of consolidating and the risk of getting it wrong.
If the subdomain turns out to carry 3% of organic traffic, the calculation is easy and the answer is probably no. If it carries 40%, the upside is real and so is the need to treat this like the full migration it is.
Site consolidation covers the harder case where two properties both rank for overlapping topics. The technical scope page covers redirect architecture and where rules should live, and the checklist sets the phase gates.
What you see Pages serve stale content, or one user’s personalized page is served to everyone. Sometimes a login state leaks between visitors.
What fixes it Define cache keys and vary headers explicitly at the proxy layer before launch. This is an engineering design decision, not an SEO setting.
What you see Pages serve at example.com/blog/ while every image, script and stylesheet requests from blog.example.com. The subdomain never actually retires.
What fixes it Route assets through the primary domain too, or at minimum ensure the subdomain host serves only assets and no indexable HTML.
What you see blog.example.com and example.com/blog/ both return 200 with identical content, competing as duplicates.
What fixes it The subdomain must 301 to the subfolder path for every URL. A canonical tag is a hint; the redirect is the instruction.
What you see Every link between blog posts takes an extra hop through the redirect layer, and crawl efficiency on the moved section drops.
What fixes it Rewrite internal links inside the migrated content at the source, including any absolute URLs stored in the content database.
| Factor | Subdomain | Subfolder | Which wins |
|---|---|---|---|
| Setup effort | A DNS record | Reverse proxy or edge routing configuration | Subdomain, clearly |
| Authority consolidation | Related host, evaluated somewhat separately | Shares the primary domain directly | Subfolder, gradually rather than immediately |
| Platform independence | Swap platforms with a DNS change | Platform changes now touch shared routing | Subdomain — a real and often ignored cost |
| Analytics | Cross-domain tracking required for a full-funnel view | One property, one session | Subfolder |
| Ongoing maintenance | Independent, low coupling | Two systems sharing a routing layer | Subdomain |
| Migration risk | Zero if you leave it alone | A full migration of every URL on the subdomain | Subdomain — the cost is paid once, but it is real |
Routing is settled before mapping. Nothing else is testable until it is.
Segment Search Console by host. Decide with the real number in front of you rather than with an assumption about which property matters more.
Output Traffic and link split by host
Reverse proxy, edge worker or path rewrite. Engineering owns this decision; it determines everything downstream, including whether the plan is feasible at all.
Output Routing design with an owner
Cache keys, vary headers, cookie scope and authentication boundaries across the two systems. Get this wrong and the failure is a security issue, not an SEO one.
Output Caching and header specification
One row per subdomain URL. These are usually deep, stable and externally linked, so pattern rules alone will not do.
Output Subdomain redirect map
Including absolute URLs stored in the content database, which no template change will catch.
Output Updated internal links
Confirm the subfolder path serves 200 and the subdomain 301s for every priority URL. Both checks, run against production.
Output Post-cutover verification results
Generally yes, though the effect is gradual rather than a step change. Google treats subdomains as related but somewhat separate hosts. Consolidating concentrates signals on one hostname. It is a real benefit and a smaller one than most articles on the subject suggest.
Expect four to twelve weeks of volatility, then gradual improvement over several months as signals consolidate. Anyone promising a fast, visible lift from consolidation alone is describing something other than what usually happens.
If the content runs on a different platform, yes — something has to serve it under the primary domain. That is a reverse proxy, an edge worker or an equivalent rewrite. It is an engineering commitment, and it needs an owner after launch, not just during it.
Then consolidation is not available, and forcing it usually creates more problems than it solves. Leave it on the subdomain and focus on internal linking between the properties instead. That is a legitimate outcome, not a compromise.
Send the launch date and what is changing. We will tell you which parts of this page apply to your situation and which do not.