Structured data for AI: what to mark up, and what only describes your website

What structured data does, and what nobody promises it does

Structured data is a vocabulary, schema.org, written into a page in one of two syntaxes: JSON-LD, a script block defined by a W3C Recommendation, or microdata attributes on the HTML elements themselves. Either way it labels facts the visitor can already see. A parser that reads "telephone": "+1 512 555 0100" does not have to work out which of the four numbers on the page is the one to call.

What it does not do is rank anything or oblige anyone. Google's introduction to structured data recommends JSON-LD and requires the markup to describe content visible on the page, and its general guidelines say plainly that correct markup does not guarantee a feature will appear. Google's page on AI features adds that no special markup is required for AI Overviews or AI Mode. No other assistant operator publishes how, or whether, it weighs schema.org markup at all.

So the honest claim is narrow. Markup does not get you named. It makes the facts an assistant would need, if it were about to name you, unambiguous. A business whose address appears in one form in the footer, another on the contact page and a third in markup has given the parser three answers, and the audit found that to be the common case.

What 9,483 small business sites had in their markup

In our audit of 9,483 small business websites (40 trades, 90 metros, September 2026) only 17.8% had no schema.org markup at all, which surprised us. The other 82% mostly carried what a page builder emits by default: WebSite, WebPage, BreadcrumbList, SearchAction, ImageObject. Every one of those types describes the website. None of them says what the business is, where it is, or when it is open.

The types that do say those things were rare. LocalBusiness appeared on roughly a quarter of sites, and a further 13.7% carried business markup with the fields that would make it usable left empty or missing. The no-schema rate was not even across trades: real estate agents (33.6%), photographers (32.7%), tax advisors (31.0%) and wedding planners (30.1%) were worst; carpenters (15.8%) and moving companies (16.1%) best among the trades with a hundred or more sites in the sample. Markets barely differed: the EU at 20.5%, the UAE at 20.0%, the US at 17.5%, Canada at 17.2%.

Read together with the rest of the audit, the markup gap is a symptom. 43.1% of the same sites were inconsistent about who and where they are across their own three main pages, and 34.1% had no postal address a machine could parse anywhere. Markup cannot state a fact the page does not agree with itself about. The order of work follows from that: settle the facts, then mark them up.

Markup that describes the business

These are the types worth an afternoon, with the properties an assistant would want to lift. Each links to its definition and, where Google documents how it reads the type, to that page.

Two of these come with a warning in Google's own documentation. The review rules say ratings must come directly from users and must not be aggregated from other websites, and a LocalBusiness page showing reviews of the business itself is not eligible for review stars. And Google no longer shows an FAQ rich result for anyone: it limited the result to government and health sites in August 2023, removed HowTo results the same year, and stopped showing FAQ results in Search on May 7, 2026. FAQPage markup still states your question-and-answer pairs in a form any parser can read; it just earns no dropdown under a Google result, and anyone selling it as if it did is out of date.

Markup that describes only your website

WebSite, WebPage, BreadcrumbList, SearchAction and ImageObject are what most page builders emit without being asked. They are not wrong. A BreadcrumbList tells a parser where a page sits in the site, and Google reads it for the path under a result. But if that is all a site carries, a parser learns that the site has a homepage, a search box and some images, and nothing about the business that owns it. That was the state of most of the 82%.

Keep what the builder wrote, and add the business types beside it. The one thing to check is that the two halves agree: the name on the WebSite node and the name on the LocalBusiness node should be the same string, and both should be the string in the page's title and footer.

A block you can copy

One JSON-LD script in the head or body of the homepage, and the same identity block on the contact page. Swap the type for your trade's subtype, fill in only what is true, and delete any property you cannot fill rather than leaving a placeholder. There is no rating in it on purpose: a business's own page earns no review stars, and a rating copied from a platform is one Google's rules say not to aggregate.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "@id": "https://www.example.com/#business",
  "name": "Your company name",
  "url": "https://www.example.com/",
  "telephone": "+1 512 555 0100",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1200 Example Street",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "areaServed": ["Austin", "Round Rock", "Cedar Park"],
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"], "opens": "07:30", "closes": "18:00" }
  ],
  "priceRange": "$$",
  "sameAs": ["https://www.example-directory.com/your-listing"]
}
</script>

Three habits keep it honest. Write the facts once, in the markup and in the visible page, from the same source: the address in the JSON-LD is the address in the footer, character for character. Give the business node an @id so the Service, Article and Review nodes on other pages can point at it instead of restating it. And when a fact changes, change it everywhere on the same day; a phone number that is new in the footer and old in the markup is the 36.9% problem in a new coat.

The mistakes that make markup useless

• Placeholders. A telephone of "+1 000 000 0000" or an empty address is worse than none: it states a wrong fact with confidence. 13.7% of the audited sites had business markup in roughly this condition.
• Facts that differ from the page. Google's structured data policies require the markup to describe the visible content; a parser that finds two answers trusts neither.
• Markup on the homepage only. The contact page and the service pages are what a fetcher opens for a specific question; they need the identity block too.
• Reviews the business wrote, or an aggregate rating with no reviews behind it on the page. The review snippet rules are explicit, and the trust you would earn from a real 4.8 is what a fake one spends.
• FAQPage whose questions are not on the page, or whose answers paraphrase the visible ones. The pairs in the markup should be the pairs a reader sees, word for word.
• Expecting a rich result. HowTo results went in 2023 and FAQ results on May 7, 2026, for every site. Mark up for the parser that reads facts, not for a feature that no longer exists.

How to check what your site states

1. View the source of the homepage and search for application/ld+json and for itemtype. What comes back is what any parser gets.
2. Read the types. If every one is WebSite, WebPage, BreadcrumbList, SearchAction or ImageObject, the site describes itself and not the business; that is the 82% pattern.
3. Compare the values with the visible page: name, address, phone, hours. Any difference is an error in one of the two places; find out which and fix both from one source.
4. Paste the block into a structured data validator, then read the warnings for the properties Google says it reads for your type. A warning on a property you cannot fill truthfully is a property to delete, not to fake.
5. Repeat on the contact page and on the service page a buyer would open. Then confirm the crawlers can fetch those pages at all; markup on a page behind a bot wall was never read by anyone.

Markup is the last of the four things we check before we measure a business, after access, identity and answers, because it can only restate what those three settled. Done in that order, it is an afternoon. Done first, it is an afternoon spent labeling contradictions. What the assistants then say is what the measurement is for.