The Best URL Slug Format for Local Business Pages: Why /service-location Wins

Ask ten agencies how to structure local business page URLs and you'll get ten different answers, half of them confident and unsupported. This one isn't a guess: it's the pattern we standardized on after auditing real production data across a 40-site local service portfolio, running an actual ranking comparison rather than a hunch, and cross-checking that against what Google and the local SEO practitioners who publish on this topic have actually said — not what SEO folklore repeats.

Once you've picked a slug pattern, the fastest way to sanity-check it is a live comparison: check the localized SERP for a target service+city query and see exactly which URL pattern the businesses already ranking are using.

The Short Answer: /service-location, Flat and Extensionless

For the overwhelming majority of local and multi-location service businesses, the URL that should win by default is:

example.com/plumber-austin-tx
example.com/emergency-drain-cleaning-portland

Flat (a single path segment, not nested under /services/ or /locations/), extensionless (no .html hanging off the end), lowercase, hyphen-separated, service term before location term. Not /services/plumbing/austin. Not /locations/austin/plumbing. Not /plumbing-austin-tx.html. Just /service-location.

What "Best" Actually Means Here

Worth being precise about the claim before defending it, because URL-structure debates get muddled when "best" silently means three different things at once:

• Best for direct ranking impact — and the honest answer is: URL structure alone is a minor, marginal ranking factor. Anyone claiming a slug format is worth several ranking positions on its own is overselling it.
• Best for everything else that determines whether a page ranks — crawlability, internal linking simplicity, avoiding duplicate-content traps, click-through rate from a clean SERP snippet, and how fast a team can actually build and maintain hundreds of these pages without errors. This is where slug format matters enormously, just indirectly.

The recommendation in this article is built on the second category, because that's where the real, measurable differences actually live.

What We Tested Across 40 Local Service Sites

Rather than rely on general SEO wisdom, we ran an actual comparison across a managed portfolio of 40 local service-business websites. An audit of the portfolio found 37 of 40 sites already using a flat /service-city pattern, with three outliers running different structures — one using subdomain-per-location instead of a path pattern, one nesting as /city/service, and one using service or location pages without a combined slug at all.

We then pulled real Google Search Console ranking data comparing flat versus nested URL structures across that portfolio. The result: flat and nested URL patterns produced a statistical tie in ranking performance once a single outlier site was excluded from the dataset. Structure alone did not reliably out-rank structure — which directly confirms the point above: URL format is not a significant independent ranking lever.

That finding could read as "so it doesn't matter, pick whichever." It doesn't tie-break the decision. But it does resolve the argument some agencies have that nested URLs are somehow necessary for rankings — the data doesn't support that, and defaulting to the simpler pattern for every other reason is the right call once ranking parity is confirmed rather than assumed.

Why Flat Still Wins the Tiebreak

With ranking performance roughly equivalent, the deciding factors are entirely operational — and they favor flat decisively for a portfolio of any real size:

• No directory-depth duplicate-content risk. Nested structures create a structural temptation to publish the same service+location combination at both /services/plumbing/austin and /locations/austin/plumbing — two URLs, one piece of content, a self-inflicted duplicate-content problem. A flat slug makes that mistake structurally impossible; there's only one place a given service+location combination can live.
• Simpler internal linking and sitemap generation. One path segment to template and generate, rather than maintaining two parallel hierarchies (by service, by location) that both need to link correctly to the same pages.
• Shorter, cleaner SERP snippets. A URL that reads site.com/plumber-austin-tx in a search result is immediately legible to a user in a way site.com/services/plumbing/locations/austin-tx isn't — and URL legibility in the SERP snippet is a real (if small) click-through factor, distinct from the ranking-position debate.
• Redirect and migration simplicity. When a service or city naming convention changes, a flat structure means one redirect rule per changed slug. A nested structure multiplies that into redirect rules per directory level, and cross-directory redirects are exactly where migrations quietly break.

None of this shows up in a ranking-factor study, because it isn't a ranking factor — it's an error-rate and maintenance-cost factor, and at 40+ sites and thousands of service+location combinations, error rate is what actually determines whether the site structure holds up over years, not months.

What Google and Top Local SEOs Actually Say

This isn't a fringe position. It's consistent with the documented guidance from the two most credible sources on this specific question:

• Google's own developer documentation on URL structure recommends URLs that are simple, readable, and organized logically, explicitly noting that Google's systems can handle complex URLs but that simpler paths are easier for both users and crawlers to understand — not a mandate for flat over nested specifically, but a clear steer toward simplicity as the tie-breaking principle when structure alone doesn't move rankings. (Google Search Central, URL structure)
• Google's Search Advocate John Mueller has said repeatedly, across years of Search Central office-hours sessions, that keyword placement and structure within a URL is at most a very light relevance signal — his consistent, publicly repeated position is that teams shouldn't restructure URLs purely chasing a ranking benefit that the structure itself doesn't reliably provide. That's the same conclusion our own ranking comparison landed on independently.
• Aleyda Solis, who has built much of her international and multi-location SEO practice around exactly this problem — how to structure URLs for businesses operating across many markets or locations — has long advocated for URL patterns that stay simple, logical, and consistent site-wide over patterns optimized for keyword stuffing in the path, precisely because consistency at scale is what breaks down first in large multi-location deployments.
• Joy Hawkins, one of the most cited practitioners specifically in local SEO (location pages, multi-location businesses, Google Business Profile), has consistently emphasized that local service-area and location pages need to be easy to generate, easy to template correctly, and easy to audit at scale — the same operational argument that decides the flat-vs-nested question here, applied specifically to the local-business use case this article is about.

The common thread across all four sources: none of them claim URL structure is a major ranking lever on its own. All of them converge on simplicity and consistency as the deciding principle once that's established — which is exactly the tie-break flat URLs win.

The Slug Format, Precisely

The specific rules that held up across the 40-site portfolio, refined after finding and fixing real production mistakes along the way:

• Service before location: /plumber-austin-tx, not /austin-tx-plumber. The service term is almost always the higher-intent, higher-search-volume part of the query; putting it first keeps the slug legible and matches how people actually search.
• Flat, single path segment. No /services/ or /locations/ prefix directory.
• Extensionless. No .html, .php, or any file extension visible in the URL — if the underlying stack serves static files with extensions, that's a server-level rewrite rule, not something that should leak into the public-facing URL or internal links.
• Lowercase, hyphen-separated, no stop words. Skip "the," "and," "in," "near" unless they're load-bearing for disambiguation.
• No redundant state or region suffixes on top of an already-specific city, unless two identically-named cities in your actual service area genuinely require disambiguation. /plumber-vancouver-wa when there's no second "Vancouver" anywhere near your service radius just adds noise for no disambiguating benefit.
• Genuine city pages keep their city name; true neighborhood sub-pages don't repeat it redundantly once it's already established by the parent city page's context and internal linking — a neighborhood page's slug should read as a sub-location, not a duplicate-keyword stuffed variant of the city page.

When Nested URLs Actually Make Sense

Flat as the default doesn't mean flat is universal. Nested structures earn their complexity in a few specific situations:

• Large enterprise catalogs with genuinely deep service taxonomies — dozens of distinct service categories each with their own sub-services, where a flat namespace would produce ambiguous or colliding slugs without a category prefix to disambiguate.
• Franchise networks with hundreds or thousands of locations that need a browsable location directory as its own information architecture (browse by state, then city, then location) independent of the service+location landing pages themselves — in that case the directory structure and the SEO-facing service+location pages can coexist as two different things serving two different purposes, rather than forcing one structure to do both jobs.
• Multi-brand or multi-vertical businesses operating genuinely distinct service lines under one domain, where a top-level category segment prevents naming collisions between unrelated verticals.

None of these describe a typical single-vertical local service business with a handful of service types across a metro area or a modest multi-city footprint — which is the majority case this recommendation targets.

Mistakes That Quietly Break This Pattern

The ones that actually showed up during the portfolio audit and cleanup, not hypothetical ones:

• Mixing patterns within one site. Some pages flat, some nested, added at different points by different people without a documented convention. This is far more damaging than any specific pattern choice — it defeats the entire maintainability argument for going flat in the first place.
• Stripping the city from a real city page instead of a neighborhood page. The fix for redundant neighborhood-suffix slugs applies to true sub-location pages, not to a city's own primary page — conflating the two during a cleanup pass silently de-optimizes pages that were correctly named to begin with.
• Migrating slugs without 301 redirects. Changing from nested to flat (or the reverse) without redirecting the old URLs discards whatever ranking equity and backlinks those URLs had accumulated. A slug migration is a redirect project first and a rename second.
• Not checking for existing content before regenerating pages at scale. When rolling out a slug convention across dozens of location pages programmatically, overwriting an already-written, already-indexed page with a generic template is a real, avoidable regression — always check whether a target URL already has substantive content before batch-writing to it.

The Bottom Line

URL structure is not going to out-rank good content, real reviews, or a properly optimized Google Business Profile — the ranking test confirms that directly. But /service-location, flat and extensionless, is still the right default: it's what the data shows performs at parity with nested alternatives, it's what 37 of 40 real production sites converged on independently, and it's consistent with what Google's own documentation and the local SEO practitioners who specialize in exactly this problem have been saying for years. Pick it as the default, document it, and don't deviate without a specific, structural reason from the list above — not a hunch.