An outdated product claim can persist in AI answers long after the underlying information has changed. A retired integration, for instance, may still be presented as available because an old page remains online. The challenge is understanding why it gets it wrong and where the misinformation originates. This builds on claim-level sentiment coding, moving from measuring how AI portrays your brand to identifying and correcting inaccurate claims. This guide covers how to maintain a reliable record of brand facts, trace errors to their sources, prioritise corrections, and understand why answer engines produce outdated or incorrect information.
A parrot repeats what it has heard
Answer engines get a claim about your brand from one of two places. One is a page the engine retrieves while answering, and the answer repeats it. The other is the model's own memory from training, which can be out of date or can fill a gap with something plausible. A wrong claim that comes from a page is an echo. A wrong claim that comes from neither is generated.
The difference matters because the fixes are different. You can correct a page. You cannot edit a model's memory. If you treat every wrong answer as a model fault, you will wait for someone else to fix it. If you treat every wrong answer as a page fault, you will go looking for a source that does not exist. The method below sorts each claim before anyone acts on it.
What research says about why answers go wrong
None of these studies is about B2B brands. They test how language models handle facts about public entities, and they are the closest independent evidence we found.
A paper from the University of Washington, the Allen Institute for AI and Johns Hopkins, presented at ACL 2023, tested about 14,000 questions about entities with different levels of popularity, measured by Wikipedia page views. Accuracy rose with popularity, and the models did worst on the long tail: on the 4,000 least popular questions, the models it tested scored between 15 and 19 percent. Adding retrieval helped on rare entities, and a small retrieval-equipped model beat a much larger one on the least popular questions. For popular entities, retrieval sometimes hurt: in about 10 percent of questions it turned a correct answer into a wrong one. The authors note that the datasets are synthetic, the models are from the GPT-3 era and page views are an imperfect measure of popularity (Mallen et al., ACL 2023).
An Imperial College London preprint tested what happens when a fact changes after a model's training cutoff. It built 225 changed facts from sources such as Wikipedia, SEC filings and FDA labels and tested seven model configurations with search. Under one provider's own web search, the model answered 53.6 percent of the time from search snippets alone, without opening the page. Across the seven configurations, answers built only on snippets were stale 6.4 percent of the time, against 1.3 percent when the answer cited a page the model had opened. The paper is a preprint based on a master's dissertation, tests one proprietary model at its lightest tier, and its domains are unbalanced, with sports driving the worst failures (Walters, Chen and Toni, arXiv 2610.21731).
A benchmark from AWS AI Labs and Purdue, called evolveQA, tested 12 models on facts that had changed over time, using time-stamped update notes from two cloud providers and the World Health Organization. In open-ended questions, the share of outdated answers ranged from about 23 to 54 percent depending on the model. When a model gave an outdated open-ended answer, it still picked the current answer in a multiple-choice version of the same question between 32 and 45 percent of the time, which the authors read as current knowledge that is stored but poorly retrieved. The study covers English only, the authors work at a cloud provider and it is a preprint (Nakshatri et al., arXiv 2510.19172).
A Stanford-led study, published in the Journal of Empirical Legal Studies in 2025, tested two leading retrieval-based legal research tools. It found that each hallucinated more than 17 percent of the time, lower than GPT-4 but far from zero. The domain is law, and the tools are closed, so the authors could only test them from outside (Magesh et al., 2025).
Our reading, not the studies' conclusions: rare entities are where models are weakest, a smaller B2B brand is more likely to sit nearer that tail than a household name, retrieval does not remove errors and a changed fact can linger. None of the studies tested brands.
Start with a master record of your facts
You cannot call a claim wrong until you can say what is right. Build one table of the facts an answer might state about you, each with an approved value, the own page that states it, an owner and a date you last checked it. Facts that change fastest go stale first, so give each a review interval.
| Fact type | Typical owner | How fast it changes | Suggested review |
|---|---|---|---|
| Price and plan names | Product marketing | Several times a year | Monthly |
| Integrations and features | Product marketing | With each release or retirement | Quarterly |
| Security and compliance status | Legal or security | Annual, with surprises | Quarterly |
| Product names | Product marketing | Rarely, but old names linger | Quarterly |
| Locations, leaders, founding year | Web or comms | Slowly | Twice a year |
| Customer counts and claims | Comms | With each announcement | Quarterly |
| Support hours and terms | Support or sales | Occasionally | Quarterly |
The review column is our suggestion. In the worksheet's invented example, four of 12 facts are overdue for review as of the as-of date, and they are the price, integration, trial and contract facts, the ones most likely to have moved. The PR and comms post covers a fact sheet in more detail, and the sentiment post uses the same record to label claims as matching or differing.
Trace each wrong claim to its cause
Take every claim that differs from the record and ask four questions in order. Figure 1 shows the path.
- Did the answer cite a page next to the claim? Save the page address with the answer.
- If it did, open the page and read it. Does it state the claim? If yes, the cause is Echo. If no, it is Misread: the answer attached a source that does not support it.
- If nothing was cited, search for the claim in your own old pages, documents, directories and review sites. If you find a page that states it, the cause is still Echo, since the engine may have retrieved that page without showing it.
- If you find no such page, ask whether the claim is true of another company or product with a similar name. If it is, the cause is Wrong entity. If it is not, the cause is No source found, and the answer generated it.
Step 3 is a limit on the method. You can only fail to find a source. You cannot prove that none exists, and a claim can also come from a page you cannot search, so treat No source found as "none that we could find."
| Cause | What it looks like | Where to fix | What you cannot control |
|---|---|---|---|
| Echo | A retired price, an old product name, a dropped integration, repeated from a page | The page that states it: update, redirect or retire it | Third-party pages you do not own, and copies elsewhere |
| Misread | A cited page is about something else or states the fact in a way that is easy to misread | The cited page: state the true fact in plain text near the top | The engine's choice of what to cite |
| Wrong entity | The facts of a similarly named company or product, attributed to you | Your own identity pages: full name, category, location, what you are not | Other companies' pages |
| No source found | A feature, certification or incident that no page states | A new page that states the true fact, then keep tracking | The model's memory |
Whether the cause was an echo also tells you where to look next. If many echoes point at one source type, such as old directory listings or documents, the problem is a source habit rather than a set of separate errors. The worksheet counts findings by where the source lives for this reason.
Repeat the prompt before you rank the error
One run that states a wrong claim does not tell you whether the claim recurs. Answers vary from run to run, so repeat the same prompt on the same engine several times and log how many runs showed the error. Keep the wording fixed, as the prompt design post describes, or you are comparing different questions.
Figure 2 shows why a short check can mislead. It is a model, not a measurement, and it assumes every run is independent, which is a best case.
Figure 2. A model, not a measurement. It assumes each run is independent and that the error appears in the same share of runs every time.
An error that appears in 20 percent of runs has a 67 percent chance of showing up in five runs, so one check in three would miss it. It takes about 10 runs to reach roughly a 90 percent chance. An error that appears in half of all runs shows up in five runs 97 percent of the time. That gap is why the worksheet will not call an error recurring, occasional or gone until you have logged a minimum number of runs, and why a claim that did not appear in a short recheck is not proof that a fix worked.
Rank by harm, reach and recurrence
You will find more errors than you can fix at once. A simple score gives a sorting order. Rate harm from 1 to 3: 1 for a minor detail, 2 for something that changes a buying decision such as price or an integration, and 3 for legal, safety, compliance or reputational exposure. Rate reach from 1 to 3: 1 for one prompt, 2 for several prompts, and 3 for prompts across buying stages or high-intent prompts. Multiply harm, reach and the share of runs that showed the error. The score runs from 0 to 9, and the cut-offs are yours to set.
In the invented example, a claim that support is available around the clock has harm 2, reach 2 and appeared in 5 of 6 runs, so its score is 3.3 and it sits in the High tier. A claim that Brand A offers a compliance dashboard it does not have appeared in 1 of 8 runs. Its score is 0.75, which would be Low, but harm is 3, so the worksheet rates anything with harm 3 that has appeared at least once as at least Medium. A score is a sorting aid. Anything involving legal, safety, compliance or privacy exposure goes to the right owner whatever its number, and the regulated industries post covers who that owner usually is.
| Cause | Findings | Recurring | Open or fix requested | High tier |
|---|---|---|---|---|
| Echo | 12 | 11 | 3 | 4 |
| Misread | 5 | 5 | 3 | 2 |
| Wrong entity | 4 | 3 | 2 | 0 |
| No source found | 7 | 0 | 4 | 0 |
| Not yet traced | 2 | 1 | 2 | 0 |
| All causes | 30 | 20 | 14 | 6 |
Invented example. Recurring means the error appeared in at least 30 percent of runs, with at least five runs logged.
Most echoes recur and none of the no-source claims reached the 30 percent threshold. That pattern is built into the example rows. It is not a finding. If your own log looks like it, it suggests that fixing pages will take care of the repeatable errors and that the generated ones will need patient tracking. If your log looks different, believe the log.
Fix the cause, then recheck
Match the action to the cause. These are our recommendations, and none of them has a measured effect on later answers. For an echo on your own site, correct the page, then redirect or remove the old version and check old PDFs and downloads, which are easy to forget. Keep one current page per fact. For an echo on someone else's page, ask the owner for a correction through their process and keep a record of the request.
For a misread, look at what the cited page says and how. If the true value is in an image, a table or a PDF, repeat it as plain text. If one page carries two conflicting numbers, remove the conflict. Our reading of the Imperial College result is that if answers lean on snippets, the title, description and opening lines of a page carry weight, so state the current value there.
For a wrong entity, state your full name, product name, category and location on your own identity pages, and say plainly what you are not, for example that you are not the similarly named firm. Keep third-party profiles consistent with those facts.
For a claim with no source found, there is no page to correct. Publish a clear page that states the true fact, such as a "what we integrate with and what we do not" page, keep tracking the prompt, and escalate serious errors to the owner named in your log. Some products offer a feedback or report option inside the answer. We found no independent evidence on how those reports are handled, so treat them as a supplement.
After a fix, wait, then recheck with the same prompt on the same engine and enough runs to judge, as in the previous section. Record the date and the result. If the claim comes back, reopen the finding. A claim that does not appear in a recheck may simply not have appeared in those runs.
Log every finding in one worksheet
The worksheet has a settings tab, a master facts tab, a findings log and a summary. Grey rows are invented examples for an invented brand, so replace them before you read any output. Do not enter customer or personal information anywhere in it.
- On the Settings tab, set the minimum runs before judging recurrence, the recurrence threshold, the tier cut-offs and the recheck interval. List your tracked prompts.
- On the Master facts tab, enter each fact with its approved value, the own page that states it, an owner and a review date.
- On the Findings tab, log each wrong claim with its prompt, engine, the fact it contradicts, error type, traced cause, where the source lives, harm, reach and the runs you checked.
- Read the recurrence share, its 95 percent range and the tier that the sheet calculates. Assign a status and an owner, and enter the date you made the fix.
- On the Summary tab, read findings by cause, error type, source location and owner, the top ten open findings and the checks for overdue facts and rechecks.
Frequently asked questions
Is a wrong answer about my company a hallucination?
Sometimes. A claim that no page states is generated, which fits the usual meaning. But the research above shows that a wrong answer can also repeat a stale page or fail to read the right one. Use the cause, not the label, to decide what to fix.
Can we make an engine stop saying something wrong?
Not directly. You can fix the pages that state it, make the true fact easy to read and keep tracking. We found no study showing that any of these steps changes later answers, so record each fix and recheck it.
How often should we check?
Match the interval to how fast the fact changes. Prices and trial terms might be checked monthly, security status quarterly and founding year rarely. Recheck after each fix and after each product change.
What if the wrong claim is on a site we do not control?
Ask the owner for a correction and keep a record. Meanwhile, make sure your own pages state the true fact clearly. An answer may cite either source, and you can only change your own.
Who owns this work?
The master record needs one owner per fact, and findings need an owner by cause: usually the web team for pages, product marketing for features and prices, comms for entity and leadership facts and legal for compliance claims. The worksheet has an owner column for this reason.
Follow one wrong claim back to its source this week
Pick one prompt that a buyer would ask about you, such as your pricing or one integration, and save five runs of it. Compare each answer with your record. If any claim differs, open the page the answer cited, or search your old pages, directories and documents for the claim, and decide which of the four causes it is. Write down the page address, the owner and the fix. Then recheck with the same prompt in a few weeks. Do not put customer or personal information in the prompt or the saved answers.
If you want a first reading on one prompt before you build the master record, the AI Search Visibility Checker gives you one that can become your first finding. If you want a recheck to use exactly the wording you logged, AI Search Intelligence tracks individual prompts.
