For a service business covering multiple cities, the right AEO architecture is almost always one strong entity with an explicit multi-city service area — not separate per-city entities. One Google Business Profile (per physical location, not per served city), one Schema.org Organization with every city enumerated in areaServed, and one website with distinctive per-city pages. Splitting into per-city entities — multiple GBPs without real offices, city-specific microsites, “Mesa Plumbing Pros” and “Chandler Plumbing Pros” brand variants — fragments the corroboration that citation share is built on, and usually violates Google’s guidelines on top of it. The exceptions are narrow and worth knowing, but the default is consolidation.
This is the most common architecture question we get from Phoenix-metro contractors, because almost nobody here operates in one city. A Mesa-based HVAC company realistically serves Mesa, Chandler, Gilbert, Tempe, and Queen Creek before lunch. The question is how AI answer engines should understand that — as one business or five.
Why fragmentation loses
AI citation is built on entity strength: how confidently a model can resolve who you are across every source that mentions you. Every signal your business generates — a review, a directory listing, a news mention, a schema block — either accrues to one entity or gets divided among several.
Split into five per-city presences and each one gets roughly a fifth of the reviews, a fifth of the mentions, a fifth of the history. In our own market audits, a consolidated business with 120 reviews and consistent citations beats five 24-review fragments on effectively every prompt — including the city-specific prompts the fragments were built for. The model would rather cite a strong entity that verifiably serves Chandler than a weak entity named after it.
Fragmentation also creates the disambiguation problem we’ve written about before in the entity-signals context: five similar names, overlapping phone numbers, and shared ownership signals read to a model like possibly the same business, possibly not — and uncertain models cite someone else.
What “one entity, multi-city” looks like concretely
One Google Business Profile per physical location. If you have one office in Mesa, that’s one GBP, set as a service-area business, with your served cities listed — five to ten, not thirty. A second staffed location justifies a second GBP. A P.O. box or a virtual office in Chandler does not, and Google suspends profiles for it regularly.
One Organization in schema, every city enumerated. Your areaServed should list each city as its own entity — Mesa, Chandler, Gilbert, Tempe, Queen Creek — not just “Phoenix metro.” Models match city-qualified prompts against city-level fields; a metro-level blanket is weaker for “plumber in Gilbert” than an explicit Gilbert entry.
One domain, distinctive per-city pages. City pages on your main site are correct and useful — if each says something true and specific about your work in that city: the neighborhoods you’re in most, the housing-stock quirks you see there, response-time realities from your actual base. A template with the city name swapped is the doorway-page pattern that both Google and LLM retrieval discount. Four strong city pages beat seven interchangeable ones; write the cities you can say something real about.
One name everywhere. The same legal name, same formatting, on every listing in every city. The temptation to register city-keyword brand variants (“Gilbert’s Best Roofing”) is the fragmentation trap with extra steps.
The narrow cases for splitting
Genuine exceptions exist:
- Truly separate staffed locations. A second office with its own crew and phone line is a real location. Give it a GBP, a location page, and its own reviews flow. This is multi-location, not fragmentation — the entities are real.
- Distinct service lines under distinct brands. If your residential and commercial operations run as separate businesses with separate books, they can be separate entities. Split because the businesses are different, never because the cities are.
- An acquired brand with strong local equity. If you buy a 30-year-old Chandler company whose name carries weight, keeping its entity alive (clearly linked to the parent via
parentOrganizationschema and consistent cross-references) can preserve corroboration you’d otherwise torch. Migrate slowly or not at all.
None of these are “we serve six cities.” Serving six cities is what areaServed is for.
How city-specific citation actually gets won
Under a consolidated architecture, the per-city work shifts from creating entities to creating city-level evidence for the one entity:
- Reviews that name the city. When you ask for reviews, suggest customers mention their city — “if you have a sec, mentioning you’re in Gilbert helps us a lot.” A review saying “replaced our water heater same-day here in Gilbert” is city-level retrieval material attached to your consolidated entity. This is the highest-volume lever, covered in more depth in our reviews piece.
- City-level list presence. Each city has its own “best of” lists, chamber directories, and community threads feeding AI answers for that city’s prompts. Placement work is per-city even when the entity is singular.
- City pages that earn their existence. Per the above — real content about real work in that city, question-shaped headers, specifics a template can’t fake.
The test
If you’re weighing any multi-city structure decision, ask: does this concentrate evidence on one entity, or divide it among several? Concentration wins on every AI surface we track. The multi-city business that presents as one clear, heavily-corroborated entity — verifiably active in every city it claims — is the one the models can cite with confidence. Confidence is what citation is.