Because the choice looks small and turns out to be permanent. Putting your blog at blog.yoursite.com or at yoursite.com/blog takes the same five minutes today. Changing it two years later means redirects, ranking risk, and weeks of waiting. The decision deserves more thought than it usually gets.
We get asked this on nearly every build. A founder has a marketing site on Webflow and a blog somewhere else, or a product team wants the blog on its own platform so nobody touches the main site. Both are fair reasons. Neither is an SEO reason, and that is the part people miss.
So here is our position up front. Use a subfolder unless you have a hard technical reason you cannot. The rest of this article explains what Google actually says, where the real differences live, and what a move costs if you get it wrong the first time.
A subdomain sits in front of your domain, like blog.yoursite.com. A subfolder sits after it, like yoursite.com/blog. A subdomain can point to a completely different server and platform. A subfolder normally lives on the same site and the same hosting. That single structural fact drives everything else.
The technical setup differs too. A subdomain is created in your DNS records, usually as a CNAME or A record at your registrar or at a provider like Cloudflare. You can point blog.yoursite.com at Webflow while yoursite.com runs on something else entirely. That flexibility is exactly why teams reach for it.
A subfolder has no DNS record of its own. It is just a path on your existing site. If you want your blog at yoursite.com/blog while your marketing site runs elsewhere, you need a reverse proxy or a rewrite rule to make one server serve both. That is real engineering work, and it is the honest cost of the subfolder route.
Google has said for years that both are fine. Matt Cutts called them roughly equivalent in 2012, and John Mueller repeated in 2017 that Google web search is fine with either, both quoted in Ahrefs' analysis by Patrick Stox. Google has never published a ranking penalty for subdomains. That part of the debate is settled.
What Google has not said is that the two are identical in every system it runs. Google Search Central's own documentation on URL structure spends its guidance on readable words, on using hyphens instead of underscores to separate words, and on country-specific subdirectories like example.com/de/ for geotargeting. It does not tell you to avoid subdomains.
The clearest official signal is elsewhere. Google Search Central's spam policies describe site reputation abuse as third-party content published on a host site mainly because of that host's already established ranking signals. The same policy page lists policy circumvention, which includes using existing or creating new subdomains, subdirectories, or sites with the intention of continuing to violate the policies. Google clearly thinks about domain structure. It just does not rank on it.
Subfolders win because they reduce work, not because they carry magic ranking power. One site means one set of technical decisions, one crawl path, one internal linking graph, and one place to fix things. Every problem you solve on the main site is solved for the blog at the same time.
Think about what a blog needs to rank. It needs internal links from pages that already have authority, and it needs to be reachable from your navigation. When the blog is a folder on the same site, your homepage, services pages, and case studies link to it naturally, and those links are internal. When the blog is a subdomain, the same links are technically external. Google may well figure out the relationship, but you are asking it to infer something you could just state.
The maintenance argument is stronger than the ranking one. On a subdomain you run two of everything: two analytics setups, two schema implementations, two performance budgets, two security reviews. Across the 150 or more projects we have delivered, the sites that stay fast are the ones with fewer moving parts. Our average PageSpeed score across projects sits at 98, and that number is easier to protect on one codebase than on two. If you want the wider picture on how paths and naming affect crawling, we covered it in our guide to URL structure and SEO.
A subdomain makes sense when the content is genuinely a separate product, when a different team owns it, or when a reverse proxy is not realistic. Documentation sites, status pages, app logins, and help centres all sit fine on subdomains. The test is simple: would a visitor be surprised that this is the same company?
Help centres are the clearest case. If you run support on Zendesk or Intercom, those platforms hand you a subdomain and the alternative is a fragile proxy setup. The same goes for status pages and for an app that lives at app.yoursite.com. Nobody expects your login screen to rank in Google, so the SEO argument does not apply.
Documentation is the interesting middle case. Docs often rank well and often bring in exactly the technical buyer you want. If your docs can live on the main domain without breaking your deploy pipeline, put them there. If moving them means rebuilding a whole publishing workflow, the subdomain is the right trade. Be honest about which situation you are actually in rather than reaching for the SEO argument to justify a decision you made for other reasons.
It changes what one property covers. Google Search Console offers three property types. A Domain property includes all subdomains and multiple protocols. A URL-prefix property includes only URLs with the specified prefix and does not pick up subdomains. So a subdomain blog needs its own property unless you set up a Domain property.
This matters more than it sounds. If your team set up a URL-prefix property for https://yoursite.com and then launched a blog on a subdomain, none of that blog's data appears in your reports. Impressions, clicks, and coverage errors all go somewhere you are not looking. We have seen teams believe their blog was not indexed when it was simply reporting to a property nobody had opened.
The fix is to verify a Domain property, which requires a DNS record rather than an HTML file or tag. It is worth doing regardless of which structure you pick, because it gives you one view of everything on the domain. Our walkthrough of how to actually use Google Search Console covers the verification steps and the reports that matter.
It involves a full site move with URL changes, which is one of the higher risk projects in web work. Every old URL needs a 301 redirect to its new location. Internal links need updating. Sitemaps need regenerating. Analytics and Search Console need reconnecting. None of it is exotic, but all of it has to be right.
The redirect map is where these projects succeed or fail. You need every published URL on the old subdomain mapped one to one to its new path, not bulk redirected to the new blog homepage. A crawler like Screaming Frog or the site audit in Semrush will give you the full inventory. Skipping this step is the single most common way a migration loses traffic.
Google's own guidance on site moves is blunt about the aftercare: keep the redirects for as long as possible, generally at least one year. That is not a suggestion you can quietly ignore in month three when someone wants to clean up the config. We have written a longer piece on migrating a website without losing SEO that covers the full sequence.
Expect weeks, not days. Google Search Central says a small to medium sized website can take a few weeks for most pages to move, and larger sites take longer. The move happens on a per URL basis, so you will see your traffic shift gradually rather than all at once on launch day.
This is why timing matters. Do not run a URL migration in the same week as a redesign, a rebrand, and a content overhaul. When several things change together and traffic dips, you cannot tell which change caused it. Move the URLs first, let the numbers settle, then change the content.
Set expectations honestly with whoever signs off on the project. There is usually a dip before there is a lift. On the migration work we do, the sites that come out ahead are the ones where the client understood the shape of the curve before we started, not the ones where we promised it would be smooth.
Less than people assume, but not zero. ChatGPT, Perplexity, Claude, and Google AI Overviews mostly cite pages, not domains. What they need is a page that answers the question clearly and loads cleanly. A well built subdomain gets cited. A slow subfolder does not.
Where structure does help is in entity clarity. When your blog, your case studies, and your services pages all sit on one domain, a model reading your site sees one organisation with one body of work. When they are split across hosts, that connection has to be inferred from branding and links. Making it obvious is cheap. Relying on inference is a gamble.
The bigger factor by far is whether your article HTML is actually there when a crawler arrives without running JavaScript. Many AI crawlers do not execute scripts. A blog on any structure that renders its body client side is invisible to them. That is a rendering decision, not a domain decision, and it is worth far more of your attention than the subdomain debate.
If you are starting fresh, put the blog in a subfolder and be done with it. If you already have a subdomain that ranks and a proxy setup would be genuinely painful, leave it alone and spend that effort on page speed and content instead. A migration you do badly is worse than a subdomain you keep.
The honest summary is that this decision is worth ten minutes at the start of a project and rarely worth a rebuild later. Get it right when it is free. If it is already wrong and the site is working, the bar for moving should be high. Ask what you actually gain, then ask what a bad redirect map would cost you.
If you are weighing this on a real site and want a second opinion before you commit, we are happy to walk through it. Send us the current structure and what you are trying to fix, and we will tell you honestly whether a move is worth it. You can reach us at phoenix.studio, and we usually reply within 48 hours.
Tell us where you want to go. We'll tell you how we'd get you there.