Local landing pages at scale
Local Landing Page SEO for Brands With Forty Cities and One Template
Local landing page SEO fails in a predictable pattern: the same page with the city name swapped. It passes a template review and fails a reader. We build city pages from local inputs that cannot be copied to the next city, then connect them to the store and service pages they should never compete with.
- City page templates with real local inputs
- Clear split between service, store and city pages
- NAP consistency and location structured data
- Nearby-city and service cross-linking
- Publishing gates that block thin pages
We will tell you which of your city pages we would not publish.
The city page trap, in three parts
Almost every multi-location site we audit has the same three problems. They are cheap to create and expensive to unwind, because by the time you notice, forty pages share one body of text.
The swap test
Take the page, replace the city name, and read it again. If nothing is wrong, the page is a doorway with a local header. It has no address, no local proof, no local constraint, no reason to exist except a keyword.
Search engines reach the same conclusion faster than readers do.
Three pages, one intent
A service page, a store page and a city page all target “emergency plumber” in the same metro. They split links, confuse the reader about which one to open and leave the strongest URL underfed.
Every page needs one job, stated in its title and delivered above the fold.
Proof that is not local
A testimonial from a client in another country, stock photography with foreign plates, a map centered on the wrong suburb, a phone number that routes to a national queue. Each one is small. Together they tell a reader the page was assembled, not written.
Three page types, three different jobs
Most duplication problems start before any copy is written. If the site does not separate the offering, the facility and the market, all three end up chasing the same query.
| Page type | Question it answers | URL shape | What belongs on it |
|---|---|---|---|
| Service page | What exactly do you do, and how does it work? | /services/roof-replacement | Process, materials, warranty terms, pricing factors, project gallery |
| Store or facility page | Where are you, when are you open, who is there? | /locations/austin-tx | Street address, hours, team names, parking, service radius, map |
| City landing page | Can you serve this market, and do you know it? | /roof-replacement/austin | Local demand context, coverage map, local projects, local rules, travel time |
The city page is not a thinner store page, and it is not a service page with a place name bolted on. It is the page that proves you understand a market: the housing stock, the weather that damages it, the permit office that slows it down, the competitors the reader is also calling. That content cannot be templated across cities, which is exactly why it works.
If you serve one metro rather than forty, most of this still applies with a much shorter checklist. Our Local SEO For Small Business work covers that narrower case, where the profile, the service page and a single city page have to carry everything.
The anatomy of a city page that holds up
Eight blocks, in this order. The first two decide whether a reader stays; the rest decide whether they believe you and whether they contact you.
Two rules keep the template from becoming a formality. The local evidence block must name something that exists only in that market — a project, a permit office, a neighborhood, a weather event. And the first hundred words must contain a local fact the reader can verify, not a claim about being trusted since 1998.
The duplication checklist we run before publishing
Our working rule: if more than half the body could appear unchanged on another city page, the page is not ready. Run this list and the decision is usually obvious.
Unique opening. The first hundred words mention a place, a condition or a project that belongs to this market.
Named evidence. At least one project, review or case study with a real local detail.
Real coverage. The map or list names suburbs and travel times instead of a single pin.
Local constraint. A permit, climate, building stock or logistics fact specific to the area.
Consistent NAP. Address, phone and hours match the profile and the store page character for character.
Distinct FAQ. Questions a local buyer asks, not the same four across forty cities.
No orphan. Linked from the locations hub, two nearby cities and the matching service page.
One canonical. No competing store page or old city URL still live for the same intent.
The checklist is deliberately mechanical, so a content editor can enforce it without a strategist in the room. Pages that fail two or more items stay in draft, and the fix is content, not a title rewrite.
Linking forty cities without a mesh
The obvious internal linking pattern is wrong: link every city to every other city and you create a mesh where each page passes a hundred weak signals and receives a hundred weak ones.
We build a hierarchy instead. A locations hub lists every market with its status and links down. Each city page links up to the hub, sideways to three or four genuinely nearby markets, and across to the two service pages that market actually buys. The service pages link down to the strongest cities for that service, not all of them. Breadcrumbs match the same path in markup and on screen.
That gives a crawler a clear depth of three: home, hub, city. It also gives readers a reason to move sideways — a neighboring city is a plausible next click in a way that a city four hundred miles away never is. When a new market launches, it inherits links from the hub and its neighbors on day one instead of waiting for a sitemap to be noticed.
Once the estate passes roughly twenty markets, the work stops being a page project and becomes a programme: shared taxonomies, region grouping, profile management and reporting by market. That is the territory covered by Multi-Location SEO, and it is usually the right frame before a fifth region is added.
NAP, schema and the boring consistency that pays
Local signals are mostly unglamorous: the same address everywhere, the same phone number, hours that match, a map that points at the right door. The markup only makes that consistency legible.
One record per real place
A physical location gets a location page, a LocalBusiness node with a stable identifier, a full postal address, geo coordinates, opening hours and the same phone number used in the footer, the profile and every citation. Service-area markets without a facility do not get a fake address; they get a Service node with an areaServed list, attached to the organisation.
Ratings only where they exist
Aggregate ratings are emitted only when first-party reviews are visible on the page and the numbers match. A city page with no local reviews shows none, and that is fine — an invented rating is a liability that outlives the campaign that created it.
Same data, same order
Street, unit, city, region, postal code, country. The same sequence in the visible block, the markup and the profile. Abbreviations are standardised across the site, because “St.” in one place and “Street” in another is exactly the ambiguity local systems are trying to resolve.
Cross-check the profile
The business profile, the store page and the city page must agree on name, category, hours and phone. When they disagree, the page that loses is usually the one you spent the most on. We keep a reconciliation sheet and review it quarterly.
Producing forty pages without forty times the work
Scale comes from a content model, not from a generator. The model defines which blocks are shared, which are local, and who supplies the local inputs.
Twelve fields per market
Coverage suburbs, typical job, local permit or licensing note, climate or building-stock factor, travel and response time, two named projects, one local review, the local team lead, price drivers, seasonal peak, nearest depot, and the local question buyers actually ask. Fill the fields and the page almost writes itself.
Twenty minutes with the city lead
The person who runs the market already knows the permit office, the neighborhoods and the complaints. A recorded twenty-minute call produces more usable local detail than a month of desk research, and it keeps the page honest about what the team can actually deliver.
Draft, review, publish
No page publishes with fewer than eight filled local fields. A second editor checks for the swap test, the checklist above and NAP accuracy. At scale, the gate matters more than the writing, because the failure mode is forty pages that all pass a spell check.
How the build runs
Every city URL, its intent, its status and the page it competes with.
Decide which markets get a store page, which get a city page, which get neither.
Blocks, fields, markup and the editing rules that hold them together.
Interviews, evidence collection, first ten pages written and reviewed.
Hub links, neighbor links, NAP checks, monitoring by market.
Three multi-location builds
5 months: 38 city pages rebuilt from interviews and project data; organic inquiries 5 → 23 per month; 11 markets now hold first-page positions for service plus city terms.
6 months: three conflicting page types merged into a store page plus a city page per market; calls attributed to organic up 34%.
4 months: 22 templated city pages cut to 14 with real local content; sessions on the retained set +19%, conversion rate 1.8x.
Client accounts under NDA, measured against a pre-engagement baseline. Markets with no local demand do not become demand because a page exists, which is why the page map comes before the copy.
Pick two cities and we will read them side by side
One that performs and one that does not. The difference usually explains the other thirty-eight.
What changes the scope
No price list. Four inputs decide the size of the job: how many markets you serve, how many of them have a physical location, how much local data already exists in your systems, and whether the template needs rebuilding or only editing.
Template and model
Field definitions, block order, markup and the editorial checklist. This is the part that makes the next thirty pages cheaper than the first three.
First ten pages
Written and reviewed with your team, so the standard is set by example rather than by a style guide nobody reads.
Rollout support
Review queue, NAP reconciliation and launch monitoring per market. We can run it or train your team to.
Questions we hear from multi-location teams
How many cities can we launch at once?
Ten to fifteen is a sensible first wave, because the first batch teaches you where the local data is thin. Publishing forty at once hides those lessons inside a large release and makes the diagnostics harder.
Will forty city pages not be duplicate content?
They will be if the only variable is the city name. With eight or more local fields filled — evidence, coverage, constraints, team — the pages diverge naturally. Our checklist exists because good intentions do not survive a deadline.
Can we rank in a city where we have no office?
You can compete for service queries with a genuinely useful city page, and you should not pretend to have an address you do not have. That means no fake local business markup and no invented reviews. The page wins on local knowledge, not on a fictional storefront.
How does the business profile fit in?
It is the anchor for a physical location: same name, category, hours and phone as the store page. City pages without a location do not get a profile, and we do not create one to chase a map result.
Should city pages sit in the main navigation?
A locations hub belongs in the navigation. Individual cities belong in the hub and in contextual links, unless a market is a primary revenue driver. Forty links in a dropdown is a crawl path nobody enjoys, including the crawler.
How do you measure a city page?
Per market: impressions for service plus city queries, sessions from the local area, calls and form fills attributed to the page, and the share of that market's leads coming from organic. Total site traffic hides exactly the variation you are trying to manage.
Can our own team write the pages?
Yes, and it is usually better. We supply the model, the fields, the checklist and the first ten examples; your city leads supply the knowledge. We review the queue until the standard holds without us.
Do you guarantee map or local pack placement?
No. Local results depend on proximity, profile signals and competition, none of which a page can override. What a page can do is convert the visitors who arrive and support the queries the profile cannot answer.