Google rarely mixes you up because it knows too little about you. It mixes you up because it knows two true things and cannot tell which belongs to whom.
That is the part most people get backwards. When a founder discovers that Google’s knowledge panel shows her photo next to a novelist’s book list, or that an AI assistant credits her company with a namesake’s lawsuit, the instinct is to publish more. More bios, more guest posts, more pages with the name on them. But if those new pages describe the person in different ways, each one adds a fresh, half-matched signal to a pile that is already confused. Volume without consistency can make entity disambiguation harder, not easier.
The fix is quieter than that. It is a short list of unambiguous facts, stated the same way in the places machines check first, connected by markup that points in one direction. This guide walks through how that works and how to apply it, using Google’s own documentation wherever Google has published something specific.
Why does Google mix up two people with the same name?
Start with what Google says about itself. Its Knowledge Panel Help page describes the Knowledge Graph as “our database of billions of facts about people, places, and things.” Knowledge panels are the boxes that show some of those facts, and Google says they are “automatically generated,” with information coming “from various sources across the web.” In a 2020 post on its Keyword blog, Google said it draws from hundreds of sources, with Wikipedia commonly cited but not the only one.
Every entity in that graph has a machine identifier. Older ones start with /m/, a format inherited from Freebase, the open knowledge base Google acquired and later shut down. Newer ones start with /g/. Wikidata tracks both: its property for Freebase IDs notes that existing /m/ identifiers remain in use, “including by Google Knowledge Graph,” and a separate property holds the /g/ IDs. Google Cloud’s documentation on its Enterprise Knowledge Graph explains the general idea behind these IDs, describing a master entity that gets a new ID “after reconciling and merging entities from multiple places.”
That reconciliation step is where collisions happen. Google sees a page saying “Dana Whitfield, author of three thrillers” and another saying “Dana Whitfield, CEO of a logistics software company.” (Dana is hypothetical; the pattern is not.) If the two pages share a name, a city, a photo crop, or a vague job title like “entrepreneur,” the system has to decide whether they describe one entity or two. Get the merge wrong and the thriller writer’s books show up in the CEO’s panel. Get the split wrong and the CEO’s own interviews scatter across two half-built entities, neither strong enough to earn a panel.
AI answers inherit the same problem, plus one more. Assistants that ground answers in web search pull from pages that already carry the confusion. Models trained on web text may have absorbed both namesakes as one blurred profile. You cannot edit a model directly, but you can change what the web says, and that is the input both systems read.
Diagnose the collision before you touch anything
Most teams skip this step and start shipping schema. Do it first, because the fix for a merge is different from the fix for a split.
Begin with plain searches in a private browser window: the name alone, the name plus your company, the name plus your city, and the name plus your job title. Note which knowledge panel appears, if any, and which facts in it belong to someone else. Screenshot everything with dates. You will want a before picture.
Next, look up the entity ID. Google’s Knowledge Graph Search API returns matching entities as JSON-LD with a name, description, type, and an @id you can read as the machine identifier. Google notes the API is read-only and warns that it is not suitable as a production-critical dependency, which is fine, since you only need it for diagnosis. If two IDs come back for two people with your name, you have a split that is working, and your job is to make your own side stronger. If one ID comes back carrying facts from both, you have a merge, and your job is to pull them apart.
Then ask the AI assistants your buyers use. Ask “Who is [name]?” and “What does [company] do?” in two or three of them, and record the answers verbatim with the date. Do not treat any single answer as a measurement. Treat the set as a symptom list: which wrong facts recur, and which sources do the assistants cite when they cite anything?
Last, trace each wrong fact to a page. A misattributed birth year usually comes from somewhere specific: an old speaker bio, a data-broker profile, a Wikipedia article about the other person that your name happens to match. Write down the URL beside each error. That list is your work order.
The Tiebreaker Stack has five layers
When a system faces two candidates with the same name, it breaks the tie on secondary facts. I call the set of signals you control the Tiebreaker Stack. It has five layers, and they work best in order, because each layer gives the next one something to point at.
The first layer is the entity home: one page on a domain you own that is about this person or brand and nothing else. For a company, that is the home page or the About page. For a person, it is a dedicated profile page on your site, not a blog post and not a LinkedIn profile you don’t control. It should state the full name, the current role, the organization, the location, and a short list of facts that a namesake cannot share, such as a founding year, a specific product, or a named employer history.
The second layer is markup. Structured data on the entity home tells Google, in a format it reads without guessing, which profiles across the web belong to this entity. That is the sameAs layer, and the next section covers it in detail.
The third layer is the reference graph: the structured databases that knowledge systems lean on, including Wikidata, Crunchbase, the company registries in your jurisdiction, and professional profile sites. These entries should match the entity home fact for fact.
The fourth layer is corroboration: the independent pages that describe you, such as press coverage, conference speaker pages, podcast show notes, and author bios on publications you write for. You do not control these pages, but you do control the bio you hand to each one.
The fifth layer is the claim: verifying yourself with Google as the subject or official representative of a knowledge panel, which gives you a feedback route that ordinary users don’t have.
A namesake can match you on one layer by accident. It is very unlikely to match you on all five. That is the whole logic of entity disambiguation: stack enough distinct, consistent facts that the tie stops being a tie.
Write sameAs markup that points one direction
Google’s Search Central documentation on organization structured data says that adding the markup to your home page “can help Google better understand your organization’s administrative details and disambiguate your organization in search results.” That word, disambiguate, is Google’s own. The same page lists sameAs as a property for the URL of a page on another website with additional information about your organization. Google’s general structured data introduction adds that Google “can make general use of the sameAs property” beyond the documented features.
Schema.org’s own definition is sharper. It describes sameAs as the “URL of a reference Web page that unambiguously indicates the item’s identity,” and gives a Wikipedia page, a Wikidata entry, or an official website as examples. Notice the word unambiguously. A sameAs link to a page that is itself confused, or that describes your namesake, does damage.
For a person, Google documents ProfilePage markup, where the page’s mainEntity is a Person with properties including name and sameAs. For a company, Organization markup on the home page does the same job. In both cases, three habits make the markup work.
Give the entity a stable @id, usually the entity home URL plus a fragment such as #person or #organization, and reuse that exact @id wherever you reference the entity across your site, including the author field on articles. That tells Google that the CEO quoted in your press release and the person on your About page are the same node.
List only profiles you control or that are unambiguously about you. Your LinkedIn, your official social accounts, your Crunchbase entry, your Wikidata item if you have one, and author pages on publications that carry your verified bio. Leave out any aggregator page that mixes you with the namesake.
Point every one of those profiles back. The link from your site to your LinkedIn says “this is me.” The link from your LinkedIn website field back to your entity home confirms it. One-way claims are weaker than a closed loop.
Should you create a Wikidata item?
Sometimes. Wikidata items carry outsized weight in entity work because they are structured, openly licensed, and widely reused, and because they can hold the Google Knowledge Graph ID property that ties an item to a specific Google entity. Wikidata’s discussion pages on notability note that the Knowledge Graph ID property alone has millions of uses.
But Wikidata has a notability policy, and it is enforced. An item is acceptable if it meets at least one of three criteria. It has a valid sitelink to a Wikimedia project page, such as a Wikipedia article. It refers to a clearly identifiable entity that can be described using serious and publicly available references. Or it fulfills a structural need, such as being needed to make statements on other items. If your only references are your own website and a press release, the item is a deletion candidate, and an item created and then deleted leaves you no better off.
Wikipedia is a separate question with stricter rules. Its conflict-of-interest guideline strongly discourages writing about yourself, your employer, or your clients. I don’t recommend that anyone write their own Wikipedia article, and I don’t recommend paying someone to do it for you.
If you do qualify for a Wikidata item, build it the same way you built the entity home: the same name, the same role, the same founding date, an image you have rights to, the official website property, and references to independent sources for each claim. Where Google’s identifier is known from your diagnosis step, add it. Where a namesake already has an item, Wikidata’s “different from” property lets you state that the two items are not the same entity, which is the most literal disambiguation statement on the open web.
Claim the panel, then keep the bios boring
If a knowledge panel already exists for you, Google’s “Get verified on Google” help page explains the process. You sign in to a Google Account, search for yourself or the entity you represent, find the panel, and choose “Claim this knowledge panel” at the bottom or in the About section. Google then asks you to verify through official sites or profiles connected to the entity. Once verified, you can suggest changes through the panel’s feedback option. Google still decides what to change. Be specific in each suggestion and cite a public source that supports it.
If no panel exists, you can’t claim one, which is another reason the first four layers come first. A panel tends to appear once Google has enough consistent information to be confident about an entity.
Then comes the unglamorous part, and it is where most entity disambiguation efforts fail: keeping every bio the same. Write one canonical bio in three lengths, 25 words, 75 words, and 150 words, and make the first sentence identical in all three. Use the same full name, the same title, the same organization name, and the same location every time. Send that exact text to every podcast, conference, and publication that asks. When your role changes, update the entity home first, then the markup, then the reference graph, then the corroborating pages, in that order.
Protect the distinguishing facts above all. If your namesake is a novelist in Chicago and you are a software CEO in Austin, then “Austin,” “CEO,” and your company name should appear in the first sentence of every bio you control. Those three facts are your tiebreakers. A bio that opens with “Dana is a storyteller and builder” gives the system nothing to break the tie with and a word that points toward the novelist.
Last, recheck the diagnosis monthly. Run the same searches, the same API lookup, and the same assistant prompts, and compare them to your dated screenshots. Progress shows up as wrong facts disappearing, not as one perfect result on one day.
As AI assistants take over more of the first impression a buyer gets, the people and brands that stated their facts once, clearly, and the same way everywhere will be the ones those systems describe correctly.