Entity SEO
Publishing so that a machine can resolve which real-world thing your page is about, and reconcile it with the same thing described elsewhere.
Karl-Gustav Kallasmaa, Founder & CEOLast updated Entity SEO is the practice of publishing so that a machine can resolve which real-world thing a page is about — a specific company, person, product, place or concept — and reconcile that thing with descriptions of it elsewhere, rather than matching the page on the strings it happens to contain.
The distinction it rests on is between a string and a referent. "Mercury" is one string and at least three entities: the planet, the element, the car marque. A string-matching system retrieves all three and lets ranking sort it out. An entity-aware system tries to decide, before ranking, which one the query meant and which one your page describes. Every technique below exists to make that decision cheap and correct for your entity.
The mechanism: assert, then reconcile
Two things have to happen for an entity to be usable.
Assertion. The page states what the thing is, in a form that can be parsed without inference. In practice this is schema markup — a JSON-LD block naming a type and its properties. Google's Organization documentation is unusually explicit that this is advisory rather than mandatory: there are no required properties, and the guidance is to add as many relevant ones as apply. Some, Google notes, are used behind the scenes to disambiguate your organization from other organizations; others influence visible elements such as which logo appears in a knowledge panel.
Reconciliation. The assertion is joined to the same entity as described somewhere else. The property that carries this is sameAs, which Google defines as the URL of a page on another website holding additional information about the organization — a social or review profile, for example. sameAs is not decoration. It is the only line in a typical markup block that makes a claim about identity across domains rather than about attributes within one.
The vocabulary these claims are written in is itself versioned: schema.org's current release is 30.0, dated 2026-03-19. Markup copied from an old template can be syntactically valid and semantically stale.
Why it matters for being cited by an agent
An assistant answering from retrieved documents has to do the same reconciliation, under worse conditions: it sees a handful of passages, not a whole site, and it must decide whether the company in passage one is the company in passage four. Three consequences follow.
Ambiguity is resolved against you by default. If two organizations share a name and only one publishes consistent identity signals, the consistent one becomes the default referent. Nothing announces that this has happened.
The rendered text carries the entity, not just the markup. A retrieval pipeline typically embeds and selects visible prose. Facts that exist only in JSON-LD may never enter the passage that gets quoted. State the founding date, the category, and the canonical name in the body as well.
Attributes travel only when they sit beside the name. A passage lifted from your page arrives without the rest of the page. "Founded in 2019 in Tallinn" three paragraphs from the brand name is two separate facts to a passage-level reader. Write them in one sentence.
Failure modes
- Naming drift. The same product appearing as three variants across the site, the docs and the press page. This is the most common cause of entity confusion and the cheapest to fix.
- Markup that contradicts the page. Structured data describing something the visible text does not say. It is a quality problem at best and grounds for distrusting the whole block at worst.
- `sameAs` pointing at pages you do not control or that no longer exist. A broken identity claim is a claim that cannot be verified.
- Treating entity work as a markup task. Markup asserts; corroboration confirms. An entity nobody else describes has nothing to reconcile against — which is why content authority and off-site mentions do work that JSON-LD cannot.
- Assuming disambiguation is permanent. A rebrand, an acquisition, or a same-named competitor's launch reopens a question you thought was settled. Models trained before the change keep the old answer until something newer is fetched.
How to act on it
- Fix one canonical name and one canonical URL per entity, and use them without variation everywhere.
- Mark up the entities you actually own — organization, products, authors — and list every off-site profile in
sameAs. - Repeat the defining attributes in prose, in the same sentence as the name.
- Check the vocabulary version you copied from; schema.org moves.
- Watch for the ambiguity case specifically: search your own entity name and see which other thing shares it. See also semantic search for how the matching itself works.
Frequently asked questions
What is an entity, as opposed to a keyword?
A keyword is a string; an entity is the thing it refers to. Entity SEO makes the referent unambiguous.
Which property does the reconciliation?
sameAs — Google defines it as a URL to another site's page carrying more information about the same organization.
Is structured data required?
No. Google documents no required properties for Organization markup and recommends adding whichever are relevant.
Does this help with AI assistants?
Yes, but only if the entity facts also appear in the visible prose an assistant retrieves.
Terms related to Entity SEO
The Schema.org vocabulary and the JSON-LD you embed with it, what it is genuinely good for, and the limits of what it can make happen.
Retrieval by meaning rather than by matching strings, what it is genuinely better at, and the class of query where it reliably fails.
The credibility a specific piece of content and its named creator carry on a specific topic — how raters are told to assess it, and why it is a page-level property rather than a site-wide score.