Link Plumbing

Moving Content Between a Subdomain and a Subdirectory

Moving content between blog.example.com and example.com/blog/ is a host change, and a host change is the most consequential kind of URL change short of switching domains. Every URL in the section changes, and a set of host-scoped things — robots rules, sitemap scope, cookie scope, certificates, analytics properties, search-console properties — moves with it.

Search engines document that either structure can work, so the interesting question isn’t which is better in the abstract. It’s what breaks during the move, and which of the things people attribute to the structure are actually artefacts of the migration.

What genuinely changes

Robots scope. A subdomain has its own robots.txt. Fold it into a subdirectory and the parent host’s file governs the content — including any Disallow patterns written years ago for other purposes. This is the single most common way a subdirectory move loses crawling: the section arrives inside a robots policy nobody re-read. See One robots.txt Per Host, Not Per Folder.

Sitemap scope. A sitemap may only list URLs on the host that serves it. A sitemap at blog.example.com/sitemap.xml listing example.com/blog/... URLs is cross-host and won’t be trusted as a submission. Publish the new sitemap on the new host and keep the old one alive, listing the old URLs, so the redirects get discovered.

Search Console properties. A domain property covers subdomains; a URL-prefix property does not. If your reporting was a prefix property on the subdomain, the data does not follow the content, and the apparent traffic cliff on the old property is a reporting boundary, not a loss. Set up the destination property before you migrate so you have both sides of the line.

Cookies, auth and CSP. Not SEO, but it breaks in the same window. Cookies scoped to the subdomain don’t apply to the parent path; a Content-Security-Policy or CORS allowlist naming the subdomain needs updating; anything doing host-based routing at the edge needs a new rule.

Certificates and edge config. The old host has to keep resolving and keep a valid certificate for as long as you want the redirects honoured — which is indefinitely, if the section earned links. A redirect that fails TLS is not a redirect; it’s a dead host. Both DNS and the certificate for the old name are part of the permanent cost of the move.

What doesn’t change by itself

Consolidating a section into the parent host does not transfer anything on its own. Signals move because redirects move them, and only for URLs you actually mapped. There’s no host-level merge step.

Which is why the honest framing for a subdomain-to-subdirectory move is: you are paying a migration cost for a structural preference. If the section is small and the structural argument is weak, the cost may not be worth it. If you’re consolidating because two teams keep publishing overlapping content on two hosts, the structural argument is real, and the move is a means to a content decision.

Redirect mapping

One hop, per URL, permanent. Redirect Chains and How to Flatten Them covers why a chain is worth avoiding; a host move is where chains breed, because the old host often already had internal redirects that now prepend a hop.

# On the OLD host only. Preserve the path, one hop, no chain.
server {
    server_name blog.example.com;
    return 301 https://example.com/blog$request_uri;
}

The two details that decide whether this works:

  • Preserve the path and query string. $request_uri includes both. Dropping the query string breaks paginated and filtered URLs and any inbound link carrying tracking parameters.
  • Do not redirect everything to the new section’s index. A blanket redirect to /blog/ is the classic shortcut and it discards the mapping entirely. If a URL has no counterpart, decide per URL: redirect to the closest equivalent if one genuinely exists, or let it 404. A redirect to an unrelated page is treated as a soft 404 anyway, so the shortcut doesn’t even buy what it promises — see Soft 404s.

Trailing-slash and case conventions frequently differ between two stacks, and each mismatch becomes an extra hop or a duplicate. Trailing Slashes Are Different URLs and Uppercase URLs and the Duplicates They Create are worth a pass over the mapping file before you ship it.

Also update your own links. Internal links pointing at the old host still work through the redirect, and they still cost a hop on every crawl and every click, and they keep the old host looking live in your own analytics. Rewrite them in content, nav, sitemaps, feeds and canonical tags.

The ccTLD variant

Folding a country domain into a subfolder — example.ie into example.com/ie/ — is the same migration plus a signal change. A ccTLD carries a geographic association by virtue of being that ccTLD. A subfolder carries none; the association has to be rebuilt from content, hreflang and the rest.

If you’re doing this, the return-tag requirement is where it fails: every locale must reference every other, including itself, and a one-directional set is ignored rather than partially honoured. See Hreflang and the Return-Tag Requirement. Expect the geo-targeted queries to behave differently from the generic ones during and after the move, and don’t read a drop on locale-specific terms as evidence that the redirects failed — check the redirects directly instead.

Reading the aftermath honestly

Traffic almost always moves after a host change, and the shape of the move tells you more than the size.

  • Immediate, total loss on the section → mechanical. Check the redirects resolve one-hop with a live certificate, check robots on the new host, check for a stray noindex in the new template.
  • Gradual re-crawl over weeks, old URLs falling out as new ones appear → the migration working as designed. The two curves should be roughly complementary.
  • Persistent softness on the new URLs after re-crawl → the interesting case, and the one people attribute to subdomains-versus-subdirectories. Before accepting that explanation, confirm the mapping was complete rather than blanket, confirm nothing is chained, and confirm the internal links point at final URLs. Incomplete mappings and chains explain a lot of what gets blamed on structure.

Keep the old host, its DNS, its certificate and its redirect rules in place permanently. The links that pointed at the subdomain are the whole reason to be careful here, and Preserving Links Through a Site Migration is the longer version of that argument.

migrationsredirectscanonicals