Content refresh for Google and AI search: what dates and updates actually signal

The short answer. A date tells search engines when a page changed; it does not make the page better. Google asks for a visible published or updated date that matches the datePublished and dateModified in your structured data, uses sitemap lastmod only when it is “consistently and verifiably” accurate, and lists “changing the date of pages to make them seem fresh when the content has not substantially changed” among the warning signs of search engine-first content. Bing says lastmod helps it decide what to recrawl. So refresh a page when its facts change, change the dates only then, and set all of them from one source.

Everything below comes from Google Search Central’s pages on byline dates, helpful content, sitemaps and ranking systems, two Bing Webmaster Blog posts on lastmod, and the schema.org definition of dateModified, as read on 15 October 2026.

What do dates tell Google, and what do they not?

They tell Google when a page was published or last significantly changed. Google calls the date it shows in results a byline date, “the date that Google estimates that the web page was updated or published”, and says it “doesn’t depend on a single date factor because all factors can be prone to issues”. Its systems look at several factors to estimate “when a page was published or significantly updated”.

Google’s instructions are short:

• Show the date. “Add a user-visible date to the page and feature it prominently”, labelled with text like “Publish” or “Last updated”.
• Mark it up. Use a CreativeWork subtype such as Article or BlogPosting “and specify the datePublished and/or dateModified fields”.
• Make them agree. “Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values.”
• Date the page, not the story. “Don’t specify future dates, or the date of the action described on the page.”
• Cut competing dates. If the wrong date is being picked, “consider removing some or all other dates that appear on the page”.

Schema.org defines dateModified as “The date on which the CreativeWork was most recently modified”. Neither of these sources defines how big a change has to be before the date moves. Google’s byline page also does not promise that a date will be shown; it says following the guidelines helps its algorithms “find and process the information”.

What a date does not do is improve the page. Google’s ranking systems guide describes “query deserves freshness” systems “designed to show fresher content for queries where it would be expected”, with the example of a film that has just been released. That is about the query: for many questions, a recent date is not what the searcher needs. Google’s helpful-content page puts the cosmetic version plainly, as a question to ask yourself: “Are you changing the date of pages to make them seem fresh when the content has not substantially changed?” The next question on that page is about adding or removing a lot of content to make a site seem “fresh”, and Google answers it: “(No, it won’t)”.

What counts as a real update?

A change to what the page says. Google’s sitemap page gives the clearest line in its documentation: “an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not.”

Change	Real update?	Move the updated date?
A fact, figure, price, step or recommendation changed	Yes	Yes, and say what changed
A section added or rewritten to answer the question better	Yes	Yes
A source replaced because the original moved, changed or died	Yes	Yes
Structured data corrected	Yes, per Google’s sitemap page	Yes
Typos, a new image crop, a template, footer or copyright-year change	No	No
A rebuild or redeploy with no content change	No	No

The last two rows are where dates drift without anyone deciding to change them, because the date comes from the build or the file’s save time rather than from the content. Bing found the same pattern in sitemaps: “the date on most XML sitemaps was set to the date of generation of the sitemap, rather than the date of content modification.”

How should the visible date, dateModified and sitemap lastmod agree?

Set all three from one stored value, the date of the last real change, and never from the build. Google’s byline page asks for the visible date and the structured data to match; its sitemap page says lastmod “should reflect the date and time of the last significant update to the page” and that Google uses it “if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate”. Bing’s 2023 post adds a warning: “if we observe that the dates are consistently set to the current date, we will suspect the validity of those dates and may disregard them.”

Date of the last real change

Stored once with the content, set by an editor, never by the build.

• Visible date

  “Published” and, after a real change, “Updated”, near the title.

  Google: feature it prominently

• datePublished and dateModified

  On the Article or BlogPosting node in JSON-LD.

  Google: must match the visible date

• Sitemap lastmod

  Per URL, with date and time.

  Google uses it only if consistently accurate

• Open Graph article:modified_time

  For link previews and other readers of the head.

  Not covered by Google’s byline page

This is how our own site does it. Each article has a published date and, only after a content change, an updated date and a short note on what changed. The visible “Updated” label, the BlogPosting dateModified, the article:modified_time tag and the sitemap lastmod are all read from that one field; without it, the schema, Open Graph and sitemap dates fall back to the published date and no updated label is shown. Pages that are not articles take their date from a single file of review dates, each one “the day the page’s content last changed in git, never the build date”, which feeds the visible “Last reviewed” line, WebPage.dateModified and the sitemap. Our editorial policy says the same in plain terms: material updates are dated on the page.

On format, Bing’s 2025 post recommends “standard ISO 8601 date formatting for lastmod values, including both the date and time”. Both Google and Bing say they ignore changefreq and priority. For changes you want seen quickly, Bing recommends IndexNow, “instantly notifying Bing and participating search engines when individual URLs are added, updated, or removed”. Google’s documentation we read does not mention IndexNow.

When should you refresh a page, and when should you merge or start a new one?

Refresh when the page has become wrong or weaker than it should be, not on a calendar. The triggers we use:

• A fact changed. A price, a product, a platform setting, a law, a vendor’s documentation. If a reader acting on the page today would get it wrong, it needs an update.
• A source broke. The page you cite moved, changed its wording or disappeared. Re-read it; if the claim no longer holds, change the claim.
• The question changed. Readers now ask something the page half-answers. Add the section rather than a new page.
• The page no longer matches its title. Either fix the content or fix the title.

None of Google’s or Bing’s pages we read set a refresh interval, and none say that updating a page on a schedule helps it.

Merge when two pages answer the same question. Google’s canonical page describes the benefit of pointing similar or duplicate pages at one preferred URL: search engines can “consolidate the signals they have for the individual URLs (such as links to them) into a single, preferred URL”. If one page is retired into another, its redirect page lists “You removed a page and you want to send users to a new page” as a reason to redirect, and says to “Use permanent redirects when you’re sure that the redirect won’t be reverted.” The merged page is a real update and gets a new updated date.

Start a new page when the subject is new: a new product, a new version with its own audience, a report for a new period. Keep the old one if people still need it, and link between them.

What do AI answer engines document about freshness?

Very little, and nothing about dates on your page. Google’s generative AI optimisation guide says its AI features use retrieval-augmented generation “to improve the quality, accuracy, and freshness of AI responses by relying on our core Search ranking systems to retrieve relevant, up-to-date web pages from our Search index”. In other words, freshness in AI Overviews and AI Mode comes through the same index and ranking systems as Search, so the date guidance above is the guidance that applies. Its AI features page notes that crawling “can take anywhere from several days to several months, depending on how often our systems determine a page needs to be refreshed”.

Bing is the most direct. Its 2025 post says “freshness signals directly influence how quickly updates are reflected in search results and AI generated answers”, and that lastmod helps Bing “prioritize URLs for recrawling and reindexing, or skip them entirely if the content hasn’t changed since the last crawl”. That is about how quickly a change is picked up, not about whether a recent date earns a citation. The Copilot side is covered in our guide to how Microsoft Copilot chooses sources.

OpenAI’s crawler overview and Perplexity’s crawler page, which we read for this article, say nothing about dates, dateModified, sitemaps or freshness. We found no vendor text from either that explains how the age of a page affects whether it is used.

A checklist

1. Every article shows a “Published” date and, after a real change, an “Updated” date near the title, with nothing that changes on every build.
2. The visible dates match datePublished and dateModified in the page’s structured data.
3. Sitemap lastmod comes from the same stored date as the page, with date and time, and not from the sitemap’s generation time.
4. The updated date moves only when the main content, the structured data or the links change, and the page says briefly what changed.
5. Other dates on the page (event dates, comment dates, a footer year) cannot be mistaken for the page date.
6. Each page is re-checked when a fact, product, price or cited source it depends on changes, and its sources are re-read at the same time.
7. Two pages answering the same question are merged into one, with a permanent redirect from the retired URL.
8. Changed URLs are submitted through IndexNow if you use it, and the sitemap is referenced in robots.txt.

Our author and freshness signals check reads one URL’s byline, visible dates, datePublished, dateModified, Open Graph times and Last-Modified header and lists every disagreement. The sitemap inspector checks a sitemap’s lastmod values for format, future dates and identical values.

What we don’t claim

• We do not claim that updating a page, or its date, improves rankings or causes an AI citation. Google lists date changes without substantial content changes as a warning sign of search engine-first content, and none of the vendors we read describe freshness as a citation factor.
• We do not claim a threshold for a “substantial” change. Google gives examples on its sitemap page and nowhere sets a size or percentage.
• We do not claim to know how OpenAI, Perplexity or other assistants weigh the age of a page. Their documentation linked here does not say.
• We do not claim the details are permanent. Vendor documentation changes without notice; re-read the sources before relying on them.