Should Location Pages Use Subfolders or Subdomains?

Google publishes exactly one documented difference between these two options, and it is not about ranking. From the site names documentation, last updated December 10, 2025: "Google Search only supports one site name per site, where a site is defined by the domain or subdomain." A subdomain can carry its own site name in Search results. A subfolder cannot. That is the whole published distinction.

Everything else is governance. A franchise group inherits three website patterns after a few years of growth: corporate locations at example.com/locations/phoenix, one franchisee at phoenix.example.com, and an acquired operator still holding phoenixplumbing.com. All three get crawled. That does not make all three equally maintainable.

The practical decision is not whether Google likes a slash more than a dot. It is whether the URL boundary matches who controls the brand, content, software, analytics, local proof, and future migrations. For most multi-location service brands with shared governance, subfolders are the cleanest default. Subdomains and separate domains are defensible when they represent a real operating boundary.

For a 20- to 500-location HVAC, plumbing, pest control, restoration, garage door, med spa, or franchise service brand, the wrong architecture creates slow operational damage. New locations launch on inconsistent templates. Google Business Profiles point to generic or obsolete URLs. Regional teams cannot see the same Search Console data. A later consolidation becomes a portfolio-wide site move.

If the goal is a repeatable branch-page system, multi-location local SEO software should connect the page, profile, review, and measurement owners before the URL format is locked.

The short answer

• Use subfolders by default when locations share one brand, CMS, templates, security team, analytics program, internal-link system, and publishing process.
• Use subdomains for a real boundary when a region or operator has separate software, permissions, releases, or site ownership and can maintain a complete local experience.
• Keep separate domains for distinct operating identities when an acquired or franchised brand remains meaningfully independent and has the resources to run a full website rather than a thin local copy.

This is a governance rule, not a ranking formula. Google recommends simple, descriptive URL structures and consistent organization. Its AI features guidance points back to the same Search fundamentals: crawlable pages, useful text, internal links, structured data that matches visible content, and current Business Profile information. There is no special location-page architecture required for AI Overviews or AI Mode.

Google does not publish a subfolder ranking rule

Claims that subfolders automatically inherit more authority than subdomains are common in agency decks. Google's current documentation does not give franchise brands that guarantee.

Google's URL structure guidance asks for simple, descriptive, logical URLs. Its crawlable link guidance explains that normal links help Google discover pages and understand their relationship. Neither document declares a universal winner between a branch path and a branch subdomain.

There is one visible search distinction worth knowing, and it cuts both ways. Google's site name documentation says: "Google Search only supports one site name per site, where a site is defined by the domain or subdomain." A subdomain can therefore present as a separate site. That is useful when the franchisee genuinely is a separate operation, and it is a reason to avoid subdomains when the location is not supposed to look or operate like a separate website.

The better evaluation is concrete. Can customers and crawlers reach every branch through normal links? Does each location have one stable canonical URL? Can corporate and local owners keep facts current? Will a rebrand require one controlled migration or dozens of separate projects?

Use subfolders when the brand runs one operating system

A shared brand usually benefits from a shared publishing boundary. An HVAC roll-up can keep Dallas at example.com/locations/dallas and Tampa at example.com/locations/tampa while using the same location schema, service taxonomy, accessibility standards, security patches, and analytics events.

This does not mean every page should be identical. The location page checklist for multi-location service brands still requires branch-specific services, coverage, hours, phone routing, reviews, photos, credentials, and local proof. A shared folder structure should make those differences easier to govern, not hide them inside cloned copy.

Subfolders also make the browse path easy to explain. A crawlable directory can link to state or region hubs and then to branch pages. Service pages can link to the locations that actually offer the service. The location finder architecture guide covers how to expose those pages without indexing every map state or ZIP-code result.

For marketing leaders, the benefit is fewer systems to reconcile. One change to the branch template can improve phone labels, schema, breadcrumbs, or conversion tracking across the portfolio. Operations still owns local accuracy, but the software and publishing controls remain visible to the brand.

A subdomain should represent a real boundary

A subdomain can be the right choice when the separation already exists in the operating model. A regional franchisee may run a different CMS, employ its own development team, control releases, and maintain the local service catalog. A hospitality group may operate booking and content systems that cannot safely share the parent site's deployment process.

The test is whether the operator can maintain a site, not just a page. The subdomain needs its own crawlable navigation, local content, canonical controls, sitemap coverage, structured data, security ownership, accessibility review, analytics, and incident response. Corporate still needs a normal link path from the main domain and a clear record of who owns each public fact.

Search Console should follow that boundary. Google's property documentation says a Domain property includes all protocols, subdomains, and paths for a domain. A URL-prefix property can isolate a specific subdomain or folder. Corporate can keep portfolio visibility through the Domain property while granting a regional operator narrower access through a URL-prefix property.

Do not reverse that logic. A reporting preference is not a reason to split the public site. Search Console can report on a folder without moving it to a subdomain.

Keep separate domains only for a distinct identity

Separate domains make sense when an acquired company or franchisee remains a distinct public brand with its own customer promise, leadership, content, and operating responsibility. A home-service roll-up may deliberately preserve a trusted local brand for several years. A med-spa franchisee may own a mature local site that serves more than one business line.

The cost is independence. Each domain needs enough useful content and local proof to stand on its own. It needs security updates, consent and analytics controls, internal links, sitemaps, structured data, profile targets, and an accountable owner. A five-page domain that copies corporate service text and sends every lead to the same national form is not meaningful local independence.

If the brand later consolidates those domains, treat the work as a migration. Google's site move guidance calls for an old-to-new URL map, permanent server-side redirects, updated internal links and canonicals, submitted sitemaps, and monitoring of both properties. Redirecting every old page to the new homepage discards the branch and service relationships customers were using.

The roll-up rebrand workflow extends that migration beyond the website. Google Business Profiles, citations, review destinations, phone routes, booking links, and former-name context need to move by market.

Every structure still needs one canonical branch URL

Subfolders do not rescue a weak location system. Subdomains do not create local relevance. Separate domains do not substitute for proof.

Every real branch needs one URL that the organization treats as primary. The location finder, service pages, XML sitemap, LocalBusiness structured data, and Google Business Profile website field should reinforce that same destination. Alternate campaign or tracking URLs should resolve cleanly to it rather than compete with it.

Google's canonical guidance ranks the signals in order of how strongly they influence canonicalization. Redirects are "a strong signal that the target of the redirect should become canonical". A rel="canonical" annotation is "a strong signal that the specified URL should become canonical". Sitemap inclusion is "a weak signal that helps the URLs that are included in a sitemap become canonical". Those signals work best when they agree. A page that declares one canonical while the locator, sitemap, and Business Profile point somewhere else creates a preventable conflict, and the sitemap is the weakest place to fight it.

The branch page should also use the most accurate LocalBusiness structured data that the visible content supports. Schema should confirm the public name, URL, address or service area, hours, phone path, and relationship to the parent organization. It should not invent a storefront for a service-area business or use a parent-company address for every franchisee.

What the portfolio data suggests, and what it does not

Cheers can measure one adjacent thing here, and it is worth reading carefully. In the home-services panel over the 28 days ending September 2, 2026, aggregate only, organizations with no more than one child location appeared in 27.5% of their tracked runs on average and were cited in 22.6%. Organizations with two to five child locations appeared in 23.2% and were cited in 17.7%. The buckets above five child locations held three and four organizations, below the ten-organization publishing floor, so they are suppressed and not reported here.

Two caveats before anyone quotes that as an architecture finding. It measures organizations, not URL patterns, and Cheers does not track whether each one used subfolders, subdomains, or separate domains. What it does support is the operating premise of this article: adding locations does not automatically add visibility, and the gap between appearing and being cited widens as a portfolio grows. Definitions and the suppression rule are in the Cheers Research methodology.

Audit ownership before changing URLs

Before choosing a new pattern, build an inventory that can survive implementation. For every active location, record:

• Current public URL, canonical URL, indexation state, and sitemap source
• Parent brand, local operator, CMS owner, release owner, and security owner
• Google Business Profile website target, booking target, phone route, and primary location ID
• Search Console property, analytics property, consent setup, and conversion events
• Internal links from the location finder, service pages, region pages, and acquisition pages
• Redirect destination and former-name context for any URL that will move

The inventory exposes the real constraint. If corporate owns every template but cannot update local hours, the problem is not subfolders. If franchisees own complete sites but corporate cannot see their crawl or conversion data, the problem is not necessarily separate domains. The missing piece is a responsibility and access model.

A 30-day architecture decision

Week 1: classify the portfolio

Group locations by operating identity, not by current URL. Mark which branches share the parent brand, publishing system, analytics, and customer promise. Flag acquired brands and franchisees with genuine independence. Identify orphaned sites and subdomains with no accountable owner.

Week 2: choose the default and the exception test

Write one default rule for new locations. For most centrally governed service brands, that will be a subfolder under one location directory. Write a stricter exception test for subdomains and separate domains: named owner, complete site duties, durable technical boundary, and a documented handoff if the exception ends.

Week 3: map discovery and measurement

Confirm that every retained location URL is reachable from normal links, appears in the correct sitemap, uses a self-referencing canonical, and has the right profile target. Set up the Domain and URL-prefix Search Console properties the owners need. Do not change URLs just to make a report easier to filter.

Week 4: pilot one migration

If consolidation is needed, move one representative market before changing the portfolio. Validate redirects page by page instead of checking the homepage alone. Update internal links, canonicals, structured data, sitemaps, profile URLs, booking destinations, and analytics. Watch crawl errors, indexation, local leads, and old-brand discovery before setting the next migration wave.

The finished architecture should be boring in the best way. A new location receives one predictable URL. A customer can reach it through the locator and service pages. The branch and brand know who maintains the facts. Search and AI systems can discover the page through the same public relationships customers use.

Sources

Every link below was opened and checked September 2, 2026.

• Site names. Google Search Central, last updated December 2025. Source of the quoted definition of a site as a domain or subdomain, which is the only documented structural difference in this decision.
• Consolidate duplicate URLs with canonicalization. Google Search Central, last updated July 2026. Source of the three quoted signal-strength lines for redirects, rel=canonical, and sitemap inclusion.
• URL structure best practices for Google. Google Search Central, checked September 2026. Source of the simple, descriptive, logical URL guidance.
• Make your links crawlable. Google Search Central, checked September 2026. Source of the normal-link discovery and anchor guidance.
• Site moves with URL changes. Google Search Central, checked September 2026. Source of the old-to-new URL map, permanent redirect, sitemap, and dual-property monitoring workflow.
• Optimizing your website for generative AI features on Google Search. Google Search Central, last updated July 2026. Source of the Search fundamentals that also apply to AI Overviews and AI Mode.
• Search Console property types. Google Search Console Help, checked September 2026. Source of the Domain and URL-prefix property boundaries.
• Local business (LocalBusiness) structured data. Google Search Central, last updated December 2025. Source of the branch-level structured data guidance.
• parentOrganization. Schema.org vocabulary, checked September 2026. Source of the branch-to-parent relationship property.
• Cheers Research methodology. Cheers home-services panel, 28 days ending September 2, 2026, 119 organizations, aggregate only, cells under ten organizations suppressed. Source of the child-location appearance and citation rates quoted above.

Amadeus Peterson is the CTO & Co-Founder of Cheers, the local search platform for multi-location service businesses.