What Google says
Google's SEO starter guide has a short section on exactly this question. From a business point of view, it says, do whatever makes sense for your business. It adds that a site segmented by subdirectories may be easier to manage, and that other times it can make sense to split topics into subdomains, depending on the site's topic or industry. The guide names no ranking advantage for either one.
The same guide does give one structural tip for larger sites. If you have more than a few thousand URLs, grouping similar topics in directories can help Google learn how often the URLs in each directory change. A news site with /sports/ and /archive/ folders makes it easy to see that one changes daily and the other almost never.
The two shapes
A subdirectory is part of the path: example.com/blog/. It sits on the same host as the rest of the site. A subdomain is a different host name: blog.example.com. It gets its own DNS record, so it can point to a different server, a hosted blog platform or a shop system run by another company. That is often the real reason for a subdomain: the software behind it lives somewhere else. The guide to domains, DNS and hosting explains how a name finds its server.
Where the difference is real
Most of the practical differences come from one rule: many systems treat a host name as the unit. Here is what changes when the blog moves from the main host to its own subdomain:
| Area | blog.example.com | example.com/blog/ |
|---|---|---|
| robots.txt | Needs its own file at blog.example.com/robots.txt | Covered by the one file at example.com/robots.txt |
| Sitemap | Own sitemap, or cross-submitted after verifying both | Root sitemap can list it |
| Search Console | In a Domain property; not in a URL-prefix property for example.com | In both property types |
| Site name in Google | Can have its own | Shares the name of the domain |
| Server | Can point to a different server | Same host as the main site |
| Browser origin | Different origin, so cross-site calls need CORS | Same origin as the main site |
| Cookies | Only if set with Domain=example.com | Same host, same cookies |
robots.txt. Google says the rules in a robots.txt file apply only to the host, protocol and port where the file is served. A file at www.example.com does not cover example.com or any other subdomain. A robots.txt inside a subfolder does nothing, because crawlers do not look for one there. So a subdomain needs its own file. The robots.txt generator writes one, and the guide on robots.txt, noindex and canonical explains what each rule does.
Sitemaps. Google says a sitemap posted at the site root can affect all files on the site, and recommends that spot. One sitemap may list URLs from other hosts too, if you have verified ownership of all of them in Search Console, or if each host's robots.txt points to the sitemap. Each file holds at most 50,000 URLs or 50 MB uncompressed. The XML sitemap generator builds the file.
Search Console. A Domain property aggregates all subdomains, protocols and paths, and is verified with a DNS record. A URL-prefix property for https://example.com/ includes only URLs that start with that prefix, so blog.example.com is not in it. If you use subdomains, a Domain property shows everything in one place.
Site name. Google shows one site name per site in results, and defines a site by its domain or subdomain. It does not support site names at the subdirectory level. A blog in /blog/ appears under the main site's name; a blog on a subdomain can have its own.
Browser rules. MDN defines the same origin as the same protocol, port and host, and lists news.company.com against store.company.com as a failure because the hosts differ. JavaScript on the main site that calls an API on a subdomain therefore needs CORS headers, as the guide on CORS shows. Cookies follow a similar line. A cookie set without a Domain attribute is host-only. To share a login between example.com and blog.example.com, the cookie needs Domain=example.com, which then reaches every subdomain. The guide to first-party and third-party cookies covers the attributes.
Subdomains and subdirectories for other countries
The question comes up most often for international sites. Google's documentation on multi-regional sites compares four URL structures:
| Structure | Example | Pros (Google) | Cons (Google) |
|---|---|---|---|
| Country domain | example.de | Clear geotargeting, server location irrelevant | Expensive, more infrastructure, one country only |
| Subdomain | de.example.com | Easy to set up, different server locations possible | Users may not know if "de" means language or country |
| Subdirectory | example.com/de/ | Easy to set up, low maintenance (same host) | Single server location, harder to separate |
| URL parameter | example.com?loc=de | None listed | Not recommended by Google |
The server location point matters less than it once did. Google lists the server's IP location as one signal for the intended audience, but calls it not a definitive one. It also advises against adapting content by the visitor's IP address, and notes that Googlebot usually crawls from the USA without an Accept-Language header, so it may never see versions shown only to visitors from elsewhere.
Whichever structure you choose, label the versions. Google uses hreflang annotations, in tags, HTTP headers or sitemaps, to send searchers to the right language version. The hreflang tag generator writes the set of tags for each page.
A worked example
A small software company runs its marketing site on a static host at example.com. It wants a blog, a help center and a German version.
- Blog: written in the same site generator, so
example.com/blog/is the simplest choice. One robots.txt, one sitemap, one site name. - Help center: runs on a hosted support tool that only works on its own host. That decides it:
help.example.com, with its own robots.txt and a Domain property in Search Console to see both hosts together. - German version: same content team, same server, so
example.com/de/with hreflang tags linking each English page to its German twin.
None of these choices is about ranking. Each one follows where the software runs and who maintains it, which is what Google's advice points to.
Changing your mind later
Moving content from a subdomain into a subdirectory, or the other way, changes every URL in that section. Treat it as a site move: map each old URL to its new one, redirect them with a permanent 301, update internal links, canonical tags and the sitemap, and keep the redirects. The guide on moving a website to a new domain walks through the same steps, and the HTTP status codes guide explains 301 against 308.
How to choose
- Does the section run on different software or a different server? Then a subdomain is usually the only option.
- Same software, same team? A subdirectory keeps one robots.txt, one sitemap and one site name.
- Need to share a login? Plan the cookie
Domainattribute and CORS before you split hosts. - Going international? Pick subdirectories or subdomains by maintenance, then add hreflang.
- Using subdomains? Set up a Domain property in Search Console and a robots.txt on each host.
Frequently asked questions
Is a subdirectory better for SEO than a subdomain?
Google does not say so. Its SEO starter guide says to do whatever makes sense for your business, notes that subdirectories can be easier to manage, and says subdomains can make sense depending on the topic or industry. The practical differences are in setup: robots.txt, sitemaps, Search Console and the site name.
Does Google treat a subdomain as a separate site?
For several features, yes. A robots.txt file applies only to the host it sits on, a URL-prefix property in Search Console excludes other subdomains, and Google defines a site for site names by its domain or subdomain. A Domain property in Search Console, verified through DNS, groups all subdomains together.
Which is better for an international site?
Google lists both as easy to set up. Subdirectories are low maintenance because everything stays on one host. Subdomains allow different server locations and an easier separation of the versions. In both cases, hreflang annotations tell Google which page is the version for which language or region.
Do I need a separate robots.txt for a subdomain?
Yes. Google says the rules in a robots.txt file apply only to the host, protocol and port where it is served, so blog.example.com is not covered by example.com/robots.txt. A robots.txt placed inside a subdirectory has no effect at all, because crawlers only look at the top level.
What happens if I move my blog from a subdomain to a subdirectory?
Every blog URL changes, so it is a site move. Redirect each old URL to its new address with a permanent redirect, update internal links and the sitemap, and keep the redirects in place. The steps are the same as for a move to a new domain.
Sources
- Google Search Central: SEO starter guide (do whatever makes sense for your business; subdirectories easier to manage, subdomains depending on topic or industry; grouping similar pages in directories for sites with more than a few thousand URLs)
- Google Search Central: Managing multi-regional and multilingual sites (the table of country domains, subdomains, subdirectories and URL parameters with pros and cons; server location is a signal but not definitive; hreflang)
- Google Search Central: How Google interprets the robots.txt specification (rules apply only to the host, protocol and port; not valid for other subdomains; files in subdirectories are not checked)
- Google Search Central: Build and submit a sitemap (a sitemap at the root can affect all files; cross-site submission after verifying ownership; 50 MB or 50,000 URLs per sitemap)
- Search Console Help: Add a website property (a Domain property covers all subdomains and protocols and is verified through DNS; a URL-prefix property covers only URLs that begin with the prefix)
- Google Search Central: Site names (one site name per domain or subdomain; not supported at the subdirectory level)
- MDN Web Docs: Same-origin policy (same origin means the same protocol, port and host; news.company.com and store.company.com differ by host)
- MDN Web Docs: Set-Cookie (Domain makes a cookie available to the domain and all its subdomains; without it the cookie is host-only)