LocalBusiness schema for AI search: locations, hours and service areas

LocalBusiness schema works best when every real customer-facing location has its own indexable page and its own structured-data node. Mark up the exact name, address, phone, hours and location type shown on that page, then keep those facts synchronized with business profiles and operational systems. For businesses that travel to customers, describe the genuine service area without publishing a fake storefront. Schema must match visible page facts and is not a guaranteed AI ranking factor.

Model a location, not a keyword target

Choose the narrowest correct subtype, such as Dentist, Restaurant or AutoRepair, only when the location actually performs that function. Give each branch a stable @id based on its canonical location URL. A national brand can be the parent Organization while each shop, clinic or office is a separate LocalBusiness node. Do not create nodes or landing pages for cities where no distinct location or legitimate service operation exists. That pattern creates confusing evidence for people and machines and may conflict with platform policies.

Encode operational facts with precise scope

• Use PostalAddress components exactly as presented to customers and include country context.
• Publish a direct local telephone number when available rather than an unrelated tracking number.
• Represent weekly schedules with openingHoursSpecification and explicit day coverage.
• Add specialOpeningHoursSpecification for known holiday closures or temporary seasonal changes.
• Use geo coordinates sourced from the actual entrance or verified business record.
• Describe areaServed only for regions the team can genuinely support under stated conditions.

Build location JSON-LD from the same source that powers store finders and operational notices. The schema generator provides a useful draft, and the schema validator can identify syntax and vocabulary problems before release. Visible hours should include qualifications such as appointment-only periods, kitchen closing times or emergency availability rather than compressing different services into one misleading schedule. Avoid aggregate ratings, price ranges, amenities or payment methods unless the corresponding location page supports those claims.

Test the local information customers actually ask for

1. Fetch every location page and confirm a successful response, canonical URL and unique location node.
2. Compare the visible name, address, phone and hours with the rendered JSON-LD.
3. Check official map, directory and social profiles for material conflicts.
4. Test holiday exceptions, overnight hours, multiple departments and temporarily closed locations.
5. Ask assistants about the nearest eligible location, current hours and supported service area.
6. Record answers, citations and test time before correcting the authoritative public record.

Start with an AI visibility scan, then monitor a stable set of local-intent prompts in ModelSaid. Include city, neighborhood, service and constraint terms that real customers use, but do not manufacture dozens of nearly identical prompts solely to claim coverage. Classify errors such as wrong branch, outdated schedule, unsupported service or closed location. Pair answer monitoring with phone, booking and direction-request data where appropriate, while avoiding claims that an assistant response directly caused every conversion.

Service-area businesses require extra restraint. Publish a real contact page and explain how customers confirm eligibility, travel charges and appointment availability. areaServed can name an AdministrativeArea or other supported geographic entity, but it should not imply a staffed address in every municipality. If the business also has a public office, distinguish visits by appointment from walk-in opening hours. For departments at one address, decide whether customers experience separate locations or one business with department contact points. Consistent modeling prevents a search for an emergency service, showroom or clinic from leading someone to an address that cannot actually help them. When coverage follows postal codes rather than city boundaries, explain the lookup or confirmation method visibly and avoid forcing a broad geographic label into the markup. Customers need the operational answer, not an artificially large service footprint.

Create an operating process for location changes

Location schema fails most often after ordinary business events: a holiday, relocation, new phone system, temporary closure or franchise transfer. Give operations a single update workflow that changes the visible page, JSON-LD and controlled profiles together. Alert on differences between the location database and deployed markup, and archive old URLs with accurate redirects or closure explanations. Valid LocalBusiness data can make public facts easier to reconcile, but it cannot guarantee inclusion, citation or higher placement in an AI answer. Accuracy at the moment a customer acts is the meaningful standard.