Subdomain vs Subfolder: The SEO Decision, With Code

Look at who ranks for "subdomain vs subfolder" in the United States. An r/TechSEO thread sits at position 2 with two backlinks. A Stack Overflow question from 2009 sits at position 6 with zero. The three polished comparison articles around them were published in 2019, 2019 and 2023, and not one of them contains a line of configuration, a curl command, or a migration checklist.

That is the gap. The strategic question is settled and has been for years. The operational question is not, and it is the one that actually costs you a weekend.

This article skips the debate about whether Google secretly prefers one shape. It covers what provably changes when your blog lives at blog.example.com instead of example.com/blog, which of those changes you can measure yourself in ten minutes, and the exact config to serve a subfolder from a separate application without a reverse proxy you have to maintain.

What Google actually documents about subdomains and subfolders

Google has never published a ranking preference between the two. What it has published is a set of mechanical rules that apply to hosts, and a subdomain is a different host. That distinction is where every real difference comes from.

Three pieces of Google documentation matter here, and all three are first-party and current as of publication.

Robots rules are per host. The robots.txt specification page states it plainly: "A robots.txt on a subdomain is only valid for that subdomain." It goes further on scope: "The rules listed in the robots.txt file apply only to the host, protocol, and port number where the robots.txt file is hosted."

So example.com/robots.txt governs nothing at blog.example.com. Your blog on a subdomain needs its own file, served from its own root, and if the platform hosting it ships a default one you did not write, that default is what crawlers obey.

Sitemap scope follows directories. The sitemap building guide states: "You can host your sitemaps anywhere on your site, but unless you submit your sitemap through Search Console, a sitemap affects only descendants of the parent directory."

A sitemap at example.com/sitemap.xml cannot vouch for URLs on another host by sitting there. Cross-host sitemaps are allowed, but the same page adds the condition: "For each individual site, make sure that the robots.txt file references the sitemap for that individual site." Two hosts, two robots.txt files, two sitemap references.

Search Console properties split on hosts, not on paths. The property types help page defines a Domain property as "a domain-level property that Includes all subdomains (m, www, and so on) and multiple protocols (http, https, ftp)". A URL-prefix property "Includes only URLs with the specified prefix, including the protocol (http/https)", and subdomains do not match it.

That is the sentence most teams discover too late. If your property is the URL-prefix https://example.com/, your subdomain blog reports into nothing. You will have search data for the marketing site and a blank where the blog should be, and you will not notice until someone asks which articles are getting impressions.

The equivalence claim, stated honestly

Google's position, repeated by John Mueller over several years, is that subdomains and subdirectories are essentially equivalent for web search. There is no documented penalty and no documented bonus.

What people observe in migration write-ups is that consolidating a blog from a subdomain onto the main domain is often followed by improvement. That is an industry pattern, not a Google statement, and it is confounded by everything else a team changes during a migration: templates, internal linking, publishing cadence, redirect hygiene.

Treat it as weak evidence pointing the same way as the operational argument, and nothing more. Nobody can guarantee a ranking outcome from a URL change, and any article that tells you otherwise is selling something.

The three things that genuinely change on a subdomain

Forget the ranking debate for a moment. Here is what changes mechanically the day your blog moves to a different host, in the order you will hit them.

None of these is fatal. Every one of them is a thing that can be forgotten, and the failure mode of forgetting is silence: no error, no alert, just a section of your site that nobody is measuring. That pattern is the same one behind most cases of a site that never shows up in search at all.

The internal-linking row is the one people underrate. Links between hosts still pass signals, but they stop being the cheap, automatic byproduct of a shared template and start being something a human has to remember to write. A blog that loses its link path to the product pages loses most of what makes SEO worth doing for a SaaS in the first place.

When a subdomain is the right answer

A subdomain is not a mistake. It is a separation, and separation is sometimes exactly what you want.

Google's own multi-regional guidance lists subdomains with a gTLD as a legitimate locale structure. Its pros, verbatim: "Easy to set up", "Allows different server locations", "Easy separation of sites". Its listed con is that "Users might not recognize geotargeting from the URL alone (is 'de' the language or country?)".

Note what the same table says about subdirectories with a gTLD. Pros: "Easy to set up", "Low maintenance (same host)". Cons: "Single server location", "Separation of sites harder".

"Separation of sites harder" is the honest framing. The subdomain question is not "which ranks better", it is "do I want these two things coupled or not".

Reach for a subdomain when:

• You need a different server location or a different stack you cannot proxy. A Rails monolith and a static docs site with incompatible build pipelines is a real constraint, not an excuse.
• The content is genuinely a different site. A status page, a customer community, a help desk run by a vendor. Nobody benefits from those sharing a crawl budget with your product pages.
• It is staging or internal. Never put a staging environment in a subfolder of production. Put it on a subdomain, and give that subdomain a robots.txt that disallows everything, which you can only do because robots rules are per host.
• Legal or compliance requires isolated origins. Cookie scope and same-origin policy are real reasons, and they have nothing to do with SEO.

Reach for a subfolder when the content exists to support the main domain: a blog, a resource library, a glossary, comparison pages. Those are the cases where coupling is the point.

Who benefits from the subdomain default

Most hosted blog platforms put you on a subdomain by default, and it is worth understanding why before you accept it.

Serving example.com/blog from someone else's infrastructure requires that infrastructure to sit behind your domain's routing. That means a proxy, a rewrite rule, or an edge worker, all of which are work for the vendor and support tickets when they break. A CNAME pointing blog.example.com at their servers is one DNS record and zero engineering.

The convenience is real, and it is theirs before it is yours. The question worth asking a vendor is not "does this hurt SEO", because they will say no and they will be quoting Google correctly. The question is "can you serve this from a path on my domain, and what does that take".

There is a worse variant, and it is common enough to name. Some platforms put your blog at yourbrand.theirplatform.com. That is not your subdomain. It is their domain, and every signal that page accumulates accumulates on a hostname you do not control and cannot take with you. If the relationship ends, the URLs end.

This is the reason syted publishes into a path on the customer's own domain rather than a hosted subdomain. It is also why the delivery integration has to do more work than a DNS record.

Serving a subfolder from a separate application

Here is the part the top-ranking articles skip. You do not need to merge two codebases to put a blog at /blog on your main domain. You need one routing rule.

Next.js rewrites

In a Next.js app, rewrites in next.config.js maps an incoming path to a destination, including a destination on another host. The URL in the browser and in the crawler's request does not change, which is the entire point: to Google, the page is at example.com/blog/your-post.

The shape from the official documentation:

// next.config.js
module.exports = {
  rewrites() {
    return [
      {
        source: '/blog',
        destination: 'https://example.com/blog',
      },
      {
        source: '/blog/:slug',
        destination: 'https://example.com/blog/:slug',
      },
    ]
  },
}

:slug matches a single path segment. It will match /blog/first-post and not /blog/2026/first-post. For nested paths you need the wildcard modifier:

{
  source: '/blog/:path*',
  destination: 'https://blog-backend.example.com/:path*',
}

The modifiers are the path-to-regexp ones: * for zero or more segments, + for one or more, ? for zero or one.

The trailing slash trap

This one costs an afternoon if you hit it cold. The documentation is explicit: "If you're using trailingSlash: true, you also need to insert a trailing slash in the source parameter. If the destination server is also expecting a trailing slash it should be included in the destination parameter as well."

module.exports = {
  trailingSlash: true,
  rewrites() {
    return [
      { source: '/blog/', destination: 'https://example.com/blog/' },
      { source: '/blog/:path*/', destination: 'https://example.com/blog/:path*/' },
    ]
  },
}

Get this wrong and the rewrite silently stops matching. You get your own 404 page, at HTTP 404, and nothing in the build output complains. Verified against the Next.js rewrites reference as of publication; this repo runs Next 16.2.12 and the documented API shape has been stable since has landed in 13.3, but check your own version before pasting.

Ordering, when you also have your own /blog routes

Rewrites returned as a flat array are applied after the filesystem and before dynamic routes. If you want a rewrite to win over a page file, or lose to everything including the 404, use the object form:

module.exports = {
  rewrites() {
    return {
      beforeFiles: [],   // wins over page files and /public
      afterFiles: [],    // after files, before dynamic routes
      fallback: [        // last resort, before the 404 page
        { source: '/:path*', destination: 'https://legacy.example.com/:path*' },
      ],
    }
  },
}

The fallback bucket is the incremental-migration pattern: your Next.js routes win, and anything you have not ported yet falls through to the old site.

If you are not on Next.js

The mechanism is the same everywhere, only the syntax changes. Nginx does it with proxy_pass, Cloudflare does it with a Worker, Vercel and Netlify both expose rewrite rules in their config files. Cloudflare's own write-up on this makes the constraint explicit: "DNS records only operate on the domain level", so a CNAME cannot address a path. A path needs something that speaks HTTP.

Whatever you use, the test is the same. The crawler must receive a 200 at the subfolder URL, not a redirect to another host. A 301 from example.com/blog/post to blog.example.com/post is a subdomain setup wearing a subfolder URL, and it gets you none of the coupling you wanted.

Migrating a blog from a subdomain to a subfolder

If you already have a subdomain blog with traffic, moving it is a site move with URL changes, and Google documents that procedure. Follow the documented one rather than improvising.

Use permanent server-side redirects. Verbatim: "Use server side permanent redirects if technically possible. Although Googlebot supports several kinds of redirects, we recommend that you use HTTP permanent redirects if possible, such as 301 and 308."

Map one to one. Every old URL redirects to the single new URL with the same content. A blanket redirect of every old article to the new index page is the mistake that actually loses rankings, because it tells Google the old pages no longer exist rather than that they moved.

Submit the new sitemap. Verbatim: "Submit the new sitemap in Search Console. This will help Google learn about the new URLs. At this point you can remove your old sitemap, since Google will use the new sitemap going forward."

Use the Change of Address tool, and know when it applies. This is the detail that separates the two directions of this migration. Google's guidance: "If you're changing domain names or subdomains, submit a Change of Address in Search Console for the old site." The same page lists what it does not cover: HTTP to HTTPS conversions, www variations on the same domain, and path changes.

So moving blog.example.com to example.com/blog is a Change of Address case, because the host changed. Moving example.com/articles to example.com/blog is not, because only the path changed. Same intuition about "moving the blog", two different procedures.

Keep the redirects. Verbatim: "Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites."

Expect noise. Verbatim: "Note that the visibility of your content in Search may fluctuate temporarily during the move. This is normal and a site's rankings will settle down over time."

That last quote is worth pinning above the dashboard. Migrations look like disasters for a few weeks. Panicking and reverting halfway through is how a recoverable dip becomes a permanent one. If you want a sense of the timescales involved, how long SEO takes covers the same impatience from the other side.

One thing not to do during a migration: rewrite the articles at the same time. Change the URLs, keep the content byte-identical, confirm the redirects resolve, then improve the content as a separate pass. If you mix them and traffic drops, you will not know which change caused it. The same discipline applies to any content audit where you are tempted to fix everything at once.

The objection nobody in the top ten raises

If a subfolder on an established domain inherits the domain's standing, the obvious follow-up is whether you can rent that out. Google has a policy on exactly this, and it was last updated on 2026-08-28.

The site reputation policy "applies where third-party content is published on a host site mainly because of that host's already-established ranking signals, which it has earned primarily from its first-party content". The example given is "an educational site hosting a page about sponsored reviews of payday loans written by a third-party that distributes the same page to other sites across the web".

The policy also says what does not trip it. Syndicated news between publications is fine. User-generated content such as forums and comment sections is fine. And the human review looks at "whether content on the relevant portion of the site is created with sufficient input, editorial oversight, or contribution from the host site to be considered fully integrated with the main site", weighing presentation consistency, quality standards, clear authorship, and whether the identical content appears elsewhere. Google adds that "not one of these factors is either necessary or sufficient on its own".

Read the test carefully, because it is the right test for anyone putting generated or outsourced content into their own subfolder. The question is not who typed the words. It is whether the content is about your business, reviewed by you, published only by you, and consistent with the rest of the site.

An article written for your domain, about your product's problem space, that exists nowhere else, sitting in your blog with your name on it, is first-party content with a production pipeline behind it. A syndicated coupon page in /deals written to monetise your domain authority is the thing the policy names. Any tool that produces the second kind, including an SEO automation setup you build yourself, is a liability regardless of where you host it.

Check your own setup in ten minutes

None of the above needs a tool subscription. Every claim in this article is checkable with curl and a browser tab.

Does your subdomain have its own robots.txt, and what does it say?

curl -s https://example.com/robots.txt
curl -s https://blog.example.com/robots.txt

If the second returns a 404, crawlers are unconstrained there, which is usually fine. If it returns a Disallow: / you did not write, your blog is invisible and has been since launch.

Does your sitemap reference the right host?

curl -s https://blog.example.com/robots.txt | grep -i sitemap

A subdomain with no Sitemap: line in its own robots.txt and no separate Search Console submission is relying on discovery alone.

Is the subfolder actually a subfolder?

curl -o /dev/null -sS -w '%{http_code} %{redirect_url}\n' https://example.com/blog/some-post

A bare 200 is a real subfolder. A 301 with a redirect URL on another host is a subdomain in disguise.

Which Search Console property covers your blog? Open Search Console and look at the property list. If your only property is a URL-prefix and your blog is on a subdomain, add a Domain property. It requires a DNS TXT record and it covers every subdomain and both protocols at once.

What does Google actually have indexed per host? Use the URL Inspection tool on one live article URL from each host. It reports the canonical Google selected, which is the answer to most "why is this page not ranking" questions before any content work starts.

Do these five checks before touching architecture. Roughly half the time the architecture is fine and the problem is a robots.txt from a template, a sitemap listing URLs on the wrong host, or a property nobody set up. Those are afternoon fixes. A migration is not.

Architecture is the cheapest decision on this list precisely because it is made once. Which structure you pick matters less than picking deliberately, wiring the three host-scoped things correctly, and then spending your remaining time on the part that compounds, which is publishing things worth linking to. For a Next.js codebase specifically, the rest of the surface is covered in Next.js SEO, and the newer question of how assistants pick which pages to cite turns out to depend on the same fundamentals: one canonical URL per piece of content, reachable, on a host you own. If you are weighing whether to do any of this yourself, working with a SaaS SEO consultant covers where outside help earns its cost and where it does not, and LLM SEO covers the measurement side.

FAQ

Are subdomains bad for SEO?

No, and Google has said so repeatedly. There is no documented penalty for a subdomain and no documented bonus for a subfolder. What is documented is that a subdomain is a different host, so robots rules, sitemap scope and Search Console properties all split along that line. The cost of a subdomain is operational, not algorithmic, and it is a cost you pay by forgetting something rather than by being penalised.

What is the difference between a URL and a subdomain?

A URL is the whole address of a page. A subdomain is one part of it: the label before your registered domain name, so in https://blog.example.com/posts/hello the subdomain is blog, the registered domain is example.com, and /posts/hello is the path. Browsers and crawlers treat a different subdomain as a different host, which is why the split matters. A different path on the same host is the same site by every mechanical definition.

When should I use a subdomain?

Use one when the content is genuinely a separate site: a status page, a vendor-run help desk, a staging environment, or a locale that needs its own server location. Google's multi-regional guidance lists "Easy separation of sites" as the subdomain advantage and "Separation of sites harder" as the subdirectory disadvantage, which is the honest way to frame the choice. If you want the content coupled to your main domain, and a blog usually should be, use a path.

Do I need a separate Search Console property for a subdomain?

Yes, unless you use a Domain property. Search Console defines a Domain property as one that "Includes all subdomains (m, www, and so on) and multiple protocols", while a URL-prefix property "Includes only URLs with the specified prefix, including the protocol". A URL-prefix property for https://example.com/ reports nothing about blog.example.com. Adding a Domain property requires a DNS TXT record and solves it for every current and future subdomain at once.

Does a subdomain need its own robots.txt and sitemap?

Yes to robots.txt, effectively yes to the sitemap. Google's specification states that "A robots.txt on a subdomain is only valid for that subdomain", so the main domain's file governs nothing there. For sitemaps, a sitemap "affects only descendants of the parent directory" unless submitted through Search Console, and cross-site sitemaps require that "for each individual site, make sure that the robots.txt file references the sitemap for that individual site".

Will moving my blog from a subdomain to a subfolder lose traffic?

Some fluctuation is expected and Google says so directly: "the visibility of your content in Search may fluctuate temporarily during the move. This is normal and a site's rankings will settle down over time." What determines whether it recovers is procedure: one-to-one 301 redirects rather than a blanket redirect to the index, a Change of Address submission because the host is changing, the new sitemap submitted, and the redirects left in place for at least a year. No one can guarantee the outcome of a migration, so keep the content identical during the move so that any change you see has exactly one possible cause.