Schema.org for AI: which structured data do assistants actually understand?
Schema.org tells a machine explicitly what a page is, instead of leaving it to guess. Which types actually pay off for AI assistants, how to tie them together with @id, and where it goes wrong in practice.
Schema.org is a shared vocabulary for stating, in machine-readable terms, what a page
contains: this is an organisation, this is an article with this author and date, this is a
product at this price. You usually express it as JSON-LD — a small block
of JSON in your page's <head>. For AI assistants this isn't a ranking
trick but something more mundane: it removes guesswork. A model
summarising your page doesn't have to infer who published it or when it was written — it's
stated outright.
So which types actually pay off? In practice, a handful: Organization (who you
are, with sameAs links to profiles models already know), Article or
BlogPosting (what this piece is, from when, by whom), FAQPage (question
and answer in exactly the shape an assistant needs), Product or
SoftwareApplication for what you offer, and BreadcrumbList for where the
page sits in your site. The rest of the vocabulary's 800-plus types is rarely worth the
effort — unless you happen to publish recipes, events or job postings.
Why a language model benefits from markup it never displays
The instinct is understandable: a language model just reads the text, doesn't it? It does — and that's precisely why markup helps. From running prose, a model has to infer that "Neuralex" is the publisher and not a client being mentioned, that "18 July" is the publication date and not a date inside the story, that the author is an organisation rather than a person. Every one of those inferences can go wrong. JSON-LD turns them into facts that need no interpretation.
On top of that, the systems you want to reach rarely read your raw HTML. An assistant searching live leans on search indexes and extraction pipelines that have been reading structured data for years and storing it as a separate field. What you put in JSON-LD often survives that journey better than a sentence halfway down your page. It sits alongside the other machine-facing layer on your domain — see our piece on llms.txt for how that one works.
The five types to start with
Organization. Define it once, reuse it across the site. Name, url, logo,
contact, and above all sameAs: links to your profiles elsewhere. That's the
hook connecting your site to what a model already knows about you from outside it — which
is exactly the cross-verification trust is built on.
Article / BlogPosting. Headline, description, both publication and modification date, language, author, publisher. The modification date is not a detail: for questions where recency matters, "when was this last revised" is one of the few signals an assistant can use objectively.
FAQPage. A list of Question objects each with an acceptedAnswer. Mind your expectations: in 2023 Google restricted the display of FAQ rich results in search to a small set of sites, so as a visual enhancement this type has largely run its course. For extraction it hasn't — it hands over a question-and-answer pair in exactly the form a generated answer needs.
Product / SoftwareApplication. For what you sell or offer. Name, description, category, and where applicable price and availability. Don't embellish here: markup that contradicts what's on the page is worse than no markup at all.
BreadcrumbList. Unglamorous but useful: it says where a page sits in the hierarchy, so a stray URL isn't read as a loose leaf but as part of a whole.
@id: from scattered blocks to a single entity
The most common mistake is treating markup as a pile of loose notes: a full Organization
block on every page, each one slightly different. Better is one canonical definition with
a fixed identifier — say https://yoursite.com/#org — and on every other page
nothing but a reference to that @id. That's exactly what the articles on this
site do: the publisher field points at one organisation definition instead of
repeating it.
The effect is that your markup becomes one coherent graph instead of fifty separate descriptions. A machine that fetches three of your pages then sees they share a publisher — rather than three possibly different organisations that happen to share a name.
Where it goes wrong in practice
Markup that doesn't match the visible page. An FAQPage block with questions that appear nowhere on the page, or a price that differs from what the visitor sees: that's precisely what structured data guidelines prohibit, and it's a bad idea regardless. Stretch this and you risk all markup from your domain being ignored.
Markup that only appears after JavaScript runs. If your JSON-LD is injected by a script, only crawlers that execute JavaScript will see it. A share of AI crawlers don't. So render it server-side, or generate it statically.
Stale data. A dateModified frozen two years ago while you
rewrote the text, or sameAs links to profiles that no longer exist, work
against you. Treat schema as part of the page, not as something you bolted on once.
Marking up everything. Stacking twenty types doesn't buy twenty times the comprehension. Five accurate types beat twenty half-filled ones.
How to check it's right
Two free checks are enough. Schema.org's own Schema Markup Validator verifies your JSON-LD is valid against the vocabulary. Google's Rich Results Test additionally checks whether a type qualifies for display in search results. The second is stricter and narrower — valid markup that yields "no rich result" isn't necessarily wrong.
More important than either: read your own JSON-LD once as a human and ask whether it matches what's on screen. We fold that question into the Agentic Search Optimizer, which runs a site through 15+ checks — including whether the structured data describes what the page actually is.
Conclusion
Schema.org isn't a clever trick to persuade assistants; it's the dullest, most reliable way
to stop them guessing. Five types, one canonical organisation with a fixed
@id, markup that matches the visible page exactly, and a validator you run
now and then. That's the whole story — and it's one of the few GEO measures entirely
within your own control. How it fits the bigger picture, from crawler access to citable
paragraphs, is covered in
our pillar article on GEO.