Sitemap XML : un lastmod identique sur toutes les URL rend votre sitemap inutile

Un sitemap XML dit aux moteurs quelles URL existent, et lesquelles ont changé. La première fonction est remplie par presque tous les CMS. La seconde est ratée par une bonne partie d'entre eux, et de façon invisible : le fichier est valide, la Search Console le lit sans erreur, et pourtant il n'apporte plus aucune information sur ce qui a bougé. La cause tient à un seul champ, lastmod, et à la manière dont il est rempli.

Ce que Google fait vraiment de lastmod

La position de Google est écrite noir sur blanc dans sa documentation sur la construction d'un sitemap : la valeur de lastmod est utilisée « si elle est cohérente et vérifiable », par exemple en la comparant à la dernière modification réelle de la page. Google ajoute que les champs priority et changefreq sont ignorés. Sur les trois champs optionnels du format, un seul compte, et seulement s'il dit la vérité.

Du point de vue du moteur, le calcul est le suivant. Un robot dispose d'un budget d'exploration limité par site. Quand il relit un sitemap, il compare les dates annoncées à celles qu'il a mémorisées. Une URL dont la date a avancé mérite une nouvelle visite ; une URL dont la date n'a pas bougé peut attendre. Si toutes les dates avancent en même temps à chaque lecture, le moteur ne peut plus distinguer une page réellement mise à jour d'une page inchangée. Il finit par ne plus faire confiance au champ, et revient à ses propres heuristiques, en général plus lentes.

Le défaut typique : la date du build

Beaucoup de générateurs de sites statiques, et un certain nombre de CMS, écrivent dans lastmod la date à laquelle le site a été régénéré. Sur un site publié tous les jours, toutes les URL portent alors la date du jour, y compris des articles vieux de trois ans que personne n'a touchés. Le sitemap annonce en permanence que tout a changé.

Nous avons vérifié ce défaut sur plusieurs sites en production au cours de l'été 2026, sur plus de trois cents URL au total : dans chaque cas, une seule valeur de lastmod pour l'ensemble du sitemap, égale à l'heure du dernier build. Aucun de ces sites n'envoyait par ailleurs d'en-tête HTTP Last-Modified ni d'ETag sur ses pages, et aucun ne répondait aux requêtes conditionnelles des robots. Le moteur n'avait donc aucun moyen de savoir quoi recharger.

Diagnostic en trois contrôles

Le contrôle tient en quelques minutes, avec un simple terminal.

1. Compter les valeurs distinctes de lastmod. Récupérer le sitemap, extraire les balises lastmod et compter les valeurs uniques. Un sitemap sain sur un site de plusieurs centaines de pages en compte des dizaines. Une seule valeur, ou une poignée toutes datées du même jour, signe le défaut.
2. Comparer lastmod à la page. Prendre une URL ancienne du sitemap, ouvrir la page, et comparer la date de modification affichée dans l'article, ou dans ses données structurées, à la valeur lastmod. Un écart de plusieurs mois confirme que lastmod ne décrit pas la page.
3. Tester les en-têtes HTTP. Demander une page avec une requête HEAD et regarder si le serveur renvoie Last-Modified ou ETag. Puis renvoyer la même requête avec If-Modified-Since à la date reçue. Un serveur qui répond 304 Not Modified sait dire qu'une page n'a pas changé ; un serveur qui renvoie 200 à chaque fois oblige le robot à tout retélécharger.

Ces trois tests ne demandent aucun outil payant. Ils font partie des contrôles que nous recommandons avant toute discussion sur l'indexation d'un média.

Pourquoi c'est plus grave pour un média que pour un site vitrine

Un site vitrine de vingt pages est entièrement recrawlé quoi qu'il arrive. Un média qui publie plusieurs articles par semaine et en corrige d'autres vit d'un signal de fraîcheur fiable : c'est lui qui fait remonter un article mis à jour, et c'est lui qui évite au robot de dépenser son budget sur des pages figées. Quand le signal est cassé, deux symptômes apparaissent au bout de quelques semaines :

• Les nouveaux articles mettent plus longtemps à être indexés, parce qu'ils sont noyés dans un sitemap où tout semble nouveau.
• Les corrections d'articles anciens ne sont pas prises en compte, parce que rien ne distingue une page corrigée d'une page qui a simplement été reconstruite par un build.

Sur un média qui vise aussi les moteurs génératifs, le problème se paie une seconde fois : les robots des IA de recherche, qui s'appuient sur les mêmes sitemaps, en héritent. Un contenu révisé pour corriger un chiffre reste servi dans son ancienne version pendant des semaines.

Le critère de correction

Corriger le défaut, c'est faire porter à lastmod la date de la dernière modification éditoriale de chaque page, et rien d'autre. Concrètement :

Le critère de recette est le même que celui du diagnostic : après correction, le nombre de valeurs distinctes de lastmod doit refléter l'histoire réelle du média, et deux builds successifs sans modification éditoriale doivent produire deux sitemaps identiques. Si le sitemap change alors que rien n'a été écrit, la correction n'est pas faite.

Le cas particulier du média en sous-répertoire

Quand un média est hébergé sous un chemin du site principal, par exemple un blog servi sous /blog/ depuis une autre plateforme, une seconde difficulté s'ajoute : le fichier robots.txt qui déclare le sitemap n'est lu qu'à la racine de l'hôte. Un robots.txt placé dans le sous-répertoire n'est jamais consulté, et les lignes Sitemap qu'il contient n'existent pas pour les moteurs, comme le rappelle la documentation de Google sur robots.txt. Il faut alors déclarer le sitemap du média dans le robots.txt du site principal, ou le soumettre directement dans la Search Console. Google a retiré en 2023 la possibilité de « pinguer » un sitemap par simple requête HTTP : sans déclaration explicite, un média en sous-chemin n'a aucun canal de découverte.

Ces deux défauts, lastmod uniforme et sitemap non découvert, se corrigent une fois pour toutes au niveau de l'outil de publication. C'est le genre de détail qu'un CMS pensé pour un média doit régler par construction, parce qu'aucune équipe éditoriale ne le vérifiera à la main à chaque publication. Sur les autres signaux de fraîcheur, la date de révision affichée et les données structurées, nous renvoyons à notre article « Fraîcheur : dater ses contenus, les réviser, et le prouver aux moteurs ».