Subdomain vs subdirectory: what Google says and what to choose

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.

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.

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.

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.

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.

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.

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.

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. 1

   Crawl and inventory the old host

   Export every URL from your crawler, your sitemaps and Search Console. Include canonicals and hreflang targets.

2. 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. 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. 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. 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. 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. 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.

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.

• 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.