Why JSON-LD is still needed, even now that AI reads text itself

I get asked this more and more: why would you still put JSON-LD in your pages, if a language model reads plain text perfectly well? A fair question, and the intuition behind it is mostly right. Still, there's something worth adding; the answer actually turns your question around.

A language model doesn't need a schema to understand text

Let me start with where the objection is right. Put a single page in front of a modern language model and it reads it fine without schema. A price, an author, an opening time; it pulls them straight out of the plain HTML. You don't need JSON-LD to understand the content.

In fact, a lot of the "you have to add JSON-LD for AI" advice is marketing: the old SEO logic sold again, now with an AI sauce on top. If the promise is that a model can't understand your page otherwise, that promise doesn't hold.

The difference: one model versus a system at scale

Here's the flaw in the reasoning. "AI reads the page" is about one model looking at one page, once. But the systems that really matter, a search engine or an AI search system, process billions of pages. They're not going to run a model on every page to find out what the price is; that's slow and expensive.

That's where JSON-LD comes in. Not because the machine can't read your text, but because at that scale it doesn't want to. You read a schema with simple, deterministic code: a parser, in milliseconds, without inference. Static code instead of a model, that's all it is.

Why that beats guessing from text

Skip the model and you win more than speed:

• Determinism. A model that picks a price out of running text is occasionally wrong: the wrong currency, an old price, or the price of a separate accessory. With "price": "29.99", "priceCurrency": "EUR" there's nothing to interpret; the value is right there. For prices, stock and opening hours you want zero guesswork.
• No ambiguity. Text can be genuinely ambiguous. Is "Jan de Vries" there as the author, as someone interviewed, or as a product name? Schema makes it explicit with author, about, and so on. That prevents errors, even when a model is reading along.
• Machine to machine. JSON-LD is an agreement between systems (schema.org). Not meant to "understand", but to exchange in a standardized way, so different parties read the same fields the same way.

When structure helps a language model anyway

And then the other way around, because sometimes that structure does give a model something, even when it's reading along:

• Context that isn't in the text. Sometimes the schema holds information that isn't neatly on the visible page, or that has to be pieced together from scattered bits of HTML. The JSON-LD then hands it over bundled and unambiguous.
• Fewer tokens, less noise. A schema block is more compact than a whole page full of navigation, footers and ads. In a pipeline that saves context window, and it reduces the chance the model gets distracted.
• Grounding against hallucination. Feed a model extracted, structured facts instead of raw HTML and it hallucinates less about exact values.

This is also why "so an AI search system understands what you offer" does hold up, even though a standalone model doesn't need schema: the system around it leans on those structured facts, not on a guess from your written text.

The rule of thumb

What it comes down to: the gain from JSON-LD isn't in "AI can't read it otherwise", it's in not needing a model for it. Deterministic parsers are cheaper, faster and more reliable for factual fields. The AI angle is a second-order benefit; it makes those systems more efficient and reliable, not possible.

And that flips the rule of thumb you often hear. Not "only price and date in the schema, the rest in text". A deterministic reader sees only what you structure; for that machine the rest doesn't exist. So structure everything that has a place in the schema.org vocabulary and is really on your page: your whole relevant entity graph, from author and organization to breadcrumbs, an FAQ, or a product with its offers. What's left is the nuance and the argument that no schema field exists for; you leave that in plain text, for the reader and for the model that does read. With the same iron rule around it as always: what you write into the schema has to match what's on the page.

Want to see how I approach this in practice, and which SEO and GEO tools are worth their money? That's in the sense and nonsense of SEO and GEO tools.