AI search thinks your founder is your company

We ran our entity analyzer against a well-known payments company and it reported that the site declared two names. One was the company. The other was a founder.

Both were correct. The markup contained an Organization node and a Person node, exactly as it should, and a reader taking the first name it found had a coin flip to lose. That is entity confusion, and the interesting part is how ordinary the markup was that produced it.

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, is based here, and is the same one referred to on these other pages.

Entity clarity is whether a machine reading your site can build that record without guessing. It matters for AI search because an assistant answering what does Acme do is not searching for the string. It is retrieving what it holds about the entity, and if it holds two overlapping half-records, you get an answer that blends them.

Where a machine looks for your name

There are five places, and a page can populate all five differently without anything appearing broken to a human visitor:

• Organization or Person 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 the brand appended after a separator
• The h1, which is a heading and not a name, but gets read as one when nothing else is available
• 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.

Disagreement is the failure, not absence

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

Conflicting names are a larger one. If your schema says Acme Software Ltd, your og:site_name says Acme, your title says Acme | Accounting for builders and your h1 says Finance software that construction firms actually use, a resolver has four candidates and no rule for choosing. Sometimes it picks well. Sometimes it produces two records that each hold half your content, and neither is strong enough to be recommended.

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

The founder problem

The payments example is worth walking through, because the markup was not wrong.

The page declared an Organization for the company and a Person for a founder quoted on it. Both nodes had a name. Both were valid schema. A naive reader taking the first typed node with a name has a real chance of deciding the company is called after a person.

The correct behaviour is to prefer the organisation type when both are present, and only fall back to a person when there is no organisation at all, which is what a personal site or a consultant’s page looks like. We fixed our own analyzer to do that after this exact report, which is a reasonable illustration of the underlying point: even code written specifically to resolve entities gets this wrong without an explicit rule.

What you can do about it from the publishing side is make the relationship explicit. A Person node with a worksFor pointing at the organisation, or an Organization with a founder, states which one is the subject. Two unrelated nodes on a page state that there are two things here and leave the ranking to the reader.

Why your h1 becomes a name

A positioning line makes a bad name and a good heading, and sites put them in h1 because that is what an h1 is for.

The problem only appears when nothing else is declared. Then theh1 is the most prominent piece of text on the page, and a resolver with no better candidate will take it. We handle this by accepting an h1 as a possible name only when it is six words or fewer, on the reasoning that a company name is one or two words and a value proposition is nine.

That heuristic is crude and it is the kind of thing every resolver has some version of. The way to stop caring what the heuristic does is to declare the name, at which point nobody has to guess.

What sameAs is for

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

Pointing your Organization at your Wikipedia article, Crunchbase profile, LinkedIn page or Companies House record gives a resolver something to reconcile against. It is the difference between asserting an identity and corroborating one, and for any company whose name collides with another, it is the single highest-value piece of markup on the site.

What this 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.

It is also not retroactive. A model trained while your markup was ambiguous holds whatever it built then, and fixing the site today changes what a grounded answer can retrieve without touching what a recalled one remembers. That distinction is worth understanding on its own terms, and we wrote about it in measurement versus memory.

Finally, none of the schema here is a promise that anything reads it. Google documents what it uses for rich results. The AI engines document very little, and the case for declaring your entity properly rests on it being unambiguous to any reader rather than on a published contract with a specific one.