Corriger les erreurs de sitemap XML : le guide complet

La plupart des erreurs de sitemap XML se ramènent à une poignée de causes : un namespace incorrect, des caractères non échappés dans les URL, des dates lastmod mal formatées, un fichier trop volumineux, ou une URL de sitemap qui renvoie autre chose que du XML. Chacune se corrige en quelques minutes une fois identifiée. Ce guide les passe toutes en revue.

1. Namespace incorrect ou manquant

C'est la première chose qu'un parseur vérifie, et l'erreur la plus brutale : si l'attribut xmlns de la balise racine n'est pas exactement celui du protocole, la plupart des outils rejettent le fichier entier. La déclaration correcte est :

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

Les variantes fautives classiques : une faute de frappe dans l'URL du namespace, l'ancien namespace 0.84 hérité d'un vieux générateur, ou un https:// glissé à la place du http://. Le namespace est un identifiant, pas un lien : il doit être copié à l'identique, caractère par caractère. Reprenez la ligne ci-dessus telle quelle et le problème disparaît.

2. Caractères non échappés dans les URL

Un sitemap est d'abord un document XML, et cinq caractères y sont réservés : l'esperluette, les chevrons, le guillemet double et l'apostrophe. Le coupable le plus fréquent est l'esperluette des paramètres d'URL : une seule esperluette brute suffit à provoquer une erreur de parsing qui invalide tout le fichier.

<!-- Invalide -->
<loc>https://example.com/page?a=1&b=2</loc>

<!-- Valide -->
<loc>https://example.com/page?a=1&amp;b=2</loc>

La correction durable : échappez au moment de générer le fichier, pas à la main. Toute bibliothèque XML digne de ce nom le fait automatiquement ; si vos sitemaps sont assemblés par concaténation de chaînes, c'est le moment d'arrêter.

3. URL relatives ou sans schéma

Chaque <loc> doit contenir une URL absolue complète, schéma compris : https://example.com/page/. Les chemins relatifs (/page/), les URL sans schéma (//example.com/page/) et les noms d'hôte nus sont invalides. Le protocole ne laisse aucune place à l'interprétation : le robot doit pouvoir requêter l'URL telle quelle, sans rien deviner.

4. Dates lastmod invalides ou dans le futur

<lastmod> n'accepte que le format de date W3C : 2026-07-16, ou avec l'heure, 2026-07-16T09:30:00+00:00. Les formats nationaux comme 16/07/2026, les timestamps Unix et les dates en toutes lettres sont invalides. Deuxième piège : les dates dans le futur. Elles trahissent presque toujours un générateur qui écrit la date de génération du fichier plutôt que la date de modification réelle de la page. Google précise qu'il n'utilise lastmod que lorsqu'il est constamment fiable : des dates fantaisistes le conduisent à ignorer le champ pour tout le site.

5. Plus de 50 000 URL ou plus de 50 Mo

Le protocole limite chaque fichier à 50 000 URL et 50 Mo non compressé. Au-delà, il faut découper : plusieurs fichiers sitemap-1.xml, sitemap-2.xml, etc., listés dans un fichier d'index. La plupart des CMS et générateurs le font automatiquement une fois la limite franchie ; si le vôtre ne le fait pas, notre guide des index de sitemaps détaille la marche à suivre, exemple XML compris.

6. L'URL du sitemap renvoie une 404, une redirection ou du HTML

Avant même de parser quoi que ce soit, le robot doit obtenir le fichier : une réponse HTTP 200 avec un contenu XML. Trois échecs reviennent sans cesse. Le fichier n'existe plus (404), souvent après une migration qui a changé son chemin. L'URL redirige, parfois en chaîne : chaque saut est un risque, et une redirection qui aboutit sur une page d'erreur est fatale. Ou le serveur renvoie du HTML — page d'erreur personnalisée, page de connexion, écran anti-bot — déguisé en sitemap.xml. Testez l'URL dans une fenêtre de navigation privée, puis dans le validateur : le diagnostic indique le code HTTP et le type de contenu réellement reçus.

7. URL sur le mauvais hôte

Les URL listées doivent appartenir au même hôte que celui qui sert le sitemap : même sous-domaine (www ou non-www) et même schéma (https). Un sitemap servi sur https://www.example.com/sitemap.xml qui liste des URL en http://example.com/ verra une grande partie de ses entrées ignorées. Alignez tout sur la version canonique du site, celle vers laquelle convergent vos redirections. La seule exception prévue par le protocole : un sitemap déclaré dans le robots.txt de l'hôte concerné peut lister des URL de cet hôte.

8. Pages bloquées par robots.txt ou en noindex

Un sitemap dit « explorez ceci » ; un robots.txt qui bloque ces mêmes URL, ou une balise noindex posée dessus, dit exactement l'inverse. Les moteurs reçoivent des signaux contradictoires et Search Console signale les URL concernées une par une. La règle est simple : le sitemap ne doit lister que des pages canoniques, indexables et accessibles. Retirez-en tout ce que vous bloquez volontairement.

9. « Couldn't fetch » dans Google Search Console

Ce statut vague recouvre plusieurs réalités : l'URL soumise est fausse (une faute de frappe suffit), le serveur bloque le user-agent de Google ou répond trop lentement, le fichier lui-même est bloqué par robots.txt, ou le sitemap vient d'être soumis et Google n'est simplement pas encore passé. Vérifiez d'abord que l'URL s'ouvre dans un navigateur en fenêtre privée, validez ensuite le fichier ; si tout est vert, laissez passer 24 à 48 heures avant de conclure à un vrai problème.

Tableau récapitulatif : symptôme, cause, correction

Vérifiez, corrigez, revérifiez

La méthode la plus rapide reste de faire lire votre fichier par un outil qui applique le protocole à la lettre. Notre validateur de sitemap XML détecte chacune des erreurs de ce guide, avec le numéro d'entrée concerné et la correction correspondante. Pour la référence officielle, le protocole complet est documenté sur sitemaps.org. Corrigez, revalidez, puis resoumettez le fichier dans Search Console : le rapport se met à jour à la prochaine lecture.