How to Build City Pages Without Doorway Page Risk

Google's spam policies, last updated August 28, 2026, name the pattern this article is about: "Having multiple domain names or pages targeted at specific regions or cities that funnel users to one page." That is doorway abuse, in Google's own words, and it describes what a city-page template does when nobody checks whether the branch behind each page is real.

So multi-location service brands hit the same page-architecture question: should every city, suburb, and service area get its own page?

The old answer was often "publish more local landing pages." That advice creates trouble when a 40-location HVAC group, franchise system, restoration roll-up, or med spa brand turns one template into hundreds of pages with the city name swapped. The pages may look efficient in a spreadsheet. To a customer, they look thin. To Google, they can drift toward doorway abuse when they exist mainly to rank for similar local queries and send everyone to the same generic destination.

AI search makes the problem easier to spot. Google AI Mode can use query fan-out across related searches and sources. ChatGPT search, Perplexity, and other answer systems can inspect the public pages and sources available to them. If the Plano page says "emergency garage door repair" but the Business Profile, reviews, citations, phone path, and service page do not support that claim, the page is not stronger because it has a city in the title.

For multi-location teams that need this governed across branches, Cheers' multi-location local SEO platform connects city, service-area, branch, review, and profile decisions into one operating system.

When a city page deserves its own URL

Google's spam policy defines doorway abuse as pages created to rank for specific, similar search queries that lead users to intermediate pages less useful than the final destination. The policy gives local examples: multiple pages or domains targeted at regions or cities that funnel users to one page, and substantially similar pages that are closer to search results than a clear browseable hierarchy.

For local service operators, that turns the decision into a customer test.

The prompt data argues for fewer pages, too. Across the Cheers panel over the 28 days ending September 2, 2026, 119 home-services organizations tracked 3,635 classified buying prompts, aggregate only. 2,209 of those, 60.8%, were best-or-top questions with no place name at all. Only 324, 8.9%, named a place or said near me. And the place-named shape had the lowest pooled appearance rate of any group, 22.8% against 28.9% for the placeless best-of prompts. Publishing a page per suburb chases the smallest and hardest slice of the demand your own prompt set describes. The prompt-shape cut is in the home-services AI visibility index, with the classification rule in the methodology.

A page deserves to exist when a buyer in that city can learn something specific: which branch or team serves them, which services are actually available, what proof exists in that market, how fast the team can respond, which phone or booking path reaches the right office, and how the page connects to the rest of the brand.

A page does not deserve its own URL when the only local fact is the city name. A copied "AC repair in {city}" page, a list of nearby towns with no service proof, or a franchise page that routes every visitor to the same generic form is not a useful local source. It is a search-targeting asset with weak customer value.

What should location pages include for AI search? covers the broader location-page standard. The doorway-risk version is narrower: before writing copy, decide whether the page has enough local substance to stand alone. For the locator system that links those pages together, see Should location finder pages be indexable for AI search?.

Why AI search raises the quality bar

Google says its AI features use the same foundational Search requirements: pages should meet technical requirements, follow Search policies, and focus on helpful, reliable, people-first content. Google also says there are no extra technical requirements for AI Overviews or AI Mode, and no special AI schema or machine-readable file that makes a weak page qualify.

That matters because city pages cannot rely on formatting tricks. AI search visibility still starts with pages that can be crawled, indexed, internally linked, understood in text, and supported by Business Profile information and structured data that match visible copy.

Crawler policy is a supporting check, not the strategy. Public branch, service, and proof pages should not be accidentally blocked from the search fetchers the brand wants to support. Which AI crawlers should local businesses allow? covers that technical decision.

AI Mode adds another practical issue. Google says AI Overviews and AI Mode may use query fan-out, issuing related searches across subtopics and data sources. A local service query can expand into coverage, service fit, reviews, hours, booking paths, photos, and third-party sources. What query fan-out means in Google AI Mode explains that retrieval behavior in more detail.

For a multi-location brand, the page has to survive those checks. A city page for "water damage restoration in Mesa" should agree with the Business Profile service area, the location or market page, the restoration service page, recent review themes, citations, phone routing, and the structured facts on the page. If those sources disagree, the city page may create more confusion than visibility.

Choose the page type before choosing the keyword

The safest architecture decision comes before copywriting. Decide what kind of page the customer needs.

A branch page

Use a branch page when the business has a real location, storefront, office, franchisee, studio, property, or service base that customers or crews can identify. The page should explain the local entity: address when appropriate, phone path, hours, team, services, reviews, photos, credentials, and the parent brand relationship.

For a med spa group, the Columbus studio page is a branch page. For a hospitality group, each property page is a branch page. For a home services roll-up, a staffed office or dispatch base may be a branch page if it represents a real operating location.

A service-area page

Use a service-area page when the business travels to customers and the page needs to explain coverage. Google Business Profile guidance says service-area businesses visit or deliver to customers directly and do not serve customers at the business address. The profile itself is bounded: you can set "up to 20 service areas based on the cities, postal codes, or other areas you serve," and Google's representation guidelines add that a profile's overall service area "shouldn't extend farther than about 2 hours of driving time from where your business is based," with larger areas appropriate for some businesses.

That guidance should shape the website page. A service-area page should read like the public version of the dispatch rule: which team covers the market, which services are available there, what changes for emergency work, and how the customer reaches the right team. How service-area businesses should show coverage for AI search goes deeper on that source stack.

A market hub

Use a market hub when several nearby cities share the same branch, same dispatch rule, same services, and limited unique proof. A strong "North Dallas service area" hub can be more useful than 18 thin suburb pages. It can list the cities served, explain service rules, link to the services that matter, and route customers clearly without pretending every suburb has a separate operating story.

The page type controls the URL. The keyword should follow the customer job, not the other way around.

What makes a city page defensible

A defensible city page has local proof that would still matter if search engines did not exist.

• Real service coverage: the branch, franchisee, crew, studio, property, or dispatch rule serving the market.
• Real service detail: the jobs available in that city, plus constraints such as emergency hours, financing, warranties, eligibility, or exclusions.
• Real customer proof: review themes, job examples, photos, credentials, citations, or staff context tied to that market.
• Real conversion path: a phone number, form, booking flow, or appointment route that reaches the correct local team.
• Real hierarchy: internal links from the brand, branch, service, and area pages that make the page easy to find without relying on search.

The page does not need every possible proof type. It needs enough proof to answer the customer's local question honestly.

For an HVAC branch in Phoenix, a Mesa AC repair page may stand if the Phoenix East team really dispatches to Mesa, handles after-hours AC repair there, has recent customer proof, and routes calls correctly. For a restoration roll-up after an acquisition, a new market page may stand if it explains the acquired branch, emergency coverage, certifications, equipment, insurance coordination, and updated brand relationship. For a franchise with 80 locations, a city page may stand when it maps to the correct franchisee or local territory and does not imply coverage the franchisee cannot deliver.

If that proof is missing, write a stronger service-area hub first. Then add city pages only when operations can support them.

Where doorway risk shows up

Doorway risk usually appears in patterns, not in one bad paragraph.

The first pattern is city-name swapping. A plumbing site creates 75 pages with the same copy, same services, same reviews, same photos, same FAQ, and only the city changed. The pages target similar queries, but they do not give the buyer a city-specific answer.

The second pattern is funnel pages. A franchise site creates pages for cities it barely serves, then sends every visitor to one generic brand page or booking form. Google calls out pages targeted at regions or cities that funnel users to one page as a doorway-abuse example.

The third pattern is city-list stuffing. Google separately names blocks of cities and regions as a keyword-stuffing example when they appear unnaturally or without substantial added value. A page that says it serves every town in a state without explaining real coverage is not doing local customers a favor.

The fourth pattern is scaled content. Google's spam policy says scaled content abuse can include many pages generated mainly to manipulate rankings and not help users, no matter how the pages are created. AI-assisted page generation does not change the rule. If the content is unoriginal and low-value at scale, the risk stays.

These are governance problems. Marketing may own the page, but operations owns the truth behind the page.

How to consolidate weak city pages

Many multi-location sites already have weak city pages. The fix is not always deletion. Start by assigning every page one of three outcomes: improve, merge, or retire.

Improve pages that have real market value but weak evidence. Add visible service rules, local proof, internal links, photos, review themes, citations, and a cleaner conversion path. Make structured data match the visible content instead of adding hidden claims.

Merge pages when several URLs describe the same operating reality. Google's canonical guidance says redirects, rel canonical annotations, and sitemap inclusion can help signal the preferred version of duplicate or very similar pages. For a service-area brand, that may mean consolidating 12 near-identical suburb pages into one stronger market hub and redirecting the old URLs when they no longer serve a distinct customer job.

Retire pages that represent services, cities, addresses, or coverage the business no longer offers. If a page needs to stay live for users but should not appear in Search, use noindex carefully. Do not use robots.txt as a canonicalization tool, because Google says it may still index disallowed URLs without their content.

After consolidation, update internal links. The site should link to the strongest branch, service, and market pages consistently. Is Google Business Profile enough for AI visibility? is useful here because the same local facts need support beyond the profile.

A 30-day city-page governance workflow

Start with the markets where thin local pages create the most risk: acquired brands, franchise territories, emergency services, service-area businesses, and high-value suburbs where competitors are cited in AI answers.

• Week 1: Export every branch, city, service-area, and service-plus-city URL. Group pages by branch, market, service, template, traffic, conversions, internal links, and indexed status.
• Week 2: Mark each URL as branch page, service-area page, market hub, duplicate, retired service, or unsupported city. Ask operations to confirm the coverage behind priority pages.
• Week 3: Improve the pages with real local value. Consolidate or redirect near-duplicates into stronger hubs. Remove city blocks, copied FAQs, reused proof, and unsupported claims.
• Week 4: Recheck the same market prompts in Google AI Mode when available, AI Overviews, ChatGPT search, Perplexity, and standard Google Search. Record which source each answer used and which page still needs proof.

Score each URL against the same four checks the page needs to survive: customer job, coverage proof, source support, and hierarchy. A page that fails the customer job check should merge. A page that has coverage proof but weak source support should improve. A page with no hierarchy is usually a linking and architecture problem, not a copywriting problem.

The useful output is not a bigger page count. It is a cleaner source system: one page per real local job, clear hierarchy, profile facts that agree with the website, and enough proof for a customer to choose the correct local team.

For AI search, that is the safer bet. The answer engine may inspect several sources before naming a provider. Give it fewer pages that say more true things. If the choice is whether to run this consolidation in-house or hand it to an agency, Cheers compared with an SEO agency sets out who owns which part of the work.

Sources

Every link below was opened and checked on September 2, 2026.

• Spam policies for Google web search. Google Search Central. Last updated August 28, 2026, checked September 2, 2026. developers.google.com/search/docs/essentials/spam-policies. Source of the quoted doorway-abuse example, plus the keyword stuffing and scaled content abuse definitions.
• Manage your service areas for service-area and hybrid businesses. Google Business Profile Help. Undated help page, checked September 2, 2026. support.google.com/business/answer/9157481. Source of the quoted 20-service-area limit and the service-area business definition.
• Guidelines for representing your business on Google. Google Business Profile Help. Undated help page, checked September 2, 2026. support.google.com/business/answer/3038177. Source of the quoted roughly two-hour driving-time boundary for a profile's overall service area.
• AI features and your website. Google Search Central. Checked September 2, 2026. developers.google.com/search/docs/appearance/ai-features. Supports the guidance that AI Overviews and AI Mode use Search foundations, may use query fan-out, require indexed pages eligible for snippets, and need no special AI files or schema.
• Google's guide to optimizing for generative AI features on Google Search. Google Search Central. Last updated July 10, 2026, checked September 2, 2026. developers.google.com/search/docs/fundamentals/ai-optimization-guide. Supports the focus on unique, expert-led, people-first content rather than GEO shortcuts or AI-specific files.
• How to specify a canonical URL with rel canonical and other methods. Google Search Central. Checked September 2, 2026. developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls. Supports the consolidation guidance for duplicate or very similar URLs.
• LocalBusiness. Schema.org vocabulary. Undated type page, checked September 2, 2026. schema.org/LocalBusiness. Supports LocalBusiness as a branch-level entity type.
• areaServed. Schema.org vocabulary. Undated property page, checked September 2, 2026. schema.org/areaServed. Supports the definition of areaServed as the geographic area where a service or offered item is provided.
• Overview of OpenAI crawlers. OpenAI Platform documentation. Checked September 2, 2026. developers.openai.com/api/docs/bots. Supports the point that OAI-SearchBot is separate from training crawlers and is used to surface websites in ChatGPT search features.
• Perplexity crawlers. Perplexity developer documentation. Checked September 2, 2026. docs.perplexity.ai/docs/resources/perplexity-crawlers. Supports crawler-access considerations for PerplexityBot and Perplexity-User.
• Home Services AI Visibility Index 2026. Cheers Research. Cheers panel, 28 days ending September 2, 2026, 119 home-services organizations, aggregate only. cheers.tech/research/home-services-ai-visibility-index-2026. Source of the tracked prompt counts and pooled appearance rates by prompt shape.

Last verified: September 2, 2026.

Amadeus Peterson is the CTO & Co-Founder of Cheers, the local search platform for multi-location service businesses.