The real AI search problem for multi-location brands: stale data, not hallucinations

A believable answer is the dangerous one

An invented business gives itself away. The address leads nowhere, the phone number does not exist, and the person who asked soon finds out that the answer was wrong.

A real location with outdated information gives nothing away. A customer asks whether the Graz branch is open on Saturday. The assistant names the right branch, the right street and a plausible set of hours. The hours changed in the spring. Nothing in the answer looks wrong, so the customer has no reason to check until they are standing at a closed door.

For local discovery, that second failure is the one that costs multi-location brands money. In the networks we work with it takes a recognizable set of forms:

• standard opening hours that are simply wrong;
• special hours for a holiday or a renovation that were never published, or are still shown after they expired;
• a permanently closed location that is still recommended;
• an address from before a relocation;
• a previous phone number, often one that now rings at a central line;
• incomplete service information, so a location seems not to offer what it does;
• a category that no longer describes what the location is;
• a brand website that still carries last year's details;
• sources that disagree, and an answer built on the wrong one.

None of these looks like an error to the person reading the answer. An invented business is visibly wrong once discovered. A real location with plausible but outdated details looks credible, and that is what makes it dangerous.

What the 2026 research shows

By September and October 2026, local AI accuracy had become one of the most actively discussed topics in local search. Studies, industry datasets and practitioner debate published through the year kept returning to the same questions: how accurately assistants describe local businesses, how often they repeat stale information, which sources they select, how far API outputs differ from what consumers see, and how much weight a business's own first-party data carries.

The studies differ in method, market and motive, and their numbers should not be added together. Read side by side, they describe one pattern.

Fabrication is rare. Staleness is not.

The most carefully designed of them is a research paper published on arXiv in August 2026 that audited AI recommendations of restaurants, cafés and bars against a complete market census^[1]. The author first enumerated every operating food-service venue in two areas of Bali, 4,776 in total, from Google's place data. ChatGPT, Claude, Gemini and Perplexity were then given 96 persona-based questions over seven days: 2,208 runs and 12,439 valid venue mentions.

Because the denominator is the whole market, every mention can be checked against what actually exists. Outright invention was close to absent: one name, mentioned 10 times, survived scrutiny as likely invented, 0.08% of valid mentions. Permanently closed venues appeared in 93 mentions, spread across 14 establishments that had verifiably shut.

For local discovery, the evidence suggests that stale information about real businesses can be a much more practical failure mode than completely fabricated locations. The assistants almost never made places up. They were recommending places that no longer existed.

Two details matter for multi-location brands. Of the mentions that could not be matched to the census at first, 38.4% turned out to be name variants of registered venues: rebrands, nicknames and transliterations. Identity drift is common even in a market of independent cafés. And the author's explanation for the closures matches the mechanism we see in operation: retrieval reports its sources faithfully, and the sources are stale. Reviews, listicles and blog posts about a closed café outlive the café.

It is one market and one sector, the assistants were queried through their APIs rather than their consumer apps, and the paper is a preprint funded by a commercial AI-visibility company, as it discloses. Why closures persist is the author's interpretation, not a measurement. What makes the pattern credible is the design: a complete census as the denominator.

The errors sit in ordinary fields

The same kind of error shows up in retail. A July 2026 industry test of UK high-street retailers put more than 72,000 questions to ChatGPT, Gemini and Perplexity and graded each answer against the retailer's verified information^[2]. Roughly two in three retailers had at least one false fact returned about them, and about one answer in 16 was false. The most common false answer placed a store in the wrong postcode, even when the prompt named the town or city.

One large-scale industry index of multi-location brands, published in January 2026, put the contact-detail accuracy of non-Google assistants at only about 68%, with the assistant grounded in Google Maps markedly more accurate and consistent^[3]. The index does not publish how that accuracy was scored, so we treat the figure as indicative. The figure measures business contact details only and is not part of the benchmark basis for our own client analysis below.

Each of these measures something different: a share of businesses, a share of answers, a share of contact details. What they share is the kind of error. Postcodes, phone numbers, opening status. These are exactly the attributes a location operation exists to keep current.

What the API returns is not what the customer sees

Research comparing API and consumer-interface outputs adds a measurement problem to the accuracy problem^[4]. A 2026 industry study ran the same 1,000 prompts through five AI products using two methods, the consumer interface and the API, and collected 13,779 answers across 14 model-and-method combinations on a single day in August. The brands named in the two versions of an answer overlapped by only 15.5% to 31.6%, depending on how names were normalized. Page-level overlap of the cited sources ran from roughly 5% to 20% across the products where it could be measured. Through ChatGPT's consumer interface an answer cited 12.1 sources on average; through its API, 3.1.

This does not make the API wrong. A consumer AI product is more than the model behind its API. It adds its own retrieval layer, search behavior, source set, system instructions and product logic, and each of them changes the answer. An AI-visibility tool built on API calls can therefore measure something different from what a customer is actually shown.

How stale data gets into answers

It starts with a change. Opening hours are adjusted for winter. A branch closes for two weeks of renovation. A store moves 300 meters down the street. A clinic group takes over a practice and renames it. A bank routes branch calls to a regional service center. Each of these is routine for the business and invisible to every system that was not told.

The change then has to travel. A large network does not have one copy of a location. It has the master record (sometimes several), the Google Business Profile, Apple Business Connect, Bing Places, the data partners that feed navigation systems, the brand's own website and Store Locator, and a long tail of directories, review sites and articles the brand does not control. The copies the brand controls can be updated within hours. The rest catch up at their own pace, if they catch up at all.

Meanwhile the platforms change data themselves. Google can update a profile from user reports and licensed data, and people on Maps can suggest edits to hours, addresses and phone numbers. Some of those changes are right; some overwrite correct data. We describe the six ways live data drifts from its source elsewhere, and the closures, relocations and rebrands where drift most often starts.

An assistant assembling an answer from these sources inherits their disagreements and has no reliable way to tell which one is current. Often, the old version of a location is the better-documented one.

What well-structured location networks have in common

The external research raised a more useful question for us: what happens when the first-party location layer is actually well structured?

MapsExperts supports more than 13,400 locations across its client base, through the Managed Service, hybrid models and direct use of our Platform, including a retail network of more than 600 locations where we operate the complete Google Business Profile program. That gives us a view of very different setups, from networks that exist only as third-party listings to networks that run their own location infrastructure.

In our internal client analysis, AI location-data accuracy was 3.2× as high in environments with a structured Store Locator, dedicated Local Landing Pages and maintained first-party location data as in the comparable industry accuracy benchmarks reviewed for this analysis.

We read the result as an observation about architecture. In those environments the brand's own site states the same current facts as its profiles, location by location, so a system that looks beyond one platform finds confirmation instead of contradiction. A companion article describes that architecture in detail.

What we see in operation

The weaker setups fail in ways that rarely show up on a dashboard:

• A location can be published everywhere and still be wrong. Distribution confirms that data arrived, not that it is true.
• Standard hours can be correct while special hours are stale, which is exactly what customers ask about in holiday weeks.
• A relocation can leave two identities in circulation, with the old address in some systems and the new one in others.
• A brand may update its listings feed before its own website and then contradict itself.
• A location can remain discoverable after it closes when downstream systems have not reconciled the change.
• An interactive Store Locator can work well for a person and still expose almost nothing a crawler can read.

The cause usually sits upstream of Google or any assistant. Hours changed at the branch but not in the master record. A closure was entered in the property system and never released to the channels. The location pages are maintained by a different team in a different CMS. A location can be technically published and still be operationally wrong.

Customers often find the error first

One of our published client examples shows how this surfaces. A healthcare and clinic group came to us with profiles that contained outdated information and inconsistent categories. Among the issues the group had underestimated were its weekend opening hours, and review feedback helped reveal them.

We corrected the profile foundations, fed the recurring issues back to the client's team and managed the review responses. After customers' concerns were resolved, the group's average Google rating rose by 0.4 stars. It is the stale-data problem in its most ordinary form: real locations, wrong hours. And because the same Maps data can now ground Gemini-based answers, an error like this no longer stays on one platform.

What this means for multi-location brands

Customers do not ask assistants about a brand in the abstract. They ask about a location, usually with a condition attached:

• “Which branch near me is open tonight?”
• “Is the Linz store open on Sunday?”
• “Where is the closest location with parking?”
• “Which of your stores offers same-day repairs?”

Every one of those answers depends on location-level facts, including the exceptions, being current in whatever the assistant retrieves. At five locations an occasional inconsistency is an irritation that someone notices and fixes. At 100, 500, 1,000 or 10,000 locations it is an infrastructure problem.

At that scale, accuracy becomes an operating discipline with owners, a source of truth and a feedback loop. In practice it comes down to a handful of decisions:

• Treat one record per location as the source of truth, and timestamp every change to it, special hours and temporary closures included.
• Publish from that record to every channel you control, your own website included, so there is no second copy to drift.
• Monitor what is live against the record, field by field, and decide every difference: accept, correct or escalate. Google's own updates and suggested edits make this necessary even when your internal process is clean.
• Prioritize by customer harm: operating status and closures first, then regular and special hours, address and map position, phone, then categories and services.
• Measure AI answers where customers see them, by intent and repeatedly, and use API-based monitoring for what it is good at. Our Location Intelligence work treats AI visibility this way.

None of this guarantees how a given assistant will describe a given location; no one can promise that. It does decide whether the current truth is available, consistent and easy to find when an assistant goes looking.

From listings to an owned location data layer

A map platform may know that a place exists. A well-built local page helps machines understand what is true about that specific place.

That distinction is the subject of a companion article: why Store Locators and Local Landing Pages are becoming part of a brand's location-data infrastructure, and what they have to contain to do that job.