# Subdomain vs subdirectory: what Google says and what to choose

You want a clear choice, not a debate. Google says subdomains and subdirectories can rank. The right answer is about links, ownership and how you run the site.

Updated 2026-09-14 · Source: https://porteur.ai/guides/subdomain-vs-subdirectory

## The short answer

Choose a subdirectory when the content is part of the same product and audience. You keep one host and one link profile.

Use a subdomain when you truly need to separate ownership, tech, or pace. Think different team, stack, or compliance boundary.

Google says both can work. Results hinge on internal links and external links, not the word before the dot. Pick the model you can maintain well.

## How Google sees subdomains and subdirectories

A subdirectory sits under the same host: yourproduct.com/blog/. It inherits the same crawl budget, cookies and many signals that tie to the host.

A subdomain is its own host: blog.yourproduct.com. Google treats it as part of the site in most cases, but it can be seen as separate. You must prove the connection with links and consistency. There is no automatic merge of signals across hosts.

- One host, one link profile: a subdirectory concentrates PageRank from internal links into one origin.
- Separate host: a subdomain starts with thinner internal authority unless you link it well.
- Analytics, cookies and auth are simpler on one host. Cross subdomain auth needs extra work.
- Operations can trump SEO. If the blog is in a different CMS and team, a subdomain may ship faster and break less.

> Rule: if your main goal is to grow the same site’s search footprint with less friction, use a subdirectory.

## When a subdirectory is the right choice

Default to a subdirectory for content that supports the same product. It is simpler and usually earns faster if you link it well in the nav and body.

| Use a subdirectory for | Why | Example URL | Fixed page looks like |
| --- | --- | --- | --- |
| Blog and guides | Share authority and demand capture for the same product audience | yourproduct.com/blog/… | /blog/how-to-migrate-to-https with nav linking to /pricing |
| Docs and API reference | Users stay inside one host, searchers see it is the same product | yourproduct.com/docs/… | /docs/getting-started indexed and linked from /signup |
| Landing pages and comparison pages | They support conversion on the main domain | yourproduct.com/compare/… | /compare/competitor-x with internal links to /pricing |
| Help centre and legal pages | They are part of the product experience | yourproduct.com/help/… | /help/reset-password visible in the footer |

Wire it into the site. Link the section in the header or footer. Cross link from product pages to deep articles. Use breadcrumbs. Keep consistent canonicals on the same host.

## When a subdomain makes sense

Use a subdomain when the section must live on a different stack or behind a boundary. This is usually an ops call, not an SEO trick.

- A separate app or microservice: app.yourproduct.com runs on another platform and release cycle.
- Docs run in an external system that cannot live under the main app: docs.yourproduct.com.
- A partner or community area with different moderation and publishing rules: community.yourproduct.com.
- Strong security or compliance isolation: status.yourproduct.com or audit.yourproduct.com.

Make the connection explicit. Link to the subdomain from the main nav. Link back to core pages. Keep brand, design and structured data consistent where possible. Treat it as a site that must earn links too.

> Warning: do not park low quality or third party content on a subdomain to piggyback on your main site. Google’s spam policies cover site reputation abuse.

## Blogs, docs and help centres by example

Your blog supports yourproduct.com. Put it at yourproduct.com/blog/. A post ranks, passes internal authority and drives readers to /pricing. You avoid cross host cookies, user tracking and mixed origins.

API docs can live at /docs/ if your site can serve them. If your generator or vendor forces a separate host, use docs.yourproduct.com and wire the links tightly. Link from /docs/getting-started to /signup and /pricing with normal anchors. Add it to the main sitemap or keep a docs sitemap and list both in robots.txt.

A help centre is long tail. Keep it on yourproduct.com/help/ where possible. Articles like /help/connect-slack answer support queries and build topical coverage that strengthens related product pages. If you must host help.yourproduct.com on a vendor, link it in the footer and cross link back to product pages by topic, not only to the home page.

## Languages and countries: folders, subdomains or ccTLDs

For international sites, choose structure before you translate. A country code domain like example.fr is the strongest geo signal and is a separate site. A subdirectory, example.com/fr/, keeps one host and one link profile. A subdomain, fr.example.com, is usually treated as part of the site but can be seen as separate. Google says all three work. The choice is about operations and links. Do not use URL parameters for language.

- If you sell one product globally and want one domain to grow, prefer subdirectories like /fr/ and /de/.
- Pick subdomains like fr.example.com if teams, tech or legal need isolation but you still want one global brand.
- Pick ccTLDs when you run fully local sites, with local teams, prices and marketing. Treat each as a separate site to build and maintain.

Keep one language per URL. Translate titles, descriptions, slugs, alt text and structured data. Localise currency, dates and examples. Use hreflang to declare page pairs across languages, with reciprocal links, correct ISO codes and x-default where needed. Do not redirect by IP or browser language. Show a switch with real links to each language URL. Avoid scaled content abuse. Machine translation without human review is listed in Google’s spam policies as abuse at scale.

> Rule: add a new language when you already see impressions from that country, you sell there and your support can answer in that language. It is a second site’s worth of work.

## Subdomain to subdirectory, or the reverse: how to move

A move with URL changes is a site move. Plan it like any migration. Build a one to one redirect map and test it. Move one thing at a time if you can.

1. **Crawl and inventory the old host** Export every URL from your crawler, your sitemaps and Search Console. Include canonicals and hreflang targets.
2. **Design the new paths** For subdomain to subdirectory, map blog.yourproduct.com/my-post to yourproduct.com/blog/my-post. Keep the slug. Avoid removing or adding trailing slashes unless you standardise across the whole site.
3. **Build the redirect map** Two columns: old URL, new URL. No many to one. No hops. Keep it in the repository. Owners can audit it.
4. **Implement 301s** Apply at the edge or server. On nginx, use a map. In Next.js, add redirects in next.config. Test on a staging host first.
5. **Update internal signals** Update internal links, canonicals, hreflang, structured data and sitemaps to the new URLs. Publish an app/sitemap.ts update if you use Next.js.
6. **Test at scale** Run a script that requests every old URL and checks the final status is 200 with one hop. Fix soft 404s and chains before launch.
7. **Switch and monitor** Ship during a quiet period. Watch logs and Search Console. Expect some fluctuation for some weeks.

If you change domains as well, verify both properties and use the Change of Address tool in Search Console. It needs domain level moves with 301s in place. It does not apply to path only changes or HTTPS only moves. Keep redirects for at least a year, longer if you can. Keep the old sitemap listed for a while so Google recrawls the old URLs and finds the redirects.

> Warning: do not redirect all old URLs to the home page. It looks like a soft 404 pattern and you lose relevance and signals.

## Implementation notes for common stacks

Next.js App Router can handle either model. Static by default, dynamic by opt in. You choose the URLs and canonicals. The framework does not write titles or make pages valuable. That is on you.

- Redirects and rewrites live in next.config. Use 308 for permanent in Next.js, which maps to 301 at the edge on many hosts.
- Use the Metadata API for titles and canonicals: generateMetadata with alternates.canonical and metadataBase.
- If you standardise trailing slashes, set trailingSlash in next.config and align your redirects.
- For sitemaps, use app/sitemap.ts. Include the moved paths on the new host and keep the old sitemap live for a while with the old URLs that now 301.
- Self host fonts with next/font and use next/image to keep LCP healthy after the move. Avoid mixed content when you flip HTTP to HTTPS.

If you use a headless CMS for the blog, you can serve the same content under /blog/ with your app. A reverse proxy can route /blog/ to the CMS. Keep canonical URLs on your main host if the CMS also publishes a copy. Avoid duplicate content by choosing one canonical per article, not two hosts with self canonicals that conflict.

## Measurement and common pitfalls

- Verify a Domain property in Search Console. It covers www and non www and all subdomains.
- Set one canonical host. Redirect the other with 301 on every path. www and non www are different hosts to Google.
- Pick one trailing slash convention for directories. /page and /page/ are different. Redirect the other and keep links consistent.
- For HTTPS moves, 301 every URL to the HTTPS twin in one hop, update canonicals, sitemaps and hreflang, and consider HSTS.
- Track the section in your nav, breadcrumbs and internal links. If a subdomain must exist, link to it clearly and deep link into it.
- Watch the Performance report. Compare clicks and impressions before and after by page group, like prefix is yourproduct.com/blog/.
- Audit for orphan pages after a move. New URLs must be linked from somewhere useful.

A fixed page has a stable URL, a self canonical, is listed in the sitemap, and is linked from the most relevant hub. It returns 200, not 301 or 404. It gets internal links with descriptive anchors, not only brand terms. It inherits authority faster on a subdirectory because it is inside the same host that already earns links.

## Questions

### What is an example of a subdomain?

It is a host placed before the main domain. blog.yourproduct.com and docs.yourproduct.com are subdomains of yourproduct.com. www.yourproduct.com is also a subdomain. Each is a separate host to Google.

### Can a URL have two subdomains?

Yes. You can chain them, like support.eu.yourproduct.com. Keep it simple unless there is a hard reason. More levels mean more places to break links, cookies and routing.

### Do subdomains hurt SEO?

No by default. Google can rank them well. They do not automatically inherit the same internal authority as a subdirectory though. You must link them well from the main site and earn links to their pages.

### What is a subdirectory URL?

It is a path under the same host, like yourproduct.com/blog/how-we-ship. It shares the same host signals and makes internal linking, analytics and auth simpler. It is the default choice for content that supports the same product.

### Will moving from a subdomain to a subdirectory boost rankings?

Sometimes it helps because you concentrate signals on one host and simplify linking. There is no guarantee. Plan a clean one to one 301 map, update all signals, and give it weeks to settle.

### How long should I keep redirects after a move?

Keep them as long as you can, at least a year. Old links, bookmarks and slow crawls will hit them for a long time. Permanent is best when possible.

## Read next

- [International SEO for a small product: structure, language, and when to start](https://porteur.ai/guides/international-seo): Pick a structure, set one language per URL, add hreflang, and know when to expand. A short plan for founders shipping their own product site.
- [Build a redirect map: one old URL, one new URL, tested](https://porteur.ai/guides/redirect-map): A practical redirect map: where to find old URLs, how to match them, store the table, apply 301s, and test every row for one hop and a 200.
- [Website migration SEO checklist: before, during, after](https://porteur.ai/guides/website-migration-seo-checklist): Run a safe website migration: crawl and export, build and test one-to-one redirects, switch cleanly, submit sitemaps, use Search Console, and watch the data.
- [Canonical tags: what they do and the mistakes that cost rankings](https://porteur.ai/guides/canonical-tag): What a canonical tag does, when to use one, the mistakes that cost rankings, and how to check and fix canonicals on a small site.
- [Internal linking for a small site: which pages link to which](https://porteur.ai/guides/internal-linking-for-seo): Decide which pages rank. Build hubs, write clear anchors, fix orphans, and crawl your site to map links you control.
- [The Search Console performance report, column by column](https://porteur.ai/guides/search-console-performance-report): Every column in the Google Search Console performance report explained with the traps that trip small sites, and how to act on each.

Not sure which way to structure it, or how risky a move is, for your site, today? Porteur reads your URL and rivals in about thirty seconds and shows three findings free. Free check: https://porteur.ai/