Entity Consistency: How AI Systems Tell One Business From Another

In June 2020, a real estate agent in Park City, Utah, logged into his Google Business Profile and found that every review his team had earned over years — the five-star praise, the client testimonials, the whole reputation — now belonged to a completely different agent. Not a hack. Not fraud, exactly. Google's own systems had looked at two competing real estate listings, decided they were probably the same business, and merged them. One team's history simply became another team's asset overnight. The Hacker News thread about it collected 590 points and 167 comments, mostly from people who'd had some version of the same thing happen to them.

That's the sharpest possible illustration of what "entity resolution" means in practice, and why it's stopped being an obscure technical concept and started being something that can genuinely wreck a small business's reputation overnight. Search engines and AI models don't read your website the way a person does. They're trying to answer one specific question before anything else: which real-world business, exactly, are we talking about? Get that question wrong, and every other signal — reviews, rankings, citations — attaches to the wrong company.

Where "Entities, Not Strings" Actually Came From

The phrase traces back further than most people assume. In May 2012, Google's then-SVP of Engineering Amit Singhal published a post announcing the Knowledge Graph, describing it as "an intelligent model...that understands real-world entities and their relationships to one another: things, not strings." At launch, it already held more than 500 million objects and 3.5 billion facts connecting them. That was the moment Google stopped treating "Apple" as a word that might mean a fruit or a company or a record label, and started treating it as a specific node in a graph with defined relationships to other nodes — this Apple, headquartered here, founded on this date, distinct from every other thing that happens to share its name.

That shift matters more now than it did in 2012, because generative AI systems inherited the same underlying problem, just with higher stakes. A search engine that misidentifies your business shows the wrong snippet. An AI system that misidentifies your business writes a confident, fluent paragraph about the wrong company — your reviews, your pricing, your hours, quietly swapped for a competitor's, delivered as fact to someone who never sees a list of ten blue links to sanity-check it against. The underlying mechanism is the same one Singhal described in 2012. The consequences of getting it wrong are worse now because there's no results page left for a user to compare against.

What Actually Breaks Entity Resolution

Google is unusually direct about this in its own documentation. The official guidelines for representing your business on Google state that your name must "reflect your business's real-world name, as used consistently on your storefront, website, stationery, and as known to customers" — and for multi-location businesses, "all business locations within the same country must have the same name for all locations," with narrow exceptions only when a location genuinely, consistently trades under a different name in the real world. That's not a stylistic preference. It's Google telling you, in plain language, exactly what its matching systems are trying to verify.

In practice, the things that quietly break this are rarely dramatic. They're small, boring inconsistencies that nobody notices until something like the Park City merge happens:

• Name variants — "Al Futtaim Trading LLC" on your trade license, "Al Futtaim Group" on LinkedIn, "AF Trading" on your own website footer. Each looks like the same business to a human. A matching algorithm has to guess.
• Address formatting — "Office 402, Building 3, Dubai Internet City" versus "DIC, Bldg 3, Ste 402" versus a PO Box used interchangeably with a physical suite. Google's own address guidance is specific about this: put the real physical address in the first line and the suite or floor in the second, and never fold marketing language or URLs into an address field, because that alone can confuse or flag the listing.
• Phone number drift — an old landline still listed on a directory from three years ago, a mobile number on Instagram, a different number entirely on the website's contact form, none of them wrong exactly, just three different threads a system has to decide whether to tie together.
• Credentials and category mismatches — a business self-categorized under a broad label like "Real Estate Agency" when it's really a single agent operating under "Real Estate Agents," which is precisely the kind of category confusion a commenter on that Hacker News thread pointed to as part of what triggered the Park City merge in the first place.

None of these individually look dangerous. That's exactly the problem — each one is small enough to survive for years without anyone noticing, right up until an automated system decides two slightly-different profiles are close enough to be the same thing, or two genuinely different businesses look similar enough to swap.

The Real Story of a Business That Lost Its Identity to a Competitor

Worth reading the actual Hacker News discussion in full, because the disagreement in the comments is more useful than the incident itself. A commenter using the handle Arainach argued the fault sat mostly with the affected business: its listing had been keyword-stuffed with a competitor's name buried in the business title, and it had been filed under the wrong category — "the core reason it happened," Arainach wrote, was that "this place doesn't qualify to be on the map in the first place and it thus confuses the system." That's a genuinely fair technical point. A listing that's already bending the rules gives a matching algorithm more reasons to misfire.

Another commenter, pdonis, pushed back on the bigger question the merge raised — not just why it happened, but what it revealed about how much trust anyone should place in Google's business data at all. The concern wasn't abstract: reviews built up by one agent over years were now attached to a different one, with no notification and no easy way to contest it beforehand.

"How can Google merge a newly created Google Business account with one that has existed for years without checking with the owner?"

— pdonis, on Hacker News

The most useful comment in the thread, though, came from jdm2212, who identified as a former Google Maps employee and explained the scale problem underneath all of this. At one point, they said, roughly "a dozen people, literally," were responsible for maintaining hours, categories, and core data for every business Google Maps knew about — everywhere on Earth. The only way to handle that scale, jdm2212 explained, is automation that scrapes structured data off business websites, directories, and profiles and tries to reconcile it automatically. And automation that reconciles data at planetary scale is, by construction, going to occasionally decide two different businesses are the same one — or that one business is actually two.

That's not a Google-specific flaw, and it isn't limited to a single well-documented Park City incident either. A separate, earlier Hacker News thread on fake business listings, built around Wall Street Journal reporting on locksmith scams, found one legitimate Phoenix locksmith pulling a list of every locksmith registered in Arizona from the data broker Acxiom and counting 9,600 of them — when, in his estimate, something closer to a few hundred actually operate in the state. jdm2212 turned up again in that thread too, describing how Google's spam-detection systems ran automated sweeps roughly every six hours, and how scammers simply set up their own automated jobs to re-upload fake listings the moment each sweep cleared them out. Different story, same underlying truth: any system trying to resolve millions of "who is this, really" questions automatically is going to get some of them wrong, in both directions — merging what should stay separate, and failing to catch what should never have been listed at all.

This Stopped Being Just a Google Maps Problem

Everything above predates generative AI by years, and it would already be reason enough to take entity consistency seriously. But the systems answering questions about your business now include ChatGPT, Gemini, Perplexity, and Google's own AI Overviews, and none of them show a user ten results to compare — they show one confident paragraph. Search Engine Land's Benu Aggarwal, writing in a February 2026 piece on AI's effect on local search, put the mechanism plainly: "AI systems build memory through entity and context graphs. Brands with clean, connected location, service, and review data become default answers." The corollary is blunter and more worrying for anyone who hasn't checked: "Brands don't simply lose visibility. They get bypassed."

Ahrefs' now-well-known experiment building a fictional company called Xarumei showed a version of this from a different angle — Perplexity, in particular, confused the fake paperweight brand with the real smartphone maker Xiaomi in roughly 40% of baseline questions, before anyone had even planted misleading information about it. That's a model failing at the most basic level of entity resolution: is this the company I think it is? If a completely fictional brand with a deliberately unique name can get confused with an unrelated, unrelated-industry business, a real company with three slightly different name variants across its own web presence is giving these systems an easier way to get it wrong, not a harder one. You can read the full Ahrefs writeup if you want the details — it's genuinely worth the ten minutes, even outside the entity-consistency angle.

What the Data Actually Says About NAP Consistency

It's worth being honest about how NAP — name, address, phone — consistency ranks among everything else that affects local visibility, because the marketing language around it has drifted toward overstatement for years. Whitespark's 2026 Local Search Ranking Factors report, which surveys working local SEO practitioners rather than guessing, puts "HTML NAP Matching GBP NAP" at #15 among all local pack ranking factors, with a weighted score of 153. Citation consistency specifically — whether your details match across primary map platforms like Google Maps, Bing Maps, and Apple Maps — ranks lower, at #28, and consistency across secondary sites like Yelp or data aggregators like Localeze ranks lower still, around #63 and #85 respectively. Citation signals overall make up something like 5 to 6% of total ranking weight, and the report's author, Darren Shaw, notes that figure has actually drifted down slightly from prior years as citations lost "about half a percentage point."

Read that carefully and the honest conclusion isn't "NAP consistency doesn't matter." It's that NAP consistency is a foundational, table-stakes signal rather than a growth lever — it's not going to be the thing that pushes you from position six to position one on its own, but getting it wrong is exactly the kind of thing that causes the Park City-style failure: not a slow ranking decline, but an actual mismatch event where a system attaches the wrong identity to your business entirely. Foundational signals are the ones you fix once and stop worrying about, which is precisely why they're worth doing properly the first time rather than as an afterthought.

What sameAs Actually Does, and What It Doesn't

A lot of technical SEO advice treats the schema.org sameAs property as some kind of magic entity-confirmation switch. It isn't, and Google's own structured data documentation for Organization markup is fairly restrained about what it actually claims: sameAs is simply "the URL of a page on another website with additional information about your organization," and you can list multiple of them — your LinkedIn page, your verified social profiles, a directory listing you actually control. What it does is give an automated system a set of pages it can check against each other to see if they agree. It doesn't fix a contradiction; it just makes the contradiction easier to find. If your sameAs links point to a LinkedIn page with a different registered name than your website's Organization schema, you've handed the mismatch to the system on a plate instead of hiding it.

That's the part most technical audits skip. Adding structured data without first reconciling what it actually claims doesn't create consistency — it just makes an existing inconsistency machine-readable.

A Practical Way to Check Your Own Entity Consistency

You don't need special tools to start this. Open your own website's footer, your Google Business Profile, your LinkedIn company page, and whatever directory or licensing register applies in your industry — a DED trade license listing, a health authority registry, a bar association directory — side by side in separate tabs. Read the legal business name character by character across all four. Then do the same for the address, down to whether "Office" is spelled out or abbreviated, whether the building number comes before or after the street name, whether it's the same suite number everywhere. Then the phone number, checking whether it's the same format (with or without the country code) everywhere it appears. Small mismatches you'd never notice reading each one individually jump out fast once they're side by side.

If that process turns up more inconsistencies than you expected — which, for most businesses that have existed for more than a couple of years and been through a rebrand, an office move, or a new hire updating one profile and not another, it usually does — that's exactly the audit our own Entity Optimization service is built around: checking your name, address, description, and credentials word-for-word across your site, Google Business Profile, LinkedIn, and the directories that matter in your industry, then fixing what doesn't match before it becomes a Park City-style problem instead of a quiet background risk. If you want a free first look at how AI systems are already describing your business before committing to anything, the AEO Score tool gives you that starting point in a few minutes.

The Bilingual Layer Most Audits Skip Entirely

For a business operating in the UAE, there's a version of this problem that's easy to miss entirely if you only check the English side. Your trade license carries a specific legal Arabic name, which may or may not be a direct transliteration of your English brand name — plenty of businesses end up with an Arabic legal name that reads noticeably differently from what's on their English signage, simply because the two were registered at different points by different people who weren't thinking about consistency at the time. If your Arabic Google Business Profile listing, your Arabic website, and your actual DED license don't agree on that name character-for-character, you've built the exact same kind of gap that caused the Park City merge — except it's invisible to anyone only checking the English side of the business, which describes most audits done by agencies that don't operate natively in Arabic.

This isn't a hypothetical add-on to the entity consistency problem — it's the same problem, just running in a second language most tools and most agencies never actually check.

Where This Actually Leaves You

None of this requires panic. It requires roughly twenty minutes of side-by-side comparison across the handful of places your business's identity actually lives, and then a resolve to fix the small stuff before it becomes the kind of thing that makes it onto Hacker News with 590 points. The Park City agent whose reviews got reassigned to a competitor didn't do anything unusually careless — a keyword-stuffed name and a slightly wrong category were enough, run through a system built to reconcile identity at a scale no small team can manually check. Every business has some version of that same small, boring inconsistency sitting somewhere in its own digital footprint right now. The only real question is whether you find it before an automated system does, or after.