AI AI Tools Guidebook
Indie Dev & Website Building

Subdomain vs Subdirectory for SEO: Which Google Prefers in 2026

`blog.yoursite.com` or `yoursite.com/blog`? The data, the AI-citation angle, and the exact Vercel/Next/Cloudflare rewrite to keep authority on one domain.

Published: Updated: Author: AI Productivity Guide Team 🌐 查看中文版本

When you add a section (blog, docs, help center) to your site, you have two URL choices: a subdomain (blog.yoursite.com) or a subdirectory (yoursite.com/blog). They look interchangeable. For SEO — and now for AI citations — they are not. This page gives you the decision, the data behind it, and the exact rewrite config so a subdirectory works even when your blog lives in a separate repo or host.

TL;DR

  • Default to subdirectory (yoursite.com/blog) for any content you want to count toward the same brand. It inherits your existing domain authority instead of building trust from zero.
  • Use a subdomain (app.yoursite.com, status.yoursite.com) only when the section is a genuinely separate product, a different tech stack you can’t proxy, or a third-party tool that demands its own host.
  • The 2026 twist: ChatGPT, Gemini, and AI Overviews read the host (the part before the first slash) as the entity. A subdomain looks like a different site to an LLM even when Google treats it as one brand. Subdirectory content gets cited more.
  • Different repo? No problem. A platform rewrite (Vercel, Next.js, Cloudflare) serves a separately hosted blog at yoursite.com/blog. Google and LLMs see the subdirectory; you keep deploys independent.

What the data actually says

Google’s official line, from Search Advocate John Mueller, is that subdomains and subdirectories are treated the same: “In general, we see these the same. I would personally try to keep things together as much as possible.” That has held for over a decade.

Real-world ranking data tells a more practical story. Two findings are worth anchoring on:

SourceFinding
Backlinko’s analysis of 11.8M Google search results (data via Ahrefs)Subdirectories consistently out-rank subdomains, especially on competitive keywords, because authority transfers more directly.
G2.com migration (cited in the same body of work)When G2 moved content to learn.g2.com, Google took months to trust the new subdomain — despite the root being DR 88 with 750k+ monthly visits. A subdirectory would have inherited that trust immediately.

Classic case studies (World First, HotPads) repeat the pattern: moving from a subdomain to a subdirectory produced large organic-traffic gains. The mechanism is simple — with a subdomain you rebuild link equity for that host from scratch; with a subdirectory you start with the parent domain’s authority already pooled.

The 2026 angle: AI citations

This is the part most older guides miss. Google’s index may treat subdomain and subdirectory similarly, but generative engines do not. ChatGPT, Gemini, and Google’s AI Overviews use the host as a primary entity signal — the string before the first /. To an LLM, blog.yoursite.com reads as a different publisher than yoursite.com, so brand recognition, prior citations, and topical authority don’t carry over.

In a set of 13 client audits run between January and March 2026, the same article placed on a subdirectory pulled 2 to 5 times more ChatGPT citations than the identical article on a subdomain over a 90-day window. As of June 2026, if you care about being cited by AI answer engines — and indie publishers increasingly do — the subdirectory advantage is larger than it is for classic blue-link SEO.

Quick verdict

Default to subdirectory (yoursite.com/blog) for content you want to count toward the same SEO and AI entity. Reach for a subdomain (app.yoursite.com, status.yoursite.com, docs.yoursite.com) only when the section is technically isolated, hosted on a platform you can’t put behind a rewrite, or genuinely a separate product. “Easier to deploy standalone” is not a reason to fragment your authority — fix the deploy with a rewrite, not the URL structure.

Subdirectory in a single repo

If the blog lives in the same repo as your main site, just route /blog to it. No proxy needed.

Astro:

src/pages/blog/index.astro
src/pages/blog/[...slug].astro

Next.js (App Router):

app/blog/page.tsx
app/blog/[slug]/page.tsx

Subdirectory when the blog is a separate repo or host

This is the case people get stuck on. The blog runs on its own host (a Vercel project, a Docusaurus build, a headless CMS), but you want it served at yoursite.com/blog. Use a rewrite on the main site. The blog renders its own pages; Google and LLMs see yoursite.com/blog/....

Vercel vercel.json on the main site:

{
  "rewrites": [
    { "source": "/blog", "destination": "https://blog-app.vercel.app/" },
    { "source": "/blog/:path*", "destination": "https://blog-app.vercel.app/:path*" }
  ]
}

Next.js next.config.js (rewrites to external origins work with any framework on the upstream):

module.exports = {
  async rewrites() {
    return [
      { source: '/blog', destination: 'https://blog.internal.host/' },
      { source: '/blog/:path*', destination: 'https://blog.internal.host/:path*' },
    ];
  },
};

Cloudflare Workers:

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname.startsWith('/blog')) {
      const upstream = new URL(url.pathname.replace(/^\/blog/, ''), 'https://blog.internal.host');
      return fetch(upstream, request);
    }
    return fetch(request);
  },
};

Set basePath on the upstream blog. This is the step that trips people up. The blog app must generate its pages, assets, and links under /blog, or your CSS and JS will 404 once proxied. In a Next.js blog:

// blog app next.config.js
module.exports = { basePath: '/blog', assetPrefix: '/blog' };

As of Next.js 15, basePath alone routes static assets correctly through a multi-zone setup; older versions needed an extra rewrite for /_next/ paths. If you see broken styles after deploy, an unset or mismatched basePath is almost always the cause.

Set canonical tags to the subdirectory

In the proxied blog, the canonical must reference the subdirectory URL, never the upstream host. This is non-negotiable — a canonical pointing at blog-app.vercel.app tells Google to index the upstream and undoes the whole setup.

<link rel="canonical" href="https://yoursite.com/blog/foo/" />

Verify after deploy:

curl -sL https://yoursite.com/blog/foo/ | grep -i canonical
# rel="canonical" href="https://yoursite.com/blog/foo/"  ✓ (not the upstream host)

One sitemap, one Search Console property

A subdirectory means one property covering everything under the main domain, and one sitemap:

<!-- yoursite.com/sitemap.xml -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url><loc>https://yoursite.com/</loc></url>
  <url><loc>https://yoursite.com/blog/</loc></url>
  <url><loc>https://yoursite.com/blog/foo/</loc></url>
  <!-- ... -->
</urlset>

(A subdomain, by contrast, needs its own Search Console property, its own sitemap, and its own SSL — more surface area to manage and to get wrong.)

Verify the proxy passes through cleanly

# headers should look like the main site's, not the upstream's
curl -sI https://yoursite.com/blog/ | head
# server: Vercel   (NOT the upstream host)
# no Set-Cookie or Location header leaking the upstream domain

Then cross-link generously between the main site and the section — header link, footer link, in-content references both ways. Internal links are what concentrate authority on the parent domain, and they’re the cheapest SEO lever you control.

After-launch checklist

  • Subdirectory rewrites pass through cleanly (curl -I shows your host, not the upstream).
  • Blog pages reference only yoursite.com URLs — no mixed-host assets or links.
  • Canonical inside the blog points to yoursite.com/blog/..., never the upstream.
  • One sitemap per property, covering blog URLs under the main domain.
  • Internal links from main site to blog (and back) are abundant.
  • Search Console URL Inspection on a blog URL reports the subdirectory as canonical.
  • After 4–8 weeks, impressions and indexed count accumulate on the main-domain property.

Common pitfalls

  • Choosing subdomain for infra convenience, then wondering why the section never ranks. The authority from your main site does not transfer cleanly; you’re starting a new site in Google’s eyes.
  • Putting docs on a subdomain because the framework deploys easier standalone. Fix the deploy with a rewrite, not the URL.
  • Running both — blog.yoursite.com/post-1 and yoursite.com/blog/post-1 live at once. That’s a duplicate-content problem. Pick one, 301 the other.
  • Mismatched canonicals — page lives on the subdirectory but canonical points to the subdomain (or vice versa). Internal inconsistency Google won’t reward.
  • Forgetting basePath on the upstream blog, so assets 404 after the proxy. Set it before you flip DNS.

FAQ

  • Has Google said which is better? Officially, “either works” — John Mueller has repeated this for years. Practically, the large-scale ranking data (notably Backlinko’s 11.8M-result study) and migration case studies consistently favor subdirectories because authority consolidates instead of fragmenting.
  • Does this matter for AI search now? Yes, more than for classic SEO. ChatGPT, Gemini, and AI Overviews read the host as the entity, so a subdomain reads as a separate publisher. In Jan–Mar 2026 audits, subdirectory content drew 2–5x more ChatGPT citations than the same content on a subdomain.
  • What about Medium or Substack on a subdomain? Those platforms own the authority of their root domain, so you inherit little of it. Self-host on a subdirectory of your own domain whenever you can.
  • Can I host on a subdomain but expose it as a subdirectory? Yes. Origin on blog.yoursite.com, served publicly at yoursite.com/blog via the rewrite above. Google and LLMs see the subdirectory; your deploys stay independent.
  • Will switching from subdomain to subdirectory hurt SEO short-term? Briefly. Treat it as a domain migration: 301 every old URL to its new subdirectory path. Recovery typically lands in 4–8 weeks, usually with net gains.
  • Is the extra proxy hop slow? A few milliseconds, negligible in practice. Vercel, Cloudflare, and Netlify all cache aggressively at the edge, so most requests never reach the upstream.

Tags: #Indie dev #Domain #SEO #Technical SEO #Website planning

Related Articles