Subdomain vs Subdirectory for SaaS: Where the Blog, Docs and App Should Live

In the subdomain vs subdirectory decision, a B2B SaaS team should put anything meant to earn search traffic in a subdirectory, such as example.com/blog, and keep subdomains for things that behave like separate products, such as app.example.com. That verdict rests less on a ranking rule than on operations. A subdirectory shares one host with your marketing site, so crawling rules, reporting, performance data and redirects all live in one place. A subdomain gives you a second site to run.

The ranking question itself is murkier than most articles admit. Google's URL structure documentation gives advice on readable words and logical organization but doesn't state a preference between the two. Many practitioners believe subdirectories consolidate authority better. That belief may well be right, yet it isn't something Google documents, so treat it as a reasonable bet and not as settled fact.

What actually differs between the two

A subdomain sits before your root domain, as in docs.example.com. A subdirectory sits after it, as in example.com/docs. To a visitor they look similar. To the systems reading your site, the hostname is a meaningful boundary, and several documented behaviors follow from it.

Google's crawl budget guide defines a site as a unique hostname, and says www.example.com and code.example.com get separate crawl budgets. Robots.txt rules apply only to the host where the file sits, so every subdomain needs its own file. Site names in results work at the domain or subdomain level and aren't supported for subdirectories. The Core Web Vitals report falls back to an origin group defined by protocol, host and port, so a thin subdomain doesn't inherit your main site's field data.

None of those behaviors makes a subdomain bad. Together they explain why it costs more to run.

Where each part of a SaaS site belongs

Say you run a 25-person SaaS selling procurement software to mid-market finance teams. Your marketing site is on one platform, the blog was started on another, docs live in a developer tool, and the product runs separately. Here is a sensible default for that stack.

Property	Default home	Why
Blog	Subdirectory	Built to rank, and it should link tightly to product pages
Feature, pricing and use-case pages	Subdirectory	Your main commercial surface
Docs and help center	Subdirectory if your stack allows it	Often rank for valuable long-tail questions
Customer-facing app	Subdomain	Different stack and security needs, with no reason to rank
Status page	Subdomain	Should stay up when your main site is down
Developer API	Subdomain	A service, not content

Docs are the honest debate in that table. Plenty of good SaaS companies run docs.example.com because their docs tool expects it, and moving is real work. If your docs mostly serve existing customers, leave them alone. If they target buyer questions and your docs are part of your search plan, a subdirectory earns its setup cost.

When a subdomain is the right call

Three situations justify one. The first is a genuine technical separation: the app, an API, or anything where isolating cookies and deployments protects you. A security review may ask for that separation, and search shouldn't override it.

The second is a separate audience or brand. A community forum with its own moderation and its own identity can reasonably stand apart, and the site name support mentioned above works in your favor there.

The third is a platform that can't be proxied. If a tool only publishes to its own hostname and the content isn't central to acquisition, accept the subdomain. Spending a sprint on infrastructure for a low-stakes help center is poor use of a small team.

How to get a subdirectory when your tools disagree

Most SaaS stacks end up here: the blog platform differs from the marketing site, yet you want everything under one host. A reverse proxy solves it. Your CDN or edge layer receives requests for /blog/*, fetches them from the blog platform, and serves them under your main domain.

The setup deserves a proper test before launch. Canonical tags must point to the public example.com/blog URLs and not the platform's hostname. Internal links, images and sitemap entries must use the public address too. The platform's original hostname should stop being crawlable as a duplicate, either through redirects or the right noindex handling. A proxy that works in a browser and leaks the wrong canonical can leave you with two competing copies of each post, which canonical URL issues on SaaS sites covers in more depth.

For the procurement company above, the likely plan is simple: proxy the blog to /blog, leave docs where they are for now, and revisit docs once the blog is producing pipeline.

Moving an existing subdomain without damage

A move from blog.example.com to example.com/blog is a site move, even though it feels small. Map every old URL to its new one, add permanent redirects, and update internal links so they don't pass through redirects. Google's site move guidance says to keep redirects as long as possible, generally at least a year.

Be honest about expected payoff before you commit. Traffic may dip while Google processes the change, and no one can promise a lift afterward, because the authority argument is unconfirmed. The stronger case is usually the operational one: one analytics setup, one set of navigation, cleaner internal linking, and fewer places for configuration to drift. If your subdomain is performing and your team is busy, moving it may rank below publishing better pages. Our migration checklist for SaaS sites covers the sequence if you do go ahead.

What changes for AI search

AI crawlers add one more reason to count your hostnames. OpenAI's crawler documentation lists separate bots for search, training and user-triggered visits, with each setting independent of the others. A team that carefully configures example.com/robots.txt can forget that docs.example.com has its own file, or none, and end up with inconsistent access across the content most likely to answer product questions.

Check every public hostname against your decision on blocking AI crawlers rather than only the main one. As for whether AI answers prefer subdirectories, no primary source that could be checked says so. Answer engines retrieve pages, and clear content on a crawlable host is the part you control. Be skeptical of anyone claiming a citation advantage for either structure.

A quick way to decide

Ask three questions of any new property. Should this rank and support buying decisions? Can our stack serve it under the main host at a reasonable cost? Does security or independence require separation? A yes, yes and no points to a subdirectory. A no on the first question, or a yes on the third, points to a subdomain. Then write the decision down in your site architecture notes, because the same debate tends to return with every new tool.

If you want a second opinion on how your blog, docs and app are split, talk to Comppound about your site structure.