Blog · Content that gets cited

How often to refresh content for AI search

Published 8 October 2026 · Updated 12 October 2026 · 9 min read

How often to refresh content for AI search
Photograph: Blessing Ri / unsplash

The short answer: Refresh a page when the facts inside it have decayed, not on a calendar. In practice that means pricing, comparison and statistics pages every four to eight weeks, how-to pages when the product or interface they describe changes, and reference pages once or twice a year. A date edit with no changed sentence is wasted work. What gets quoted back at you is the claim on the page, not the timestamp above it.

Most refresh advice gets this backwards. It starts from a cadence, hands every page the same interval, and measures success by how many pages were touched. That produces a lot of edited datelines and very few changed answers.

Decay rate, not age, decides the cadence

Think of each page as carrying a half life. A page that names a price, a plan tier, a model version, a market share figure or a competitor count has a short one. A page that explains a concept has a long one. Age alone says nothing: a two year old explanation of how retrieval works can be perfectly correct, while a four month old pricing table can be wrong in three places.

So the useful question is not "when did we last touch this". It is "which sentences on this page would embarrass us if an engine quoted them today". Open the page, highlight every sentence containing a number, a date, a version string or a product name, and ask when each of those was last verified. That list is your real refresh queue, and it is usually far shorter than the list of pages older than twelve months.

A sensible starting split, which you should then correct with your own evidence:

  • Pricing, plan comparison and "best X for Y" pages: four to eight weeks. They carry the

    • most short half life claims and they are the pages buyers ask about most.

  • Statistics and benchmark pages: whenever the underlying dataset publishes again, which

    • for many sources is monthly or quarterly.

  • How-to and setup pages: on event, not on schedule. The trigger is a UI change, a renamed

    • setting or a deprecated endpoint.

  • Definitions, concept explainers and policy pages: once or twice a year, mostly to check

    • that nothing contradicts a newer page of yours.

Comparison pages that get cited sit at the top of that list for a reason. In the audits we run, they are the page type we most often see lifted close to whole into an answer, and the page type where a stale row shows up fastest. That is our sample of client sites, not a measurement of the web.

Two retrieval paths, two very different clocks

There is a mechanism underneath all of this that explains why some edits show up in an answer the same afternoon and others take months.

The clearest documented case is OpenAI's, so take it as the worked example rather than as a description of the whole category. OpenAI's crawler documentation separates the agents: OAI-SearchBot builds the index behind ChatGPT's search features, while ChatGPT-User fires when a person's question in ChatGPT triggers a visit to a page. The same page adds that for search results it can take around 24 hours from a robots.txt update for OpenAI's systems to adjust, which tells you the live path has a lag measured in hours, not months. The second route is the model's own weights, formed from a crawl snapshot taken long before. Common Crawl's September 2026 archive, one of the public corpora used for this kind of training, holds 2.17 billion pages and 361.4 TiB of uncompressed content, captured inside one month and then frozen. Other engines document their crawlers differently, and some document nothing about refresh lag at all.

That is the asymmetry. An edit can reach the live path as fast as the next crawl, and OpenAI's own 24 hour figure for robots.txt is the only published number we have found for how quickly any of this propagates. It reaches the frozen path on a schedule nobody outside the labs publishes, and may never reach it, because the snapshot of your page that mattered was taken before you fixed it.

The practical consequence, and this is an inference from the mechanism rather than something an engine confirms, is that refreshing moves answers on queries that trigger retrieval and does little on queries answered from the model's own weights. If you want to know which of the two you are dealing with, run the question twice: once in a mode with browsing on, once with it off. If the on and off answers differ, you are on the live path and a refresh can move it. If they match, you are arguing with training data, and the lever is corroboration elsewhere rather than an edit on your own page. The sample audit report shows what that retrieval-on and retrieval-off split looks like when it is run across a prompt set rather than one question.

The dateline is a claim, and engines check it against the page

Google's documentation on publication dates is direct about two things. It asks for a user visible date on the page, featured prominently, and it asks that the user visible and structured values match. It also says plainly that Google does not guarantee a date will be shown in results at all. This is Google's guidance for Google's surfaces. We know of no equivalent published requirement from the other engines, which is not the same as saying they ignore dates.

Treat that as a contract rather than a formality. If your HTML says October 2026 and your dateModified says 2024, you have given a conflicting signal and neither value is worth much. If both say October 2026 but the body still quotes a 2023 figure, you have published a page that contradicts itself, and a system assembling an answer from passages will keep whichever passage it cut, which may well be the stale one.

A refresh that counts therefore changes at least one of these, verifiably:

  1. A number, with its source and the date it was measured.
  2. A sentence that was wrong and is now right.
  3. A section that no longer applies and is now gone.

Then, and only then, the dateline moves. The order matters because the edit is the signal and the date is the label on it.

The failure mode nobody budgets for

Refreshing a page is the easy half. The harder half is everything else that still repeats the old version of your claim.

An engine assembling an answer pulls passages from several places. Your page is one. A directory listing, a review site, a roundup post and a forum thread are the others. Change your price and you have corrected the one source you control. The ones you do not own keep feeding the old number into answers for as long as they survive. Forums, communities and user content in AI answers is worth reading alongside this. Community threads turn up often in the citation sets we record during audits, and they are rarely edited once posted, so an old thread quoting your old pricing can outlive several refreshes of your own page.

So a refresh plan with no outreach half is incomplete. When you change a material fact, list the external pages that state the old one, and work that list. It is slow, it is unglamorous, and it moves answers more than another dateline edit will.

One more trap, cheap to avoid. If the refreshed fact lives inside a screenshot, a chart image or a PDF datasheet, the text change never happened as far as most retrieval is concerned. See content locked in images and PDFs for why that keeps happening to pricing tables in particular.

How to tell the refresh worked

Pick ten questions where the stale claim would surface. Record the answer before you edit, including which sources were cited. Edit. Then wait. We cannot give you a crawl interval for your site, because the engines do not publish one and your logs are the only place it is visible: watch for the crawler's next hit on that URL and start the clock from there. Run the same ten questions several times each, because a single run is noise.

What you are looking for is not a higher score. It is a changed sentence: the number in the answer matches the number on your page, or the engine now cites the refreshed page instead of the old roundup. If the citation set did not change at all, the page was probably never in the candidate pool to begin with, and the problem is a citability problem rather than a freshness problem. What makes a page citable by an AI engine is the right place to start in that case.

What we are still measuring

We cannot tell you how much freshness weighs against the other retrieval signals. We have not found a published weighting from any of the engines we test, and we have no measurement of our own that would let us put a number on it, so the cadences above are a starting split to test against your own evidence rather than a finding. The four to eight week figure for pricing and comparison pages comes from how fast those facts change on the sites we work on, not from any published study, and you should expect it to be wrong for your catalogue.

Our evidence is an audit prompt set of about 45 prompts run across five engines with retrieval on and retrieval off, repeated for each client. That is a sample of questions on a sample of sites, not a census of either, and citation sets move between runs for reasons we can only partly explain. We have also not measured how long a refresh holds before the old claim returns, so we have left that number out rather than guess at it.

FAQ

Does changing only the date help? No. Google's documentation asks that the visible date and the structured date match each other and describe a real publication or update. A date edit with no content edit leaves you with the same passages in the retrieval pool.

How fast will an engine see the change? Only one engine publishes a number we can point at: OpenAI documents a roughly 24 hour lag for a robots.txt change to reach its search systems, which gives the order of magnitude for the live path. Beyond that, your own crawl logs are the only honest estimate. Answers written from the model's weights rather than from a fetch will not reflect the change at all.

Should every page get the same cadence? No, and a uniform cadence is how refresh budgets get wasted. Sort pages by how fast their facts decay, then by whether they are cited today, and spend on the top of that list.

Is there a minimum size of change that counts? One corrected fact is enough if it is a fact the answer depends on. Volume of edited words is the wrong measure. A single corrected price beats four hundred rewritten words of preamble.

Sources

All four checked on 12 October 2026.

Related reading

What makes a page citable by an AI engineComparison pages that get citedForums, communities and user content in AI answersContent locked in images and PDFsFAQ content that is not fillerDefinition pages, and why engines love them