Blog · Machine readability

Brand entity resolution: making AI engines sure who you are

Published 8 October 2026 · Updated 12 October 2026 · 9 min read

Brand entity resolution: making AI engines sure who you are
Photograph: mk. s / unsplash

The short answer: Brand entity resolution is the knowledge-graph step where an engine decides that the company on your website, the record in a public database and the name in a news story are one company rather than three. Not the record-matching sense. Google documents structured data properties whose stated job is to disambiguate your organisation from other organisations, so at least one engine says the step exists. When it goes wrong, what a reader sees is a hedge, a blend with a namesake, or nothing at all. The fix is identifiers, repeated consistently, wired to each other.

Almost nobody asks for entity resolution by name. It is a plumbing problem borrowed from records management, and it sits underneath every visibility number anyone will ever show you.

One disambiguation before we go further, because the phrase is shared. In data management, entity resolution means record linkage inside systems you own: deduplicating customer rows, joining two supplier lists, reconciling a CRM against a billing database. That is a real discipline with its own software category, and it is not the subject of this post. Here the records are public, the matcher belongs to somebody else, and the only decision that matters is whether an engine treats your brand and the entity in its knowledge graph as the same company. If you came looking for deduplication tooling, this is the wrong page.

A name is a string, and strings collide

Retrieval systems do not start with companies. They start with text. "Citrel" in one document and "Citrel AI" in another are two different strings until something decides otherwise, and the thing that decides is a matcher: a set of rules and models that compares names, URLs, addresses, codes and co-occurring facts, then assigns a confidence that two records describe the same real thing. None of the five engines in our prompt set publishes its matcher, so read the description above as the general technique from the record linkage literature, not as a report of what any one system does inside.

Two errors fall out of that technique. A false split leaves you as several weak entities, each with a fraction of the evidence, so none of them clears the bar for being named in an answer. A false merge staples you to a different company with a similar name, which is worse, because the answer then arrives confidently with facts that belong to somebody else. In our own audit work false merges are the ones clients notice first, usually because a customer quoted a founding year or a headquarters that was never theirs. We have not counted how often each failure occurs, so that is an impression from client work rather than a rate.

Scale is the reason careful matching is slow to merge. Wikidata's statistics page reported 123,612,541 content items when we loaded it on 12 October 2026, and company names in that pile repeat constantly. At that size, merging on thin evidence produces nonsense, so a cautious matcher needs evidence before it joins two records, and missing evidence looks much like a different company. That is the logic of the technique, not an engine behaviour we can observe.

The four failure modes worth checking first

The name is written four ways. Legal name on the invoice, trading name in the footer, an abbreviation on social, a stylised spelling in the logo alt text. Each variant is a separate string. The schema vocabulary has alternateName precisely for this. It is optional, and it is usually absent on the sites we audit, so the variants stay unlinked. We have not counted that across a sample large enough to put a figure on it.

The facts disagree across your own properties. Founded year on the about page, a different one in a directory profile, a third in an old press release. How a given engine settles that contradiction is not documented by any of the five we run, and we cannot see it from outside. What we can see is the output: on sites whose public facts disagree, the answers we collect are more often hedged or absent than wrong in a specific, correctable way.

The graph has no edges. Your profiles exist but nothing says they belong together. A profile that links back to your domain and a domain that links out to the profile form a two-way edge; a profile sitting alone forms nothing.

The structure is flattened. A holding company, three product brands and a regional subsidiary described as one undifferentiated blob gives a matcher nothing to separate them with. We have watched answers about an enterprise product quote the consumer app's pricing in exactly that situation, on client sites, without having measured how often it happens. parentOrganization and subOrganization exist to draw that line, and so does isPartOf on the pages beneath.

Identifiers beat adjectives

Here is the part most entity advice skips. Matching on names and descriptions is fuzzy by nature. Matching on registered identifiers is not, because an identifier is issued once, against a filed legal entity, by a registry an engine can go and read.

Schema.org's Organization type carries a row of them: leiCode for the ISO 17442 Legal Entity Identifier, duns for the Dun and Bradstreet number, naics for the industry classification, globalLocationNumber, taxID, and iso6523Code, which encodes several of those in one standard string. Google's own Organization documentation, last updated on 8 September 2026, says there are no required properties at all, and it is explicit that some fields are used behind the scenes to disambiguate your organisation from other organisations rather than to change anything visible. The two it names in that group are iso6523 and naics. It does not name leiCode or duns there, so treat those as vocabulary that exists rather than as fields a search engine has told you it reads. The other engines we run publish nothing comparable either way.

The LEI is the underrated one for anyone regulated or selling into finance. GLEIF reported the active LEI population reaching 3.02 million by the end of Q1 2026, with 87.6 per cent of those records fully corroborated against public authoritative sources. An LEI in your markup is a key that resolves against that public file rather than against a name and a city, and iso6523Code is the property that carries it in a form Google has said it uses for disambiguation. Whether a given engine performs the lookup is not something we can observe.

A caution worth stating plainly: do not publish an identifier you do not hold. Google's general structured data guidelines, last updated on 10 July 2026, require markup to represent the page accurately and not to mislead, and a code that belongs to somebody else fails that test on its own terms. That a wrong code also costs you confidence inside a matcher is our inference from how record linkage works, not a documented behaviour. Only assert codes you can show a registry entry for.

Which fields to add, in which order, is the subject of Structured data for AI search: what to mark up first, and the field-by-field version of the Organization node lives in Organization schema done properly.

A resolution check you can run this afternoon

Take thirty minutes and a spreadsheet. No tooling.

  1. Write the canonical record. One row: legal name, trading name, every alternate spelling,

    2. founding year, registered city, one-sentence category, primary domain, and any registry codes you genuinely hold. This row is the answer key.

  2. Diff every public surface against it. Your about page, your footer, your markup, each

    3. claimed profile, your newest press mention. Mark each field match or mismatch. Count the mismatches. Older companies with more public surface tend to carry more of them, and we do not have a baseline that would tell you what a normal count looks like for your size.

  3. Test the namesake. Search your brand name alone, then your brand name plus your

    4. category, in two engines. Note whether a different company appears and what it does. That company is your merge risk, and naming it internally is half the fix.

  4. Ask the engines a resolution question, not a marketing one. "Which company is X, where

    5. is it based, and what does it sell" asks the system to commit to one entity. Hedged answers ("there appear to be several organisations by this name") are a resolution failure stated out loud. Run it twice per engine, because one run is an anecdote.

  5. Check the edges both ways. For each profile in your sameAs list, confirm the profile

    6. itself links back to your domain. One-directional edges come up often in the audits we run. We have not tallied them across audits, so take that as an impression, not a rate.

Expect the engines to disagree with each other on step four, sometimes sharply, for reasons set out in Why five engines give five different answers about you. If you want a longer version of this exercise with the rest of the surface included, the self-check is ten tests in the same spirit.

Honest limits

Entity resolution is necessary and it is not sufficient. A perfectly resolved company with nothing interesting to say still goes unmentioned. Identifiers raise the probability that a matcher commits to you; they do not make an engine choose you over a better-documented rival.

Propagation is slow and uneven. A corrected public record can take weeks to show up in one engine and considerably longer in another, and we have no reliable way to predict which. We have not found published refresh or caching behaviour for the five engines in our prompt set, which is not the same as saying it does not exist anywhere.

We also cannot see the matcher. Everything above is inferred from documented properties, from what the registries publish, and from running the same prompts repeatedly and watching what changes. Treat anyone claiming to know the internal thresholds with suspicion, ourselves included.

The observations from our own work in this post are not measurements. Which failure mode clients notice first, how often alternateName is missing, how often a sameAs edge points one way: those come from audit work, they are a sample and not a census, and we have not kept counts we could show you. Where a number would have been useful we have left it out rather than estimate one.

The last limit is organisational, not technical. Resolution work touches legal, finance, comms and engineering at once, which is exactly why it stalls. Somebody has to own the canonical record and enforce it, which is the argument made in Who owns AEO inside a company.

FAQ

Is entity resolution the same thing as entity SEO? Related, narrower, and more precise. Entity SEO usually covers the whole business of being understood as a topic. Resolution is the specific decision of whether two records refer to one organisation, and it either succeeds or it does not.

Do I need a Wikidata item? It helps, because it is public, structured and widely reused. It is not a prerequisite. A consistent canonical record across properties you already control, cross-linked both ways, does most of the work and is entirely in your hands.

What if another company genuinely shares our name? Compete on evidence rather than on the name. Make your category, location and identifiers unambiguous everywhere, and state what you are not in plain prose on your about page. A sentence that distinguishes you is useful text for a matcher and for a reader.

How long before a correction shows up? Days for a page you control and a crawl cycle to pick it up. Weeks to months for records that propagate through third parties. Anyone offering a date is estimating.

Does an LEI or DUNS number help if we are not regulated? Both resolve to a filing a third party has checked, which is the quality that makes an identifier useful for matching. Google names iso6523 and naics, not these two, among the properties it uses to disambiguate, so we would not claim a search benefit beyond that. Whether a code is worth obtaining purely for this reason depends on effort and what else is already broken.

Sources

All five were opened and checked on 12 October 2026.

Related reading

Structured data for AI search: what to mark up firstOrganization schema done properlyWho owns AEO inside a companyWhy five engines give five different answers about youFAQPage and HowTo after the rich-result changesJSON-LD mistakes that quietly break parsing