TL;DR: Ask three assistants the same question about your brand and you can get three materially different answers, including different facts. The largest study of this in local search found recommendation rates varying by roughly nine times between assistants and profile accuracy varying from around 68 percent to 100 percent. The difference comes from what each system grounds its answers in, which means a weak result on one and a strong result on another is a diagnosis rather than noise.
Key Takeaways
The gap is large and measured. Across the same set of brands, one assistant recommended 1.2 percent of locations and another 11 percent.
Grounding explains most of it. An assistant anchored in a structured source behaves differently from one assembling from open web retrieval.
Accuracy differs too. The same study found profile information roughly 68 percent accurate on two assistants and 100 percent on a third.
The pattern is diagnostic. Strong on the Google-grounded surface and weak elsewhere points at your wider web presence. The reverse points at your structured data.
Never blend them. A combined figure hides the only information that tells you what to fix.
What you control is mostly the same. Crawler access, extractable pages and corroboration serve every engine. The weighting differs, not the work.
Anchor targets assume your CMS generates slug IDs from heading text. Confirm on staging and adjust the hrefs if your platform slugifies differently.
The evidence
The best available measurement of this comes from local search, where one study ran the same brands across three assistants and compared results.
What it found
SOCi's 2026 Local Visibility Index analysed roughly 350,000 locations across 2,751 multi-location brands.
Measure | ChatGPT | Perplexity | Gemini |
|---|---|---|---|
Share of locations recommended | 1.2% | 7.4% | 11% |
Profile information accuracy | ~68% | ~68% | 100% |
Same brands, same category questions, same period. A nine-fold difference in recommendation rate and a material difference in whether the facts given were correct.
Why this matters beyond local
The study is about local business recommendations, and the mechanism it reveals is not local-specific. One assistant was grounded in a structured, authoritative source and was accurate and comparatively generous; two were assembling from wider retrieval and were more selective and less accurate.
That difference in grounding exists outside local search too, which is why the diagnostic patterns in this article generalise even though the figures do not.
The honest scope
These numbers describe local business recommendations for multi-location brands in early 2026. Do not quote them as general citation rates, and do not expect your own category to produce the same ratios.
What generalises is the finding that the engines differ substantially and systematically, which is the thing most measurement programmes assume away.
What you should expect in your own data
Different rates per assistant, and sometimes different facts. If you are measuring across three assistants and seeing near-identical results, check your method before concluding the engines agree.
Why nobody reports this
Because a blended number is easier to put on a slide, and because most tools present one figure by default. The information is usually collected and then averaged away.
Why they differ
Four things vary between assistants, and grounding is the one that matters most.
1. What they ground in
The biggest factor. An assistant that anchors a class of answers in a structured, authoritative dataset behaves very differently from one assembling from open web retrieval.
Gemini's local answers are anchored in Google's own local data, which explains both the higher recommendation rate and the perfect accuracy in that study: if your Google Business Profile is right, it is right. ChatGPT and Perplexity assemble from wider sources, which is why they were more selective and less accurate.
The same logic applies wherever one assistant has privileged access to a structured source and another does not.
2. Whether they search at all
Assistants decide per query whether to retrieve or answer from what the model already encodes. Those decisions differ between products and between versions of the same product.
An answer composed without retrieval reflects whatever the model absorbed in training, which no amount of publishing this quarter changes.
3. What index they retrieve from
Different crawlers, different coverage, different refresh rates. A page crawled by one and not another is available to one and not another, which is why the crawler access check has to cover every agent separately.
4. How they compose
How many sources they pull, how many brands they name, whether they cite inline, how cautious they are about recommending. These are product decisions and they vary.
A system that names three brands and one that names eight produce different appearance rates on identical retrieval.
The practical summary
Two of these you can influence and two you cannot. You can influence what is in each index, through crawler access and publishing. You cannot influence whether a system searches or how it composes.
That split is worth holding on to, because it tells you which differences are worth acting on.
Documented versus inferred
Worth being precise about, because a lot of writing on this topic states guesses as mechanism.
What providers document
Documented | Where |
|---|---|
Which crawlers exist and what each does | Provider bot documentation |
That training and retrieval crawlers are separate | OpenAI and Anthropic documentation |
That Google-Extended governs training use, not AI Overviews appearance | Google Search Central |
That appearing in Google's AI features requires ordinary indexing and snippet eligibility | Google Search Central |
That no new machine-readable files are required | Google Search Central |
What is observable without documentation
Observable | How |
|---|---|
Which sources an assistant cites | Read the answer |
Whether it searched | Usually visible in the interface |
How many brands it names | Count them |
Whether the facts are right | Check them |
How much answers vary between runs | Run them repeatedly |
What is inferred
The grounding explanations in the previous section are inference from observed behaviour plus what providers say about their products. They are reasonable and they are not published architecture.
Nobody outside these companies knows the retrieval weighting, the index composition or the decision rules for whether to search.
Why the distinction matters to you
Because advice built on inferred mechanism should be held loosely, and advice built on invented mechanism should be discarded. The second category is large in this field.
If someone tells you exactly how an assistant weights sources, they are describing something nobody outside that company knows.
The safe way to use this
Treat the per-engine patterns as empirical: this is what we observe, this is what it correlates with, this is what we will try. Not: this is how the system works, therefore do this.
The first survives being wrong about the mechanism. The second does not.
Diagnosing from the pattern
The practical payoff. Your per-engine pattern tells you which problem you have, and a blended number tells you nothing.
Pattern | Likely cause | Where to work |
|---|---|---|
Strong on the Google-grounded surface, weak elsewhere | Your structured data is fine; your wider web presence is thin | Corroboration: reviews, publications, communities |
Weak on Google-grounded, stronger elsewhere | Your Business Profile or structured data is wrong or incomplete | Your own data, which is fast to fix |
Weak everywhere | Access, or you are not a recognised candidate at all | Crawler logs first, then entity work |
Cited on one, named without citation on another | Different index coverage of your pages | Check crawler access per agent |
Facts right on one, wrong on others | The wrong facts are coming from third-party sources | Find and correct the source |
Strong everywhere | Working | Maintain |
The second row is the quick win
If one assistant has you right and others have you wrong, the correct information exists and some systems are not reading it. That usually means either an access problem for specific crawlers or third-party sources contradicting you.
Both are findable. Check crawler hits by user agent, then look at what the inaccurate assistants cite.
The first row is the common one
Many brands are tidy in their own structured data and thin in independent coverage. That shows up as competence on the grounded surface and absence elsewhere.
It is also the slower fix, since corroboration is earned over quarters.
How to run the diagnosis
Take fifteen questions. Run each three times on each assistant separately. Record appearance, citation and factual accuracy per assistant.
Then read across the rows rather than averaging down the columns. The comparison between engines is the finding.
What changes this pattern
Mostly your own work, slowly. But providers change grounding and retrieval without announcement, so a pattern that shifts across all brands at once is a system change rather than something you did.
Recording competitors alongside yourself is what lets you tell those apart.
What to do differently
Less than vendors suggest. The weighting differs; the work mostly does not.
If you are weak on | Emphasise |
|---|---|
The Google-grounded surface | Your Google Business Profile, structured data, and ordinary Google indexing and snippet eligibility |
Open-retrieval assistants | Independent coverage: review platforms, trade publications, community discussion |
Any of them, with facts wrong | Finding and correcting the third-party sources carrying the error |
All of them | Crawler access and entity recognition, in that order |
The Google side specifically
Google documents that appearing in its AI features requires ordinary indexing and snippet eligibility rather than anything new. So the work is your existing technical SEO plus accurate structured data, and for local, your Business Profile.
That is the most directly controllable surface available to you, which makes it the sensible place to start if you are weak there.
The open-retrieval side
Harder and slower, because it depends on what other people publish about you. Reviews, trade coverage, comparison content and community discussion are the inputs.
This is the corroboration work covered elsewhere in the cluster. The per-engine data just tells you whether it is your binding constraint.
What not to do per engine
Tactic | Problem |
|---|---|
Different site versions for different crawlers | Cloaking. Serve everyone the same thing |
Engine-specific metadata files | No provider documents reading them |
Content written to game one assistant's phrasing | Treated as spam behaviour by search platforms |
Dropping an engine because your rate is low there | That is the diagnosis, not a reason to stop looking |
The proportionality point
If one engine drives most of your measurable referrals, weight your attention accordingly, while continuing to measure the others.
But do not build separate programmes. One set of crawlable, extractable, well-corroborated pages serves all of them, and the differences in weighting do not justify parallel workstreams.
What is the same everywhere
The reassuring half, and the reason this does not fragment into separate programmes.
Constant | Why it holds across engines |
|---|---|
Crawlers must be able to reach your pages | Every system needs something to retrieve |
Content must be in the server response | A page assembled in the browser is not reliably parsed |
A clean answer must be extractable | They all select passages |
Specifics beat adjectives | Facts can be quoted; claims cannot |
Independent corroboration matters | All of them weight sources other than you |
Consistent entity facts help | Contradictions make any system hedge |
Answers vary between identical runs | Every one of them, which is why ranges are needed |
Why this matters more than the differences
If you do nothing engine-specific and do all of the above well, you will perform reasonably across all of them. If you do engine-specific work and neglect these, you will perform badly everywhere.
The differences tell you where your remaining headroom is. The constants are the work.
The practical reading
Start with the constants. Measure per engine to find out which one is holding you back once the constants are handled.
Most teams are not yet at the point where engine differences are the binding constraint, because the constants are not yet in place. The crawler access check usually settles that question in ten minutes.
The thing that is the same and gets forgotten
Variance. Every assistant gives different answers to identical questions, which means per-engine comparison needs multiple runs per engine before any difference is real.
A single run on each of three assistants produces three numbers that cannot be compared. Three runs each is the minimum and five is better.
The summary to hold
One set of pages, crawlable and extractable, corroborated by independent sources, with consistent facts. Measured separately per engine so you can see which part is weak.
That is the whole model, and the per-engine differences are a diagnostic layer on top of it rather than a different strategy.
Which engines to measure
Not all of them. Measurement cost scales with engines, and the marginal one adds little.
How to choose
Criterion | Note |
|---|---|
Which appear in your referral data | Your own analytics, segmented by assistant domain |
Which your customers mention at intake | The how-did-you-hear field |
Which dominate in your geography | Availability and adoption vary by market |
Which ground differently | Measuring two open-retrieval assistants adds less than measuring one of each type |
That last row is the useful one. Two assistants with similar grounding tend to produce correlated results, so a third of the same type adds cost without adding diagnosis.
A reasonable default
Three: one Google-grounded, one or two open-retrieval. That gives you the contrast the diagnostic table depends on without multiplying runs.
Adding a fourth is worth it only if it appears meaningfully in your referral data or your customers name it.
Re-check annually
Which assistants matter changes. Adoption shifts, products launch and close, and regional availability changes.
Review your referral data once a year and adjust the set. Note the change as a prompt set version event, because adding an engine changes your blended figures even if nothing else moved.
The cost reality
Each engine multiplies your run count. Fifteen prompts at five runs is 75 runs per engine, so three engines is 225 and five is 375.
That is the real argument for choosing deliberately rather than adding every assistant you have heard of.
What about assistants you cannot measure
Some surfaces are hard to query systematically, including assistants embedded in other products. Note the gap rather than pretending the set is complete.
An honest statement that you measure three of the surfaces that matter is better than an implied claim of full coverage.
Never blend them
The single most consequential reporting decision in this area.
What a blended figure destroys
Consider two companies both reporting 20 percent overall visibility.
Google-grounded | Open retrieval A | Open retrieval B | |
|---|---|---|---|
Company A | 48% | 6% | 6% |
Company B | 19% | 21% | 20% |
Identical headline. Completely different situations, completely different work. Company A has clean structured data and no independent presence. Company B is evenly mediocre and needs something else entirely.
The blended number is the only view in which these look the same.
Why it happens anyway
Because one number is easier to report, because tools default to it, and because leadership asks for a single figure.
The answer to that last one is to give them the leading engine's figure with its name attached, or the breakdown. Not an average across systems that work differently.
How to report instead
Three rows, one per engine, each with its range. A short line underneath saying which pattern you are in and what you are doing about it.
That is barely more space than one number and it carries the diagnosis rather than hiding it.
The exception
Trend direction. If all three are moving the same way over several quarters, saying so is reasonable, because the common movement is the point.
Even then, show the three lines. A single averaged line invites a reader to treat the engines as interchangeable, which is the misconception this page exists to correct.
The version note
If you add or remove an engine from your measurement, your blended figure changes for that reason alone. Mark it as a version event on the chart, the same as a prompt set change.
That is another argument for per-engine reporting: the per-engine lines stay comparable across such a change, and the blended one does not.
Six mistakes
1. Blending engines into one number. Two companies with identical headline figures can have opposite problems. The average is the only view in which they look the same.
2. Assuming a weak engine is broken measurement. A nine-fold difference between assistants was measured across hundreds of thousands of locations. Divergence is expected; identical results across engines should make you check your method.
3. Building separate programmes per engine. The constants, crawler access, extractable pages, corroboration, consistent facts, serve all of them. The differences tell you where your headroom is, not that you need parallel workstreams.
4. Serving different content to different crawlers. That is cloaking. Serve everyone the same pages.
5. Comparing engines on one run each. Answers vary between identical runs, so three numbers from three single runs cannot be compared. Three runs per engine is the minimum.
6. Stating mechanism you cannot know. Nobody outside these companies knows the retrieval weighting or index composition. Treat grounding explanations as inference and hold them loosely.
The pattern
Three are measurement errors and three are over-interpretation. Both come from wanting the engines to be either identical or fully explicable, and they are neither.
The one that matters most
Number one. It is the default in most tools and most reports, and it discards the only information in your data that tells you what to fix.
Splitting one number into three takes no additional measurement if you are already recording which engine each run came from. Most teams are, and then average it away before anyone sees it.
FAQs
Why do AI assistants give different answers about my brand?
Mainly because they ground answers in different sources. One anchored in a structured, authoritative dataset behaves differently from one assembling through open web retrieval. They also differ in whether they search, what they have indexed, and how many brands they name.
How big is the difference?
Large. Across roughly 350,000 locations, one study found recommendation rates of 1.2 percent, 7.4 percent and 11 percent across three assistants, with profile accuracy ranging from about 68 percent to 100 percent on the same brands.
Should we optimise differently for each one?
Mostly no. Crawler access, extractable pages, consistent facts and independent corroboration serve all of them. The per-engine pattern tells you which of those is your weak point, rather than requiring separate programmes.
What does it mean if we do well on one and badly on others?
Strong on the Google-grounded surface and weak elsewhere usually means your structured data is fine and your wider web presence is thin. The reverse usually means your own data or Business Profile is wrong, which is faster to fix.
Can I report one combined visibility number?
Better not to. Two companies with the same blended figure can have opposite problems and need opposite work. Report three rows with ranges instead; it is barely more space and it carries the diagnosis.
How many assistants should we measure?
Three is a reasonable default: one grounded in Google's data, one or two open-retrieval. Two assistants with similar grounding produce correlated results, so a third of the same type adds cost without adding diagnosis.
Do I need engine-specific metadata or files?
No. No provider documents reading such files, and Google's documentation states no new machine-readable files are needed for its AI features. Serving different content to different crawlers is cloaking.
How do I know if a difference is real or just variance?
Run each question at least three times per assistant, five for important ones. Answers vary between identical runs, so single runs produce numbers that cannot be compared across engines.
Splitting your number
If you already measure across assistants, your per-engine data exists and is probably being averaged before anyone sees it. Split it. Three rows with ranges instead of one figure, and read across rather than down.
The pattern you find tells you which problem you have, which is the thing a blended number is structurally incapable of showing.
The diagnosis in four lines
Strong on the Google-grounded surface, weak elsewhere. Your structured data is fine; your independent coverage is thin.
Weak on Google-grounded, stronger elsewhere. Your own data or Business Profile is wrong. Fast to fix.
Weak everywhere. Check crawler access first, then entity recognition.
Facts right on one, wrong on others. Find the third-party source carrying the error.
If the finding is independent coverage
That is the slow lever, and the content half of it is a steady production problem: comparison pages, capability pages, the questions you lose. Blazly SEO covers research, planning, drafting and direct publishing from about $39 a month.
The measurement and the diagnosis stay with you, and they are what tell you whether coverage is actually your constraint.
Summary
Assistants give materially different answers about the same brand, and the gap is large: one study across roughly 350,000 locations found recommendation rates of 1.2, 7.4 and 11 percent across three of them, with accuracy ranging from about 68 percent to 100 percent. The main cause is grounding, since a system anchored in a structured authoritative source behaves differently from one assembling through open retrieval. That makes your per-engine pattern a diagnosis: strong where the data is structured and weak elsewhere points at your independent coverage, and the reverse points at your own data. The work itself barely changes, because crawler access, extractable pages, consistent facts and corroboration serve every engine. What changes is knowing which of those is holding you back. So measure three assistants with contrasting grounding, run each question at least three times per engine, and never report a blended figure, because the average is the one view in which opposite problems look identical.