Structured data for AI search: the enterprise standard for 2026

Almost every enterprise structured data program we inherit was built on a promise that has now been measured and found wanting. The promise was that marking up your pages makes machines prefer you. The measurement says otherwise. What the measurement does not say, and what gets lost in the backlash, is that broken markup still costs you real eligibility for real features, and that the cost of breakage went up sharply in August when Google stopped compensating for sloppy escaping.

So the correct posture in 2026 is neither the enthusiasm of 2023 nor the dismissal that followed the citation studies. It is the posture you take toward any piece of infrastructure that is invisible when it works and expensive when it fails: define the contract, gate the deploy, assign the owner, and stop asking it to produce growth it was never capable of producing.

Executive summary

This document is written for the person who owns technical search at an organization with more than a hundred templated page types, where nobody can inspect every page and the markup is generated by code that three teams have edited. It assumes you already have structured data deployed. The question it answers is not whether to implement schema. It is how to run what you have without it rotting, and what to stop expecting from it.

The short version has four parts. First, treat schema as eligibility, not as ranking or citation influence, because the controlled evidence on citations is now decisive enough to plan against. Second, treat validity as a build-time requirement rather than a periodic audit finding, because Google's parser is stricter than it was and a template level escaping error multiplies across every page that template renders. Third, assign a single owner with veto power over template changes that touch markup, because diffuse ownership is the root cause of every large scale schema failure we have audited. Fourth, measure the one thing schema demonstrably controls, which is rich result eligibility and its coverage in Search Console, and stop attributing citation movement to it.

What follows is the reasoning behind each of those, then a standard you can adopt directly, a governance model, the validation gates, a measurement plan, and a ninety day sequence for getting an existing implementation from unknown state to known state. Numbers throughout are attributed to their source and date. Where we are describing our own practice rather than published research, we say so.

What changed in August, and why it broke silently

On August 21, 2026, Google changed how it extracts JSON-LD. In Google's own words, the change was made "to bring our parser up to JSON and other standards," and the mechanism is that the extractor now applies only a single pass of HTML unescaping. Gary Illyes pointed implementers at RFC 8259, section 7, which is the part of the JSON specification that governs escaping inside strings.

The practical consequence is narrow and nasty. Markup that contained double-escaped entities used to be repaired by a second unescaping pass. An ampersand written as a doubly encoded entity, or a check mark written the same way, would eventually resolve to the character you meant. It no longer resolves. The value in your structured data is now the literal escaped string, which means a product name, a price, a URL or an author field can silently carry garbage that no human ever looks at.

“To bring our parser up to JSON and other standards, we changed our JSON-LD extraction and are now only applying a single pass of HTML unescaping.”

Why this breaks silently is the important part, and it is a lesson about where escaping bugs come from. Almost nobody hand-writes JSON-LD at enterprise scale. It comes out of a template engine, and the template engine has its own escaping rules, and a content management system in the middle has another set. The classic failure is a field that is escaped once by the CMS on save and again by the template on render. Under the old parser that was invisible. Under the new one it is a corrupted value, and it corrupts every page the template renders at once.

// Field value stored in the CMS, already entity-encoded once:
//   Acme Pro & Enterprise
// Template escapes it again on render into JSON-LD:
 
{ "@type": "Product", "name": "Acme Pro & Enterprise" }
 
// Old behavior: multiple unescaping passes resolved this to
//   Acme Pro & Enterprise
// Behavior since 2026-08-21: the value is taken literally as
//   Acme Pro & Enterprise
//
// Correct: escape for JSON string context only, per RFC 8259 s7.
{ "@type": "Product", "name": "Acme Pro & Enterprise" }

This landed in a month that was already noisy. Google ran a spam update from August 18 to August 21, practitioners logged ranking volatility on August 5 and 6 and again on August 12 and 13, and Search Console dropped performance data around August 12 along with two days of crawl stats. A team looking at a rich result coverage dip in that window has four plausible explanations available and only one of them is the parser. That confusion is exactly why validity has to be enforced at build time: once a change ships into a volatile month, you cannot reason backward from the metrics to the cause.

One clarification worth stating because it causes real waste. Deprecated almost always means the rich result stopped rendering, not that the markup became invalid or harmful. Valid FAQPage markup on your pages today is not a penalty risk and does not need an emergency removal project. What it needs is to stop appearing in a slide as a structured data win, because the display feature it was buying no longer exists.

The evidence on structured data for AI search, honestly stated

The claim that structured data drives AI citations has been tested properly twice, and both tests came back unfavorable. An honest standard has to start there rather than route around it.

The stronger of the two is the Ahrefs study by Louise Linehan and Xibeijia Guan, published May 11, 2026. They identified 1,885 pages that added JSON-LD between August 2025 and March 2026 and matched each against three control URLs from different domains with similar pre-period citation levels that never added markup, for roughly 4,000 controls. They compared citations in the thirty days before and after the change. Google AI Overviews citations fell 4.6 percent, which was statistically significant. Google AI Mode rose 2.4 percent and ChatGPT rose 2.2 percent, both statistically indistinguishable from zero. Their conclusion was that adding schema produced no major uplift on any platform, with the caveat that the sample is pages already being cited, so the finding may not transfer to pages with no citation history at all.

The second is a controlled test Otterly.ai ran on its own site from December 7, 2025 to March 7, 2026, implementing five schema types and tracking brand coverage across 319 prompts in the United States market on seven platforms. The headline movements look dramatic and point in every direction at once: AI Overviews up 611 percent, AI Mode up 42 percent, ChatGPT down 71 percent, Gemini down 35 percent, Copilot down 64 percent, Perplexity flat. The finding that matters is the control observation buried underneath: competitors who changed no schema at all showed equivalent or larger movements over the same window. That is the signature of platform level algorithmic churn, not of anything the test did.

There is a second, quieter result in the Otterly work that deserves more attention than the citation numbers. When the platforms were asked to return the raw markup from a page, only Gemini returned correct JSON-LD. Google AI Mode produced schemas that were not on the page at all, including a Service type that did not exist. If a model will confabulate the contents of a structured data block, then structured data is not functioning as a machine readable channel into that model in any meaningful sense. It is being read, at best, indirectly.

None of this is an argument for removing structured data. It is an argument for correctly pricing it. If a program was funded on the promise of AI citation lift, that program's business case is void and should be rewritten before someone else notices. If it was funded on rich result eligibility, product feature display and internal data consistency, the business case is intact and the August parser change just raised the cost of neglecting it.

What structured data still buys you in 2026

Four things, and they are worth having. None of them are citations.

The first is eligibility for the twenty five features Google still supports in its structured data gallery. Product with variants, policies and loyalty, Organization, Article, Video, Review Snippet, Breadcrumb, Job Posting, LocalBusiness, Course List, Discussion Forum and the rest. These render, they occupy space in the results, and they are gated on valid markup. This is the entire hard benefit and it is sufficient justification on its own for a commerce or listings business.

The second is entity disambiguation. Organization markup with consistent identifiers, sameAs references and a stable name is how you reduce the chance that an engine merges you with a similarly named company or splits you across two entities. This is not measurable on a dashboard, which is why it gets cut, and it is the failure that is most expensive to unwind once it has set.

The third is internal. A schema layer is often the only place in an enterprise where product name, price, availability, author and publication date exist in one machine readable structure per page. Teams that treat it as a data contract rather than an SEO tag discover it is useful for feeds, syndication, internal search and analytics. Teams that treat it as a marketing artifact let it drift out of sync with the page it describes, which is worse than not having it.

The fourth is the one people mean when they argue for schema in AI contexts, and it is real but indirect. Structured markup correlates with pages that are well organized for extraction, because the same discipline that produces valid Product markup usually produces a clear heading structure, a direct answer near the top, and a comparison table. The extraction structure is what earns the citation. The markup is a side effect of the team that also did the extraction structure. Confusing the correlate for the cause is how the industry got here.

That distribution is the argument for spending the marginal hour on format rather than on markup. Comparison content took the largest share of citations we tracked by a wide margin, and no amount of Product schema turns a page that does not compare anything into a comparison. The full breakdown and what it implies for content planning is in the anatomy of an AI citation, and the more recent read on how those format preferences have shifted is in the 2026 content format study.

The five failure modes we find in enterprise audits

These are ordered by how often we find them, not by severity. Every one of them is a template level defect, which is what makes them worth a governance response rather than a ticket.

The through line is that four of these five are invisible in a browser and invisible on a dashboard. They are only visible in the raw response, at scale, on a schedule. That is the argument for the validation gates later in this document, and it is the same argument we make about crawler behavior generally, since the request itself is now a variable: Google's crawlers issue HEAD, OPTIONS, PUT, PATCH and DELETE requests, and infrastructure that rejects them creates failures nobody attributes correctly, as we covered in what happens when your firewall answers Googlebot badly.

A structured data standard for AI search, written as a contract

Adopt this as written or edit it to fit, but write it down somewhere a developer will find it. The value is not in the specific choices, it is in there being a document that settles the argument before the argument reaches a pull request.

Two deliberate omissions. There is no rule here about marking up every possible entity, because coverage for its own sake produces sprawl and sprawl produces the failure modes above. And there is no rule about llms.txt or any adjacent file format, because the correct treatment of those is a separate evidentiary question with its own answer, and bundling them into a schema standard implies a relationship between them that the data does not support.

Governance: who owns schema when four teams touch the template

Here is the pattern behind almost every large structured data failure we have audited. Marketing asks for markup. A developer adds it to a template. A platform team later refactors that template. A third party plugin adds its own block. Nobody is accountable for the output, so the output is whatever the last edit produced. Six months later a validator finds four hundred thousand errors and the only honest answer to who owns this is nobody.

The fix is unglamorous and it is a single named owner with two specific powers. The first is review authority over any change touching a template that emits markup, exercised as a required reviewer on the repository path rather than as a meeting. The second is the authority to say no to a new type. Without the second power the allowlist decays within two quarters, because every individual request for a new type is reasonable and the aggregate is not.

Where the owner sits matters less than that they exist, but there is a pattern. Owners inside the platform or web engineering team hold the gate more reliably than owners inside marketing, because the gate lives in the repository and the enforcement is cultural as much as technical. The marketing side of the relationship then becomes a requester and a reviewer of outcomes rather than a requester and an implementer, which is a healthier arrangement for both.

In multi brand or multi region organizations, resist the temptation to give each property its own standard. One standard with documented regional exceptions is far cheaper to maintain than nine standards that agree on ninety percent of their content. The exceptions we see legitimately are language and currency handling and regional availability fields. Everything else that gets proposed as an exception is usually a team that does not want to be reviewed.

Validation gates that catch this before deploy

Three gates, in increasing cost and decreasing frequency. Together they cost a few engineering days to build and they replace an audit finding that would otherwise recur every year.

The first gate is syntactic and runs on every pull request. Extract every JSON-LD block from a rendered sample of each affected template, parse it as strict JSON, and fail on a parse error. Then scan the parsed string values for encoded entity patterns and fail on those too, because after August that is a correctness bug rather than a cosmetic one. This gate is fast, deterministic and catches the single most common failure mode in this document.

The second gate is semantic and runs on merge to the main branch. Validate the extracted markup against the required properties for its declared type, using your own allowlist as the schema of record rather than a third party tool's opinion. Warn on recommended properties. Compare a small set of critical fields, price and availability being the usual pair, against the values rendered on the same page, and fail on a mismatch. This gate is the one that catches markup drifting away from the page.

The third gate is behavioral and runs on a schedule against production. Crawl a stratified sample of live URLs, fetch the raw server response rather than a rendered document, and track the error rate per template over time. What you are looking for is not a number, it is a step change. A steady low error rate is a backlog. A step is a regression that shipped, and knowing which week it shipped is most of the diagnosis.

Measuring structured data without fooling yourself

Measure three things and refuse to measure a fourth.

Measure valid item coverage per type per template, from your own crawl rather than from a vendor. This is the number that tells you whether the program is healthy. It should be near total and boring, and any movement in it is a signal. Report it monthly with the error count broken out by template, because per template is actionable and per site is not.

Measure rich result impressions and clicks in Search Console for the features you are actually eligible for, with the retired features removed from the view. This is the closest thing to an outcome metric that structured data legitimately owns. Segment it by feature type, because an aggregate that mixes a growing feature and a retired one produces a flat line that means nothing.

Measure time to detection for markup regressions. When the third gate finds a step change, how long had it been live? That number is a direct read on whether the gates are working, and it is the metric most likely to improve quickly once someone is watching it. A program that goes from ninety day detection to seven day detection has materially reduced its exposure even if coverage never moves.

Refuse to measure AI citations as a structured data outcome. Two controlled studies say the relationship is not there, and a metric that moves for unrelated reasons will eventually be used to justify a decision it cannot support. Citation measurement is worth doing, and it belongs to the content and authority programs that actually influence it. The readiness baseline for that work is a separate exercise with its own instrumentation, laid out in the AI answer surface readiness playbook.

The ninety day implementation sequence

This is the order we would run it for an organization that has structured data deployed at scale, has never audited it properly, and does not know its current error rate. Ninety days is enough time to get from unknown state to governed state without a rewrite.

Days one through fifteen establish the baseline. Crawl a stratified sample of production URLs, capture raw responses, extract and strict-parse every JSON-LD block, and produce an error count per template. Run the encoded entity scan separately and report it on its own, because after August it is the finding most likely to be both widespread and unknown. Do not fix anything yet. The baseline is worth more than fifteen days of fixes, because it is what makes every later claim of improvement credible.

Days sixteen through forty five fix the top templates and build gate one. Rank templates by pages affected rather than by error count, since one broken template on a large catalog outweighs twenty broken pages elsewhere. Fix the escaping in the shared helper rather than template by template, because a per template fix reintroduces the bug the next time someone copies an existing template as a starting point. Ship the pull request gate in the same window so the fixes cannot regress behind you.

Days forty six through seventy write the standard and name the owner. Adopt the contract above, agree the allowlist, and get the required reviewer configured on the repository path. This is a political exercise more than a technical one and it takes longer than the work suggests. Do it after the fixes, when you have a baseline and a visible improvement to point at, because the standard is much easier to pass when it is ratifying a success rather than proposing an overhead.

Days seventy one through ninety build gates two and three, remove retired features from reporting, and stand up the monthly metric. By the end you should be able to answer three questions in under a minute: what is our valid item coverage by template, when did we last have a regression, and how long did it take us to find it. Most organizations we start with cannot answer any of the three.

See where you are cited today

A free snapshot audit of your rankings and AI citations before we ever talk.