Le champ lastmod d'un sitemap : ce que Google en fait vraiment

Parmi les champs facultatifs d'un plan de site XML, un seul est réellement pris en compte par les moteurs, et c'est celui dont l'usage est le plus mal maîtrisé. La date de dernière modification aide un robot à décider quelles adresses méritent une nouvelle visite, ce qui compte beaucoup sur les sites volumineux où l'exploration est répartie. Encore faut il qu'elle soit exacte : un site déclarant que toutes ses pages ont changé cette nuit obtient exactement l'inverse de l'effet recherché, puisque le champ devient inexploitable et cesse d'être consulté. Cet article détaille ce que ce champ déclenche réellement, ce qui le disqualifie et comment le calculer correctement.

Ce que ce champ déclenche

Il faut d'abord dissiper une confusion courante : ce champ ne demande pas au moteur de venir, il l'informe. La différence est fondamentale et elle explique la plupart des déceptions. Le rôle général du fichier est rappelé dans notre article sur le fichier sitemap.xml, sa définition et son utilité.

Une aide à la priorisation

Un robot disposant d'un budget d'exploration limité doit choisir quelles adresses revisiter. Une date récente sur une poignée d'adresses, au milieu de milliers de dates anciennes, désigne clairement où regarder en premier. Ce signal se combine avec d'autres, popularité de la page, historique de changement, importance dans le maillage. Il ne les remplace pas et il pèse d'autant plus que le site est volumineux. Sur un site de quelques centaines de pages, le robot revisite de toute façon l'ensemble régulièrement, ce qui rend le signal peu utile. Sur un catalogue de cent mille références, il devient l'un des rares moyens d'orienter l'effort vers ce qui a réellement bougé.

Une économie pour les deux parties

Un moteur qui sait qu'une page n'a pas changé depuis deux ans peut espacer ses visites, ce qui économise de la bande passante de votre côté et des ressources du sien. Cette convergence d'intérêt explique pourquoi le champ est effectivement exploité. Sur un site de plusieurs dizaines de milliers d'adresses, l'effet cumulé est significatif. Sur un site de trente pages, il est nul. Cette dépendance à la taille explique pourquoi les recommandations trouvées en ligne se contredisent : elles décrivent des situations différentes sans le préciser. La question à se poser est simplement de savoir si le robot a le temps de tout revisiter.

Ce qu'il ne fait pas

Le champ ne provoque pas de visite immédiate, ne garantit aucune réindexation et n'améliore aucun positionnement. Il ne compense pas non plus un maillage interne défaillant : une page orpheline déclarée modifiée reste une page orpheline. Ces attentes irréalistes sont la principale source de frustration sur le sujet. Le champ optimise la répartition de l'exploration, rien de plus. C'est déjà beaucoup sur un site où l'exploration est le facteur limitant, et c'est nul ailleurs. Présenter le travail sous cet angle évite des attentes que rien ne viendra satisfaire.

La différence avec l'en tête serveur

Le serveur peut également déclarer une date de dernière modification dans ses en têtes de réponse et répondre par un code indiquant l'absence de changement. Ce mécanisme, complémentaire, agit au moment de la requête plutôt qu'en amont. Les deux se renforcent et se contredisent parfois, ce qui envoie un signal brouillé. Le fonctionnement de ce code est détaillé dans notre article sur le code 304 Not Modified et son effet sur le crawl.

Le sort des autres champs

Les champs de priorité et de fréquence de changement, présents dans la même spécification, sont ignorés depuis longtemps par les principaux moteurs. Les renseigner ne nuit pas et ne sert à rien. Les discussions sur la valeur idéale à leur attribuer sont donc sans objet. Les omettre allège les fichiers, ce qui n'est pas négligeable sur les gros volumes. Sur cinquante mille adresses, la différence se compte en mégaoctets pour une information que personne ne lit.

Le seuil de confiance

Un moteur évalue la fiabilité du champ en comparant ce qu'il annonce avec ce qu'il constate en visitant. Si les pages déclarées modifiées ne le sont pas, la confiance tombe et le champ cesse d'être consulté pour l'ensemble du site. Ce mécanisme est simple et impitoyable. Il explique pourquoi un lastmod approximatif est pire que pas de lastmod du tout. Un champ absent laisse le moteur appliquer ses propres heuristiques, un champ faux le conduit d'abord à perdre du temps, puis à ignorer l'ensemble. Le rétablissement de la confiance après une longue période de valeurs fausses demande par ailleurs plusieurs semaines.

Ce qui disqualifie le champ

Les défauts sont peu nombreux et très répandus. Les connaître permet de vérifier son propre site en quelques minutes.

La date de régénération

C'est le défaut numéro un : le fichier est régénéré chaque nuit et toutes les dates prennent la valeur du moment. Le résultat est un fichier où dix mille pages ont été modifiées à trois heures du matin, information manifestement fausse. Plusieurs extensions se comportent ainsi par défaut. La vérification consiste à ouvrir le fichier et à regarder si les dates sont toutes identiques. Un réglage existe généralement pour corriger ce comportement, encore faut il savoir qu'il faut le chercher.

Les modifications non substantielles

Un changement de pied de page, l'ajout d'un commentaire, le recalcul d'un compteur de vues ou la mise à jour d'un bloc de contenus liés ne constituent pas une modification du contenu. Les faire remonter dans la date déclarée revient à annoncer des changements que le moteur ne constatera pas. Ce cas est fréquent sur les sites affichant des blocs dynamiques dans leurs pages. Il demande de distinguer, dans le code, ce qui touche au contenu et ce qui touche à l'habillage. Cette distinction n'a rien d'évident lorsque tout passe par le même mécanisme d'enregistrement, et elle mérite d'être posée explicitement plutôt que subie.

Le format incorrect

La date doit respecter le format normalisé, soit en date seule, soit en date et heure avec le décalage horaire. Une date écrite dans un format local, ou sans indication de fuseau lorsque l'heure est précisée, produit un avertissement et le champ est ignoré. Ce défaut est facile à repérer et il persiste sur les générateurs maison. Un contrôle sur trois lignes du fichier suffit. Les outils de validation de plan de site signalent également ce défaut, à condition de les employer une fois après la mise en place.

Les dates futures

Une date postérieure au moment de la lecture est incohérente et disqualifie l'entrée. Ce cas se produit sur les sites employant une planification, où la date de publication future se retrouve dans le champ. Il se produit aussi lors d'erreurs de fuseau horaire, un décalage de quelques heures suffisant. La correction consiste à borner la valeur à l'instant présent. Cette précaution tient en une ligne et elle protège contre plusieurs causes d'erreur à la fois.

L'absence de date sur une partie des entrées

Un fichier où seule une partie des adresses porte une date n'est pas invalide et il devient difficile à interpréter. Mieux vaut renseigner toutes les entrées ou aucune. L'incohérence provient souvent d'un contenu dont la date de modification n'a jamais été enregistrée, cas des pages créées par import. Une valeur de repli, la date de publication par exemple, résout le problème. Elle est honnête, puisqu'une page jamais modifiée depuis sa publication a effectivement pour date de dernière modification celle de sa mise en ligne.

La contradiction avec l'en tête serveur

Déclarer dans le fichier une date récente alors que le serveur répond que la page n'a pas changé produit un signal contradictoire. Ce cas survient lorsque le cache du serveur conserve une date figée. La cohérence entre les deux sources doit être vérifiée sur quelques pages, notamment après la mise en place d'un cache. C'est un contrôle rarement fait et souvent instructif. Il suffit d'interroger l'en tête d'une page dont on connaît la date de dernière reprise et de comparer avec ce que déclare le fichier.

Calculer une date juste

La bonne date est celle de la dernière modification substantielle du contenu principal de la page. Cette définition simple demande quelques décisions au moment de l'implantation.

Ce qui compte comme modification

Une reprise du texte, un ajout de section, une correction de fond, un changement d'image principale, une mise à jour de prix sur une fiche produit. Ce qui ne compte pas : une correction de faute isolée, un changement de catégorie, une modification de métadonnée interne. La frontière n'est pas toujours nette et il vaut mieux être conservateur, une date trop ancienne étant moins dommageable qu'une date trop récente. Une règle écrite dans les conventions du projet, listant ce qui met la date à jour et ce qui ne le fait pas, évite que chaque développeur ne tranche à sa manière.

Le cas des pages de liste

Une page de catégorie change dès qu'un élément y entre ou en sort. Sa date de modification est donc celle du dernier changement de sa composition, information qui n'est stockée nulle part par défaut. La calculer demande de prendre la date la plus récente parmi les éléments affichés, approche correcte et un peu coûteuse. Sur les catalogues importants, une mise en cache de ce calcul est indispensable. Le cache doit alors être invalidé lorsqu'un élément entre ou sort de la liste, ce qui suppose de brancher cette invalidation sur les bons événements.

Les contenus assemblés

Une page composée de plusieurs blocs provenant de sources différentes n'a pas de date unique évidente. La règle raisonnable consiste à retenir la date la plus récente parmi les blocs qui participent réellement au contenu, en excluant les éléments d'habillage. Ce calcul demande d'identifier ces blocs, ce qui n'est pas toujours immédiat sur un constructeur de pages. Un repli sur la date d'enregistrement de la page est acceptable. Il vaut mieux une approximation raisonnable et stable qu'un calcul sophistiqué dont personne ne comprendra le comportement dans deux ans.

Stocker plutôt que recalculer

La date doit être enregistrée au moment de la modification plutôt que calculée à la génération du fichier. Un champ dédié, mis à jour uniquement lors des changements retenus comme substantiels, garantit la stabilité de la valeur. Cette approche évite qu'un recalcul ne fasse bouger toutes les dates. Elle demande une intervention dans le code de sauvegarde des contenus. Le travail est modeste et il constitue le cœur du sujet : sans lui, toutes les autres précautions restent sans effet.

Le fuseau horaire

La valeur doit porter son décalage horaire explicite, faute de quoi son interprétation dépend du lecteur. Les serveurs configurés en temps universel et les sites configurés en heure locale produisent des écarts de quelques heures, suffisants pour générer des dates futures. Fixer le fuseau explicitement à la génération règle définitivement la question. Le temps universel est le choix le plus sûr, puisqu'il ne subit aucun changement saisonnier.

La granularité

La date seule, sans heure, suffit dans la plupart des cas et présente l'avantage de la stabilité. L'heure devient utile sur les sites publiant plusieurs fois par jour, où elle permet un ordonnancement fin. Sur un site publiant deux fois par semaine, elle n'apporte rien et ajoute une source d'erreur. Ce choix se fait selon le rythme réel de publication, ce qui rejoint les questions de répartition de l'exploration traitées dans notre article sur la manière de calculer son budget d'exploration à partir des journaux.

Vérifier et mesurer l'effet

Le contrôle demande dix minutes et il permet de savoir si le champ est exploité ou ignoré, information que personne ne possède par défaut.

Lire le fichier

Ouvrir le plan de site et parcourir une trentaine de lignes suffit à repérer les défauts les plus courants. Des dates toutes identiques, toutes très récentes ou visiblement fausses se voient immédiatement. Ce contrôle élémentaire n'est presque jamais fait. Il devrait figurer dans toute prise en main d'un site existant. Il donne en quelques secondes une indication sur le sérieux de la configuration technique du site. Le résultat oriente d'ailleurs souvent la suite de l'audit vers d'autres réglages laissés en l'état.

Comparer avec l'historique réel

Choisir cinq pages dont on connaît la date de dernière reprise et comparer avec ce que déclare le fichier donne une mesure directe de la fiabilité. Un écart systématique signale un problème de calcul, un écart aléatoire signale un problème plus profond. Ce test se mène en quelques minutes et il est concluant. Choisir des pages modifiées à des périodes différentes rend la comparaison plus parlante qu'un échantillon récent.

Observer les journaux du serveur

Les journaux indiquent quand le robot est passé sur chaque adresse. Croiser ces passages avec les dates déclarées montre si le champ influence réellement le comportement observé. Une page déclarée modifiée hier et visitée dans les jours qui suivent est un bon signe. Cette vérification demande quelques semaines de recul. Elle reste la seule qui porte sur le comportement observé plutôt que sur une hypothèse.

Suivre la fraîcheur en résultat

Le délai entre une mise à jour de contenu et la prise en compte de cette mise à jour dans les résultats constitue l'indicateur le plus parlant. Le mesurer sur quelques pages avant et après correction du champ donne un chiffre défendable. Ce délai varie selon l'autorité du site, ce qui interdit les comparaisons entre sites différents. Seule la comparaison du site avec lui même, avant et après, produit une information exploitable.

Ne pas surinterpréter

Le champ est un signal parmi beaucoup d'autres et son effet reste modéré sur un site de taille moyenne. Attribuer à sa correction une variation de trafic serait abusif. Son intérêt réel est de rendre l'exploration plus efficace, ce qui se mesure dans les journaux et non dans les positions. Rester honnête sur ce point évite de vendre un effet qui ne viendra pas. Ce cadrage protège aussi la relation avec le client, qui jugera le travail sur ce qui avait été annoncé.

Inscrire le contrôle au calendrier

Une mise à jour d'extension peut réintroduire le comportement fautif sans prévenir. Un coup d'œil au fichier après chaque intervention technique majeure, et une fois par trimestre en routine, suffit à maintenir la qualité du signal. Ce contrôle prend deux minutes. Son absence explique pourquoi tant de sites corrigés retrouvent le défaut six mois plus tard. Consigner la correction dans la documentation technique du projet permet en outre au prochain intervenant de comprendre pourquoi ce réglage a été modifié. Une ligne suffit : la date, le réglage modifié et la raison, information qui évite au suivant de rétablir la valeur d'origine en croyant corriger une erreur.