Subdomain vs Subdirectory: What Actually Differs (SEO Included)

blog.example.com or example.com/blog/? The short answer: search engines can crawl, index and rank both, and Google's representatives have said for years that you should pick the structure that fits your setup. The differences that are certain, and that will cost or save you work, are technical: a subdomain is a separate DNS name, a separate browser origin and a separate host for crawlers, while a subdirectory is just a path on a host that already exists. This guide walks through those mechanics and ends with a decision table. It makes no claim that one form ranks better, because nobody outside the search engines can source such a claim.

What each one is

A subdomain is a name below your domain: blog.example.com, shop.example.com, status.example.com. It exists because a DNS record for that name exists. It can point anywhere: the same server as the main site, another data centre, or a SaaS platform on the other side of the world.

A subdirectory (subfolder) is a path: example.com/blog/. DNS knows nothing about it. The browser resolves example.com, connects to whatever answers, and asks that server for /blog/. Everything behind that path must be delivered by the host that serves example.com, or by something that host forwards to.

$ dig +short blog.example.com
blog-example.hosted-platform.example.
203.0.113.20

$ curl -sI https://example.com/blog/ | head -n 1
HTTP/2 200

The first command shows a subdomain handed to an external platform through a CNAME. The second shows a path answered by the main site's own server.

DNS and hosting

Subdomain. One record, and the content lives wherever you like. A CNAME to a hosted blog, shop or documentation platform takes a minute to set up, has its own TTL, and can be moved later without touching the main site. The apex domain cannot be a CNAME, but a subdomain can, which is why SaaS products almost always ask you for one.

The price is inventory. Every subdomain is a DNS entry somebody must remember. When the platform subscription is cancelled and the CNAME stays, you have a dangling record, which is the starting point of a subdomain takeover. Wildcards change the picture again: see wildcard DNS records.

Subdirectory. No DNS work at all, as long as the same application serves the path. If the blog runs on a different platform than the main site, you need a reverse proxy or CDN rule that routes /blog/* to the other backend. That works, but it is an operational dependency: the proxy must pass the right Host header, rewrite redirects and absolute URLs, handle caching for two applications with different rules, and it becomes a single point of failure for both. Many hosted platforms do not support being served under a path at all.

TLS certificates

A certificate is valid for the host names listed in it. A subdirectory needs nothing new: example.com/blog/ is covered by the certificate for example.com.

A subdomain must appear in a certificate, either by name as a Subject Alternative Name or through a wildcard *.example.com. A wildcard covers one label only: it matches blog.example.com, not eu.blog.example.com. Hosted platforms usually issue the certificate for your subdomain themselves once the CNAME is in place; if you restrict issuers with CAA records, the platform's certificate authority has to be allowed.

The browser: origin, cookies, HSTS

This is where the two options differ most, and where the security argument lives.

Same-origin policy. An origin is scheme + host + port. https://example.com and https://blog.example.com are different origins. They do not share localStorage, IndexedDB or service workers, and JavaScript on one cannot read responses from the other unless the server sends CORS headers. https://example.com/blog/ and https://example.com/app/ are the same origin: scripts under one path have full access to everything the other path stores.

Cookies. A cookie set without a Domain attribute is host-only: it is sent to the host that set it and nowhere else. A cookie set with Domain=example.com is sent to example.com and every subdomain. So sharing a login between the site and a subdomain is possible, but it is a deliberate choice, and it means every subdomain, including the forgotten ones, receives that cookie. Within one host, all paths share cookies; the Path attribute is not a security boundary.

Isolation. The consequence: content you do not fully control should not live on the origin that holds your sessions. User-generated pages, a third-party help desk or a marketing tool running under example.com/… executes with the same origin privileges as your application. On a subdomain it does not (as long as your session cookies are host-only). Platforms that host customer content go one step further and use a separate registrable domain, often listed in the Public Suffix List, so that customers' sites cannot set cookies for each other.

HSTS. A Strict-Transport-Security header applies to the host that sent it. Subdomains are covered only when the apex sends includeSubDomains; otherwise each subdomain needs its own header. Going the other way, turning on includeSubDomains forces HTTPS on every subdomain you have, including internal or legacy ones. Details in the HSTS glossary entry.

What crawlers and Search Console treat separately

Without any statement about rankings, these host-level facts hold:

• robots.txt is per host. https://blog.example.com/robots.txt governs the subdomain; the file on example.com does not apply to it. A subdirectory is governed by the main site's single file.
• Sitemaps are per host in practice: list the subdomain's URLs in a sitemap served from, or referenced by, that subdomain.
• Search Console properties. A URL-prefix property covers one host. A Domain property (verified by a DNS TXT record) covers the apex and all subdomains together. A subdirectory is always inside the main site's property.
• Crawl behaviour is managed per host name. A slow or failing subdomain platform is a separate matter from the main site's server; a slow path under one host is not.
• Analytics. Across subdomains, check that your analytics cookie is scoped to the parent domain and that referral exclusions are set, or sessions split in two when a visitor moves between hosts.

$ curl -s https://blog.example.com/robots.txt
User-agent: *
Disallow: /drafts/
Sitemap: https://blog.example.com/sitemap.xml

A classic accident: the staging robots.txt with Disallow: / goes live on the new subdomain and nobody notices, because everybody checks the main site's file.

Decision table

Use case	Usually fits	Reason
Blog on the same CMS as the site	Subdirectory	No extra DNS, certificate or origin; one robots.txt and one property
Blog on a hosted platform	Subdomain	One CNAME; a path needs a reverse proxy you must run and monitor
Shop on a SaaS platform	Subdomain	Platforms expect a custom host name; keeps checkout scripts off the main origin
Documentation	Either	Same build pipeline: path. Separate docs platform: subdomain
Web application (app.)	Subdomain	Separate origin isolates sessions from marketing pages and their third-party scripts
Country or language versions	Either (or ccTLDs)	Paths are simpler to run; subdomains allow separate hosting per region. Use hreflang in both cases
User-generated sites or uploads	Separate domain	Origin and cookie isolation
Status page	Subdomain on separate infrastructure	It must stay up when the main site, its CDN or its DNS provider is down; consider separate DNS as well

Moving from one to the other

A move between blog.example.com and example.com/blog/ is a site migration, even if the content is identical:

1. Map every old URL to its new URL. Redirect each one with a 301, one to one, not everything to the new home page.
2. Update canonical tags, hreflang annotations, internal links and sitemaps to the new URLs.
3. When leaving a subdomain, keep its DNS record and certificate alive, because the redirects are served from that host.
4. Verify the new location in Search Console and submit the new sitemap.
5. Expect a transition period in which old and new URLs both appear in search results and traffic fluctuates.
6. Keep the redirects for the long term. Links from other sites keep pointing at the old URLs for years.

If you are also deciding on the host name of the main site, read www vs non-www first: that choice determines cookie scope and the CNAME options for everything else.

Common mistakes

• Choosing the structure because of a ranking rumour and then paying for a reverse proxy nobody on the team can maintain.
• Setting session cookies with Domain=example.com "to be safe", which hands them to every subdomain, including ones run by third parties.
• Putting a third-party tool under a path of the application's origin.
• Forgetting the subdomain's own robots.txt, sitemap and Search Console coverage.
• Enabling includeSubDomains without an inventory of subdomains that still speak plain HTTP.
• Deleting the old subdomain record straight after a migration, which kills the redirects.
• Cancelling a hosted platform and leaving its CNAME in the zone.

Check it with OrbitProbe

The OrbitProbe DNS lookup shows what a subdomain actually points to: the CNAME chain, the A and AAAA records behind it and the TTLs, queried live. Run it for each host name you operate to see which ones lead to external platforms, and again after a migration to confirm the old name still resolves so its redirects keep working. A path such as /blog/ has no DNS of its own; for it, the record that matters is the one for the host in front of it.