Faut-il vraiment renseigner l'attribut lastmod dans vos sitemaps XML ?

Pourquoi Google accorde-t-il de l'importance à cet attribut lastmod ?

Le crawl budget — cette quantité limitée de pages que Googlebot accepte de crawler sur votre site dans un laps de temps donné — est une ressource précieuse. Google cherche constamment des signaux fiables pour orienter ses robots vers les pages qui ont vraiment changé, plutôt que de crawler aveuglément l'intégralité de votre site.

L'attribut lastmod dans les sitemaps XML est l'un de ces signaux. Quand vous indiquez qu'une page a été modifiée à une date précise, vous dites en substance à Googlebot : « Reviens voir celle-ci, il y a du neuf. » Sauf que si toutes vos pages affichent la date du jour, le signal devient bruité, voire inexploitable.

Que se passe-t-il si je mets la date du jour partout ?

Google perd la capacité de prioriser le crawl. Imaginons un site de 50 000 pages : si votre sitemap indique que les 50 000 pages ont été mises à jour aujourd'hui, Googlebot ne sait plus par où commencer — et il finit par ignorer purement et simplement cet attribut.

Résultat : vous passez à côté de l'avantage principal du sitemap, qui est de guider efficacement le crawl vers vos contenus frais. Les pages réellement modifiées risquent de ne pas être recrawlées rapidement, tandis que des pages inchangées consomment du crawl budget inutilement.

Dans quels cas l'attribut lastmod doit-il être mis à jour ?

La nuance est importante. Google parle de modifications significatives. Un changement de footer ou un ajustement CSS ne justifie pas de toucher à lastmod. En revanche, une refonte de paragraphe, l'ajout d'un chapitre, une mise à jour de données chiffrées — là oui, c'est légitime.

Beaucoup de CMS et de plugins mettent à jour lastmod dès qu'on touche à un champ quelconque de la page, y compris des métadonnées invisibles. C'est précisément ce comportement automatique que Mueller pointe du doigt : il faut maîtriser ce qui déclenche la mise à jour de cet attribut.

• Ne renseignez lastmod que pour les pages dont le contenu visible a changé de manière substantielle
• Évitez les générateurs de sitemap qui mettent la date du jour par défaut sur toutes les URLs
• Gardez lastmod vide ou omettez-le si vous n'avez pas de système fiable pour tracker les vraies modifications
• Privilégiez la qualité du signal à la présence systématique de l'attribut : un lastmod faux est pire qu'un lastmod absent

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, et c'est même une confirmation bienvenue. Depuis des années, les SEO qui suivent de près les logs serveur constatent que Googlebot priorise certaines pages au détriment d'autres — et que l'attribut lastmod joue un rôle dans cette priorisation, à condition d'être crédible.

Les sites qui mentent systématiquement sur lastmod (volontairement ou via un CMS mal configuré) voient leur sitemap progressivement dévalué par Google. C'est visible dans les rapports Search Console : le taux de pages crawlées après soumission du sitemap chute, et Google se rabat sur ses propres signaux (liens internes, fraîcheur perçue via les SERPs, etc.).

Quelles nuances faut-il apporter à cette recommandation ?

La notion de « modification significative » reste floue. Google ne donne pas de seuil chiffré — 10 % de texte changé ? 20 % ? Un nouvel encart ? Ça dépend probablement du contexte, du type de page, et de la fréquence habituelle de mise à jour de votre site. [À vérifier] sur la base de vos propres analyses de logs et de l'évolution de votre crawl budget.

Ensuite, cette recommandation s'applique surtout aux gros sites. Si vous avez 50 pages, peu importe que lastmod soit exact ou fantaisiste — Google crawlera tout régulièrement. Mais dès que vous dépassez quelques milliers de pages, la gestion fine de ce signal devient stratégique.

Y a-t-il des cas où cette règle ne s'applique pas ?

Oui. Les sites d'actualité, les plateformes de petites annonces, ou tout site avec un flux massif de nouvelles URLs doivent parfois faire des arbitrages. Certains préfèrent omettre lastmod complètement et miser sur d'autres leviers (fréquence du sitemap, priorité, structure du site).

De même, si votre CMS ne permet pas de distinguer facilement une modification cosmétique d'un vrai changement éditorial, mieux vaut ne pas renseigner lastmod que de le renseigner mal. Un attribut inexact envoie un signal trompeur qui finit par être ignoré — et vous perdez alors toute la valeur de ce levier.

Que faut-il faire concrètement pour exploiter lastmod correctement ?

Première étape : auditez votre sitemap actuel. Téléchargez-le, extrayez les valeurs de lastmod, et vérifiez si elles correspondent réellement aux dates de modification du contenu. Si 90 % de vos pages affichent la même date récente, c'est le signe d'un problème.

Deuxième étape : identifiez ce qui, dans votre CMS ou votre générateur de sitemap, déclenche la mise à jour de cet attribut. Est-ce un hook WordPress qui se déclenche à chaque save_post, même si vous n'avez touché qu'à une métadonnée invisible ? Est-ce un cron qui régénère le sitemap et met la date du jour partout ? Il faut reprendre le contrôle de cette logique.

Quelles erreurs techniques éviter absolument ?

L'erreur la plus courante : mettre lastmod = date du jour par défaut dans le template de génération du sitemap. Certains développeurs font ça par commodité, pensant que « plus récent = mieux ». C'est l'inverse : vous sabotez le signal.

Autre piège : confondre modification de la base de données et modification du contenu visible. Si votre système met à jour lastmod dès qu'une donnée interne change (statut de publication, tag ajouté, etc.), vous allez sur-signaler. Filtrer ces événements demande un peu de développement spécifique, mais c'est indispensable.

Comment vérifier que mon implémentation est propre ?

Surveillez les logs serveur pour voir si Googlebot crawle effectivement les pages dont vous avez modifié le lastmod — et s'il ignore celles que vous n'avez pas touchées. Si le comportement du bot ne change pas après avoir corrigé votre sitemap, c'est que Google a déjà classé votre signal comme non fiable.

Vous pouvez aussi comparer les dates lastmod de votre sitemap avec les dates de « dernière exploration » dans Search Console. Un décalage important et systématique entre les deux est un indice que Google n'utilise pas (ou plus) votre lastmod pour prioriser le crawl.

• Vérifiez que lastmod n'est mis à jour que lors de modifications éditoriales réelles du contenu
• Désactivez ou corrigez tout plugin/module qui met la date du jour par défaut sur toutes les URLs
• Omettez l'attribut lastmod plutôt que de le renseigner incorrectement si vous n'avez pas de système fiable
• Analysez vos logs serveur pour confirmer que Googlebot réagit bien aux changements de lastmod
• Documentez précisément ce qui déclenche la mise à jour de cet attribut dans votre stack technique
• Testez sur un échantillon de pages avant de déployer une nouvelle logique de sitemap à l'ensemble du site