The short version
- Google has said it handles both fine. In practice, subdirectories are the safer default and most migrations run in that direction.
- A subdirectory shares your domain’s signals unambiguously. A subdomain may be treated as a somewhat separate entity.
- Choose a subdomain for genuine technical necessity — a different stack, a separate application — not for SEO reasons.
- Whatever you pick, do not switch without a proper redirect map. The migration risk usually exceeds the theoretical gain.
This argument has run for well over a decade, partly because the official position and the practitioner consensus have not always sounded identical. Google has stated it handles both structures fine. A great many practitioners have nevertheless reported improvements after consolidating a subdomain into a subdirectory.
Both things can be true. Search engines can be capable of treating a subdomain as part of the same site while consolidation still helps, because consolidation also fixes the internal linking and structural clarity that were the real problem.
The short answer
Fit for your workflow
Subdirectory by default. Subdomain only for genuine technical necessity.
Put your blog, documentation and resources at example.com/blog rather than blog.example.com unless there is a real technical reason not to. The subdirectory shares your domain unambiguously and makes internal linking natural. Use a subdomain when the content genuinely runs on separate infrastructure you cannot proxy — a hosted help desk, a status page, a separate application.
- Blog on the same stack
- Subdirectory. No reason to separate it.
- Blog on a different platform
- Subdirectory via a reverse proxy if you can; subdomain if you cannot.
- Hosted help desk or status page
- Subdomain. Fighting this is not worth the effort.
- Different language or region
- Different decision entirely — see the international guide.
What actually differs
The second row is where the practical difference lives. Teams with a subdomain blog routinely fail to link between it and the main site, because they are different codebases maintained by different people. The structural separation becomes an editorial separation, and the internal link graph fragments — which is a real SEO cost regardless of how search engines treat subdomains in principle.
If you are considering a migration
- Be honest about the expected gain. It is usually modest and partly attributable to fixing internal linking, which you could do without migrating.
- Map every URL from the old structure to its new equivalent before touching anything.
- Use 301 redirects, not 302s — see the comparison.
- Avoid chains. Map old URLs directly to final destinations.
- Update internal links rather than relying on redirects to carry them.
- Crawl the old URL list immediately after launch to verify every redirect resolves in one hop.
Fix the linking before you move anything
Before committing to a migration, run the cheap experiment. Add proper internal linking between your main site and the subdomain — navigation links in both directions, contextual links from relevant pages, the subdomain’s content surfaced where it is genuinely useful. Then wait a quarter and look at Search Console.
A meaningful share of reported subdomain underperformance turns out to be a linking problem wearing a structural costume. If the linking fix moves the numbers, you have your answer at no risk. If it does not, you now have a much better case for the migration, and the linking work you did is not wasted — you will need it in the new structure anyway. See internal linking.
The migration is riskier than the structure
Botched redirect mapping during a structural migration is one of the most reliable ways to lose a large share of traffic permanently. If your subdomain is performing adequately, the expected gain from consolidating rarely justifies the downside risk. Fix the internal linking first and see whether that was the real problem.