URL structure is one of the last places in SEO where people still argue from folklore. Someone read a 2013 case study about moving a blog from a subdomain to a subdirectory, traffic went up, and fifteen years later that anecdote is still driving six-figure engineering decisions.
The uncomfortable truth is that most URL choices are weak signals with strong opinions attached. A few of them genuinely matter — just not the ones that get debated. Here's what the evidence actually supports, separated from what's reasonable inference and what's noise.
Does Google treat a subdomain as a separate site?
Mostly no, sometimes yes, and that ambiguity is the entire answer.
Google's documented position, repeated by John Mueller and others for years, is that Google can crawl and index either arrangement and that you should pick whatever is easier for you to run. Google Search Console still splits them: a domain property covers subdomains, but a URL-prefix property for https://blog.example.com/ reports separately from https://example.com/. That's a reporting boundary, not a ranking one.
Where the boundary becomes real is in host-level grouping. When Google rolled out its site diversity change in 2019 — limiting how many results from the same site appear in a single SERP — its public search liaison account said subdomains are generally treated as part of the root domain for that purpose, while noting Google may treat them separately when it makes sense. That "when it makes sense" is doing a lot of work. Genuinely independent hosts (think a large hosting platform where every customer gets a subdomain) get treated as distinct sites; a marketing blog on blog.example.com almost certainly does not.
So the algorithmic difference between example.com/blog/ and blog.example.com is small and hard to isolate. The migration cost between them is not small. Google's own site move documentation treats a subdomain-to-subdirectory change as a URL-changing site move, which means redirects, re-crawl lag, and temporary volatility. If your traffic is fine, the expected value of that project is usually negative.
Then why do subdomain-to-subdirectory migrations so often "work"?
Because the subdomain was rarely the actual problem. It was the symptom of a structural one.
Subdomains tend to exist because a different team owns the content, often on a different platform. That produces the things that really suppress performance:
- Broken internal linking. The blog links to itself and to the homepage; the product pages never link into the blog. Internal link equity and crawl discovery both suffer, and that's a graph problem, not a hostname problem.
- Divergent templates. Separate navigation, separate breadcrumbs, no shared header links, sometimes a separate and worse mobile experience.
- Duplicate or conflicting canonicals between the two hosts, especially when both serve near-identical landing pages.
- Separate analytics and separate ownership, so nobody notices decay.
When a migration fixes all of that at once and traffic improves, the hostname gets the credit. If you want to test the hypothesis cheaply, fix the internal linking and templates first and leave the host alone. If the numbers move, you just saved yourself a migration.
The one case where consolidating onto the main host has a clear mechanism: when the subdomain is small and new, and the root domain is established. Site-level signals are computed per host in at least some systems, and a thin standalone host has less to draw on. That's an inference, not a Google statement — but it's a defensible one.
Does folder depth hurt rankings?
The number of slashes in a path is not a ranking factor. Google representatives have said this repeatedly, and there's no plausible mechanism for it — the path string is an identifier, not a measure of importance.
What does matter is click depth: how many internal links you have to traverse from a well-linked entry point to reach the page. Click depth is a real driver of crawl discovery and crawl frequency, because Google finds URLs by following links and prioritizes based on the signals flowing to them. These two things are frequently confused because they often correlate — deep folders usually mean deep navigation — but they're separable, and the separation is useful:
/electronics/audio/headphones/wireless/anc/sony-wh1000xm5
Six path segments. If that product is linked from a "best sellers" module on the homepage, it's one click deep and will be crawled often. Meanwhile:
/p/sony-wh1000xm5
One segment, but if it's only reachable through eight paginated listing pages, it's effectively buried.
What path structure does buy you is operational leverage. Consistent folders make it trivial to segment Search Console and log data, apply robots.txt rules, and scope redirects. Google's documentation does say a logical URL structure helps it understand how your content is organized — treat that as a mild organizational benefit, not a ranking lever.
Do keywords in the URL do anything?
A little. Google's URL structure documentation recommends simple, descriptive words over long ID strings, and recommends hyphens rather than underscores or run-together words. That's documented advice, and it's cheap to follow on new URLs.
The size of the effect is where people overreach. Mueller has described words in URLs as a very small ranking factor and something SEOs overrate. There are two plausible mechanisms, both modest: a weak text-matching signal, and a user-facing one — Google bolds matched query terms in the displayed URL or breadcrumb, which may nudge click-through.
The practical conclusion follows directly: put keywords in URLs when you're creating them, and almost never rewrite existing URLs to add them. A rewrite costs you redirect chains, re-crawl time, lost link equity through the 301, and analytics discontinuity — to buy a very small factor.
Which URL decisions actually have strong evidence?
The ones about identity. A URL is the primary key Google uses to store a document. Everything that fragments or destabilizes that key has documented consequences.
| Decision | Evidence strength | Why it matters |
|---|---|---|
| One canonical URL per piece of content | Strong, documented | Prevents signal splitting and canonical guesswork |
| URL stability over time | Strong, documented | Every change costs re-crawl time and redirect loss |
| Consistent trailing slash and case | Strong | /Page and /page are different URLs; hosts aren't case-sensitive, paths are |
| Consistent protocol and www choice | Strong | Four variants of the same page is the classic self-inflicted duplication |
| Parameters that don't change content | Strong | Tracking and session params generate near-infinite crawlable variants |
| Descriptive words, hyphens | Documented, weak effect | Small text signal, minor CTR effect |
| Subdirectory vs subdomain | Weak / contested | Migration cost usually exceeds expected benefit |
| Path depth | No evidence of direct effect | Confused with click depth, which does matter |
What to do
- Audit for URL variants before anything else. Confirm one canonical host and protocol, one trailing-slash convention, lowercase paths enforced at the edge, and no indexable tracking-parameter variants. This is where the recoverable losses are.
- Measure click depth, not folder depth. Crawl your site and pull the shortest internal-link distance to every indexable URL. Fix anything important sitting past three or four clicks with real internal links, not sitemap entries.
- Set URL conventions for new content and freeze old URLs. Short, hyphenated, descriptive, stable. Then stop touching them.
- Default to a subdirectory on greenfield builds — it's marginally better on the ambiguous signals and strictly easier to link internally. On existing sites, only migrate a subdomain when you have an independent reason (platform consolidation, shared templates, one analytics stack), and count the SEO benefit as a bonus rather than the justification.
- Test the cheap fix first. If someone proposes a subdomain migration to recover traffic, spend two weeks on internal linking and template parity. If that doesn't move the numbers, you now have a much better argument for the migration budget.