// OUTIL GRATUIT · VALIDATEUR DE SITEMAP XML
Validateur de sitemap XML
Collez votre sitemap.xml — ou déposez le fichier — et vous obtenez chaque erreur du protocole avec son numéro de ligne et sa correction : loc, lastmod, priority, changefreq, appariement des hreflang et limite des 50 000 URL. Gratuit, dans votre navigateur, sans rien envoyer.
Aussi enEnglishDeutschEspañolFrançais日本語한국어Português (Brasil)繁體中文
La validation se lance à la frappe. Vous pouvez aussi déposer un sitemap.xml ou un sitemap.xml.gz directement sur ce cadre : le fichier est lu et décompressé par votre navigateur, et n’en sort jamais.
Comment valider un sitemap XML
Trois étapes, toutes sur cette page. Le validateur lit le fichier que vous lui donnez — il ne va pas chercher votre site, alors collez le XML ou déposez le fichier plutôt que de saisir une URL.
- Collez ou déposez le fichier. Collez le XML dans le cadre de gauche, ou faites-y glisser sitemap.xml (ou sitemap.xml.gz — votre navigateur décompresse). La validation se lance aussitôt, à chaque frappe.
- Descendez la liste des constats. Chaque constat porte un numéro de ligne et la correction. Les erreurs sont ce qu’un robot rejettera ou lira de travers ; les avertissements sont du XML valide qui vous coûte tout de même quelque chose, comme un lastmod dans le futur ou une URL en double.
- Copiez le rapport, corrigez, revérifiez. Le panneau de droite contient un rapport en texte brut — type de fichier, marge avant les limites de 50 000 URL et 50 Mo, tous les constats — que vous pouvez coller dans un ticket. Corrigez, recollez le nouveau fichier, vérifiez qu’il revient propre.
Ce que ce validateur de sitemap vérifie
Il fait trois passes sur le fichier que vous collez. D’abord la bonne formation XML : balises non fermées ou mal imbriquées, un & non échappé dans une chaîne de requête, un préfixe d’espace de noms non déclaré — chacun signalé à la ligne où il se produit, plutôt que sous la forme d’une unique « erreur d’analyse ». Ensuite le protocole sitemaps.org : la racine est <urlset> ou <sitemapindex> dans l’espace de noms http://www.sitemaps.org/schemas/sitemap/0.9, chaque entrée porte exactement un <loc> absolu, <lastmod> est un vrai W3C Datetime, <priority> se situe entre 0.0 et 1.0, <changefreq> fait partie des sept mots autorisés. Enfin les limites et les renvois croisés : 50 000 URL, 50 Mo non compressés, URL en double, hôtes mélangés, et les annotations hreflang portées par xhtml:link, vérifiées dans les deux sens.
Un sitemap XML est un fichier publié à une URL fixe qui énumère les pages que vous voulez faire explorer : chacune sous forme d’élément <loc>, éventuellement avec <lastmod>, regroupées sous une racine <urlset> — ou sous un <sitemapindex> qui pointe vers plusieurs fichiers de ce type. C’est tout le protocole, et c’est toujours le schéma 0.9 sur lequel les moteurs se sont entendus. D’où l’intérêt de passer un sitemap au validateur exactement une fois par changement de générateur : les défaillances sont mécaniques, et chacune se corrige en une ligne dès que quelque chose vous dit laquelle.
| Règle | Niveau | Pourquoi |
|---|---|---|
XML bien formé : balises fermées et imbriquées, & écrit &, chaque préfixe déclaré | erreur | Un robot analyse le fichier avec un analyseur strict. Une seule esperluette nue et c’est tout le fichier qui est rejeté, pas seulement cette URL. |
Racine <urlset> ou <sitemapindex> déclarant l’espace de noms 0.9 | erreur | Sans l’espace de noms, ces éléments ne sont pas des éléments de sitemap : le fichier s’analyse et ne liste rien. |
Un <loc> par entrée, absolu en http(s), 2 048 caractères au plus | erreur | Un sitemap se lit hors contexte ; il n’y a aucune URL de base pour résoudre /tarifs/. |
<lastmod> au format W3C Datetime, avec fuseau s’il porte une heure | erreur | 01/09/2026 et 2026-09-01 10:00:00 sont rejetés tous les deux. C’est le seul indice que Google lit : cassé, c’est un champ perdu. |
<priority> de 0.0 à 1.0, <changefreq> dans la liste autorisée | erreur | 0,8 avec une virgule décimale et hebdomadaire au lieu de weekly : XML valide, sitemap invalide. |
| Seuls les éléments du protocole dans l’espace de noms sitemap ; les extensions déclarent le leur | erreur | <lastmodified> et <image:loc> sans xmlns:image sont les deux coquilles habituelles. |
| 50 000 entrées et 50 Mo non compressés par fichier | erreur | Au-delà de l’une ou l’autre limite, le fichier est rejeté en entier, pas tronqué. Le gzip n’y change rien. |
| hreflang : auto-référence, lien de retour, code valide, x-default | erreur | Une annotation à sens unique est écartée intégralement par Google, en silence. |
<loc> en double, hôtes mélangés, <lastmod> futur ou approximatif | avertissement | Du XML valide qui vous coûte quand même du budget d’exploration ou de la crédibilité. |
Présence même de <priority> ou <changefreq> | avertissement | La documentation de Google dit qu’il les ignore. Voir la section qui leur est consacrée plus bas. |
fr, fr-CA, fr-BE, fr-CH : quand une version régionale en vaut vraiment la peine
Le français est le cas d’école d’une langue parlée sur plusieurs marchés : France, Belgique, Suisse, Canada, Luxembourg, une bonne partie de l’Afrique de l’Ouest. D’où le réflexe de multiplier les codes régionaux dans le sitemap. Or fr tout seul couvre déjà tout le monde qui cherche en français : une région ne se justifie que si les pages disent réellement autre chose.
Et là, les cas ne se valent pas. fr-CA est le seul où la différence est souvent linguistique : la terminologie commerciale québécoise n’est pas celle de France (« courriel », « magasiner », « clavardage »), et le cadre linguistique du Québec pousse les sites commerciaux à publier un texte réellement distinct. Une version fr-CA qui serait la version française mot pour mot n’apporte donc rien. fr-BE et fr-CH, à l’inverse, diffèrent rarement par la langue et presque toujours par autre chose : TVA, prix en francs suisses, frais de port, mentions légales, service client. Si ces éléments sont sur la page, la version régionale a un sens ; s’il s’agit du même texte servi deux fois, vous venez d’ajouter deux nœuds à un graphe de liens de retour qu’il faudra maintenir sans rien gagner.
Côté syntaxe, deux pièges que ce validateur attrape et deux qu’il n’attrape pas — les seconds étant les plus coûteux :
fr_FRavec un tiret bas : erreur. C’est la forme locale de votre application, pas celle du hreflang, qui veut un trait d’union.fr-been minuscules : avertissement, avec la bonne graphie (fr-BE).capour « Canada » : rien du tout.caexiste bel et bien en ISO 639-1 — c’est le catalan. Le fichier passe, Google accepte l’annotation, et votre page québécoise est déclarée écrite pour des lecteurs catalans. Le Canada, c’estfr-CA: le pays ne va qu’après le trait d’union.fr-QCpour le Québec : rien du tout non plus. La forme est syntaxiquement correcte (deux lettres après le trait d’union), donc aucun validateur ne bronche — maisQCest un code de province, pas un code pays ISO 3166-1, et les moteurs ne le reconnaissent pas comme région. Le Québec n’a pas de code à lui : c’estfr-CA, et rien d’autre.
Ces deux dernières lignes sont la raison pour laquelle « mon sitemap est valide » ne veut pas dire « mon hreflang est juste ». Un code peut être formellement impeccable et désigner la mauvaise langue. Ce que le validateur fait à la place, et que personne d’autre ne fait sur un fichier collé : il construit le graphe et vérifie que chaque version se cite elle-même et que chaque paire se répond. Pour écrire l’annotation plutôt que la déboguer, le générateur de balises hreflang produit à partir d’un seul motif d’URL le bloc <link> du head et le bloc xhtml:link du sitemap : générez là-bas, collez ici, les liens de retour sont corrects par construction.
« priority » et « changefreq » : le malentendu qui dure
Il reste, dans à peu près tous les guides francophones sur les sitemaps, l’idée que <priority> sert à « indiquer à Google les pages les plus importantes du site » et <changefreq> à « lui dire à quelle fréquence revenir ». Les deux champs existent bien dans le schéma 0.9 — c’est ce qui rend l’idée crédible — mais la documentation de Google indique qu’il ignore l’un comme l’autre. Mettre 1.0 partout ne hiérarchise rien ; mettre daily sur une page annuelle ne fait pas revenir le robot plus vite. C’est pour cela que ce validateur émet un avertissement dès qu’il en voit un dans le fichier : non pas parce que c’est invalide, mais parce que c’est un champ que vous générez, versionnez et maintenez pour rien.
Et tant qu’ils sont là, ils continuent de coûter des erreurs. Comme leur valeur reste soumise au schéma, une valeur fausse invalide l’entrée alors même que le champ n’est pas lu. Les deux formes qui reviennent le plus dans les fichiers francophones :
<priority>0,8</priority>— la virgule décimale. Elle est correcte en français, elle ne l’est pas ici : le schéma veut un point. C’est une erreur, et elle est facile à produire quand la valeur est formatée par la locale du serveur.<changefreq>hebdomadaire</changefreq>— la traduction. Les sept valeurs (always,hourly,daily,weekly,monthly,yearly,never) sont des mots-clés du protocole et restent en anglais, au même titre qu’un nom de balise.
Le champ qui compte, lui, est <lastmod> : c’est le seul que Google dit utiliser, et il ne sert que s’il est exact. Une date de dernière modification recopiée depuis la date de génération du fichier — donc identique sur les 12 000 URL et remise à jour à chaque déploiement — ne vaut pas mieux qu’une absence de lastmod : le moteur compare la valeur à sa dernière exploration, et un fichier entier qui « change » tous les jours cesse d’être un signal. Mieux vaut aucune date qu’une date fausse. Le bouton Exemple erroné plus haut charge un fichier qui rassemble tout ce dont parle cette section : virgule décimale, changefreq traduit, date au format français, fr_FR, ca pour le Canada, et un lien de retour qui pointe vers une URL absente du fichier.
Pourquoi celui-ci prend un fichier collé et non une URL
Tous les autres validateurs de sitemap gratuits demandent une URL et vont la chercher depuis un serveur. Celui-ci tourne entièrement dans la page que vous regardez, et un navigateur n’a pas le droit de lire un fichier hébergé sur un autre domaine à moins que ce domaine ne l’autorise explicitement — la politique de même origine, appliquée sous forme de CORS. Presque aucun site n’envoie Access-Control-Allow-Origin sur son sitemap : un champ URL échouerait donc sur la quasi-totalité des adresses saisies. Plutôt que de livrer un champ qui échoue la plupart du temps, l’outil prend le fichier.
Ce qui couvre, au passage, les cas qu’un champ URL n’atteint pas du tout :
- Pas encore publié — le fichier que votre générateur vient d’écrire sur votre poste, avant le déploiement.
- Construit en CI — l’artefact du pipeline, vérifié avant même d’atteindre un hébergement.
- Derrière une authentification, un VPN ou un mot de passe de préproduction — un validateur qui télécharge récupère la page de connexion et la signale comme du XML cassé.
- Interne ou hors ligne — rien du fichier ne quitte votre machine : un sitemap que vous n’avez pas le droit de confier à un serveur tiers reste vérifiable.
Le prix est réel et mérite d’être dit : cet outil ne peut pas vous dire si https://votredomaine.fr/sitemap.xml renvoie effectivement un 200, si le robots.txt pointe dessus, ni si les URL qu’il contient sont vivantes. Il lit les octets que vous lui tendez. Pour vérifier un fichier publié, récupérez-le vous-même — curl -s https://votredomaine.fr/sitemap.xml, ou curl -s https://votredomaine.fr/sitemap.xml.gz | gunzip — et collez la sortie. À noter aussi : le google.com/ping?sitemap= que certains outils proposent encore a été abandonné en 2023 et ne fait plus rien. Ce qui marche aujourd’hui : une ligne Sitemap: dans le robots.txt, un envoi unique dans la Search Console et les Bing Webmaster Tools, et un <lastmod> exact. Tout ce qui vient après l’analyse est du travail serveur : c’est ce que fait clize seo check --domain votredomaine.fr, qui lit votre sitemap et votre propriété Search Console ensemble et vous montre les pages listées dans le fichier qui n’ont jamais obtenu la moindre impression. Dans la même couche lisible par les machines, deux voisins suivent la règle de cette page — générer depuis une source unique plutôt que corriger à la main : le validateur llms.txt et le générateur de schéma FAQ.
// Questions fréquentes
Que vérifie un validateur de sitemap XML ?
Trois choses. Que le fichier soit du XML bien formé — balises fermées et imbriquées, esperluettes échappées, préfixes d’espace de noms déclarés. Qu’il suive le protocole sitemaps.org — une racine <urlset> ou <sitemapindex> dans l’espace de noms 0.9, exactement un <loc> absolu par entrée, un W3C Datetime valide dans <lastmod>, <priority> entre 0.0 et 1.0 et <changefreq> issu de la liste autorisée. Et qu’il reste dans les limites tout en étant cohérent — moins de 50 000 URL et 50 Mo non compressés, aucune URL en double, et des versions hreflang qui se répondent.
Faut-il écrire fr, fr-FR ou fr-CA dans le hreflang ?
fr seul couvre tous ceux qui cherchent en français, et c’est le bon choix si vous n’avez qu’une version française. Ajoutez une région uniquement si les pages diffèrent réellement : fr-CA quand la terminologie québécoise et le contenu commercial ne sont pas ceux de France, fr-BE ou fr-CH quand la TVA, les prix ou les mentions légales changent. Une version régionale qui reproduit le même texte n’apporte rien et alourdit le graphe de liens de retour à maintenir.
Peut-on utiliser hreflang="ca" pour le Canada ou "fr-QC" pour le Québec ?
Non, et ce sont les deux erreurs que les validateurs ne détectent pas. ca existe en ISO 639-1 mais désigne le catalan, donc le fichier passe sans un mot alors que votre page est déclarée en catalan. fr-QC est syntaxiquement correct, donc aucun outil ne proteste, mais QC est un code de province, pas un code pays ISO 3166-1 : les moteurs ne le reconnaissent pas comme région. Le français du Canada s’écrit fr-CA, et le Québec n’a pas de code à lui.
À quoi sert vraiment <priority> dans un sitemap ?
À rien du côté de Google, qui indique dans sa documentation ignorer <priority> comme <changefreq>. Le champ existe dans le schéma 0.9, ce qui explique sa longévité dans les guides, mais lui donner une valeur ne hiérarchise pas vos pages. Et comme il reste soumis au schéma, une valeur fausse invalide l’entrée : 0,8 avec une virgule décimale est une erreur, alors même que le champ n’est pas lu. Le seul champ facultatif que Google dit utiliser est <lastmod>, à condition qu’il soit exact.
Pourquoi mon lastmod est-il refusé alors que la date est bonne ?
Presque toujours à cause de l’écriture, pas de la date. Sont valides AAAA-MM-JJ, ou AAAA-MM-JJThh:mm:ss avec un fuseau horaire. Le format 01/09/2026 est refusé, une espace à la place du T est refusée, et une heure sans fuseau l’est aussi. Si votre générateur écrit l’heure locale, le plus sûr est de passer en UTC avec un Z final, ou de retirer l’heure : une date seule est valide et suffisamment précise pour un signal d’exploration.
Peut-on valider un fichier d’index de sitemaps ?
Oui. Collez un fichier dont la racine est <sitemapindex> et le validateur bascule sur les règles d’index : chaque entrée doit être un <sitemap> avec un <loc> et au plus un <lastmod>, sans <priority>, <changefreq> ni éléments <url> mélangés. Il ne peut pas suivre les sitemaps enfants, puisqu’il ne télécharge jamais rien — validez chaque fichier enfant en le collant à son tour.
Mon fichier est-il envoyé quelque part, et pourquoi ne pas saisir une URL ?
Rien n’est envoyé. Le validateur est un script qui tourne dans votre navigateur : rien de ce que vous collez ou déposez ne quitte la page, il n’y a ni compte ni inscription, et une fois la page chargée, tout fonctionne hors ligne. C’est aussi pourquoi il ne peut pas aller chercher une URL : la politique de même origine empêche une page d’un domaine de lire un fichier d’un autre, sauf en-têtes CORS que presque aucun site n’envoie sur son sitemap. Récupérez le fichier avec curl et collez la sortie ; en échange, vous pouvez aussi vérifier des fichiers non publiés, construits en CI ou derrière une authentification.
Un fichier valide, c’est le plancher. Voyons maintenant ce qui a été indexé.
Vérifier votre propre site ne coûte rien : la commande lit votre sitemap et votre propriété Search Console ensemble, liste chaque page avec son statut HTTP et son état d’indexation réels, signale celles qui n’ont jamais obtenu une impression, et montre le trafic par source avec les moteurs IA comptés à part. Une commande depuis votre agent.
$ npm i -g @clize/clize && clize install $ clize seo check --domain votredomaine.fr[ Agent SEO by Clize → ]