Local business schema for AI search: what we add and why

Somebody on every local project eventually asks whether adding schema will get the business into ChatGPT. Our answer is that we add LocalBusiness markup to every location page, and that we can't tell you how each AI engine uses it. We haven't seen documentation from the AI engines that says. What Google does document is how LocalBusiness markup works for Google Search and Maps, so that's what we build to. For AI search, we treat the markup as hygiene and then measure what happens.

What Google's documentation actually says

Google's Local Business structured data page describes the markup as a way to tell Google about things like business hours and departments, for business details in Search and Maps. It lists two required properties, name and address, and a set of recommended ones. It also says plainly that Google doesn't guarantee features that use structured data will show up.

That page is about Google Search rich results. It says nothing about AI chatbots, and we don't stretch it to cover them.

What we add to a location page

We use JSON-LD, one block per location, on the page for that location. The properties we fill in, following Google's page:

• @type: the most specific LocalBusiness sub-type that fits, like Dentist or Plumber, rather than plain LocalBusiness. Google's page says to use the most specific sub-type and, for a business with several, to list them as an array.
• name and address, the two required properties. The address as a full PostalAddress, with street, locality, region, postal code and country.
• url: the URL of this location's page, not the homepage. Google asks for the specific location URL and says it has to work.
• telephone: the number customers should call, with country and area code.
• geo: latitude and longitude. Google asks for at least five decimal places.
• openingHoursSpecification: regular hours, plus seasonal closures with validFrom and validThrough.
• priceRange when it's meaningful, kept under 100 characters, which is Google's limit for showing it.
• department for a location with parts that keep their own hours or phone number, like a store with a pharmacy counter.

What we leave out

We don't add aggregateRating or review to a business's own location page. Google's page recommends those properties only for sites that capture reviews about other local businesses. A clinic marking up its own star rating doesn't fit that description, so we don't do it.

We also don't add facts that aren't on the page. If the page doesn't list a price range, the markup doesn't get one. Markup that says more than the visible page gives anyone reading the source two different versions of the business, and we have no way of knowing which one a given system will trust.

Same facts in three places

The markup is only useful if it agrees with everything else. Before we ship it, we put three sources side by side: the visible location page, the JSON-LD, and the Google Business Profile. Name, address, phone, hours and the location URL must match exactly. That pass catches more problems than the markup itself solves. Our profile checklist is in Google Business Profile and AI answers: what we check.

One small detail we like: the geo coordinates in the markup are the same point we use when we set up a coordinate monitor for that location in Promptwatch. The storefront has one position, and every system we touch uses it.

We validate every block in Google's Rich Results Test before release, as Google's page recommends, and we prefer the JSON-LD to be in the HTML the server sends. Google says it can handle structured data generated with JavaScript, but we can't confirm every AI crawler runs JavaScript, so we don't rely on it.

How we check afterwards

This is where "we added schema" usually ends. We keep going, because we'd like to know whether anything changed, and we'd rather show a client data than a theory.

First, crawler logs. Promptwatch's Agent Analytics logs AI crawler visits, verified by IP so spoofed user agents are filtered out. After a location page is updated, we look at whether bots like GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot and PerplexityBot fetched it, and whether any visits ended in errors. A page that fails for crawlers isn't helped by any markup. The crawl-to-citation view then shows each page's citation rate, so we can see whether a fetched page gets cited. More on reading those logs is in AI crawler logs and the crawl-to-citation path.

Second, citations. We add the location page to Page Tracker and watch whether answers in that location's monitor start citing it, and in which position.

Third, accuracy. The location's monitor includes a few factual prompts: is this location open on Sunday, what's the address, what services does it offer. If the answers start matching the page and markup, good. If they still repeat old hours, the citation data usually points to the stale source that needs fixing, and it's rarely the schema.

We don't attribute any change to the markup alone. Location work changes several things at once, and we tell clients that. What we can show is that the page is consistent, crawlable and being fetched, and whether it's being cited.

Why bother, then?

The cost is a few hours per location, and Google documents what the markup is for in Search and Maps, even if it doesn't guarantee a result. Writing the markup also forces the consistency check across page and profile, which we'd want to do anyway. For AI search, the markup is one more place where the facts are stated cleanly, and the monitors tell us what the engines do with the page. Our broader notes on technical work for AI crawlers are in technical optimization for AI crawlers.

If you want your location pages marked up and checked, email hello@1001seomedia.com.