Validateur de plan du site gratuit

Qu'est-ce qu'un sitemap.xml et pourquoi est-ce important ?

Un sitemap est un document XML structuré qui liste les URL d'un site web que vous souhaitez faire connaître aux moteurs de recherche. Il est servi depuis un chemin stable, presque toujours /sitemap.xml, et suit le Protocole Sitemap — une petite spécification publiée à l'origine par Google en 2005 et adoptée comme standard commun par Google, Yahoo et Microsoft un an plus tard. Le format est simple : un élément racine <urlset> contenant un élément <url> par page, avec des métadonnées optionnelles sur quand chaque URL a été modifiée pour la dernière fois, à quelle fréquence elle change, et comment elle se situe en priorité par rapport aux autres pages du même site.

L'objectif d'un sitemap est la découverte, pas le classement. Les moteurs de recherche explorent le web en suivant les liens de page en page. Sur un petit site avec des liens internes propres, chaque page est accessible depuis la page d'accueil en quelques clics, et les robots trouvent tout sans aide. Sur un grand site, sur un site avec une pagination profonde, sur un site avec des pages d'atterrissage isolées vers lesquelles aucun lien interne ne pointe, ou sur un site qui vient de publier du nouveau contenu, les robots peuvent prendre des jours ou des semaines à découvrir les URL via les liens seuls. Le sitemap résout ce problème en remettant au robot une liste complète d'emblée.

Les sitemaps ne garantissent pas l'indexation. Google l'a explicitement indiqué dans sa documentation depuis le lancement du protocole : une URL dans votre sitemap est un signal que vous souhaitez qu'elle soit indexée, pas une commande qui sera exécutée. Les pages de faible qualité, avec du contenu dupliqué ou des informations insuffisantes seront ignorées quelle que soit leur présence dans le sitemap. Ce que le sitemap change, c'est l'efficacité de l'exploration. Avec un sitemap, Google peut explorer vos pages nouvelles et mises à jour en premier, les prioriser selon le champ lastmod, et éviter de gaspiller des requêtes sur des URL obsolètes ou archivées.

Les sitemaps comptent aussi pour la longue traîne. Un site avec 100 000 pages produits, 5 000 articles de blog et 200 pages de catégories a trop d'URL pour qu'un système de liens internes expose chaque URL en quelques clics. Sans sitemap, le site dépend de l'exploration exploratoire de Googlebot pour trouver les URL profondes, ce qui fonctionne mais est lent. Avec un sitemap, chaque URL est immédiatement connue de Google, et le robot peut consacrer son budget aux vérifications de fraîcheur et à la qualité du contenu plutôt qu'à la découverte. Pour les sites e-commerce, les éditeurs d'actualités, les marketplaces et les sites à fort contenu, le sitemap n'est pas optionnel.

Comment utiliser ce vérificateur

Le vérificateur prend une URL de sitemap ou la racine d'un domaine et retourne un rapport structuré sur la validité, l'exhaustivité et l'accessibilité.

Étape 1 — Entrez l'URL du sitemap. Collez l'URL complète de votre sitemap, ou simplement le domaine — le vérificateur effectuera l'autodécouverte via robots.txt et essaiera les chemins courants comme /sitemap.xml, /sitemap_index.xml et /sitemap.xml.gz. Il suit également les fichiers sitemap-index automatiquement et parcourt chaque sitemap enfant à l'intérieur.

Étape 2 — Examinez le rapport de validité. Le vérificateur valide le XML selon le schéma du Protocole Sitemap, signale les valeurs lastmod malformées, vérifie les URL dépassant la limite de 2048 caractères, et confirme que le fichier est sous les limites absolues de 50 Mo non compressé et 50 000 URL. Chaque problème est affiché avec l'URL exacte ou le numéro de ligne qui l'a déclenché.

Étape 3 — Vérifiez l'accessibilité. Pour un échantillon d'URL du sitemap, le vérificateur effectue une requête HEAD et rapporte le code de réponse. Les URL qui retournent 404, 301, 302 ou 5xx dans votre sitemap sont du bruit qui gaspille le budget d'exploration ; le rapport les affiche groupées pour que vous puissiez les corriger ou les supprimer.

Le protocole sitemap en détail

Un sitemap minimal valide ressemble à ceci :

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-04-27T12:00:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/article</loc>
    <lastmod>2026-04-15</lastmod>
  </url>
</urlset>

Seul <loc> est obligatoire. Les trois autres champs optionnels sont <lastmod>, <changefreq> et <priority>, et la bonne pratique moderne traite chacun différemment.

Limites absolues et le modèle sitemap-index

Un seul fichier sitemap peut contenir au maximum 50 000 URL et doit être inférieur à 50 Mo non compressé. Ces limites font partie du protocole depuis son lancement et sont appliquées par tous les robots majeurs. Les fichiers dépassant la limite ne sont pas simplement tronqués — ils sont rejetés entièrement par Googlebot, qui signale alors une erreur dans Search Console. Pour un site avec plus d'URL que ce qui tient dans un seul fichier, le protocole définit un format sitemap-index qui liste plusieurs sitemaps enfants :

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
</sitemapindex>

L'index peut lister jusqu'à 50 000 sitemaps enfants, chacun contenant 50 000 URL, pour une limite théorique de 2,5 milliards d'URL sur le site. En pratique, organiser par type de contenu — pages, produits, articles de blog, tags, catégories — produit une structure maintenable qui permet aussi de régénérer uniquement le sous-sitemap modifié à chaque déploiement. La convention est de nommer l'index sitemap.xml ou sitemap_index.xml et les enfants avec des chemins descriptifs.

Précision de lastmod et quand Google lui fait confiance

Google a répété à plusieurs reprises qu'il utilise lastmod lorsque la valeur est précise, et qu'il la dévalue sur l'ensemble du sitemap lorsqu'elle semble peu fiable. Un site qui indique toujours la date du jour pour chaque URL signale une fraîcheur qui n'existe pas ; Google détecte le schéma et cesse de pondérer ce champ. Il en va de même pour les valeurs lastmod qui ne se mettent jamais à jour même lorsque le contenu change — l'absence de signal est elle-même un signal.

Utilisez le format datetime ISO 8601 complet, incluant le décalage de fuseau horaire : 2026-04-27T12:00:00+00:00. Le format date seule 2026-04-27 est valide et accepté, mais le format datetime est préféré pour les sites à haute fréquence où l'heure de la journée importe. Définissez lastmod sur le temps de modification réel du contenu de la page, pas sur l'heure de déploiement de votre application. Les pages qui n'ont pas changé doivent conserver leur ancienne valeur lastmod, même lorsque le reste du sitemap est régénéré.

changefreq et priority : largement ignorés

Les champs <changefreq> et <priority> ont été définis dans le protocole original pour donner aux propriétaires de sites un moyen d'exprimer à quelle fréquence une page change (always, hourly, daily, weekly, monthly, yearly, never) et une priorité relative au sein du site (un décimal entre 0,0 et 1,0). Google moderne ignore les deux. Le robot détermine la fréquence d'exploration à partir des schémas de changement observés et la priorité à partir de la qualité du contenu et du capital de liens, pas des déclarations dans le sitemap.

La recommandation pratique est d'omettre ces deux champs. Ils rendent le sitemap plus volumineux et plus complexe sans modifier le comportement des robots. La documentation de Bing suggère qu'il tient encore faiblement compte de changefreq, mais l'impact est suffisamment faible que maintenir des valeurs précises vaut rarement le coût d'ingénierie. Un sitemap propre avec juste <loc> et <lastmod> est la valeur par défaut moderne.

Autodécouverte via robots.txt vs soumission Search Console

Deux façons d'informer Google d'un sitemap : le déclarer dans robots.txt ou le soumettre via Search Console. Les deux fonctionnent, les deux sont recommandés, et les deux ensemble constituent la bonne pratique moderne.

User-agent: *
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

La déclaration dans robots.txt est lue par chaque robot bien configuré — Googlebot, Bingbot, DuckDuckBot, Yandex, et la plupart des outils SEO — sans aucune configuration par plateforme. La soumission via Search Console est spécifique à Google mais débloque les rapports d'indexation qui montrent combien d'URL du sitemap sont indexées, combien sont exclues, et pourquoi. Pour un site qui prend le SEO au sérieux, soumettez via Search Console pour la visibilité et déclarez dans robots.txt pour la portabilité.

Extensions sitemap image, vidéo et actualités

Le protocole de base dispose d'extensions pour le contenu image, vidéo et actualités. Les sitemaps image ajoutent un élément <image:image> listant les images de chaque page, ce qui aide Google à découvrir les images sur les pages rendues en JavaScript où les URL d'images ne sont pas dans le HTML initial. Les sitemaps vidéo ajoutent un élément <video:video> avec titre, description, miniature et durée, et restent la méthode canonique pour exposer des vidéos à Google Video. Les sitemaps actualités utilisent un élément <news:news> distinct avec une date de publication et l'espace de noms requis, et sont obligatoires pour l'inclusion dans Google Actualités.

Pour un site marketing ou de contenu typique, un sitemap d'URL simple couvre entièrement le cas d'utilisation. Les extensions ne valent la complexité que lorsque la découvrabilité des images, la vidéo ou l'inclusion dans les actualités est une source de trafic significative.

Erreurs courantes qui nuisent au SEO

404 et redirections dans le sitemap. Lister des URL qui retournent 404 ou redirigent vers une URL différente pollue le sitemap avec du bruit. Google les signale dans Search Console comme des erreurs de sitemap et peut dévaluer le reste du sitemap. Auditez le sitemap à chaque déploiement et supprimez les URL non-200. Les redirections doivent être remplacées par l'URL de destination.

Inclure des URL non canoniques. Les pages avec rel="canonical" pointant vers une URL différente ne doivent pas figurer dans le sitemap. Le sitemap est une liste de pages que vous souhaitez indexées ; les pages canonicalisées vers ailleurs sont des pages que vous avez explicitement demandé aux moteurs de recherche d'ignorer. Les inclure crée des signaux contradictoires.

lastmod toujours actuel. Définir lastmod à la date du jour pour chaque URL à chaque régénération indique à Google que le champ n'est pas fiable, et le robot cesse de le pondérer. Définissez lastmod à partir du temps de modification réel du contenu de la page, pas de l'heure de déploiement. Les pages qui n'ont pas changé doivent conserver leur lastmod précédent.

Sitemap bloqué par robots.txt. Une ligne Disallow: /sitemap.xml, ou un Disallow: /sitemap plus large qui correspond au fichier, empêche les robots de récupérer le sitemap. Testez toujours avec curl ou un vérificateur de sitemap après avoir modifié robots.txt pour confirmer que l'URL du sitemap est accessible.

Sous-sitemaps dans un sitemap-index retournant 404. Un sitemap-index qui liste dix sitemaps enfants mais dont seulement neuf se résolvent provoque le signalement du manquant comme erreur. Pire encore, si le schéma de chemin change entre les déploiements, chaque ancienne URL de sous-sitemap devient un 404 jusqu'à ce que l'index soit régénéré. Générez l'index depuis la même source de vérité que les enfants pour les maintenir synchronisés.

Mélanger les protocoles dans un sitemap. Un sitemap servi à https://example.com/sitemap.xml ne doit contenir que des URL en https://. Les URL en http:// mélangées sont traitées comme un hôte différent et ignorées par le processeur de sitemap de l'hôte canonique. Il en va de même pour l'incohérence www vs non-www : choisissez-en un et utilisez-le systématiquement dans le sitemap.

Oublier d'échapper les caractères spéciaux dans les URL. XML exige que &, <, >, " et ' soient échappés dans les valeurs d'attributs et d'éléments. Les URL avec des esperluettes brutes cassent le parseur XML, et l'ensemble du sitemap échoue à la validation. Générez les URL via une bibliothèque qui gère l'échappement plutôt que de concaténer des chaînes manuellement.

Cas limites dont personne ne parle

Un sitemap.xml servi avec le mauvais type de contenu casse certains robots. Le type de contenu correct est application/xml ou text/xml. Certains serveurs retournent text/plain ou text/html pour les fichiers .xml lorsque le type MIME n'est pas configuré, et Bingbot en particulier est connu pour refuser de telles réponses. Le vérificateur teste le type de contenu et le signale comme avertissement lorsqu'il ne correspond pas.

Les sitemaps compressés servis en .xml.gz économisent considérablement la bande passante — les sitemaps se compressent à 5-10 % de leur taille originale en raison de la forte répétition des préfixes d'URL. Google et Bing acceptent tous deux les sitemaps gzippés sans aucune configuration supplémentaire, et la limite de taille de fichier est mesurée par rapport à la taille non compressée. Le seul écueil est que certaines plateformes d'hébergement servent les fichiers .gz avec un encodage de contenu incorrect, amenant le robot à recevoir des octets gzip bruts qui échouent à l'analyse. Testez la version gzippée dans un navigateur ; si vous voyez des caractères binaires à la place du XML, la réponse manque l'en-tête Content-Encoding: gzip.