Structured data for AI: what helps and what is theatre

It declares. It takes information the page expresses in prose and in graphics and rewrites it in a form a machine can read without interpreting: this is a product, this is the price, this is the currency, this is the availability state. It is translation, not optimisation.

The confusion comes from markup having been sold as a ranking lever for years. It is not one, and Google's documentation is fairly clear about it: structured data serves to understand a page's content and to present that content in a richer appearance in results. Understanding and presentation, not ordering.

The useful version of this distinction is economic. If you think schema lifts a page, you add it where you want to rise, meaning where you have a competition problem. If you understand that it declares, you add it where you have an ambiguity problem, which is a different and usually duller place.

Three positions, all public, and worth knowing precisely because they are the strongest argument you have when somebody promises you results.

First: correct markup does not guarantee appearance. Google writes that it does not guarantee your structured data will show up in search results, even if the page is marked up correctly. The algorithm decides which format best serves the user in that context.

Second: the list of types that produce anything is finite and published. Article, product, organization, local business, event, recipe, job posting, breadcrumb, review, discussion, video, dataset, and a limited number of others. That list moves over time in both directions: types get retired when the feature they fed no longer exists.

Third, and most underrated: a structured data policy violation costs eligibility for the rich result and does not change how the page ranks in web search. Read backwards, that says exactly what markup is: an eligibility lever, not a ranking one. Were it otherwise, the penalty would have touched ranking.

The criterion is whether the type is in the documented list. Outside it you can write schema that is perfectly valid by the standard, and it triggers nothing, because no feature is attached. It is not harmful, it is inert, and the cost is the time you spent.

Because it stops being a missing figure and becomes a false claim made by you. The policies are explicit on two connected points: do not mark up content that is not visible to the reader of the page, and do not mark up irrelevant or misleading content. A price in the schema different from the price on screen violates both.

The technical consequence is lost eligibility, and in the worst cases a manual action. But the bigger damage is upstream: a system finding a divergence between what you declare and what you display has learned something about how reliable your declarations are in general, and that judgement extends to the correct fields.

The case I see most often is not dishonesty, it is drift. The schema is generated from a different source than the one feeding the page, and the two come apart over time: the price changes in the back office, the page updates, the schema keeps the old value. Nobody decided to lie, and the system reads a lie.

Hence an implementation rule worth more than any choice of type: schema must be generated from the same data that generates the visible page. Hand-written, or coming from a second system, drift is a matter of when.

The purpose changes. A rich result is a traditional search feature: supply the markup, get a display format. In a generative engine there is no format to trigger, there is an answer to build, so markup serves something else: resolving ambiguity.

That is the real benefit. A price declared in a field with its currency does not have to be inferred from a string. A declared availability state does not have to be read off a graphical badge. An organization declared with its address and its profiles does not have to be guessed at among namesakes. In all three cases the markup convinces nobody: it removes a step of interpretation, and that step is where things break.

What should be said just as plainly is that no generative engine vendor has stated that structured data raises the chance of being cited. Anyone claiming so is inferring. The inference is reasonable, because unambiguous data is easier to use than ambiguous data, but it stays an inference and should be presented as one.

From which the correct order of priority follows: markup comes after accessibility and entity consistency, not before. Marking up a page crawlers cannot read is time spent on a field nobody reads.

By page type and by the ambiguity actually present, not by coverage. The goal is not marking everything up: it is removing interpretation where interpretation can go wrong.

It does not make you rank. Worth repeating because it is the promise that sells best: in the documentation markup produces understanding and eligibility for a presentation, and the penalty for misusing it does not touch ranking. Those two together settle the question.

It does not guarantee the rich result even when it is perfect. That is not my caution, it is written by the vendor.

It does not make an unreadable page readable. If the content only arrives after the browser renders it, schema injected by the same script arrives with it, which is to say it does not arrive.

It does not replace the text. An attribute declares a value, it does not explain why that value matters to whoever is buying. The answer an engine builds is made of prose, and you write the prose.