How to build city pages without doorway risk in AI search

Multi-location service brands usually 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.

The useful test: would this page help a customer in that city?

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.

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.

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. It also says service areas should be specific and accurate, cannot be set as a radius, and should usually stay within about two hours of driving time from the business base.

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.

Sources

• Google Search Central: spam policies for Google web search. Supports the doorway abuse, keyword stuffing, and scaled content risk definitions used in this article.
• Google Search Central: AI features and your website. Supports the guidance that AI Overviews and AI Mode use Search foundations, may use query fan-out, require indexed pages eligible for snippets, and do not need special AI files or schema.
• Google Search Central: optimizing your website for generative AI features on Google Search. Supports the recommendation to focus on unique, expert-led, people-first content instead of GEO shortcuts or unnecessary AI-specific files.
• Google Search Central: how to specify a canonical URL. Supports consolidation guidance for duplicate or very similar URLs, redirects, canonical annotations, and sitemap signals.
• Google Business Profile Help: manage your service areas. Supports service-area and hybrid business definitions, specific service-area rules, and the recommendation to remove an address when customers are not served there.
• Schema.org: LocalBusiness. Supports LocalBusiness as a branch-level entity type.
• Schema.org: areaServed. Supports the definition of areaServed as the geographic area where a service or offered item is provided.
• OpenAI: overview of OpenAI crawlers. Supports the point that OAI-SearchBot is separate from training crawlers and is used for surfacing websites in ChatGPT search features.
• Perplexity docs: Perplexity crawlers. Supports crawler-access considerations for PerplexityBot and Perplexity-User.

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