Subdomain vs Subdirectory
Subdomain vs subdirectory is the choice between putting a section of your site on its own hostname, such as blog.example.com, or on a path of the main hostname.
Subdomain vs subdirectory is the choice between putting a section of your site on its own hostname, such as blog.example.com, or on a path of the main hostname, such as example.com/blog. It is not a ranking setting, and neither option comes with a bonus attached. The consequences land in operations, linking and ownership, which is where the decision should be made.
Why the choice matters
What you are really choosing is how much friction sits between two parts of your site. A subdirectory inherits the main site’s navigation, its templates, its analytics setup and its robots rules by default. A subdomain inherits none of that unless somebody configures it, and the person who would configure it usually works on a different team with a different backlog.
The failure is predictable. Content ships to a subdomain, the main navigation never links to it, nobody notices for two quarters, and the section quietly earns nothing. Then a migration gets proposed to fix a ranking problem that was actually a linking problem. Check how much traffic each section earns today before anyone builds a business case, because the numbers usually point at neglect rather than at the hostname.
How Google treats each one
Google’s public position, stated consistently by its Search Relations team over many years, is that both structures work and you should pick the one you can maintain. The differences are administrative, and they are worth knowing precisely because they are the ones that bite.
- Crawling ignores the boundary. Googlebot follows a link to another hostname the same way it follows any link. No permission step exists between your own hosts.
- robots.txt is per host. A subdomain needs its own file at its own root. Rules on the main site do not reach it, which is how staging subdomains end up crawlable.
- Sitemaps are scoped by host. A sitemap can list URLs beyond its own host only when both are verified in Search Console, so most teams end up managing two files.
- Search Console splits by property. A URL-prefix property covers one host; a Domain property covers the whole domain and its subdomains, which is the setup most people should have chosen from the start.
- Internal links still count across hosts. The link works. The problem is that navigation, breadcrumbs and related-content modules frequently stop at the hostname, so the links never get built.
- Cookies and analytics are host-scoped. Sessions crossing the boundary need explicit configuration, or your reporting will invent a new visitor every time somebody clicks through.
Every item on that list is a maintenance question rather than an algorithmic one, and each maps onto a decision about how the whole site is organised. That is the level at which this gets decided well, rather than in isolation for one section.
| Concern | Subdirectory | Subdomain |
|---|---|---|
| robots.txt | Shared with the main site | Separate file, on that host |
| Search Console | Inside the existing property | Needs a Domain property or its own |
| Analytics sessions | Continuous by default | Cross-host tracking must be configured |
| Hosting | Same stack, usually one deploy | Can point anywhere via DNS |
| Internal linking | Falls out of normal navigation | Has to be built deliberately |
| Ownership | Shared codebase, shared release process | A separate team can ship alone |
The blunt version
Google says it treats the two similarly and tells you to choose what you can maintain. That should close the question. It does not, because the argument in the room was never about search: it is about who owns the deploy. Marketing wants a content platform the engineering team refuses to run inside the main application. Engineering refuses because a separate host is a clean boundary and the alternative is a reverse proxy somebody has to babysit. The SEO case gets wheeled in as neutral evidence for a decision that has already been made politically.
Much of the supposed evidence traces to tools rather than to Google. Domain Authority and its equivalents are third-party scores. Google does not use them. Those tools often calculate by hostname, so a subdomain scores lower simply because the metric was built that way, and a measurement artefact has been quoted as a ranking fact for over a decade.
Use a subdirectory when the same team can ship both and the content serves the same audience. Use a subdomain when the stack, the security boundary or the ownership genuinely differs, and the honest alternative is infrastructure nobody wants to maintain. Then link the thing properly either way. If this argument is running hot at your organisation, the underlying issue is usually the one described in what happens when those two teams stop talking.
Example
Say a software company runs its help centre on a hosted support platform that only supports its own hostname, so the documentation lives at help.example.com. Two years on, the help centre outranks the marketing site for most product questions, but nothing on the main site links to it beyond a footer entry, and no help article links back to a pricing or feature page. The subdomain is not the fault. The absent links are. Moving everything to example.com/help would take a quarter of engineering time and a redirect map; adding contextual links in both directions takes an afternoon and captures most of the benefit anyone was promising from the migration.
FAQ
Does Google rank subdirectories higher than subdomains?
There is no bonus for either. Google’s stated position is that both work and you should choose what you can maintain. Where a subdirectory does outperform, the cause is almost always practical: it inherits the main navigation, so it receives internal links and gets updated by the same team, rather than sitting forgotten on its own host.
Does a subdomain need its own robots.txt file?
Yes. Crawlers read robots.txt from the root of each host, so blog.example.com is governed by its own file and not by the rules on example.com. Forgetting this is how staging and support subdomains end up fully crawlable, and how a blocking rule you assumed was site-wide turns out to cover only one host.
Should I migrate a blog from a subdomain into a subdirectory?
Only when you can maintain it there and something else already justifies the work, such as a platform change. A migration for its own sake spends engineering time and adds redirect risk to fix a difference Google says is minor. Build the internal links first, then judge whether a real problem remains.
Related terms
- Pagination — the other structural choice that decides whether deep content is reachable at all.
- Heading Hierarchy — structure inside the page, once you have settled where the page lives.
- Site architecture — the wider system this decision belongs to, rather than a one-off call.
If the SEO argument for one option is doing all the work, check whether the real disagreement is about who owns the deploy. Pick the structure your team can maintain, then spend the saved effort on the internal links that actually decide how the section performs.