Pourquoi Google ignore-t-il les dates lastmod de votre sitemap XML ?

Que se passe-t-il concrètement quand toutes les dates sont identiques ?

Lorsque Google Search Console détecte qu'un sitemap XML affiche la même date de modification pour 100% des URLs, l'algorithme neutralise l'information. Techniquement, le sitemap reste valide et parsable, mais les signaux temporels disparaissent. Googlebot continue de lire le fichier pour identifier d'éventuelles nouvelles URLs à indexer, mais il n'accorde aucune priorité aux contenus marqués comme récemment modifiés.

Le problème vient souvent de scripts automatisés mal configurés : certains CMS ou plugins génèrent les sitemaps à la volée et appliquent systématiquement la date du jour à toutes les entrées. Cette pratique part d'une bonne intention — signaler de la fraîcheur — mais elle sabote le signal en le noyant dans le bruit. Google ne peut pas distinguer un article vraiment remanié d'une page statique qui n'a pas bougé depuis trois ans.

Les balises priority et changefreq sont-elles vraiment inutiles ?

Oui, et ça fait un moment que c'est documenté. La balise <priority> visait à indiquer l'importance relative d'une page au sein d'un site — de 0.0 à 1.0. La balise <changefreq> suggérait une fréquence de mise à jour (daily, weekly, monthly). Mais Google a publiquement confirmé qu'il ignore ces deux attributs dans la quasi-totalité des cas.

Pourquoi ? Parce que chaque webmaster assigne mécaniquement priority="1.0" à toutes ses pages importantes, ce qui revient à dire que tout est prioritaire — donc rien ne l'est. Même logique pour changefreq : les sites indiquent « daily » par défaut sans que le contenu bouge réellement. Le moteur a cessé de faire confiance à ces signaux auto-déclarés et préfère analyser lui-même la fréquence de modification via ses propres crawls successifs.

Qu'est-ce qu'un changement de contenu « majeur » aux yeux de Google ?

Google ne définit pas publiquement un seuil quantitatif précis — pas de « 30% de texte modifié » ou de nombre de mots minimal. En revanche, Mueller et d'autres porte-parole ont clarifié qu'il s'agit d'une modification substantielle du corps éditorial : réécriture d'un paragraphe entier, ajout de sections nouvelles, mise à jour de données chiffrées, refonte de la structure argumentative.

À l'inverse, ne comptent pas comme changements majeurs : le simple incrément d'un compteur de vues, l'ajout d'un commentaire utilisateur, la modification d'un footer ou d'une sidebar commune à tout le site, le changement d'un bouton CTA sans toucher au contenu. Ces micro-variations déclenchent souvent une regénération du sitemap avec une nouvelle date, alors que le contenu indexable reste identique.

• lastmod identique partout → Google désactive le signal temporel et se limite à la découverte d'URLs
• priority et changefreq → ignorés dans la plupart des configurations, signal devenu non fiable
• Changement majeur → modification substantielle du contenu éditorial indexable, pas un détail technique ou cosmétique
• Scripts automatisés → souvent responsables de l'écrasement systématique des dates avec la valeur du jour
• Audit du CMS → vérifier que le générateur de sitemap récupère bien les vraies dates de publication ou de dernière modification éditoriale depuis la base de données

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

Absolument. On observe depuis des années que les sites qui jouent la carte de la transparence — en renseignant uniquement les vraies dates de modification éditoriale — constatent un meilleur taux de crawl des pages récemment mises à jour. À l'inverse, les sites qui réinitialisent toutes les dates à J quotidiennement voient Googlebot espacer ses passages sur les contenus stables, puisqu'il ne peut plus faire confiance au sitemap pour détecter ce qui a réellement changé.

Un test classique consiste à auditer les logs serveur après avoir corrigé un sitemap pollué par des dates uniformes : dans les jours suivants, on voit le bot concentrer ses ressources sur les URLs dont la balise lastmod a effectivement évolué par rapport au crawl précédent. C'est un signal indirect mais mesurable que Google réactive la prise en compte de cette métadonnée une fois qu'elle redevient fiable.

Quelles nuances faut-il apporter à cette règle ?

Première nuance : Google parle d'un sitemap où toutes les URLs portent la même date. Si 95% de vos pages affichent des dates variables et cohérentes, mais que 5% portent accidentellement la date du jour (par exemple les pages de catégories régénérées automatiquement), le moteur ne coupe pas nécessairement le signal pour l'ensemble du fichier. Il dégrade simplement la confiance accordée au sitemap dans sa globalité. [À vérifier] : Google n'a jamais publié de seuil chiffré (« si plus de X% des URLs ont la même date, on ignore lastmod »), donc prudence sur les configurations mixtes.

Deuxième nuance : certains sites à très haute fréquence de publication — agrégateurs d'actualité, plateformes de contenu généré par les utilisateurs — peuvent légitimement voir une portion significative de leurs URLs modifiées quotidiennement. Dans ce cas, avoir beaucoup d'entrées datées du jour n'est pas suspect. Mais même là, il est rare que 100% des pages bougent simultanément : un bon sitemap devrait refléter la distribution réelle des mises à jour.

Faut-il pour autant abandonner les sitemaps XML ?

Non. Le sitemap reste un outil de découverte précieux, surtout pour les contenus profonds ou orphelins qui ne bénéficient pas de liens internes solides. Même si Google ignore lastmod/priority/changefreq, le simple fait de lister une URL accélère son indexation initiale. C'est particulièrement critique pour les gros sites e-commerce ou les médias qui publient des centaines de pages par jour.

Mais il faut arrêter de voir le sitemap comme un levier de priorisation du crawl si on n'y injecte pas de données fiables. Mieux vaut un sitemap minimaliste — juste <loc> et une vraie <lastmod> — qu'un fichier gonflé de métadonnées fantaisistes que le moteur apprendra à ignorer. Et si votre CMS ne permet pas de récupérer les vraies dates de modification, désactivez carrément la balise lastmod plutôt que de polluer le signal.

Que faut-il faire concrètement pour corriger un sitemap mal configuré ?

Première étape : auditer le générateur de sitemap. Identifie s'il s'agit d'un plugin WordPress (Yoast, RankMath, All in One SEO), d'un script custom, ou d'un module natif du CMS. Vérifie dans le code ou les paramètres si la balise <lastmod> est câblée sur un champ de base de données correspondant à la vraie date de modification éditoriale (post_modified, updated_at) ou si elle appelle systématiquement date(). Beaucoup de plugins offrent une option « use post modified date » qu'il suffit de cocher.

Deuxième étape : nettoyer les dates historiques aberrantes. Si ton site a accumulé pendant des mois des sitemaps avec lastmod uniformisé, Google a peut-être déjà désactivé le signal. Regénère le fichier avec les vraies dates, puis force une nouvelle soumission via Search Console (ou attends le prochain fetch automatique). Surveille les logs pour vérifier que Googlebot recommence à crawler prioritairement les URLs dont la date a changé depuis son dernier passage.

Quelles erreurs éviter lors de la refonte d'un sitemap ?

Ne pas confondre date de publication et date de modification. Certains CMS proposent deux champs : created_at et updated_at. Pour le sitemap, c'est updated_at qui compte — sauf si la page n'a jamais été modifiée, auquel cas les deux sont identiques. Évite aussi de déclencher une mise à jour de lastmod pour des changements triviaux : correction d'une faute de frappe isolée, ajout d'une balise alt manquante, modification du menu global. Ces micro-interventions ne justifient pas un nouveau signal de fraîcheur.

Autre piège classique : les sitemaps index qui pointent vers des sous-sitemaps générés à la volée. Si chaque sous-sitemap est recréé quotidiennement avec la date du jour pour toutes ses entrées, le problème remonte au niveau parent. Assure-toi que la logique de génération cascade correctement les vraies dates depuis la source de données jusqu'au fichier XML final.

Comment vérifier que mon sitemap est désormais exploité par Google ?

Première vérification : Search Console, rapport Sitemaps. Si Google détecte un problème de cohérence (toutes les dates identiques), il ne te le signalera pas explicitement comme erreur — le fichier reste valide au sens du protocole XML — mais tu peux croiser avec le rapport Couverture pour voir si les pages récemment modifiées sont effectivement recrawlées dans un délai court.

Deuxième vérification : analyse des logs serveur. Compare la fréquence de crawl avant et après correction du sitemap. Si Googlebot concentre ses ressources sur les URLs dont lastmod a évolué, c'est bon signe. Si le pattern de crawl reste inchangé, soit le moteur n'a pas encore refait confiance au signal, soit d'autres facteurs (budget de crawl saturé, contenus de faible qualité) limitent l'impact de la correction.

• Auditer le générateur de sitemap pour vérifier que <lastmod> reflète bien post_modified ou updated_at depuis la BDD
• Désactiver ou corriger les scripts qui écrasent systématiquement les dates avec date() ou la date du jour
• Exclure du sitemap les pages qui ne changent jamais, ou y injecter leur vraie date de publication initiale sans la modifier artificiellement
• Soumettre le sitemap corrigé via Search Console et surveiller le taux de crawl des URLs récemment mises à jour dans les logs
• Ne pas déclencher de mise à jour de lastmod pour des modifications cosmétiques (footer, sidebar, balises meta communes)
• Segmenter les sitemaps par type de contenu ou fréquence de mise à jour si le site mélange pages statiques et flux d'actualité à haute fréquence