Multi-city landing pages: how to build one page per city without a duplicate content penalty

A tradesperson serving ten cities, a recruitment firm present in several regions, a franchise with twenty branches: they all share the same intuition — a landing page per city captures local search better than a single "we cover the whole region" page. The intuition is right. The method that usually comes with it is not: duplicating a single page template and only changing the city name. That shortcut produces exactly the kind of pages search engines are built to spot and cluster together — at best, only one of the pages survives in search results; at worst, none do. Here is how to build one page per city that actually captures local search, without falling into the duplicate content trap.

Why one page per city rather than a single page

A search for "plumber Boston" and a search for "plumber Austin" don't carry the same intent: the searcher wants a professional near them, not a company that "covers the whole country". A single page listing every city served answers that intent poorly — it contains neither the address, nor the local landmarks, nor the social proof specific to the searched city. A dedicated page per city, with its own content, answers the query with the precision search engines aim to reward — the same principle detailed in our article on message match: the page must mirror exactly what the person typed or clicked.

The trap: a cloned page with only the city name changing

The most tempting shortcut is also the riskiest: take a "template" page, duplicate it for every city, and only edit the city name in the headline and two or three sentences. The result is a set of pages that are near-identical in text, structure and images — what search engines call near-duplicates. Detecting this is nothing new: as early as 1997, the foundational study by Andrei Broder and his co-authors, published in Computer Networks and ISDN Systems, described the "shingling" technique — breaking each page into overlapping word sequences to measure its similarity to other pages across the web at scale. That approach, or its descendants, still sits at the core of how search engines cluster near-identical pages: they typically index and rank only one representative of the cluster, which condemns every "same page, different city" variant to cannibalize each other rather than complement one another.

The rule: content that is genuinely local per page, not a keyword that changes

The difference between a variant that works and one that gets filtered out comes down to a simple question: if you strip out the city name, is there still content specific to that location left? A multi-city page set that ranks provides, for each city, elements no other page on the site contains.

• A real address and service area — not a list of cities at the bottom of the page, but the branch's actual address or the precise service radius around the targeted city.
• A local team or provider — the name of the branch manager or tradesperson covering that area, with a photo if possible: proof that someone is actually on the ground.
• Testimonials and reviews specific to the city — customers from Boston for the Boston page, not the same generic reviews copy-pasted across twenty pages.
• Local landmarks — neighborhoods served, typical response time, local market specifics (regulation, climate, type of housing) when they actually change something about the service.
• City-specific contact details and hours — a local phone number, distinct branch hours if applicable, a link to that location's Google Business Profile — see our article on the Google Business Profile for how the two complement each other.

What can legitimately stay common across pages — the value proposition, the service walkthrough, the page structure — isn't the problem: search engines can tell a coherent family of pages with specific local content apart from a set of interchangeable pages. The problem is content that's 90% identical with a single variable swapped in.

The technical architecture: one template, per-city content in data

In practice, the right architecture isn't "one file per city copy-pasted", but a single page template fed by data specific to each city — address, team, reviews, service area stored separately and injected into the layout. With Next.js — the stack behind LanderKit templates — that means a dynamic route such as /cities/[slug], generated from a file or database listing the covered cities, in the same static logic described in our comparison Next.js vs WordPress. Three technical points not to overlook:

• Self-referencing canonical tag. Each city page points to its own URL as canonical — never to an "all cities" page — otherwise you're telling search engines yourself to keep only one version.
• Per-city LocalBusiness structured data. A schema.org/LocalBusiness markup (or the relevant business type) with the address and service area specific to each page, in the spirit of our guide on structured data.
• A hub-and-spoke internal linking structure. A "hub" page listing every city covered and linking to each one, with every city page linking back to the hub — this structure helps search engines understand the whole rather than discovering isolated pages.

How many cities to launch at once

Publishing twenty city pages the same day, with local content still rough while reviews and landmarks get collected, is the surest way to reproduce the very trap you're trying to avoid — a batch of thin pages published at once is exactly the profile that quality updates like Panda have historically targeted. It's better to start with three to five priority cities, each with complete and verified local content, then expand gradually once those first pages show signs of correct indexing and positions in Search Console. It's slower, but every page added starts with every chance of being treated as standalone content rather than a suspect variant.

When a single page is enough

Multi-city isn't automatic. A tradesperson working within a 20 km radius of a single city doesn't need ten pages — a single page with a clear service area, like the ones featured in our guides for plumbers and electricians, locksmiths or tradespeople, answers the local intent perfectly well. Multi-city is worth it when there's a real, differentiated presence in each city — a branch, a dedicated provider, a distinct service area — not as an artificial way to multiply indexed pages.

LanderKit's Local Agency template is built for exactly this case: a structure ready to hold per-city content (address, team, reviews), with the delivered source code to build the dynamic route and hub-and-spoke linking described above. Like the other nine templates in the catalog, it's available individually for €89 or in the full pack for €229.

What should stay unique even in shared blocks

One last trap concerns blocks that look secondary: legal notices, the privacy policy, the footer. If they're copied identically across every city page with just the headquarters address, that's not an issue in itself — search engines treat a page's main content differently from its shared structural elements (menu, footer, legal notices). The duplicate content risk concerns the page's main content, the part meant to answer the search intent: that's where the per-city personalization effort needs to concentrate, not the ancillary blocks.