When a Real Name Belongs to Someone Who Doesn't Exist
Fiction borrows ordinary names constantly, for the obvious reason that ordinary names are what make a character feel real. Writers reach for common first-and-last-name combinations precisely because they read as unremarkable - which means a common real name and a fictional character's name are frequently identical strings of text. For most names this causes no practical problem, because the character is minor or the show is obscure enough that no meaningful search traffic collides with it. For a sufficiently common name, though, some fictional character somewhere is almost guaranteed to carry the exact name a real, living person also has - and that character's documentation can surface in searches meant for the real person.
This is a distinct problem from ordinary namesake confusion between two real people. A namesake collision is a disambiguation problem: which of two real people did you mean? A fictional-character collision is a more basic problem: is this even a person at all? A searcher who does not immediately recognize a title or a plot reference has no built-in way to tell from a results page alone, and a name common enough to belong to several real professionals is, by the same logic, common enough to have already been assigned to a character in some franchise, novel, or long-running series without anyone involved intending confusion.
The Star Trek Case: Harry Kim's Father
John Kim is a character on Star Trek: Voyager - the father of a main character, Harry Kim, who was played throughout the series by actor Garrett Wang. The character John Kim himself appeared in a single episode, "Author, Author," broadcast in 2001, where he was portrayed by actor Robert Ito. He is not a major character and has no ongoing presence in the series beyond that appearance.
What makes him a genuine search-contamination risk despite that minor role is not his prominence within the show - it is that the fan-wiki ecosystem built around Star Trek documents even minor, single-episode characters in full biographical style: a name, a family relationship, an episode citation, cross-links to related characters and actors. That structure is functionally identical to how a real person's short biography reads, which is exactly the problem: a fictional father-of-a-supporting-character from one 2001 episode can be formatted, linked and indexed in a way that makes it competitive, in a search engine's eyes, with real biographical content sharing the same name.
How Fan Wikis Are Built - and Why They Rank
Fan wikis such as Memory Alpha, the Star Trek wiki referenced above, are built on the same collaborative-encyclopedia software and conventions as Wikipedia itself: a dedicated page per entity, consistent infobox formatting, extensive cross-linking between related pages, and an engaged community that keeps pages updated. Those are exactly the qualities that search engines have historically rewarded - structured data, internal link density, consistent freshness, topical depth. A long-running fandom with an active editing community can produce wiki pages that are more thorough, more consistently formatted and more frequently updated than the sparse or nonexistent biographical content available for many real people who share a character's name.
None of this reflects any intent to deceive. Fan wikis are built by and for fans of the source material, not as identity-verification tools, and they generally make no claim to document real people at all. The contamination is a side effect of good wiki engineering colliding with a name that happens to also belong to someone real.
Why Search Engines Struggle to Separate Fiction From Fact
Search engines and the knowledge graphs behind features like infoboxes and answer panels rely heavily on structured signals - the kind of data a well-built wiki page provides in abundance - to decide what an entity is and how confidently to describe it. Many of those signals are agnostic to whether the entity is real. A page with a name, a clearly defined "appeared in" field, cross-links to related entities and a stable publication history looks, structurally, much like a page about a real person with a name, an employer field, and cross-links to related institutions.
Some knowledge-graph systems do carry an entity-type field intended to distinguish a fictional character from a real person, but that field depends on the source data being tagged accurately and consistently in the first place, and enforcement varies. In practice, a search engine is often reasoning from name-text overlap and page-authority signals more than from a hard, reliable answer to the question "is this a real person." That is enough to produce exactly the outcome this guide describes: a fictional entry surfacing alongside, or above, real biographical content for the same name.
A Quick Way to Tell Whether You've Found a Real Person
A few fast checks resolve most cases without needing to read an entire page. Look for a clear "appeared in" or "portrayed by" field - a fictional character's page will almost always name the actor who played them and the show or film they appeared in, which a real person's biography will not have. Check the domain or wiki name in the URL or page header - a page hosted on a dedicated fan-wiki platform, or bearing a franchise-specific wiki logo, is documenting fiction by definition, regardless of how formally it is written. And look for institutional grounding: a real person's professional biography typically links back to an employer, a licensing body, a publisher, or another verifiable real-world institution, while a fictional character's page links only to other fictional entities within the same franchise.
When any of these signals point toward fiction, the safest assumption is that the page is fiction, even if the name matches exactly and even if the writing style reads like a straightforward biography.
The Larger Problem: Entity Type Confusion in Knowledge Graphs
The Star Trek example is a clear, low-stakes illustration of a broader and more consequential problem: knowledge graphs and search systems generally struggle with entity type confusion whenever multiple entities - real people, fictional characters, organizations, even products - share an identical name string. The more common the name, the more entity types are likely to collide under it, and the harder it becomes for an automated system to resolve a search query to the single entity a searcher actually meant, if there even is a single correct answer.
For a name shared by a large number of unrelated real people, as is the case throughout this site, the presence of even one fictional entity under the same name adds an additional layer on top of ordinary namesake disambiguation. A reader is not just choosing among several real professionals; they are first ruling out at least one entity that isn't a person at all. Recognizing that this is a structural feature of how names get indexed - not a special case unique to any one show or character - is the most useful thing a reader can take from this guide.