Most SEO practitioners still think about schema the way they did in 2018: add Product markup, get star ratings in the SERP, job done. That framing is now dangerously incomplete.
The actual job schema does in 2026 is entity disambiguation for AI inference engines. Google’s AI Overviews, Perplexity, and ChatGPT Search all do named-entity resolution when they decide which source to quote, which brand to surface, and which claim to attribute. If your structured data doesn’t give those systems an unambiguous read on who you are, what you do, and how your entities relate to each other, you’re leaving that resolution to chance — and you’ll lose to a competitor whose markup is cleaner, not whose content is better.
Why Disambiguation Is the Actual Problem
Say you’re a B2B SaaS company called “Summit” in the project management space. There’s also a Summit Insurance Group, a Summit Climbing Gym franchise, a Summit Foods distributor. None of you have identical names, but all of you are generating content, earning mentions, and getting linked to. When an AI model encounters a citation like “Summit’s Q3 report” or a backlink anchor that just says “Summit,” it has to decide which entity that refers to.
Schema is one of the few direct channels you control to push on that decision. A well-formed Organization block with a stable @id URI, a matching sameAs array pointing to your Wikidata entry, your LinkedIn company page, your Crunchbase profile, and your Pitchbook listing — that’s not decorative. That’s constructing a canonical fingerprint for the knowledge graph.
Without it, you’re relying entirely on co-occurrence signals to do that work. Sometimes that’s enough. Often it isn’t.
The @id Property Deserves More Respect Than It Gets
The @id field in JSON-LD is consistently undertreated. Most implementations either omit it or set it to the page URL, which is technically valid but semantically weak. The stronger pattern is a persistent, non-page-specific URI — typically your homepage URL with a fragment identifier — as a stable IRI for the entity itself, separate from any given document.
So instead of:
"@id": "https://example.com/about"You want:
"@id": "https://example.com/#organization"Then reference that same @id consistently across every page that mentions the organization — in your breadcrumbs, in your author fields, in your publisher fields on Article nodes. This creates a graph of internal entity references that a knowledge engine can actually traverse. Google’s structured data guidelines don’t spell this out as loudly as they should, but the Schema.org spec and the mechanics of Google’s Knowledge Graph both reward it.
sameAs Is Doing Heavy Lifting in AI Citation Decisions
When we audit sites that have real authority but aren’t getting cited proportionally in AI answers, sparse or inaccurate sameAs arrays are one of the first things we find. Entities with dense, accurate sameAs entries — especially pointing to Wikidata, LinkedIn, and Crunchbase — show up more reliably as cited sources than entities with equivalent content quality but thin structured data.
The mechanism makes sense from the model’s perspective. When a retrieval-augmented generation system is choosing between two sources that both look authoritative, the one it can more confidently identify as a known, cross-referenced real-world entity gets the benefit of the doubt. sameAs is the fastest path to being a known entity rather than a pattern of text that looks like one.
What goes in sameAs? Prioritize:
- Your Wikidata QID URL (if you have a Wikidata item — if you don’t, consider whether you should)
- Your LinkedIn company page
- Your Crunchbase profile
- Your Wikipedia page (if applicable)
- Your Google Knowledge Panel URL (the
/g/format URL, not the search results page)
Don’t pad it with irrelevant directories just to look robust. Five accurate entries beats fifteen where half are low-quality citation directories that don’t actually verify identity.
Article and Author Schema: Where Most Sites Are Bleeding Trust
Article schema is almost universally implemented wrong. The author field gets set to a string name instead of a Person entity with its own @id, and the publisher field points at a page URL instead of the Organization entity node.
Why does this matter for AI search? When an AI system attributes a claim to your content, it’s attributing it to an entity — ideally one it can look up, verify credentials for, and cross-reference against other signals. A Person node with a sameAs pointing to a LinkedIn profile and a Wikidata item is a verifiable expert. A string that says "Jane Smith" is just text.
For E-E-A-T specifically, the author entity’s knowsAbout and hasCredential fields are underused. They’re not magic — they’re one signal among many. But they’re a direct declaration of topical expertise that structured data parsers can surface, and that’s worth more than nothing.
One Pattern Worth Stealing: Speakable Schema for AI Summaries
Speakable schema (https://schema.org/speakable) was designed for voice assistants. Google never fully rolled it out as a mainstream feature and support remains limited. The secondary use case worth knowing: some AI-powered summary tools use CSS selectors and structured data hints to identify which parts of a page contain the most citable content.
Implementing Speakable with cssSelector pointing at your key summary paragraphs signals — to any parser that respects it — exactly which text blocks you want surfaced. Whether any given AI crawler honors that is not guaranteed. It costs almost nothing to implement and the downside is zero.
The Caveat Worth Internalizing
Schema markup is not a ranking factor in the direct, measurable sense that a backlink from a high-authority domain is. You can’t A/B test schema changes and see a clean keyword ranking lift two weeks later. The mechanism is slower and more indirect: better entity resolution leads to more accurate knowledge graph associations, which leads to citation-eligible status in AI retrieval systems, which leads to traffic that looks organic but is actually coming from AI-mediated recommendations.
If your site has fundamental content quality or authority problems, schema won’t paper over them. It’s a force multiplier on a foundation that already exists, not a substitute for one.
That said — for sites with real authority that aren’t getting cited proportionally in AI answers, under-built structured data is consistently one of the first things we find when we audit them. Not always. But often enough that it’s now the first thing we check.
Where to Actually Start
Run your homepage through Google’s Rich Results Test and the Schema.org validator side by side. The Rich Results Test tells you what Google can currently extract. The Schema.org validator tells you if your markup is technically valid against the full vocabulary — they’re not the same check, and the gaps between them are often where the real problems are hiding.
Then pull your Organization node and count how many other pages on your site reference that same @id. If the answer is zero or one, that’s your actual starting point — everything else is secondary.
Fix the graph first. The rich snippets will follow.