Un sitemap XML ne contrôle ni le crawl ni l’indexation. Google le rappelle explicitement : soumettre un plan de site ne garantit ni le téléchargement du fichier, ni l’exploration des URL, ni leur prise en compte dans l’index. Le sitemap est un signal déclaratif, pas une instruction. Comprendre cette distinction change la manière dont on le construit, on le maintient et on l’intègre dans une stratégie de référencement.
Balise lastmod dans le sitemap XML : ce que Google exploite réellement
La majorité des sitemaps en production affichent des dates lastmod identiques sur toutes les URL, ou des dates correspondant à la génération du fichier. Ces deux cas sont ignorés par Google. La balise lastmod n’a de valeur que si elle reflète une modification substantielle et vérifiable du contenu principal.
Ce qui constitue une modification significative : un changement du corps de texte, une mise à jour des données structurées, un ajout ou une suppression de liens internes. En revanche, modifier l’année dans un copyright ou régénérer le fichier sans toucher au contenu ne qualifie pas.
Nous recommandons un audit régulier du sitemap pour vérifier la cohérence entre les dates lastmod et les modifications réelles. Un CMS qui met à jour lastmod à chaque sauvegarde (même cosmétique) produit du bruit. Mieux vaut conditionner la mise à jour de cette balise à un diff réel du contenu rendu. Vous pouvez consulter le plan du site Référencement Qualitatif pour observer un exemple de structure propre avec des dates cohérentes.
Les balises changefreq et priority sont devenues obsolètes dans la pratique. Google ne leur accorde plus de poids mesurable. Continuer aux renseigner n’est pas nuisible, mais y consacrer du temps d’optimisation est improductif. Seules l’URL et la valeur lastmod (quand elle est fiable) comptent.
Sitemap XML et IndexNow : complémentarité pour le crawl Bing
Bing recommande explicitement de combiner le sitemap avec le protocole IndexNow. Le sitemap fournit une couverture persistante de l’ensemble des URL. IndexNow, lui, transmet en temps quasi réel les ajouts, mises à jour ou suppressions individuelles.
Cette combinaison prend tout son sens sur les sites à contenu dynamique : catalogues e-commerce avec variations de prix ou de stock, annuaires mis à jour quotidiennement, sites d’actualité. Le sitemap reste la base de référence, IndexNow accélère la prise en compte des changements ponctuels.
- Le sitemap couvre l’inventaire complet des URL canoniques du site, y compris les pages rarement modifiées
- IndexNow notifie Bing (et les moteurs compatibles) d’un changement spécifique sans attendre le prochain crawl du sitemap
- Les deux mécanismes sont complémentaires : l’un ne remplace pas l’autre, et les maintenir en parallèle réduit le délai d’indexation
Côté implémentation, IndexNow nécessite une clé API hébergée à la racine du site et un appel HTTP à chaque publication ou modification. La plupart des CMS disposent de plugins compatibles.
Segmentation du sitemap pour les sites à grand volume de pages
Un sitemap unique contenant plusieurs dizaines de milliers d’URL pose deux problèmes. Le fichier devient lourd à télécharger pour les robots, et il noie les pages stratégiques dans la masse. La segmentation par type de contenu (articles, produits, catégories, pages statiques) via un sitemap index permet de hiérarchiser les fichiers soumis.
Nous observons un gain concret lorsque les sitemaps segmentés sont associés à un nettoyage des URL non canoniques. Inclure dans le sitemap des URL redirigées, des pages en noindex ou des variantes de paramètres revient à envoyer un signal contradictoire. Le sitemap doit refléter exactement les pages que vous souhaitez voir indexées, rien de plus.
Critères de filtrage avant inclusion dans le sitemap
- La page renvoie un code HTTP 200 et n’est pas bloquée par le robots.txt
- La page porte une balise canonical auto-référente (canonical pointant vers elle-même)
- La page n’est pas en noindex et n’est pas orpheline (au moins un lien interne pointe vers elle)
- La page contient du contenu indexable suffisant (pas une coquille vide ou un template non rempli)
Automatiser cette vérification dans le pipeline de génération du sitemap évite l’accumulation d’URL mortes. Certains outils de crawl permettent de croiser le sitemap avec l’état réel du site et de signaler les incohérences.
Soumission du sitemap dans Google Search Console : erreurs fréquentes
Soumettre un sitemap via Google Search Console reste la méthode la plus directe pour signaler son existence. L’erreur la plus courante consiste à soumettre le fichier une fois, puis à ne jamais vérifier le rapport de couverture associé.
Le rapport de couverture du sitemap dans la Search Console indique combien d’URL soumises sont effectivement indexées, combien sont exclues, et pour quelle raison. Un écart significatif entre URL soumises et URL indexées signale un problème de qualité : contenu dupliqué, pages trop fines, erreurs de crawl, ou canonical mal configurés.
Autre piège : déclarer le sitemap dans le robots.txt avec une URL incorrecte (protocole HTTP au lieu de HTTPS, sous-domaine erroné). Le fichier robots.txt doit pointer vers l’URL exacte du sitemap, accessible sans redirection.
Fréquence de vérification recommandée
Sur un site publiant plusieurs contenus par semaine, un contrôle mensuel du rapport de couverture suffit pour détecter les dérives. Sur un site plus statique, un audit trimestriel reste pertinent. L’objectif n’est pas de soumettre plus souvent le sitemap, mais de s’assurer que ce qu’il déclare correspond à ce que Google constate lors du crawl.
Le plan de site reste un outil de communication entre votre site et les moteurs de recherche. Sa valeur dépend entièrement de la rigueur avec laquelle il est maintenu. Un sitemap obsolète ou incohérent n’aide pas le référencement, il le brouille.
