Brand entities: being recognised by Google and by models

What an ambiguous name costs

It is the layer beneath keywords. A page can rank on a phrase without the system having worked out who publishes it; a recognised entity works the other way round, because every mention of the name, wherever it sits, adds to a single profile instead of dispersing.

If a name is shared with other organisations, every mention has to be disambiguated before it can be attributed. The result is that some citations disperse and others end up credited to somebody else.

In our experience ambiguity weighs more in generated answers than in classic results, and the reason is structural: a list of links leaves the decision to the reader, a synthesised answer decides for them, and sometimes it decides badly.

The symptoms of a confused entity

• The name appears associated with sectors that are not yours.
• Generated descriptions converge on details belonging to another company.
• Mentions never consolidate onto a single reference.
• Ask an assistant who you are and the answer changes a lot from one attempt to the next.

When the name is genuinely a problem

The examples people cite are easy ones: Apple the fruit against Apple the company. The real cases are duller and harder: a registered name that is an ordinary word, or sharing a name with a larger foreign company.

In those cases disambiguation does not come from repeating the name. It comes from tying it stably to something the other party does not have: the sector, the city, the names of the people who represent it, the products. The formula to make constant is the name plus at least one distinguishing attribute, used identically on the site, in external profiles, and in the material that ends up quoted by others.

What recognition is built on

Recognition comes from consistency of references: the same name, the same essential description and the same identifiers, repeated everywhere the company appears. Inconsistencies are the material a system builds its own uncertainty from.

Here is the point that often gets inverted: structured data helps you declare, not establish. Declaring a machine-readable list of links while the same information is written differently elsewhere moves the problem rather than solving it.

What structured data says, and what it does not

According to Google, adding Organization structured data to the home page can help Google better understand your organisation's administrative details and distinguish it in search results. Some properties work behind the scenes precisely to tell it apart from others — the examples Google gives are formal identifiers such as iso6523 and naics; others affect visual elements instead, such as which logo is shown.

The properties that matter for identity are few:

• name, the name in its exact form, and alternateName, another common name the company is called by, where one exists and is genuinely recognisable: an acronym, a shortened form. No property is required; you add the relevant ones.
• url and logo, which anchor the name to an address and an image.
• sameAs, which Google defines as the URL of a page on another site with additional information about your organisation — a social profile, say, or a review site.

Two warnings about the markup, both of which save wasted work. The first is that Google states it does not guarantee that structured-data features will appear in results: the markup is a declaration, not a switch. The second is that sameAs links, it does not certify: listing profiles that then say different things makes the situation worse rather than better.

The name you appear under in results

There is a little-discussed detail that bears on the same question. In the attribution line of a result, the one with the favicon and the address, Google shows the site name, for domain-level and subdomain-level results. It works it out itself by putting together WebSite structured data, the og:site_name property, the title tag, heading elements and other home page text, plus references to the site across the web.

You can declare a preference with site name structured data, giving name and url on the home page and, if needed, variants in alternateName. Google's guidance is consistent with everything else: a unique, concise, recognisable name, one per domain or subdomain, consistent with what the home page already says.

The earlier warning applies here too. Google does not guarantee it will use the declared name: it tries to honour the preference, but may pick another if the one given is not recognisable enough. That is another way of saying the same thing — the declaration counts for as much as the confirmation it finds around it.

What to keep aligned

• The exact form of the name, with no undeclared variants.
• The essential description of the business, in one version only.
• Verifiable references to the sources that talk about the company: each has to confirm the same facts.
• Formal identifiers, such as the VAT number and the registered address, where it makes sense to publish them.

The knowledge panel

The knowledge panel is the box that appears beside the results on desktop and at the top on mobile, when Google reckons it knows enough about a subject. It is the most immediate visible signal of recognition, and also the source of two widespread misunderstandings.

The first: for most subjects, you do not request one. Panels are created automatically by Search's algorithm when enough information is available on the open web. There is no request form, and no agency can procure one. Businesses are the exception: their box is created and claimed through Google Business Profile.

The second: Business Profile is not the same thing, but it is not disconnected either. Google describes business profile boxes as a variant reserved for businesses, similar to knowledge panels but managed with a different tool. The practical consequence is that they are administered differently: anyone trying to correct a knowledge panel from Business Profile, or the reverse, is working in the wrong tool. The knowledge panel draws on the Knowledge Graph, the database Google builds from public data, licensed sources and information suggested by content owners.

If a panel already exists, whoever officially represents the subject can claim it and suggest changes after verification. Corrections to names, titles, descriptions and images can be proposed, as long as they are backed by solid evidence. They cannot be imposed: the change is a suggestion, and Google decides.

Wikidata and Wikipedia

They are among the public sources that feed a system's understanding of entities, which is why they get presented as a shortcut. Two things are worth being precise about.

The first is that they do not have the same threshold, and confusing them wastes time. Wikidata admits an item that refers to a clearly identifiable entity describable with serious, publicly available sources: a low bar, which many companies clear. Wikipedia asks for considerably more — as a rule, notability at least at national level and a subject already covered by reliable, independent sources; an article that does not meet it can be proposed for deletion, through a procedure the community debates.

The second is that both have criteria of their own, independent of the goals of whoever would like to get in, and they work when they reflect something that already exists. If the independent sources are not there, the problem is not solved by creating the entry: it is solved by doing the work that produces the sources.

How to check whether you are recognisable

The most direct test is to ask. You query the engines about your own name and read what comes back. But it has to be done in a way that yields data comparable over time, not an impression.

The protocol, in five steps

1. Fix the questions. Who is company name, what does company name do, what does company name specialise in, plus two or three sector questions where the company ought to come up without being named.
2. Repeat each question several times and across different assistants. Answers vary from run to run: a single reading cannot tell an improvement from random variation.
3. Record the same things every time: the question, the engine, the date, whether the subject was identified correctly, which attributes are associated with it, and which sources are cited.
4. Note the errors separately. Wrong attributes, confusion with another company, the wrong sector: those are the diagnosis, and they belong on a list of things to correct.
5. Run the same questions again a few weeks later, without changing them. Fixed questions are what makes the comparison possible.

Two extra checks are worth the time they cost: search the exact name on Google and see whether a knowledge panel appears and what it says; and verify that the sources assistants cite when they talk about you are the ones you expect, because that is often where the error starts.

When a model gets you wrong

It happens, and the instinctive reaction is to fix the site. That is almost always the wrong place to look first.

The useful order is this. First find where the wrong information comes from: very often it is an external source, an old profile, a directory listing never updated, an article confusing two companies. Then correct it there, because as long as the source says that thing the system will keep repeating it. Only then fix the site, making the correct fact explicit and verifiable.

If the error shows in a knowledge panel, there is the suggested-edit route described above. For generated answers there is no equivalent claiming procedure: only generic feedback channels, with no guarantee of correction. The main lever remains changing what the sources say, and waiting for it to be picked up.

Common questions