Two staleness clocks run against your brand at once, and they need different maintenance. Model memory is frozen at a training cutoff, typically months to a year or more behind the present,OpenAI publishes per-model knowledge cutoffs in its models documentation; other providers list theirs in model cards. and a model will repeat your old pricing with full confidence for as long as that model serves traffic. Live retrieval runs on the opposite clock: it reads pages fetched at answer time and favors the current, dated, maintained ones. Model Memory and Live Retrieval covers the split; this chapter covers keeping both clocks from hurting you.
The two clocks, and which pages each governs
The memory clock governs facts about you that models absorbed from training data: your pricing, product line, leadership, positioning, and reputation as they stood at the cutoff. You cannot edit a shipped model; you can only feed correct facts to the sources the next training run will read, and let retrieval override memory in the meantime. The retrieval clock governs the pages you maintain: whatever a fetcher reads at answer time is what the answer reflects, so a stale page is a stale answer today, regardless of any cutoff.
Sort your pages by which clock they serve. Fact-source pages, pricing, and specs serve retrieval and must be current. Coverage, profiles, and third-party records about you serve the next training run, and errors there become next year's confident wrong answers.
Finding and fixing stale model beliefs
Audit memory directly. With search off, ask each model about the facts that change: what you charge, what you ship, who runs the company, what you no longer offer. Run each prompt several times, since answers are sampled, and log every stale or wrong claim; Measuring AI Search Visibility covers the protocol. The output is a list of specific wrong beliefs, per model, with dates.
Fixing has two speeds. Fast: make the correct fact retrievable, since a current page pulled into context at answer time beats stale memory for search-on answers; that is the architecture and access work from Content Architecture: Building for the Chunk and Technical Accessibility for AI Crawlers. Slow: correct the fact at every source a training pipeline reads, your site, your profiles, Wikidata, the coverage that repeats your old pricing, then wait for models to ship trained on the corrected record. The slow fix is unglamorous and it is the only one that changes memory-only answers.
Update signals retrieval systems actually use
Retrieval systems read the same update evidence search engines always have: a visible dateline stating when the content was last revised, a changelog on pages where facts change, sitemap lastmod values that match reality, and text whose facts have actually moved. Keep those honest, and specifically do not fake them. Bumping dates on unchanged pages is detectable by comparing content versions, and a page whose "updated" claim proves hollow is training every system that checks to distrust your datelines. My rule: change the date when a fact changes, log what changed, and leave finished evergreen pages alone.
Where freshness does not pay
The counterweight finding, from OppAlerts' news analysis across 100 industries: press coverage predicts a brand's presence in memory-based answers more strongly than in search-based answers, in nearly every model tested.The news-coverage analysis in the AI Search Visibility research; per-model comparison in The Research Behind This Guide. Model split: [number: verify]. Coverage works as durable reputation compounding into future models, rather than as recency expiring with the news cycle, which is the argument developed in Digital PR, News, and the Gatekeeper Publishers.
The practical consequence: chasing freshness where it does not pay is a real and common waste. Republishing evergreen explainers on a schedule, rewriting stable pages so they look active, daily-posting for the algorithm; none of it has a mechanism behind it in AI search. Freshness effort belongs on pages whose facts decay.
A maintenance calendar a small team can sustain
- Same week as any change: pricing, product, and availability pages ship their updates alongside the change itself, as part of the launch checklist rather than a content task.
- Quarterly: review fact-source pages, spec pages, and statistics pages; update numbers, datelines, and changelogs.
- Twice a year: rerun the memory audit above and refresh the list of wrong model beliefs.
- Yearly: full refresh triage across the site. Three piles: update pages whose facts drifted, leave evergreen pages that remain true, and prune dead pages, since removing a page that states wrong facts is also freshness work.
That cadence is deliberately light. The point of sorting pages by clock is that most pages need nothing most of the time, and the ones that need attention need it promptly.