Entity SEO
Entity SEO is optimization for entities: uniquely identified things, brands, people and concepts, rather than keyword strings. Search engines represent the world as a network of entities and the relations between them (the Knowledge Graph), and language models assemble brand facts from the available sources. A brand that exists clearly and consistently in that network enters answers more easily than a brand the machine has to assemble from fragments.
In short
| What it is | Building an unambiguous machine identity for the brand and the topics it covers |
| What it consists of | Consistent facts across the site and profiles, structured data, records in external databases |
| How it differs from keyword SEO | A keyword is a string of characters. An entity is the thing the strings point to. You optimize for the thing |
| When it is critical | With ambiguous names, for young brands, and anywhere AI talks about you without a click to your site |
How a search engine recognizes an entity
From string to identifier
During indexing the search engine marks names of people, companies, products and places and tries to attach each to a record it already knows, with its own identifier. The string alone is not enough: the same word can name an e-shop, a constellation and a software company. Context decides: the words around the name, the domain and the other entities on the page. When the attachment fails, the name stays a string and the page competes on keywords only.
Signals that build one identity
- One form of the name. The same name in the header, footer, page titles, profiles and billing details. Variants with or without the legal form are merged only when they appear side by side, for example as name and alternateName in Organization schema.
- Organization schema with @id and sameAs. The block declares name, url, logo, address, founding date and a sameAs array linking to LinkedIn, Wikidata, industry directories and other profiles. Each sameAs link tells the machine that the node on the site and that profile are one thing.
- Confirmation from the other side. The profile links back to the site and carries the same name, industry and location. A one-way statement weighs less than a two-way one.
- Third-party mentions in the same context. Media, directories and partners write the name together with the same industry, city and people. The match of facts around the name counts, not the link.
- Relations to entities already known. The parent company, named clients, products, authors through Person schema and worksFor. An entity connected to recognized nodes gets attached more easily.
Disambiguation when names collide
When a name has several meanings, the machine decides by how many sources tie the name to a given industry, place and people, not by who is bigger. An e-shop whose name is also a common word therefore adds an industry qualifier in the title, H1 and schema and repeats the same description in every profile. A B2B company sharing its name with a firm in another industry keeps the same industry, registered address and company ID in every source, so statements about the two do not get mixed.
Worked example: an e-shop selling children's furniture shares its name with a restaurant in another city. The site, 4 profiles and 2 directories state the same industry, city and founding year for the e-shop; the restaurant has 1 profile and 1 directory entry. That is 7 sources for one reading, 2 for the other. With furniture context in the query the machine picks the right entity; on the bare name it may offer both until the e-shop adds confirmation.
How an entity gets built
A machine needs three things. First, unambiguity: the same name, the same facts and the same numbers on the site, in profiles, in directories and in structured data. Second, relations: links to the parent company, clients, industry and topics through sameAs references and consistent mentions. Finally, third-party confirmation: records in databases such as Wikidata, industry directories and media writing about the brand in the same words.
From our own practice: one number, identical everywhere
The inconsistencies companies run into are mundane: different founding years, different figures for size, different variants of the name across the site, profiles and documents. Until they are unified, the company offers machines several different entities instead of one.
Hence the rule of a single canonical figure: EUR 52 million (CZK 1.3 billion) of managed spend, identical on the site, in profiles and in structured data. A Wikidata record is a later step, not the first: without consistent sources, models assemble brand facts from the site and profiles anyway, which is exactly why those have to match.
Common mistakes
- Different numbers in different places. Every contradiction forces the machine to pick what to believe, and you do not control the pick.
- Optimizing copy while ignoring profiles. Directories and databases matter as much for the entity as your own site.
- Confusing entities with keywords. Ten phrase variants do not help when it is unclear what thing the page is about.
Related terms
See also Knowledge Graph, structured data, E-E-A-T, GEO and semantic search.
Frequently asked questions
Where do you start?
With a fact inventory: write down the canonical company numbers and facts, then align the site, profiles and structured data with them. A contradiction is always the first fix.
Do I need a Wikidata record?
It helps, but it is not a precondition. Consistency of what already exists matters more.
How do I know it works?
Ask the assistants about your brand. When they answer in your wording with the right numbers, the entity holds. When they invent or mix facts, you have a gap.
How we can help
Entity consistency is part of our AI visibility work. Details on the AI visibility agency page.