To get a Google Knowledge Panel when you share your name with someone famous, you have to convince Google’s Knowledge Graph that you’re a separate entity, not a noisy variant of the famous one. That takes a single canonical home page, Person schema with a stable @id and a disambiguatingDescription, discriminating facts like birth year and employer, a verified sameAs set, and corroboration from sources you don’t control. Then you hold every signal consistent for months while Google decides you’re real.
That’s the short answer - everything below is the long one, written from inside the problem.
Search “Robert Galasso” and you’ll meet Bob Galasso, a former MLB pitcher with a Wikipedia article and a Knowledge Panel keyed to his version of our name. You’ll also find a physician and a handful of other Roberts, none of whom are me. I’ve spent 10+ years in SEO helping brands turn digital chaos into measurable growth, and the messiest SERP I ever inherited turned out to be my own name. He has a Wikipedia article and a career’s worth of box scores, while I have a personal site and some very deliberate JSON-LD, and the playbook below is how I’m making that be enough.
Why does Google show someone else for my name?
Google’s Knowledge Graph doesn’t index names so much as entities that happen to have names. “Robert Galasso” is a string, and that string currently resolves hardest to a man who pitched in the big leagues before I existed. When several people share one string, the graph does one of two things. Best case, it splits them into distinct entities and disambiguates right in the results. Default case, it merges the weaker signals into whichever entity is already strongest. A Wikipedia article works like gravity here, pulling everything ambiguous toward it, even though his panel is keyed to “Bob” and I go by Robert.
One observation shaped my entire approach: my qualified queries were already clean. My name plus my city resolved to me, and so did my name plus my profession, which left only the bare-name query contested. Google already knew a second Robert Galasso existed, it just wasn’t confident enough to say so without a hint from the searcher.
The gap between “resolved with a qualifier” and “resolved bare” is the entire job, and rankings won’t close it - identity resolution will.
What is entity SEO?
Entity SEO is the practice of making a person, brand, or thing machine-readable as a distinct node in a knowledge graph, so search engines and AI systems can tell who you are, what you do, and who you are not. Classic SEO optimizes pages to rank for queries, while entity SEO optimizes the identity behind the pages: one stable identifier, consistent attributes, and corroborated connections that let a machine collapse scattered mentions into a single confident record.
For anyone building a personal brand on a common name, the “who you are not” clause is the whole point. You’re not trying to outrank your namesakes - you’re trying to hand Google enough discriminating data that it mints a separate node for you instead of filing your signals under someone else’s.
How do you get a Knowledge Panel for a person?
What follows is the exact sequence I’m running on robertgalasso.com, using the same structured-data discipline I bring to client work, pointed at myself, and I’m just dangerous enough with JSON-LD to write and validate every node by hand. The order of these steps matters more than people expect.
-
Pick one entity home and never move it. Every entity needs a canonical URL that all other signals reference. Mine is my about page: one URL, one bio, one place where the facts live. If your identity is spread across six bios on six platforms with no hub, you’re asking Google to guess which one is authoritative, and Google doesn’t tend to guess in your favor.
-
Publish Person schema with one stable @id. My Person node carries the same @id on every page of this site, byte-identical, from the homepage to my capabilities page to this post. The repetition is deliberate (scattered signals don’t accumulate, identical ones do).
-
Write a disambiguatingDescription that names the confusion. Schema.org built this property for exactly this situation; its canonical example separates two U.S. presidents who share a name. One machine-readable sentence that says what you are and what you’re not, and mine mentions baseball explicitly.
-
Stack discriminating properties. Mine carries birthDate 1995, birthPlace Alpharetta, Georgia, jobTitle Lead of Innovation and AI, and worksFor Tandem Interactive, because every property my namesakes cannot share is another fence post around my node. A birth year does more disambiguation work than a thousand words of bio, because a retired pitcher and I can’t both have it.
-
Build a reciprocal sameAs set. Link every profile you actually control from the entity home, and make every profile link back. Same name string, same title, same city, everywhere. Then prune ruthlessly: a sameAs URL that 404s, or points at a profile you abandoned years ago, is evidence against your coherence, not for it.
-
Add registry-grade identifiers, in the right order. My plan runs ORCID first and Wikidata second, because ORCID I can claim today and start citing immediately. Wikidata has sourcing standards, and it wants references that exist independently of me, so it comes after the corroboration exists, not before. Run this backwards and your entry gets deleted.
-
Earn corroboration you don’t control. Panels render when independent sources agree the entity exists: editorial profiles, coverage, records with oversight behind them. Your own site is the anchor rather than the argument - markup tells Google what to believe, and other people’s sites tell it whether to.
What does disambiguatingDescription look like in practice?
Here’s a trimmed version of the Person node I publish:
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://robertgalasso.com/#person",
"name": "Robert Galasso",
"url": "https://robertgalasso.com/",
"jobTitle": "Lead of Innovation and AI",
"worksFor": { "@type": "Organization", "name": "Tandem Interactive" },
"birthDate": "1995",
"birthPlace": { "@type": "Place", "name": "Alpharetta, Georgia" },
"disambiguatingDescription": "SEO and AI marketing lead born in 1995. Not the former MLB pitcher Bob Galasso.",
"sameAs": ["https://..."]
}The disambiguatingDescription is doing two jobs at once here, since it positively identifies me through profession and birth year while explicitly severing the connection Google is most tempted to make. Naming the confusion outright works better than pretending it isn’t there.
What doesn’t work when your name is contested
The instinct most people have is to publish more of everything: more posts, more bylines, more volume under the bare name. On its own, that mostly feeds the ambiguity: you’re pumping content into a contested string without ever telling the graph who’s speaking. Volume helps after the entity scaffolding exists to catch it, and barely at all before.
The other tempting shortcut is treating markup as magic, when on-site JSON-LD, no matter how clean, can’t substitute for corroboration. Google treats self-declared data as a claim, not a fact, and it weighs claims against what the rest of the web says.
There are a few more failure modes I’ve watched play out:
- Schema that contradicts itself: different @ids, name strings, or job titles across pages
- sameAs links pointing at dead URLs or profiles you stopped maintaining
- A premature Wikipedia article, which gets deleted and leaves a public record of the deletion
- Ignoring the namesake and hoping Google untangles things out of politeness
How long does it take to get a Knowledge Panel?
Months at minimum, and the bare-name query moves last. Entity consolidation is slow because it’s a confidence system: every consistent signal compounds, every contradiction sets you back, and the threshold where Google decides to render a panel isn’t observable from the outside. Nobody can promise you a date, including the people who sell panel services.
What you can do in the meantime is track leading indicators, because qualified queries clean up first and they certainly did for me. Watch your name plus city, name plus employer, and name plus profession, and log what renders every month. When Google starts getting the bare-name query right intermittently, the graph is converging.
I don’t have my panel yet, and I’d rather say that than imply otherwise. What I do have is a name where every signal I control agrees, qualified queries that resolve correctly, and a sequenced plan with ORCID and Wikidata as the next milestones. That is what the method looks like partway through, which is where most people reading this will be.
FAQ
Do you need a Wikipedia page to get a Knowledge Panel?
No, and that’s worth saying plainly because the myth persists. Wikipedia is the strongest single corroborator, but panels generate from the Knowledge Graph, which also draws on Wikidata, structured data, and other sources Google trusts. Plenty of people hold panels without articles, and a premature article that gets deleted hurts more than never having one.
What is disambiguatingDescription in schema.org?
It’s a schema.org property that holds a short description distinguishing an entity from others sharing its name. Machines use it to decide which same-named record a mention belongs to. Write it to state what you are and what you are not.
Can you get a Knowledge Panel if someone famous already has one for your name?
Yes, and the mechanism behind it is more straightforward than people assume. The Knowledge Graph stores multiple entities per name string and disambiguates between them once it has enough data. Your job is to supply discriminating properties, a stable @id, and independent corroboration so Google mints a second node instead of merging you into the first.
How do I know entity SEO is working before the panel appears?
Watch the qualified queries, because those are the ones that move first. My name plus city and name plus profession resolved to me long before the bare name showed movement, and that progression is the clearest evidence the graph is learning. Track those SERPs on a recurring schedule and log every change.
Does entity SEO matter for AI search and LLMs?
It matters more than it does for classic search, honestly, because AI systems inherit the Knowledge Graph’s ambiguity, and a model that can’t separate me from a retired pitcher will happily blend us into one confident, wrong biography. Clean entity data is how you keep the machines from writing fiction about you.