When seven people share your name

Being invisible is a problem. Being mistaken for someone else is a bigger one — because the person reading it does not know it is wrong.

Search engines have struggled for years to tell apart people who share a name. The results page shows that honestly: ten blue links belonging to different people, and you pick which is which yourself.

AI answers lost that honesty. They do not offer ten options; they give one answer. And if several people's data got mixed while producing it, what comes out is a person who does not exist.

A concrete example

A search engine was asked "who is Murat Tunalı" — and the domain name was added to the query explicitly. This came back:

Murat Tunalı, born in İzmir in 1982, is a men's hairdresser and an educator-author. Bringing classical barbering together with a modern grooming approach, Tunalı operates as a premium men's hairdresser in Bursa. He is also a professional specialised in family counselling and provides consultancy services in Istanbul.

At least three separate people are in that paragraph: a barber in Bursa, an author born in İzmir, a family counsellor in Istanbul. All three are real. All three are different people. The answer matches none of them.

This is not a "hallucination" — nothing was invented. Every sentence comes from somewhere. The problem is fusion: the model treats fragments attached to the same name as one identity.

Why this happens

Three mechanisms stack on top of each other.

A name is not an identity. To a language model, "Murat Tunalı" is a string; what binds it to an entity is the surrounding context. When the context is weak, everything attached to the same string collects in one pool.

Retrieval brings the nearest, not the truest. A search layer fetches documents that resemble the query. Seven people's pages all resemble the query "Murat Tunalı". Then a model reads those seven sources and writes a single summary — and summarising is, by its nature, fusing.

It feels obliged to answer. A classic results page can say "here are ten results". A chat interface had to learn to say "I don't know", and it does not always do so.

In the same experiment another engine did the opposite: it said it "could not reach a profile clearly matching this description" and listed near-name suggestions. Same data, different behaviour. The difference is the product's posture toward uncertainty.

Whoever is heavier wins

What decides which of seven people sharing a name counts as "the" one is not accuracy but measurable weight.

One measurement: how many records two same-named domains hold in the open crawl archive — one of the sources feeding the training data of large language models.

The archive also holds an unbroken record since 2007: 158 snapshots. Published books, author pages on bookseller sites, a dictionary entry.

Against that stands a one-day-old site. Its on-page quality may be better — flawless structured data, a complete multilingual layer, clean technical ground. None of it matters. If you are not in the corpus, the model does not know you.

The same measurement produced an even sharper comparison: a site with only 238 words and no structured data at all held sixteen records in that archive. On-page perfection does not produce corpus presence. Age and mentions do.

Why this is not an ordinary SEO problem

In classic search the namesake problem is annoying but manageable: the user looks at the list and picks the right one. Click the wrong result and you go back.

In an AI answer there is no going back. The user reads the single answer and moves on. If the answer is wrong, there is no opportunity to learn that it was.

When an employer, a client or a journalist asks about your name and what comes out is not you, the cost sits in a different category from "low ranking". Being invisible takes you off the list; being misrepresented puts you on the wrong list.

How to test yourself

Finding out whether this problem is yours takes half an hour and requires no tools.

One — ask your name. Ask three different AI interfaces "who is X". Read the answer and mark each sentence: which belongs to you, which does not. If there is fusion, try to trace which person each part came from; usually you can.

Two — add your domain to the query. Say "who is X, [yourdomain]". If the engine still describes someone else, the problem goes beyond recognition: it cannot bind you even when handed your own source.

Three — ask without the brand. Without mentioning your name at all, ask a question describing what you do and where. This is your real visibility measurement, independent of the namesake problem. If your namesakes are absent there too, that is open ground.

Four — check the archive. How many records does your domain hold in the open crawl archive, and how many does your namesake's? The ratio between those two numbers predicts well which person a model will "know".

Five — try the misspelling. If your name carries country-specific characters (ı, ş, ğ, é, ñ, ö), ask for the plain form too. Most systems treat the two strings as separate entities.

The output of these five steps is not a list but a diagnosis: is your problem invisibility or misidentification? The two need different medicine. Invisibility resolves with time and mentions. Misidentification does not resolve — it gets managed.

A common mistake

Most people who hear about the namesake problem first add keywords: writing their name more often on the page, filling headings with it, putting it three times in the meta description.

That does not work, because the problem is context, not frequency. What an engine needs in order to distinguish is not how many times the name appears but what it appears alongside. City, occupation, technology, institution, date — those separate. A repeated name does not.

Indeed, on the site I measured, the name never appearing in the body prose was a finding; but the fix was not "write the name ten times". It was "write the name once, together with occupation and city, in a third-person sentence".

What works

Three groups of signals separate you in a crowd of namesakes. None is sufficient alone; the three work together.

1. Explicit separation in structured data

Schema.org defines a field for exactly this job, and most sites leave it empty: disambiguatingDescription. It was designed to separate entities that share a name.

{
  "@type": "Person",
  "name": "Murat Tunalı",
  // Including the plain variant — so queries without local characters match too
  "alternateName": ["Murat Tunali", "M. Tunalı"],
  "disambiguatingDescription":
    "A systems engineer in Istanbul building AI-powered web applications;
     unrelated to the namesakes who are a personal-development author
     or a family counsellor.",
  "jobTitle": "Systems engineer",
  "knowsAbout": ["AI-powered web applications", "Networks and security"]
}

This field is not a ranking signal. Its job is to tell an engine, while it tries to bind you to an entity, which entity you are not.

2. Bidirectional profile links

The sameAs field lists your profiles. But a one-way list is a weak signal: you say "this is my GitHub", and GitHub does not confirm it.

The correct setup is reciprocal — from profile to site, and from site to profile. A two-ended link belongs to a different class of evidence than a one-ended claim.

Writing a sameAs you cannot verify does harm. Listing a profile that does not exist, or is not yours, does not strengthen the entity graph; it pollutes it.

3. A definition sentence in the body text

This is the most overlooked one. A page can carry your name in the <title> tag and in structured data while never mentioning it in the body prose.

When a language model splits your page into chunks and embeds them, those chunks are all it has. If a chunk has no name in it, that chunk does not answer "who is this".

The fix is a single sentence: third person, one line, name + occupation + location. It can be added beneath the existing narrative without disturbing the tone of the text.

What these three share: none is a ranking trick. All three make easier the job the engine is already trying to do — bind the entity correctly.

What I did not do

This problem has a tempting but wrong solution: opening a Wikidata record.

Wikidata is the anchor of entity graphs, and being there genuinely separates you. When I checked during the measurement, the field was completely empty — neither I nor any of the seven namesakes had a record.

It still was not opened. Wikidata has a notability threshold, and a one-day-old site with zero independent mentions and zero published works does not meet it. A forced entry gets deleted and leaves a negative trace on the domain.

The right order is this: real mentions accumulate in independent sources first, and then the record becomes defensible on its own. Imitating the result of a signal instead of producing it at the source fixes the measurement but not the truth.

How long does it take

The honest answer: I do not know, and nobody does.

What is known: training corpora refresh periodically, search indexes update much faster, and an entity becoming "recognised" in a model depends on mentions accumulating. Overtaking an eighteen-year incumbent in a quarter is not realistic.

What is realistic is changing the battle. The name itself is not a winnable query in the short term. But "name + attribute" compounds, and service queries where the brand never appears — that is open ground. None of the namesakes is in those queries.

In my own measurement the most valuable metric was not the citation rate. It was appearing in brand-free queries — because someone who knows your name is already looking for you; the real gain is in being found by someone who does not.

There is something reassuring in that. The crowd of namesakes may be burying you in one query, but that query was not your most valuable one anyway. Someone searching your name mostly knows you already. Someone who does not know you writes not your name but their problem — and in that field you are not competing with seven people, you are competing with the subject.