How Do You Fix Entity Confusion Between Similar Companies?

Four things people mean by entity confusion

Four different failures get reported with the same sentence — “Google thinks we’re someone else” — and they have four different repair paths. Sorting yours first saves months of work on the wrong layer.

1. Two organisations share a name

The commonest case and the least tractable. Two unrelated companies, often in different countries or different industries, carry the same trading name. One of them has more coverage, more links and an older footprint, and the graph resolves the name to that one. Nothing is factually wrong in either entity; the wrong entity is simply being retrieved.

2. The company is conflated with its founder

A one-person consultancy or a founder-led agency where the human and the organisation share a surname, a domain and a photograph. The graph may hold one item instead of two, or two items with each other’s facts. This is the failure mode that makes a founder’s bio appear under a company query and a company’s funding round appear under a personal one, and it is the reason a founder authority footprint and a company footprint have to be built as separate things rather than one.

3. The company is conflated with its product or brand

A single-product software company whose product name is better known than its corporate name. Schema.org models these as different types — an Organization with a brand, or a SoftwareApplication published by an organisation — but if the site asserts neither, a graph has no reason to keep them apart, and no reason to attach reviews of the product to the company or vice versa.

4. The company is conflated with a defunct predecessor

The hardest to argue and the most damaging. A same-named company went bankrupt, was acquired, was sanctioned or was written about badly, and its history has been absorbed into your item. The graph is not wrong that a company of that name did those things. It is wrong that it was you. This is the only one of the four where the remedy involves asserting a distinction rather than adding a fact.

How a knowledge graph decides you are one thing

A knowledge graph does not store names. It stores items, each with an opaque identifier, and attaches labels to them. On Wikidata the identifier is a QID. In Google’s graph it is a machine ID: Wikidata’s property for it, P2671, is defined as an “identifier for Google Knowledge Graph API, starting with ‘/g/’”, with the note that for identifiers starting with “/m/” you use the separate Freebase property instead — a reminder that today’s graph has a decade of inherited Freebase identifiers underneath it.

Resolution is the step that maps a string, a page or a mention onto one of those items, and Google’s own public interface describes its probabilistic character honestly. The Knowledge Graph Search API “lets you find entities in the Google Knowledge Graph”, returns “only individual matching entities, rather than graphs of interconnected entities”, and attaches a result score to each. It also carries a warning worth quoting before anyone builds a monitoring dashboard on it: “This API is not suitable for use as a production-critical service. Your product should not form a critical dependence on this API.” The page was last updated on 26 April 2024 and says Google is migrating the endpoint to Cloud Enterprise Knowledge Graph.

It is worth being clear about how little Google now publishes about the graph itself. Its own How Search Works material describes the Knowledge Graph as “our own encyclopedia of facts” and, when we read the organizing-information page on 26 September 2026, gave no entity count, no fact count and no description of the resolution process. The widely repeated “five billion entities” figure is not on that page today. Anyone quoting a size for the Knowledge Graph in 2026 is quoting an old press line. What Google does publish is the mechanism for feedback, and the constraints on it, which is the subject of a later section and of how an entity actually gets into the knowledge graph.

The reason resolution fails is banal: ordinary company words are heavily overloaded. We measured this directly rather than asserting it, by counting Wikidata items whose exact English label is a single commercial-sounding noun.

Which identifiers actually disambiguate

The clean answer is: an identifier issued by a registry that verifies existence, expressed on your own site, and present on the third-party record a graph is likely to join against. Each part of that sentence is load-bearing, and the last part is where most programmes fail.

A Wikidata QID is the most useful single identifier a company can hold, for three unglamorous reasons: it is free, it is persistent, and it is the join key that other open datasets use. Wikidata’s notability policy admits items on any one of three grounds, and the one that matters for a company is an item that “refers to an instance of a clearly identifiable conceptual or material entity that can be described using serious and publicly available references”. That is a lower bar than a Wikipedia article and a real bar all the same; the practical comparison is in is Wikidata easier to get into than Wikipedia.

A Legal Entity Identifier is the strongest legal-entity claim available. Wikidata’s P1278 defines it as an “identifier for a legally distinct entity per ISO 17442”, a twenty-character alphanumeric string. It is issued against verified registry data, which makes it the only identifier in this list that positively distinguishes a live company from a same-named defunct one. When we queried GLEIF’s own API on 26 September 2026 it reported 3,443,418 LEI records, with a golden copy publish date of the same day.

A D-U-N-S number — Wikidata’s P2771, “unique company identifier from Dun & Bradstreet”, nine digits — and an ISO 6523 code are both legitimate and both, as we show below, almost absent from the open graph. ISNI and ORCID do the equivalent job for people: ISNI describes its purpose as assigning “to the public name(s) of a researcher, inventor, writer, artist, performer, publisher, etc. a persistent unique identifying number”, which is exactly the founder-versus-company problem stated as a registry mission. The broader question of whether holding any of these moves visibility at all is treated separately in do identifier registries affect search visibility; this guide is only about whether they separate you from someone else.

Now the part that is usually skipped. An identifier disambiguates nothing on its own. It has to appear on both sides of a join, and on the open side it mostly does not.

Two readings of that chart matter. The first is that the identifier Google documents most prominently after the LEI — the D-U-N-S number — exists on 277 business items in the whole of Wikidata. If you are hoping a D-U-N-S number in your markup will be cross-checked against an open record, there is almost nothing to cross-check against. The second is that “different from”, the one property that expresses a distinction, is used on 1.7% of these items. The mechanism for saying “not us” exists and is essentially unused.

The gap is not that the registries are small. It is that they are not linked.

What Organization schema can and cannot assert

Schema.org is the one layer entirely under your control, and its limits are as instructive as its vocabulary. We read the current specification — version 30.1, dated 16 September 2026 — rather than working from memory.

sameAs is the central disambiguation property and schema.org’s definition is unusually strong: “URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Wikidata entry, or official website.” Note that Google’s gloss on the same property in its own documentation is markedly weaker — “the URL of a page on another website with additional information about your organization, if applicable” — which is a fair signal of how much identity work Google is willing to promise it does with the field.

The rest of the useful vocabulary: name and alternateName (“an alias for the item”), legalName (“the official name of the organization, e.g. the registered company name”), url, logo, foundingDate and dissolutionDate, founder, brand, parentOrganization and subOrganization, and the identifier set: leiCode (“an organization identifier that uniquely identifies a legal entity as defined in ISO 17442”), duns, naics, globalLocationNumber, iso6523Code, taxID and vatID.

Google’s Organization structured data page, last updated 8 September 2026, documents every one of those identifier properties and states the purpose explicitly: adding the markup to your home page “can help Google better understand your organization’s administrative details and disambiguate your organization in search results”. It recommends placing the markup “on your home page, or a single page that describes your organization, for example the about us page” — which is the practical instruction most implementations get wrong by scattering conflicting Organization blocks across a site. And it prints the standard caveat: “Google does not guarantee that features that consume structured data will show up in search results.”

Two limits deserve stating plainly. First, Google documents these identifier properties without saying anywhere that it uses them for entity resolution, and no rich result depends on them. They are, on the published evidence, a well-formed statement of identity with no documented consumer. That is still worth making — it costs nothing and it is the only machine-readable assertion you own — but it is not a lever with a measured effect, a pattern that recurs throughout whether schema markup affects citation.

Second, and more importantly: schema.org cannot express a negative. There is no property that means “we are not the company you are thinking of”. You can add facts about yourself, and you can point sameAs at records that are unambiguously yours, but you cannot assert a distinction. For failure mode four — absorbed history from a defunct namesake — this is the whole difficulty. The markup has no sentence for it.

The boundary on what you may assert is set by Google’s structured data policies, last updated 10 July 2026, and it is narrower than it looks. “Don’t mark up content that is not visible to readers of the page” means a sameAs array pointing at profiles nowhere referenced in your HTML is out of policy. “Don’t use structured data to deceive or mislead users. Don’t impersonate any person or organization, or misrepresent your ownership, affiliation, or primary purpose” rules out the tempting shortcut in a name collision, which is to assert the more famous namesake’s records as your own. The consequence Google names is specific and worth knowing: a violation means “a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search”, applied as a structured data manual action visible in Search Console.

Repairing the open layer

Wikidata is the layer where an outsider can actually edit the graph, which is why it absorbs most of the practical work. Three operations cover nearly every case.

Merge, when two items exist for one company. Wikidata’s help page is direct about the trigger — “a merge is performed when two or more items exist in Wikidata on the same topic, concept, or object” — and about the consequence: because item IDs are treated as persistent identifiers, “merged items should be redirected. Never reuse merged items for other things.” Any registered editor can do this with the Merge gadget enabled in preferences. The same page warns against merging things that merely look alike, and if you are unsure it directs you to Project Chat rather than to a form.

Split, when one item holds two entities — the founder-and-company case, or a company that has absorbed a namesake’s history. This is harder, because the second entity now needs to clear notability on its own. In practice that means the criterion quoted earlier: a clearly identifiable entity describable from serious and publicly available references. Independent, dated, published sources about the entity you are separating out are the whole of the argument, which is where the relationship between coverage and a panel becomes concrete rather than theoretical.

Distinguish, using P1889. Its definition is written for exactly this problem: “item that is different from another item, with which it may be confused”, with the aliases “is not”, “distinct from”, “not the same as” and “not to be confused with”. It carries a symmetric constraint, so the statement should be added in both directions — your item points at theirs and theirs at yours. The property is used 1,255,407 times across Wikidata and, as the chart above shows, on only 4,404 items typed as a business. For a company with a namesake, adding this pair of statements is probably the single highest-leverage free edit available, and almost nobody makes it.

Two cautions. Editing the item about your own employer is a conflict of interest and should be declared on your user page and the item’s talk page; undeclared promotional editing gets reverted and attracts scrutiny to everything else you have touched. And Wikidata is not Google’s graph. A corrected QID is an input that Google may or may not take, on no published timetable, which is the standing limitation set out in our guide to the knowledge panel and in whether Gemini decides what goes into the knowledge graph.

Getting the panel itself corrected

The panel is the surface a client looks at, and it is the layer with the least give. Google’s own description sets the frame: knowledge panels “are information boxes that appear on Google when you search for entities (people, places, organizations, things) that are in the Knowledge Graph”; the information in them “comes from various sources across the web”, they are “automatically generated”, and they “are updated automatically as information changes on the web”. Google adds that “some of the information displayed may also come from verified entities who have suggested edits to facts on their own knowledge panels” — which is the opening a company has.

The route is to verify as an official representative, sign in with the verified account, search for the entity and use Suggest edits. What that actually buys, on Google’s own account, is a short list: social profiles, the featured image (supplied as a direct URL to the replacement), removal of certain personal facts such as birth date and marital status, and feedback on the title, subtitle and description. The distinction between changing and giving feedback is doing a lot of work there. Google says it “doesn’t accept or create custom subtitles” and does not create custom descriptions; a title change requires “substantial evidence that our automated systems didn’t make the most representative selection”, and a description challenge requires “strong evidence for why the description is inaccurate”.

Timing and refusal are also documented. Google “reviews feedback from verified users within a few days, and sends a confirmation email with a resolution update”. It “may not make a change you request” where the request contains inappropriate content or where “we can’t confirm its accuracy”. Anyone, verified or not, can submit feedback through the Feedback link on a search feature; verified submissions are the ones that get prioritised.

And then the sentence that decides most entity-confusion projects: “our current policy doesn’t manually create or delete Knowledge Panels.” If the wrong entity has a panel and you do not, there is no request that fixes that. If your panel has merged two companies, you can correct facts within it but you cannot ask for it to be split into two panels. The panel follows the graph; the graph follows the web.

What you can do this week, and what you wait for

The honest division of labour looks like this.

Yours today

Publish one Organization block on the home page or a single canonical about page, not five inconsistent ones, with name, legalName, alternateName for every string you are genuinely known by, url, logo, foundingDate, and a sameAs array containing only records that are unambiguously yours and are also linked from visible page content. Add leiCode, duns, iso6523Code, naics, taxID or vatID for every identifier you actually hold; they are cheap and they are the only machine-readable proof of legal distinctness you own. If you have a product whose name outweighs the company name, mark the product up as its own thing with the company as publisher, rather than leaving a graph to guess.

Fix the registries you control: the LEI record, the D-U-N-S record, the company-registry filing, the LinkedIn company page, the GitHub organisation. Use one legal name and one trading name consistently — in filings, in wire copy, in bylines, in conference programmes. Inconsistent naming across your own coverage is a leading cause of the confusion people blame on Google.

Repair the Wikidata layer: merge duplicates, split conflations where you can source the second entity, add the symmetric different from statement to both items, and declare the conflict of interest while you do it. If the person is the problem, get them an ORCID or an ISNI and put it on the item.

Then earn the thing that actually moves resolution: independent, dated coverage that names your company and its home city or sector in the same sentence, and that does not name the namesake. Co-occurrence in text is what teaches a graph which cluster a name belongs to, and it is the one input a company can commission. It is also slower and less certain than any pitch suggests.

Not yours, at any price

Which entity Google resolves an ambiguous query to. Whether a panel exists for you at all — Google states it does not manually create panels. The subtitle, and whether a custom one exists. The description, which is generated. Any property of a competitor’s entity. The timetable for any of it. And the local layer, which is a separate system with its own rules and its own eligibility test, covered in does a Google Business Profile affect brand search — a same-named business with a verified profile in your city can occupy the box beside your name without touching the knowledge graph at all. What the whole of page one looks like while you wait is the subject of owning page one when someone Googles you.

Nobody should be sold a knowledge-panel correction as a deliverable. What can be delivered is a complete and consistent set of identity assertions, a repaired open graph, and the coverage that makes the correct resolution the likelier one. Those are real, they are cheap relative to their effect, and they come with no date attached.

Methodology and limitations

All specification and documentation quotations were read from primary sources on 26 September 2026. Schema.org definitions are from the live Organization and sameAs pages, which reported version 30.1 dated 16 September 2026. Google’s wording on organization markup is from “Organization (Organization) structured data” on developers.google.com, last updated 8 September 2026; the policy wording is from “Structured data general guidelines”, last updated 10 July 2026; the knowledge panel wording is from Google’s knowledgepanel help centre articles 9163198 and 7534842; the API wording is from developers.google.com/knowledge-graph, last updated 26 April 2024. Wikidata policy and property definitions are from Wikidata:Notability (last edited 12 September 2026), Help:Merge, and the property pages for P1278, P1889, P2671 and P2771. Google’s help centre article on verification requirements, linked from article 9787176 as “Get verified on Google”, was not reachable at a stable URL during this read, so this guide describes the claim flow from the two articles above and does not state the verification criteria. All Wikidata counts are our own reads of the Wikidata Query Service on 26 September 2026 using the query forms printed in the chart sources; they are point-in-time and will drift. Three caveats on them. The business denominator is items whose “instance of” is exactly the plain business class (Q4830453), which excludes the many companies typed as an enterprise, a public company or an industry subclass, so the percentages describe that population and not all companies on Wikidata. The label-collision counts are exact-string English matches and understate real collision, which also runs through aliases, other languages and multi-word names. And Wikidata is not Google’s Knowledge Graph: Google publishes no property-coverage statistics, no entity count on its current How Search Works pages, and no account of how it weights any of these signals, so every Wikidata figure here is evidence about the open substrate rather than about Google’s behaviour. Registry denominators were read the same day: the GLEIF LEI records API returned meta.pagination.total of 3,443,418 with a golden copy publish date of 26 September 2026; isni.org states 16.6 million public records with no date; the ORCID public API wildcard search returned num-found of 29,805,810. GLEIF’s own LEI statistics page and ORCID’s statistics page both render figures in client-side script and returned no numbers to an automated read, which is stated rather than worked around. We found no published study — platform, academic or vendor — measuring how often entity confusion is corrected, how long a correction takes to propagate to a knowledge panel, or whether adding a “different from” statement changes any search result. Every claim in this guide about effect is therefore a claim about mechanism, and is written that way.

Conclusion

Entity confusion is fixable in layers, and the layers are not equally yours. The markup layer you own outright, and it is worth completing carefully even though Google documents its identifier properties without documenting a consumer for them. The open graph layer you can edit, and the most valuable edit available — a symmetric “different from” statement between your item and your namesake’s — exists on 1.7% of business items, which makes it the rare piece of free leverage nobody uses. The registry layer is real but disconnected: 3.4 million LEIs exist and about 1.6% of them have reached Wikidata, so an identifier in your markup is currently an assertion rather than a join. And the panel layer is not yours at all. Google will take feedback from a verified representative within a few days, will change a social profile or an image, will not write you a subtitle, and states in its own documentation that it does not manually create or delete panels. The work that actually shifts resolution is the slowest kind: consistent naming everywhere you appear, and enough independent dated coverage that your name and your facts keep occurring together. Anyone offering to fix the panel is selling the one layer they cannot touch.

Frequently Asked Questions

Sources

1. specification Schema.org, 2026. Organization. Version 30.1, 16 September 2026. Read 26 September 2026. Definitions of legalName, alternateName, leiCode, duns, naics, globalLocationNumber, iso6523Code, taxID, vatID, parentOrganization, founder, brand, dissolutionDate.
2. specification Schema.org, 2026. sameAs. Version 30.1. “URL of a reference Web page that unambiguously indicates the item’s identity.”
3. platform documentation Google, 2026. Organization (Organization) structured data. Last updated 8 September 2026. The disambiguation purpose statement, the placement recommendation, the identifier properties and the no-guarantee caveat.
4. platform documentation Google, 2026. Structured data general guidelines. Last updated 10 July 2026. Invisible-content and impersonation rules; the rich-result-eligibility consequence and structured data manual action.
5. platform documentation Google. Knowledge panels — about. Read 26 September 2026. Automatic generation, sources across the web, verified-entity edits, who can claim.
6. platform documentation Google. Provide feedback on a knowledge panel. Read 26 September 2026. What a verified representative can and cannot change; the few-days review; the no-manual-creation policy; evidence thresholds for titles and descriptions.
7. platform documentation Google, 2024. Knowledge Graph Search API. Last updated 26 April 2024. Individual matching entities, result score, the not-production-critical warning and the migration to Cloud Enterprise Knowledge Graph.
8. platform documentation Google. How Search organizes information. Read 26 September 2026. The Knowledge Graph described as “our own encyclopedia of facts”, with no entity or fact count published.
9. community policy Wikidata, 2026. Wikidata:Notability. Last edited 12 September 2026. The three notability criteria, including “serious and publicly available references”.
10. community documentation Wikidata. Help:Merge. Read 26 September 2026. When to merge, persistent IDs and redirects, the Merge gadget, Project Chat for disputed cases.
11. property definition Wikidata. different from (P1889). “Item that is different from another item, with which it may be confused”; symmetric constraint.
12. property definition Wikidata. Legal Entity Identifier (P1278). “Identifier for a legally distinct entity per ISO 17442”; twenty-character format constraint.
13. property definition Wikidata. Google Knowledge Graph ID (P2671). Identifiers beginning /g/; /m/ identifiers belong to the separate Freebase property.
14. property definition Wikidata. D-U-N-S number (P2771). “Unique company identifier from Dun & Bradstreet”; nine-digit format.
15. live data read Wikidata Query Service, 2026. query.wikidata.org. Media Morpheus counts run 26 September 2026 for exact English labels and for P31/Q4830453 intersected with P856, P2671, P1278, P1889 and P2771, plus site-wide counts for P213, P496, P1278, P1889, P2671 and P2771.
16. registry Global Legal Entity Identifier Foundation, 2026. GLEIF LEI Records API. Read 26 September 2026: meta.pagination.total 3,443,418, golden copy publish date 2026-09-26. GLEIF’s LEI statistics page renders its figures client-side and returned none to an automated read.
17. registry ISNI International Agency. ISNI. Read 26 September 2026. “16.6 million public records”; the persistent-identifier mission statement.
18. registry ORCID, 2026. ORCID public API search endpoint. Read 26 September 2026: num-found 29,805,810. ORCID’s statistics page requires functional cookies and client-side rendering and returned no figures to an automated read.