The structured data an AI actually reads, and why most sites have none

Everything else on your page has to be inferred. An assistant reading your prose is guessing what you sell, where you are and what it costs, and inference is where it invents facts about you. Structured data — a <script type="application/ld+json"> block using the schema.org vocabulary — is the one part it can consume directly, without guessing.

So we measured how much of it is actually out there. Across 292 well-known public sites scanned on 2026-09-06, the result is not what the SEO literature would lead you to expect.

It is not broken. It is missing.

The failure everybody writes about — malformed JSON, a syntax error, a block that will not parse — barely exists. Of the 134 sites that ship any structured data, 0 have a block that fails to parse. Zero. Whatever generated it — a plugin, a framework, a person — produced valid JSON.

The real problem sits one step earlier and one step later. 158 of 292 (54%) of the sites publish nothing at all, and of those that do publish something, 106 describe the wrong thing: a product page carrying only WebSite, an article typed as Organization, a pricing page whose offers are not offers.

The commercial one: your prices are invisible

Of the 70 sites in the sample that show a price on the page, 68 do not publish it in a form a machine can read. The number is on the page as styled text and nowhere else.

This is the finding with a direct commercial edge. When somebody asks an assistant to compare three suppliers, the one whose price sits in an Offer gets quoted exactly. The one whose price sits in a <span class="text-3xl font-bold"> gets described as "pricing available on request", or gets a number read out of the wrong element, or gets left out of the comparison. None of those produce an error anybody sees.

Copy<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Warehouse arm, 6-axis",
  "description": "Reaches 1.8 m, lifts 12 kg, mounts on a standard rail.",
  "offers": {
    "@type": "Offer",
    "price": "41200.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://acme.test/arm-6"
  }
}
</script>

The price goes in as a plain decimal string: no currency symbol, no thousands separator, no "from". "€41,200" is not a price to a parser. It is a string that happens to contain digits.

The one that makes an assistant wrong about you

A quieter failure, and the one we did not expect to find: 37 sites publish structured data making a claim the visible page does not support. The commonest is a phone number — 22 sites declare a telephone in JSON-LD that appears nowhere on the page a human reads. 16 do the same with an email address.

Usually this is a stale template rather than a deception: the number changed on the contact page and the JSON-LD block kept the old one. It does not matter which. An assistant treats structured data as the authoritative answer, so the number it reads out to a customer is the one nobody has answered for two years.

And the typos that ship

10 sites use property names that are not in the schema.org vocabulary at all. The commonest is founders, on 5 sites — the real property is founder, singular. A parser does not correct that. It drops the property and moves on, so the field was written, reviewed, shipped, and has never once been read.

One site in the sample publishes a property called contactOpintion. It has presumably been in production for years.

What to publish, in order

1. One block that types the page correctly. Product on a product page, Article on an article, Organization on the home page. Getting the type right matters more than the number of properties hung off it.
2. The price, as an Offer, if the page has one. This is the highest-value single field on a commercial site and almost nobody publishes it.
3. The facts a customer would ask for: what it is, what it costs, where you are, how to reach you. Then check that each one appears on the visible page too.
4. sameAs links to profiles you control, which is what makes your identity verifiable rather than merely asserted.
5. Delete anything the page does not say. A stale field is worse than a missing one, because it will be believed.

How to check it

Google's Rich Results Test tells you whether a block is eligible for a search feature. That is a different question from whether it is right: a block can be perfectly valid, fully eligible, and describe the wrong thing, and no validator will say so, because none of them read your visible page.

Copynpx axray-cli your-site.com --verbose

The scanner checks presence, type, parse, and the part validators do not: whether each claim is supported by the text an agent actually receives. Ships structured data and Structured data describes the right thing carry the full rules.