Entity SEO: how a business becomes machine-readable

// In this article+

Entity SEO is the practice of giving a business a stable, disambiguated identity that a search engine or a language model can resolve on its own: a name, a type, and a consistent set of links back to itself, rather than more content about what the business does. Search Engine Land's definitive guide to entity SEO ↗︎ defines an entity as "a uniquely identifiable object or thing characterized by its name(s), type(s), attributes, and relationships to other entities". Entity SEO is the work of clearing that bar: not writing about a business more, but describing it precisely enough that a machine can tell it apart from every other business with a similar name.

Ahrefs' piece arguing entity SEO is just SEO ↗︎ takes the contrarian view that this is not a separate discipline at all: "If Google has moved to entity-oriented search, then entity SEO is just SEO". That claim only holds once the identity work actually gets done, and most of it sits outside a normal keyword checklist. This piece walks through what establishes an entity, what schema does and does not guarantee, and how a small or mid-size business gets resolved by Google's Knowledge Graph, a database of entities and the relationships between them, and by the models that increasingly answer instead of rank.

What is entity SEO?

Entity vs. keyword: what changed in how engines read a page

A keyword-matching system scores how well a page's words line up with a query's words. An entity system scores something else: whether the page names a thing precisely enough to be distinguished from every other thing with a similar name, per Search Engine Land's guide to entity SEO ↗︎. Two dental practices both named Bright Smile Dental, one in Ohio and one in Oregon, can rank for the same keywords. Only one of them clears the entity bar for any given search, because only one of them is the specific, identifiable thing the searcher meant.

Where 'entity' comes from: Google's Knowledge Graph and schema.org

The vocabulary for describing an entity comes from schema.org, the markup standard Google's own Organization structured-data documentation ↗︎ is built on. Google's Knowledge Graph is where that vocabulary gets applied at scale: entities pulled from structured data, public records, and reference sources, each stored with a name, a type, and a set of attributes. Entity SEO is the operator-facing half of that system: the properties a business controls that feed its own record.

How does a search engine or an LLM actually identify a business as an entity?

The Knowledge Graph Search API: mid, name, type

Google's Knowledge Graph Search API documentation ↗︎ says it "lets you search for entities (people, places, things) using a variety of search parameters like keywords, IDs, and entity types". A query against the API's public endpoint for a known brand name returns a small record: an @id (an internal machine identifier, sometimes called an mid), a name, a @type such as Organization or Corporation, and often a short description pulled from a reference source. That record is the entity, not the website. The website is only the evidence Google used to build it.

Run the same query on your own business name. If nothing comes back, Google has not yet resolved the business as a distinct entity. It may still rank pages from the domain, but it is reading the site as a collection of pages rather than as a named, typed thing with its own record. A language model drawing on that same reference layer inherits the gap: nothing to point to when a user asks who the business is, only text to summarize.

Why disambiguation properties like iso6523 and naics exist

Google's Organization Schema Markup documentation ↗︎, last updated on September 8, 2026, describes properties beyond the obvious ones, including standard business-registry identifiers like iso6523 and naics codes, used to disambiguate an organization from others that share a name or a category. A name and a logo are not unique. A registry number is. That is the entire logic of disambiguation: give the graph something that cannot collide with a competitor's listing.

What schema actually establishes an entity, and what does it not do?

Organization and Person schema: the properties that matter

Google's own specification for Organization schema ↗︎ is explicit that none of it is mandatory: "There are no required properties; instead, we recommend adding as many properties that are relevant to your organization". That freedom is also the trap. Without a floor, most homepages ship an Organization block with only a name and a logo. A shortlist worth adding: name, url, logo, founder (as a Person entity, not a string), employee, contactPoint, identifier, and sameAs. Each property gives the graph one more anchor to disambiguate the business against every similarly named competitor.

sameAs: what it is for and the mistake to avoid

sameAs is the property that ties an entity to its other verified presences. Schema.org's Organization page ↗︎ defines it as the "URL of a reference Web page that unambiguously indicates the item's identity". In practice that means a Wikipedia page, a Crunchbase profile, a verified social account, or a Wikidata item, anything a third party maintains and that names the business unambiguously.

The mistake most guides skip is what to leave out. John Mueller, Google's Search Advocate, warned specifically against pointing sameAs at a Knowledge Graph ID, according to Search Engine Roundtable's report on the warning ↗︎: "I would try to avoid doing that and instead do something like pointing at your contact page or your website's homepage or a Wikipedia article about your company... something that is more stable than the knowledge graph ID". A Knowledge Graph ID can change or be reassigned. A homepage or a Wikipedia article does not move.

What Google's own guidance says schema does NOT guarantee

Structured data has a floor of its own, per Google's structured data guidelines ↗︎: "Your structured data must be a true representation of the page content". Schema does not create an entity. It describes one that has to already be true, already disambiguated, and already corroborated elsewhere, or the markup is just an unverified claim sitting on a homepage. Adding every property on the list does not manufacture authority the business has not otherwise earned.

How does a business get into Wikidata and claim a Knowledge Panel?

Wikidata's notability bar

Wikidata's own notability policy ↗︎ sets a real bar, not a formality: an eligible item "refers to an instance of a clearly identifiable conceptual or material entity that can be described using serious and publicly available references". Run a small B2B company through three checks before attempting an entry:

• Independent, reliable coverage of the company beyond a press release it wrote itself.
• A stable, citable reference, a news article, a registry filing, or an existing Wikipedia page, that a neutral editor could point to.
• A reference that would survive removal of anything the company published about itself.

A ten-person regional firm with no independent press coverage typically fails all three, and the gap to close first is earned coverage, not a Wikidata submission.

Claiming and verifying a Knowledge Panel

Knowledge Panels are the information boxes that, according to Google's knowledge panel help page ↗︎, "appear on Google when you search for entities (people, places, organizations, things) that are in the Knowledge Graph". The panel only exists once Google has already resolved the entity, so the sequence runs in one direction: get resolved first, through consistent schema and third-party corroboration, then search the business or founder name to see if a panel has appeared, and only then look for a claim option tied to a verified account on the business's own site or social profiles.

How do you corroborate an entity beyond your own website?

Third-party mentions that reinforce identity

Jes Scholz's five-step sequence for establishing a brand entity ↗︎ treats corroboration and related-entity linking as two of the five required steps, alongside sponsorship, a consistent bio, and markup. In practice, corroboration means a Wikipedia article, a legitimate industry directory listing, press coverage that names the business correctly, and a founder's professional profiles that link back to the organization the same way the organization's own schema links out to them. Each one is a second, independent voice telling the graph the same thing the schema block already claims.

This corroboration work is also the base layer of what the industry variously calls generative engine optimization (GEO), answer engine optimization (AEO), or AI search optimization, three names for one discipline covered at the category level in GEO vs SEO: what changes when the engine answers: the work of getting cited by name inside a generated answer rather than only ranked in a list. A model has nothing stable to cite about a business it cannot first resolve as a distinct entity, which is the identity-first argument behind WorkHacker's AI SEO services practice. The mechanics of whether a resolved entity then gets named in a specific answer are a separate question, covered in LLM SEO.

Mentions to avoid building

Not every third-party mention helps. Aleyda Solis's framework for citation-era corroboration ↗︎ names manufactured reviews, astroturfed discussions, and undisclosed endorsements as fabricated activity to avoid entirely, since it manufactures independent-seeming experience instead of earning it. A directory listing purchased in bulk, a review written by an employee, or an undisclosed sponsored post does not corroborate an entity. It manufactures a signal that a careful reviewer, human or model, can eventually discount, and it puts the legitimate mentions next to it under the same suspicion.

What to do this week

1. Run your business name and your founder's name through Google's Knowledge Graph Search API ↗︎ to see whether Google has already resolved either one as a distinct entity.
2. Audit your homepage Organization schema against the property list in Google's September 2026 Organization schema documentation ↗︎, filling gaps such as founder, identifier, and contactPoint rather than duplicating fields you already have.
3. Check every sameAs value for a Knowledge Graph ID or any other URL that could change, and replace it with a homepage, a Wikipedia article, or another stable reference, per Mueller's guidance in Search Engine Roundtable ↗︎.
4. Run the business or founder name through Wikidata's three-question notability test ↗︎ and, if it fails, name the specific reference gap to close first rather than attempting an entry anyway.
5. List every third-party page that already names the business, then mark each one as corroboration to keep building on or noise, manufactured or undisclosed, worth removing, per Aleyda Solis's framework ↗︎.

FAQ

Is entity SEO different from schema markup?

No, and yes. Schema is the vocabulary, a shared set of properties like Organization, Person, and sameAs defined by schema.org. Entity SEO is the broader identity-resolution work: making sure what the schema claims is true, disambiguated, and corroborated by independent sources, since schema alone does not create an entity, it only describes one.

Do I need special schema to appear in AI Overviews?

Google's own specification states there are no required properties for an Organization entity, only ones it recommends adding where relevant. Entity SEO is not a fixed compliance checklist. It is the ongoing work of making a business resolvable, which schema supports but does not by itself guarantee.

How long does it take to get a Knowledge Panel?

There is no fixed timeline. A panel only appears once Google has already resolved the business or person as an entity in the Knowledge Graph, so the real variable is how quickly the underlying identity and corroboration work gets done, not how quickly a form gets submitted, according to Google's knowledge panel help documentation.