Why a model can use your content and still name somebody else, and the work that stops it.
Entity SEO is the work of making your company a single, unambiguous thing to search engines and AI models: one name, one description, one stable identifier, consistently repeated on your own site and corroborated by independent sources.
This is the failure that looks like success. An assistant fetches your page, finds the answer, uses it — and names a different company, or describes yours wrongly, or declines to name anyone at all. Access was fine. The content was fine. The model simply was not sure who you were.
An entity is a thing a system can identify as distinct: a company, a person, a product, a place. The difference between an entity and a keyword is that a keyword is a string, and an entity is a referent. “Apple” is a string that refers to at least two very different entities, and every system that uses it has to decide which one is meant.
For your company, the question a model is effectively asking is: when this name appears, how confident am I that it refers to the business at this domain, doing this thing? High confidence gets you named. Low confidence gets you paraphrased without attribution, or confused with something else.
By looking for agreement. A model — or the search system feeding it — sees your name in many places: your own pages, your structured data, your llms.txt, your LinkedIn page, directory listings, press mentions, comparison articles written by others. Where those sources describe the same thing in compatible terms, confidence rises. Where they conflict, it falls.
Two consequences follow. First, your own site is necessary but not sufficient: a company that only describes itself, with no independent confirmation, is the weakest possible entity. Second, inconsistency is actively harmful: three different descriptions on your own site do not add up to three signals, they add up to doubt.
| Property | What it does | Common mistake |
|---|---|---|
@id | A stable identifier, e.g. https://yourdomain.com/#organization, that ties every mention on every page to one node | Different @id per page, or none — each page then describes a separate, unconnected company |
name / alternateName | The canonical name and the spellings people actually use | Missing variants, so “Acme Ltd” and “Acme” look like two things |
description | The one-sentence definition models reach for | Marketing copy, or a different sentence on every template |
sameAs | Links to your profiles elsewhere — LinkedIn, Crunchbase, Wikidata | Dead links, or links to profiles that describe you differently |
founder / Person | A real person node with its own @id and sameAs | A name string with no node, so the person cannot be resolved either |
disambiguatingDescription | States what you are not, when the name collides with something | Unused on exactly the companies that need it most |
The single most important line in that table is the first. A stable @id, identical on every page, is what turns forty pages of schema into one entity instead of forty. The full schema guide →
Then you have a disambiguation problem, and it is more common than it sounds. Generic words, common surnames, acronyms and names shared with a product in another industry all produce it. The symptom is an assistant that describes your company using facts that belong to something else entirely.
The fixes, in order of effort:
disambiguatingDescription to your Organization schema that names the collision directly: “Acme the project management software company is unrelated to Acme Corporation, the manufacturer.”llms.txt with the same content, plus the one-line description you want used.Check your own structured data before blaming the model. When an assistant describes a company wrongly, the cause is very often that company’s own description field, llms.txt or areaServed — old copy nobody updated, repeated back faithfully. We found exactly this on our own site: an AI summary describing us with a market we had left, quoted almost verbatim from our own schema. The worked case →
description. Open /llms.txt and copy the summary. Copy your footer line and your LinkedIn tagline.More than anything on your own site, once the basics are in place. Your site is you describing yourself. Independent sources are the corroboration that makes the description credible.
The sources that count are the ones models already rely on for your category: comparison articles, “best X for Y” roundups, industry directories, trade press, well-maintained profiles on major platforms. Being described consistently in several of them is worth far more than any amount of on-site optimisation. It is also slow, manual outreach work — which is exactly why it is hard for a competitor to copy quickly.
A founder or author with a resolvable identity strengthens the company entity, and vice versa. Give each named person a proper Person node with a stable @id, a sameAs link to a profile that actually resolves, and worksFor pointing back at the organisation. Then reference that @id as author on articles they wrote.
One rule matters more than the rest: a dead sameAs link is worse than none. It is a claim of identity that fails verification. Check every profile link resolves after every deploy.
Take a fictional company, Acme, and walk through the places a model might meet it. On its homepage the Organization schema says: “Acme is project management software for engineering teams of 20 to 200 people.” Its llms.txt opens with the same sentence. Its footer carries the same sentence. Its LinkedIn tagline is a shortened version of it. Three comparison articles written by other people describe it as “project management software aimed at mid-sized engineering teams”. A directory lists it under project management, engineering.
None of those sources is individually impressive. Together they agree, and agreement is the whole mechanism. When an assistant is asked for project management tools for an engineering team of fifty, Acme is an easy entity to name, because every source it can reach points at the same thing.
Now the weak version. The homepage says “the operating system for modern teams”. The schema, generated by a plugin two years ago, says “Acme Ltd — software solutions”. The footer says “building the future of work”. LinkedIn says “productivity platform”. There are no third-party descriptions at all. The product may be identical. The entity is a fog, and a model asked the same question has no reason to name it.
| Traditional SEO | Entity SEO | |
|---|---|---|
| Unit of work | A page and its keywords | The company, person or product as one thing |
| Main question | Does this page match this query? | Does the system know who this is? |
| Key signals | Relevance, links, page experience | Consistency, stable identifiers, independent agreement |
| Where the work happens | Mostly on your own site | Split between your site and everyone else’s |
| Failure looks like | A page that does not rank | Content used without your name, or a wrong description |
The two reinforce each other. A clear entity helps pages rank, and well-ranked pages spread a consistent description. But the failure modes are different, which is why a site can pass an SEO audit and still be misdescribed by every assistant a buyer asks.
@id, identical on every page.llms.txt, footer and your main third-party profiles.sameAs links, checked.disambiguatingDescription if your name collides with anything.The first four are a day’s work. If you want to know whether entity is actually your bottleneck or whether something earlier is failing, the free check tests access, extraction and entity together and tells you which gate is closed.
The work of making a company, person or product a single unambiguous thing to search engines and AI models: consistent naming, one stable identifier in structured data, one description repeated everywhere, and independent sources that agree.
Most often because it is repeating an out-of-date or inconsistent description from your own structured data or llms.txt, or because your name collides with another entity. Compare what it says against your own schema description before assuming the model is at fault.
A schema property that links your organisation or person node to the same entity's profiles elsewhere, such as LinkedIn or Wikidata. It helps systems confirm identity, but only if the linked profiles resolve and describe you consistently.
A schema.org property for stating what an entity is not, used when a name is shared with something unrelated. It lets you say explicitly that your company is distinct from another business, product or term with the same name.
No. Wikipedia has strict notability rules and most B2B companies do not qualify. Consistent descriptions across your own site, major profiles, directories and third-party articles do the practical work.
On-site fixes are quick to ship, but models and search systems re-encounter sources over weeks. Third-party corroboration builds over months. Expect gradual change rather than a switch.