Local proof and real service detail per city — and a gate that rejects the cities you cannot support.
We want city pages for 40 metros. Which ones should we actually build?
Nine of forty metros qualify. You have customers in fourteen, but five of those have no measurable search demand for the service-plus-city query, so a page there would be a maintenance cost with no upside. The remaining twenty-six have no local proof at all — building them would risk the nine that can rank.
A location page template that swaps the city name into the same paragraph builds a doorway page set. This one requires genuinely local substance for every page — local customers, local service details, local context — and refuses to generate pages for cities where you have none of it.
A structure for city or service-area pages that specifies which elements must be locally unique: proof, service details, pricing or availability differences, and local context. The template is a set of requirements, not a fill-in-the-blank layout.
By requiring substance that only applies to that location. Google treats near-duplicate city pages as doorway pages, and the practical test is whether a page would still be useful with the city name removed — if yes, it has nothing local in it.
Customers, projects, reviews, or team presence in that area, plus service specifics that genuinely differ. Two or three locally verifiable elements are enough; zero is a doorway page regardless of word count.
Only as many as you have proof for. Ten strong city pages outrank two hundred templated ones, and the templated set can suppress the whole directory once it is classified as thin.
The agent checks service-plus-city demand and the local SERP before writing, and pulls local proof from your CRM, review platforms, or Google Business Profile. Qualified pages publish to Sanity or your CMS with local schema, internal links to the service pillar, and consistent business details.
Plus CRM or review data showing where you actually operate.
Cities without proof or demand are rejected with a reason.
Each page shows which elements are locally unique.
Ship with LocalBusiness or Service schema and links to the service pillar.
Refuses to generate pages for cities without local proof
Every page must survive removing the city name test
Local schema and NAP consistency built in
Checks service-plus-city demand before writing
Local proof, service specifics for that area, contact and coverage details, and links to the service pillar. If removing the city name leaves a page that still makes sense, there is nothing local in it.
They are when they are near-duplicates differing only by city name. Pages with genuine local proof and service detail are legitimate, which is why this template gates the list before generating anything.
As many as you have local proof for. Once a directory is classified as thin, the pages that did have substance get suppressed along with the rest.
The local elements must be unique — proof, service details, coverage. Shared service explanation is fine; a shared page with a swapped noun is not.