Subdomain vs subdirectory SEO for SaaS blogs: why folders inherit domain authority, why CMS platforms default you to a subdomain, and how to migrate safely.
Subdomain vs subdirectory SEO looks like a settled question until you look at what companies actually do with their own blogs. Google's position has been consistent for over a decade: the two are roughly equivalent, pick whichever is easier to configure. Salesforce, HotPads, and a long list of SaaS teams since have moved their blog off a subdomain and onto a subfolder anyway, and most of them reported a jump when they did it. That gap between the official answer and what teams keep doing is the actual subject of this post.
This is the deep dive on a claim we make in passing in our guide to SEO for SaaS: put your blog on the root domain, not a subdomain. Here is why that advice holds up under scrutiny, what Google's own engineers have actually said, why so many blogging platforms still default new customers to a subdomain regardless, and how to move an existing blog without losing the rankings it already earned.
A subdirectory blog, yoursite.com/blog, inherits the ranking signals your main domain has already built: backlinks, domain age, topical trust, all of it. A subdomain blog, blog.yoursite.com, sits close enough to a separate site that a meaningful share of those signals don't fully carry over unless the two are tightly interlinked. That is why teams that move from one structure to the other tend to see a lift, not a dip, and why almost nobody moves the other direction.
Two migrations get cited constantly in this debate, and both are messier than the one-line version suggests.
Salesforce's blog move from a subdomain to a subfolder is widely reported to have doubled traffic overnight, a claim that traces back to a tweet from SEO consultant Todd Friesen, relayed by Ruth Burr Reedy. SEO researcher Michael Martinez dug into the same case afterward and concluded the jump was more plausibly driven by the internal linking overhaul that happened alongside the URL change, not the subfolder switch by itself, according to cognitiveSEO's review of the case.
HotPads.com ran into the identical confound. Marketer John Doherty moved the company's blog from blog.hotpads.com to a /blog subfolder in February 2014 and traffic roughly doubled almost immediately. But Doherty was upfront about what else moved at the same time: a full replatform to WordPress, better indexation, and pruning of low-quality posts. The subfolder switch was one change bundled into several, not an isolated variable.
The cleaner data point in that same roundup is a smaller, lesser-known case: Craig Emerson's blog, where he reported a specific page climbing from outside the top 100 results to position 57 within about two weeks, with no other simultaneous changes to the site. cognitiveSEO's own team ran their own subdomain-to-subfolder migration too, and it did close to nothing: rankings sat around fifth position before and after. Structure alone didn't move the needle when nothing else about the site changed with it, which is the honest counterweight to the more dramatic stories above.
Officially, yes, and Google has said so consistently for over a decade. Google's own crawling and ranking systems can index and rank either structure fine, and the real determinant of how much authority a subdomain shares with its root domain is how tightly the two are linked, not the URL pattern itself.
The two most-quoted statements both come directly from Google. In 2012, then-head of webspam Matt Cutts told a webmaster: "They're roughly equivalent. I would basically go with whichever one is easier for you in terms of configuration, your CMSs, all that sort of stuff," a stance Ahrefs' rundown of the debate still cites as the clearest statement of Google's position. Six years later, in a May 2018 webmaster hangout, John Mueller echoed the same conclusion with a telling qualifier attached, reported at the time by Search Engine Journal: "In general, we see these the same. I would personally try to keep things together as much as possible."
That last sentence is doing real work. Even Google's own "it's the same" answer comes with a default preference for keeping content together, because a subdomain only inherits the root domain's trust if it is treated, in practice, as part of the same site: linked to heavily, crawled the same way, referenced from the pages that already rank. A neglected subdomain, thin on internal links and treated as a separate property in Search Console, doesn't automatically get the root domain's authority just because Google's ranking algorithm is theoretically indifferent to the URL pattern. The gap between "Google says it's the same" and "teams see a jump when they switch" is explained by what migrations actually bundle: redirect cleanup, sitemap fixes, content pruning, and tighter internal linking, the same quality-of-execution factors Google's own site-move guidance treats as the real variable in any URL structure change.
Despite Google's "roughly equivalent" stance, most hosted blog tools still hand a new customer blog.yoursite.com by default, not yoursite.com/blog. The reason has nothing to do with SEO advice and everything to do with infrastructure: putting an externally hosted blog inside another site's folder structure means routing requests for one path to an entirely different backend, and most platforms only support that, if at all, on their most expensive tier.
HubSpot is the clearest example. Getting a HubSpot-hosted blog to resolve as yoursite.com/blog when the rest of the site runs on a different platform requires a reverse proxy, and HubSpot's own developer documentation is direct about what that takes: "your IT team must be capable of implementing and maintaining the proxy configuration," and "reverse proxy setup is not provided by HubSpot's support team." That capability is gated to HubSpot's Content Hub Enterprise tier, so the low-risk, zero-engineering default HubSpot points customers toward instead is a subdomain.
Wix runs into the same wall from a different angle. Wix's own subdomain setup guide requires a Premium plan just to connect a subdomain, and Wix's domain connection model assigns a given domain to one site at a time. If your Wix site owns the root domain and your blog runs on a separate platform, there is no reverse proxy option to slot that blog into a folder of the Wix site. A subdomain, pointed at the other platform with a CNAME record, is the only path that doesn't require reengineering how the root domain resolves.
beehiiv takes the same default even without a technical wall forcing it. beehiiv's custom domain documentation tells customers to use a subdomain such as newsletter.yourdomain.com specifically when the root domain already serves another website, no subfolder alternative offered. It is the fastest path to a working custom domain, and for a newsletter platform where most customers already have a separate marketing site, fast setup wins over the SEO case for a folder.
A blog that lives as markdown files in the same repository and the same build as the marketing site never runs into the reverse proxy problem, because there is no second backend to route around. The subdirectory isn't a workaround bolted on afterward. It is just the route the framework already serves.
This is the same structural gap covered in our headless CMS vs git-based blog comparison, just one layer up: a headless CMS adds a sync step between publishing and a rebuild, and a hosted blog platform on a separate domain adds a routing step between a URL and the right backend. Both are places a SaaS blog can silently underperform for reasons that have nothing to do with the writing. A git-based blog removes the sync step because a merged pull request is the publish event, and it removes the routing step because content/blog/*.md in the same repo as the marketing site compiles to /blog/* on the same domain, the same deploy, every time. That mechanical shipping process is also what a GitHub Actions SEO check can gate automatically, since there is one build to validate instead of two systems to keep in sync.
This isn't a theoretical setup. This blog runs the same way: markdown in the same repo as the rest of trylyra.ai, deployed on the same build, living at /blog/ because that is simply where the framework put it. Lyra writes into that same structure, opening a pull request against your existing repo instead of asking you to stand up a second hosted platform on a subdomain and figure out a reverse proxy later. If you haven't picked the framework underneath that repo yet, our Astro vs Next.js SEO comparison covers the trade-off before you commit.
If your blog already has real search traffic on a subdomain, the migration itself is where the risk lives, not the destination structure. Handled with a complete redirect map, ranking fluctuation during the move is expected and typically settles within a few weeks. Handled with gaps in that map, you can lose traffic the URL change never had to cost you.
Start with Search Console's Coverage report, not the list of posts in your CMS. Pull every URL Google has actually indexed under the old subdomain, since a page you forgot about can still be sending you a trickle of traffic through an old backlink. Build a spreadsheet mapping every old URL to its new subfolder equivalent before you touch anything else. This is the same discipline we walk through in detail for a Notion to git-based blog migration, and the mapping step matters more than which platform you are moving from or to.
One tool people reach for here doesn't actually apply. Search Console's Change of Address tool is scoped to domain and subdomain-level moves, example.com to example.net, or blog.example.com to a different subdomain entirely. Google's own Search Console documentation is explicit that path-level moves within the same domain, which is what a blog.example.com to example.com/blog migration actually is, are handled with plain redirects and an updated sitemap, not the Change of Address tool. Reaching for that tool here is a common enough mistake that it is worth ruling out before you start.
Use 301 or 308 redirects for every mapped URL, never a 302 or 307. A permanent redirect is the standard signal that a URL move is intended to be permanent, which is what tells search engines to fold the new URL's ranking signals into the old one rather than treating it as a temporary detour; a temporary redirect code doesn't carry that same weight. Google's site-move guidance covers the redirect requirement and the PageRank-preservation mechanics behind it. Ship the redirect map and the new subdirectory build in the same release, not one before the other, so there is never a window where an old URL resolves to nothing. Then keep the redirects live. Google's own recommendation is specific: "Keep the redirects for as long as possible, generally at least 1 year," since that is the window it needs to recrawl backlinks pointing at the old subdomain and fully reassign their signal to the new URLs. There is no penalty for leaving them in place indefinitely, so the safer default is to just never remove them.
Subdomain vs subdirectory SEO isn't really a ranking-algorithm question. It is a question of which structure you can maintain without a reverse proxy, an IT ticket, or a redirect map you have to get exactly right. A blog built into the same repo and the same deploy as your product never has to choose, because the subdirectory was never a special case to engineer around in the first place.
Lyra ships new posts as pull requests against your existing repo, so a SaaS blog lands on your root domain by default instead of a subdomain you will migrate off later.
FAQ
Not by policy. Google's John Mueller said in 2018 that Google sees the two the same, and Matt Cutts called them roughly equivalent back in 2012. In practice, migrations from subdomain to subdirectory often show gains, but the honest read of those case studies is that internal linking cleanup, redirect quality, and content pruning done during the move usually explain more of the jump than the URL pattern alone.
If your blog already gets meaningful search traffic, weigh the migration risk against the upside carefully, since a mishandled redirect map can cost you rankings you already have. If you are starting a blog from scratch or it has little to no organic traffic yet, put it on a subdirectory from day one and skip the question entirely.
No. Search Console's Change of Address tool is scoped to domain and subdomain level moves, such as example.com to example.net. Google's own documentation states it doesn't cover moving a subfolder within the same domain, which is what a blog.example.com to example.com/blog move actually is. That kind of move needs 301 or 308 redirects and an updated sitemap, submitted the normal way, not the Change of Address tool.
Google's site-move documentation recommends keeping redirects live for as long as possible, generally at least a year, since that is the window Google needs to recrawl old backlinks and fully transfer ranking signals to the new URLs. There is no downside to leaving them in place permanently.
Because putting an externally hosted blog inside another site's folder structure requires a reverse proxy, routing one path to a different backend while the rest of the domain serves from somewhere else. HubSpot gates that capability behind its Content Hub Enterprise tier and an IT team to run it; Wix requires a paid plan just to connect a subdomain and has no reverse proxy option at all. A subdomain needs none of that, so it is the low-friction default.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Start free with three posts, no card.
Keep reading
A Contentful to git-based blog migration playbook: convert Rich Text JSON and entry references to Markdown, protect your rankings, and cut the metered API bill.
A Medium to git-based blog migration playbook: export your posts, handle redirects since medium.com isn't your domain, and protect your rankings.
A Substack to git-based blog migration playbook: keep your subscriber list, redirect the /p/ URLs, and protect the rankings you already earned.