Entity disambiguation, for humans who share a name.

Search the name Gilad Sasson and the index returns at least four distinct people. There is the SEO consultant (me, the author of this archive). There is a rabbinic scholar with a substantial publication record. There is a chemical-engineering researcher attached to an Israeli university. There is, as of last season, an eleven-year-old footballer in a youth league whose match-result pages have started outranking the rest of us for the bare query. The disambiguation work, until very recently, was performed by the human clicking through and reading the first paragraph of each result.

That human is no longer there.¹ When a language model answers “who is Gilad Sasson?”, it does not present four candidates and let the reader pick. It generates one biography, fluently and with confidence, and that biography is a weighted average of every Gilad Sasson the training data could find — plus whatever a retrieval system pulled in at inference time, which itself was selected by vector-space proximity that does not know we are four people. Asked enough times across enough models, the answer drifts. Sometimes I get the rabbinic scholar’s publications attributed to me. Sometimes the chemical engineer’s PhD lands in my profile. Sometimes the footballer’s age gets blended in and the resulting “Gilad Sasson” is an SEO consultant who happens to also be in primary school.

This is the entity-collision problem, and it is the single most underrated source of hallucination in 2026-era AI visibility work. The hallucination is not random. It is the predictable result of insufficient disambiguation infrastructure surrounding the entity. The model is doing exactly what its loss function asks of it: producing the most probable continuation given the context, where the context contains conflated identities. Cleaner editorial inside any one Gilad Sasson’s pages cannot fix this. The fix has to live at a layer the model can read at retrieval time.

Why editorial cannot solve it

The standard reflexive answer — “write a clearer bio” — does not work, and the reason it does not work is worth being precise about. A clearer bio adds clarifying tokens to one document. Retrieval pulls passages from many documents. If the rabbinic scholar’s biography is also clearly written and attached to his name, the model now has two clearly-written biographies for the same string and no machine-readable basis to choose. Clarity at the document level cannot resolve ambiguity at the graph level.

The other intuitive answer — “use a more specific name” — also fails for the people for whom the name is the name. I cannot rename myself to fix a retrieval problem; the appositive “Gilad Sasson, also known as Algoholic” is the bridge, and it works only insofar as the model has been shown — across many sources — that the appositive consistently maps to one specific entity. That mapping is the structural fix. Editorial is downstream of it.

What the structural fix is

Three layers, in priority order:

1. A canonical Person schema, on every page that mentions you. The schema.org/Person JSON-LD with a stable @id (typically a URL fragment like #gilad-sasson), the appositive in alternateName, the description carrying the appositive again, and — critically — a sameAs array linking to every verified profile that resolves to the same human. LinkedIn, X, GitHub, ORCID, the canonical company bio, the speaker pages on conferences you have actually spoken at. The sameAs array is the disambiguation bridge: it tells the model “these URLs all resolve to the same entity,” and it is the single strongest signal you can give a retrieval system to converge on the right person.

2. A Wikidata node. Once the sameAs graph is dense enough — five or more verified outbound profiles, several inbound mentions on stable publications — a Wikidata Q-ID becomes both possible to submit and meaningful to cite. Wikidata is the entity-graph layer the major LLMs are demonstrably trained against; a Q-ID is the closest thing to a passport for your identity inside the model. The submission process is slow and curated; budget for it rather than expecting it.²

3. Consistent naming and consistent surroundings, across every surface you control. The name appears in the same form on every byline. The appositive appears beside it on every author bio. The same photo runs on multiple profiles — vector models are increasingly multimodal, and image-consistency is becoming a real signal. The biographical sentence has a stable shape across LinkedIn, the company About page, conference speaker bios, and your own site’s CV. Each consistent surface adds a single weak signal; the accumulation is what converges the model.

Inbound mentions are also part of the graph

The piece most practitioners miss: disambiguation is also driven by the neighbourhoods you appear in. If your name consistently appears beside the same set of other named entities — the companies you have worked at, the events you have spoken at, the products you have built, the peers you have co-published with — the model learns the neighbourhood as part of the entity. Asked about you, it reaches for the neighbourhood it knows. This is why inbound coverage on stable industry publications matters disproportionately for entity work: not for the link equity, which barely registers in the new substrate, but because each inbound mention thickens the neighbourhood around the right identity and thins the neighbourhood around the wrong one.

The practical first move

For anyone with a name-collision problem — and there are more of you than the SEO discourse acknowledges — the practical sequence is unromantic:

1. Audit who shares your name. What does each of them produce? Where do they live in the index?
2. Decide your appositive. “X, also known as Y” or “X, the [profession]” — the form that most uniquely separates you. Use it everywhere.
3. Ship Person schema on every byline page you control, with sameAs and the appositive. (The Algoholic site, for reference, has the full implementation in src/components/Head.astro and src/data/site.ts; the dossier called this Priority 1, and they were right.)
4. Build the sameAs graph: claim every speaker page, every author profile, every directory listing.
5. Submit the Wikidata node once 5+ stable outbound links exist.

Editorial cannot solve a structural problem. Structure can.

Gilad Sasson

aka Algoholic · גלעד ששון

Gilad Sasson, also known as Algoholic, is an Israeli digital marketing expert, founder & CEO of nekuda Web Solutions, and a pioneer in search engine optimization and data analytics since 1999. Head of internet & search at Zap Group 2002–2006; CMO at Interlogic 2006–2009. Speaker at SMX Israel, TNW Amsterdam, Web Summit Dublin, DMIEXPO.

LinkedIn @algoholic Work with me →