Guides · 2026-08-28 · By VSNARY | Emmanuel Orta
Entity SEO: what a machine has to resolve before it can cite you
Being read is not being identified. If a system cannot tell you apart from a similar business two towns over, it will either name the wrong one or name nobody, and both look identical from your side.
Entity SEO is the work of making a machine able to answer which one is this about you, unambiguously, and then answer specific questions about that thing. It sits underneath everything else: content that is read but not attached to a resolvable entity produces answers about a business the reader cannot name.
Three failures cause almost all of it, and none of them is reported by a validator, because in every case the markup is perfectly valid.
Failure 1: declaring existence instead of facts
Web-wide detection counts for individual schema types tell a consistent story:
| Schema type | Sites | The question it answers |
|---|---|---|
Organization | 354,358 | who this is |
PostalAddress | 108,730 | where to send someone |
ContactPoint | 91,622 | how to reach them |
Offer | 55,182 | what it costs |
GeoCoordinates | 27,993 | where it is on a map |
LocalBusiness | 26,108 | that it is a place of business |
OpeningHoursSpecification | 22,972 | whether they are open now |
These are independent detection counts, not a joint distribution — each row counts sites where that type was found anywhere, so nothing here says which sites overlap and no coverage rate should be inferred by dividing one row by another. What the magnitudes support is the ordering, and the ordering is the finding: declaring that you exist is common, declaring the specific fact somebody asked about is an order of magnitude rarer.
Are they open? and what does it cost? are among the most common questions anyone asks an assistant about a business, and they are among the least published machine-readable facts on the web.
Failure 2: identity claims that are not true
The sameAs property asserts identity. It means this thing is the same as the thing at that URL, and structured data is read literally.
On one site measured, the homepage sameAs contained sixteen map URLs. Resolving them showed fourteen pointed at cities rather than at the business — read literally, the site claimed the company was Phoenix, and also Denver, and also twelve other places. Most were shortlinks, so the destination was hidden until each one was followed.
No validator reports this. Every URL was well formed and every value a legal string. It only appears if something resolves the targets and looks at what is on the other end. The fix is straightforward: sameAs is for profiles of the entity; service areas belong in areaServed.
A related pattern: using the entity graph as a place to put keywords. A knowsAbout array containing dozens of service-keyword strings inflates the topic edges around your entity without making it more identifiable — the same instinct, one layer down.
Failure 3: collisions and duplicates
ENTITY_COLLISION fires on 3.9% of scans and ENTITY_NO_COORDINATES on 1.1%. The commonest form is a business whose name, category and rough location are shared with another business, with nothing in either site's data forcing them apart — no coordinates, no distinct address, no unique identifier.
Then there is the self-inflicted version. Two nodes carrying the same @id are not two businesses; they are one node parsed twice, and whichever parse lands second overwrites the first. Sites do this by including a global Organization block in a template and then declaring a page-level one with the same identifier.
The redundancy rule
Readers vary more than people assume. Some pipelines discard structured data entirely and form a view of your entity from prose alone — and get it substantially right. Others read only the schema.
So: state every important fact twice, in your structured data and in visible prose. A fact that exists only in JSON-LD is a fact with a delivery condition attached. A fact that exists only in prose is invisible to anything that reads the graph. Neither is a place to be exclusively.
Failure 4: declaring places you are not
The multi-location version of the identity problem deserves naming, because it is common in service businesses and it compounds.
One site emitted fifteen distinct LocalBusiness nodes, one per city it served. Fourteen had no street address, fourteen had no postal code, and all fifteen carried the same phone number. One page carried a literal +1-XXX-XXX-XXXX placeholder in the rendered HTML. Against that, exactly one real business listing existed.
Declaring an entity in a city you have no presence in does not create presence. It creates fourteen weakly specified entities that collide with each other and with the real one, all sharing a phone number, none with coordinates. The honest structure is one entity with a real address, and areaServed for everywhere you work.
How to check your own
Extract your JSON-LD and read it as a set of claims rather than as markup. For every sameAs URL, follow it and confirm what is on the other end is a profile of you. Confirm every @id in the graph is unique. Confirm the entity has coordinates, an address specific enough to disambiguate, and the facts people actually ask about — hours, price, service area, a contact point an agent can act on.
Then confirm all of it survives delivery. Schema in a page that is served from a stale cache, or refused to a given crawler, is not published to that reader at all.
Every figure above came out of this scanner.
Point it at your own domain and see the same measurements, free.
Questions this post answers
What is entity SEO?
The work of making a machine able to identify unambiguously which business you are, and then answer specific questions about it. It sits underneath content work, because text that is read but not attached to a resolvable entity produces answers about a business the reader cannot name.
What does sameAs actually do?
It asserts identity: this entity is the same as the thing at that URL. It is for profiles of the entity, such as social accounts or a business listing. Service areas belong in areaServed. One site was found with fourteen sameAs URLs pointing at cities rather than at the business, which read literally claims the company is those cities.
Why does no validator catch these errors?
Because the markup is valid. Every URL is well formed and every value is a legal string. These failures only appear when something resolves the targets, checks whether identifiers are unique, and asks whether the declared facts are the ones people ask about.