0

Validateur de Sitemap.xml — Vérificateur de conformité réelle au protocole

Collez ou téléversez un fichier sitemap.xml (ou un index de sitemap) et validez-le par rapport au véritable protocole sitemaps.org : élément racine et espace de noms, URL <loc> absolues, limites documentées de 50 000 URL / 50 Mo, <lastmod>, <priority>, <changefreq> — plus un histogramme de fraîcheur et une détection des URL en double.

🔒 Entièrement traité dans votre navigateur — rien de ce que vous saisissez ici n'est jamais téléchargé.

🗺️

Glissez-déposez un fichier ici ou cliquez pour sélectionner

ou cliquez pour parcourir — un seul fichier .xml

Traitement en cours... 0%
Analyse du XML
Vérification des règles du protocole sitemap
Analyse des URL
Terminé

Résultat

Un fichier sitemap.xml peut être un XML parfaitement bien formé tout en étant un sitemap cassé : un espace de noms xmlns manquant, une URL <loc> relative, une <priority> à « 1,5 », ou un <changefreq> à « Daily » au lieu de « daily » passeront tous un validateur XML générique avec succès, alors qu'ils échoueront silencieusement face au protocole sitemap réel qu'attendent Google, Bing et tous les autres consommateurs du fichier. Cet outil analyse votre sitemap collé ou téléversé avec le DOMParser natif du navigateur et le vérifie par rapport aux règles officielles publiées sur sitemaps.org : l'élément racine doit être <urlset> pour un sitemap standard ou <sitemapindex> pour un index de sitemap (détection automatique), idéalement déclaré avec l'espace de noms exact http://www.sitemaps.org/schemas/sitemap/0.9, et chaque <url> (ou <sitemap>, dans un fichier d'index) doit contenir une balise <loc> qui correspond à une véritable URL absolue en http ou https.

Au-delà de la structure, le protocole documente également des limites strictes et des formats de champ précis que cet outil vérifie champ par champ. Un fichier sitemap ne doit pas lister plus de 50 000 URL et ne doit pas dépasser 50 Mo non compressé — des limites qui s'appliquent aussi aux fichiers d'index de sitemap, en comptant les entrées <sitemap> au lieu des entrées <url> — et cet outil mesure votre contenu réellement collé ou téléversé par rapport à ces deux critères. Chaque <lastmod>, si elle est présente, est vérifiée par rapport aux formats de date W3C-Datetime réels que la spécification accepte : une date simple (AAAA-MM-JJ) ou un horodatage complet avec les heures, les minutes, les secondes optionnelles et un indicateur de fuseau horaire obligatoire. Chaque <priority>, si elle est présente, doit être un nombre décimal entre 0,0 et 1,0, et chaque <changefreq> doit être exactement l'une des sept valeurs définies par la spécification — always, hourly, daily, weekly, monthly, yearly, never — et non un synonyme plausible. Chaque violation signale le numéro d'entrée spécifique et sa valeur réelle, limité à 50 contrevenants affichés par règle avec une mention « +N more » afin que le rapport reste lisible même pour un sitemap proche de la limite d'URL.

Deux vérifications vont au-delà de ce qu'exige le protocole écrit mais détectent des problèmes réels et fréquents : un histogramme de fraîcheur des <lastmod> regroupe chaque date de dernière modification valide par mois afin que vous puissiez voir en un coup d'œil si le contenu d'un site est vraiment maintenu à jour ou si la plupart des URL portent un horodatage obsolète datant de plusieurs années, et un détecteur de <loc> en double signale toute URL listée plus d'une fois dans le même fichier — un effet secondaire fréquent des générateurs de sitemap qui fusionnent plusieurs sources sans dédoublonnage. Tout s'exécute en local : l'analyse, les vérifications des règles et l'histogramme sont entièrement calculés dans votre navigateur à partir du texte que vous avez collé ou du fichier que vous avez téléversé via l'API File, rien n'est récupéré ni envoyé vers un serveur, et aucune URL individuelle de votre sitemap n'est jamais requêtée ni explorée — cet outil vérifie le document sitemap lui-même, pas si les pages qu'il liste existent réellement ou renvoient un code 200 OK.