Subdomain vs Subdirectory: blog.example.com or example.com/blog?
Should your blog, docs or app live on a subdomain (app.example.com) or a subdirectory (example.com/app)? The technical differences, what it means for SEO, cookies and hosting, and sensible defaults for a small product.
When you add a blog, documentation or the app itself to your website, you have to decide where it lives:
- Subdomain:
blog.example.com,app.example.com,docs.example.com - Subdirectory (or subfolder):
example.com/blog,example.com/app,example.com/docs
Both work. They differ in how they're set up, how they're hosted, and — arguably — how search engines treat them.
What each one is
A subdomain is a separate name in front of your domain. It's set up in DNS, so it can point to an entirely different server:
| Type | Name | Value |
|---|---|---|
| A | @ |
your marketing site's server |
| CNAME | app |
your app's host |
| CNAME | blog |
your blog platform |
(See DNS records explained.)
A subdirectory is a path on the same domain. It's handled by whichever server answers for example.com, which then serves or forwards /blog requests. (Anatomy of a URL shows where each part sits.)
The hosting difference
Subdomains are easy to split across services. Your marketing site on one host, your app on another, your docs on a docs platform — each just needs a DNS record.
Subdirectories need one front door. If the blog is a different system from the main site, the main site's server (or a reverse proxy) has to route /blog/* to it. That's very doable, but it's an extra piece to configure and maintain.
The SEO question
This is where most of the debate is. Google has said it can handle both and that you should choose whatever works best for you technically. In practice, many SEO practitioners prefer subdirectories for content — blogs, guides, docs — on the reasoning that links and authority earned by the content then clearly benefit the main domain, while a subdomain can be treated more like a separate site.
The evidence is mixed and the effect, if any, is modest compared with simply writing useful content. A reasonable default:
- Content you want to rank (blog, guides, landing pages): subdirectory, if it's practical.
- Things that don't need to rank (the logged-in app, status page, admin): subdomain.
Cookies and security
Subdomains are separate origins, which matters for logins:
- A cookie set by
app.example.comisn't sent toexample.comby default. To share a login across subdomains, the cookie has to be set for.example.comdeliberately — and then every subdomain receives it, including any you host on third-party platforms. - Keeping the app on its own subdomain isolates its cookies from your marketing site's scripts, analytics and widgets — a security benefit.
(Cookies explained covers the Domain attribute.)
Browser storage (localStorage) and same-origin rules also treat subdomains as different sites, which affects CORS when your frontend and API are on different subdomains.
Sensible defaults for a small product
| What | Where | Why |
|---|---|---|
| Marketing site | example.com |
Your main brand |
| Blog, guides | example.com/blog |
Content that should build the main domain |
| Docs | example.com/docs or docs.example.com |
Subdirectory if they drive search traffic; subdomain if a docs platform makes that much easier |
| The app itself | app.example.com |
Separate hosting, isolated cookies, doesn't need to rank |
| API | api.example.com or example.com/api |
Either; same-origin avoids CORS |
| Status page | status.example.com |
Must stay up even if your main site is down |
Changing later
You can move between the two, but it's work: set up 301 redirects from every old URL to its new one, update internal links and your sitemap, and expect search traffic to wobble for a few weeks. Choosing well at the start saves that.
The summary
- Subdomains (
blog.example.com) are set up in DNS and easy to host separately. - Subdirectories (
example.com/blog) share the main domain and need routing on one server. - Many prefer subdirectories for content that should rank; subdomains suit apps and tools.
- Subdomains isolate cookies — good for the app, something to plan for if you share logins.
EasySpawn lets you connect your own domain and subdomains to each project with automatic SSL — app.yourdomain.com for the app, your root domain for the site, all on one server if you like. See how it works or join the waitlist.
Related: What Is a Domain Name? · How to Connect a Custom Domain to Your App · www vs non-www · SEO Basics for Your App
Keep reading
Cloudflare Proxied vs DNS Only: The Orange Cloud Explained
In Cloudflare's DNS settings, the orange cloud sends traffic through Cloudflare and the grey cloud doesn't. What changes with each, which records must be grey, the SSL modes that avoid redirect loops, and how proxying interacts with your host's automatic SSL.
www vs non-www: Which Should Your Website Use?
example.com or www.example.com? What the difference actually is, why it doesn't matter for SEO as long as you pick one, how to redirect the other, the DNS catch with root domains, and the cookie consideration that makes some teams choose www.