Sitemaps, dates and freshness signals for generative indexes.

Freshness is a selection criterion, not a bonus

Generative engines often display the date of their sources, and their sub-queries frequently carry a year or the word “recent”. On any question whose answer changes over time, a price, a regulation, a version, a comparison, a page dated three years ago starts with a handicap that no editorial quality can make up for, because the engine is looking precisely for the source that reflects the current state of affairs. Conversely, on a question of definition or method, age carries little weight, and a stable, well-corroborated page remains cited for years.

Freshness is therefore not a fifth condition added to the four conditions of a citation; it is a component of the first and the second. A page whose date is unreadable or contradictory is less well identified, and a passage that states a figure without dating it is less citable. Generative engines have not documented any weighting of dates in their selection; what can be observed in their answers is nevertheless enough to establish that they read the date, display it, and prefer it recent when the question demands it.

From this follow a rule and a trap. The rule: the date you emit must be accurate and identical everywhere it appears. The trap: refreshing a date without changing the content. An engine that re-reads a page and finds nothing new in it learns to stop trusting your dates, and that loss of trust spreads to the whole site. Google says so explicitly for the lastmod of sitemaps, which it uses only if it regularly finds it accurate; there is no reason to assume the other indexes are more lenient.

The XML sitemap: what engines actually read from it

The sitemaps.org protocol defines four elements per URL: loc, lastmod, changefreq and priority. Only the first two matter. Google documents that it ignores changefreq and priority, and that it uses lastmod on condition that it is consistently and verifiably accurate; Bing also relies on lastmod to decide what to recrawl. A file must not exceed fifty thousand URLs or fifty megabytes uncompressed, beyond which a sitemap index splits the entries across several files.

For generative engines, the sitemap matters in two ways. Directly for AI Overviews, AI Mode and Copilot, which rely on the Google and Bing indexes. Indirectly for the others: OpenAI, Anthropic and Perplexity have not documented how their index crawlers discover URLs, but nothing suggests they have invented any mechanism other than links and sitemaps, and our logs show these crawlers reading recent pages shortly after they are added to the sitemap. The file below illustrates a correct entry: canonical URL returning a 200, date to the second, explicit time zone.

<!-- One entry per canonical URL; lastmod = last real modification of the main content -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.exemple.fr/guides/tva-batiment</loc>
    <lastmod>2026-05-11T09:20:00+02:00</lastmod>
  </url>
  <url>
    <loc>https://www.exemple.fr/guides/fiscal-2026</loc>
    <lastmod>2026-01-15T08:00:00+01:00</lastmod>
  </url>
</urlset>

An honest lastmod: the rule that governs everything else

A lastmod is honest when it corresponds to the last modification of the page's main content, as a reader would perceive it. It corresponds neither to the date the sitemap was generated, nor to the site's last deployment, nor to a change of template, menu or sidebar block. This simple definition is violated by the majority of the sites we audit, almost always unintentionally: it is the content management system that, at every publication, rewrites the date of every page.

The errors come in a limited number of forms, and each can be detected in a few minutes by comparing two versions of the sitemap taken a week apart.

• All URLs carry the same date, that of the file's last generation: the signal is nil, and Google stops relying on it.
• The date changes at every deployment while the content is identical: same effect, harder to spot.
• A comment, a customer review or a “related articles” block updates the date of the page that hosts it.
• The time zone is omitted or wrong, and the date appears in the future to a crawler running in UTC.
• The sitemap lists redirected or broken URLs, with recent dates that invite the crawler to re-read them.

The fix consists in distinguishing, within the content management system, the modification date of the main content from all other events, and emitting only the former. When the system does not allow it, a simple rule works: update the lastmod only upon an explicit, logged editorial intervention, and leave all other dates unchanged. An old but true date is worth more than a recent date the crawler learns to ignore.

Visible dates, and their consistency across four locations

A generative engine reads the date in four places, and it does not rank them the way you do. The first is the visible text of the page, which a language model processes like any other passage: a line reading “Updated 11 May 2026” under the title is the date it will cite. The second is the Article or BlogPosting markup, with datePublished and dateModified. The third is the sitemap's lastmod. The fourth is the HTTP Last-Modified header, which the crawler receives before it even reads the page. Google recommends displaying a clear date, using structured data and avoiding any contradiction between the two; the article on publication and update dates details these recommendations and the inconsistencies that discredit a page.

The most frequent contradictions come from the template: a visible date supplied by the writer, a dateModified computed by the system at every save, a lastmod produced by a third-party plugin, a Last-Modified that reflects the caching time. Four origins, four dates, and an engine that keeps none of them. The technical solution is not complicated: a single source of truth in the content management system, and the four locations fed from it.

Update feeds: sitemap, RSS feed, IndexNow

Emitting an accurate date is not enough; the indexes also need to learn that a page has changed without waiting for their next visit. Three channels exist, and they are not read by the same engines. The sitemap and RSS or Atom feeds are documented by Google, which accepts the latter as fully-fledged sitemaps, and by Bing. IndexNow, an initiative launched by Microsoft and adopted by several engines, makes it possible to notify a modified URL with a single request; Google does not take part in it, to our knowledge, and moreover retired its old sitemap “ping” endpoint in 2023. As for the index crawlers of generative engines, no vendor has documented a notification channel.

Table: scroll horizontally.

An update feed has value only if it is selective. A feed that announces a hundred modifications a day because the system regenerates every page is ignored as quickly as a sitemap with uniform dates. The discipline is the same as in the previous chapter: one notification per real modification, and nothing else.

Which content to refresh first

Not everything deserves to be refreshed, and refreshing without reason costs dearly in credibility. Priority is read by crossing two axes: the page's weight in your citation share, measured on your panel of questions, and how time-sensitive its subject is. Pages cited on questions with a time component, and whose displayed date is more than twelve months old, come first. Next come pages whose citation has declined in favour of a more recent competing source, which the panel reveals within a few weeks.

The categories of content that call for regular revision are always the same: price lists, regulatory and tax pages, comparisons and “best X” pages, compatibility or version sheets, market figures, calendars. For each, the update must touch the citable passage itself, the figure, the condition, the reference date, and not an introductory paragraph. The article on updating old content describes the protocol page by page; the calendar below sets its rhythm.

What freshness does not replace

A recent but vague page is not cited any more than an old and vague page. The date opens the door on the questions where it counts; it does not dispense with a passage that answers in forty to eighty words, nor with an identified entity, nor with external corroboration. We regularly see sites that scrupulously date pages nobody cites, and others, rarely updated, that dominate their subject because they are precise and picked up elsewhere.

The ultimate point to watch concerns propagation speed. Between a modification and its inclusion in a generative answer, there elapses the time of a new crawl, then of an index update, and no vendor documents this delay. It is measured on your own site, by matching the modification date against the crawler's next visit in the logs, as explained in the article on speed and crawl budget for AI crawlers. A site that responds fast, with clean URLs and reliable dates, is re-read sooner; that is where freshness is really won.

What to remember