Subdomains vs Subfolders for SEO

Direct answer: Google says it has no indexing or ranking preference between subdomains and subfolders. Use a subfolder when the section belongs to the same audience, brand, navigation, editorial system, and measurement model as the main site. Use a subdomain when the section genuinely needs a separate operational boundary, such as independent ownership, security, deployment, platform constraints, or site identity. A different CMS alone is not enough. Do not move established URLs between them only to chase a presumed authority boost.

This guide decides whether content belongs inside one site boundary or on a separately managed host. It does not choose between static and dynamic publishing, design individual slugs, or execute a migration. Those jobs belong in the website architecture comparison, the SEO-friendly URL guide, and the site migration checklist.

The decision in one table

The default is not a universal SEO rule. It is a cost-of-coordination rule. Keep one site together when the work is genuinely shared. Split it when independent ownership is valuable enough to justify separate controls and migration responsibility.

Why SEOs still debate this

A team may move a blog from a subdomain into a subfolder and see traffic grow. That before-and-after result can be real without proving that the folder itself received an inherent ranking advantage. The migration may also improve internal links, navigation, crawl paths, templates, content maintenance, canonicals, page speed, and how closely the section is integrated with the main site.

To identify the cause, compare what changed besides the hostname and path. A successful migration is evidence that the new implementation worked better as a system. It is not evidence that every subdomain should move, especially when Google's explicit guidance still says it has no indexing or ranking preference between the two structures.

1. Decide whether this is one site or two operating systems

Start with the reader and business relationship. A resource section that explains the same services to the same customers is normally part of the main site. A customer application with authenticated workflows, a separate product team, and different uptime requirements may be a separate operating system even when it uses the same brand.

Write a one-sentence page job for the proposed section and answer:

• Does it serve the same audience and conversion journey?
• Should visitors perceive it as the same site or a distinct product?
• Will the main navigation and related content link to it routinely?
• Does it use the same editorial standards, legal policies, design system, and support process?
• Would a separate site name in search help users understand the source?

Google can show site names for domains and subdomains, while subdirectories remain sections of a domain-level site. That does not guarantee a separate displayed name, but it makes site identity a legitimate product consideration rather than a ranking tactic.

2. Map ownership before URL structure

A subdomain creates more places where responsibility can drift. Name the owner for DNS, TLS certificates, hosting, deployments, monitoring, access, templates, content review, redirects, robots rules, sitemaps, Search Console, analytics, incident response, and eventual retirement.

If nobody owns the additional controls, the subdomain is not independence. It is unmanaged duplication. A subfolder can also hide ownership problems, but it normally keeps fewer infrastructure surfaces in play.

3. Compare publishing and browser boundaries

A subfolder can still run on a different application through a reverse proxy, edge worker, or routing layer. A subdomain can still share a CMS and design system with the main site. The visible URL does not dictate the backend, so compare the complete delivery path rather than assuming one structure fixes platform limitations.

Subdomains are different browser origins because the hostname changes. That can affect authenticated requests, cross-origin resource sharing, embedded tools, storage, and how cookies are scoped. This separation may be desirable for an application or risky surface. It also adds integration work when navigation, forms, personalization, or account state must cross the boundary.

Use a prototype with the intended production topology. Test login handoffs, forms, consent behavior, shared assets, fonts, canonical output, response headers, and failure states. A vendor demo on its default hostname does not prove the branded subdomain will behave correctly.

4. Model crawling, links, and measurement

Google's crawling and indexing FAQ says to choose whichever structure is easiest to organize and manage because Google has no preference for indexing or ranking. This does not make implementation irrelevant. Pages still need crawlable links, useful content, stable responses, consistent canonicals, and accurate sitemap entries.

• Internal discovery: link to important pages in context with normal crawlable anchors, regardless of host.
• Navigation: preserve a coherent way back to the main site and into relevant commercial or support routes.
• Robots: Google applies a robots.txt file only to the protocol, host, and port where it is served. Main-site rules do not automatically govern a subdomain.
• Sitemaps: keep canonical URLs accurate. Cross-site sitemap submission is possible when ownership of all included sites is verified, but separate inventories can make ownership and monitoring clearer.
• Search Console: a Domain property aggregates subdomains and protocols. URL-prefix properties can isolate a specific subdomain or path when the team needs a focused view.

Do not describe a subdomain as either completely unrelated or automatically equal to a folder. Google can crawl and rank both. Your actual link graph, site identity, content quality, and operational consistency determine how usable the architecture is.

5. Apply the boundary to common cases

Blog or learning center

Prefer a subfolder when the content supports the same products, services, authors, and conversion journey. Use a subdomain when a genuinely separate publication has its own audience, editorial leadership, brand identity, and release system. A different CMS alone is not decisive because routing can sometimes preserve a subfolder.

Help center or documentation

A subfolder keeps documentation close to the product site and can simplify the journey from explanation to action. A subdomain is defensible when a documentation platform, release cadence, versioning model, or technical owner is separate. In either case, maintain contextual links between product pages and the exact help articles users need.

Store, marketplace, or regional site

Keep the store in a subfolder when it is one part of the same brand and customer journey. Use a subdomain when commerce infrastructure, legal operation, catalog ownership, or availability rules require a separately managed property. For international content, Google supports multiple URL structures. Language-specific URLs, accurate localized content, and hreflang implementation matter more than a presumed subdomain advantage.

Customer application or account portal

A subdomain often matches a separate application, authentication boundary, deployment process, and support owner. Most private account pages should not become search landing pages. Keep public marketing and documentation decisions separate from authenticated application routing.

6. Prove the design before you move anything

Build a representative proof before changing established URLs. Include a homepage or section root, one article or document, one conversion page, one error route, and one page with shared navigation. Record the expected host, path, status, canonical, robots rule, sitemap source, owner, and Search Console view for each.

Section purpose:
Audience and site identity:
Preferred structure: SUBFOLDER / SUBDOMAIN
Content owner:
Platform and deployment owner:
DNS, TLS, robots, sitemap, and Search Console owner:
Shared navigation and inlink sources:
Failure and rollback plan:
Existing URLs affected: YES / NO
Decision date and reviewer:

If the proof requires fragile rewriting, duplicated templates, manual cross-posting, or an owner who does not control the platform, record that cost before approval. The cleanest-looking URL is not the best architecture when nobody can operate it reliably.

7. Treat an existing structure change as a migration

Moving from resources.example.com/page to example.com/resources/page, or the reverse, changes every affected URL. Google processes site moves per URL and warns that visibility can fluctuate while old and new URLs are recrawled and reindexed. A permanent redirect can transfer signals, but it does not remove implementation risk.

1. Inventory the current URLs, traffic, links, canonicals, robots rules, sitemaps, and templates.
2. Create a one-to-one old-to-new map with relevant final destinations.
3. Test the new host or path, including capacity, rendering, forms, structured data, and mobile output.
4. Implement direct permanent redirects and update internal links, canonicals, hreflang, sitemaps, feeds, and campaigns.
5. Verify the relevant Search Console properties and monitor both old and new URL sets.
6. Keep redirects for as long as practical, generally at least a year according to Google's site-move guidance.

Change one major variable at a time. Do not combine the host move with a redesign, CMS replacement, content purge, and measurement rewrite if you need to diagnose the result.

What not to do

• Do not split content to create more ranking opportunities. Create distinct page jobs, not duplicate site sections.
• Do not move a healthy subdomain into a folder only for “authority consolidation.” Google does not state a ranking preference.
• Do not use a subdomain to avoid fixing weak navigation. Important content still needs useful discovery paths.
• Do not publish the same content on both structures with self-canonicals. Choose one preferred URL and consolidate duplicates.
• Do not assume the main robots.txt covers subdomains. Validate the file on every relevant host.
• Do not monitor only one URL-prefix property. Use a Domain property for the combined view and focused properties or filters where owners need them.
• Do not let a temporary platform constraint become a permanent boundary without an exit plan.

Verification checklist

• The chosen structure reflects a documented audience, ownership, platform, or security boundary.
• Every production host has correct DNS, TLS, status, robots, canonical, and sitemap behavior.
• Important pages have crawlable contextual links from the relevant site journey.
• Navigation, design, legal copy, forms, and consent behavior remain coherent across the boundary.
• Search Console includes an aggregate Domain property and any focused views the owners need.
• Analytics and conversion reporting can separate the section without losing the complete journey.
• Any changed URL has a tested direct redirect and a post-launch monitoring owner.
• The team can roll back the release without losing content, redirects, or verification.

The durable choice is the one your team can publish, secure, measure, link, migrate, and retire correctly. Structure follows ownership. It does not manufacture ranking value by itself.

Evidence basis

Google Search Central, Search Console, and browser-origin documentation were checked on August 30, 2026. The ownership map, common-case decisions, and proof record are FloxoLab implementation frameworks.

• Google Search Central: no indexing or ranking preference between subfolders and subdomains
• Google Search Central: choose the structure that makes sense for the business
• Google Search Central: managing multi-regional and multilingual sites
• Google Search Console Help: Domain and URL-prefix property coverage
• Google crawling documentation: robots.txt host, protocol, and port scope
• Google Search Central: sitemap location and cross-site submission
• Google Search Central: site moves with URL changes
• Google Search Central: site names at domain and subdomain level
• MDN: browser origins use scheme, hostname, and port