Before You Publish City SEO Pages: A Query-to-Page Intent Map

Before You Publish City SEO Pages: A Query-to-Page Intent Map for French Service Businesses

A page for “plumber in Nantes” is useful only if it helps someone in Nantes decide what to do next. Replacing Nantes with Rennes in a template does not make the second page useful. The practical question is not how many city pages a team can publish; it is which distinct customer tasks its real locations or service operations support, and what evidence each URL can show.

For a working example of how this decision can be grounded in a real French-market page, see our French site-positioning guide. This article adds a narrower operational tool: a query-to-page map that tells a small team when to keep a branch page, when to create a service-area page, when to strengthen a service page, and when to stop multiplying URLs. It does not promise rankings and it does not treat a unique paragraph as a substitute for a genuinely distinct customer need.

The decision in one minute

Create a separate city or branch URL when three things are true: the business can actually serve that place; the page can prove a material local difference that changes a customer’s decision; and the page has a clear role in the site’s navigable structure. If one statement is false, start with the existing service or location page and improve it. A city name in a title, a map screenshot, or a paragraph written from a template is not enough evidence.

A real branch and an area served are different things. A branch page represents a place customers can visit or contact as a distinct operating location. A service-area page represents the way a business serves customers without claiming a storefront in every town. Those pages should answer different questions. A branch page may need opening hours, accessibility, staff, stock, and directions. An area page may need service boundaries, travel fees, appointment coverage, response windows, and the nearest team. If the business cannot truthfully give those details, it does not yet have the information needed for a useful local page.

This is an editorial and product decision, not a ranking forecast. Google describes doorway abuse as creating pages for similar queries or locations that funnel people toward the same destination, and scaled-content abuse as producing unoriginal pages primarily to manipulate search visibility. That policy is a reason to test the page’s user job before production; it is not a formula saying a particular word count or similarity percentage is safe. See Google’s spam policies for its definitions and examples.

What the evidence can and cannot tell you

The baseline is familiar: search documentation explains crawling, canonical selection, localized variants, and spam policies; local SEO guides recommend useful location experiences; forum questions repeatedly ask whether city pages cause cannibalization, whether one business should build many pages, and what can be different without inventing local details. The unresolved operational question is how a small team should decide page by page before writing. This article supplies a repeatable classification and evidence worksheet instead of another generic list of ranking factors.

For prioritization, one Search Console page row reviewed on 3 November 2026 showed 458 impressions and an average position of 19.51 for the SEO-True French positioning guide. The extracted row did not state its lookback period, so these values are only a snapshot used to choose a source page for this research. They are not a benchmark, trend, or evidence that location pages caused those impressions. The sample is one page row; query composition, device split, country split, and the date range were not inspected in that extract. A practitioner should open Search Console, choose a known date range and search type, then inspect query and page combinations before making a content decision.

There is tension in the advice. Google cautions against sets of near-identical location pages that route users to one destination. Local practitioners discuss legitimate situations where one business really serves multiple towns and local proof can help visitors. A Local Search Forum thread asks whether a service-plus-city URL makes sense for a business with one location and nearly identical services. “Duplicate content” is often shorthand for several separate problems: same intent, unsupported service claims, poor navigation, canonical confusion, or pages with no local value. Diagnose the actual failure before choosing a fix.

The customer task comes before the keyword

Start with the task behind the query. “Service + city” can mean a person wants a nearby provider, wants to know whether the company travels there, needs a physical office, or wants general advice that applies to the area. Those tasks can belong on different page types. Search volume alone cannot tell you whether the destination should be a branch page, service-area page, service guide, or locator.

The following map is an original reusable worksheet. Its cases are synthetic; they are not an empirical sample of businesses or ranking outcomes. Replace each hypothetical service, town, detail, and proof item with records verified by the business.

Query or customer task	Likely destination	Evidence before publication	Merge or stop condition
Find the nearest open branch	Branch page or locator	Address, current hours, contact route, visitor access, directions	No distinct visitable branch: do not label an area page as one
Check whether a trade serves a town	Service-area page or service section	Dispatch boundary, appointment coverage, travel fee, realistic response window	The service is not actually available there
Compare a service in one town	Local service page only if the offer changes there	Availability, constraints, project example, pricing or delivery difference	Same service, process, proof, and next step: consolidate
Learn how a service works across France	National service page or guide	Complete explanation, eligibility, price logic, process	No local task: keep national intent on one page
Ask about directions, phone, or access	Branch page	Operational details checked by the local team	Details missing or stale: a locator may be safer
Ask about a local rule or process	Explanatory guide, possibly linked from local page	Authoritative local source and impact on the task	Local mention does not change answer: no city landing page
Compare several towns before choosing	Locator or regional hub	Accurate coverage map, comparison criteria, route to each team	Avoid a directory of thin pages funneling to one form
Request a quote where coverage varies	Service-area page or quote flow	Covered postcodes or communes, exclusions, costs, eligibility	Form cannot route by area
Ask for emergency response	Service page with maintained availability	Actual opening, escalation, staffing, service terms	No verified emergency capability: do not imply immediacy
Research a local project	Case study, optionally linked locally	Permission, place, scope, dates, outcome evidence, caveats	No project or permission: do not invent one
Find a specialist in an underserved area	Service page or referral route	Provider identity, qualifications, availability, referral process	No provider and no truthful service route
Visit a named office	Branch page	Verified location, who receives visitors, appointment rules	Mailbox or nominal address only: do not imply a staffed office

A row is not permission to publish. It is a hypothesis about what the page needs to answer. The team should name the question, the facts that answer it, the person who verifies those facts, and the next action a visitor can take. If it cannot do that, it should not schedule a URL yet. Treat the map as an interface between content and operations, not a quota. A new route should begin with a documented question and end with a destination a person can use without guessing which team owns the request.

An important distinction is the difference between a task and its wording. “Plumber Nantes,” “boiler repair Nantes,” and “emergency plumbing Nantes” may indicate one service team or three different service conditions. Conversely, several phrases that share no words may mean the same task. Have operations explain the offer, coverage, hours, fee, and call to action for each group. Let verified service distinctions decide whether separate URLs make sense; let phrase variations guide language on the chosen page.

A practical page-intent scorecard

Use this scorecard in a workshop with sales, operations, and the site owner. It is not a Google scoring system. Each item is a yes/no gate. A “yes” needs a record or a person who can verify it, not a writer’s intuition.

1. Service truth: Is the named service available in the named area? Record who confirmed it and when.
2. Place truth: Does the URL represent a real branch or honestly described service area? Do not imply an office where there is none.
3. Decision difference: Would a visitor make a different choice based on coverage, price, timing, access, stock, route, eligibility, or a local rule?
4. Evidence: Can each material claim link to a source record, staff confirmation, public authority, or documented operating rule?
5. Next step: Can the visitor call, book, request a quote, compare, or find the right branch without an irrelevant intermediary page?
6. Site role: Can the URL be reached from a service page, locator, or regional hub that explains the relationship?
7. Maintenance owner: Is someone accountable for changes to hours, coverage, price, or staffing?
8. Distinct task: Does this URL answer a need an existing page does not already answer more clearly?

Interpret the result as a release gate, not a score. If service truth, place truth, evidence, or next step is “no,” do not publish. If distinct task or site role is “no,” test whether an existing page or a regional hub can do the job. If ownership is “no,” solve that before creating URLs. Passing every gate means the idea is ready for drafting; it does not imply Google will index or rank it.

The scorecard is binary because a fabricated “7.5 out of 10” can make weak facts look precise. Red, amber, and green labels can help only when their thresholds are explicit. Red might mean there is no operations confirmation or no safe contact route. Amber might mean facts exist but no one accepted maintenance. Green might mean all critical assertions are sourced and reviewable. The colour summarizes a release decision, not ranking probability.

Original asset: a 12-case local-page release test

This synthetic acceptance test can be run before a developer builds routes. These are design cases, not observations from a customer dataset, and they do not predict search performance. The point is to expose false local claims and duplicate page jobs before they spread through a CMS.

Case	Proposed page	Test question	Expected decision
1	“Agency in Lyon,” staffed address	Can visitors verify who is there and how to visit?	Branch page if operations confirms
2	“Agency in Villeurbanne,” same Lyon team	Is there a separate visit or service task?	Do not imply a second branch
3	Weekday-only emergency repairs	Are real hours and exclusions clear?	Keep only without implying 24/7
4	Service not dispatched to that town	Can the company fulfill the call to action?	Reject the page
5	Town with different travel fees	Can the boundary and rule be explained?	Candidate page with dated fee rule
6	Local project with client permission	Are place, scope, and proof real?	Case study with limited claims
7	City page with only swapped town names	What decision fact does the visitor gain?	Merge or do not publish
8	Hub linking three real branches	Does it help choose a location or service?	Keep if it improves navigation
9	Many postcode URLs to one national form	Does each route change coverage or destination?	Replace with one coverage explanation
10	Address is only a coworking mailbox	Is it a customer-facing operating location?	Do not represent it as a branch
11	City FAQ generated from national FAQ	Does the answer materially vary by town?	Keep on national service page otherwise
12	Regulated service with local process differences	Can the rule be sourced and reviewed?	Keep with source, scope, owner, review date

For every candidate, attach a page record to a ticket or spreadsheet. Minimum fields are proposed URL, page type, task, service owner, area owner, evidence links, canonical preference, internal links, last verified date, review trigger, and decision. A synthetic row could read: “/services/boiler-repair/nantes/; service area; determine whether an engineer visits; dispatch map version 4 confirmed by operations; show covered postcodes and fee rule; regional operations reviewer; draft allowed.” This is an example of record structure, not a claim about a real company.

The page record separates four things often mixed together: the query hypothesis, the operational fact, the content claim, and the measure used later. An impression is not proof of delivered service. A call is not proof of organic rank. A form submission is not proof the visitor received the right answer. Record those steps independently so the team can tell whether a change helped discovery, service routing, or task completion.

Reproducible build sequence

Make publishing the final step after evidence and routing checks.

1. Export query and page pairs for a declared Search Console period.
2. Group queries by likely task, not just shared city or service words.
3. Map each task to an existing URL, branch record, service record, or evidence gap.
4. Ask operations to confirm delivery, access, hours, exclusions, price, and contact route.
5. Select one destination per distinct task; merge competing pages with the same job.
6. Draft from verified facts and mark unknowns instead of guessing.
7. Check canonical, indexability, language variants, navigation, and form destination.
8. Review the page on mobile as a visitor who does not know the company.
9. Publish only after the gates pass; save the baseline and review date.
10. Recheck after an operational change, not only after rank movement.

Runnable pre-publish record check

This small Node.js example validates a proposed page record before it enters the CMS. It deliberately fails closed on missing operations evidence; it does not assess ranking potential, legal compliance, or whether the prose is genuinely useful. The sample record is synthetic. Replace it with a real record and keep the named owner and verification date.

const page = {
  url: "/services/boiler-repair/nantes/",
  pageType: "service-area",
  task: "Check engineer coverage and travel cost",
  serviceAvailable: true,
  evidence: ["dispatch-map-v4", "travel-fee-rule-2026-10"],
  verifiedBy: "regional-operations",
  verifiedAt: "2026-10-30",
  nextStep: "postcode-coverage-checker",
  maintenanceOwner: "regional-operations",
  reviewTrigger: "dispatch-boundary-or-fee-change",
  canonical: "https:" + String.fromCharCode(47, 47) + "example.test/services/boiler-repair/nantes/"
};

function validate(record) {
  const required = ["url", "pageType", "task", "verifiedBy", "verifiedAt",
    "nextStep", "maintenanceOwner", "reviewTrigger", "canonical"];
  const errors = required.filter((key) => !record[key]);
  if (record.serviceAvailable !== true) errors.push("serviceAvailable must be confirmed true");
  if (!Array.isArray(record.evidence) || record.evidence.length === 0) {
    errors.push("at least one evidence reference is required");
  }
  const secureScheme = "https:" + String.fromCharCode(47, 47);`n  if (!record.canonical || !record.canonical.startsWith(secureScheme)) {
    errors.push("canonical must be an absolute HTTPS URL");
  }
  return errors;
}

const errors = validate(page);
if (errors.length) {
  console.error("BLOCKED:", errors.join("; "));
  process.exitCode = 1;
} else {
  console.log("RECORD READY FOR HUMAN INTENT AND TECHNICAL REVIEW");
}

Run it with node check-local-page.js after saving the code in a file. A passing result only means the record is complete enough for human review. It does not prove that a local URL should exist. A manager still needs to compare the task with current pages, inspect real search evidence, validate the service route, check the page in context, and verify technical signals in the target environment. Keep the output with the page record so later editors can see whether a decision was based on current facts or assumptions.

flowchart TD
 A[Query or customer request] --> B{Can the business serve or host here?}
 B -- No --> C[Do not create local URL; correct coverage info]
 B -- Yes --> D{Does locality change the customer's decision?}
 D -- No --> E[Use existing service page or locator]
 D -- Yes --> F{Can operations prove and maintain the difference?}
 F -- No --> G[Collect evidence and assign owner]
 F -- Yes --> H{Does another page already answer this task?}
 H -- Yes --> I[Improve or merge the existing destination]
 H -- No --> J[Draft one page with proof, route, review date]
 J --> K{Technical signals and contact route verified?}
 K -- No --> G
 K -- Yes --> L[Publish and measure against a declared baseline]
~~~

The diagram exposes an important point: a local-page idea can fail before copywriting begins. If the business does not serve a town, changing the title cannot fix service truth. If locality does not alter the customer’s decision, adding more paragraphs cannot make two pages serve different jobs. If evidence exists but no one maintains it, a page can be accurate on launch day and misleading later. The least costly fix is upstream of the CMS.

## Query grouping in Search Console

Search Console helps find query/page overlap, but it shows a reported view of search behavior, not a person’s intent with certainty. Set a date range, keep search type constant, and choose a country or device segment only when the decision needs it. Export query, page, clicks, impressions, CTR, and average position, and save the settings with the export so a second analyst can reproduce the selection.

A practical group is task-based. “Plombier Nantes dépannage,” “réparation chaudière Nantes,” and “urgence plomberie Nantes” may or may not be one task. Ask whether they correspond to the same offer, team, opening conditions, and next step. Variants with different wording may still express the same task. Do not make a page assignment solely because a query contains a different commune.

Build a small query-to-page matrix with one row per query group and columns for existing URL, page type, business evidence, search data, intent, and proposed action. If several URLs receive impressions for one group, inspect the actual queries and page content before calling it cannibalization. The pages may serve different tasks, or the search engine may be uncertain about which URL best satisfies one task. Those cases require different remedies.

No data for a town does not prove no need. It can mean the site has not been discovered, the query is rare, reporting suppresses low-volume data, or the business has not established local service. Use call logs, quote requests, interviews, service records, and public geographic data as separate evidence sources. Label how each source was collected. Do not manufacture a search-demand estimate from a few conversations.

Preserve the difference between average position and a stable rank. The average can vary across query, device, country, and time. It should not be translated into “we rank at position 19 everywhere.” Use it to prioritize inspection. When a broad page serves several queries, a single mean can hide different page jobs. Open the page row, examine the available query set, and ask what a visitor needs for each cluster.

## Canonical and hreflang: solve the right problem

A local service page that differs in language, region, or service rules can have a legitimate relationship to another page. A city page with a different town token but identical core information does not automatically have a language relationship. Do not add hreflang between city URLs just because both are French. Do not canonicalize all town pages to the national page to hide thin material if the local pages truly serve different tasks. A self-referencing canonical is not a substitute for useful content or navigation.

Google describes a canonical as the representative URL it selects from similar content. A site can signal a preference, but Google may choose another URL. Signals can include redirects, links, sitemap inclusion, and the content Google considers more complete and useful. See [Google’s canonicalization overview](https://developers.google.com/search/docs/crawling-indexing/canonicalization). If a distinct branch page keeps being canonicalized to a national URL, investigate content, internal links, and sitemap treatment. Verify Google’s selected canonical in URL Inspection; do not infer it only from the HTML source.

Use hreflang for genuine language or regional alternatives intended for different audiences. Each alternative should refer to itself and to reciprocal alternatives, with absolute URLs. Google’s [localized-versions guide](https://developers.google.com/search/docs/specialty/international/localized-versions?hl=en) gives the implementation rules. A French page for France and a French page for Belgium should not differ only in footer, currency, or a place name when the body otherwise serves the same person in the same way. If the service rules, delivery, price, eligibility, or support differ, explain and substantiate that distinction.

Technical QA cannot decide page intent, but it can catch implementation errors. Check final response status, redirect destination, rendered canonical, robots directives, sitemap inclusion, internal links, alternate links, and form route. Search Console URL Inspection can report the selected canonical and indexing context. Preserve both the site’s declared signals and Google’s interpretation. A mismatch may require content or architecture changes, not just replacing a tag.

## Claims, proof, and local facts

Local pages tempt writers to make confident claims from public context and generic industry knowledge. Separate claims the business controls from facts it borrows. “Our engineers cover postcode X” is an operating promise dispatch must confirm. “The office is near the station” may be verifiable, but the useful detail might be a route, parking, or entrance access. “We understand local homeowners” is broad and needs real evidence or should be removed.

Use an evidence ledger. For each sentence that could change a decision, record claim, source, owner, date checked, expiry trigger, and whether the evidence is public or internal. Public sources can establish official boundaries or administrative procedures. Internal records can establish hours, appointment lead time, stock, or fees. A testimonial supports one customer’s experience, not a universal outcome. A case study shows a particular job, not what every customer can expect.

When public geographic or census data helps, link the exact source and explain its unit and date. A population count does not prove a company serves the town; a boundary map does not prove travel time; a local event does not establish year-round demand. These distinctions stop a page from sounding authoritative while substituting context for operational proof.

If evidence is missing, a coverage checker that asks for a postcode, a locator that lists only actual branches, or a national page with service subject to confirmation may be the right product. Honest uncertainty is better than invented local details. The customer can still take a next step if the page offers a transparent way to confirm availability.

## What guides and videos miss

Many guides begin with an element checklist: name, address, phone, map, reviews, photos, and FAQs. Those can help a real branch page, but an inventory is not a page-selection method. A map may repeat the locator. A testimonial may be national. A city FAQ may rephrase a national answer. Ask whether each element changes this customer’s decision.

The [Wix webinar replay on local landing pages](https://www.wix.com/seo/learn/resource/how-to-create-local-landing-pages-for-seo) discusses multiple data sources, user-generated questions, and location-specific context. A useful second practitioner perspective is the [Ahrefs guide to location landing pages](https://ahrefs.com/blog/location-pages/), which describes how presence, service-area claims, internal structure, and local evidence fit together. Treat both guides as practical perspectives, not as independent ranking experiments or guarantees. Its practical insight is that a reusable layout can coexist with local details. Its limitation is that a webinar is a practitioner session, not a controlled ranking experiment; it cannot establish how many URLs a business should publish or prove a ranking effect. Use it as a design prompt: collect genuine local questions, then validate the proposed page against service evidence.

Search results contain strong claims in both directions: create a page for every town or never create city pages. Google’s policy is narrower. It describes abuse patterns involving similar queries, location-targeted pages, and intermediate destinations, while its canonical documentation recognizes legitimate regional variants. The conclusion is conditional: a city URL is neither automatically harmful nor automatically deserved. Its value depends on whether it represents a distinct job and whether the business can fulfill its promise.

Forum participants often describe two failure modes: pages differing only by town names, and several URLs aimed at nearly the same service intent. Others argue pages can work when they show local projects, coverage, staff, or facts that change a customer’s decision. This is anecdotal and generally lacks stable search settings or comparison groups. Use it to discover questions, not to make causal claims. A comment that traffic fell after pages were added does not prove the pages caused the decline.

## Failure modes to prevent

**The city-token page.** Copy changes the town name while service, coverage, evidence, form, and next step remain the same. Paraphrasing does not repair the problem. Choose one destination for the shared task and add local pages only when the service difference can be shown.

**The false branch.** An area served is described as an office with implied staff or walk-in access. Correct the page type and wording. Do not create a presence customers cannot verify.

**The impossible call to action.** A page invites quotes from an area operations does not cover. Connect service boundaries to the form and disclose exceptions before submission.

**The unique-content checkbox.** Editors add a landmark paragraph or weather detail. Textual uniqueness does not guarantee decision value. Ask whether the fact changes which provider, date, cost, or route the visitor chooses.

**The canonical bandage.** Every local page points to the national page because the owner fears duplicate content, even though branches have distinct addresses and tasks. Decide whether pages are true alternates, duplicates, or separate resources; then make canonical and alternate signals consistent with that decision.

**The canonical wish.** A page points to itself but Google selects a national URL. Inspect redirects, internal links, sitemap, visible content, and URL Inspection. The tag is a signal, not a command.

**The regional-language mismatch.** hreflang points to missing, nonreciprocal, redirected, or not meaningfully localized URLs. Validate each alternate, including its self-reference, and do not use language markup for unrelated city pages.

**The unowned page.** Hours, fees, and coverage go stale. Assign a named owner and a change trigger such as new routes, price changes, or staffing changes.

**The impression-only victory.** Impressions rise, so the team declares success even though visitors cannot book or get service. Pair search measures with operational outcomes; do not claim causation from a before-and-after chart.

**The no-data veto.** No impressions are treated as proof that no customer needs the service. Search Console is not the only evidence source. Ask service desk, quote, and dispatch teams, while recording what those signals cannot establish.

## Measuring whether the page helps

Write the intended outcome before launch. A branch page might support calls to the correct office, route clicks, or appointments that branch can serve. A service-area page might support eligible quote requests, fewer out-of-area submissions, or more accurate expectations before contact. These are user and business outcomes, not ranking guarantees.

Define events carefully. A phone-link click is not a completed call. A form submission is not a qualified request. A quote request outside coverage is a routing failure, not a lead win. Where possible, join page URL, declared area, contact outcome, and service acceptance using a privacy-respecting internal identifier. Limit access and avoid collecting personal data just to attribute a page. The UK Information Commissioner’s Office advises organizations to collect only personal data needed for the stated purpose and to make relevant privacy information accessible; see its [small-organization data-protection advice](https://ico.org.uk/for-organisations/advice-for-small-organisations/getting-started-with-gdpr/data-protection-advice-on-common-topics/). This is a privacy design reminder, not a substitute for jurisdiction-specific legal review.

Use a stable baseline: record page set, date range, query/page pairs, country, device, search type, and major site changes. If many pages change together, do not attribute the result to one title, FAQ, or link. If practical, introduce changes in a controlled sequence and choose a comparison group similar in service and demand before launch. Selecting a control after seeing results invites bias.

Search performance is noisy. Seasonality, competitor changes, algorithm updates, outages, opening hours, and local demand can move results without a content change. Record these events. “Eligible calls increased during the period after rollout” is descriptive; “the landing page caused the increase” requires a credible causal design. The measurement plan should specify what would cause the team to revert or merge pages, not only what would count as success.

A page can help without ranking for its target phrase by reducing misrouted calls or helping an existing visitor find the right branch. Conversely, an impressive impression count cannot excuse advertising unavailable service. Keep separate measures for discoverability, task completion, and operational fit. Preserve the source and window used for each measure so a later reader can reproduce the comparison.

## A small-team review ritual

For each URL, schedule a brief review with an editor and an operational owner. Read the page as if you were a customer arriving from a result. What is different in this place? What can be verified? Can the visitor complete the next step? What becomes misleading if it goes stale next month? If the answer is “we can add that later,” the page is not ready.

The editor checks intent, plain language, hierarchy, internal links, title, and overlap with existing URLs. Operations checks service availability, boundaries, hours, fees, contact destination, staff claims, and local evidence. A technical reviewer checks rendering, canonical, robots directives, sitemap, internal discovery, and language alternates. One person can hold several roles in a small team, but each decision still needs an explicit pass or unresolved status.

Keep a “not yet” state. A business may need to map dispatch boundaries, confirm travel pricing, or ask a branch manager about walk-ins. This can improve operations even if no new page results. A content calendar should distinguish research required, draft allowed, technical QA, and published instead of turning every keyword idea into a URL.

Review facts when they change, not only on a calendar cadence. A quarterly review can catch drift, but an operational change should trigger an immediate update. The page record should name triggers such as branch opening or closure, a new route, a price change, a seasonal pause, revised coverage, or a new rule. If nobody can tell whether a claim changed, assign an owner or remove the claim.

## Release checklist

- [ ] This URL represents a real customer-facing branch or an accurately described service area.
- [ ] The service owner confirms the offer is currently available in that place.
- [ ] The page answers a local decision that an existing URL does not answer more clearly.
- [ ] Evidence supports every local claim that could change a customer’s action.
- [ ] The call, booking, quote, direction, or comparison route is operational.
- [ ] A service page, locator, or regional hub links to this page in a clear hierarchy.
- [ ] The title does not imply a branch, guarantee, or emergency response that does not exist.
- [ ] Status, canonical, robots, sitemap, internal links, and language alternates are checked.
- [ ] Search Console comparison has a declared date range and saved query/page export.
- [ ] A named owner and factual update trigger are recorded.
- [ ] The team defined what would trigger a merge, rewrite, or removal from navigation.

## The final rule

A city page earns its place when it is a truthful, reachable destination for a distinct customer task and has evidence the business can maintain. If a visitor gets the same answer and next step from an existing service page, keep one destination. If a real branch or coverage difference changes the decision, make that difference visible, verifiable, and maintainable.

The output is not a target page count. It is a record linking a customer task to a real service, a page, proof, an owner, and an outcome measure. That record is useful even when the answer is “do not publish.” A smaller set of accurate pages can give people a reliable route to the right service; a larger set without distinct tasks can be harder to navigate and maintain.

## Sources

- [Google Search spam policies: doorway abuse and scaled content abuse](https://developers.google.com/search/docs/essentials/spam-policies)
- [Google Search Central: canonicalization](https://developers.google.com/search/docs/crawling-indexing/canonicalization)
- [Google Search Central: localized versions](https://developers.google.com/search/docs/specialty/international/localized-versions?hl=en)
- [Wix webinar: local landing pages for SEO](https://www.wix.com/seo/learn/resource/how-to-create-local-landing-pages-for-seo)
- [Ahrefs: location landing pages](https://ahrefs.com/blog/location-pages/)
- [UK ICO: data protection advice for small organizations](https://ico.org.uk/for-organisations/advice-for-small-organisations/getting-started-with-gdpr/data-protection-advice-on-common-topics/)
- [Local Search Forum: URL structure and location-page overlap](https://localsearchforum.com/threads/local-seo-help-url-structure-causing-cannibalization-ranking-drop.62434/)
- [Search Engine Land: location page SEO](https://searchengineland.com/guide/location-pages-seo)

## Method and limits

The twelve release cases are synthetic acceptance examples designed for this article, not observations of businesses or search outcomes. No ranking lift, performance rate, sample-wide conclusion, or citation likelihood is reported. One Search Console page row reviewed on 3 November 2026 contained 458 impressions and average position 19.51; the extracted record omitted date range, query breakdown, country, and device. It was used only to prioritize an existing source page for deeper research. The forum and webinar are discovery evidence for questions and practitioner viewpoints, not controlled experiments. Google documentation is the primary source for policy and technical statements attributed to Google. Recommendations are operational inferences from these sources and the synthetic release test; actual page decisions require each business’s verified service records.