Blog · Machine readability

Structured data for AI search: what to mark up first

Published 8 October 2026 · Updated 12 October 2026 · 8 min read

Structured data for AI search: what to mark up first
Photograph: Amsterdam City Archives / unsplash

The short answer: Structured data for AI search is a disambiguation job, not a ranking lever. Mark up Organization first, on one canonical page, with a complete sameAs list. Then the page type that carries your commercial facts, usually Product with Offer, or Service. Then Article with a real dateModified, then Breadcrumb. Everything else can wait. The goal is not a rich result. The goal is that a machine reading your site can say who you are and what you charge without guessing.

Google is blunt about this. Its own documentation on AI features says there is "no special schema.org structured data that you need to add" to appear in AI Overviews or AI Mode. That sentence gets quoted at us in most kickoff calls, usually by an engineering lead who would rather not ship another template change. They are reading it correctly. They are also reading it as permission to skip markup, which is a different claim and a weaker one.

What the documentation says, and what it leaves open

Google documents no markup that unlocks one of its AI answers. No type, no property, no file. That is Google's statement about Google's features. The other engines we test publish nothing equivalent in either direction, so a claim that some type unlocks an answer elsewhere is unsourced until that engine says so itself.

What markup still does is reduce the number of guesses a machine has to make about your page. If an engine cannot resolve your entity from the page itself, it has whatever else it holds about a company with a similar name. We cannot watch that substitution happen from outside, so we are describing a mechanism, not a measurement. What we do see is the output: in audit work, wrong revenue figures, wrong headquarters and wrong product categories turn up most often for companies whose own pages never state those facts plainly. Markup is cheap disambiguation, not a ranking lever, and the distinction matters because it changes which types you bother with.

Look at what Google actually documents. We counted the entries in Google's structured data gallery on 12 October 2026 and got 25, on a page Google last updated on 15 June 2026. FAQPage and HowTo are not among them. Many of the 25 describe content shapes most B2B sites do not have: vacation rental, math solver, movie, recipe, dataset. The useful set for a software or services company is small, and that is the point of ordering it.

The order we work in, and the reason for each step

Organization, on one page. Google recommends putting it on the home page or a single page describing the organisation. Note the singular. Shipping the same Organization node into every template is the most common thing we find, and it creates dozens of near-identical entity assertions that can drift apart over a year of edits. The documentation states plainly that there are no required properties at all, and listed 23 top-level recommended ones when we counted them on 12 October 2026, which means the spec will not tell you that your markup is thin. Only a human will. We have written up what a complete one looks like in Organization schema done properly.

The page that carries money. Product with a nested Offer, or Service, on whatever page a buyer lands on to find out what something costs. This is the node most likely to be checked against your visible text, and the one most likely to disagree with it.

Article with a true dateModified. Google documents how it works out a byline date and recommends datePublished and dateModified in structured data, so dates are read at least there. Whether an engine learns to discount a site whose date moves on every deploy while the body text sits untouched, we cannot see and will not assert. The argument for setting the date from the content rather than the build is simply that it should be true.

Breadcrumb. Cheap, and it tells a parser where a page sits in a hierarchy that the URL alone may not express.

Everything after that is situational. FAQPage no longer earns a Google rich result and is absent from Google's current gallery. It remains valid schema.org vocabulary. Which other systems parse it is not something we can see, so we leave existing blocks in place, which costs nothing, and do not build new ones.

The failure mode nobody catches in testing

Validators check syntax and eligibility. They do not check whether your markup is true.

Here is the shape of it. A pricing page renders its headline price from a live billing API in the browser. The JSON-LD block, meanwhile, is generated server side from a CMS field somebody last touched in March. Both are valid. Both are in the HTML. They say different numbers. A rich result test checks syntax and eligibility, so it passes. Google's own AI features page asks you to make structured data match the visible text on the page, and then leaves the matching to you.

What an engine does with a page whose markup and visible text disagree is not stated in public documentation we can find, and we are not going to pretend we know. What we can say is smaller. In audit work, where each audit runs a set of about 45 prompts across five engines with retrieval on and retrieval off, pages carrying this kind of contradiction have tended to come back summarised more vaguely, and more often with a price quoted from a third-party listing than from the site itself. We have not counted that across a defined sample of sites, so it is an impression from case work rather than a measurement, and we are not attaching a number to it. It is consistent with a system preferring a source it can corroborate. It is not proof of one.

The same problem has a quieter cousin: markup injected by a tag manager after page load. A browser sees it. A crawler working from the raw response may not. Both halves of that failure are covered in JSON-LD mistakes that quietly break parsing.

A check you can run in two minutes

No tooling, no account. Pick your pricing page and run this.

`` curl -sL -A "Mozilla/5.0" example.com/pricing | \ grep -o '"price"[^,]*' ``

Compare what comes back to the number a human reads on the rendered page. Then do the same for availability, for name, and for the @id of your Organization node. On the sites we audit, before anything has been fixed, we usually find at least one disagreement of this kind, and finding none is unusual. That is what we see in our own case work, not a rate measured across a sample you could check.

Run it on the raw response, not on the rendered DOM in devtools, because the raw response is closer to what a crawler on a budget sees. If grep finds nothing at all, your markup is client side, and you have found a bigger problem than a stale price.

The self-check has nine more of these, in the same spirit: small, dull, checkable without buying anything.

Where structured data stops helping

Markup describes a page. It does not make a page worth citing. A page with immaculate Product schema and four hundred words of preamble before the answer will still be cut into passages that do not contain the answer, which is the argument in answer-first writing.

It also does nothing for corroboration. If no source an engine already trusts repeats your claim, your own assertion about yourself is one data point from an interested party. Schema makes that point legible. It does not make it credible.

And the vocabulary keeps moving. Schema.org shipped version 30.1 on 16 September 2026, adding terms for EU Digital Product Passports and common ecommerce product data. Which engines consume a new term, and when, is not published and not visible from outside, so adopting one the month it ships buys optionality rather than visibility we could demonstrate. We sequence markup in the first fortnight of an engagement for exactly this reason, ahead of anything slower, as set out in the first 90 days of AEO work.

Honest limits

We cannot measure how much one schema type contributes to being cited. None of the five engines we test exposes that, we have found no way to observe it from outside, and we will not reverse-engineer a number we cannot defend. The order proposed above is a judgement, not a ranked finding: Google documents where to put an Organization node and what it recommends on it, but we have found no published priority order from any of the engines we test, and we have not tested one ordering against another. Our claim about markup that contradicts the visible text comes from audit case work rather than a counted sample, which is why it carries no number. We also cannot see which non-Google systems parse FAQPage, which consume new schema.org terms, or how any of them weigh dates, so where this post says we cannot see something, read that literally rather than as modesty.

FAQ

What schema markup actually matters for AI search? Organization on one canonical page, then the type that carries your prices, then Article with a true dateModified, then Breadcrumb. None of it is an entry ticket to an AI answer. It is there so a machine does not have to guess who you are or what you charge.

Does adding schema get me into AI Overviews? No. Google states directly that no special structured data is needed for its AI features. Other engines publish no equivalent statement, so we do not make the claim on their behalf. Markup helps a machine resolve who you are and what you sell. It is not an entry ticket.

Should I still use FAQPage markup? It no longer produces a Google rich result and was absent from Google's feature gallery when we counted it on 12 October 2026. The vocabulary remains valid. Which other systems parse it is not something we can see, so keep what you have and spend new effort elsewhere.

How many Organization nodes should a site have? One canonical node, with a stable @id, referenced from other pages rather than repeated. Google recommends the home page or a single page about the organisation.

Is a validator enough to sign off a release? It confirms your syntax parses and your page is eligible. It cannot tell you the price in your JSON-LD is six months old. That check has to be yours.

Sources

All five pages were opened and checked on 12 October 2026.

Related reading

JSON-LD mistakes that quietly break parsingOrganization schema done properlyAnswer-first writing, and why the opening paragraph carries the answerThe first 90 days of AEO workWhat an agent-readable page looks likeYour API and MCP server as a visibility surface