Search & SEO

Entity SEO and Structured Data: How Search Engines Tell 'Things' Apart

July 12, 2026 · by Brendon Kennedy

I’ve been going deep on entity SEO lately — the shift from optimizing pages for keywords to helping a search engine recognize the thing a page is about. It’s one of those topics where the primary docs are short, free, and weirdly under-read, so this is a catalog of what I’m reading and the markup I’m testing on my own sites.

”Things, not strings”

The mental model starts in 2012, when Google introduced the Knowledge Graph with a now-famous phrase: things, not strings. Instead of matching the letters you typed against documents that contain the same letters, the graph tries to identify a real-world entity — a person, a company, a place — along with the facts and relationships attached to it. Google’s own launch example is the disambiguation problem in miniature: search “Taj Mahal” and the engine has to decide whether you mean the monument, the musician, or the casino, then let you choose. At launch the graph already held more than 500 million objects and 3.5 billion facts.

That framing reorganized how I think about a website. The job isn’t only to rank a string; it’s to make sure the engine can pin a page to the correct entity — and, when a name is ambiguous, to hand it enough signal to tell that entity apart from every other thing that happens to share the name.

Structured data is how you label the facts

Structured data is the machine-readable layer that spells out what’s on a page. Google is explicit that it uses structured data “to understand the content of the page, as well as to gather information about the web and the world in general”, and that JSON-LD is the recommended format because it’s the easiest to implement and maintain at scale. In practice that’s a small <script type="application/ld+json"> block describing the entity — invisible to readers, fully legible to crawlers. Worth stating plainly: adding it doesn’t guarantee a rich result or a knowledge panel; it only makes the underlying facts unambiguous.

The two entity types that matter most for identity are Person and Organization.

Person and Organization schema

Schema.org defines Person as, literally, “A person (alive, dead, undead, or fictional)”. The type carries exactly the fields you’d want for disambiguation: name, url, jobTitle, worksFor, alumniOf, knowsAbout, an image, a short disambiguatingDescription, and — the important one — sameAs.

Organization works the same way for companies. Google’s guidance here is refreshingly loose: there are no required properties; you add the ones that apply. Two details worth knowing — the logo you declare influences which logo shows in Search results and the knowledge panel and must be at least 112×112px, and Google recommends placing the markup on your home page or a single “about us”-style page rather than scattering it across the site.

sameAs and why common names need disambiguation

Here’s the property that does the heavy lifting. Schema.org defines sameAs as a “URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Wikidata entry, or official website”. So sameAs is how a page says “the entity described here is the same entity described over there,” pointing at authoritative anchors the graph already trusts.

Why this matters is easiest to see with a generic example. Imagine two people who genuinely share a name — say a “Jordan Rivera” who is a marine biologist and a “Jordan Rivera” who is a session drummer. To a keyword system they’re an indistinguishable string. To an entity system they’re two separate nodes that happen to collide on one attribute — the name — while differing on every other: occupation, affiliations, topics, external profiles. The way you keep an engine from merging or confusing them is by feeding each node distinct, corroborating signals: a consistent name, a jobTitle and worksFor, a knowsAbout list, a disambiguatingDescription, and sameAs links to profiles that are unambiguously that one.

Common names aren’t a special edge case here — they’re just where the ordinary disambiguation machinery becomes most visible. The more consistently an entity’s attributes point the same direction across the web, the easier it is for the graph to resolve which node a given page belongs to. Inconsistency is the enemy: a name spelled one way here and another there, a logo that differs by page, sameAs links that don’t reciprocate — each mismatch is a reason for the engine to hesitate.

What I’m actually testing

This is the n=1 side — what I’m running on my own properties:

• A single Person JSON-LD block with a stable name, a jobTitle, a knowsAbout list, and sameAs pointing only to profiles I actually control — I keep that set small on purpose, since a link I can’t vouch for is worse than no link at all.
• One Organization block for zsty on zsty.us, with a 112×112-or-larger logo and sameAs to its real profiles, kept on a single canonical page instead of duplicated site-wide.
• A consistency pass: same name string, same URLs, same logo everywhere, since mismatched signals are what muddy an entity. Most of that work is unglamorous — hunting down the one profile where a name or handle drifted and pulling it back in line.
• Validating with Google’s Rich Results Test, then watching behavior over weeks, not hours — the graph updates on its own schedule, so I lean on whatever validator and tracking I’m already using rather than expecting an instant result.

The honest summary: structured data doesn’t make you an entity, and none of it forces a knowledge panel into existence. What it does is remove ambiguity — hand the graph clean, corroborated, cross-linked facts, so that when it decides which “thing” a page is about, it decides correctly.

← All writing