Subdomain vs Subdirectory: How to Structure a SaaS Website

A subdomain is a different host name (docs.example.com); a subdirectory is a path on the host you already have (example.com/docs). Google has said for years that both can work, which is true and almost useless when you are deciding where the docs go next sprint. This guide is for the founding engineer, technical co-founder, or growth lead at a software company serving one market across several surfaces: a marketing site, a blog, docs, a help center, an app, and a status page. It covers what genuinely differs between the two structures, where each of those surfaces belongs, how to serve a vendor's subdomain at a path when the vendor gives you no choice, and whether consolidating is worth it if you already picked.

The short version

• The useful fact is not that subdomains rank worse. It is that a host is a documented administrative boundary for robots.txt, Search Console properties, and sitemaps, so a subdomain is a separate unit whether or not it is a separate ranking one.
• Default to a subdirectory for any surface you want to rank, and pick a subdomain for a reason other than SEO.
• The reason most teams end up on a subdomain is a vendor constraint, and a reverse proxy usually removes it.
• Some surfaces belong on a subdomain and out of the index entirely. The app is the first of them.
• If you already chose a subdomain, migrating is usually worth it for the blog and docs, and usually not for anything else.

What is the actual difference between a subdomain and a subdirectory?

One is a separate host, the other is a path on the same host. docs.example.com resolves through its own DNS record and can point at a completely different server, run a different stack, and be operated by a different vendor. example.com/docs resolves through the same record as your homepage and is served by whatever answers for that host.

Everything else follows from that. A host is the unit crawl directives, verification, and sitemaps attach to, so a subdomain quietly creates a second thing to configure and remember.

What a host boundary changes	Subdomain (docs.example.com)	Subdirectory (example.com/docs)
robots.txt	Its own file, governing only that host	Covered by the main site's file
Search Console	Included only by a domain property, not a URL-prefix one	Included automatically
Sitemaps	Needs its own, or cross-host submission	Listed in the site's existing sitemap
Hosting and DNS	Can point anywhere, independently of the main site	Tied to whatever serves the main host
Failure domain	Can stay up when the main site is down	Goes down with the main site

Google's robots.txt documentation states the first row plainly: the rules apply only to the host, protocol, and port where the file is hosted, so a robots.txt on a subdomain is valid for that subdomain alone. None of that is a ranking penalty. It is administrative surface area, and administrative surface area is where the real cost of a subdomain shows up.

What does Google actually say, and what do practitioners find?

They say different things, and keeping them apart is the only honest way to answer this question. Google documents that both structures are workable. Practitioners overwhelmingly prefer subdirectories. Neither of those is a measured ranking difference.

What is documented: the closest thing to a direct comparison in Google's own material sits inside its guidance on multi-regional URL structures, which lists both a subdomain and a subdirectory on a generic domain as valid options. It gives the subdirectory low maintenance on a single host as an advantage, and gives the subdomain easier separation of sites and flexible server locations as advantages of its own. That is a fair statement of the trade. It is not a ranking claim, and it should not be quoted as one.

What is consensus: the widely held practitioner position is that a single host accumulates authority more effectively, so content that lives at a path benefits from everything the rest of the host has earned. The argument is mechanically reasonable, and it is the same argument that makes how link equity flows through a site worth designing on purpose. Cloudflare's engineering team makes the concentration case explicitly in its write-up on subdomains versus subdirectories with Workers.

What nobody has is a clean controlled study. Isolating host structure from the dozens of things that change during a migration is close to impossible in the field, and I would treat any single-site before-and-after chart as an anecdote rather than evidence. We have not measured a ranking difference between the two structures either, and this article does not claim one.

So the practical rule is not "subdomains are bad." It is this: subdirectories are the lower-risk default, and a subdomain should be chosen for a concrete operational reason you can state out loud.

Where should each part of a SaaS site live?

Six surfaces cover almost every software company, and five of the six have a clear answer. Here is the placement I would specify before a build starts.

Surface	Where it belongs	Why
Marketing site	Root domain, indexed	The host every other surface should be reinforcing. Everything below is judged against whether it strengthens or splits this.
Blog	Subdirectory /blog, indexed	Its entire job is to earn queries that lead to the product. Putting it on another host means doing that work for a host you are not selling from.
Docs	Subdirectory /docs, indexed	Documentation attracts the highest-intent queries a technical product gets. Credit them to your primary host, and proxy the vendor if it insists on a subdomain.
Help center	Subdirectory /help, indexed selectively	Same argument as docs, weaker. Noindex the thin ticket-deflection tail rather than the whole section, and accept a subdomain here if proxying the vendor's interactive UI is fragile.
App	Subdomain app., not indexed	Different stack, different auth, nothing that answers a search query. The value is separation, and the correct index state is out.
Status page	Subdomain status. on separate infrastructure	It exists to be reachable when your main site is not. Putting it behind your own edge defeats the only reason you have one.

Two questions produce every row in that table, and they are worth asking directly rather than reasoning by analogy each time.

Does it need to rank?	Can it share a failure domain with the marketing site?	Placement
Yes	Yes	Subdirectory, indexed. Blog, docs, most help centers.
Yes	No	Subdomain, or a path served by proxy if you accept the coupling. Decide which risk you prefer.
No	Yes	Either. Use a path for simplicity and noindex it. Not worth an argument.
No	No	Subdomain, out of the index. App, status page, internal tools.

The framework matters more than those row-by-row answers, because your product may have surfaces this list does not: a community forum, a public template gallery, a customer-facing API console. Run each one through the same two questions and the placement falls out.

Should your app subdomain be indexed at all?

Usually not, and the default in most stacks is that nobody ever decided. The app went up on app.example.com, nothing was configured, and Googlebot has been quietly crawling it ever since.

Here is what that produces mechanically. A client-rendered application serves broadly the same HTML shell at every route before authentication runs, so a crawler that follows links into the app collects a set of URLs whose visible content is a loading state or a login prompt. Those pages are thin by construction, near-duplicate by construction, and cannot satisfy any query. They consume crawl requests that would otherwise land on pages you want reprocessed. Occasionally one of them surfaces for a brand query and gives a searcher a login screen where a product page should have been.

What to do about it: decide deliberately, and write the decision down. If nothing on app. should rank, serve Disallow: / from that host's own robots.txt, remembering that the file governs only that host and that the app team may not know it exists.

The trap in that instruction: a robots.txt disallow does not remove URLs Google has already indexed, because Google cannot see a noindex on a page it is not allowed to crawl. If app URLs are already in the index, allow crawling and serve noindex until they drop out, and only then disallow. Doing both at once is the most common way this fix fails.

When not to noindex the app: when part of it is genuinely public. Shared dashboards, public profiles, published workspaces, and template galleries are real content that can earn real queries. If you have one of those, that is usually a signal it should live at a path on the marketing host rather than inside the authenticated app, where it will always be an awkward exception.

What if your docs or help center vendor only supports a subdomain?

Proxy it. You can serve a vendor-hosted subdomain at a path on your own host, so that readers and crawlers both see example.com/docs while the vendor keeps serving the content. This is the single most useful thing to know about this decision, and it is the option most teams never evaluate.

In projects I've worked on, the vendor constraint is what pushes teams onto a subdomain in the first place, and a rewrite usually removes it before it hardens into a permanent architecture choice.

The mechanism is a reverse proxy at your edge. A request for /docs/anything hits your infrastructure, your infrastructure fetches the corresponding page from the vendor's host, and the response is returned under your domain.

• Next.js: a rewrite in next.config.js maps a source of /docs/:path* to a destination of https://acme.vendorhost.com/:path*. The Next.js documentation on rewrites to an external URL covers the syntax and the ordering rules, which matter once you have more than one.
• CDN worker or edge function: a Cloudflare Worker, Vercel or Netlify edge function, or plain nginx proxy_pass does the same job without a framework involved. Useful when your marketing site is not the thing doing the routing.

Now the honest part, because a proxy moves problems rather than deleting them.

• You own the path now: a vendor outage becomes an outage of example.com/docs, and your edge becomes a dependency of documentation you do not host.
• Canonicals and metadata: if the upstream emits a canonical tag pointing at its own host, you have proxied the page and handed the credit straight back. Check the canonical, the Open Graph tags, and the sitemap, and confirm the vendor lets you override all three before you commit.
• Internal links and assets: absolute URLs in the vendor's navigation, search widget, and asset references often still point at the subdomain, which sends users back out of your host mid-session.
• Caching: you now decide the cache policy at the edge. Too aggressive and you serve stale docs after a release; too loose and every request becomes an origin fetch against a vendor that never expected the traffic.
• Latency: one extra hop, usually small, but it stacks on top of the vendor's own response time and you cannot optimize their half.
• Terms of service: some vendors prohibit proxying or reject unexpected Host headers. Read the contract before you write the rewrite.

My rule is to proxy static documentation happily, think hard before proxying an interactive help center with ticket forms and chat, and never proxy a status page. The more stateful the surface, the more the proxy costs you and the less ranking upside there is to gain.

How do you move a subdomain to a subdirectory without losing rankings?

You treat it as a site migration, and you only run one where the upside justifies the risk. This is the question the incumbent guides abandon: they resolve the choice and leave the reader who already chose with nothing.

Worth doing: the blog and the docs. Both exist to earn organic queries, both are mostly static, and both usually map one-to-one onto new paths, which is the cheapest kind of redirect plan there is.

Usually not worth doing: the app, because nothing on it should rank and noindexing it in place achieves the goal for free. The status page, because moving it destroys the isolation it exists for. A help center welded to a vendor's interactive UI, where a proxy is the better answer anyway. And any subdomain that ranks for nothing today, because moving pages that earn no traffic earns no traffic.

The precondition that decides it: can the old host serve permanent redirects? Some hosted platforms cannot issue a 301 at all. If yours cannot, you are not migrating those URLs, you are abandoning them, and the answer is to stay put or change vendors first.

Expect a period of instability while Google reprocesses the moved URLs, and do not read the second week as the verdict. The full redirect map, the phasing, and the verification steps belong to a migration process rather than this decision, so work through the migration checklist before you touch DNS.

What does this do to your reporting?

It splits it, unless you configure both tools deliberately. This is the cost of a subdomain that teams discover last, usually while trying to explain a traffic number to someone.

Search Console: a domain property covers every subdomain of the domain; a URL-prefix property covers exactly the prefix you entered and nothing beneath a different host. If you run subdomains, a domain property is the one that shows you the whole picture, and you can add URL-prefix properties per host when you want them reported separately. Our guide to Search Console property types covers the setup and verification differences.

Analytics: subdomains of the same registrable domain usually stitch together without extra work, because the measurement cookie is set at the top-level domain by default. The break happens for a different reason: the app team ships its own analytics property, so your marketing site and your product report into two places and nobody can follow a user across the join.

Sitemaps and crawl controls: each host needs its own robots.txt and its own sitemap, or explicit cross-host submission. A sitemap listing URLs on a host it does not live on is the kind of thing that silently does nothing for months.

When is a subdomain the right answer?

More often than the "always use a subdirectory" advice admits. The rule is a default, not a law, and there are five cases where the subdomain is simply correct.

• Failure isolation: the status page, and anything else whose job is to work when your main infrastructure does not. Different host, different provider, ideally a different DNS zone.
• A stack you will never merge: coupling a Rails application and a Next.js marketing site behind one edge purely to gain a path is a large amount of complexity for zero ranking benefit, since nothing in the app should rank anyway.
• Genuinely separate audiences: a careers site, an investor page under a holding brand, a partner portal. Content that is not trying to build the same authority does not benefit from sharing a host.
• Tenancy and compliance boundaries: per-customer subdomains, region-locked instances, and environments with their own regulatory scope. These are not marketing decisions.
• Reputation you want quarantined: user-generated content at scale. If you would not want it judged as part of your main site, separate it properly and accept that it builds its own standing.

One case that looks like this but is not: multiple countries or languages. That decision has its own rules around hreflang, country targeting, and ccTLDs, and our guide to multi-region URL structure is where it belongs.

What should you check on the hosts you already have?

Most teams reading this have already made the decision several times without noticing. Before changing anything, find out what you actually run.

Inventory: list every host that answers for your product, including the ones support, sales, or a growth experiment stood up without telling engineering. Certificate transparency logs and your DNS zone are faster than asking around.

Index verdict: for each host, decide indexed or not indexed, and record the decision somewhere durable. A host with no verdict is a host that will surprise you.

robots.txt: confirm each host serves its own file and that the file says what you meant it to say. Fetch them, do not assume them.

Canonicals on proxied paths: if you already proxy a vendor surface, view source on a real page and confirm the canonical points at your host.

Search Console coverage: confirm the property type actually includes the hosts you think you are measuring.

Redirect capability: for any subdomain you might consolidate later, check today whether the vendor can serve permanent redirects. Finding out afterwards is the expensive version of this question.

The habit worth building is treating host placement as part of the build spec, alongside routing and rendering, rather than a decision made the week a new surface goes live. Every surface added later inherits whatever the vendor's default was, and a default is not a decision. Our guide to a site where SEO is designed in, not patched on after launch puts this in the same document as URL structure and rendering strategy, which is where it belongs.

This week, list every host your product answers on and mark each one indexed or not indexed. If a row makes you hesitate, that is the row to fix first, and if you would rather have the architecture and the build handled together, that is what how we build sites exists to do.