Blog Subdomain vs Subdirectory: Which Wins for SEO?

Key takeaways

Subdirectories (/blog) inherit domain authority instantly; subdomains (blog.) are often crawled and evaluated as a separate site, at least initially.
The gap has narrowed since Google got better at associating subdomains with their root domains, but narrower isn't zero — migrations from subdomain to subdirectory still regularly show traffic lifts.
Pick based on your CMS and engineering constraints first, then fix the SEO cost with proper internal linking and a shared sitemap — not the other way around.

Why this question keeps coming up for SaaS founders

Most indie hackers hit this decision at the exact moment they're deciding whether to run their marketing blog on the same Next.js/Webflow/WordPress instance as their app, or spin up a separate platform because the app's codebase wasn't built to serve content pages. That engineering constraint is usually the real driver — SEO gets invoked after the fact to justify whichever option was easier to ship.

That's backwards, and it's expensive to fix later. We've watched founders migrate a two-year-old blog.app.com setup to app.com/blog and watch organic sessions climb 20-40% over the following three months with zero new content published — just the domain consolidation. That's not universal, but it's common enough that "we'll just use a subdomain for now" is one of the more costly shortcuts a founder can take in year one.

What actually happens technically

A subdirectory lives under the same hostname as your main site. The same SSL certificate, the same robots.txt, the same DNS record. Googlebot crawls it as part of the same site, and internal PageRank flows through normal hyperlinks without crossing a host boundary.

A subdomain is, technically, a different hostname — even though it shares a root domain. Google has gotten significantly better at recognizing that blog.yourapp.com and yourapp.com are related properties, largely because of signals like shared Search Console verification, canonical patterns, and crosslinking. But "related" is not "the same." Google's Search Central documentation describes site structure and crawling as evaluated per-host, and in practice many subdomains still get their own crawl allocation, their own initial trust assessment, and sometimes their own separate appearance in Search Console performance reports — which makes unified reporting harder too.

This matters most in the first 6-12 months of a new blog's life, when you're trying to earn initial rankings for anything. A brand-new subdomain is functionally closer to a brand-new site than people expect.

Side-by-side comparison

Factor	Subdirectory (/blog)	Subdomain (blog.site.com)
Inherits domain authority	Immediately	Partially, over time
Crawl budget	Shared with main site	Often allocated separately
Setup complexity	Depends on CMS/stack compatibility	Easier if blog runs on different tech
Search Console reporting	Unified by default	Requires separate property (can be grouped)
SSL/cookies/analytics	Shared automatically	Needs separate config or workaround
Best use case	Marketing blog, docs, most content	Genuinely separate product (e.g., a community app, a status page)

When a subdomain is still the right call

There are legitimate reasons to use a subdomain, and they're almost never SEO reasons.

Your main site runs on infrastructure that can't serve a path-based blog. A no-code landing page builder, a custom app shell that intercepts all routes, or a legacy system where adding a reverse proxy rule isn't worth the engineering time.
The content is genuinely a different product, like a knowledge base meant to be its own standalone destination, a status page, or a community forum with different hosting and auth requirements.
You're consolidating multiple brands under one umbrella domain temporarily and need clean separation during a transition.

If none of those apply, the honest answer is you're choosing a subdomain for developer convenience and paying an SEO tax for it. That's a fine trade if shipping fast matters more right now — just don't pretend it's SEO-neutral.

The reverse proxy fix (and where it breaks)

Most modern stacks solve the "my blog runs on different software" problem with a reverse proxy: you run your blog on Ghost, WordPress, or a static site generator, but route yoursite.com/blog/* traffic to it at the edge using something like Cloudflare Workers, an Nginx rule, or a Vercel rewrite. The visitor never sees the different backend; the URL stays on your main domain.

This is the right move in 2026 for almost every founder, but three things break it in practice:

Relative links inside the CMS point to the wrong host. If your blog platform generates canonical tags or sitemap URLs referencing its own subdomain instead of the proxied path, you end up with duplicate content signals — Google sees both yoursite.com/blog/post and blog-platform.ghost.io/post as live, indexable pages.
Trailing slash and redirect mismatches. Reverse proxies frequently introduce double redirects (yoursite.com/blog → blog-platform.io → yoursite.com/blog/) which waste crawl budget and occasionally get flagged as redirect loops.
The sitemap doesn't get merged. Your main site's sitemap.xml and your blog platform's sitemap.xml are two different files unless someone explicitly combines them or references one from the other via a sitemap index. We cover the mechanics of getting this right in our sitemap guide for AI and traditional crawlers — it's the single most common thing we find broken when auditing a reverse-proxied blog.

Platform-specific reality check

The "which should I pick" decision often collapses once you know your stack's actual constraints:

WordPress makes subdirectory setup trivial — it's designed to live at a path. If your main marketing site is also WordPress, this is a non-decision.
Webflow historically couldn't host a blog at a subdirectory of a non-Webflow main site without a proxy layer, which pushed a lot of Webflow users toward subdomains by default, not by choice. We go deeper on the tradeoffs of each platform in our WordPress vs Webflow comparison.
Headless setups (Next.js, Astro, etc.) handle subdirectories cleanly since routing is code, not platform configuration — this is usually the easiest case.
Ghost defaults to its own subdomain-style URL structure unless you configure a reverse proxy, which is why so many SaaS blogs end up on blog.company.com without anyone deciding that on purpose.

What GEO changes about this decision

Generative engines that cite web content — the systems behind AI Overviews, Perplexity answers, and ChatGPT's browsing mode — tend to favor pages with clear topical association to a trusted root domain. A subdirectory structure gives an AI crawler an unambiguous signal: this content belongs to this company, under this domain's existing trust and citation history. A subdomain introduces a question mark these systems have to resolve by inference rather than reading it directly off the URL.

This isn't a documented ranking factor for AI answer engines the way it is for traditional search — there's no public specification for it. But the underlying mechanism is the same one that drives featured snippet selection: these systems pull a quotable unit of content and need to attribute it with confidence. A URL structure that visibly ties back to an established, citable domain reduces friction in that attribution step.

Migration mechanics if you're moving from subdomain to subdirectory

If you already have a blog on a subdomain with meaningful traffic, moving it isn't free — it's a real migration with real risk, not a quick DNS change.

Map every existing URL to its new subdirectory equivalent before touching anything.
Implement 301 redirects at the server or edge level — not meta-refresh, not JavaScript redirects.
Update internal links across the entire site to point to new paths directly, rather than relying on the redirect chain.
Submit the new sitemap in Search Console and keep the old subdomain's sitemap live (returning redirects) for at least a few weeks so Google can re-crawl and reconcile.
Expect a temporary dip — typically 1-3 weeks — before the consolidation gain shows up. This is normal redirect-processing lag, not a sign something went wrong.

Site speed during this transition matters more than people expect, since a slow redirect chain compounds the crawl delay; if you haven't audited this recently, testing your site speed properly before a migration catches problems a redirect map alone won't.

Frequently Asked Questions

Q: Does Google penalize subdomains for SEO?

No, there's no penalty. Subdomains are simply evaluated with more independence from the root domain, which means they often take longer to accumulate trust and rankings than content placed in a subdirectory of an already-established site.

Q: Can I switch from a subdomain to a subdirectory without losing my rankings?

Yes, with a proper 301 redirect map and updated internal links, most sites retain the bulk of their rankings within a few weeks and often see a net improvement from consolidated authority.

Q: Is blog.company.com ever better than company.com/blog for SEO specifically?

Rarely. The main scenario is when the blog needs entirely separate hosting, security, or branding — and even then, a reverse proxy usually achieves the separation without the SEO cost of a true subdomain.

Q: Does the subdomain vs subdirectory choice affect how AI search engines cite my content?

It can indirectly, since AI engines favor clear attribution to a trusted domain, and a subdirectory makes that attribution more direct than a subdomain does. It's not a documented factor the way crawlability or content clarity are, but the mechanism points the same direction.

Q: What's the fastest way to check which setup a competitor uses?

Look at their blog URL directly — if it starts with the same root domain as their homepage (company.com/blog), it's a subdirectory; if it has a prefix before the root domain (blog.company.com), it's a subdomain. You can confirm DNS structure with a tool like ICANN's WHOIS lookup if you want to see the full domain registration.