Subdomain vs subfolder: four things that split the moment you pick the subdomain

Subdomain vs subfolder is a hosting decision with four documented consequences for search, and none of them is a ranking claim. A subdomain is a separate hostname, and Google's crawler, robots.txt, Search Console properties and sitemaps all draw their boundaries at the hostname. A subfolder inherits every one of those from the site it sits in. Pick the subfolder unless one of the four splits is something you want.

What you need before this chapter

You need to know what the section is for and who will run it, and you need the rules for writing the address once the host is decided — those are in URL structure for SEO. This chapter only settles the part before the first slash.

What actually differs: subdomain vs subfolder

blog.example.com and example.com/blog/ serve the same content to the same reader. The difference is that the first one is a new host, and a host is the unit almost every crawling rule is scoped to. Google states its own definition plainly in the crawl budget documentation: "In this context, Google's crawling infrastructure defines a site as a unique hostname. For example, https://www.example.com/ and https://code.example.com/ are treated as separate sites and have separate crawl budgets" (Crawl budget management for large sites, read 2026-09-04).

A subfolder inherits. A subdomain starts over.

The four things a subdomain splits

Each row is documented behaviour, not an opinion about authority. Each one is also work you will do again for the second host.

The robots.txt row is the one that surprises people, because the rule is absolute: "A robots.txt on a subdomain is only valid for that subdomain", and more generally "The rules listed in the robots.txt file apply only to the host, protocol, and port number where the robots.txt file is hosted" (robots.txt introduction and guide, read 2026-09-04). A carefully written robots.txt at the apex governs nothing on the subdomain you launched last week. That subdomain either serves its own file or serves none.

The sitemap row is the quietest of the four. A sitemap is checked against the location it is served from, so a file at the apex that lists subdomain URLs is not automatically honoured; Google documents cross-submission as the supported way to do it, and cross-submission is something a person sets up, not something that happens because both hostnames belong to you.

The Search Console row has an escape hatch worth knowing about before you start: a Domain property covers every subdomain at once, which is the reason the property type is worth deciding early. It is covered in Search Console verification.

None of this is about authority moving between hosts, and it is worth being precise about that, because the argument usually gets framed that way. The four rows are plumbing. They describe which file governs what, which allocation applies where, and which dashboard shows you the result.

When a subdomain is the right answer

There are real cases. All of them share a shape: the thing on the other host is genuinely a different system, run by different people, on a different release schedule.

The last row is not a dodge. For international sections Google lists country-specific domains, subdomains and subdirectories side by side with pros and cons rather than a recommendation, and the pros it gives subdirectories are "Easy to set up" and "Low maintenance (same host)" (Managing multi-regional and multilingual sites, read 2026-09-04). The cost it names for subdomains is that separation which, for a single team, is the cost rather than the benefit.

The decision in five questions

Answer them in order and stop at the first yes.

1. Can the content technically live in a path on the existing host? If it cannot — a hosted help desk, a vendor's app — the decision is already made for you.
2. Does it need to be crawled at all? A login screen or a status page does not, and putting it on its own host makes excluding it a one-line job.
3. Will a different team ship it on a different schedule? Separate hosts mean separate deploys without a shared build, which is a real operational win.
4. Is anyone going to own the second robots.txt, sitemap and property? If nobody is, the subdomain will quietly go unmanaged.
5. None of the above? Use the subfolder.

How to check what you already have

Run these against a site you already operate. The third command is the one that finds the mistake nobody looks for.

# Does the subdomain serve its own robots.txt, and is it a different file?
curl -s https://example.com/robots.txt      | head -20
curl -s https://blog.example.com/robots.txt | head -20

# Which hostnames does your sitemap actually list?
curl -s https://example.com/sitemap.xml \
  | grep -oE '<loc>https?://[^/]+' | sed 's|<loc>||' | sort | uniq -c

# Is the subdomain a separate host at the DNS level?
dig +short blog.example.com

A sitemap listing two hostnames is not automatically wrong — Google documents cross-submission, where sitemaps for several sites are hosted in one place and each site's robots.txt points at its own. It is wrong when nobody set that up on purpose, which is most of the time.

Three ways this goes wrong

All three come from treating the second host as if it were still the first one.

1. The subdomain has no robots.txt of its own. Whatever you wrote at the apex does not apply. Check with the first command above, not from memory.
2. Nobody verified the second property. A URL-prefix property on the apex reports nothing about the subdomain, so the section looks like it has no impressions when it simply has no property.
3. The migration was a redirect and nothing else. Moving example.com/blog/ to blog.example.com changes the host for every URL at once. The redirects are the easy half; the internal links, canonical tags and sitemap all point at the old host until someone changes them.

What this chapter will not tell you is which of the two ranks better. No Google documentation states a ranking difference, we have not run a test that isolates one, and any single site that moved and then improved also changed a dozen other things at the same time. The four splits above are documented; the ranking claim is not. If the section is large enough that crawling itself is the constraint, that question is answered separately in is crawl budget your problem. To see what each host actually returns before you commit, see how QueryWin reads a page.

Common questions

Is a subdomain treated as a separate site by Google?

For crawling, yes, and Google says so in those words. That is a statement about hostnames and crawl allocation, not a statement about how pages are scored.

Do subdomains hurt SEO?

Nothing in the documentation says so. What they cost is duplicated setup: another robots.txt, another sitemap, another property, another thing to remember. On small teams that cost is the whole argument.

Should I move an existing subdomain into a subfolder?

Only if the split is causing you a problem you can name. A host migration touches every URL you have, and doing it for a benefit nobody has measured is a large amount of risk bought with a guess.

Which one should I use for a different language?

Google documents both as workable and lists the trade-offs instead of picking. The subdirectory is the lower-maintenance option; the subdomain is the one that lets a different team and a different server handle it.

Does www count as a subdomain?

Technically yes, which is why example.com and www.example.com are different hosts with different robots.txt scopes. Serve one and redirect the other, and make sure your Search Console property matches the one you serve.