John Mueller a répondu sur Bluesky à une question consacrée à une technique observée sur un site de grande taille. Search Advocate chez Google, il intervient régulièrement sur le crawl, l’indexation et le fonctionnement des sitemaps.
Un horodatage crée une nouvelle URL de sitemap
La méthode consiste à ajouter un paramètre daté à l’URL de chaque sitemap enfant déclaré dans l’index principal. Une adresse peut par exemple passer de sitemap-produits.xml?v=1788393600 à une nouvelle valeur le lendemain.
Le fichier reste identique, mais son adresse change. Le moteur reçoit donc une nouvelle URL chaque jour, au lieu d’une information signalant la modification réelle du sitemap.
Cette technique vient du cache busting. Sur une feuille CSS ou un fichier JavaScript, le changement de paramètre permet de contourner une copie en cache après une mise à jour. Le navigateur demande alors la nouvelle version du fichier.
Son application aux sitemaps poursuit un autre objectif. Elle cherche à provoquer un téléchargement quotidien par les moteurs, même lorsque les fichiers et les pages qu’ils contiennent n’ont pas changé.
Les paramètres d’URL peuvent désigner différentes versions d’une même ressource. Sur des catalogues volumineux, leur création automatique peut rapidement multiplier le nombre d’adresses rencontrées par les robots.
John Mueller recommande des URL stables
Dans son échange sur Bluesky, John Mueller qualifie cette pratique de mauvaise idée. Il explique qu’elle indique aux moteurs que l’adresse de référence du fichier change constamment.
Il rappelle l’importance de conserver des URL propres et stables. Cette stabilité concerne le traitement des fichiers par les moteurs, mais aussi leur observation par les équipes qui administrent le site.
Lorsque chaque version quotidienne possède une adresse différente, le suivi devient aussi fragmenté. Les journaux serveur, les outils de crawl et les rapports internes peuvent enregistrer une succession d’URL pour un fichier dont le contenu reste identique.
lastmod doit correspondre à une modification réelle
Le protocole prévoit déjà un élément destiné à communiquer une date de mise à jour. Son rôle dépend de l’endroit où il apparaît.
Dans un index de sitemaps, <lastmod> indique la date de modification du sitemap enfant concerné. Cette information peut aider Google à planifier la lecture des différents fichiers.
Dans un sitemap XML, la balise associée à une page doit refléter la date réelle de modification de cette URL. Google cite notamment les changements apportés au contenu principal, aux données structurées ou aux liens.
Une simple modification de la date de copyright ne constitue pas une modification significative du contenu. De la même manière, attribuer chaque jour une nouvelle date à des pages inchangées ne fournit pas une information exacte.
La documentation officielle de Google précise que <lastmod> est utilisé lorsque ses valeurs restent cohérentes et peuvent être vérifiées. Google ignore en revanche les éléments <priority> et <changefreq>.
La soumission du sitemap reste une indication. Elle ne garantit ni son téléchargement, ni le crawl des URL, ni leur indexation. Le rapport Sitemaps de Search Console permet de consulter la dernière lecture du fichier et les éventuelles erreurs de traitement. La méthode prévue repose donc sur un signal fiable et vérifiable, sans modifier artificiellement l’adresse du sitemap.
