Entity SEO: build your entity in the Knowledge Graph

If you only read one sentence: a keyword is a string, an entity is a thing, and AI answers cite things.

Try this at home — I did: type a brand name that collides with a common word into an answer engine and ask what the company does. More often than not, the engine describes the other “apple” with complete confidence. That small embarrassment is the whole topic. Search and AI answer engines stopped matching characters years ago; they resolve a query to entities in a knowledge graph, then choose sources that are themselves recognized entities. Ranking for a keyword gets a blue link, while being a known entity gets a source cited inside the answer. So the question I’d ask isn’t “which words do I repeat?” but “does the graph know I exist?” — and becoming an answerable node comes down to one consistent name, verifiable sameAs links, and facts that never contradict each other across the web.

Keywords match strings; entities resolve things

Since Google’s 2012 “things, not strings” shift, the index has carried a second layer under the text: a graph of entities — people, companies, products, places — each with a stable identifier and a set of facts. When someone (or an LLM) asks a question, the first thing that happens is entity resolution: the query “best eSIM for Japan” is mapped to the entity eSIM, the place Japan, and an intent, and only then does the engine look for sources connected to those entities.

A keyword page hopes to match the words in a query; an entity is the thing the query is about. That’s the whole gap, and it’s bigger than it sounds: triples build a fact, and a cluster of consistent facts about one subject builds an entity the graph can name.

Why an entity beats a keyword for citation

Axis	Keyword target	Entity
Unit	a string of characters	a thing with an identity
Matched by	lexical / vector similarity	resolution to a graph node
Ambiguity	”apple” = fruit or company?	disambiguated by ID + sameAs
Payoff	a ranked link	a citation inside the answer
Durability	swings with each algo update	compounds as facts corroborate
Portability	one engine’s SERP	every engine that reads the graph

An LLM composing an answer doesn’t reward the page that repeated a phrase most; it reaches for sources it can attribute — named, recognizable entities it has seen described consistently. Being that entity is more durable than any keyword ranking, because it compounds: every corroborating mention strengthens the node instead of resetting with the next update. Is that fair to a brilliant page by an unknown author? Probably not. It’s how the machinery works, though, and I’d rather work with the machinery than argue with it.

Become an answerable node

Four moves, in order of leverage — and yes, the boring one comes first!

1. One name, everywhere

Pick a single canonical name and use it verbatim — same spelling, same casing, same legal form — on the site, the profiles, the press, and the schema. “Acme”, “Acme Inc.”, and “ACME Technologies” read as three weakly-connected candidates, not one strong entity, and consistency is what lets the graph collapse the mentions into a single node. Boring? Absolutely. Also the move I see skipped most often, usually by teams who consider it beneath them.

2. sameAs to the hubs

The sameAs property is how you tell every engine “these accounts are all me.” Point the Organization or Person schema at the authority hubs — Wikidata, Wikipedia (if there’s an article), LinkedIn, Crunchbase, GitHub, official social profiles. Wikidata matters most: it’s the open reconciliation hub the others cross-reference. A cluster of sameAs links is the strongest disambiguation signal a site can ship on its own.

"sameAs": [
  "https://www.wikidata.org/wiki/Q…",
  "https://en.wikipedia.org/wiki/…",
  "https://www.linkedin.com/company/…"
]

3. Entity-consistent facts

The graph trusts facts that agree with themselves. Founding year, founders, HQ, category, and product names must read identically on the About page, the schema, the Wikidata item, and LinkedIn — and here’s the uncomfortable check I run first: is the founding date on Crunchbase the same as the one on the About page? One contradiction and the engine lowers confidence in all the facts, not just the wrong one. Pick the canonical value once and propagate it.

4. Disambiguation

If the name collides with something better-known (a common word, another brand), help the engine tell you apart: a precise description, a specific @type, category and location facts, and a distinct Wikidata item. The clearer the disambiguating facts, the less likely an answer engine hands your query to the other “apple.”

How AI answers resolve an entity

Walk the pipeline an answer engine runs before it writes a word — I find it clarifies where the effort should go:

• Parse the query into candidate entities and intent.
• Resolve each candidate to a graph node — or fail, and treat it as a plain string.
• Retrieve passages connected to the resolved entities.
• Attribute — prefer sources it can name as recognized entities, because a named source is a safer citation.
• Compose the answer, citing the ones it trusts.

Notice where a keyword-only page falls out: at resolve. If nothing links the page to a named node, it competes on lexical similarity alone — and it’s invisible the moment the engine reasons about the thing instead of the words. Harsh? Yes. Also, I suspect, permanent.

Checklist

• One canonical name used verbatim across site, schema, and every profile.
• Organization/Person schema with a sameAs array to Wikidata, Wikipedia, LinkedIn, and official profiles.
• A Wikidata item exists and cross-links back to your site.
• Founding year, founders, HQ, and category identical everywhere — no contradictions.
• A precise description + specific @type for disambiguation.
• Key facts expressed as clean subject-predicate-object triples.
• External mentions describe you the same way your schema does.

Run GEO checker to see which of your pages the graph can already resolve to a named entity — and which ones read as an anonymous string.

Resolves to a named entity 100%

Matches keyword only 0%

source: internal audits, 2026

The chart is the argument in miniature: a page tied to a recognized entity survives resolution and reaches the citation step, while a keyword-only page drops out before the engine ever considers it as a source. That zero isn’t a rounding error — it’s a locked door!

In short

• A keyword is a string to match; an entity is a thing the graph can name.
• AI answers resolve a query to entities first, then cite recognized-entity sources.
• Build your entity with one consistent name and sameAs links to Wikidata, Wikipedia, and LinkedIn.
• Keep every fact identical across the web — one contradiction lowers confidence in all of them.
• An entity compounds and travels across engines; a keyword ranking resets with each update.

And the next time an answer engine calls the company a fruit, at least you’ll know which of the four moves got skipped.

Sources

• Google, “Introducing the Knowledge Graph: things, not strings” (2012) — the shift from string-matching to entity-based understanding.
• Schema.org — sameAs — the property that binds your profiles into one entity.
• Wikidata — the open reconciliation hub other knowledge bases cross-reference for entity identity.
• Google Knowledge Graph Search API — how entities are queried by machine-readable ID.
• Aggarwal et al., “GEO”, KDD ‘24 — arXiv:2311.09735: citation depends on a source being an attributable, extractable entity.