The sameAs Problem: Why "Being the Same Business Everywhere" Is Harder Than It Looks

One business, a dozen records, no single source of truth

A single local business does not exist on the web as one object. It exists as a scatter of separate records: the page on its own site, a Google Business Profile, a Yelp page, an Apple listing, entries in industry directories, a Facebook page, mentions in local press, and rows inside the data aggregators that quietly feed all of the above. Each of these is, in the language of the Semantic Web, a distinct identifier for what everyone assumes is the same thing.

The assumption is doing a lot of unspoken work. A human reading two listings for "Bright Smile Dental" at slightly different addresses can usually tell they are the same practice that moved suites, or two different practices, or one practice and one stale duplicate nobody created. A machine assembling an answer cannot rely on that intuition. It has to decide, from the facts on the records themselves and how they corroborate each other, whether these identifiers point to one entity or several. When the facts disagree, the machine is left resolving an ambiguity you did not know you had created.

This is the practical shape of a much older and deeper problem. Before it was a local-search headache, it was a named, studied, and only-partly-solved question in computer science.

The problem has a name, and it was never fully solved

The Linked Data vision, articulated by Bizer, Heath, and Berners-Lee, was that the web could be structured so machines relate real-world things to each other, not just documents to documents. To make that work you need a way to say "the thing described here is the same thing described there." The Web Ontology Language gave it one: owl:sameAs, a property asserting that two identifiers denote the identical real-world entity. It is the direct ancestor of the sameAs property in schema.org that local businesses are told to add to their markup today.

In 2010, Halpin, Hayes, and colleagues examined how owl:sameAs was actually used across the published Linked Data web. Their finding was uncomfortable and durable: publishers were applying the property in at least four looser, non-equivalent senses of "same," conflating things that are genuinely identical with things that merely refer to the same context, share a role, or are related closely enough to feel interchangeable. The strict logical meaning of identity was, in practice, not what people were encoding. The paper is titled, precisely, "When owl:sameAs Isn't the Same."

That matters far beyond the Semantic Web. It establishes that entity co-reference, deciding whether two representations are the same entity, is a known-hard problem that resisted a clean solution even when it was a deliberate, standards-governed act by technical publishers. It did not get solved in the years since. It got worked around, platform by platform, with heuristics: match on name similarity, address proximity, phone number, shared links, and the weight of corroborating sources. Heuristics are probabilistic. They can be wrong, and they can be starved of the corroboration they need.

Search moved from strings to things, which raised the stakes

The reason this abstract problem now touches revenue is that search stopped being primarily about matching strings of text and became about resolving entities. In 2012 Google introduced the Knowledge Graph under the explicit banner "things, not strings," launching with 500 million entities and 3.5 billion facts about them, assembled from sources including Freebase, Wikipedia, and the CIA World Factbook. The unit of understanding shifted from the keyword on a page to the entity behind it.

Once the engine reasons over entities, the first question it must answer about your business is not "does this page mention the query" but "which entity is this, and is it the one the user wants." Every downstream outcome, whether you appear in the local map pack, whether a knowledge panel forms, whether an AI answer names you, depends on the engine first resolving your scattered records to a single, confident entity. If it cannot, you are not ranked poorly; you are ambiguous, and ambiguity is easier to leave out than to feature.

The generative-answer layer inherits this substrate rather than replacing it. The retrieval-augmented systems behind AI Overviews, ChatGPT, Perplexity, and Gemini still reason over entities and passages, and they still depend on corroboration across sources to decide what is trustworthy enough to state. The sameAs problem did not disappear when answers replaced links. It moved closer to the moment of decision.

Marking sameAs is an assertion, not a resolution

A common piece of advice is to add sameAs links in your structured data pointing from your site to your social and directory profiles, as if that closes the identity question by fiat. It helps, and it is worth doing, but it settles less than it appears to.

Why this decides who gets named, not just who ranks

It is tempting to treat identity hygiene as a minor technical chore because its payoff used to be a small ranking nudge. In the answer era the payoff changed shape. When an AI summary appears on a search, the Pew Research Center found users clicked a traditional result in about 8 percent of those searches, versus 15 percent without a summary, and clicked a link inside the summary itself only about 1 percent of the time. The click you used to compete for is often not offered at all.

That inverts what "winning" means. If most answer sessions never click through, the outcome that matters is being the entity the answer names, not a link buried in a citation list nobody opens. And to be named with confidence, the engine has to resolve you cleanly first. A business whose facts contradict themselves across the web is a business the engine is less sure how to name, at the exact moment naming is the whole game.

Winning a citation is necessary but not sufficient, and it is not the same as being read faithfully. Attribution research on retrieval-augmented systems has found that citations are frequently attached to an answer independently of the evidence that actually produced it, with one survey reporting that over 95 percent of answers from the open-source models it tested contained at least one unattributed sentence. Clean entity resolution improves your odds of being surfaced and named; it does not guarantee a citation, because the evidence does not show that degree of control exists yet.

NAP consistency is the floor, not the ceiling

The traditional local-SEO framing of this problem is "NAP consistency": keep your Name, Address, and Phone identical everywhere. That is the right instinct and the wrong scope. Matching three fields is the floor. Entity consistency is the ceiling, and the gap between them is where most businesses actually lose.

An entity is more than three strings. It is a legal and trading name, an address written one canonical way, a primary phone, hours, categories, service areas, the practitioners associated with it, its relationships to parent or sibling locations, and its links to the profiles that corroborate all of it. Any of these can drift, duplicate, or contradict, and each contradiction is a small reason for an engine to hold back its confidence. A stale suite number on one aggregator, a tracking phone number on another, a former business name surviving on a third, and a duplicate listing nobody created can each be individually trivial and collectively decisive.

The correction is not volume. Current local-search guidance is consistent that a smaller set of accurate, high-authority, industry-relevant records outperforms a large pile of low-quality ones, and that duplicates and inconsistencies actively work against you. The work is to settle one canonical version of the entity, correct and de-duplicate what already exists, and make the sources that matter agree, so every engine resolves you to one unambiguous business rather than a cloud of near-matches.

How to read your own entity

The reason this is worth auditing rather than assuming is that the gap is almost always invisible from the inside. Owners see their own site and their claimed Google profile, which are usually correct. They do not see the aggregator row with the old address, the duplicate on a directory they never signed up for, or the review platform where the phone number is a decade out of date. The engine sees all of it.

A rigorous read starts by inventorying where the business already appears and exactly how its core facts are written on each source, then flags the conflicts, duplicates, and stale records that give an engine reason to hesitate. It treats classic search and AI answers as related but distinct surfaces, because the same underlying entity feeds both and a contradiction that dents your local ranking can equally cost you a mention in an answer. And it reports what is confirmed, what is pending platform review, and what depends on a third party, rather than a tidy finished number that is not yet true. Identity is not a field you fill in once. It is a footprint you maintain, because the corroboration that lets a machine trust who you are can always drift back out of sync.