Aujourd’hui, si vous voulez augmenter vos chances qu’un sitemap XML soit pris en compte, il est toujours possible de « pinger » Google.
Comment faire ?
Et bien c’est simple, il suffit d’appeler cette url en précisant l’adresse de votre fichier sitemap en paramètre et le tour est joué:
https://www.google.com/ping?sitemap=L-URL-ABSOLUE-DE-VOTRE-SITEMAP-XML
exemple :
https://www.google.com/ping?sitemap=https://example.com/sitemap.xmlA quoi cela sert ?
Et bien à indiquer à Google que vous avez mis en ligne un nouveau fichier sitemap XML ou sérieusement mis à jour un fichier existant.
Bref, « pinger » Google consiste à « héler » le moteur de recherche en disant « eh ! J’ai de nouvelles urls à crawler, ce serait bien que tu télécharges ce sitemap et que tu crawles les urls qu’il contient sans attendre ».
Ce qui s’avère particulièrement utile quand Google ne crawle le contenu de vos sitemaps une fois tous les deux mois parce que votre contenu ne change jamais (en tout cas jusqu’à maintenant).
Ce « ping » est très facile à faire (il suffit d’entrer l’url dans un navigateur et d’appeler l’url et le tour est joué). Et ce système a été mis en place par Google il y’a 16 ans, en 2007.
Google : dans six mois, nous cesserons de supporter le « ping » pour les sitemaps !
Oui mais voila, Google a décidé de désactiver le système de ping dans six mois. Et propose d’utiliser l’attribut lastmod des sitemaps XML à la place.
Sauf que cette nouvelle méthode n’est pas aussi simple à utiliser, et que le support réel des lastmod par Google a été jusqu’ici … très limité, et assez peu fiable.
Google a annoncé ce changement dans un billet de blog daté du 26 juin 2023 :
https://developers.google.com/search/blog/2023/06/sitemaps-lastmod-ping?hl=fr
Pourquoi un tel changement ?
Bing avait déjà abandonné ce système il y’a quelques mois. Fabrice Canel avait notamment révélé qu’il avait décidé d’arrêter de supporter les pings de Sitemaps parce que c’était surtout utilisé par des spammers. La faille, c’est que le ping permet de soumettre des sitemaps de manière anonyme. C’est idéal pour faire crawler rapidement des pages ajoutées sur un wordpress hacké par exemple.
L’autre raison c’est que c’était une fonctionnalité méconnue, donc sous utilisée.
Par contre Bing supporte parfaitement l’attribut lastmod, et « normalement » (en faisant confiance aux déclarations du webmaster) ce qui permet de se passer du ping sans problème.
Côté Google, c’est moins simple.
Google supporte-t’il l’attribut lastmod aujourd’hui ?
Rappelons que Google est à l’origine du format des sitemaps XML : c’est donc Google qui a décidé de créer les attributs « priority », « changefreq », et … « lastmod ». Des attributs qu’il a très vite renoncé à exploiter. Totalement pour priority et changefreq, et partiellement pour l’attribut lastmod.
En 2015, un porte parole avait révélé que le support de lastmod par Google était plutôt limité.
La balise lastmod est facultative dans les sitemaps et, dans la plupart des cas, elle est ignorée par les moteurs de recherche, car le travail de mise à jour des valeurs par les webmasters est affreux.
Gary Illyes, 2015, sur Stack Overflow
En théorie, Google peut tenir compte des informations contenues dans les « lastmod ». Mais dès que Google détecte que l’attribut lastmod est modifié sans que le contenu soit réellement mis à jour => Google n’en tient plus compte, et c’est compliqué de le faire changer d’avis.
Ce comportement est expliqué dans cette page support de Google :
https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap?hl=en#general-guidelines
Comment obtenir que Google crawle un nouveau sitemap XML ou de nouvelles urls dans un sitemap XML en 2024 ?
Le problème avec cette gestion des « lastmod » par Google, c’est que si vous n’avez pas une gestion parfaite des valeurs de lastmod, les urls nouvelles seront crawlées… quand Google en aura envie, ce qui peut repousser l’échéance de plusieurs semaines !
Google a donc fait un peu de comm sur son billet de blog pour « adoucir » l’impact du changement, mais la réalité c’est qu’ils n’ont (pour le moment) pas changé de politique concernant les « lastmod »
Donc, toute erreur dans la gestion des valeurs de lastmod déclenche l’arrêt de la prise en compte de l’attribut lastmod. Sauf que c’est facile de générer ce genre d’erreur. Et qu’en plus Google ne veut pas de « petites modifications ». Enfin, tout dépend de ce qu’on appelle des petites modifications :
- changement de liens => ok, mettre à jour les lastmod
- changement dans les données structurées => ok, mettre à jour les lastmod
- changement de texte, en dehors du « texte principal » => ko, ne pas changer la valeur du lastmod
Google propose de ne renseigner les lastmod que pour les urls pour lesquelles la date du dernier changement est connue de manière sûre. Ce serait un bon conseil si c’était facile à faire. En pratique, dès qu’un site à plusieurs milliers d’urls, on génère un sitemap automatiquement avec un script. Et ces scripts le plus souvent génèrent des valeurs d’attributs systématiquement, ou jamais. Si on veut sortir de ce mode « tout ou rien », il faut modifier le script. Si c’est une extension d’un CMS ou d’une plateforme, c’est rarement simple et pas toujours une bonne idée.
Utiliser l’attribut « lastmod » n’est donc pas un solution de substitution équivalent au « ping » de sitemaps. Mais alors pas du tout.
Et comme Google ne prévoit pas d’voluer vers une prise en compte plus systématique des valeurs de lastmod, on va perdre quelque chose d’utile avec la fin de l’url de ping.
C’est bien dommage…
(Eh, messieurs de Mountain View, quand vous finissez par suivre la position de Bing sur un sujet, suivez les jusqu’au bout, ce sera mieux pour tout le monde. Je dis ça, je dis rien).