Yes, you can fix a knowledge panel merged with someone else, but not by clicking one button. Google built that panel by deciding two people were one entity. The fix is giving it enough clean, distinct evidence to decide you are two, then using the feedback tools to point at that evidence.
The process has six steps. The order matters, because Google weighs some sources far more than others, and a feedback request with nothing behind it tends to get ignored.
What a merged knowledge panel means
Google’s Knowledge Graph stores every person, company, and thing as an entity with its own machine ID, sometimes visible in URLs as a code starting with /g/ or /m/. A knowledge panel is a display of one entity. When the panel shows your books next to someone else’s university job, or your face next to their birth date, the graph has fused two people into a single ID.
This is called entity conflation, and it happens most when two people share a name and work in related fields. Wikidata’s own help page on the problem says exactly that: conflation tends to happen when individuals have similar names and are active in related fields, and it can reflect confusion at Wikidata, at Wikipedia, or at other sources.
The public record is full of examples. In one Google Search Central community thread, an author named Alison Stone found her verified panel had disappeared and been blended with Alison Stone, a philosophy professor at Lancaster University. The product expert who answered guessed Google had decided the professor was the more notable of the two, likely because she had a Wikipedia page and a stronger academic footprint. In an October 2025 thread, an author found her books merged with another author whose name differed by a single middle initial. In 2023, a band named ANHEDONIA found its music, photos, and links mixed into a panel already claimed by a different band with the same name.
Every one of those cases had the same cause and the same cure. The cause was weak separation. The cure was building it.
Confirm it is a merge, not a wrong photo
Before you spend weeks on the wrong fix, diagnose the problem.
A wrong image alone is a photo problem. Google chose a picture from a page it trusts, and the fix runs through image sources and the featured image suggestion, which we covered in our guide to a knowledge panel showing the wrong picture.
A merge looks different. The panel mixes facts that belong to two people: your job title with their birth year, your books with their degree, your website with their social profiles. Search your name in quotes along with each distinct fact. If one search brings up your work and another brings up theirs, but both feed the same panel, it is a merge.
A duplicate is the opposite problem. Your own signals are split across two entities, so neither panel is strong. That needs consolidation, not separation.
It also helps to search the other person’s name with their own distinguishing details. If their panel appears with your facts bleeding into it, you are looking at the same merge from the other side, and the evidence from both directions will strengthen your feedback.
Write down every wrong fact and where it seems to come from. That list becomes the evidence for every step that follows.
The Separation Stack
We call the fix the Separation Stack. It has four layers, built from the bottom up, and each one gives Google a reason to treat you as a distinct entity.
The bottom layer is your entity home. That is the single page on your own site that defines who you are, usually an About page. It should state your full name, a short descriptor that separates you from the namesake (“Alex Morgan, Phoenix real estate attorney”), your location, your role, and links to every official profile.
The second layer is structured data on that page. Person schema (or Organization schema for a company) with your name, job title, employer, and a complete sameAs list pointing to your LinkedIn, X, Crunchbase, Wikidata item, and any other profile that is unmistakably yours. Never link to a profile that might be the other person’s.
The third layer is the reference graph: Wikidata, and Wikipedia if you are notable enough. This is the layer Google draws on most directly, and it is covered in its own step below.
The top layer is third-party corroboration. Articles, directory listings, and bios on reputable sites that describe you with the same distinguishing details. Coverage that names your city, your field, and your company together helps Google tell you apart. Coverage that only says your name and “entrepreneur” does not.
For a company, the same layers apply with Organization schema, a Google Business Profile if you serve customers locally, and registry records such as your state business filing or Crunchbase entry. Companies merge less often than people, but when they do (two firms called Summit Capital, say), the fix uses the same four layers.
Press coverage deserves a special note because it does double duty. An article that profiles you with your city, your company, and your photo feeds the top layer of the stack and gives Google a trusted page to verify feedback against. If your existing coverage is thin or uses only your bare name, earning two or three detailed features is often the fastest way to tip the balance. That is a big part of what our GoogleMe program does for clients with common names.
Build the stack before you file feedback. A feedback request that points at a clean entity home, matching schema, a separate Wikidata item, and three articles with consistent details has something to stand on.
Claim and report through Google
With the stack in place, use Google’s own tools.
If the merged panel shows a “Claim this knowledge panel” option and you can verify through one of the official profiles Google lists, claim it. Verified users can suggest edits to facts in the panel, and Google says it reviews verified feedback, though it also checks every suggestion against public information on the web. That is why the stack comes first.
If the other person has already claimed the panel, you cannot claim it too. Use the public Feedback link at the bottom of the panel instead. Submit each wrong fact as a separate item. Describe the merge in one plain sentence, such as “This panel combines two different people named Jordan Lee. The books listed belong to Jordan Lee, the Chicago novelist. The university role belongs to Jordan Lee, the Boston economist.” Then link to public pages that support each half.
Consider reaching out to your namesake as well. The product expert in the Alison Stone thread suggested exactly that: ask the other person to claim their panel and suggest edits that remove your work. It feels awkward, but they usually want the mess fixed as much as you do.
Fix Wikidata and schema
Wikidata is the most direct lever most people never touch, and it is where conflation often starts.
Search Wikidata for your name. If an item exists that mixes facts from both of you, follow Wikidata’s own guidance on conflation. Do not just delete the other person’s facts. The help page explains how to split a conflated item into two, move statements to the right person, and keep identifiers on the original item when they belong to both. If you are unsure, post on the item’s talk page and let experienced editors help. Edits by the subject of an item are scrutinized, so cite reliable published sources for every statement.
If no item exists for you and you meet Wikidata’s notability bar, create one with distinguishing statements: occupation, employer, country, official website, and references. Then add the “different from” property (P1889) pointing to your namesake’s item. That single statement tells any system reading Wikidata that the two items must not be merged.
Back on your site, update your schema to include the Wikidata URL in sameAs. Now your entity home, your structured data, and the reference graph all point at each other and away from the other person.
Mistakes that make a merge worse
Some fixes backfire. These are the ones we see most.
Linking to the wrong profiles. People in a hurry add every result for their name to their sameAs list, including a namesake’s old Twitter account or a LinkedIn profile that is not theirs. That tells Google the two of you really are one entity. Audit every link before it goes into schema.
Using the bare name everywhere. If your bios, press releases, and podcast pages all say only “Jordan Lee, entrepreneur,” you give Google nothing to separate on. Pick one distinguishing descriptor and use it the same way everywhere: city, field, company, or middle initial. Consistency beats cleverness.
Editing the other person’s facts away. Deleting a namesake’s birth date or degree from Wikidata without moving it to a correct item can look like vandalism and gets reverted. Worse, it can get your own edits watched. Follow the split process and cite sources.
Changing your name format midstream. Switching from “Jordan Lee” to “J. Michael Lee” in the middle of a cleanup creates a third entity candidate rather than fixing the first two. If you want a new name format, adopt it everywhere at once and treat it as its own project.
Filing feedback ten times a week. Repeated identical reports do not speed anything up. One precise report per fact, with sources, followed by a monthly check, is the pattern that works.
Ignoring the AI layer. ChatGPT, Perplexity, and Gemini draw on many of the same sources as the Knowledge Graph, and a knowledge panel merged in Google often shows up as a merged biography in AI answers too. Ask each assistant who you are after every major fix, and you will see whether the separation is spreading beyond Google.
How long until Google splits you
Expect weeks to months, not days. Google recrawls and reprocesses entity data on its own schedule, and a merge built over years of mixed signals does not unwind overnight.
Track progress with a simple log. Once a month, search your name in a private window, screenshot the panel, and note which wrong facts remain. Search your name plus your distinguishing descriptor as well, because a separate panel for you often appears there first, before the main name query changes. If a fact stays wrong after two months, find the source still feeding it and fix or outweigh that source.
In short: diagnose the merge, build the Separation Stack, file precise feedback, clean up Wikidata with a “different from” link, and log the results monthly. A knowledge panel merged with someone else is a data problem, and data problems yield to better data.