An engine answering from training data is describing the version of your company that existed at its cutoff. An engine answering from retrieval is describing whatever page it just read. Both are common and the fixes differ.
Cutoffs are published, so the staleness is measurable rather than mysterious. Anthropic lists a knowledge cutoff for every current Claude model, and the dates differ between models in the same family.
The same question, asked of the same brand, can return last year’s positioning or this morning’s pricing page. Knowing which one you are looking at decides whether the fix takes a week or a model generation.
What is a training cutoff, exactly?
The date past which the model has no absorbed knowledge. Anthropic publishes these openly on its models overview, and it distinguishes two of them: “Reliable knowledge cutoff indicates the date through which a model’s knowledge is most extensive and reliable. Training data cutoff is the broader date range of training data used.”
Two things follow. The first is that recency degrades before it disappears. Between the reliable cutoff and the training cutoff, the model has seen some material but knows it less well, which is where confidently half-right answers about your company come from.
The second is that the cutoff is not one date across the industry. Different models in the same family carry different cutoffs, so two engines can disagree about you purely because they stopped reading at different times.
How can you tell which mode answered you?
Read the answer rather than the score. Four tells separate them, and you usually only need one.
The infrastructure backs this split. OpenAI’s crawler documentation keeps the two entirely separate: “OAI-SearchBot is used to surface websites in search results in ChatGPT’s search features,” while GPTBot “is used to crawl content that may be used in training our generative AI foundation models.” Two crawlers, two pipelines, two different reasons your page might or might not be reachable.
Why do the two disagree about your company?
Because they are reading different things from different times. Retrieval reads your site as it is now. Training data holds a compressed impression of everything written about you before a date, most of it not by you.
That second point is the one people miss. A training-data answer is weighted toward third-party sources, because there are more of them and they repeat each other. So the model’s memory of you is closer to the market’s description of you than to your own, and it lags.
Retrieval describes your website. Training data describes your reputation, as of a date that has already passed.
Retrieval, meanwhile, is only as good as what it can reach. Google’s documentation on AI features sets the bar as a page that “must be indexed and eligible to be shown in Google Search with a snippet,” and Anthropic’s citations documentation describes returning “the exact passages that support each claim.” Both assume a fetchable page exists. If yours does not, retrieval falls back to memory and you get the stale answer by default.
What fixes a training-data answer?
Time and third-party corroboration, in that order, and neither is fast. You cannot edit a model’s memory. You can only change what the next one reads.
That makes the work indirect: get accurate, structured, widely-repeated facts into places that get crawled for training, and wait for a model generation. Wikidata is unusually efficient here because its licensing removes every barrier to reuse, which is the argument in should my company be on Wikidata.
It also makes the work unfalsifiable in the short term. Judging entity work on a two-week window declares failure on something that had no mechanism to appear yet, which is why the response window matters in how to baseline AI visibility.
What fixes a retrieval answer?
A page that answers the question, reachable by the search crawler, and clearer than the alternatives. This is ordinary work with an ordinary feedback loop, and it can show results in days.
Check reachability first and separately. A retrieval-mode failure is often not a content problem at all but an access problem, and the two look identical from the outside: in both cases the engine falls back to what it remembers.
Publish, get indexed, get fetched. Measurable inside a normal reporting cycle, and reversible if you get it wrong.
Depends on what gets crawled, what gets repeated, and when the next model is trained. Not schedulable.
What happens when the two modes contradict each other?
You get an answer that is internally inconsistent, and it is more common than a cleanly wrong one. An engine can cite your current pricing page and then describe a plan structure you retired, because it fetched one fact and recalled another in the same response.
Treat that as a retrieval signal rather than a memory problem. The fetch succeeded, so the page is reachable; the model simply preferred its own recollection for the part your page did not state plainly. The fix is to state the contradicted fact explicitly on the page that gets fetched, in a sentence rather than in a table or a graphic.
The pattern also tells you which pages are load-bearing. Whatever got cited is the page the engine trusts for your category, and it is the one worth making comprehensive, because it is already winning the retrieval half of the argument.
Does the model changing underneath you reset all this?
Partly, and it is worth planning for. OpenAI’s deprecations page states that “As we launch safer and more capable models, we regularly retire older models,” with at least six months of notice for generally available models and as little as two weeks for previews.
When a model is replaced, its cutoff moves and its memory of you is rebuilt from whatever existed by the new date. That is the one moment your training-data work lands, all at once, and it is also why a whole-engine step change in your numbers is usually a release rather than something you did. Diagnosing that shape is covered in AI visibility dropped suddenly.
Which one should you optimise for?
Retrieval first, because it is controllable, checkable, and it also protects you when memory is wrong. A current page that answers the question gives the engine something better than its recollection to use.
Then do the slow work anyway, deliberately and with the right expectations. The two are not alternatives: retrieval decides what an engine can say about you today, and training data decides whether it thinks of you at all when nobody named you. That difference between being found and being recalled is the split in mention rate vs citation rate.
Track a handful of checkable attribute facts across engines as your instrument. When a fact you changed six months ago finally appears in an engine that previously had it wrong, that is training data catching up, and it is the only clean signal you will get that the slow work worked.