Schema markup for local businesses and AI search

Google says there is no special schema.org markup you need to appear in AI Overviews or AI Mode, so structured data is not a shortcut to being recommended. It is still worth adding LocalBusiness markup, because it states your name, address, hours, phone and services in a form machines can read without guessing. Keep it accurate and make it match the visible page.

This guide covers what to add, a worked example, where to put it and the mistakes to avoid.

Do you need schema for AI search?

No, and the platforms are clear about it. Google’s AI features guidance says there are no additional requirements to appear in AI Overviews or AI Mode, and that you don’t need machine-readable files, AI text files or markup. It also says structured data should match the visible text on the page.

So why add it? Three reasons that don’t depend on a ranking claim:

• It removes guesswork. A crawler reading a paragraph has to infer your opening hours. Markup states them.
• It supports Google’s own features. Local business markup is documented for Search, and Google says to validate it with the Rich Results Test.
• It forces you to decide your canonical facts, which helps every other step in getting recommended.

Think of it as tidy facts, not a lever.

Which properties to include

Google’s local business guidance lists name and address as required and recommends adding as many properties as possible. These are the ones we would fill in for a service business:

Property	Status	Notes
name	Required	Exactly how it appears on your site and profile
address	Required	A PostalAddress with street, locality, postcode, country
telephone	Recommended	Include country and area code
url	Recommended	The page for this specific location
openingHoursSpecification	Recommended	Day, opens, closes in hh:mm:ss
geo	Recommended	Latitude and longitude, at least five decimal places
priceRange	Recommended	Under 100 characters
image	Useful	A real photo of the business
areaServed	Useful	The places you serve, if you travel to customers
sameAs	Useful	Your official profiles, to tie the entity together

Use the most specific subtype that fits, such as Dentist, and you can give more than one type as an array. LocalBusiness is a subtype of Organization, so Organization fields apply too.

A worked example

This is for the fictional Lakeside Dental Studio. The domain and phone number are placeholders.

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://lakesidedental.example/hackney/#clinic",
  "name": "Lakeside Dental Studio",
  "url": "https://lakesidedental.example/hackney/",
  "image": "https://lakesidedental.example/images/hackney-clinic.jpg",
  "telephone": "+44 20 7946 0000",
  "priceRange": "££",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Example Street",
    "addressLocality": "London",
    "postalCode": "E8 1AA",
    "addressCountry": "GB"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 51.54530,
    "longitude": -0.05530
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00:00",
      "closes": "18:00:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "09:00:00",
      "closes": "13:00:00"
    }
  ],
  "areaServed": ["Hackney", "Islington", "Camden"],
  "sameAs": ["https://www.facebook.com/lakesidedental.example"]
}

Place it in a <script type="application/ld+json"> tag in the page’s HTML. Google’s examples use JSON-LD.

Where to put it

• Home page: an Organization or LocalBusiness block for the business as a whole.
• Each location page: one block for that location, with that location’s address, phone and hours.
• Service pages: you can describe the service in the visible text and reference the same business with the same @id. Keep the markup simple.

Don’t paste one block onto every page with only the city swapped. If the visible page doesn’t match, the markup is wrong.

How to test it

1. Run the page through Google’s Rich Results Test and fix critical errors. Non-critical warnings are worth fixing but aren’t required.
2. Use the URL Inspection tool to confirm Google can reach the page and that it isn’t blocked by robots.txt, noindex or a login.
3. Submit or update your sitemap, and allow several days for recrawling.

The Rich Results Test can’t catch spammy or misleading markup, so the check that matters most is the human one: read the markup next to the visible page.

Common mistakes

• Markup that doesn’t match the page. Hours in the JSON that differ from the hours on the page. Google says structured data should match the visible text.
• Self-serving review markup. Google’s guidance says review and aggregateRating are for sites that capture reviews of other local businesses. Marking up your own five-star average isn’t what the property is for.
• Invented or stale facts. Update the markup whenever hours, phone or address change.
• Duplicate conflicting blocks. A plugin adds one block and a theme adds another with different details.
• Treating it as an AI trick. It isn’t, and Google says so.

What about FAQ and Service markup?

You can describe services and common questions in visible text, and that text is what assistants and people read. We include FAQ markup on our own pages when the questions and answers are visible, but we don’t expect it to change whether an assistant names us. Spend the effort on the page content first.

RankWeb drafts the LocalBusiness markup for each location page and shows it next to the page for your approval, so the markup and the visible text stay in sync.