Subdomain vs Subdirectory for Content: Which Google Prefers

`blog.yoursite.com` or `yoursite.com/blog`? Use this Vercel/Next/Cloudflare rewrite config to keep SEO consolidated on one domain.

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. They are not — at least not for SEO. Below is the decision and the exact rewrite config for either path.

Background

Google has stated for over a decade that subdomains and subdirectories can both work. In practice subdirectories consolidate authority on a single domain, while subdomains are treated more like separate sites — which can fragment your SEO equity. For most indie content, subdirectory is the correct call. The infra to make subdirectory work even when your blog lives in a different repo is straightforward — a reverse proxy or platform rewrite.

How to tell

  • You are launching a blog or docs section under an existing brand domain.
  • You want to build domain authority faster across one trust signal.
  • You are not running on completely separate tech stacks for each section.
  • You expect to link extensively between the main site and the new section.

Quick verdict

Default to subdirectory (yoursite.com/blog) for any content you want to count toward the same SEO entity. Use a subdomain (docs.yoursite.com, app.yoursite.com) when the section is technically isolated, hosted on a different platform, or genuinely a separate product.

Before you start

  • Know whether your blog and main site live in the same repo or different ones.
  • Pick a host that supports rewrites (Vercel, Netlify, Cloudflare Workers, Next.js).
  • Plan canonical tags to match the chosen structure.

Step by step

  1. Decide based on purpose, not infrastructure. Same brand, same audience → subdirectory. Standalone product or separate stack → subdomain.

  2. Subdirectory in a single repo: route /blog to the blog section. Astro example:

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

Next.js:

app/blog/page.tsx
app/blog/[slug]/page.tsx
  1. Subdirectory with the blog in a different repo / different host: use a platform rewrite. 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:

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);
  },
};

The blog renders its own pages but Google sees yoursite.com/blog/....

  1. Subdomain alternative (only if intentionally separating): set DNS for the subdomain pointing at its own host. Each host handles its own SSL and content. Add the subdomain as a separate Search Console property.

  2. Set canonical tags inside the chosen structure. In the proxied blog, canonical must reference the subdirectory URL, not the upstream subdomain:

<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/"  ✓
  1. Submit one sitemap per Search Console property. Subdirectory = one sitemap covering all sections under the main domain:
<!-- 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>
  1. Cross-link generously between main site and the section — this is what concentrates authority. Header link, footer link, in-content references.

  2. Verify the proxy passes through correctly:

# 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)
# the blog pages should load with no mixed-host references

Implementation checklist

  • Subdirectory rewrites work and pass through cleanly (curl -I confirms).
  • Canonical tag inside the blog references yoursite.com/blog/..., never the upstream.
  • One sitemap per property; sitemap covers blog URLs under the main domain.
  • Internal links from main site to blog (and back) are abundant.
  • Upstream host (if any) is not exposed publicly via a separate subdomain.

After-launch verification

  • Search Console URL Inspection on a blog URL shows the subdirectory URL as canonical.
  • dist or proxied output for the blog references only yoursite.com URLs.
  • Authority signals (impressions, indexed count) accumulate on the main domain property after 4-8 weeks.

Common pitfalls

  • Picking subdomain because it is easier infrastructure-wise, then wondering why the blog never ranks — the SEO juice from the main site does not transfer cleanly.
  • Putting docs on a subdomain because Docusaurus is easier to deploy standalone — fix the deploy with a rewrite, not the URL structure.
  • Using both — blog.yoursite.com/post-1 and yoursite.com/blog/post-1 simultaneously is a duplicate content nightmare. Pick one, 301 the other.
  • Mixing canonicals — page lives on subdirectory but canonical points to subdomain (or vice versa). Internal inconsistency.
  • Forgetting hreflang and other multi-language signals when splitting into subdomains — each subdomain might end up with its own hreflang config to manage.

FAQ

  • Has Google said which is better?: Officially “either works”. Practically, search engineers like John Mueller have implied subdirectories tend to consolidate signals more easily. Most case studies of “moved from subdomain to subdirectory and rankings improved” tell the same story.
  • What about Medium / Substack on a subdomain?: Common, but those platforms own the domain authority of their root — you get little benefit. Self-host on a subdirectory of your own domain whenever possible.
  • Can I use a subdomain just for hosting and proxy it to subdirectory?: Yes — origin on blog.yoursite.com but exposed publicly at yoursite.com/blog via reverse proxy. Google sees the subdirectory.
  • Will switching from subdomain to subdirectory hurt SEO short term?: Yes, briefly — treat it like a domain migration with 301s. Recovery typically in 4 to 8 weeks, often with net gains.
  • Is the rewrite slow because of the extra hop?: A few ms, mostly negligible. Vercel/Cloudflare/Netlify all cache aggressively on the edge.

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