Sitemaps : avec des dates lastmod fausses, mieux vaut ne pas en mettre (Gary Illyes)

L’essentiel

• Gary Illyes conseille de retirer les dates lastmod d’un sitemap quand elles sont fausses.
• Selon sa documentation, Google n’utilise la balise que si elle est exacte de façon constante et vérifiable.
• En juin 2024, Gary Illyes qualifiait déjà cette confiance de binaire : Google se fie aux dates d’un site, ou pas du tout.
• Google n’a pas précisé si une lastmod jugée non fiable pénalise un site ou si elle est simplement ignorée.

Gary Illyes : une lastmod fausse ne vaut pas mieux que pas de lastmod

Le 15 juillet 2026, le SEO Jason Kilgore a interpellé John Mueller et Gary Illyes sur Bluesky. Son équipe venait de découvrir un bug qui inscrivait des dates de dernière modification erronées dans ses sitemaps XML. Partant du principe, déjà exprimé par Google, que la confiance accordée à lastmod est binaire, il voulait savoir s’il valait mieux retirer la balise de toutes les pages ou garder des dates auxquelles Google ne croit plus. Gary Illyes lui a répondu le 16 juillet au matin, en une ligne : « il vaut probablement mieux se passer des lastmod. Au moins, vous économisez quelques octets » (traduction).

Quelques heures plus tard, Jason Kilgore a précisé sa question. Le poids du fichier ne l’intéresse pas : il demande si Google traite une lastmod non fiable comme un signal négatif, ou s’il se contente de l’ignorer, à la manière d’une balise meta keywords laissée dans le code sans aucun effet. Au moment de la publication, Gary Illyes n’avait pas répondu à cette relance. Sa réponse ne dit donc pas qu’une lastmod fausse pénalise un site. Elle dit qu’elle ne sert à rien.

Documentation de Google : lastmod n’est lue que si elle est fiable

Pour rappel, la page de Google consacrée à la création des sitemaps précise que la valeur de lastmod n’est utilisée que si elle est « exacte de façon constante et vérifiable » (traduction), ce que Google peut contrôler en la comparant à la dernière modification réelle de la page. Cette date doit correspondre à la dernière mise à jour significative. Google range en général dans cette catégorie un changement du contenu principal, des données structurées ou des liens de la page. Changer l’année du copyright ne compte pas. Les balises priority et changefreq, elles, sont ignorées.

En juin 2024, Gary Illyes avait déjà répondu sur LinkedIn à Mark Williams-Cook, qui lui demandait si Google attribuait aux sites une forme de réputation sur la fiabilité de leurs lastmod. Cette confiance était selon lui « binaire, ou du moins elle l’était la dernière fois que j’ai vérifié. Soit on s’y fie, soit non » (traduction). Si ce fonctionnement n’a pas changé, des dates fausses sur une partie des URL pourraient suffire à priver tout le site du bénéfice de la balise. Google ne l’a pas formulé ainsi : c’est une déduction.

Des dates qui bougent sans que la page change

Chez Jason Kilgore, la cause était un bug. D’autres configurations aboutissent au même résultat sans la moindre anomalie. Un générateur de sitemap peut inscrire l’heure de création du fichier plutôt que celle de la page, ou reprendre une date technique modifiée à chaque enregistrement. WordPress en donne un exemple. Dans ses sitemaps natifs, la lastmod des contenus (articles, pages et types de contenus personnalisés), ajoutée au code en octobre 2023, reprend le champ post_modified_gmt. Ce champ change à chaque mise à jour du contenu, y compris pour une simple coquille. Un import de catalogue ou une modification en masse par une extension peut ainsi réécrire la date de milliers d’URL sans que le visiteur voie la moindre différence.

Contrôler ses lastmod avant de les supprimer

Quelques vérifications suffisent pour savoir si les dates d’un sitemap sont crédibles.

1. Ouvrir le sitemap XML et repérer les centaines d’URL qui partagent la même date à la seconde près : c’est souvent l’heure de génération du fichier.
2. Recharger le sitemap le lendemain sans avoir rien publié. Si les dates ont avancé, elles ne suivent pas les pages.
3. Comparer quelques lastmod avec la date de mise à jour affichée sur la page, la propriété dateModified des données structurées et l’en-tête HTTP Last-Modified quand le serveur l’envoie.
4. Recenser les traitements automatiques (imports, tâches planifiées, extensions) qui modifient la date de mise à jour en base.

Ce que j’en retiens

La réponse de Gary Illyes tient en une ligne, et elle se défend : une date que Google ne croit plus n’apporte rien, la retirer ne coûte rien. Je ne supprimerais pas la balise par réflexe pour autant. Sur un site qui publie et met à jour souvent, une lastmod exacte est justement ce que Google dit exploiter. Le premier chantier consiste donc à corriger la source de la date, pour qu’elle ne change qu’en cas de vraie modification du contenu.

Retirer la balise se justifie quand cette correction est hors de portée, avec un CMS fermé ou un bug sans correctif rapide. Dans ce cas, je préfère un sitemap sans lastmod à un sitemap qui déclare toutes ses pages modifiées chaque matin. Rien n’empêche de remettre la balise une fois les dates corrigées.

Des dates lastmod fausses vont rarement seules : canoniques, sitemap et redirections se contrôlent ensemble, et c’est l’un des premiers points que je passe en revue dans un audit SEO technique.