Sitemaps, dates et signaux de fraîcheur pour les index génératifs.

La fraîcheur est un critère de sélection, pas un bonus

Les moteurs génératifs affichent souvent la date de leurs sources, et leurs sous-requêtes portent fréquemment une année ou une mention « récent ». Sur toute question dont la réponse change avec le temps, un prix, une réglementation, une version, un comparatif, une page datée d'il y a trois ans part avec un handicap qu'aucune qualité rédactionnelle ne compense, parce que le moteur cherche précisément la source qui reflète l'état actuel. À l'inverse, sur une question de définition ou de méthode, l'ancienneté pèse peu, et une page stable et bien corroborée reste citée pendant des années.

La fraîcheur n'est donc pas une cinquième condition qui s'ajouterait aux quatre conditions d'une citation ; c'est une composante de la première et de la deuxième. Une page dont la date est illisible ou contradictoire est moins bien identifiée, et un passage qui affirme un chiffre sans le dater est moins citable. Les moteurs génératifs n'ont pas documenté de pondération de la date dans leur sélection ; ce que l'on observe dans les réponses suffit néanmoins à établir qu'ils la lisent, l'affichent, et la préfèrent récente lorsque la question l'exige.

Il en découle une règle et un piège. La règle : la date que vous émettez doit être exacte et identique partout où elle apparaît. Le piège : rafraîchir une date sans changer le contenu. Un moteur qui relit une page et n'y trouve rien de nouveau apprend à ne plus croire vos dates, et cette perte de confiance s'étend à tout le site. Google le dit explicitement pour le lastmod des sitemaps, qu'il n'utilise que s'il le constate régulièrement exact ; il n'y a aucune raison de supposer que les autres index soient plus indulgents.

Le sitemap XML : ce que les moteurs en lisent réellement

Le protocole sitemaps.org définit quatre éléments par URL : loc, lastmod, changefreq et priority. Seuls les deux premiers comptent. Google documente qu'il ignore changefreq et priority, et qu'il utilise lastmod à la condition qu'il soit constamment et vérifiablement exact ; Bing s'appuie également sur lastmod pour décider quoi réexplorer. Un fichier ne doit pas dépasser cinquante mille URL ni cinquante mégaoctets non compressés, au-delà de quoi un index de sitemaps répartit les entrées en plusieurs fichiers.

Pour les moteurs génératifs, le sitemap compte de deux manières. Directement pour AI Overviews, AI Mode et Copilot, qui reposent sur les index de Google et de Bing. Indirectement pour les autres : OpenAI, Anthropic et Perplexity n'ont pas documenté la manière dont leurs robots d'index découvrent les URL, mais rien n'indique qu'ils aient inventé un autre mécanisme que les liens et les sitemaps, et nos journaux montrent ces robots lire des pages récentes peu après leur ajout au sitemap. Le fichier ci-dessous illustre une entrée correcte : URL canonique en code 200, date à la seconde, fuseau horaire explicite.

<!-- Une entrée par URL canonique ; lastmod = dernière modification réelle du contenu principal -->
<?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>

Un lastmod sincère : la règle qui vaut pour tout le reste

Un lastmod est sincère lorsqu'il correspond à la dernière modification du contenu principal de la page, telle qu'un lecteur la percevrait. Il ne correspond ni à la date de génération du sitemap, ni à celle du dernier déploiement du site, ni à celle d'un changement de gabarit, de menu ou de bloc latéral. Cette définition simple est violée par la majorité des sites que nous auditons, presque toujours sans intention : c'est le système de gestion de contenu qui, à chaque publication, réécrit la date de toutes les pages.

Les erreurs reviennent en nombre limité, et chacune se détecte en quelques minutes en comparant deux versions du sitemap prises à une semaine d'intervalle.

• Toutes les URL portent la même date, celle de la dernière génération du fichier : le signal est nul, et Google cesse de s'y fier.
• La date change à chaque déploiement, alors que le contenu est identique : même effet, plus difficile à repérer.
• Un commentaire, un avis client ou un bloc « articles liés » met à jour la date de la page qui l'héberge.
• Le fuseau horaire est omis ou faux, et la date apparaît dans le futur pour un robot en UTC.
• Le sitemap liste des URL redirigées ou en erreur, avec des dates récentes qui invitent le robot à les relire.

La correction consiste à distinguer, dans le système de gestion de contenu, la date de modification du contenu principal des autres événements, et à n'émettre que la première. Lorsque le système ne le permet pas, une règle simple fonctionne : ne mettre à jour le lastmod que lors d'une intervention éditoriale explicite, consignée, et laisser toutes les autres dates inchangées. Une date ancienne mais vraie vaut mieux qu'une date récente que le robot apprend à ignorer.

Les dates visibles, et leur cohérence entre quatre emplacements

Un moteur génératif lit la date à quatre endroits, et il ne les hiérarchise pas comme vous. Le premier est le texte visible de la page, celui qu'un modèle de langage traite comme n'importe quel passage : une ligne « Mis à jour le 11 mai 2026 » sous le titre est la date qu'il citera. Le deuxième est le balisage Article ou BlogPosting, avec datePublished et dateModified. Le troisième est le lastmod du sitemap. Le quatrième est l'en-tête HTTP Last-Modified, que le robot reçoit avant même de lire la page. Google recommande d'afficher une date claire, d'utiliser les données structurées et d'éviter toute contradiction entre les deux ; l'article sur les dates de publication et de mise à jour détaille ces recommandations et les incohérences qui décrédibilisent une page.

Les contradictions les plus fréquentes tiennent au gabarit : une date visible fournie par le rédacteur, un dateModified calculé par le système à chaque enregistrement, un lastmod produit par une extension tierce, un Last-Modified qui reflète l'heure de mise en cache. Quatre origines, quatre dates, et un moteur qui n'en retient aucune. La solution technique n'est pas compliquée : une seule source de vérité dans le système de gestion de contenu, et les quatre emplacements alimentés depuis elle.

Flux de mise à jour : sitemap, flux RSS, IndexNow

Émettre une date exacte ne suffit pas ; encore faut-il que les index apprennent qu'une page a changé sans attendre leur prochain passage. Trois canaux existent, et ils ne sont pas lus par les mêmes moteurs. Le sitemap et les flux RSS ou Atom sont documentés par Google, qui accepte ces derniers comme des sitemaps à part entière, et par Bing. IndexNow, une initiative lancée par Microsoft et adoptée par plusieurs moteurs, permet de notifier une URL modifiée par une simple requête ; Google n'y participe pas, à notre connaissance, et a par ailleurs abandonné en 2023 son ancien point de terminaison de « ping » de sitemap. Quant aux robots d'index des moteurs génératifs, aucun éditeur n'a documenté de canal de notification.

Tableau : faites défiler horizontalement.

Un flux de mise à jour n'a de valeur que s'il est sélectif. Un flux qui annonce cent modifications par jour parce que le système régénère toutes les pages est ignoré aussi vite qu'un sitemap aux dates uniformes. La discipline est la même qu'au chapitre précédent : une notification par modification réelle, et rien d'autre.

Quels contenus rafraîchir en priorité

Tout ne mérite pas d'être rafraîchi, et rafraîchir sans raison coûte cher en crédibilité. La priorité se lit en croisant deux axes : le poids de la page dans votre part de citation, mesurée sur votre panel de questions, et la sensibilité de son sujet au temps. Les pages citées sur des questions à composante temporelle, et dont la date affichée dépasse douze mois, viennent en tête. Viennent ensuite les pages dont la citation a reculé au profit d'une source concurrente plus récente, ce que le panel révèle en quelques semaines.

Les catégories de contenu qui appellent une révision régulière sont toujours les mêmes : grilles tarifaires, pages réglementaires et fiscales, comparatifs et pages « meilleur X », fiches de compatibilité ou de versions, chiffres de marché, calendriers. Pour chacune, la mise à jour doit toucher le passage citable lui-même, le chiffre, la condition, la date de référence, et non un paragraphe d'introduction. L'article consacré à la mise à jour d'un contenu ancien décrit le protocole page par page ; le calendrier ci-dessous en donne le rythme.

Ce que la fraîcheur ne remplace pas

Une page récente mais vague n'est pas citée davantage qu'une page ancienne et vague. La date ouvre la porte sur les questions où elle compte ; elle ne dispense ni d'un passage qui répond en quarante à quatre-vingts mots, ni d'une entité identifiée, ni d'une corroboration externe. Nous voyons régulièrement des sites qui datent scrupuleusement des pages que personne ne cite, et d'autres, rarement mis à jour, qui dominent leur sujet parce qu'ils sont précis et repris ailleurs.

Le point de vigilance ultime concerne la vitesse de propagation. Entre une modification et sa prise en compte dans une réponse générative, il s'écoule le temps d'une nouvelle exploration, puis d'une mise à jour de l'index, et ce délai n'est documenté par aucun éditeur. Il se mesure chez vous, en rapprochant la date de modification du prochain passage du robot dans les journaux, comme l'explique l'article sur la vitesse et le budget d'exploration des robots IA. Un site qui répond vite, aux URL propres et aux dates fiables, est relu plus tôt ; c'est là que la fraîcheur se gagne réellement.

Ce qu'il faut retenir