TL;DR. Every controlled test of schema markup published in 2026 tested description, and every one of them found close to nothing. Not one tested identity. That distinction decides what you should ship.
A structured fact earns its place only if a machine can do something with it that it could not already do with your visible prose. Applied honestly, that test deletes most of the markup on most sites.
The one thing prose cannot carry is an identifier. Identifiers are therefore the entire non-redundant surface of a JSON-LD block, and they are usually under 1% of it.
An identifier is a rendezvous, not a name. Its strength is not who issued it but how many other parties publish it beside you, which makes this an outreach problem rather than a template problem.
Most sites sever their identifiers during a redesign and never find out, because validators check syntax and nothing checks continuity.
The rendering contract expired and nobody renegotiated
On 7 May 2026, Google added a deprecation banner to the top of its FAQ structured data documentation. FAQ rich results stopped appearing in Google Search that day, for every site, including the government and health domains that had held on to them since the August 2023 restriction. The search appearance filter, the rich result report and Rich Results Test support went in June, the Search Console API data in August. There was no blog post and no explanation, just a small label on a developer page.
Within a day the industry had split into two camps: one declaring FAQ schema dead, the other declaring it more important than ever for AI. Both were arguing from the same unexamined premise, that the job of markup is to describe your content to a machine, and the only open question is which machine is listening. That premise is what this article is about, and it is wrong in a way that has real money attached to it.
Schema.org was never a description technology in the way the industry has come to use it. It was a rendering contract. You supplied labels a parser could not infer from prose, Google supplied a visual feature, and eligibility was checkable in a validator before you shipped. Explicit input, explicit output, a test button in between.
That contract has been quietly unwinding for two years. Google retired seven structured data types in 2025 alone: Book Actions, Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement and Vehicle Listing. Book Actions was un-deprecated that November because a live Search feature still consumed it. Then FAQ went. Meanwhile Google’s own AI optimization guide lists overfocusing on structured data as a mistake, states plainly that structured data is not required for generative AI search and that there is no special schema.org markup to add, and then recommends keeping it anyway because it helps with eligibility for rich results.
Read those two facts together. The only official reason left to maintain your markup is eligibility for a category of feature the same company is actively shrinking. That is not an argument for abandoning structured data. It is an argument that the industry spent a decade optimising the wrong properties, and the deprecations are making the bill visible.
What is structured About data?
Structured About data is the machine-readable declaration of what a page and an organisation actually are, written in JSON-LD (JavaScript Object Notation for Linked Data, the script block format Google recommends) using properties such as about, mentions, sameAs and identifier. Its purpose is not to restate your page in a second format but to connect the things on it to the same things as they exist in other systems.
What the 2026 null results actually tested
The Otterly.AI experiment
Otterly.AI ran a three-part experiment from 7 December 2025 to 7 March 2026 across seven platforms: ChatGPT, Google AI Overviews, Google AI Mode, Perplexity, Microsoft Copilot, Gemini and Claude. They implemented FAQ, Organization, SoftwareApplication, Review snippet and Article schema on their own site and tracked brand coverage over 319 prompts. They are admirably clear that this is one SaaS brand, not an industry sample.
Test one asked each platform to fetch and return the raw markup from a given URL. Six of the seven could not. Gemini returned the correct JSON-LD; Claude and ChatGPT reported no markup present, Perplexity was blocked, and Copilot could reach readable text but not raw source. Google AI Mode did something worse than fail: it confidently described the schema types on the page and included a Service schema that had never been implemented. The mechanical explanation Otterly offer is the important part. The HTML-to-Markdown extraction pipelines used in most AI retrieval workflows either strip <script> tags or treat them as low-value, so the JSON-LD is gone before the model ever sees the page.
Test two measured brand coverage before and after. AI Overviews and AI Mode rose for the tested pages; ChatGPT, Copilot and Gemini fell. Site-wide they recorded a 377% rise in SERP features and a 1,500% rise in AI Overviews appearances over three months, then did the thing almost nobody does and checked their competitors. Brands that had changed no markup moved in parallel through December, so Otterly attributed the lift to a platform-level shift rather than their own intervention. That is the discipline most AI visibility measurement still lacks.
Test three is the one that matters. They placed a question and answer inside FAQPage markup whose answer existed nowhere else on their site or on the web: how many Otterly.AI employees live in Portugal. No platform used it, not even when the prompt pointed at the specific page.
The Ahrefs difference-in-differences study
Ahrefs tracked 1,885 pages that added JSON-LD between August 2025 and March 2026, matched them against 4,000 controls, and ran a difference-in-differences test, which compares the before-and-after change in a treated group against the same change in a similar untreated one. AI Mode and ChatGPT treated pages did marginally better, well inside noise across thousands of URLs. AI Overviews showed a 4.6% decline that was small but statistically significant.
The finding that gets skipped sits in the same study: across an initial six million URLs, pages cited by AI systems were almost three times as likely to carry JSON-LD as pages that were not. A strong cross-sectional association and a null intervention effect, in one dataset.
The usual reading is that the association is confounded, that markup is a marker of a professionally run site, and that you should stop caring. That reading is available and probably partly right. But look at what the intervention consisted of in every one of these tests. FAQPage. Organization. Article. Review. SoftwareApplication. Every property under test restated content the page was already showing a human reader. Not one study added a resolvable identifier and measured what happened.
Key takeaway. The 2026 evidence does not show that structured data is worthless. It shows that adding descriptive markup to a page that already describes itself does nothing, which is exactly what you would predict. The identity properties have never been tested at scale, and they are the only ones that carry information the prose cannot.
The join test: four classes of a structured fact
Here is the reframe the argument rests on. Structured data is not a description layer. Descriptions are what your prose already is, and a model that can read your page can read your page. Markup is a join layer. It exists so a machine can connect the thing on your page to the same thing as it appears in a system you do not control.
If you deleted this property and a competent reader of the visible page lost nothing, the property was never doing any work.
Run it across a real implementation and every property falls into one of four classes, defined not by schema type but by what a machine can do with the value.
| Class | What it is | What a machine gains | Verdict |
| Redundant | A value that restates text already visible on the page | Nothing. Any reader, human or model, already had it | Delete or ignore. This is the bulk of most blocks |
| Literal | A value that appears only inside the markup and nowhere in the prose | Nothing, and you believe otherwise | Actively harmful. Move it into visible text or drop it |
| Local | An identifier that resolves only inside your own domain, such as an @id fragment | Your own nodes cohere into one graph instead of many strangers | Keep. Cheap, useful, ceiling is your own site |
| Resolvable | An identifier that already exists in someone else’s system | A join to records outside your control | The entire point. Usually under 1% of what you ship |
Redundant: the ninety per cent
A description reading “Hallowfield Analytics helps finance teams forecast cash” sitting three hundred pixels below an H1 that says the same thing is redundant. So is headline duplicating the title, and name duplicating the logo alt text. None of these are wrong, and several remain required for the rich result types that survive. They simply do not transmit anything, and treating them as a visibility lever is the error the null results caught, including by teams running citation recovery programmes on the assumption that markup was the missing input.
Literal: the class that fools you
A literal is a value that exists nowhere except inside the script tag. The Portugal question in Otterly’s third test is the purest specimen ever published: a fact that lived only in FAQPage markup, invisible to every platform tested.
Google’s guidance also requires structured data to match the visible text on the page, and mismatched or invented markup is a spam category with manual action consequences. A literal is therefore either inert or a policy exposure, depending on how strictly the mismatch is read. There is no version where it pays.
Local: the cheapest thing on this list
An @id is a globally unique string that names a node so other nodes can point at it. Used inside a @graph array, which holds several related entities in one block, it lets your WebSite node point at your Organization node and every page agree that these refer to one company. Without it, a 3,400-page site can be asserting 3,400 unrelated organisations that happen to share a name.
Resolvable: the reason any of this exists
A resolvable identifier is one that already exists in a system somebody else runs: a Wikidata QID (the stable Q-number every Wikidata item carries), a Companies House number, an LEI (the twenty-character Legal Entity Identifier issued under GLEIF), a ROR ID from the Research Organization Registry, or a claimed profile URL on a platform that maintains its own entity records.
On a typical enterprise implementation these are a rounding error, which is the actual finding an audit produces and the reason the null results were never surprising.
Does schema markup help AI search?
Descriptive markup does not: controlled 2026 tests found no reliable citation lift, and most retrieval pipelines strip the script block before a model reads the page. Identity properties are a different intervention, untested the same way, and the only part of a JSON-LD block carrying information the visible prose cannot.
The rendezvous rule: an identifier is worth what other people publish
The standard advice, once you accept that identifiers are the point, is to use the most authoritative one available: the statutory registry over the commercial database, the thing with a governing body over the thing with a marketing team.
That advice optimises the wrong axis, and it is why a lot of careful entity work produces nothing.
An identifier does no work by itself. It works when two records that both use it meet. It is a rendezvous point, and a rendezvous only counts if somebody else turns up.
So consider an LEI. It is statutory, globally unique and precise to a degree no marketing platform can match. If it appears on exactly two pages in the world, the GLEIF record and your own footer, it joins nothing to nothing. Now consider your LinkedIn company URL: proprietary, non-authoritative, and present on four hundred pages of press coverage, staff profiles, funding databases, speaker bios, partner directories and recruitment listings.
Rendezvous count beats issuing authority, every time, because authority is a property of the issuer and rendezvous is a property of the world.
This is not an argument against registering an LEI. It is an argument that an identifier and its rendezvous count are two separate assets, only one of which can be manufactured from your own templates, and the industry has spent its entire budget on that half.
| Identifier | Who else publishes it | What it settles | How you raise the count |
| Companies House number | Registry, credit agencies, procurement portals, tender records | Legal existence and exact corporate identity in the UK | File it yourself, then get it into supplier and tender records |
| Wikidata QID | Wikidata mirrors, research datasets, downstream knowledge graphs | Which concept or organisation a name refers to | Create a well-sourced item; the notability bar is far below Wikipedia’s |
| LEI (GLEIF) | Financial counterparties, regulatory filings, GLEIF search | Identity in financial and regulatory contexts | Almost nothing you can do off your own site. Low ceiling for most brands |
| ROR or ISNI | Publishers, funders, repositories, library systems | Institutional identity in scholarly and archival corpora | Only worth it if you publish research or appear in those corpora |
| Claimed profile URLs | Press, directories, staff, partners, review platforms, everyone | Practically: which company the web means when it says your name | Earned coverage, directory listings, partner pages, speaker bios |
| Canonical site URL | Every page that has ever linked to you | The address the rest of the graph points at | Every link you have ever built, which is the point |
The column that matters is the last one, and every honest answer in it describes an action taken somewhere other than your own website. You cannot raise your own rendezvous count from your own markup; it is definitionally impossible. The ceiling on your structured About data is therefore set by your off-site citation footprint, not by your schema implementation, and the schema implementation is only the part that cashes it in.
Key takeaway. Pick identifiers by how densely the outside world already publishes them next to your name, not by who issued them. Then treat raising that density as a link building and digital PR objective, because that is the only place it can be raised.
about versus mentions: the two properties this is named after
The about property declares the primary subject of a page. The mentions property declares things the page refers to without being principally about. Both expect a Thing, which is the part almost everyone misses, because a Thing can be a node carrying an @id rather than a bare string.
That single choice is the whole difference between structured About data that works and structured About data that is decoration. Writing “about”: “link building” publishes a string, and a machine must then re-derive which concept you mean by matching text, which it could already do from your H1. Writing about as an object with a @id pointing at a Wikidata entity URI publishes a join to a node that thousands of other records already point at.
The failure mode is treating about as a keyword field
The commonest broken implementation is an about array holding fifteen strings scraped from the page’s target keywords. This fails twice. It publishes fifteen unjoinable literals, and it asserts that the page is primarily about fifteen things, which is an assertion that it is primarily about nothing.
For example, a page analysing how answer engines choose sources should carry one resolvable about node for information retrieval, then perhaps six mentions nodes for the engines and protocols it names. Not eleven subjects. One subject and a cast list.
Working budget. One to two resolvable about nodes per page, up to roughly eight mentions nodes, and every one of them also named in the visible prose, because parity is a Google requirement and because on the direct-fetch path the prose is the only copy some systems will ever see.
A way to check adoption before you ship
On 4 June 2026, schema.org announced a usage statistics dataset built with Google: monthly counts of how many domains actually use each type and property, published on the schema.org GitHub repository in CSV and JSON, aggregated to domain level and reported in popularity range buckets. The figures now appear on the term pages themselves.
This is the first public adoption figure for individual schema terms, and it should change a habit: before committing engineering time to a property, look up whether anybody is using it. A term in the lowest popularity bucket is one no consumer has had a commercial reason to parse. That is not a reason never to use it, but it is a reason to stop treating obscure properties as an edge everybody else has missed.
What is the difference between about and mentions?
The about property names what a page is principally about and should be used once or twice. The mentions property names entities referred to in passing and can be used more freely; both should point at resolvable nodes rather than plain strings.
The @id contract, and the join you break without noticing
An @id is a promise: this exact string will refer to this exact thing, for as long as this organisation exists. Every join anyone makes to your entity rests on that promise holding.
Almost every @id in production is generated by a plugin from the page URL.
Put those two sentences together and you have the least-discussed failure in the discipline. A redesign, a locale prefix, a category restructure, a trailing-slash normalisation, a move from /about-us/ to /about/, and every identifier on the site is silently reissued. Every join anyone had made is severed, and nothing reports it, because the new markup is perfectly valid. It parses. It passes the Rich Results Test. Search Console is quiet.
Validators check syntax. Nothing checks continuity. Your markup can be flawless on the day it stops meaning what it meant.
The continuity check
The fix is a diff, and it takes an afternoon to set up. Crawl the site, extract the set of @id strings it emits, and store that set with a date. Re-run it quarterly, and before and after any template or URL change. Any @id that disappears without a 301 from its old URL is a severed join, and you know the same week rather than two years later.
Duplicate Organization nodes are extremely common, usually because a theme emits one and an SEO plugin emits another with a different @id. The site is then asserting two companies with the same name at the same address, which is precisely the ambiguity the markup was supposed to remove. Web Data Commons, extracting structured data from Common Crawl since 2013, recorded average JSON-LD statements per page rising from around ten in 2015 to around fifty-two in 2022, and verbosity is what produces duplicate nodes.
One rule prevents most of it: pin the Organization @id to a fragment on the root domain, define it in exactly one place, and have every other node reference rather than redefine it. Multi-market sites should hold the same organisation @id across locales rather than minting one per market, which is the standard mistake in international SEO builds.
Worked example: Hallowfield Analytics
Hallowfield Analytics is a Bristol B2B SaaS company selling cash-flow forecasting to finance teams. 3,400 indexed pages, two overlapping plugins emitting markup, plus a theme emitting its own. It is a composite of a very ordinary implementation, and the numbers below are the shape an audit actually takes.
What the audit found
- 37,400 populated property instances across the site, averaging eleven per page.
- 34,100 of them (91.2%) were redundant: values restating text visible on the same page.
- 2,600 were literal, existing only inside the script block. Of those, 1,190 matched no visible text at all, which is the manual-action exposure rather than a missed opportunity.
- 640 were local identifiers, but inconsistently: the theme and one plugin each emitted an Organization node with a different @id.
- 61 instances were resolvable, and 48 of those were the same three sameAs URLs repeated site-wide. Three distinct resolvable identifiers on a 3,400-page site.
- A May 2026 redesign had moved /about-us/ to /about/, reissuing every @id fragment derived from that URL. Nothing in Search Console or the Rich Results Test flagged it, because nothing was invalid.
The fourteen-week intervention
Weeks 1 to 3: collapse to one @graph per template, one Organization node with a root-pinned @id, every other node referencing it, and disable the duplicate emitter. Weeks 4 to 6: delete FAQPage blocks whose questions were not visible. Weeks 7 to 9: populate identifier with the Companies House number and VAT registration, expand sameAs to six claimed profiles, and convert about from a fifteen-string array to two Wikidata-backed nodes across eleven hub pages. Weeks 10 to 14: the off-site half, described below.
What moved, and what did not
| Measure | Before | After 14 weeks | Read |
| Property instances shipped | 37,400 | 9,800 | A 74% cut in surface that has to stay true |
| Fields re-verified per page edit | 11 | 3 | The real recurring saving |
| Markup / visible-text mismatches | 1,190 | 0 | Policy exposure closed |
| Distinct resolvable identifiers | 3 | 14 | Cheap, one-off, done once |
| Rendezvous count (third-party pages carrying an identifier beside the name) | 9 | 63 | Driven by 11 placements and 3 registry corrections, not by markup |
| AI citation share on a fixed 24-prompt set | Baseline | Within noise | No detectable lift. Say so. |
That last row is the honest one, and it is why this example is worth reading. Over fourteen weeks the visibility metrics did not move in any way that survived a look at the control set. The case rests on the other five rows: a 74% reduction in maintained surface, a closed policy exposure, and a sevenfold rise in the number of external records that can be joined to this company. Anyone selling you the sixth row on the strength of the first five is selling something the evidence does not support.
Where this argument breaks
The strongest objection is not that identifiers are useless, but that the argument is unfalsifiable. It deserves putting at full strength.
The objection. Six of seven platforms cannot fetch JSON-LD at all. Google’s own documentation names overfocusing on structured data as a mistake and states there is no special markup for its AI features. A matched difference-in-differences test across 1,885 pages found nothing, with AI Overviews slightly down. The only positive evidence in the space is a vendor measuring its own product on its own site: Schema App reports a 19.72% rise in AI Overview visibility on schemaapp.com after entity linking, plus client figures including a 25% click increase for Brightview Senior Living, all self-measured and commercially interested. You have taken a null result and rescued it by asserting the studies tested the wrong properties. That is what every proponent of every failed tactic says.
The evidence asymmetry is real and disqualifying for any forecast of lift. The Schema App figures are self-measured on a vendor’s own property with no control group and an obvious commercial interest in the result: a hypothesis worth testing, not a finding. Anyone quoting 19.72% as though it were the Ahrefs number is misreading both. And the join claim is unproven today, and will stay unproven until somebody runs the Ahrefs design with identifier linking as the treatment arm. Nobody has.
What does not follow is the practical conclusion, because the decision does not depend on the size of the effect.
The resolvable class is roughly eight to twelve properties, written once and changed almost never. The redundant class is thousands of fields regenerated on every template change, each carrying a standing obligation to remain true and a subset carrying real policy exposure when it drifts. Those are not comparable investments. You are not being asked to bet on identifiers. You are being asked to stop paying rent on literals. At a true effect of exactly zero, the join test is still a cost-reduction argument with upside attached.
There is a second reason it survives, and it matters most to anyone building links. Identifiers pay in a channel that does not depend on any parser. They are how a journalist, a directory editor, a procurement system and a dataset compiler each record which company they mean, which holds whether or not a retrieval pipeline ever reads your script block, and increasingly matters where agents browse and act on your behalf. It is the reason brand entity monitoring keeps finding the same confusions in the same places.
Key takeaway. Concede the lift. There is no controlled evidence that identity markup raises AI citations, and the vendor numbers circulating in this space would not pass review anywhere. Do the work anyway, because it removes maintained surface, closes a policy exposure, and buys correct attribution in channels that have nothing to do with retrieval.
What this changes about outreach
If rendezvous count is the binding constraint and can only be raised off-site, structured About data stops being a development ticket and becomes a brief.
- Specify the name string, not just the anchor text. A placement that calls you “Hallowfield” and links to a campaign URL adds a string to the corpus. One that calls you “Hallowfield Analytics” and links to your canonical homepage adds a join. That is a one-line addition to the guest posting brief you already send.
- Treat registry and directory entries as link targets. Companies House, GLEIF, Wikidata, association member lists and product directories each publish an identifier beside your name in a machine-readable record. Most cost nothing, take under an hour, and are unusually within your control.
- Ask for the correction, not just the link. When a published piece names you with the wrong legal form, an old brand name or a competitor’s URL, that record is joining to somebody else. A correction request has a materially higher acceptance rate than a link request, because you are reporting an error rather than asking a favour. The same applies to journalist request placements, where the credit line is written once and copied everywhere, and it is the mechanism behind fixing brand facts in AI answers.
The prospecting pass is straightforward. Search your exact brand name, filter to pages naming you without linking, and sort them into two buckets: those already carrying a resolvable identifier beside your name, and those carrying only the string. The second bucket is your target list, better than a generic competitor backlink gap export because every entry on it is a page that has already decided you are worth naming.
It also explains what practitioners keep observing without explaining: brands with heavy earned coverage get described accurately by answer engines, while brands with immaculate markup and thin coverage do not. The same asymmetry shows in how AI systems pick which sources to cite, and in what drives product recommendations inside AI answers.
Your Monday checklist
- Export every property your site emits on ten representative templates and sort each into redundant, literal, local or resolvable. The ratio is the finding, and resolvable will be under 1%.
- Find every literal, the values appearing in markup and nowhere in visible text. Move the useful ones into the prose and delete the rest the same day.
- Count your Organization nodes. More than one @id for your company means a duplicate emitter. Turn one off.
- Pin the surviving Organization @id to a root-domain fragment and reference it everywhere else. Store the full set of emitted @id strings as a dated baseline and diff it quarterly.
- Populate identifier and sameAs with every resolvable identifier you already hold. An hour of work, and the entire non-redundant surface of your block.
- Convert about from strings to nodes on your top pages, one or two subjects each, capping mentions at around eight. Check every one appears in the visible prose.
- Count your rendezvous baseline: how many third-party pages publish one of your identifiers beside your name. Add it to your link building reporting and treat raising it as an outreach target, the only number here that outreach can move.
When to stop
Set the failure threshold before you start, because this work has an obvious way to become a hobby. If two quarters of registry filings, directory entries and correction requests have not raised your rendezvous count, the constraint is not your identifiers. Too few people are writing about you for resolution to be the bottleneck, and the budget belongs in earned coverage. Structured About data cashes in a reputation. It cannot mint one, and no amount of tooling changes that.
The single sentence to keep: markup is not how you tell an engine what is true about you, it is how you tell it which record to believe you are. Everything else is a longer way of saying what your page already said, and 2026 spent a great deal of research money establishing that engines read your page perfectly well without it. For the wider foundations, start with the fundamentals of link building and the way machine-readable feeds sit alongside them.
