Pour auditer un sitemap, comparez sa liste d'URL aux pages que vous souhaitez rendre indexables, puis vérifiez les réponses de ces adresses. Compter les lignes ne suffit pas : un fichier peut contenir le bon nombre d'URL tout en oubliant un dossier et en conservant des pages supprimées.
Définir l'ensemble attendu
Préparez un inventaire à partir des contenus publiés et des décisions éditoriales. Distinguez les pages publiques, les fichiers techniques, les brouillons et les routes d'erreur. Ce registre devient la référence à comparer avec le sitemap généré.
La présentation des sitemaps par Google décrit leur rôle dans la découverte des contenus. Un sitemap n'est ni une garantie d'exploration complète ni une preuve d'indexation. Gardez cette limite dans vos rapports de livraison.
Vérifier le fichier et ses sous-ensembles
Chargez le sitemap public, puis les fichiers qu'il référence lorsqu'il s'agit d'un index. Vérifiez qu'ils correspondent au bon domaine et qu'ils sont lisibles. Comparez ensuite les URL sans perdre les différences de chemin, de protocole ou de paramètres.
Relevez les doublons, les adresses inattendues et les pages absentes. Pour un petit site, un contrôle exhaustif est souvent possible. Pour un grand corpus, documentez ce qui est vérifié automatiquement et les échantillons examinés plus finement ; ne présentez pas un échantillon comme une validation de toutes les pages.
Exemple fictif : un dossier ajouté à une publication
Imaginons un site qui ajoute six guides à un nouveau dossier. Le build produit bien les pages, mais la configuration du sitemap ne prend en compte que les anciens dossiers. L'accueil permet de lire les guides ; le fichier soumis au moteur reste incomplet.
La comparaison d'ensembles doit faire apparaître les six adresses manquantes. Après correction, vérifiez qu'elles sont présentes une seule fois et que les anciennes pages sont toujours conservées. Un simple passage de trente à trente-six entrées serait insuffisant si certaines entrées correspondaient à de mauvaises adresses.
Ce cas fictif illustre une vérification de livraison. Le nombre de pages sert uniquement à décrire l'exercice et ne constitue pas une recommandation de taille de site.
Relier chaque URL à sa réponse publique
Contrôlez le statut HTTP, la canonical et les directives d'indexation des pages listées. Une URL qui redirige mérite d'être comparée à sa destination de référence. Une page exclue volontairement demande de relire la décision avec le guide sur robots.txt et noindex.
Après un changement d'adresses, reprenez le plan de redirections pour éviter de conserver uniquement les anciens chemins. Vérifiez aussi les données structurées des modèles : elles doivent parler des mêmes pages et de leurs contenus réels, sans que cette vérification remplace celle du sitemap.
Archivez le fichier observé et la liste des différences corrigées. Lors de la prochaine publication, vous pourrez détecter une régression sans reconstruire manuellement tout l'inventaire.
Questions fréquentes
Toutes les routes du serveur doivent-elles être listées ?
Non. Un endpoint technique, une page d'erreur ou un brouillon ne devient pas une page à indexer parce qu'il possède une adresse. Le sitemap doit suivre le corpus public souhaité.
Un sitemap accepté prouve-t-il que les pages sont indexées ?
Non. La lecture du fichier et le traitement des pages sont des observations différentes. Consultez les informations d'indexation disponibles sans confondre soumission et résultat.
Faut-il changer toutes les dates à chaque build ?
N'inventez pas une modification éditoriale. Si vous publiez des dates de mise à jour, elles doivent correspondre à une évolution pertinente des pages concernées, pas simplement au passage d'une commande de génération.
Sources
Documentation consultée lors de la relecture du 10 septembre 2026.