Sitemap.xml Validator — Vérificateur de conformité du protocole réel
Collez ou téléchargez un sitemap.xml (ou un index de plan de site) 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> - ainsi qu'un histogramme de fraîcheur et une détection d'URL en double.
Résultat
Un fichier sitemap.xml peut être parfaitement bien formé en XML tout en restant un plan de site défectueux : un espace de noms xmlns manquant, une URL <loc> relative, une <priority> de "1,5" ou un <changefreq> de "Daily" au lieu de "quotidiennement" passeront tous par un validateur XML générique tout en échouant discrètement au protocole de plan de site réel attendu par Google, Bing et tous les autres consommateurs du fichier. Cet outil analyse votre plan de site collé ou téléchargé avec le DOMParser natif du navigateur et le vérifie par rapport aux règles réelles publiées sur sitemaps.org : l'élément racine doit être <urlset> pour un plan de site standard ou <sitemapindex> pour un index de plan de site (détecté automatiquement), 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 index file) doit contenir un <loc> qui se résout en une véritable URL http/https absolue.
Au-delà de la structure, le protocole documente également des limites strictes et des formats de champs précis que cet outil vérifie champ par champ. Un seul fichier de plan de site ne doit pas répertorier plus de 50 000 URL et ne doit pas dépasser 50 Mo non compressés – des limites qui s'appliquent également aux fichiers d'index de plan de site, en comptant les entrées <sitemap> au lieu des entrées <url> – et cet outil mesure votre contenu réellement collé/téléchargé par rapport aux deux. Chaque <lastmod>, s'il est présent, est vérifié par rapport aux formats datetime W3C réels acceptés par la spécification : une date nue (AAAA-MM-JJ) ou un horodatage complet avec des heures, des minutes, des secondes facultatives et un indicateur de fuseau horaire obligatoire. Chaque <priority>, s'il est présent, doit être une valeur décimale comprise entre 0,0 et 1,0, et chaque <changefreq> doit être exactement l'une des sept valeurs définies par la spécification - toujours, horaire, quotidien, hebdomadaire, mensuel, annuel, jamais - ce qui n'est pas un synonyme plausible. Chaque violation indique le numéro d'entrée spécifique et sa valeur réelle, plafonné à 50 contrevenants affichés par règle avec une note "+N plus" afin que le rapport reste lisible même sur un plan de site proche de la limite d'URL.
Deux vérifications vont au-delà de ce que le protocole écrit exige, mais détectent des problèmes réels et courants : un histogramme de fraîcheur <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 réellement tenu à jour ou si la plupart des URL portent un horodatage obsolète d'il y a des années, et un détecteur de doublons <loc> signale toute URL répertoriée plus d'une fois dans le même fichier - un effet secondaire fréquent des générateurs de plan de site qui fusionnent plusieurs sources sans déduplication. Tout s'exécute localement : l'analyse, la vérification des règles et l'histogramme sont tous calculés dans votre navigateur à partir du texte que vous avez collé ou du fichier que vous avez téléchargé via l'API File, rien n'est récupéré ou téléchargé sur un serveur, et aucune URL individuelle dans votre plan de site n'est jamais demandée ou explorée - cet outil vérifie le document de plan de site lui-même, et non si les pages qu'il répertorie existent réellement ou renvoient 200 OK.