How do AI engines answer local questions?
‘Best dentist open Saturday near me’, ‘does this restaurant take reservations’ — local questions run the same retrieval-grounding-generation-citation pipeline as everything else, but grounding is brutal because the facts are binary: you are either open at 9pm or you are not. The model cross-checks your page, your LocalBusiness markup, your Google Business Profile, Bing Places, map providers and review platforms. Agreement produces confident recommendations; disagreement produces either hedged answers or your exclusion. For brands with many locations this is an entity-management problem as much as an SEO one — see entities and the knowledge graph.
Which LocalBusiness fields matter?
- Type specificity. Use the most precise subtype:
Restaurant,Dentist,Plumber, not genericLocalBusiness. Subtypes carry extra fields (menus, cuisines, priceRange) that answer richer sub-queries. - NAP: name, address, telephone. The identity triad; it must match directory listings character-for-character where possible.
- geo (latitude/longitude). Removes ambiguity for dense urban areas and multi-tenant buildings.
- openingHoursSpecification. Structured hours, including special hours for holidays — a top local-answer failure point.
- sameAs and @id. Link the location to its map profiles and, for chains, to the parent Organization — see Organization schema.
- areaServed / serviceArea. Essential for service-area businesses without storefronts.
A minimal LocalBusiness skeleton
{"@context":"https://schema.org","@type":"Restaurant","@id":"https://example.com/locations/soho#location","name":"Example Bistro Soho","address":{"@type":"PostalAddress","streetAddress":"12 Example St","addressLocality":"London","postalCode":"W1D 3AB","addressCountry":"GB"},"telephone":"+44-20-0000-0000","geo":{"@type":"GeoCoordinates","latitude":51.513,"longitude":-0.136},"openingHoursSpecification":{"@type":"OpeningHoursSpecification","dayOfWeek":["Monday","Tuesday","Wednesday","Thursday","Friday"],"opens":"09:00","closes":"22:00"},"sameAs":["https://www.google.com/maps/place/..."]}
Where do AI local answers pull from beyond your site?
Google’s local answers lean on Business Profiles plus the Knowledge Graph; Bing Places feeds Copilot and, through the Bing index dependency, influences ChatGPT; Perplexity retrieves in real time from whatever sources agree. So the markup is one leg of a tripod: your schema, your claimed map profiles, and your review footprint — see review management. Multilingual and multi-region brands must also keep name variants aligned per market — see multilingual GEO.
Implementation checklist
- Give every physical location its own URL with a complete, subtype-specific LocalBusiness node and a stable
@id. - Synchronize NAP across site markup, Google Business Profile, Bing Places and top directories; audit quarterly.
- Keep holiday and special hours current in both markup and map profiles.
- Link locations to the parent Organization graph by
@id— see JSON-LD nesting patterns. - Track local question visibility monthly in your fixed 50-100 question GEO measurement set.
Common pitfalls
First, stale hours: the fastest local-answer killer, especially around holidays, when local query volume spikes. Second, one markup node for a whole chain — each location needs its own node and page, or engines cannot answer location-specific questions. Third, NAP drift after moves or rebrands, leaving directories contradicting the site. Fourth, fake service areas and virtual offices, which grounding cross-checks against map data. Fifth, forgetting voice surfaces: local questions dominate voice assistants — see voice assistants — where a single wrong fact means a spoken wrong answer with no alternatives offered.
How should chains structure dozens of locations?
At scale, treat location markup as generated data, not copywriting. Maintain one locations database — name, address, phone, coordinates, hours — and generate every location page, every LocalBusiness node and every map-profile sync from it. Give locations a clean URL hierarchy (/locations/city/name/) and interlink them from a locations hub so crawlers reach all of them; see site architecture for AI. Chain-specific fields help too: link each location node to the parent Organization by @id, and use branchOf where the subtype supports it. The failure mode to engineer against is partial updates: a chain that updates hours in map profiles but not site markup has built a grounding contradiction at machine scale. One database, every surface regenerated, no hand edits.
Where to go next
Anchor the parent entity with Organization schema, manage the review leg in Review schema, and register broadly via knowledge graph registration.