Structured data for AI consumption

The bet that a website should publish a machine-facing description of itself for AI systems, separate from the markup it embeds for search crawlers. Three sources arriving together on 2026-07-28 (merchant-listing-structured-data, yoast-schema-aggregation, entitymap) mark three positions on it, and the first one is the baseline the other two are trying to leave behind.

The trajectory: markup leaves the page

Classic schema-org markup lives inside the document it describes. The graph is implicit — spread across a site, reconstructed by whoever crawls it. Each of the three sources sits further from that model:

1. Embedded, crawler-read — merchant-listing-structured-data. Product + Offer in the page’s HTML; Google reads the page and renders a richer result. The vocabulary is shared, the payoff is a visual treatment, and the consumer’s eligibility rules do the real governing.
2. Same markup, aggregated delivery — yoast-schema-aggregation. The site’s per-page graph is merged, deduplicated, and served from one REST endpoint. Nothing new is authored; the graph becomes explicit and addressable instead of implicit and scattered.
3. New file, new fields — entitymap. entitymap.json at a predictable URL, with entities, sameAs identifiers, typed relations, and chunk-level evidence. Explicitly modelled on sitemap.xml.

The direction is consistent: from inferred by the consumer to declared by the publisher, at a well-known location. ../search-marketing-wiki’s llms-txt is the same move made a year earlier without the entity model.

What’s actually new versus repackaged

Most of what these formats propose, the semantic web already had. Stable identifiers, sameAs, typed relations between entities — rdf has expressed all of it since the beginning, and schema-org carries sameAs today. What was missing was never expressive power; it was a publisher-side reason to author the graph. These proposals are bidding for AI visibility to be that reason.

entitymap‘s hasChunks resists that reading. A claim plus the URLs supporting it, with relevance scores and attribution, has no semantic-web equivalent, because it isn’t describing meaning but retrieval: which passage grounds which assertion, and who gets credit. That’s shaped by how RAG consumes text, not by how ontologies model the world. If this thread produces something genuinely new, that’s where to look.

The evidence problem

The premise is asserted by parties who sell against it and denied by the party that would consume it.

• yoast-schema-aggregation: “Your content cannot be visible in AI if it is not understood correctly.” No named consumer, no measurement.
• entitymap: one reference implementation, built by the maintaining vendor. No AI system documented as reading the file.
• Google, first-party (../search-marketing-wiki’s google-ai-optimization-guide): structured data “isn’t required for generative AI search” — it helps rich results, and is not a gate on generative features. The same guidance says of llms.txt that “Google Search itself doesn’t use them,” and lists AI-specific rewrites and content chunking among things publishers should ignore.

So the tension is sharp and worth keeping rather than resolving: the biggest consumer of structured data on the web says structured data is not the AI-visibility lever, while the tooling market builds products on the premise that it is. Both claims are on the record. Google is describing its own systems and has an interest in publishers not chasing hacks; the vendors have an interest in the opposite. Neither has published a measurement.

What would settle it: any AI system documented as fetching one of these artifacts, or a before/after visibility comparison from a party not selling the tool.

Related

merchant-listing-structured-data · yoast-schema-aggregation · entitymap · schema-org · rdf · knowledge-representation · synthesis