Faut-il vraiment remplir les dates de modification dans vos sitemaps XML ?

Pourquoi Google accorde-t-il de l'importance à la balise ?

Google crawle des milliards de pages quotidiennement. Pour optimiser son crawl budget, il doit identifier les contenus qui ont évolué depuis sa dernière visite. La balise <lastmod> dans les sitemaps sert précisément à ce triage.

Concrètement, si votre sitemap indique qu'une page a été modifiée il y a 6 mois et qu'elle n'a effectivement pas bougé, Google n'y voit aucun souci. Il crawlera selon sa fréquence habituelle pour cette URL. La véracité de la date prime sur sa fraîcheur.

Quel est le piège qui rend ces dates inutiles ?

Le problème survient quand un CMS ou un générateur de sitemap inscrit systématiquement la même date pour toutes les URLs — typiquement la date du jour de génération du fichier XML. Google détecte cette uniformité aberrante.

Face à ce pattern, l'algorithme considère que ces dates sont mécaniques et non représentatives de l'état réel du contenu. Il ignore alors complètement la balise <lastmod> pour l'ensemble du sitemap. C'est comme si vous n'aviez rien renseigné.

Vaut-il mieux omettre les dates ou risquer des valeurs approximatives ?

Johannes Müller précise qu'omettre totalement la balise <lastmod> est acceptable, surtout pour du contenu dynamique où tracer la vraie date de modification est complexe (pages catalogue, listings, filtres).

Sans cette balise, Google se rabat sur ses propres heuristiques : analyse du contenu lors du crawl, détection de changements dans le DOM, signaux de fraîcheur externes. Autrement dit, ne rien mettre vaut mieux que mentir. Si votre système ne peut garantir la fiabilité des dates, assumez le silence plutôt que le bruit.

• Google utilise <lastmod> pour prioriser le recrawl des pages potentiellement mises à jour
• Une date ancienne mais exacte n'est pas pénalisante — elle reflète simplement une page stable
• Le vrai problème : toutes les dates identiques (date de génération du sitemap) — Google ignore alors complètement ces métadonnées
• Omettre la balise est préférable à fournir des dates mécaniques ou approximatives
• Pour du contenu dynamique, ne pas renseigner <lastmod> reste une stratégie défendable

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et elle confirme ce que beaucoup de praticiens soupçonnaient depuis longtemps. Les audits de crawl montrent régulièrement que Google revisite certaines pages malgré des <lastmod> anciennes, et en délaisse d'autres malgré des dates récentes. La clé réside dans la cohérence globale du fichier.

En revanche, Google reste opaque sur le seuil de détection de ces patterns uniformes. À partir de quel pourcentage d'URLs avec la même date le système bascule-t-il en mode « ignore » ? [À vérifier] — aucune métrique précise n'est communiquée. Empiriquement, si 80% de vos URLs affichent la même <lastmod>, vous êtes probablement concerné.

Quels risques court-on à laisser des dates erronées ?

Le risque principal n'est pas une pénalité au sens classique, mais une perte d'efficacité du crawl. Si Google détecte que vos dates sont fantaisistes, il ne punira pas votre site — il ignorera simplement cette information. Vous perdez alors un levier d'optimisation du crawl budget.

Par contre, si vous mettez régulièrement à jour des pages stratégiques (fiches produits, articles de blog) sans refléter ces modifications dans le sitemap, vous retardez potentiellement leur réindexation. Sur des sites e-commerce avec des stocks ou prix volatils, c'est problématique. [À surveiller] : testez l'impact réel avec des logs Apache/Nginx pour mesurer le délai moyen entre modification réelle et recrawl Google.

Dans quels cas cette règle ne s'applique-t-elle pas pleinement ?

Pour les sites d'actualité ou médias, Google utilise d'autres signaux (balise <news>, fraîcheur du contenu, vitesse de publication) qui court-circuitent partiellement le sitemap classique. Un article publié il y a 2 heures sera crawlé rapidement même si le sitemap général n'a pas encore été mis à jour.

De même, pour des sites avec un crawl budget très large (autorité élevée, millions de pages crawlées quotidiennement), l'impact d'une <lastmod> défaillante est dilué. Google crawle de toute façon massivement. À l'inverse, un site de 500 pages avec un crawl budget serré doit absolument affûter ses signaux pour éviter le gaspillage.

Comment vérifier si vos dates sont exploitables par Google ?

Téléchargez votre sitemap XML et extrayez toutes les valeurs <lastmod>. Un script Python ou un tableur suffit. Si vous constatez que 90% des URLs partagent la même date, vous êtes dans le cas problématique. Google ignorera ces dates.

Ensuite, croisez avec vos logs serveur : comparez la date de dernière modification réelle (timestamp du fichier ou champ `modified` en base) avec celle du sitemap. Si l'écart dépasse régulièrement plusieurs semaines, votre CMS ne suit pas correctement les changements. Corrigez la logique de génération du sitemap avant de le soumettre.

Que faire si votre CMS génère des dates uniformes ?

Deux options : soit vous supprimez complètement la balise <lastmod> de votre template de sitemap, soit vous refactorez le générateur pour qu'il interroge la vraie date de modification en base. La première option est rapide et sans risque — Google se débrouillera avec ses propres signaux.

Si vous choisissez de conserver les dates, assurez-vous que votre CMS met à jour cette valeur à chaque modification réelle du contenu : texte, images, métadonnées, prix, stock. Un simple changement de catégorie ou d'URL canonique devrait aussi rafraîchir la <lastmod>. Attention aux faux positifs : ne touchez pas la date si seul un élément cosmétique (footer, sidebar) a changé sur toutes les pages.

Quelles erreurs éviter absolument ?

Ne régénérez pas votre sitemap quotidiennement en inscrivant la date du jour pour toutes les URLs — c'est le cas d'école que Google blackliste. Ne laissez pas non plus des dates figées dans le passé si vos pages évoluent vraiment : ça revient à mentir dans l'autre sens.

Évitez également de segmenter vos sitemaps par type de contenu (blog, produits, catégories) si chaque fichier présente le même syndrome de dates uniformes. Mieux vaut un seul sitemap sans <lastmod> que cinq sitemaps aux métadonnées douteuses. Enfin, si vous constatez que Google ignore vos dates malgré leur fiabilité, testez temporairement leur suppression pour mesurer l'impact sur la fréquence de crawl.

• Auditer votre sitemap actuel pour détecter les patterns de dates uniformes (script ou tableur)
• Croiser les <lastmod> avec les vrais timestamps de modification en base ou fichier
• Supprimer la balise <lastmod> si votre CMS ne peut garantir sa fiabilité
• Configurer le générateur de sitemap pour qu'il lise la vraie date de modification à chaque génération
• Éviter les régénérations quotidiennes mécaniques qui écrasent toutes les dates avec celle du jour
• Monitorer les logs serveur pour vérifier si Google recrawle effectivement les pages fraîchement modifiées