Entity SEO: making a machine certain of who you are

An assistant asked what your company does is not searching for your name. It is retrieving what it holds about an entity, and if it holds two overlapping half-records under similar names, the answer blends them or picks the weaker one.

Entity SEO is the work of making sure there is one record, that it is yours, and that it says what you would say. Most of it is stating plainly things your site currently implies.

What is an entity?

An entity is the thing a page is about, held as a distinct item rather than as a string of characters. Not the words Acme Software, but a record: this company, which sells this, which is based here, and which is the same one referred to on these other pages.

The distinction is old in search and newer in importance. A ranked list can be assembled from string matching alone. A generated answer cannot, because the system has to decide what it is talking about before it can say anything about it.

Declarations and inferences

There are five places a machine looks for your name, and a site can populate all five differently without anything appearing wrong to a visitor.

• Organization schema in JSON-LD, which is the declaration proper
• og:site_name, set by most themes and rarely revisited
• The <title> element, usually a page title with a brand appended after a separator
• The h1, which is a heading rather than a name but gets read as one when nothing better exists
• Repeated phrases in body copy, which is where a resolver ends up when the four above are absent

The first two are declarations: you stated a fact. The last three are inferences: a machine guessed from evidence.

A site with no declarations is not silent about its identity. It is leaving the answer to whatever the guesser finds most repetitive, which on a lot of marketing sites is a positioning line rather than a name.

Disagreement is the failure, not absence

A missing name is a small problem. A resolver falls back to the domain, which is usually close enough to be workable.

Conflicting names are the larger problem. Four candidates across four sources give a resolver no rule for choosing, and the failure mode is not an error message. It is two records that each hold half your content, neither strong enough to be recommended.

Legal suffixes are the most common version and the easiest to fix. Acme and Acme Ltd are obviously the same company to you and not necessarily to a matcher. Pick the form you want quoted, use it in the declarations, and stop worrying about what the inferred sources say.

What to declare, in priority order

The whole of the mandatory work is one JSON-LD block, present on every page rather than only the homepage.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme",
  "legalName": "Acme Software Ltd",
  "url": "https://acme.com",
  "logo": "https://acme.com/logo.png",
  "description": "Acme is accounting software for UK construction firms.",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Acme_Software",
    "https://www.linkedin.com/company/acme",
    "https://www.crunchbase.com/organization/acme"
  ]
}

• name is the form you want quoted. Short, no tagline, no suffix unless the suffix is genuinely part of how people refer to you.
• legalName carries the registered form, so the registry version and the spoken version can both be correct without competing.
• description is the single most reused string on your site. Write it as a definition rather than a headline, and use the identical sentence in your About page and your llms.txt. Four paraphrases across four pages is the ambiguity you are removing.
• sameAs is covered below, and for a company with a common name it is the highest-value line here.

What sameAs is for

Declaring a name tells a machine what you call yourself. sameAs tells it which existing record you are.

Pointing at your Wikipedia article, LinkedIn company page, Crunchbase profile or companies registry entry gives a resolver something to reconcile against. It is the difference between asserting an identity and corroborating one.

The value scales with how confusable your name is. A company called Zyzzyva gains little. A company called Atlas, Nova or Apex gains a great deal, because those names collide with dozens of others and a resolver with nothing to reconcile against is guessing between them.

The founder problem

A page that quotes a founder usually declares two typed nodes: an Organization for the company and a Person for the human. Both carry a name. Both are valid.

A reader taking the first typed node with a name has a real chance of deciding the company is called after a person. We hit this with our own entity analyzer against a well-known payments company, which is a reasonable illustration that code written specifically to resolve entities gets it wrong without an explicit rule.

The fix from the publishing side is to state the relationship rather than leaving two unconnected nodes on the page. A Person with worksFor pointing at the organisation, or an Organization with a founder, says which one is the subject and which one is an attribute of it. There is more on this failure in the write-up of that specific bug.

Consistency is the actual deliverable

Everything above reduces to one instruction: say the same thing in every place a machine reads. That is harder than it sounds, because the places accumulate.

A theme sets og:site_name at install. A plugin emits Organization markup with whatever was in the settings panel two years ago. Someone rewrites the homepage h1. Someone else edits the title template. Each change is correct in isolation, nothing reconciles them, and the drift is invisible in a browser.

The practical answer is to hold these strings in one place in your codebase and read them everywhere, rather than typing them into each template. It is the same argument as any other single source of truth, and the failure it prevents is the one you cannot see by looking at the page.

What entity work does not fix

Entity clarity keeps you from being confused with something else. It does not make an assistant recommend you, and the two are easy to conflate because both get filed under AI visibility. A perfectly described company with nothing distinctive to say is described perfectly and recommended never.

It is also not retroactive. A model trained while your markup was ambiguous holds whatever it built then. Fixing the site changes what a grounded answer can retrieve without touching what a recalled one remembers, a distinction worth understanding before reading any measurement, and one we cover in measurement versus memory.

And none of this schema comes with a guarantee that a given engine reads it. Google documents what it uses for rich results. The AI engines document very little. The case for declaring your entity properly rests on being unambiguous to any reader rather than on a published contract with a particular one, which is a weaker claim than the field usually makes and the one the evidence supports.

How to check where you stand

The question to answer first is not whether you have schema. It is whether the names your site declares agree with each other.

The free entity analyzer reads a URL and reports every name, description and identifier the markup declares, which source each came from, and whether they agree. Anything it lists as inferred rather than declared is a place a machine is currently guessing.

For where this sits among the rest of the work, the generative engine optimization guide covers the six things that decide whether you appear in an answer, and AI search optimization puts them in the order worth doing them.