Subdomain vs Subdirectory SEO: The SaaS Blog Decision
Subdomain vs subdirectory SEO for a SaaS blog: what Google actually says, and why deployment, analytics, navigation and migration cost should decide it.
TL;DR Google's documentation and John Mueller both say Search is fine with a blog on a subdomain or in a subdirectory, so do not pick one hoping for a ranking boost. Pick the setup your team can deploy, measure, and link from the product site without friction. For most small SaaS sites starting from zero, that ends up being a subdirectory. If you already have an established subdomain blog, leave it where it is unless something operational is broken.
Picture a founder with a Next.js marketing site on the root domain, the app on app. and a half-finished Ghost install he wants to put on blog.. Ghost on a subdomain takes him twenty minutes. Serving the same blog under /blog means a reverse proxy, a rewrite rule he does not fully understand, and probably a lost weekend. Then someone on X tells him that subdomains "don't inherit authority" and that putting the blog there will waste every post he writes.
So he freezes, which costs him more than either option would. Three weeks go by and he publishes nothing.
The subdomain vs subdirectory SEO debate gets argued as if it were only about ranking. For a small SaaS blog it is mostly an operations question: who deploys the blog, where the analytics live, whether the blog links to the product, and how expensive it is to change your mind later. Answer those and the SEO side mostly takes care of itself.
What Google says about subdomain vs subdirectory SEO
Google's own documentation is short and unusually direct. In the SEO Starter Guide, the topic sits in a section titled "Things we believe you shouldn't focus on." The guidance reads: "From a business point of view, do whatever makes sense for your business. For example, it might be easier to manage the site if it's segmented by subdirectories, but other times it might make sense to partition topics into subdomains, depending on your site's topic or industry."
John Mueller covered the same ground in a Google Webmasters video on subdomains and subdirectories: "Google Web Search is fine with using either subdomains or subdirectories." He added one practical difference. A subdirectory helps with crawling because Google can see that everything sits on the same server. With a subdomain, Google has to learn how to crawl it separately, which he described as mostly "a formality for the first few days."
That is the whole official position on subdomain vs subdirectory SEO: no ranking penalty for subdomains, no bonus for subdirectories, and a short learning period when Google meets a new host.
Here is where I part ways with both camps. The "subdirectory always wins" crowd usually points to case studies where a company moved its blog and traffic went up. I have not seen one that isolates the move from everything else that tends to change with it: a new template, a rebuilt navigation, fresh internal links into product pages, pruned old posts. The "Google says it doesn't matter" crowd is right about Google's ranking systems but treats that as the end of the discussion, when the operational differences can still change how well a blog performs. A subdomain blog can rank. Moving a blog guarantees nothing. What really moves results is the operational work around the blog, which is why the rest of this post is about that.
Subdomain vs subdirectory pros and cons for a small SaaS
Here are the four questions I ask, with the trade-offs in plain words:
| Question | Subdirectory, like /blog | Subdomain, like blog. |
|---|---|---|
| Who deploys it | Same repo or a proxy in front of the main site | Can live on any CMS or host, deployed on its own |
| Analytics and Search Console | One host, one robots.txt, one set of filters | Needs a domain-level property and a shared cookie domain to stay clean |
| Navigation and internal links | Shares header, footer and components with the product site by default | Gets its own template, which often drifts away from the product site |
| Cost of changing later | Any move is a site move with redirects | Same, and it is the move founders most often consider |
Deployment ownership
This is the question that usually settles it, and nobody asks it out loud. If your marketing site is a framework app you already deploy, and you are happy writing posts as Markdown or MDX in the repo, a subdirectory costs nothing. The blog ships when the site ships. That is how this blog works.
If the person writing posts needs a hosted CMS and your marketing site cannot render it natively, a subdirectory means a reverse proxy: the main domain forwards /blog requests to the CMS host and passes the response back. That works, but now a small piece of infrastructure sits between your readers and your posts. Someone has to own it when canonical tags point at the wrong host or assets load from the CMS domain. A subdomain skips all of that. For a two-person team with nobody who wants to own a proxy, that is a legitimate reason to pick it.
Analytics and Search Console
A subdomain blog gives you a few more settings to get right, and they are all easy to miss.
In Search Console, a Domain property "includes all subdomains" and is verified by DNS record only. A URL-prefix property covers only URLs under that exact prefix. If you set up https://example.com as a URL-prefix property years ago and then launch blog., the blog is not in it. Use a Domain property from the start and the subdomain question disappears from your reports.
In Google Analytics, Google's cross-domain measurement guide warns that when users move "from one subdomain on your site to another subdomain that uses a different cookie domain, self-referrals can appear." The fix it gives is to make sure "all subdomains in a domain are using the same cookie domain." If you skip it, your blog shows up as a referrer to your own signup page and your content attribution is wrong from day one.
Crawling controls are split by host too. Google's robots.txt documentation says rules "apply only to the host, protocol, and port number where the robots.txt file is hosted," so a subdomain blog needs its own file. If you are unsure what belongs in it, I covered that in robots.txt vs noindex for SaaS pages. Sitemaps can be cross-submitted between hosts, but the default is one per site, and my notes on sitemap best practices for a SaaS blog assume you know which host each one lives on.
None of this hurts rankings. It makes your data less trustworthy, and bad data leads to bad decisions about what to write next.
Navigation and internal links
This is where I think subdomain vs subdirectory SEO really diverges for low-authority sites, and it has nothing to do with the hostname itself.
A blog in a subdirectory usually shares the main site's header, footer and components. A blog on a separate CMS usually gets a theme, and themes drift. Six months in, the blog footer still shows the theme's defaults, the header has no link to pricing, and no post links to a feature page because the CMS editor makes that awkward. Google's ranking systems may be indifferent to the subdomain, but they still follow links, and those links are missing.
On a small site, internal links are one of the few signals you fully control. A blog that never links into the product, and a product site that never links back to the blog, is two thin sites instead of one connected one. Whichever setup you choose, wire it into your internal linking strategy for topic clusters from the first post. If the blog already exists, run an internal link audit on your content clusters before you blame the hostname for anything.
Migration effort
Picking a structure is cheap on day one. Changing it later is a site move. Google's guide to site moves with URL changes is clear about the cost: "you may experience ranking fluctuations while Google recrawls and reindexes your site," and for medium-sized sites "it can take a few weeks or more" before the new URLs replace the old ones. It also says to keep redirects "generally at least 1 year."
That cost matters more than any ranking theory. If you are not sure, start with the setup that is cheaper to keep correct.
Subdomain vs subdirectory examples: three small-SaaS scenarios
These are composites of setups I see often, not case studies, so there are no traffic numbers attached.
The solo founder on a framework site. Next.js or Astro marketing site, posts written in MDX, no other writers. Use a subdirectory. It is the default your framework already supports, the blog inherits your navigation, and there is no proxy to maintain. Spend the saved time on the slug and folder decisions in SEO-friendly URL structure for a SaaS blog instead.
The small team on a no-code site plus a hosted CMS. Marketing site on a site builder, a part-time writer who wants a real editor, nobody technical enough to own a reverse proxy. A subdomain is a defensible call here. Use a Domain property in Search Console, share the analytics cookie domain, copy the main navigation into the blog theme, and add product links to every post template. If someone later is willing to own a proxy, revisit it then.
The established subdomain blog. Eighty posts on blog. that already get search traffic, with the original reason for the subdomain long gone. My advice is to leave it. Fix the operational gaps first: navigation, links into the product, analytics referrals. Only move it if you are rebuilding the site anyway, so the redirects and fluctuation happen once instead of twice.
When to use subdomain vs subdirectory: the decision rule
If you want one rule for the blog subdomain vs subdirectory decision: choose the structure where the blog is deployed by the same people, measured in the same property, and linked from the same navigation as the product site. For most early SaaS sites that is a subdirectory, because it is the cheapest way to get all three.
Choose a subdomain when:
- The blog needs a CMS your main site cannot serve, and nobody will own a proxy.
- The content is a genuinely separate product, such as docs for a developer API, a community forum, or a help center run by support. The starter guide's "partition topics into subdomains" line describes this case.
- It already exists, it works, and moving it would mix a site move into a period when you should be publishing.
Choose a subdirectory when:
- Your site is a framework app and the blog can live in the same repo.
- You want the blog to share navigation, components and internal links with product pages without extra effort.
- You are starting from zero and have no reason to add a second host to configure.
If you do move the blog
When the operational case is real, treat the move like any site move. Map every old URL to one new URL and redirect it with a 301. Google's site move guide notes that permanent redirects "don't cause a loss in PageRank." Update internal links so they point at the new URLs directly, not through the redirects. Replace the old sitemap, keep the old host's redirects live for at least a year, and watch the Pages report in Search Console for stragglers. The broader setup steps are in the SaaS SEO checklist for your first six months, and most of them are worth re-running after a move.
Then set expectations honestly: in subdomain vs subdirectory SEO, the goal of a move is cleaner operations, not a ranking lift. If traffic rises afterwards, check the links and template you fixed along the way before you credit the hostname.
What actually decides whether a small SaaS blog ranks
Back to the founder with the Ghost install. Since he wants Ghost and does not want to own a proxy, the sensible move is to put it on the subdomain, copy his nav into the theme, set up a Domain property, and start publishing. What decides his results after that is not the hostname. It is whether each post targets a query a low-authority site can actually win, and whether the posts link to each other and to the product in a way that forms a cluster.
That is the part I am building Boomranq for. It takes a product description and turns it into a 30-day calendar of winnable topics, grouped into clusters with the internal links planned in advance, so your structure decision supports a publishing plan instead of replacing one. Pick your subdomain or subdirectory this afternoon, write it down, and get back to deciding what to publish.