AI content freshness: update when the evidence changes

Why stale pages cost more in AI answers

AI answers read the page for the searcher, and which version they read depends on how they reach it. OpenAI's help page says ChatGPT may search the web automatically when a question would benefit from current information, and its crawler documentation says ChatGPT may visit a page with its ChatGPT-User agent when someone asks a question. Perplexity describes its Perplexity-User agent the same way, and Anthropic its Claude-User agent. Those live visits, started by a person's question, read whatever the page says that day.

Answers built from a search index reflect the version of the page that was last crawled. Google says a page must be indexed to be shown as a supporting link in AI Overviews or AI Mode, and that crawling can take anywhere from several days to several months, depending on how often its systems decide a page needs refreshing. OpenAI says its OAI-SearchBot crawler is what surfaces websites in ChatGPT's search results. So a fix can take a while to reach these answers, and a wrong fact can keep being repeated after you correct it. The gap between the two is covered in why a crawl does not prove an AI citation.

People are told to check, too. OpenAI's ChatGPT search help page warns that search results and citations can be incomplete, outdated or incorrect, and tells users to open the source and see when it was published or updated. An old date on an accurate page can cost you trust. A fresh date on a wrong page does worse.

Google hasn't added a separate freshness rule for AI features. Its page on AI features and your website says normal SEO practice applies, with no additional requirements or special optimisations for AI Overviews or AI Mode, and no need for new machine-readable files or AI text files. One item on its list is keeping your Business Profile information up to date. Its SEO starter guide is plainer still: check in on published content, update it as needed, or delete it if it's no longer relevant. Freshness, in other words, is an accuracy job, and the rest of this guide treats it that way.

What counts as a real update, and when to go further

Start with what Google's own guidance says. Its guide to helpful content lists, as a warning sign, changing the date of pages to make them seem fresh when the content hasn't substantially changed. It also says adding or removing lots of content to make a site seem fresh won't help.

Google's sitemap documentation draws a finer line. Google uses the lastmod value only when it's consistently and verifiably accurate, and that value should reflect the last significant update: a change to the main content, the structured data or the links on the page. A new copyright year doesn't count. The same page says Google ignores the priority and changefreq values, so a sitemap can't promise a crawl schedule either.

Some reviews find more than a stale sentence. If the page's main point is now wrong, rewrite it on the same URL so the address people and AI tools already know carries the corrected version. If two pages now answer the same question, read when to merge overlapping pages before touching either. If you no longer offer the service at all, Google's redirect guidance recommends a permanent server-side redirect (a 301 or 308) when a page's address changes for good, so send it to the closest page that still helps that searcher. Noindex, canonical and redirects explained covers which signal fits which case.

Use this table to sort what a review finds:

Set triggers and a review rhythm for each kind of page

A calendar alone is a weak trigger. A page can be right for two years, then wrong the week a platform rewrites its help page. So for each page, list the claims that could change, the source behind each, and the event that would make it wrong.

Platform documentation is the obvious trigger. Google's Search Central blog announced Generative AI performance reports for Search Console on 3 June 2026, rolling them out to a subset of sites first, and says they reached all websites worldwide as of 31 August 2026. A guide that said Search Console had no AI-specific report was wrong from the launch, and wrong for every site by 31 August. The report itself is explained in how to interpret Google AI impressions.

Official sources also age at different speeds. As of 1 October 2026, Google's AI features page, last updated in December 2025, still explains AI feature data only through the Performance report's Web search type, with no mention of the new report. Accurate, but incomplete. Check each source's own date, lean on the newest, and note both in your log.

Keep a calendar backstop for pages nothing has triggered. Google says its systems give even more weight to strong E-E-A-T on topics that could significantly affect people's health, financial stability or safety, which it calls Your Money or Your Life topics. The intervals below are practical defaults for a local service business, not a ranking rule:

• Keep each changeable fact in one place. Hours, phone numbers and service areas should come from one site setting that feeds every page and the structured data, so one edit fixes them everywhere.
• Write dated facts with their date: "as of October 2026" beside a platform rule or a report name tells the reader, and your next reviewer, how old the claim is.
• Keep stable explanations apart from changeable detail. A paragraph on why reviews matter rarely changes; a paragraph naming a menu path in a dashboard changes often, so keep it short and easy to find.
• Record every claim's source in your page notes when you publish, so the next review starts from a list rather than a hunt.
• Match your Google Business Profile and other listings to the same master record. Business listing accuracy covers that side.

Find the pages that need a review first

Start where an error would do the most harm or reach the most people. You don't need to review a whole site at once; a short, ranked list worked through properly beats a sweep that touches everything lightly.

Search Console's own help explains the moves. Its Performance report lets you compare two time periods, such as this period against the one before, and sort by the Difference column to see queries or pages with significant change. Its Pages tab shows which pages get the most clicks, and you can filter the report to one URL. Google also suggests that a page with a low click-through rate may need its title and description updated to better represent the content. Combine these with your own records:

• Pages that state hours, prices, service areas or regulated advice. These carry the most risk if wrong, whatever their traffic.
• Your top pages by clicks in the Performance report's Pages tab, and any page in the Generative AI performance report. These are the versions most people and AI answers are reading.
• Pages whose clicks or impressions fell when you compare the last three months with the three before. A fall is a prompt to check, not proof of staleness: Google notes that news events, competitors and shifts in what people want can all move the numbers.
• Pages whose lastmod or log entry hasn't changed in twelve months, and pages that have never been reviewed since launch.
• Pages whose newest source is old, or whose outbound links now redirect, break or point to a rewritten page.
• Pages AI agents fetch often. Ask your host or developer for server logs, or a report, filtered to user agents such as OAI-SearchBot and ChatGPT-User (OpenAI), PerplexityBot and Perplexity-User (Perplexity), and Claude-SearchBot and Claude-User (Anthropic). A page fetched often is being read, so check it early. A fetch alone doesn't prove anything was cited.

A review routine for one page

Here's an order that keeps a review honest. It suits a business owner with a checklist as well as a content team.

1. Re-read each source on the page's claim list and note the source's own last updated date. Open every outbound link and confirm it still lands on the page it cites.
2. Mark every sentence that no longer matches, and any question customers now ask that the page doesn't answer. Look in three places: your call and email notes, the Queries tab in Search Console filtered to this page, and the questions shown on the results page for its main search.
3. Decide the scale of the job with the table above: edit, rewrite, merge or redirect.
4. Rewrite only what changed, on the same URL. If AI helps draft it, a person checks every claim against its current source before it goes live.
5. Check the metadata too. Google's guidance on generative AI content asks for accuracy in titles, meta descriptions, structured data and image alt text. Rewrite the meta description if the page's main point changed.
6. Change the visible last updated date and the dateModified value in structured data together. Google's byline guidance says the two should match and that dates shouldn't be in the future.
7. Update the sitemap lastmod and write the log entry.
8. Ask Google to recrawl: the URL Inspection tool for a few pages (you need to be an owner or full user of the Search Console property), or a sitemap for many. Google's recrawl guidance says crawling can take a few days to a few weeks, a request doesn't guarantee inclusion, and repeat requests won't speed it up.
9. Tell other search engines. IndexNow, according to its own FAQ, lets you submit URLs when content is added, updated or deleted, and a submission is shared across all IndexNow-enabled search engines; its published list includes Bing. Google isn't on that list. The FAQ also says a submission doesn't guarantee immediate indexing and asks you not to resubmit the same URL many times a day without meaningful changes.
10. If an AI answer still repeats the old version long after that, work through AI source correction and retraction.

Worked example: one refresh for a Caloundra plumber

This is a hypothetical business, made up to show the routine. Say a plumbing business in Caloundra adds weekend call-outs and stops travelling to one suburb it used to cover. Nothing about Google or AI has changed; the business has, and that is the trigger.

Step one is the claim list. The owner searches the site for the hours and the dropped suburb and finds them in five places: the contact page, the hot water service page, the blocked drains page, the home page footer and a suburb page for the area they no longer cover. The Business Profile still shows the old hours, and the LocalBusiness structured data still lists weekday hours only.

Step two is sorting each find with the table. The contact page, both service pages and the footer get a straight edit. The suburb page is different: its main point, that the business serves that suburb, is now false. The owner can't rewrite it into something true, so it is redirected to the nearest regional page that still describes the business's real coverage, and the suburb is taken out of every list that names it. Service area pages for genuine local coverage helps with that call.

Step three is the edits. Hours change in the one site setting that feeds every page and the structured data, so all five places update together. The two service pages get a new line about weekend call-outs. The Business Profile hours are changed the same day. Each edited page gets a new visible last updated date, a matching dateModified and a new lastmod.

Step four is telling search engines. The owner inspects the three edited service and contact pages in Search Console and requests indexing, resubmits the sitemap, and sends the changed URLs through IndexNow.

Step five is the log. One entry per page records the date, the change in a sentence, the trigger (weekend call-outs added, one suburb dropped), who checked it, and a saved copy of the old version. A month later the owner compares the four weeks after the change with the four weeks before in Search Console for those pages, and asks ChatGPT, Perplexity and Google's AI Mode for a plumber in Caloundra on a weekend, noting which pages each answer cites. Every figure from that check is a note in the log, not proof that the update caused it.

Keep a revision history, then check what the update did

A revision history answers two questions: what changed, and why anyone should trust the new version. Keep two layers.

On the page, show a clearly labelled last updated date and, for a change readers would care about, a line or two saying what changed. Keep that note to the latest change. Google's byline guidance says that if it keeps picking the wrong date for a page, consider removing some of the other dates on it, so a long public changelog can work against you. When advice reverses, say so. Quietly swapping a recommendation people already acted on is exactly what a log should catch.

If AI helped draft the update, say so where a reader would reasonably wonder how the page was made. Google's helpful content guidance suggests disclosures in that case, and AI content shows an editor-led approach to AI drafting. The same guidance asks whether content is written or reviewed by someone who demonstrably knows the topic, so record who checked each update: the owner for services, areas and qualifications, the writer for sources, dates, structured data and links.

Behind the scenes, keep the full log. Each entry should carry:

• The date of the change, which is also your before and after line for measurement
• What changed, in one sentence
• Why: the trigger, such as a rewritten help page or a new service area
• The source you checked, and the date you read it
• Who reviewed it
• A saved copy of the old version
• What you'll check later, and when: equal date ranges in Search Console before and after, the Generative AI performance report, the AI answers you spot-checked, and referrals in GA4 as covered in how to measure ChatGPT referrals