SEO-Friendly URL Structure for Service Business Sites

URL structure is one of the few SEO decisions that is genuinely hard to undo. You can rewrite a title tag in ten seconds. Changing a URL means a 301, a redirect map, lost internal links, and a recrawl window where your traffic wobbles.

So the money is in getting it right before the site is built — and in leaving it alone once it is. This guide covers the pre-build architecture: the folder depth, the service x city matrix, and the slug rules. Redirect migration is its own job and its own post.

What does a good service-business URL actually look like?

A good one is short, lowercase, hyphenated, human-readable, and one or two folders deep at most — /emergency-plumbing, not /services/plumbing/emergency/index.php?id=4471. Google's own URL structure documentation says to use readable words rather than long ID numbers, and recommends hyphens instead of underscores because it 'helps users and search engines better identify concepts in the URL.'

Google's URL structure guidance also warns that overly complex URLs with multiple parameters can cause problems for crawlers, and notes that Google's URL handling is case sensitive — so /Drain-Cleaning and /drain-cleaning are two different URLs to Google. Lowercase everything and enforce it at the server.

Dates in blog URLs are the quiet killer. Update that post in 2028 and the URL still says 2026 — so you either live with a stale-looking link in the SERP or eat a redirect. Leave the date out of the path.

How deep should you nest service and location pages?

Two levels, hard ceiling. Every page a customer might search for should be reachable in one or two clicks from the homepage, and its URL should say so: /drain-cleaning, /drain-cleaning-austin, /blog/post-name. There is no ranking bonus for /services/ sitting in front of your service page.

The trap is thinking the URL path has to mirror your navigation. It doesn't. Google's breadcrumb documentation is explicit: 'We recommend providing breadcrumbs that represent a typical user path to a page, instead of mirroring the URL structure.' Breadcrumb schema carries the hierarchy into the SERP. Your folders don't have to.

That single line kills the main argument for deep nesting. You can have a flat /drain-cleaning URL and still show Home > Services > Drain Cleaning in the search result, because that trail comes from your markup, not your path.

How do you structure the service x city matrix without duplicating yourself?

Use one flat pattern — /{service}-{city} — and only build a page where the service and the city are both real. A 6-service, 10-city business does not need 60 pages; it needs the 12 to 18 combinations that carry actual demand and actual proof.

The structure that breaks businesses is the nested matrix: /services/plumbing/locations/austin/emergency. Four folders, a URL nobody can read, and a page competing with /services/plumbing and /locations/austin for the same query. When three of your own URLs are eligible for 'emergency plumber austin,' Google picks one — and it is usually not the one you wanted.

Verdict: flat wins. The nested version buys you a tidy-looking sitemap and costs you crawl depth, click depth, and a permanent internal cannibalization problem. If you already have a city-page program, our guide to location pages for service-area businesses covers what has to be on each one before the URL matters at all.

When does a city deserve its own URL instead of a section on the service page?

A city earns its own URL when you can put at least three things on it that exist nowhere else on your site: local proof, local specifics, and local intent. If all you can do is swap the city name into the same 700 words, it is a section on the service page, not a page.

The honest test is whether a stranger reading the page could tell which city it was about with the city name deleted. Real jobs completed there. Local permit or code details. Response times from your actual dispatch area. Neighborhoods you cover and ones you don't. If you can't produce those, the page is a template with a find-and-replace, and Google's duplicate handling will collapse it.

Google's guidance on consolidating duplicate URLs puts it plainly: if you don't specify a canonical, 'Google will identify which version of the URL is objectively the best version to show to users in Search.' Near-identical city pages hand that choice to Google. It will pick one and quietly ignore the other 29.

Start with your top three revenue cities. Build them properly. Add the fourth only when the first three are ranking and converting.

Should keywords go in the slug — and how many?

One keyword, once. /water-heater-repair is right; /water-heater-repair-services-plumber-near-me-austin-tx is keyword stuffing you can see from space. Google's guidance is to use words in your audience's language, not to cram the URL — the ranking weight of a keyword in the slug is small, and the readability cost of stuffing it is not.

Treat the slug as a promise about the page, not a place to store keywords. The real on-page work happens in the H1, the intro, and the entities you cover — which is what our on-page SEO checklist for service pages is for.

• Skip filler words: services, company, best, top, professional, near-me
• Skip the state abbreviation unless two cities share the name (springfield-il vs springfield-mo)
• Skip stop words (a, the, and, for) unless removing them makes the URL unreadable
• Keep the slug matching the H1 in meaning, not word-for-word
• Percent-encode non-ASCII characters — Google's docs recommend it

Subfolder or subdomain for the blog?

Subfolder. /blog, not blog.yoursite.com. On a fresh service-business domain with little authority, splitting your content across two hosts means splitting the signal, and you have none to spare. Every link your blog earns should be building the same domain that sells the service.

The subdomain argument only holds when there's a real technical reason — a separate CMS you cannot reverse-proxy, or a platform that flatly refuses to serve from a subpath. Even then, a reverse proxy to /blog is usually cheaper than the visibility you give up. If your stack is fighting you on this, that's a technical SEO problem, and it's the sort of thing a technical SEO engagement exists to unblock.

Same rule for booking systems, review widgets, and job-listing tools that want to live at their own hostname. Anything that can earn a link or rank for a query belongs on your domain, in a folder.

When should you leave your ugly URLs alone?

If the pages rank and convert, leave them. An ugly URL that holds position 4 is worth more than a beautiful URL that has to re-earn its rankings — and Google says to keep redirects after a URL change for 'as long as possible, generally at least 1 year,' which tells you how long the debt lasts.

Google's site move documentation is blunt about the risk: 'With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site,' and 'a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer.' That is weeks of volatility on pages that are currently paying your bills.

So the decision rule is simple. Change URLs when you're rebuilding the site anyway, when the current structure is actively cannibalizing itself, or when the pages have no rankings to lose. Do not change URLs because the new ones look nicer in a spreadsheet.

Before you touch anything, run a crawl and find out what you actually have — how many URLs, how deep, how many duplicates, what ranks. Our technical SEO audit walkthrough covers the crawl. The audit tells you whether this is a cleanup or a migration.

What does the right structure look like end to end?

For a typical multi-service, multi-city business, the whole site fits in about five patterns and never goes past two folders. That is the entire architecture — no /services/, no /locations/, no fifth level.

• / — homepage
• /drain-cleaning — service money page
• /drain-cleaning-austin — service + city, only where demand is real
• /austin — city hub, only with 3+ services in that city
• /blog/how-much-does-drain-cleaning-cost — informational, funnels to the service page
• /about, /contact, /pricing — the trust and conversion pages

Build that on day one and you never pay the migration tax. Build the nested version and you will — usually about eighteen months in, right when the pages have finally started ranking and a rebuild costs the most.

If you're not sure which side of that line your site is on, we'll crawl it and tell you: how deep your pages sit, which URLs are competing with each other, and whether a restructure is worth the redirect debt. Start with technical SEO, or just Get my free audit and we'll show you the map of your own site.