Subdomain vs Subfolder: Where Your Blog and Second Brand Should Live
Published 2026-09-11 · Updated 2026-09-11 · 7 min read · AI 工作術 (FreeCo Co., Ltd.)
Subfolder or subdomain for your blog, docs, or second brand? Here's the default we use, the exceptions that justify a subdomain, and a 3-question checklist.
If you're about to launch a blog, a help center, a campaign site, or a second product line, you'll hit the same question every site owner hits: put it on a subdomain (blog.example.com) or in a subfolder (example.com/blog)? Short answer: use the subfolder unless you have a specific, concrete reason not to. Nine times out of ten, that's the right call.
It looks like a cosmetic decision about how the URL reads. It isn't. It decides whether the search authority you earn from new content pools with your main domain or gets built up somewhat separately. It also decides how many certificates, analytics properties, and tracking configurations your team will be babysitting for the next five years.
We run our own AI tool platform, and everything that supports the main brand lives in subfolders: the learning articles you're reading now, the video clipping engine, the ads tooling. We'll walk through why we made that call, and then cover the handful of cases where we'd tell you to do the opposite.
What Google Says vs. What Actually Happens
Let's get the official position right first. Google has said repeatedly that content on subdomains and subfolders both get crawled, indexed, and ranked normally. There's no systematic penalty for one or bonus for the other. "Use whichever works for you" is the line. That statement is true. But notice what it answers: "can this rank?" It does not answer "which one compounds faster?"
In practice, search engines sometimes treat a subdomain as a relatively independent site. Your main domain has spent years building content depth and inbound link trust. New content in a subfolder inherits that accumulated trust on day one. Content on a fresh subdomain may need to build its own signals over time. Plenty of site owners have published case studies showing traffic growth after moving a blog from a subdomain into a subfolder. Those are individual experiences, not a Google-certified rule, but the reports point in the same direction often enough that you should weigh them.
A subfolder deposits new content into the same account. A subdomain opens a second account. It's all your money, but the interest compounds separately.
There's a newer angle too. AI answer engines cite sources by domain, and a recognizable domain gets picked more often than a stranger. If you care about showing up in AI-generated answers, consolidating your brand's footprint under one domain helps. We cover that side of the picture in our explainer on generative engine optimization.
Why Subfolder Is the Default
- Authority pools in one place. Search traffic and backlinks your blog posts earn flow straight into the main domain, and your product and service pages benefit. It works in reverse too: your main site's existing trust helps new articles rank faster than they would on a cold subdomain.
- One stack to operate. One website, one TLS certificate, one analytics property, one Search Console profile. You never have to stitch data across properties or debug cross-domain attribution. Cross-domain tracking is the kind of thing that works until someone changes the consent banner, and then your conversion data quietly breaks for a month.
- Internal linking is native. Articles link to product pages, product pages link back to related articles, and all of it is same-site linking, which is the most direct way authority moves around.
- One sitemap, one robots file, one llms.txt. Every file that tells crawlers and AI engines how to read your site only has to be written and maintained once. If you haven't set up the last one yet, see our llms.txt guide.
Typical cases where subfolder wins with no debate: company blog, knowledge base, case studies, campaign landing pages, and tool pages. If the content exists to support the main brand's search performance, it belongs in a subfolder.
Concrete example from our side: we could have shipped the clipping tool on its own subdomain with its own deploy pipeline. We didn't. Every how-to article about cutting long videos into short clips links to the tool page on the same domain, and the tool page links back to the articles. That loop is why the tool pages rank for terms we never explicitly targeted.
When a Subdomain Is the Right Call
- The tech stack is genuinely different. Your main site is custom-built, but your store runs on a hosted commerce platform and your courses run on a third-party learning system. Getting two vendor-hosted systems to share one domain path is often impossible or fragile. shop.example.com is the pragmatic answer.
- You're deliberately separating brands. If you run multiple brands or product lines that shouldn't be associated with each other, or that have independent teams and independent positioning, a subdomain draws a clean boundary. Sometimes a separate domain altogether is even cleaner.
- The purpose is wildly different from the main site. Developer documentation, a system status page, a support ticketing portal. This content doesn't need to compete for your main keywords, and separation keeps things tidy. A status page specifically should live on separate infrastructure so it stays up when your main site goes down.
- Language or regional sites. fr.example.com is a common pattern. So is example.com/fr/. Both are supported by search engines. We went with the subfolder approach for our English content because it's one platform run by one team, and splitting it would have doubled our operational surface for no gain.
Now the "don't do this" part. Don't pick a subdomain because it "feels more professional," and don't pick one because a developer wants a separate deploy pipeline. A separate codebase can sit behind a subfolder using reverse proxy routing at the edge. That's an engineering preference, not an architecture reason, and it shouldn't cost you years of consolidated authority.
Already on a Subdomain? Should You Move?
If your blog has lived on a subdomain for years and has stable traffic, don't uproot it for a theoretical gain. A migration carries real risk and real cost, and the upside is uncertain. Moving is worth it when the subdomain is young, when traffic is small, or when you're already planning a redesign and the move rides along for free.
If you do move, follow the standard migration playbook without shortcuts. Redirect every old URL with a 301 to its exact new counterpart, not to the homepage. Update internal links, canonical tags, and the sitemap. Then watch index coverage in Search Console for several weeks. Expect a temporary dip, usually a few weeks, before things recover and, ideally, climb.
Here's the thing most people get wrong: it's not the subfolder that rescues or ruins rankings. It's the redirect work. A sloppy migration where half the old URLs 404 or everything gets blanket-redirected to the homepage is what actually destroys years of search equity. If you can't commit to doing the redirects properly, don't move yet.
One more honest note. If the content on your subdomain isn't ranking because it's thin or generic, moving it into a subfolder won't fix that. Structure amplifies good content. It doesn't create it.
The Three-Question Checklist
Compress the whole decision into three questions:
- Is the purpose of this content to earn search traffic for the main brand? Yes → subfolder.
- Can it technically live on the same domain as the main site? Yes → subfolder.
- Does the brand need to be deliberately separated? Yes → subdomain.
Answer those three and roughly ninety percent of situations resolve themselves. The remaining ten percent are the messy ones: multiple brands, multiple vendor systems, and a desire to keep authority consolidated anyway. That's exactly the kind of decision to make on paper before anyone writes code. Changing it later isn't a config tweak. It's a migration project with all the risk described above.
Our own rule of thumb after running a multi-tool platform: default to subfolders, tolerate a subdomain only when a vendor forces it, and never let a URL decision be made by whoever happens to be setting up the hosting that afternoon. You can see how this plays out across our full tool lineup, where every tool page shares one domain, one sitemap, and one pool of authority.
FAQ
Q: Does Google penalize subdomains?
No. Google has stated that subdomains and subfolders are both crawled, indexed, and ranked normally. The practical difference is that a subdomain may be treated as a relatively separate site, so it can take longer to build up its own authority instead of inheriting the main domain's.
Q: Is a subdomain a separate website for SEO purposes?
Sometimes, partially. Search engines don't publish a hard rule, but real-world results suggest subdomains often have to earn trust on their own rather than fully sharing the parent domain's. Treat it as "separate-ish" and plan accordingly.
Q: Should I move my blog from a subdomain to a subfolder?
Only if the blog is young, the traffic is modest, or you're already doing a redesign. A mature blog with stable traffic shouldn't be moved for theoretical gains. If you do move, redirect every URL one-to-one with 301s and monitor Search Console for weeks.
Q: Can I use a subfolder if my blog runs on a different platform than my main site?
Often yes. A reverse proxy at your edge or CDN can route example.com/blog to a separate backend. It takes some setup, and some hosted platforms make it painful, but it's usually possible. If the vendor truly blocks it, a subdomain is the reasonable fallback.
Q: What about country or language versions of my site?
Both fr.example.com and example.com/fr/ work and both are supported by search engines. Subfolders are simpler to operate if one team runs everything. Subdomains or separate country domains make more sense when regional teams run their own sites with their own infrastructure.