A plumbing company serves twelve suburbs around one city. Someone built twelve pages, one per suburb, each identical except for the town name swapped into the headline and a single line of copy. Six months later the pages bring almost no traffic, three of them sit in Search Console marked “Discovered – currently not indexed,” and the owner has decided local SEO is a scam. The pages were not the wrong idea. The execution was, and the distance between those two things is where most location-page projects quietly fail.
Location pages (also called local landing pages or city pages) are one of the oldest tactics in local search, and also one of the easiest to do in a way that Google was built to ignore. This is a walk through when you actually need them, what separates a page that ranks from a page that gets flagged, and how to verify the difference before you scale.
What a location page is actually for #
A location page is a page on your own website that targets a “[service] in [place]” query for a specific area you serve. Its job is to be the page Google can rank in the organic results (not the map pack) when someone searches for what you do plus where they need it, especially in places where you have no storefront and therefore no strong Google Business Profile presence.
That last part matters, because a location page is not a substitute for a Business Profile, and the two compete on different surfaces. The profile feeds the local pack through proximity, relevance, and prominence tied to a verified address. A location page feeds the classic organic listing below the pack, where a physical address is not required and a genuinely useful page can rank for a town you serve but do not sit inside. When someone frames a location page as “a page to get into the map,” they have already misread the tool: the map pack is not where these pages live.
So the honest use case is narrow. You build location pages when you serve real, nameable places that your Business Profile cannot reach on its own, and you can say something true and specific about serving each one.
The doorway line, in local terms #
Google’s spam policies name “doorways” directly: pages created mainly to rank for many similar queries that funnel people toward the same destination, without being genuinely useful in their own right. Multiple near-identical city pages are the textbook example, and the enforcement is not theoretical. A doorway pattern can be demoted algorithmically or hit with a manual action.
There is one test that settles almost every case. Cover the town name with your thumb and read the page. If nothing else on the page changes meaning when the city is swapped for a different one, it is a doorway in Google’s sense, no matter how clean the code is. A real location page fails that swap test on purpose: remove the town and half the sentences stop being true.
The uncomfortable part is that valid markup and a tidy template do not clear this bar. The differentiator is substance the reader could only get about that specific place, and there is no schema field for that.
When you actually need them (and when you don’t) #
Most of the damage comes from building location pages by reflex. The decision is really four different situations wearing one name.
| Your situation | Location pages? | Why |
|---|---|---|
| Multiple physical storefronts | Yes, one per location | Each has a real address, hours, staff, and reviews. Google’s own multi-location guidance points to a distinct page per location. Unique content is available because the location is real. |
| Service-area business, several named areas, no address in each | Selectively, with real substance | Legitimate, but this is where doorway risk lives. Only build a page for an area you can describe with genuine specifics. |
| Same service, long list of nearby towns | Rarely, and never as a set | The highest-risk pattern. A page per town with only the name changed is the doorway example. Build the few that earn substance, park the rest. |
| One city, one location | No | Your homepage and core service pages already carry the local signal. A separate city page competes with them and tends to split relevance rather than add it. |
Notice the pattern: the more real your presence in a place, the safer and more useful the page. The temptation runs the opposite way, toward pages for places you barely touch, which is exactly the direction the policy is watching.
What makes a location page genuinely unique #
Uniqueness here does not mean a reworded intro or a synonym swap. It means information a reader in that specific area could not get from your generic service page. The reliable sources of it are things a find-and-replace script cannot produce.
Name the actual service-area boundaries: the neighborhoods, the ZIP codes, the “we cover north of the river but not past the county line” reality. Reference specific local work, even briefly (“a repipe in a 1920s bungalow in the Highlands, where the original galvanized lines were the real problem”). Note anything locally true about the work itself: permit rules that differ by municipality, seasonal patterns, building stock, drive time from your nearest crew. Pull in reviews written by customers in that area, directions and parking if there is a physical spot, and photos of real jobs rather than stock images that could sit on any page.
A useful way to audit this before publishing is to count. If a page offers zero specific local details, zero references to real local work, and zero locally distinct information, it has nothing to rank on and nothing to keep it out of the doorway bucket. One genuine local specific is worth more than three paragraphs of “proudly serving the greater metro area.”
Structure and the signals that carry the page #
Once the substance is real, the structure is straightforward, and it is the same discipline you would use on any well-built page.
Give each page a clear, stable URL that reads out loud (something like /locations/city-name/ or /service-city-name/), and keep the pattern consistent across the set. Write a title tag and H1 that name the service and the place without stuffing every nearby town in. If the location has a real address, put accurate NAP details on the page and mark it up with LocalBusiness structured data so Google has more context to connect the page to the entity; if there is no address, do not invent one, because a fake or shared address is one of the fastest ways into local spam enforcement.
Then link the pages into your site on purpose. A parent hub (a /locations/ page listing every area, each linking down to its page, each page linking back up and across to a few siblings) does two things at once: it gives readers a way to find the right page, and it gives Google a crawl path so these pages are not orphaned. Location pages that exist only in the sitemap, with no internal link pointing at them, are the ones that tend to stall at “Discovered – currently not indexed,” because a URL Google has merely found is a weaker candidate than one your own site clearly stands behind.
Building at scale without crossing the line #
Two or five location pages get hand-written, and that is the whole governance model. The problem starts at fifty or five hundred, where the only way to build is a template, and a template plus a thin dataset is precisely how scaled pages tip into abuse.
The line is not “templated or not,” because plenty of legitimate pages share a template. The line is whether each generated page carries enough unique, valuable information to deserve its own place in the index. Practically, that means a minimum-data threshold before a page is allowed to publish: if the only variable data for a town is its name and a latitude, the page should not go live. It means a publish gate rather than a bulk export, and it means watching for the canary. When a batch of near-identical templated pages goes up, the symptom shows in Search Console as a wave of “Crawled – currently not indexed,” which is Google’s index-side way of saying it fetched the page and judged it not worth keeping. That status is the signal to stop adding pages and start adding substance, not to build more.
Verify before you scale, then monitor #
The failure mode of location pages is silent, so the verification has to be deliberate. Do not judge the project by whether the pages exist. Judge it by whether Google indexed them and whether they earn impressions for the queries you built them for.
After publishing the first one or two pages, run each URL through URL Inspection in Search Console to confirm it is indexed and that Google selected your URL as canonical. Over the following weeks, open the Performance report and filter by a query containing the town name, or by the page itself, to see whether it is collecting impressions and clicks for local searches (the sign the page is doing its job). Keep the Page indexing report in view: “Discovered – currently not indexed” points at a crawl and internal-linking problem, while “Crawled – currently not indexed” points at a quality and uniqueness problem, and the two need opposite fixes.
So here is the sequence worth following. Build one location page properly, with real local substance and a link from your locations hub. Validate that it indexes and starts earning local impressions in Search Console. Only then build the next area, and only for areas where you can say something equally true and specific. Expand town by town on the strength of pages that actually rank, and stop the moment you are down to swapping names, because that is the exact point where more pages stop helping and start putting the whole set at risk.