What Is an Entity?

An entity is a particular, distinguishable thing: a company, a person, a place listed in Google Business Profile, a product, an event. What matters is that the entity is the thing, not the word naming it — and that distinction is the whole matter.

A search engine whose crawler works with words can only compare strings of text. One working with entities knows that two different names may point at the same thing, and that the same name may point at different things.

Hence its weight for AI visibility: systems that summarise and answer work with things rather than strings — and a brand not clearly identifiable as a thing is hard to cite correctly.

The difference between thing and word shows best in an everyday example. "Chamber" can be a room, a trade body or a part of an engine; whoever wants one of the three does not want the other two. Conversely, "Volkswagen", "VW" and "the manufacturer from Wolfsburg" are three different strings for a single thing.

That double problem — one name for several things, several words for one thing — is exactly what an entity-based system solves and a string-based one cannot. It is also why search intent is read better once it is clear which thing is being talked about.

And that is why it matters beyond classic search too: an assistant composing an answer needs to know what it is referring to before it can cite it, and a badly identified brand ends up cited as another or not cited at all.

A thing is identified through agreement, not through assertion. Saying on your own site who you are is the starting point; what turns that assertion into identification is other sources saying the same and pointing at each other with reciprocal links.

That is exactly what the markup is for. Google's documentation on organisations shows the use of sameAs: alongside the name and address it lists the profiles where that same organisation appears, so whoever reads the structured data markup can follow the threads.

Consistency, as with hreflang, weighs more than quantity. A name written three ways in three places does not add up to three confirmations; it adds up to doubt — and that is the difference between appearing and appearing identified.

One source of agreement is underrated and costs nothing: your own contact or company page. Full name, address, phone and legal form, written once and in one way, are the reference point everything else is measured against — and on many sites they do not even exist as selectable text.

And a warning about people pages. If your team appears with names and roles, those are entities too, and each inherits the same problems: namesakes, old profiles, accounts from a previous employer. An author page without correct structured data adds no authority, it merely takes up space.

The most expensive fault is also the quietest: linking from the markup to a profile that is not yours. It happens when somebody derives a profile address from the name instead of checking it, and the result is a formally correct statement pointing at somebody else.

I have seen it close up: in a review in August 2026, the author markup of a site with nearly two hundred pages linked to two unrelated people with similar names. No validator and no automated technical SEO review complains about that, because technically the schema.org markup is well formed; it merely points wrongly.

The second fault is accumulated inconsistency: legal name in one place, trading name in another — the same inconsistency that produces duplicate content —, old address in a third. Each version is defensible on its own, and together they identify nobody.

It is worth understanding why this fault survives so long: it breaks nothing visible. The page loads, the validator passes, the link answers. The only symptom is that the declared identity is not the real one — and no automated tool measures that; you have to open the profile and look.

The case I mention was found exactly that way, by looking. A status check would have found nothing: some platforms answer any automated request with an error code, so the correct link and the wrong one look exactly alike from outside. The same trap makes it pointless to check a backlink by its response code alone.

First, decide the canonical form: one name, one address consistent with Search Console, one way of writing them, and use it everywhere. That decision is made once and written down, because otherwise every person on the team will pick their own.

Second, declare it where it belongs with structured data, and use sameAs to link the profiles that really are yours — each one checked by opening the page, not derived from the name.

And third, review what already exists. Old profiles, forgotten directory listings and outdated team pages keep speaking in your name; correcting an old address in three directories is worth more than adding the fortieth meta tag.

A fourth step is hardly ever taken and orders everything else: write down the list of places where your organisation appears. Not to change them all, but to know which exist. Without that list every review starts from zero, and the directory nobody remembers is always the one left out.

And a recommendation on order of work: first what can be corrected today — your own site, your own profiles — and afterwards what depends on third parties. Half of all identity problems resolve without asking anybody for anything, and that half is also the one a log file analysis or any audit can verify afterwards.

The first is treating it as a markup problem. Markup declares what is already true outside; if there is nothing consistent to declare, adding markup does not create an entity, it merely asserts one.

The second is deriving profile addresses from the name. An identifier resembling yours belongs to somebody else as often as to you, and a status check does not catch it: the page exists, it is just not the one you meant.

And the third is expecting a results panel as a reward. Nobody can promise it will appear, and chasing it leads to odd decisions; the sensible goal is that whoever searches your name — or asks an assistant — gets an answer that means you and not a namesake, which also shows in the SERP.

A fourth mistake is changing the canonical form without telling anyone. Renaming the company, moving or merging are legitimate decisions — but if the change happens on the site and not in the twenty places citing it, two versions coexist for months and neither gets confirmed.

And the last, more fundamental: believing this is settled once. Profiles expire, platforms close and their URLs end in 404 errors, people change employer. Keeping a consistent identity resembles maintaining a sitemap more than publishing an article: a recurring task, short each time, and expensive only when left for years.