Structured data for AI: necessary, and not sufficient

Structured data is the most-recommended fix for AI visibility and one of the least sufficient, for a simple reason: it is embedded in the page. If the page is too expensive to fetch and parse, the markup goes with it.

Scan a URL freeNo account, no card. You get the score and the fix list.

Your business

Products, services and policies

What is missing

Details a customer needs

A clearer answer

Information you can publish

What it does, precisely

Structured data annotates facts already on the page so a machine does not have to infer them from layout. That is genuinely valuable: it removes ambiguity about which number is the price and which string is the opening time, and it is the difference between a parser guessing and a parser knowing.

What it does not do is get your page read. JSON-LD is delivered inside the same HTML document as everything else, so it inherits every delivery problem that document has. A blocked fetch takes the markup with it, and a page too large to be read carries its schema into the part that got truncated.

If this is brokenDoes more structured data help?
The fetch is blocked by a bot ruleNo. Nothing in the page is read
Facts render only after JavaScriptNo, unless the JSON-LD is server-rendered too
The response is enormousMarginally. It is more bytes, not fewer
Facts are present but ambiguousYes. This is what it is for
Prose and markup disagreeNo. More markup deepens the conflict

The failure mode nobody mentions

The most common structured-data defect in our scans is not missing markup. It is markup that contradicts the visible text: a price updated in the template but not the JSON-LD, hours changed on the page but not in the schema, a product marked in stock by a block that no longer runs.

An assistant given two versions of a fact picks one, fluently, and nothing in the answer signals that there was a conflict. This is worse than having no structured data at all, because the confident wrong answer is indistinguishable from a right one.

The order that works

  1. Confirm the page is fetched and parseable. Everything else is downstream of this, including your markup.
  2. Fix disagreements before adding types. Diff the visible facts against the JSON-LD on one page of each template. Fix what conflicts.
  3. Cover the facts people ask about. Price, availability, hours, location, fees, eligibility. Coverage beats exotic types.
  4. Then serve the facts cheaply too. Content negotiation gives the parser the same facts without the document they were buried in, so it never has to reach the markup at all.

What this does not do

Frequently asked questions

Does structured data help with AI search?

Yes, but conditionally. It removes ambiguity about facts already on the page, which is real value. It cannot help if the page is never fetched or is too expensive to read, because the markup is embedded in that same page.

What schema types matter most for AI?

Coverage of the facts people actually ask about matters more than the type list: price, availability, hours, location, fees and eligibility. Exotic types are a poor substitute for the common ones being complete and correct.

What if my structured data and page text disagree?

Fix it before adding anything. An assistant will pick one version, state it confidently, and give no sign there was a conflict. The durable fix is printing both from the same stored values so they cannot drift apart.

Is structured data enough on its own?

No. Treat it as necessary and not sufficient: it makes a readable page unambiguous, and it does nothing at all for a page that was never readable.