Subdomain or subdirectory: what Google says and how to choose your structure
Table of contents
The same content can live at example.com/blog or at blog.example.com. Choosing subdomain vs subdirectory looks like an algorithm decision, but Google documents it as a business decision: it changes how you measure, which features treat you as a separate site, and what a move costs later.
Subdomain vs subdirectory: what each one is
A subdirectory is a path on the same host: example.com/blog/. A subdomain is another hostname, blog.example.com, with its own DNS entry, its own certificate and, if you want, a different server.
The mental rule for this topic: a subdirectory splits content; a subdomain splits infrastructure. That difference is what later shows up in measurement, in crawlers and in the cost of moving.
Why machines treat them differently
Google defines "site" by hostname in two features. For favicons: "one favicon per site, where a site is defined by the hostname"; that is why https://news.example.com can have its own and https://example.com/news cannot, because it is a subdirectory. For site names: "one site name per site, where a site is defined by the domain or subdomain", and they are not supported at the subdirectory level. Some pieces of Search only exist per hostname: a folder cannot have its own; a subdomain can.
Cookies, certificates and deployment
Cookies are issued per host: blog.example.com does not see cookies from example.com unless they are declared for the parent domain with Domain=example.com. A wildcard certificate covers the subdomains; a subdirectory lives inside the domain certificate. And a subdomain allows a different server, region or CDN: Google's own documentation lists that as an advantage.
What Google says (and what nobody can tell you)
The official answer is in the SEO starter guide: "From a business point of view, do whatever makes sense for your business". Decide for management convenience, not for a supposed ranking edge.
There is no ranking factor in the official documentation for using one or the other, no penalty on subdomains, and no rule that treats them as foreign sites: the links report groups by root domain, which sums the root, the subdomains and the folders.
So why does "subdomains rank worse" keep circulating? Because what you usually observe in practice is the effect of splitting infrastructure and internal links, not a Google call about the hostname. If someone quotes you a percentage, ask for the official source: there is none.
The multi-language case: the only official table
The multi-regional sites documentation is the only place that compares the options with pros and cons:
| Option | Example | Pros (doc) | Cons (doc) |
|---|---|---|---|
| Country domain (ccTLD) | example.de | Clear geotargeting; server location is irrelevant; easy separation of sites | Expensive; requires more infrastructure; can only target one country |
| Subdomain with gTLD | de.example.com | Easy to set up; allows different server locations; easy separation of sites | Users might not recognize geotargeting from the URL alone |
| Subdirectory with gTLD | example.com/de/ | Easy to set up; low maintenance (same host) | Single server location; separation of sites is harder |
| URL parameters | example.com?loc=de | - | Not recommended by Google |
And the detail everybody skips: a language subdomain does not communicate language. The hreflang documentation warns that en or de in a subdomain are not used to determine the target audience; that is what hreflang is for, not the host name. We cover it in the multilingual website guide.
Where it actually matters
Search Console: properties and verification
A URL-prefix property "includes only URLs with the specified prefix, including the protocol": it does not include subdomains, and the help page asks for a separate property for each subdomain. A Domain property aggregates all subdomains and protocols and is verified through DNS only.
Practical translation: if you move the blog to a subdomain and you use a URL-prefix property, your dashboard stops seeing it on day one. See Search Console and platform properties.
The links report and the fake "externals"
The links report groups by root domain: protocol, subdomain and subdirectories are stripped. But "external" means outside your property: with a URL-prefix property, a link from your own subdomain can show up as an external site. It is not a bad link, it is how the report groups data. See internal linking.
robots.txt: one per host
The robots.txt documentation is blunt: the rules apply only to the host, protocol and port, and a robots.txt on a subdomain is only valid for that subdomain. If you move /blog/ to blog.example.com, you have to create the one for the new host. See robots.txt.
Favicon, site name and sitelinks
A subdomain wins in what only exists per hostname: its own favicon and site name, which a subdirectory cannot have. If the subdomain declares no structured data on its home page, Google may use the parent domain site name as a fallback. Sitelinks, by contrast, are generated at the domain level.
When a subdomain makes sense
- A different stack or software: help center, documentation, forum or a store on another platform.
- Different infrastructure: another server, region or CDN.
- A different team and release cycle: deployments independent from the main site.
- An identity of its own: a product with its own name and favicon.
- Test environments:
staging.andtest..
The cost: separate verification and measurement, its own robots.txt, its own favicon and site name, and a more expensive move later.
When a subdirectory makes sense
- Blog, news and guides on the same topic as the main domain.
- Categories and sections of the same business.
- Language or country versioning with a gTLD (
/es/,/de/), which Google marks as "low maintenance (same host)". - Shared pieces: one robots.txt, one sitemap, one certificate, one deployment and one Search Console property.
- Cheap future moves: moving paths within the domain does not require Change of Address; changing host does.
With the same content, links and server speed, Google documents no ranking edge for using a folder. If someone sells you the opposite, ask them for the official source: there is none.
Four costly mistakes (and one that does not work)
Moving hosts will not get you out of a penalty
Google's spam policies include circumvention: creating new subdomains or subdirectories to keep violating the rules is one of the patterns the documentation describes. And the site reputation policy covers publishing third-party content on a host because of its previous authority. Moving problematic content to blog. or to /blog/ is not a strategy.
Indexed staging and duplicate content
Two classics: a crawlable staging.example.com that gets indexed and muddies your data, and a blog.example.com and an example.com/blog/ serving the same thing at once. The first is blocked or protected; the second is decided and redirected with a 301 to the chosen one.
And two measurement mistakes that cost dearly: verifying only one property and assuming it covers the whole domain, and forgetting Change of Address when the host changes.
How to migrate from a subdomain to a subdirectory (or the other way round)
- Inventory your URLs: the ones with links, traffic or pagination.
- Build a one-to-one 301 map to the equivalent URL, not everything to the home page.
- Check with the URL Inspection tool that every 301 resolves to a single final URL.
- Use Change of Address only if the host changes: the site move documentation states you do not need it for HTTP to HTTPS, www to non-www, or for moving paths within the same domain.
- Keep the redirects for at least one year.
- Update internal links, sitemaps and templates.
- Watch the next 4 to 6 weeks and do not draw conclusions from 48 hours of data.
An honest note: a move always has a reordering cost; the goal is not losing URLs or signals to your own mistakes. If traffic drops, the diagnosis is in search traffic drop.
Checklist: how to decide in 10 minutes
- Same topic and business as the domain: subdirectory.
- Another stack, server or deployment: subdomain.
- Multi-language or multi-region: country subdirectory; if the infrastructure requires separate servers, a subdomain plus hreflang.
- Measuring everything together: Domain property, with a per-host filter if you want detail.
- Your own favicon or site name: only with your own hostname.
- Different crawling rules: your own robots.txt per host.
- Third-party content: review the site reputation policy before hosting it.
- Cost of rolling back: write the redirect plan before you start.
- Verify the property in Search Console on day one.
- Document the decision, the date and the metric behind it.
No URL format gets rewarded by Google: there is a business decision with measurable technical consequences. A subdirectory gives you simplicity, joint measurement and cheap migrations; a subdomain gives you independent infrastructure and per-hostname features, in exchange for configuration and data that stop being automatic.
Choose with the checklist, write the migration plan, and do not ask the hostname to do what only better content can do. If the URL format itself interests you, the detail is in SEO-friendly URLs.