Sitemap XML : quelles URLs inclure et comment le vérifier ?

9 min de lecture

Un sitemap XML doit lister les URLs finales, canoniques et destinées à l’indexation, pas toutes les adresses produites par votre site. Pour le vérifier, croisez votre inventaire avec les réponses HTTP, les directives d’indexation et les données de modification. La soumission vient ensuite, lorsque le fichier décrit correctement les pages que vous souhaitez rendre visibles.

À retenir : le sitemap est un indice de découverte, pas une garantie d’indexation.^[21] Retenez les versions utiles et canoniques, renseignez lastmod seulement à partir d’un changement significatif, puis vérifiez le traitement du fichier et l’état des pages prioritaires.

Définir le périmètre du sitemap XML

Google précise qu’une soumission ne garantit ni le téléchargement du sitemap ni son utilisation pour explorer les URLs.^[21] Distinguez donc le fichier disponible, la page accessible et la page effectivement indexée. Même indexée, une page n’apparaît pas nécessairement dans chaque recherche.^[22]

Le périmètre pertinent comprend les contenus que vous voulez proposer dans les résultats : pages de services, catégories éditoriales substantielles ou ressources publiques. Il ne correspond ni à l’historique des URLs ni à l’ensemble des routes techniques du CMS.

Nous proposons une règle d’admission opérationnelle : retenir une URL finale accessible, indexable, cohérente avec la version canonique retenue et utile au public visé. Ce filtre est une méthode de contrôle, pas une nouvelle obligation du protocole.

Construire un inventaire canonique exploitable

Partez des contenus publiés dans le CMS, puis rapprochez-les d’une exploration du site et du sitemap existant. Repérez les pages manquantes, les anciennes routes et les variantes de campagne.

Pour chaque URL candidate, consignez :

• l’adresse absolue et son type de page ;
• le statut HTTP et la destination d’une éventuelle redirection ;
• la canonique déclarée, les directives noindex et les restrictions d’exploration ;
• l’utilité du contenu, son responsable et son état de publication ;
• la date du dernier changement significatif, avec sa justification.

Lorsque plusieurs URLs donnent accès au même contenu, Google recommande de choisir celle que vous préférez et de l’inclure plutôt que toutes ses variantes.^[21] Ne supprimez toutefois pas aveuglément chaque URL contenant un paramètre : analysez sa fonction.

Fixez également vos conventions d’adresse : domaine, protocole, chemin et forme retenue par le site. Conservez séparément l’URL rencontrée et l’URL finale. Vous pourrez ainsi expliquer pourquoi une ancienne route disparaît du fichier sans perdre la trace de son remplacement.

Décider avec une table d’admission remplie

Exemple explicitement fictif : le site atelier.example publie des services et conserve des URLs de campagnes. Les chemins ci-dessous sont abrégés pour la lecture ; les entrées XML devront utiliser des adresses absolues.

La dernière ligne demande une décision métier et technique : la page est-elle un doublon volontaire, ou sa canonique provient-elle d’un mauvais réglage de modèle ? N’exportez pas une contradiction simplement parce que le CMS fournit une URL. Les autres contrôles d’accès restent nécessaires.

Ajoutez au registre la justification, le responsable de correction et la preuve attendue. Pour une redirection, cette preuve sera la réponse de la destination ; pour une exclusion volontaire, la décision de conserver noindex. « Suspendre » signifie attendre cet arbitrage, pas supprimer automatiquement la page du site.

Contrôler les réponses avant de produire le fichier

Appliquez les contrôles dans cet ordre, avant chaque mise en service d’un générateur ou après une modification de modèle :

1. Résolution HTTP. Interrogez l’adresse exacte. Pour votre règle d’admission, attendez une réponse directe 200. Remplacez les URLs redirigées par leur destination admissible ; écartez les pages supprimées et traitez les erreurs serveur.
2. Accès et indexabilité. Vérifiez l’accès sans connexion, les règles robots.txt, la balise robots et l’en-tête X-Robots-Tag. Un contenu destiné à l’indexation ne doit pas être exporté avec une exclusion contradictoire.
3. Cohérence canonique. Comparez l’adresse finale et la canonique déclarée. Si elles divergent, vérifiez le contenu et la configuration avant de décider quelle version conserver.
4. Utilité réelle. Ouvrez la page : un code satisfaisant ne prouve pas qu’une offre existe encore ni que le contenu principal est présent.

Contrôlez toutes les URLs automatiquement pour les réponses et directives récupérables, puis examinez manuellement les exceptions. Un contrôle limité à la page d’accueil ne valide pas les autres modèles.

Archivez l’export testé, les réponses HTTP et les directives relevées. Une correction est techniquement validée quand le nouveau contrôle confirme le comportement attendu. Cela ne constitue pas une preuve d’indexation par Google.

Produire un XML propre et un lastmod crédible

Le fichier doit être encodé en UTF-8 et contenir des URLs absolues. Les valeurs XML doivent être échappées : un caractère & dans une adresse devient & dans le fichier.^[21] Testez le document avec un parseur XML, pas seulement en l’ouvrant dans un navigateur.

Voici une entrée utilisable pour notre exemple fictif, sans date de modification non justifiée :

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://atelier.example/services/audit/</loc>
  </url>
</urlset>

Google utilise lastmod lorsque cette valeur est régulièrement exacte et vérifiable. Elle doit refléter un changement significatif du contenu principal, des données structurées ou des liens, pas une simple mise à jour du copyright.^[21]

Reliez donc cette valeur à un événement documenté : révision d’une offre, modification substantielle d’une ressource ou changement de liens pertinents. La date d’export du sitemap et la date d’enregistrement automatique du CMS ne suffisent pas à établir ce changement.

Si votre outil ne distingue pas une vraie modification d’une opération technique, mieux vaut omettre lastmod que diffuser une date trompeuse. Gardez la trace de l’événement retenu pour pouvoir comparer le champ au contenu. Google ignore par ailleurs priority et changefreq : ne les utilisez pas comme leviers de priorité d’indexation.^[21]

Organiser la soumission sans automatisme aveugle

Faites générer le fichier depuis l’inventaire validé, plutôt qu’en empilant plusieurs extensions dont les règles se contredisent. Vérifiez que publication, retrait et changement d’adresse mettent à jour les entrées concernées.

Un sitemap est limité à 50 Mo non compressés ou 50 000 URLs. Au-delà, il faut le découper ; un index de sitemaps peut regrouper les fichiers.^[21] Sans atteindre ces limites, des sous-sitemaps par modèle, comme les services et les ressources, peuvent faciliter votre suivi si leurs critères d’admission restent identiques. Ce découpage est un choix d’organisation, pas une garantie SEO.

Placez de préférence le fichier à la racine. Sans soumission dans Search Console, sa portée se limite aux descendants de son répertoire parent.^[21] Vérifiez aussi que l’URL du fichier renvoie bien du XML, et non une page HTML de connexion ou d’erreur.

Soumettez ensuite le sitemap ou son index dans le rapport Sitemaps de Search Console. Vous pouvez également indiquer son adresse dans robots.txt, par exemple Sitemap: https://atelier.example/sitemap.xml.^[21] Consignez le chemin soumis et la configuration du générateur.

Valider les corrections avec les bons rapports

Commencez par le rapport Sitemaps : Google y indique ses accès au fichier et les erreurs potentielles de traitement.^[21] Une erreur XML appelle une correction du document ; un fichier inaccessible appelle un contrôle de l’hébergement ou des restrictions d’accès. Resoumettre le même fichier sans corriger la cause ne remplace pas ces vérifications.

Consultez ensuite le rapport d’indexation des pages. Analysez les motifs, pas seulement le total des URLs non indexées : les doublons et les exclusions intentionnelles ne nécessitent pas tous une correction. Les totaux peuvent aussi différer de votre inventaire.^[22]

Pour une page de service prioritaire, utilisez l’inspection d’URL et comparez l’état connu de Google avec le test en direct. Celui-ci renseigne sur l’accès actuel ; il ne prouve pas que la page est déjà indexée.^[22] Pour approfondir ce cas, consultez notre diagnostic d’une page absente de Google.

Relevez aussi la canonique retenue par Google dans l’inspection d’URL.^[22] Si elle diffère de votre préférence, vérifiez les doublons et les liens internes avant de modifier le générateur. Le sitemap exprime une préférence, il n’impose pas votre choix.^[21]

Conservez une preuve de clôture : fichier corrigé, contrôle XML réussi, réponses des URLs concernées et état du rapport après traitement. Si une page admissible reste absente, ouvrez un diagnostic ciblé plutôt qu’une succession de soumissions. Aucun délai d’indexation ne peut être garanti.

Questions fréquentes

Une page orpheline peut-elle figurer dans le sitemap ?

Oui, si elle remplit vos critères d’admission. Mais son inscription ne remplace pas une navigation utile : cherchez pourquoi aucun lien interne ne la dessert. Pour une offre publique, ajoutez un lien contextuel depuis une page pertinente et vérifiez que les visiteurs peuvent la trouver. Le sitemap complète cette découverte, sans résoudre à lui seul l’isolement éditorial.

Faut-il retirer une URL après une panne temporaire ?

Pas automatiquement. Pour une URL déjà admise, distinguez une indisponibilité passagère d’un retrait durable. Notez l’incident, vérifiez le rétablissement de la réponse attendue et évitez de transformer cette panne en exclusion permanente. Ne modifiez pas lastmod pour signaler une simple remise en ligne sans changement de contenu. Réexaminez l’admission si l’offre ou son adresse change réellement.

Le retrait du sitemap suffit-il à cacher une page privée ?

Non. Google peut découvrir une adresse par d’autres liens ; son absence du sitemap n’interdit pas l’indexation.^[22] Pour un contenu confidentiel, utilisez un contrôle d’accès adapté, pas le sitemap comme protection. Une page publique que vous souhaitez exclure des résultats doit porter une directive noindex lisible par le robot. N’exportez jamais des URLs contenant des jetons d’accès ou des données personnelles.

Conclusion : valider avant de soumettre

Votre prochaine action : reprenez la table d’admission et contrôlez une page de service, sa variante de campagne et une ancienne adresse redirigée. Corrigez les règles du générateur, puis validez le fichier avant de le soumettre. Si le CMS ou les modèles produisent des signaux contradictoires, vous pouvez solliciter nos services web et SEO pour cadrer les contrôles et les corrections nécessaires.

Sources

• Build and Submit a Sitemap | Google Search Central  |  Documentation  |  Google for Developers (consulté le 2026-10-08)
• Page indexing report - Search Console Help (consulté le 2026-10-08)