Faut-il encore remplir la priorité et la fréquence dans vos sitemaps XML ?

Pourquoi Google ignore-t-il ces balises pourtant standards du protocole sitemap ?

La norme sitemap.xml inclut historiquement trois attributs facultatifs : priority (0.0 à 1.0), changefreq (always, hourly, daily, etc.) et lastmod (date de dernière modification). Ces balises étaient censées guider les moteurs sur l'importance relative des pages et leur rythme de mise à jour.

Dans les faits, Google a constaté un taux d'abus massif. Des milliers de sites assignaient priority=1.0 à toutes leurs pages, ou déclaraient changefreq=daily alors que le contenu restait figé pendant des mois. L'algorithme a donc appris à ignorer ces signaux auto-déclarés peu fiables pour se concentrer sur des indicateurs qu'il observe lui-même : fréquence réelle de modification du contenu, volume de crawl alloué au domaine, et popularité des URLs.

Que reste-t-il comme signal exploitable dans un sitemap ?

La balise <lastmod> est le seul élément que Google utilise encore activement. Elle indique la date de dernière modification effective d'une page. Si cette date est récente et cohérente avec ce que Googlebot observe lors du crawl, elle peut accélérer la réindexation d'une URL mise à jour.

Attention : Google croise cette donnée avec sa propre analyse du contenu. Si vous déclarez lastmod=hier mais que le HTML n'a pas bougé d'un pixel, le signal perd toute crédibilité. La cohérence entre déclaration et réalité est capitale — un sitemap qui ment érode la confiance du crawler.

Dois-je supprimer ces balises de mes sitemaps existants ?

Non, ce n'est pas nécessaire. Google les ignore simplement, elles ne nuisent pas. En revanche, évitez de passer du temps à les optimiser, ajuster, ou à construire des systèmes complexes pour calculer des priorités dynamiques. C'est du travail pour rien.

Si vous générez vos sitemaps via un CMS ou un script, vous pouvez soit retirer ces balises pour alléger le fichier et accélérer son parsing, soit les laisser avec des valeurs par défaut (priority=0.5, changefreq=weekly). L'essentiel est de ne plus y investir d'énergie et de vous concentrer sur lastmod.

• Priority et changefreq sont ignorés par Google — ils ne servent plus à rien en pratique.
• Lastmod reste le seul signal exploité, à condition qu'il soit fiable et cohérent avec le contenu réel.
• Évitez d'abuser de lastmod : déclarer une date récente sur un contenu inchangé dégrade la confiance du crawler.
• Concentrez-vous sur la qualité : un sitemap propre, à jour, sans URLs orphelines ou 404, vaut mieux qu'un sitemap bourré de balises inutiles.
• L'allègement du fichier peut accélérer son parsing si votre site génère des sitemaps volumineux (dizaines de milliers d'URLs).

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

Oui, et depuis longtemps. Les SEO expérimentés ont remarqué dès le début des années 2010 que manipuler priority ou changefreq ne changeait strictement rien au comportement de crawl. Les tests en conditions réelles — sites avec priority=1.0 vs sites avec priority=0.1 sur pages identiques — ne montraient aucune différence mesurable de fréquence de visite ou de vitesse d'indexation.

Mueller enfonce ici une porte ouverte, mais c'est utile : trop de CMS et de plugins continuent de proposer des interfaces élaborées pour « optimiser » ces balises. Autant clarifier officiellement que c'est du temps perdu. Ce qui compte, c'est la stratégie de contenu et la capacité à maintenir des dates de modification précises et honnêtes.

Quelles nuances faut-il apporter à cette affirmation ?

Google n'est pas le seul moteur. Bing, par exemple, a historiquement déclaré prendre en compte changefreq dans certains scénarios (sites d'actualité, flux à forte vélocité). Difficile de savoir si c'est encore d'actualité, mais si vous ciblez un trafic multicanal, conserver ces balises peut avoir un intérêt marginal. [À vérifier] — aucune donnée publique récente ne confirme l'impact réel chez Bing.

Autre point : lastmod reste un signal faible. Il n'accélère la réindexation que si le budget crawl est déjà disponible et que la page a un historique de mises à jour fréquentes. Sur un site de 10 000 pages crawlées une fois par mois, afficher lastmod=hier ne déclenchera pas miraculeusement un recrawl sous 24h. Le crawl budget réel reste déterminé par l'autorité du domaine, la profondeur des URLs et l'activité globale du site.

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

Si vous utilisez un sitemap pour un moteur vertical ou un agrégateur tiers (flux produits e-commerce, syndication de contenu, API de recherche interne), ces balises peuvent encore jouer un rôle. Certains parsers tiers respectent les conventions du protocole sitemap à la lettre, notamment pour prioriser l'ordre de traitement dans une file d'attente.

Dans ces contextes B2B ou techniques — hors Google — il peut être pertinent de maintenir une logique cohérente dans priority et changefreq. Mais pour le SEO Google classique, c'est inutile. Distinguez bien les usages : un sitemap destiné au crawl Google n'a pas forcément la même structure qu'un sitemap destiné à alimenter une plateforme tierce.

Que faut-il faire concrètement dès maintenant ?

Auditez vos sitemaps actuels. Si vous dépensez du temps développeur ou si votre CMS exécute des calculs complexes pour ajuster priority/changefreq, arrêtez. Simplifiez la génération : liste d'URLs + lastmod fiable, c'est tout. Cela réduit la charge serveur et accélère la génération des fichiers.

Concentrez-vous sur la cohérence de lastmod. Vérifiez que la date remonte bien à la dernière modification éditoriale significative, pas à un changement mineur (balise meta, tracking, widget latéral). Si votre CMS n'offre pas cette granularité, adaptez le code ou utilisez un champ custom pour tracer les vraies mises à jour.

Quelles erreurs éviter absolument ?

Ne mentez pas sur lastmod pour forcer un recrawl. Google détecte l'écart entre la date déclarée et le contenu réel, et cela dégrade la confiance accordée à votre domaine. À terme, le crawler peut même ignorer complètement vos balises lastmod si elles sont systématiquement fausses.

Évitez également de générer des sitemaps surchargés : trop d'URLs (au-delà de 50 000 par fichier), URLs orphelines, redirections, 404. Un sitemap propre et léger — même sans priority/changefreq — sera toujours plus efficace qu'un sitemap obèse bourré de signaux parasites.

Comment vérifier que mon sitemap est optimal ?

Analysez les rapports de Search Console : section Sitemaps, onglet "Pages découvertes". Google vous indique combien d'URLs ont été lues, combien indexées. Si l'écart est important, le problème n'est probablement pas le sitemap mais la qualité des pages ou le budget crawl alloué au domaine.

Testez la cohérence de lastmod : crawlez votre propre site avec Screaming Frog ou OnCrawl, extrayez les dates de modification HTTP (Last-Modified header) et comparez-les aux dates déclarées dans le sitemap. Les divergences flagrantes révèlent un bug de génération qu'il faut corriger en priorité.

• Supprimez ou ignorez les balises priority et changefreq dans vos processus d'optimisation — elles ne servent plus.
• Assurez-vous que lastmod reflète la dernière modification éditoriale substantielle du contenu principal.
• Éliminez les URLs orphelines, 404, et redirections de vos sitemaps — seul le contenu indexable doit y figurer.
• Vérifiez la cohérence entre lastmod dans le sitemap et les en-têtes HTTP Last-Modified renvoyés par le serveur.
• Analysez les rapports Search Console pour détecter les écarts entre URLs découvertes et URLs indexées.
• Simplifiez la génération de vos sitemaps pour réduire la charge serveur et accélérer le parsing côté Google.