Location pages built as one thin template with the city name swapped in are exactly the pattern Google's guidance on doorway pages targets — and a common reason a site with 50 city pages still doesn't rank for most of them. Done right, each page has genuinely unique content, doesn't compete with your other pages for the same search, and links back into a coherent structure instead of sitting as an island.

The Service × City Matrix

The full location-page opportunity is every service offered crossed with every city or area served — junk car removal in Springfield, cash for cars in Fairview, used parts pickup in Riverside, and so on. Laid out as a grid, it's easy to see both what needs a page and where the matrix is thin:

ServiceSpringfieldFairviewRiverside
Junk Car RemovalLive pageLive pageGap — no page
Cash for CarsLive pageGap — no pageLive page
Used Parts PickupGap — no pageGap — no pageLive page

A three-city, three-service business already has nine possible pages in the matrix — four of them missing in the example above. Scale that to a real service area covering eight or ten cities and two or three services, and the matrix easily runs to twenty or thirty cells, most sites never map deliberately. Some cells genuinely don't deserve a page (a service with no real demand in a particular city shouldn't get one just to fill the grid), but the matrix at least makes that a conscious decision instead of an accident.

Doing It Without a Doorway-Page Penalty

Google's own guidance is specific about what it doesn't want to see: pages that exist only to rank for a city name, with the same content template and only the city swapped. The risk isn't hypothetical — a site that builds 40 city pages from one template, differing only in the H1 and a find-and-replaced city name in two sentences, is a textbook doorway pattern, and Google's algorithms are built specifically to detect and suppress exactly that shape of content.

The fix isn't avoiding location pages — it's making each one genuinely useful. What separates a unique-and-safe page from a thin-and-penalized one comes down to a handful of concrete things:

  • Don't: a single paragraph of generic copy ("We buy junk cars in [City]! Call today for a free quote!") repeated across every city page with only the bracket filled in.
  • Do: a real intro paragraph specific to that city — the actual neighborhoods or zones covered, how far outside city limits service extends, and any city-specific detail worth mentioning (a particular scrap yard or recycling facility partnership, a local permit or bylaw that affects abandoned-vehicle pickup, typical response time for that specific area).
  • Don't: identical FAQ blocks copy-pasted across every city page, answering questions with no city-specific detail at all.
  • Do: at least one or two FAQ entries genuinely specific to that city — local title/registration rules if they differ, or a logistics question that only makes sense for that market (e.g., how pickup works in a dense downtown core versus a rural outskirt of the same service area).
  • Don't: a page with no unique schema, sharing identical structured data with every other city page word-for-word.
  • Do: LocalBusiness or Service schema with that page's actual areaServed and geographic data — covered in more depth in schema markup for auto recyclers.

None of this requires a novel by the time all your city pages are done — it requires each page to earn its existence with real, specific information rather than existing purely as a landing spot for a search query.

Cannibalization: When Your Own Pages Compete

A subtler problem than thin content: two pages on your own site targeting the same search term end up splitting ranking signal between them instead of either one ranking well. A few concrete scenarios where this shows up in practice:

  • Citywide page vs. neighborhood page. A "Junk Car Removal in Springfield" page and a "Junk Car Removal in Downtown Springfield" page both end up targeting the same underlying query if the neighborhood page isn't clearly differentiated — most searchers just type the city name, not the neighborhood, so the neighborhood page often has no real search volume of its own to justify existing separately.
  • Service page vs. location page overlap. A core "Junk Car Removal" service page that isn't clearly positioned as the general/national version can end up competing with a "Junk Car Removal in Springfield" location page for the exact same local searches, especially if the service page's own content leans heavily on one city's examples.
  • Blog content vs. location pages. An article titled "How Junk Car Removal Works in Springfield" written for informational intent can accidentally target the same transactional query as the location page itself, if the article isn't clearly angled toward the how-it-works question rather than trying to also rank for the bare "junk car removal Springfield" term.

Detecting it means checking which pages are actually competing for the same queries in Search Console — looking at which URLs show impressions for the same search term — not guessing from the page titles alone. The fix is usually one of two things: differentiate the pages more clearly (different target term, different intent, different depth), or consolidate them into a single stronger page rather than splitting authority across two weak ones.

Internal Linking Structure

Location pages shouldn't be orphaned, and the linking structure that avoids that is a hub-and-spoke shape: the pillar guide sits at the top, linking down into core service pages, which in turn link down into the city-specific location pages under each service. From there, nearby city pages link across to each other where a visitor plausibly cares about an adjacent market, and every location page links back up to its parent service page and the pillar. A visitor landing on any single city page should be able to reach the core service pages, the pillar guide, and a neighboring city's page within one click — and so should Google's crawler, which relies on that same link structure to understand how the pages relate to each other rather than treating each one as an isolated island.

Large sets of city pages are also easy to accidentally orphan from crawl paths entirely if they only exist in a sitemap file and never get linked from anywhere a visitor or crawler naturally travels — a footer directory or an area-served index page listing every city page by name is worth having once the count gets past a handful.

Finding the City Pages You're Missing

The matrix above is easy to sketch on paper and easy to leave incomplete in practice. Gap detection running against real search data flags valuable city and service combinations that don't have a page yet — and flags pages that exist but are underperforming for the term they should own — rather than relying on a one-time manual audit that goes stale as your service area changes.

How Many Is Too Many?

There's a real failure mode on the other end of this too: building a location page for every small town in a fifty-mile radius regardless of whether any of them have meaningful search volume. A cluster of five towns within a few miles of each other, each with a handful of monthly searches, often performs better as one well-built regional page than as five thin pages competing with each other for the same tiny pool of traffic — the doorway-page risk doesn't disappear just because the city names are real; a page built for a city with essentially no search demand behind it is thin content either way, however unique its paragraph is.

Frequently Asked Questions

How many location pages do I actually need?

It depends on how many cities or areas have meaningful search volume for your services — not every town in your service area needs its own page, especially small ones close together that may perform better sharing one regional page.

What counts as "unique enough" content for each city page?

Real specifics tied to that location — service area boundaries, neighborhoods covered, city-specific logistics or regulations, and at least one or two city-specific FAQ entries — rather than the same paragraph and FAQ block with only the city name changed.

Should city pages have their own schema markup?

Yes — see schema markup for auto recyclers for how LocalBusiness and Service schema apply at the page level, with each city page carrying its own accurate area data.

Does Google Business Profile use the same city data as location pages?

They're related but separate — see Google Maps marketing for how service-area settings in your GBP profile line up with your website's location pages.

Should a neighborhood inside a city I already cover get its own page?

Only if the neighborhood has real, distinct search volume of its own — most searchers type the city name, not the neighborhood, so a separate neighborhood page often just cannibalizes the citywide page instead of capturing new traffic.

What's the fastest way to tell if two of my pages are cannibalizing each other?

Check Search Console for search terms where two of your own URLs both show impressions — that's a more reliable signal than comparing page titles, which can look distinct even when the pages are actually competing for the same query.