Subdomain vs subfolder for a blog: which is better for SEO?

A subfolder is also called a subdirectory. Many SEOs hold that a blog in a subfolder benefits from the main domain's links while a subdomain starts from nothing, and plenty of sites have moved their blogs on that advice. The evidence is thinner than the advice.

What Google says about subdomains and subfolders

Google's crawling and indexing FAQ answers the question directly: "You should choose whatever is easiest for you to organize and manage. From an indexing and ranking perspective, Google doesn't have a preference."

Its spokespeople have said the same for over a decade. Matt Cutts, then head of webspam, called the two "roughly equivalent" in 2012, and John Mueller said in 2017, as Ahrefs quotes him: "Google websearch is fine with using either subdomains or subdirectories. Making changes to a site's URL structure tends to take a bit of time to settle down in search so I recommend picking a setup that you can keep for longer."

The belief that a subdomain counts as a separate site is incomplete rather than wrong. Ahrefs' Patrick Stox describes what happens in practice: subdomains a site treats as part of itself, mainly by linking to them, tend to be treated as part of the site, while an unlinked subdomain "may be treated as separate". The same goes for a subfolder nobody links to. Semrush reaches the same verdict from the other side: used correctly, subdomains are "fine for your SEO performance", and the choice "largely depends on reasons outside of SEO."

There is one documented difference in how results look. Google shows one site name per site, and its site names documentation defines a site "by the domain or subdomain". A blog on its own subdomain can carry its own name in results; a blog in a subfolder appears under the main site's name, because Google "does not support site names at the subdirectory level."

What blog migrations actually show

The main evidence for the subfolder rule is case studies of blogs that moved from a subdomain to a subfolder and then grew. Stox's objection is that he has not seen one "that wasn't complicated by other changes like additional internal linking or migrating multiple properties into one." His example: mention.com moved its blog from a subdomain to a subdirectory in January 2016 and he saw no difference in that period; traffic grew later, when the site added content. GitHub moved its blog twice, from github.com/blog to blog.github.com and then to github.blog, without one address proving better than another.

Check for the usual confounders before you trust a migration story:

• A blog that was barely linked from the main site became a folder linked from every page's navigation.
• Content was rewritten, merged or pruned during the move.
• Tracking changed, so "before" and "after" were measured differently.
• The comparison window crossed a busy season or a Google update.

What the stories do show is that links and content move results. That argues for whichever setup makes good internal linking the default rather than a chore.

Subdomain vs subfolder compared

	Subfolder (example.com/blog)	Subdomain (blog.example.com)
Google's ranking preference	None	None
Links to and from the main site	Usually built in: shared navigation and templates	Have to be added on purpose
Hosting	Same server or app, or a reverse proxy if the blog runs elsewhere	Can run anywhere; a DNS record points the name at the blog's host
Setup	No separate hosting account, certificate or analytics tracking	Often needs its own hosting, certificate and tracking
Reporting	One site in your reports	Combining data across hostnames can take extra settings
Site name in Google results	The main site's name	Can have its own
Design	Shares the main site's templates	Free to look and work differently
Typical use	Blogs, guides and help content that belong to the brand	Separate apps, shops on another platform, staging, some country sites

For most business blogs the table points one way. If the blog exists to win searches around your product and send readers to it, a subfolder keeps it visibly part of one site, with no linking work to remember. A subdomain is the better tool when the section is genuinely different: another platform you cannot proxy, a separate product, or a team that deploys on its own schedule. Then link it from the main navigation and from relevant pages, as you would any part of the site.

WordPress and headless setups

Where the blog can live depends mostly on the platform under it.

The whole site runs on WordPress. The blog is already a folder of the same install, so there is nothing to decide.

The main site runs on another platform and the blog on WordPress. The simple route is a subdomain pointed at the WordPress host. The subfolder route needs a reverse proxy that serves the WordPress install under example.com/blog, and WordPress must be configured with that public address, because it builds its links, canonical tags and sitemap from the address it is given. Get that wrong and the blog links to the hidden host.

The site has a headless front end. With headless WordPress or any other content API, the blog is a route in your own app, such as /blog/[slug], rendered from content the app fetches. The CMS can sit on a subdomain like cms.example.com that readers never see, and the subfolder costs nothing extra. If the blog is a separate deployment, a framework rewrite can still put it under your domain: in Next.js, rewrites "act as a URL proxy and mask the destination path", and the documentation's own example sends the /blog route of the main app to an external site. The Next.js CMS page compares the content sources such a front end can read.

How Structura handles this

Structura does not decide where your blog lives; your site does, and Structura publishes to that address. With the WordPress plugin, posts are written into the WordPress install you already run, at its permalinks. If that install is only a backend, say cms.example.com feeding a front end on example.com, the plugin's headless mode makes the internal links in new posts, channel shares and the AI's research of your site use the public domain instead of the CMS host.

With a headless space there is no blog server to place at all. Structura stores the posts and serves them from a public Content API; your front end fetches them and renders them on whatever route you choose, so a blog at example.com/blog needs no proxy and no subdomain. The links inside each post and the URLs in its structured data use your public domain. Before launch, check that the post address shown in the customer portal matches the route your front end serves.

Structura does not run a proxy, move an existing blog, or set up the redirects a move needs; those stay with your host or developer. The API-first CMS page shows how a front end reads the posts.

FAQ