Knowledge Graph Navigator

Entity SEO: The Complete Guide (From Strings to Things)

Entity SEO is the practice of making the things a website is about (its organization, its people, its products, its topics) identifiable to search engines as distinct things with stable identifiers, rather than as collections of keywords. It rests on one observation: search systems maintain a knowledge graph of entities, and a brand that exists in that graph can be retrieved, described, and displayed in ways a brand that exists only as words on its own site cannot. The tactics are ordinary web publishing work, applied with identity in mind.

What “things, not strings” actually changed

Google announced the Knowledge Graph in May 2012 under the headline “things, not strings.” The phrase describes a change in what the system retrieves against. A string-matching retrieval system looks for documents containing a sequence of characters. An entity-aware system first decides which thing a query refers to, then looks for documents about that thing.

Three consequences follow, and practitioners can act on them.

Queries get resolved before documents get ranked. “jaguar top speed” is ambiguous at the string level and unambiguous at the entity level once the system commits to the animal or the car. Content that clearly describes one referent competes for that referent; content that hedges across both competes poorly for either.

Synonyms and paraphrases stop being separate targets. “who founded neo4j” and “neo4j founders” are the same question about the same entity. Writing two pages for two phrasings produces two thin pages, not two rankings. See /seo/semantic-seo/.

Some results are keyed to entities rather than to pages. Knowledge panels, “people also search for” carousels, and entity-attribute answers are drawn from the graph. No amount of page optimization produces them, because they are not page results. See /ecosystems/google-knowledge-panel/.

What did not change: pages still rank, links still matter, and relevance is still assessed against page content. Entity SEO is a layer on top of ordinary SEO, not a replacement for it.

Three kinds of claims, kept separate

The literature on this topic mixes documented behavior with speculation, so it is worth stating which is which.

Documented. Google publishes that it maintains a Knowledge Graph, that knowledge panels are generated from information in it, that the graph draws on sources across the web including licensed and public data, that structured data is used to understand page content and to make pages eligible for specific rich result types, and that eligibility is not a guarantee of display. Google Search Central’s structured data documentation lists exactly which types produce which features.

Observable. Anyone can watch entity behavior from outside: query the Knowledge Graph Search API and see whether an entity exists in the lookup subset and what description it carries; watch a knowledge panel appear after a Wikidata item and several independent profiles come into agreement; see a rich result appear in Search Console after valid markup is deployed.

Inference. That corroboration across independent sources increases a system’s willingness to treat a brand as a known entity is an inference from observed behavior, not a documented mechanism. It is a good working model, and this page uses it, but there is no published confidence metric and no Google statement describing an internal score for entity certainty. Claims about “your entity confidence score” describe nothing that exists in public documentation.

Entity catalogs and what each is good for

Public catalogs are the shared reference points against which private data gets reconciled. They differ in what they contain and what they are useful for.

CatalogWhat it isPractical use
WikipediaEncyclopedia articles written by editors, with strict notability rulesThe reference text most entity descriptions derive from; the article’s structure is a usable model for how to describe an entity
WikidataCollaboratively edited structured database; items carry Q-IDs (Q937 for Albert Einstein) and statements built from P-IDs (P31, “instance of”)The most useful sameAs target, queryable via SPARQL, editable by anyone within notability rules
DBpediaRDF extracted from Wikipedia infoboxes, with its own ontology and a public SPARQL endpointBulk analysis of Wikipedia-derived facts; DBpedia Spotlight for entity linking over text
FreebaseCommunity-edited graph acquired by Google with Metaweb in 2010, closed to editing in 2015, with data migration toward WikidataHistorical only, but its lineage survives in Google machine IDs of the form /m/0jcx
YAGOKnowledge base derived from Wikipedia, WordNet, and GeoNames by a research group, with a strongly typed taxonomyResearch and evaluation work where a clean type hierarchy matters more than coverage

Wikipedia’s notability standard is a real gate, and most companies don’t meet it. Wikidata’s standard is lower and different (an item needs a clear identity and serious sources, not encyclopedic significance), which is why a Wikidata item is often the reachable step. Neither is purchasable, and any vendor offering to place either is offering to violate the project’s rules.

The entity home

An entity home is the single canonical URL a brand designates as its authoritative page. For an organization, it is normally the home page or an “about” page; for a person, one profile or bio page under a domain they control.

The concept does two jobs. It gives every external reference a single target, so that profiles, directories, press coverage, and sameAs statements all point at one URL rather than scattering across a home page, three landing pages, and a LinkedIn company page. And it gives structured data a stable @id, so that markup on every page of the site refers to one node instead of minting an anonymous organization node per page.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://neo4j.com/#organization",
  "name": "Neo4j",
  "url": "https://neo4j.com/",
  "foundingDate": "2007",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Neo4j",
    "https://www.linkedin.com/company/neo4j/"
  ]
}

The @id here is a fragment URI on the canonical home page. Every other page on the site can reference https://neo4j.com/#organization in its own markup (as publisher, as provider, as the parentOrganization of a division) and a processor will merge those statements into one node. Property details are at /seo/organization-schema/ and person markup at /seo/person-schema/.

Consistency of naming belongs with this. If a company is “Acme Analytics” in its markup, “Acme Analytics, Inc.” in its footer, “AcmeAnalytics” on one profile, and “Acme” in its press releases, every consumer of that data has an extra disambiguation problem to solve. Pick a primary name, put the legal name in legalName and the variants in alternateName, and stop varying it elsewhere.

Corroboration is the mechanism worth working on

The most useful model of entity confidence is agreement across sources that don’t depend on each other. A brand’s own site asserting that it was founded in 2007 in Malmö is one source. Wikidata, a Crunchbase profile, a conference speaker bio, a local business registry, and a newspaper article saying the same thing are independent confirmations. The site’s own claim is the least persuasive evidence available, because it is unverified and self-interested.

This model explains behavior that is otherwise puzzling. It explains why a company can deploy correct Organization markup and see nothing happen, while a company with the same markup plus a Wikidata item and consistent third-party profiles gets recognized. It explains why inconsistency is worse than absence: two sources disagreeing about a founding date give a system a reason to trust neither. And it explains why the practical work looks less like markup and more like getting the facts about a business stated accurately in places the business does not control.

Treated as inference, the instruction is narrow and defensible: decide the canonical facts about the entity (name, URL, founding date, location, key people, category), then make every place those facts appear agree.

Structured data restates on-page facts machine-readably

Structured data does not add information. It restates, in a form a parser can read without natural language processing, facts that the page already states in prose. That framing sets the correct expectation for what it can achieve.

Google uses structured data to understand page content and determine eligibility for specific result types. It is not a ranking factor; Google has not described it as one, and markup describing an entity does not raise a page’s position. What it does is remove ambiguity: a Person node with @id and sameAs says which person, with no inference required from the surrounding text.

Two rules keep markup honest. Every property value must correspond to something a user can see on the page. And every sameAs target must be a page about the same entity, never a related one; linking a company to its founder’s Wikipedia page asserts that a company and a person are the same thing. Formats are compared at /languages/json-ld-vs-microdata-vs-rdfa/, with JSON-LD as the format Google recommends, and validation is available at /seo/structured-data-testing-tools/.

The pipeline that has to resolve your mentions

An extraction pipeline sits between a page’s text and an entry in a knowledge graph. Understanding its stages explains which writing choices help.

Named entity recognition finds spans of text that name things and labels their coarse type: PERSON, ORG, GPE, DATE. It is a text problem, and it fails on names that look like ordinary words, names introduced without context, and pronoun chains that never restate the referent.

Candidate generation looks up each mention in a knowledge base and retrieves every entity it could refer to. “Mercury” retrieves a planet, an element, a Roman god, and several companies.

Disambiguation picks one candidate using the surrounding context. “Mercury is the only metal that is liquid at room temperature” resolves to the element because “metal” and “liquid” match that candidate’s description and not the planet’s.

The writing implications are concrete. Name the entity in full before using a short form. Put a disambiguating attribute near the first mention (“Archer Education, a Tampa-based enrollment growth company” gives a type and a place). Keep a page about one primary entity rather than sharing it between two that a system will have to choose between. Full detail at /concepts/entity-linking-ner-and-extraction/.

What entity SEO cannot do

An honest account of the limits keeps expectations attached to reality.

It cannot guarantee a knowledge panel. Panels are generated when a system holds enough corroborated information about an entity. No application, markup, or purchase produces one, and the claim process applies only to panels that already exist.

It cannot raise rankings by markup alone. Structured data creates eligibility for defined result types. Adding Organization markup to a page that does not deserve to rank changes nothing about its position.

It cannot manufacture notability. A Wikipedia article requires significant coverage in independent sources. A Wikidata item requires a clear, sourced identity. You can’t create either by writing more content on your own domain.

It cannot force an AI to cite it. Generative systems select sources by mechanisms their operators do not fully document and change frequently. Being an identifiable entity with corroborated facts is a reasonable bet on being retrievable; it is not a lever. See /seo/knowledge-graphs-ai-search-and-llms/.

It cannot fix contradictory facts by asserting the preferred one louder. Where a wrong founding date sits in three third-party profiles, the correction has to happen in those profiles.

For developers

The site’s entity layer is a small graph and benefits from being treated as one. Keep a single source of truth for the canonical facts about each entity (a YAML file, a CMS content type, a database table) and generate all markup from it, so the organization’s name cannot drift between templates. Mint @id values in a namespace you control, keep them stable, and never reuse one for a different thing. Store external identifiers as properties, not keys.

For measurement, the Knowledge Graph Search API answers whether an entity exists in the lookup subset it exposes and what name, @type, description, and detailedDescription it carries. It looks up a subset of the graph, not the source of knowledge panels, so treat a missing result as inconclusive. The Wikidata Query Service is the better tool for auditing public facts in bulk, and the underlying model is RDF triples of the kind described at /concepts/triples-subject-predicate-object/.

Related pages

FAQ

What is entity SEO?

Entity SEO is the practice of making the things a site is about identifiable to search engines as distinct things with stable identifiers, rather than as keyword strings. In practice, it means one canonical URL per entity, consistent naming, structured data that restates on-page facts, sameAs links to public identifiers such as Wikidata, and accurate facts in independent third-party sources.

What is an entity home in SEO?

An entity home is the single canonical URL a brand designates as the authoritative page about itself, normally the home page or an about page. It gives external references, profiles, and sameAs statements one target instead of several, and it gives structured data a stable @id that every page on the site can reference so all statements merge into one node.

Does entity SEO improve rankings?

Not directly, and no search engine documents structured data as a ranking factor. Markup makes pages eligible for specific rich result types and helps a system identify what a page is about. The ranking benefit practitioners report comes indirectly, from being retrievable for the right entity and from the content quality that entity-focused planning tends to produce.

How do search engines decide a brand is an entity?

Google does not publish the mechanism. Observed behavior is consistent with corroboration: a brand becomes treated as a known entity when independent sources agree on the same facts about it. A site’s own claims are the weakest evidence available. Practitioners therefore work to make the facts consistent across Wikidata, directories, profiles, and press coverage, as well as on-site markup.

Sources and further reading

Powered by CookieAdmin