Entity Disambiguation: When You Share a Name in Search

By Cory Maki · Aug 25, 2026

There are roughly 23,318 John Smiths and 348 George Washingtons living in the United States right now. That's the surface-level version of a problem that quietly damages founders and executives in AI search: when you share a name with someone else, the machine has to decide which of you a page — or an answer — is about. Get that decision wrong, and your funding round gets attributed to a namesake, your book gets credited to a different person, and the AI assistant describing you to a buyer stitches together a biography that belongs to two people at once.

This is the entity disambiguation problem, and it's not new — Google has held patents on it for years. What's changed is the stakes. Generative engines now answer questions about you before a buyer ever reaches your site, and they resolve name collisions with far less context than a human reviewer would. Understanding how that resolution works — and how to steer it — is now part of managing your reputation. This post is about the problem itself and how to fix it; for the broader strategy of establishing yourself as a recognized entity, see Building Your Entity: Schema and the Knowledge Graph for SaaS.

Disambiguation is the one-to-many problem search engines solve before they can rank or answer

A single name can point to many real things, and the engine has to pick one. Disambiguation is the one-to-many case: a single name refers to multiple possible entities. "Georgia" could be the U.S. state or the country. "John Williams" could be any of several people. Google needs to recognize which specific entity is meant in a given context.

The canonical example makes the shape of the problem clear. On a search for "John Williams," the results shown may be for one set of documents on the composer, a second set about the wrestler, a third on the venture capitalist, and on, for any number of the different senses of the name. The engine isn't just matching keywords — it's deciding, page by page, which person each document describes, then grouping them.

Both the query side and the page side get resolved the same way. Both problems are solved through context and through connection to a knowledge base where each entity has a unique identity. In the Knowledge Graph, that unique identity is an entity ID. In Wikidata, it's a Q-number. These identifiers let Google reference a specific entity unambiguously, even when the human-readable name is shared by many things. That unique ID is the mechanism — I've written about how Google assigns and uses them in What Is a KGMID?. The rest of this post is about the problem those IDs exist to solve, and what you can actually do when you're on the wrong side of it.

When AI can't disambiguate you, it doesn't stay silent — it confabulates

The failure mode that hurts most isn't the engine refusing to answer. It's the engine answering confidently and wrong. Anthropic's interpretability research on Claude showed the mechanism directly: when a model recognises a name but lacks detailed knowledge, the "known entity" circuit may activate weakly, overriding the refusal system. In other words, a familiar-looking name is enough to trigger a fabricated answer.

That's exactly the condition a shared name creates. The model sees your name, recognizes it as a "known entity," and fills the gaps — often with details that belong to your namesake. You might ask a question about someone and see real bits of personal information about the individual mixed with a completely fabricated narrative. This kind of specificity makes the hallucination harder to catch because humans are wired to trust detailed statements. A buyer researching you can't tell which half of the bio is real.

AI systems inherit these mistakes from the sources beneath them. AI answers inherit their facts from these sources, and wrong or missing entries follow you into chatbots, AI Overviews and Knowledge Panels. That's why you can't fix this by arguing with ChatGPT — you fix it at the source layer. I go deeper on that correction process in AI Reputation Management: When AI Describes Your Brand Wrong.

Machines resolve identity the same way we do — through corroborating context, not the name alone

The good news is that disambiguation is learnable, and the signals are the same ones a careful human would use. People often recognize identities through context. We see a name, photograph, employer, and job title and can usually infer which person is being discussed. These signals may be clear, but they do not have to be. Several people can share the same name.

Research bears out that context and graph structure do the heavy lifting. In one academic dataset there were 38 authors named "Lei Li," and the structure information of "Lei Li" from Duke University and the graph structure of "Lei Li" from Zhejiang University is different — the graph structure information can be used to capture the global characteristics of the entity. Two people, same name, separated by who they're connected to. Even strong systems aren't perfect: one knowledge-graph disambiguation model links each object to the appropriate Wikidata item with an accuracy of 76%. A quarter of the time, the machine gets it wrong when the context is thin. Your job is to make your context thick.

The single strongest lever is a clean sameAs cluster pointing at authoritative profiles

If you do one technical thing, do this. sameAs connects your entity to external authoritative sources so models can understand who you are across the web — think Wikipedia, LinkedIn, Crunchbase, G2, Gartner Peer Insights, and your social profiles. It isn't a ranking trick. sameAs is not a backlink signal and does not pass PageRank. Its value is entirely in entity verification — helping search engines and AI confirm your identity by cross-referencing information across linked profiles.

That cross-referencing is precisely what defeats a namesake. sameAs helps search engines distinguish between entities with similar names. When your brand has multiple verified presences, sameAs consolidates them into one recognized entity. This prevents split entity signals that confuse AI systems. Not all links carry equal weight. When implementing entity linking, always prioritize authoritative knowledge bases like Wikidata and Wikipedia, as they carry the strongest signals for Knowledge Graph recognition. Wikidata is especially valuable because a Q-number is a machine identifier that ties your entity straight into the graph — though as I explain in Wikidata vs Wikipedia for Entity Building, you have to clear a real notability bar to keep an entry.

Two cautions from the field. First, an unverified or unclaimed Wikidata or Crunchbase profile carries weaker signal than a claimed and maintained one — spend the hour to claim each target you include in the sameAs array. Second, a broken sameAs link is worse than no link. For the mechanics of wiring @id, sameAs, and identifier together, see How to Connect Entities with Schema Markup for the Knowledge Graph.

Your facts have to agree everywhere, or the engine hedges between you and your twin

Disambiguation isn't a one-time schema task — it's a consistency discipline. Three fields do most of the work. Three properties must match across every profile: name, canonical URL, and description. When they drift — a different job title on LinkedIn than on your site, a different company on Crunchbase — you hand the engine a reason to merge you with someone else, or to skip you entirely.

Google resolves entities partly on naming consistency, so pick one form and never vary it. Nail down one canonical name. Google resolves entities by consistent naming — pick one exact form and use it identically on your site, social profiles, and directories. This is the deeper reason cross-source consistency is now a citation requirement rather than a nicety; I make the full case in Why Your Facts Must Match Everywhere for AI Search.

Biographical differentiation is the human-readable version of the same idea. If a namesake shares your name, lean into what separates you: your city, your company, your specific domain of expertise, your co-authors and affiliations. The "Lei Li" example is the whole strategy in miniature — the university attached to the name is what let the machine tell two people apart. Give the engine an employer, a location, a category, and a distinctive body of work, and you become the resolvable entity while your twin stays ambiguous.

What to actually do when you share a name

Run these in order:

1. Confirm which entity the engines think you are

Check whether Google, Wikipedia, and Wikidata recognize you as a distinct entity and what each says. Tools exist for this — my free Knowledge Panel Checker will tell you whether you have a panel and a KGMID at all. If a namesake owns the panel, that's your baseline problem.

2. Build and claim your sameAs cluster

Add Person schema with a sameAs array pointing to your claimed LinkedIn, Crunchbase, and (if you qualify) Wikidata. Keep it to profiles you own and maintain.

3. Make your facts identical across all of them

Name, canonical URL, description, employer, location — one version, everywhere.

4. Claim your Knowledge Panel if one exists

Google builds panels from entity confidence, not on request; the realistic path is in How to Get a Google Knowledge Panel.

5. Track whether the answer actually changed

Disambiguation work is invisible in Search Console. Test direct prompts about yourself across ChatGPT, Gemini, and Perplexity at 30, 60, and 90 days. If you want that measurement done for you, start with a free AI visibility report, or read how I structure the whole effort in the ARC Method audit.

Sharing a name isn't a life sentence in search — it's a signal-strength problem. The person the machine can resolve is the person who wins the answer. This work sits inside the larger discipline of Generative Engine Optimization; if you'd rather have someone run it end to end, here's how to work with me.