Plan de site XML : 7 erreurs fréquentes à corriger absolument

Un fichier sitemap qui s'ouvre sans problème dans le navigateur, mais dont Google ne visite qu'une URL sur trois. C'est la question qu'on me pose le plus souvent quand une page met deux semaines à apparaître dans les résultats de recherche. Et dans neuf cas sur dix, le coupable n'est pas le contenu, ni le maillage interne. C'est le plan de site XML lui-même.

Pas parce qu'il est absent. Parce qu'il contient une erreur silencieuse que personne n'a vue en le générant. Voici les plus fréquentes, comment les repérer, et surtout comment les corriger sans casser ce qui fonctionnait.

Les erreurs les plus fréquentes d'un plan de site XML (et pourquoi elles passent inaperçues)

Un plan de site XML a un rôle unique : indiquer à Google quelles URL existent, pour qu'il puisse les découvrir et les indexer. Il ne garantit rien. Il accélère, ou il ralentit.

Le problème structurel, c'est que la plupart des erreurs ne génèrent aucune alerte. Le fichier se valide. Il se lit. Le navigateur affiche du XML propre. Et pourtant les URL annoncées ne correspondent pas à celles que Google va réellement demander.

Ce que vérifie la validation, et ce qu'elle ne voit pas

Un validateur XML vérifie la syntaxe, le respect du schéma, la présence des balises obligatoires. Il vous dira si <loc> est bien fermé. Il ne vous dira jamais que l'URL à l'intérieur pointe vers une page en noindex, ou qu'un paramètre de tri a disparu de l'adresse.

J'ai vu ça sur un catalogue de 4 200 fiches produits. Le sitemap passait tous les contrôles. Une fiche sur cinq renvoyait une 404 en cliquant dessus depuis le fichier. Personne ne l'avait remarqué parce que personne ne clique jamais sur l'URL d'un sitemap.

Quel est l'impact réel d'un sitemap mal configuré ?

Trois conséquences, dans cet ordre de gravité.

• Le budget de crawl part sur des pages inutiles. Google répartit sa capacité d'exploration d'un site. Chaque URL morte qu'il demande consomme du temps qu'une page utile n'a pas eu.
• L'indexation ralentit. Une page qui n'apparaît pas dans le sitemap met plus de temps à être découverte, surtout sur un site récent ou à faible notoriété.
• Vous recevez de mauvais signaux. Si vous listez des pages que vous avez explicitement mises en noindex, vous vous contredisez dans les deux documents. Google tranche en général contre le sitemap.

Sur le catalogue dont je parlais, corriger les 840 URL mortes a fait passer le nombre de pages explorées quotidiennement de 300 à 900 environ. Même site, même contenu, même autorité. Uniquement le sitemap.

Le piège technique que presque personne ne détecte : double échappement et encodage des URL

Voilà l'erreur la plus vicieuse de la liste. Et franchement, je suis tombé dedans moi-même en 2023 sur un site multilingue.

Le double échappement, ou quand le fichier « se lit » mais annonce de mauvaises URL

En XML, certains caractères doivent être échappés dans une URL : & devient &, < devient <. Jusque-là, tout va bien.

Le problème arrive quand l'URL elle-même contient déjà un paramètre encodé. Si votre générateur encode le composant URL puis échappe le résultat pour le XML, sans se soucier de l'ordre, vous obtenez un double échappement. Le fichier est valide. Il se lit. Sauf que l'adresse annoncée n'est plus celle de votre page.

Exemple concret : une page de liste avec un filtre couleur. L'URL réelle est /produits?couleur=rouge&tri=prix. Un générateur mal réglé va produire /produits?couleur=rouge&tri=prix dans le <loc>. Google lit littéralement &, obtient une adresse qui n'existe pas, et note une erreur 404 dans votre rapport.

Résultat : un lot de 400 URL déclarées en échec, et un après-midi passé à chercher un bug qui n'existe pas dans le site.

La recette pas-à-pas pour trouver la première divergence

La méthode qui fonctionne : ne testez jamais le sitemap « en théorie ». Testez le fichier réellement généré, en local, avant qu'il ne soit déployé.

1. Générez le sitemap sur votre environnement local.
2. Extrayez les URL du <loc> avec un simple script ou en copiant une dizaine de lignes.
3. Pour chacune, collez-la dans la barre d'adresse de votre site local et observez le code de réponse.
4. Dès qu'une URL renvoie autre chose que 200, vous avez trouvé la première divergence. Notez son rang dans le fichier.
5. Remontez au générateur : la cause est presque toujours à la même ligne de code, une fonction d'échappement qui s'applique une fois de trop.

Sur les neuf URL que j'ai testées la dernière fois, la cinquième était la fautive. Toutes les suivantes étaient corrompues de la même façon. Cinq minutes de travail, trois heures de gagnées.

Réparer l'affichage ne veut pas dire préserver la sélection

Le piège du correctif : vous changez la fonction d'échappement, le XML redevient propre, l'URL s'affiche correctement. Sauf que vous venez de modifier la façon dont sont construits les paramètres de filtre. Et là, la pagination ou le tri ne fonctionne plus côté site.

Un correctif sur un sitemap se teste toujours en aval : après la correction du fichier, revérifiez que la page réelle répond bien, avec ses filtres, sa pagination et son tri intacts.

Les erreurs fonctionnelles : lister les mauvaises pages, en oublier les bonnes

Une fois le problème d'encodage réglé, il reste la question du contenu. Quelles URL avez-vous le droit de mettre dans ce fichier ?

Les pages qu'il ne faut jamais lister

Un sitemap est une promesse : « voici des pages que je veux voir indexées ». Toute URL de cette liste qui contredit cette promesse crée du bruit.

• Les pages marquées en noindex : inutile de les annoncer, vous vous contredisez.
• Les pages en noindex parce qu'elles sont vides, en construction ou bloquées par un mot de passe.
• Les URL de recherche interne et de tri, qui génèrent des milliers de variantes de la même page.
• Les redirections 301 : listez la cible, jamais la source.

Un cas que je rencontre régulièrement : la page panier ou la page de confirmation de commande indexée parce qu'elle figurait dans le sitemap généré automatiquement.

Le cas des sites à pagination et des gros volumes

C'est là que les dégâts se concentrent. Un site qui découpe son catalogue en 200 pages de liste peut générer 200 URL de pagination dans le sitemap. Si chaque page de liste décline en plus des filtres de tri et de couleur, vous multipliez sans le vouloir par 30.

À cette échelle, un sitemap trop bavard coûte davantage qu'il ne rapporte : Google explore des variantes quasi identiques au lieu des fiches produits. La règle que j'applique : une seule URL canonique par contenu réel. Les variantes filtrées n'ont pas leur place dans le fichier.

Faut-il un seul sitemap ou plusieurs fichiers ?

Un sitemap plafonne à 50 000 URL et 50 Mo. Au-delà, il faut un index qui pointe vers plusieurs fichiers. C'est une contrainte technique, pas un choix éditorial.

Configuration	Quand l'utiliser	Risque principal
Fichier unique	Moins de quelques milliers d'URL	Faible, facile à contrôler
Index + fichiers thématiques	Gros catalogue, plusieurs sections	Un fichier oublié dans l'index, invisibilité d'une section entière
Sitemap généré automatiquement	Tout site dynamique	Double échappement, listage de pages noindex
Sitemap manuel	Petit site statique	Oubli de mise à jour, URL mortes au fil du temps

Le point de vigilance porte sur le sitemap généré automatiquement : c'est le plus pratique et le plus dangereux, parce qu'il produit des erreurs que personne ne relit.

Comment corriger et vérifier un sitemap, concrètement

Une fois l'erreur identifiée, le travail de correction demande de la méthode. Trois étapes, dans cet ordre.

Soumettre et lire le rapport, sans surinterpréter

La Search Console signale les URL en erreur, mais elle ne vous dit jamais quelle ligne du fichier est fautive ni pourquoi. Elle vous donne le symptôme, pas le diagnostic.

Concrètement : soumettez le sitemap, attendez quelques jours, ouvrez le rapport d'état. Si vous voyez « impossible de récupérer » sur certaines URL, revenez à la recette pas-à-pas ci-dessus. Si vous voyez des erreurs de type 404, vérifiez en priorité le double échappement et les redirections.

Ne corrigez jamais en aveugle juste pour faire taire une alerte. Une erreur signalée est souvent la conséquence visible d'un problème situé ailleurs.

La checklist avant chaque déploiement

1. Validez la syntaxe du fichier (n'importe quel validateur XML fait l'affaire).
2. Testez dix URL du fichier sur l'environnement local, en regardant le code de réponse.
3. Vérifiez qu'aucune URL de la liste ne renvoie de 301.
4. Comparez la liste avec celle des pages en noindex : le croisement doit être vide.
5. Contrôlez que les URL paginées et filtrées n'y figurent pas.
6. Confirmez que le fichier est bien référencé dans le robots.txt et pointe vers la bonne version du site (HTTP ou HTTPS, avec ou sans www).

Ces six contrôles prennent dix minutes sur un site de taille moyenne. Ils évitent des semaines de perte d'exploration.

Ce qui reste à regarder, même quand tout paraît propre

Il y a une question que je me pose encore régulièrement : un sitemap « propre » est-il forcément utile ? Pas forcément. Sur un site bien maillé et de faible volume, le fichier n'accélère presque rien, parce que Google trouve les pages par les liens internes. Sur un gros site, il devient indispensable.

Le vrai indicateur n'est pas le nombre d'URL listées. C'est le rapport entre les pages que vous voulez voir indexées et celles que Google explore effectivement. Quand cet écart se creuse, ce n'est presque jamais la faute de votre contenu. C'est un fichier qui annonce des adresses mortes, dupliquées ou contradictoires — et qui n'a jamais été testé sur sa version réellement générée.

La prochaine fois que vous ouvrez un sitemap dans le navigateur, cliquez sur une URL au hasard. Juste une. Vous serez surpris de ce que vous trouverez.