TL;DR
The best URL structure pattern for most multi-location businesses is a single domain with a /locations/ hub, one page per real location or service area, and nested service pages only when each one can stand on its own with unique local content. URL patterns organize the relationship between your brand, locations, and services for both search engines and customers. But the URL is just the skeleton. Rankings come from the full local SEO system: unique local content, Google Business Profile alignment, internal links, reviews, and real proof you serve each area.
[Need help building and scaling local SEO pages? See how Rankai’s done-for-you SEO works.]
What Are URL Structure Patterns for Multi-Location Businesses?
URL structure patterns for multi-location businesses are standardized URL formats used to organize pages for different branches, cities, service areas, franchises, providers, or local services on one website. Common patterns include:
- Location folders:
/locations/chicago/ - Location plus service:
/locations/chicago/dental-implants/ - Location-first:
/chicago/dental-implants/ - Service-first:
/dental-implants/chicago/ - Flat slugs:
/chicago-dental-implants/ - Subdomains:
chicago.example.com - Separate domains:
chicagobrand.com
Think of the URL pattern as a taxonomy decision, not just a slug-writing exercise. It determines how your local pages relate to each other and answers three questions for every visitor and every crawler:
- Where is this page about? Chicago, Phoenix, Brooklyn, Back Bay.
- What is offered there? HVAC repair, dental implants, storage units.
- How does this page fit into the site? Brand → locations → Chicago → emergency HVAC.
The pattern you pick shapes your entire site architecture: how pages link to each other, how content teams produce new pages, how Google crawls and categorizes your site, and how customers navigate from “I need this service” to “I found the right branch.”
Why URL Structure Matters for Local SEO
URL structure is not a magic ranking factor. Google’s own URL guidance recommends using descriptive words users understand, hyphens between words, consistent casing, and fewer unnecessary parameters. But the documentation does not say that a specific URL pattern will push a page to position one.
Local rankings are primarily shaped by three things: relevance, distance, and prominence. Google’s local ranking documentation says that complete, accurate business information helps a profile appear for relevant searches, and that reviews and positive ratings can improve local ranking. URL structure connects to all three factors indirectly.
Relevance. A clear URL like /locations/phoenix/drain-cleaning/ combined with matching page content signals what the page is about. The URL alone does not rank the page, but it reinforces the topic for crawlers and users.
Distance and location confidence. A dedicated location page with a real address, directions, and a consistent NAP (name, address, phone) helps Google understand where the business operates.
Prominence. Organized URL patterns make internal linking easier. Strong internal links help Google discover pages and understand their importance. They also make it easier to earn citations and backlinks to specific location pages.
A good multi-location URL structure also prevents two common problems: cannibalization (where multiple pages from the same site compete for the same local query) and orphaned pages (where location pages exist but nothing links to them). A LinkedIn post by franchise SEO consultant Hardik Shah explains that when many franchise locations compete for the same keywords, the solution is hub-and-spoke architecture with keyword mapping by level and internal linking rules, not just more pages.
The Main URL Structure Patterns Compared
Here is a side-by-side comparison of every common multi-location URL pattern. Use the “best for” column to find your starting point.
| Pattern | Example | Best for | Pros | Cons |
|---|---|---|---|---|
| Location folder | /locations/phoenix/ |
Physical branches, clinics, stores | Clear, scalable, works with locator page, easy GBP alignment | Does not target service-city queries unless nested or included |
| Location + service nested | /locations/phoenix/drain-cleaning/ |
Multi-service businesses in many cities | Strong hierarchy, good local-service targeting | Can produce thin pages without real local proof |
| Location-first | /phoenix/drain-cleaning/ |
Smaller local service sites | Good user logic: pick city, then see services | Gets messy without a parent location hub |
| Service-first | /drain-cleaning/phoenix/ |
Service-taxonomy-driven sites | Useful when users search by service first | City pages may feel secondary |
| Flat slug | /phoenix-drain-cleaning/ |
Tiny sites with a handful of targets | Short, simple | Hard to scale, weak hierarchy, messy sitemaps |
| State/city nested | /locations/az/phoenix/ |
National brands with 50+ locations | Strong organization for large footprints | More URL depth; empty state pages are a risk |
| City/neighborhood nested | /locations/boston/back-bay/ |
Multiple units in one metro | Distinguishes multiple stores in one city | Requires unique neighborhood content |
| Provider under location | /locations/san-jose/jane-doe/ |
Healthcare, legal, real estate | Clarifies organization-office-individual relationships | Provider moves require redirects |
| Subdomain per location | phoenix.example.com |
Legally separate franchises | Separates operations and tech stacks | Internal linking and authority consolidation harder |
| Separate domains | phoenixbrand.com |
Truly independent businesses | Full autonomy | Highest SEO and brand fragmentation cost |
| Parameter-based | /services?city=phoenix |
Internal filters only | Easy for dev teams | Poor user clarity; should not be used for indexable pages |
A note on subdomains: John Mueller has said Google Search can work with both subdomains and subdirectories, while recommending that related content be grouped together. The argument for subdirectories is not that Google “cannot rank subdomains.” It is that subdirectories usually make governance, analytics, internal linking, and content consistency easier for SMBs and franchise teams.
Location-First vs. Service-First: The Real Debate
This is the question practitioners argue about most. Should the URL read /phoenix/drain-cleaning/ or /drain-cleaning/phoenix/?
Practitioners on Reddit’s r/localseo are split. In a widely discussed thread, some argued that location-first better matches the customer journey because a person in Phoenix wants to see all Phoenix services, not the same service listed across other cities. Others said service-first makes more sense when the site’s primary taxonomy revolves around services offered in many markets.
One comment in that thread cut through the noise: Google cares more about your link structure than whether the city name comes before or after the service name in the URL. That observation is closer to the truth. The URL slug order is a secondary signal at best.
What actually matters is whether users and crawlers can move logically between the location hub, individual city pages, service pages, service-city pages, nearby locations, and booking actions.
Use location-first when:
- Customers choose by city or branch first
- Each location offers multiple services
- You want the location page to function as a local hub
Use service-first when:
- Your service taxonomy is the primary site structure
- You have strong service pages with city variations underneath
- Users typically search for the service before specifying a location
In the same Reddit thread, one user recommended flattening to /drain-cleaning-phoenix/, while another responded that flat slugs create indexing trouble and messy sitemaps at scale. This tracks with broader practitioner experience: flat slugs work fine for a tiny site, but become a liability when you need to manage dozens or hundreds of local pages.
Either way, research local keywords before committing to a pattern. The data will often reveal which approach matches how your customers actually search.
The Best Default URL Architecture
For most multi-location businesses, the safest and most scalable URL structure follows this pattern:
/locations/
/locations/{city-state}/
/locations/{city-state}/{service}/
A concrete example:
/locations/
/locations/phoenix-az/
/locations/phoenix-az/drain-cleaning/
/locations/scottsdale-az/
/locations/scottsdale-az/drain-cleaning/
This produces a clean site hierarchy:
Homepage
└── Locations hub (/locations/)
├── Phoenix AZ (/locations/phoenix-az/)
│ ├── Drain cleaning in Phoenix
│ ├── Water heater repair in Phoenix
│ └── Nearby locations
└── Scottsdale AZ (/locations/scottsdale-az/)
├── Drain cleaning in Scottsdale
├── Water heater repair in Scottsdale
└── Nearby locations
Why this works as the default:
- Clear hierarchy from brand to location to service.
- Supports a location finder page at
/locations/. - Scales from three locations to hundreds without restructuring.
- Easy to map each Google Business Profile to its corresponding branch page.
- Gives content teams a repeatable system for producing new pages.
- Reduces random flat-page sprawl that makes sitemaps confusing and internal linking harder.
For a deeper walkthrough on building these pages, see this guide on multi-location landing page templates.
Publish service-location pages (like /locations/phoenix-az/drain-cleaning/) only when the page can be genuinely different from other city-service pages. More on that distinction in the doorway pages section below.
How to Choose a Pattern by Business Type
The “best” multi-location URL pattern depends on what kind of business you are. Here is a decision framework organized by business model.
Physical storefronts
Use /locations/{city-state}/ for each branch. If you have multiple locations in one city, add a neighborhood or store identifier:
/locations/boston/back-bay/
/locations/boston/cambridge/
Each page should include the full branch details: address, hours, phone, directions, parking, staff, local reviews, and services available at that location.
Service-area businesses
Use either /service-areas/{city}/ or /locations/{city}/. Pick one convention and stay consistent. Backlinko recommends separating physical location pages from service-area pages because they answer different user needs: physical-location visitors want logistics like hours and parking, while service-area visitors want proof the business covers their region.
For a comprehensive approach to this business type, read our guide to service area business SEO.
Franchises
Use one main domain with location folders unless the franchise model legally requires separate websites. Subdirectories keep all locations under one domain, simplify analytics, and make internal linking straightforward. Google can rank subdomains, but subdirectories make governance and content consistency easier for most franchise teams.
Healthcare, legal, and provider businesses
Nest providers under locations:
/locations/san-jose/jane-doe-md/
/locations/san-jose/cardiology/
This clarifies the relationship between the organization, the office, and the individual. It matters for industries where patients or clients search for specific people at specific offices.
Multi-state brands with 50+ locations
Add a state level:
/locations/az/phoenix/
/locations/ca/san-diego/
Only do this if state hubs will contain real content. Empty state pages with nothing but a list of cities add little value and may look like filler.
Multiple locations in one city
Use neighborhood or store-name identifiers under the city slug:
/locations/chicago/loop/
/locations/chicago/lincoln-park/
Each page needs unique neighborhood content, not just the same city text with a different header.
Explore the full multi-location SEO playbook for a broader strategy beyond URL structure.
What Every Location Page Needs
The URL pattern is the address. The page content is the house. A clean URL pointing to a thin page accomplishes nothing.
Every location page should include:
- Unique NAP. Name, address, phone number specific to that branch.
- Hours of operation.
- Local phone number, not just a central call center line.
- Directions and a map. Include parking or transit info if relevant.
- Local photos. Real images of the office, team, storefront, or service area. Not stock photos.
- Local reviews. Testimonials or review excerpts from customers at that location.
- Staff or provider bios for that branch.
- Services available at that specific location.
- Nearby landmarks and neighborhoods served.
- FAQs specific to the city or branch (pricing differences, local regulations, seasonal considerations).
- Internal links to service pages, nearby locations, and booking/contact pages.
- LocalBusiness schema markup with accurate structured data.
- A clear call to action: call, book, get directions, or request a quote.
Search Engine Land recommends complete business information, branch photos, reviews, directions, and location-specific content to help both users and search engines understand each branch.
A correlational study by Steve Wiideman found that higher-ranking local pages were associated with hyperlocal content, custom location images, and native reviews, with the largest differences appearing for hyperlocal content and custom images. Correlation is not causation, but the pattern is consistent: pages that look and read like they belong to a specific place outperform templates with a swapped city name.
Steve Wiideman also argues on LinkedIn that one-page-per-city templates break down at scale because customer intent varies by market. He gives examples like student storage demand, climate-controlled storage needs, and seasonal patterns differing city to city. The best multi-location sites do not only map city to page. They map city plus demand pattern to page type.
For step-by-step guidance on building these pages, see how to create local landing pages that convert.
How to Avoid Doorway Pages
This is where most multi-location URL strategies go wrong. The risk is not having many local URLs. The risk is having many near-identical local URLs.
Google’s spam policies explicitly describe doorway abuse as pages targeted at specific regions or cities that funnel users to one page, and substantially similar pages that sit closer to search results than a browsable hierarchy.
Good location page: /locations/phoenix/
Contains the Phoenix team’s bios, the office address, local customer reviews, photos of the Phoenix storefront, services available at that branch, parking instructions, neighborhood info, and locally relevant FAQs.
Bad doorway page: /phoenix-plumbing/, /mesa-plumbing/, /scottsdale-plumbing/
All three use identical text with only the city name swapped. All three push users to the same quote form. None contains anything specific to any city.
Here is a simple test practitioners on LinkedIn have shared: if you can copy a page to another city and it is still accurate, the page is not local enough. It does not deserve its own URL yet.
Practitioners on Reddit report that near-duplicate location pages often get crawled but not indexed. The fix is not more pages. It is adding local landmarks, unique reviews, local FAQs, and genuinely relevant content so each page is truly about that place rather than a template with a different header.
Practical rule for service-location pages: If the content for /locations/phoenix/drain-cleaning/ would still be true after replacing “Phoenix” with “Scottsdale,” the page is not ready. Mention the service on the main location page and link to the main service page instead.
Internal Linking Rules for Multi-Location URL Structures
URL structure organizes pages. Internal linking connects them. For multi-location sites, the linking architecture often matters more than the URL path itself.
Follow these rules:
- Link from the homepage or main navigation to
/locations/. - Link from
/locations/to every indexable location page. - Link each location page to its top services at that branch.
- Link each service page to the location pages where that service is offered.
- Link nearby locations to each other. Phoenix links to Scottsdale, Scottsdale links back.
- Link location pages to booking, contact, or quote request pages.
- Link provider pages back to their parent location.
- Always link to canonical URLs. Google’s canonicalization documentation recommends that internal links point to the canonical version of each page.
The internal link structure is what turns a collection of isolated location pages into a coherent local site. Without it, each page is an island that Google may never discover or prioritize. For guidance on quantity and placement, read about internal linking best practices.
Should You Change Existing URLs?
If your site already has location pages with a different URL pattern, the instinct is to restructure everything. Resist that instinct unless the upside clearly outweighs the migration risk.
Google recommends permanent server-side redirects (301 or 308) when a page URL permanently changes. But practitioners on the Local Search Forum warn that changing a URL that already ranks well can have negative effects, even with proper redirects in place. One contributor put it bluntly: there is no reason to change a ranking URL because it can have ill effects.
Use this decision table:
| Current situation | What to do |
|---|---|
| URL ranks well and has backlinks | Keep it. Improve page content if needed, but leave the URL alone. |
| URL does not rank and has no links | Consider changing to a cleaner, more organized slug. |
| URL is misleading or conflicts with new architecture | Change with a 301 redirect. Update all internal links. Monitor closely. |
| Many old city pages are thin or duplicate | Consolidate, improve, noindex, or redirect based on each page’s value. |
| Existing pattern is ugly but performance is stable | Improve content and links first. URL changes are the last lever to pull, not the first. |
The bottom line: URL restructuring is surgery, not cosmetics. Before you operate, make sure the patient needs it. Run a technical SEO audit first to understand what is actually holding your local pages back.
Technical Checklist
Before publishing or restructuring multi-location URL patterns, verify these technical basics:
- Use lowercase URLs consistently. URLs are case-sensitive.
- Use hyphens between words, not underscores.
- Avoid unnecessary URL parameters for indexable location pages.
- Keep the pattern consistent across all locations. Do not mix
/locations/phoenix/with/cities/scottsdale/. - Make the location hub page crawlable and indexable.
- Include all indexable location URLs in the XML sitemap.
- Use self-referencing canonical tags on each indexable location page.
- Redirect old URLs with 301s when changing structure.
- Update internal links to point to the final canonical URL after any migration.
- Avoid orphaned location pages, meaning pages with no internal links pointing to them.
- Do not generate thousands of pages without unique local value on each one.
Explore Rankai’s SEO tools to help audit and monitor your site’s technical health.
URL Structure Examples by Scale
Example A: 3-location dental practice
/locations/
/locations/chicago-loop/
/locations/lincoln-park/
/locations/oak-brook/
Add service-location pages only for services with real search demand and location-specific content:
/locations/chicago-loop/dental-implants/
Three locations do not need state hubs or complex nesting. Keep it simple.
Example B: 1 office serving 15 cities
/locations/kansas-city-mo/
/service-areas/overland-park-ks/
/service-areas/leawood-ks/
/service-areas/blue-springs-mo/
Separate the physical office from the cities served. The office page gets full branch details. Service-area pages focus on proof of coverage and reasons to choose the business for that market.
Example C: 50-location franchise
/locations/
/locations/az/
/locations/az/phoenix/
/locations/az/scottsdale/
/locations/ca/
/locations/ca/san-diego/
State hubs make sense here if each state page has real content: a list of locations, state-specific offers, or regional information. Do not create empty state pages just for nesting.
Example D: Healthcare group with providers
/locations/san-jose/
/locations/san-jose/jane-doe-md/
/locations/san-jose/cardiology/
Providers and specialties nest under the location. This clarifies which doctors practice at which office, a structure that matters for patients searching by provider name.
Frequently Asked Questions
What is the best URL structure for a multi-location business?
For most businesses, use one domain with a /locations/ hub and one page per location, such as /locations/chicago/. Add nested service-location pages like /locations/chicago/emergency-plumbing/ only when each page has genuinely unique local content. This pattern is easy to scale and keeps the site organized regardless of whether you have five locations or five hundred.
Is /city/service/ better than /service/city/?
Neither is always better. Use /city/service/ when the city or branch is the primary user entry point. Use /service/city/ when services drive the main site taxonomy. Internal linking, page content, and Google Business Profile alignment usually matter more than which word comes first in the URL slug.
Should a multi-location business use subdomains?
Usually not, unless each location operates as a legally or operationally separate entity. Google can handle both subdomains and subdirectories, but subdirectories are typically easier for SMBs and franchise teams to manage, link between, and report on. The operational simplicity of folders wins for most businesses.
Are city pages bad for SEO?
City pages are not automatically bad. Thin, duplicate city pages built mainly to rank for similar queries and funnel users elsewhere are the problem. Google’s spam policies specifically warn against region-targeted pages that are substantially similar and sit closer to search results than a browsable hierarchy. If each city page has unique local proof, it belongs on your site.
Should I include keywords in location URLs?
Use descriptive words when they help users understand the page. A URL like /locations/phoenix/drain-cleaning/ is clear and helpful. A URL like /best-cheap-emergency-drain-cleaning-plumber-phoenix-az/ is stuffed and counterproductive. Keep slugs natural and readable.
Should every service get its own page for every location?
No. Create service-location pages only when there is real search demand and enough unique local content to justify the page. Otherwise, mention the service on the main location page and link to the main service page. Mass-generating city-service combinations without unique content is a doorway page risk.
Should I change old location URLs to match a cleaner pattern?
Only when the benefit clearly outweighs the risk. If a URL ranks well and has backlinks, keep it. If it does not rank and has no links, it is safer to change. Always use a permanent redirect (301) when moving a page, and update all internal links to point to the new URL.
How does Google Business Profile connect to URL structure for multi-location businesses?
Each eligible location’s Google Business Profile should link to the most relevant canonical page for that branch, not the homepage. Practitioner testing reported by Search Engine Journal found that changing the GBP link away from a city-targeted location page hurt Local Pack rankings, and switching it back recovered them. Align your GBP website links with the same URL structure your location pages use.
Managing URL structure patterns for multi-location businesses is an architecture problem, not a cosmetic one. The URL is the skeleton. Local content, internal linking, GBP alignment, reviews, and real proof of local presence are the muscle and the skin. Get the structure right, fill it with substance, and the pages will do their job.
