Un client m'appelle un mardi matin, paniqué. Son site marchand a perdu 40 % de trafic organique en trois semaines. Première chose que je regarde : Search Console. Le sitemap soumis deux ans plus tôt était marqué « Impossible de lire le sitemap ». Personne n'avait touché au fichier depuis. Sauf que le serveur avait migré, et une règle de réécriture renvoyait désormais une page 404 en HTML sur /sitemap.xml. Google lisait du HTML là où il attendait du XML. Tout le reste du diagnostic a découlé de là.
Ce genre d'incident résume pourquoi un plan de site XML n'est pas un fichier qu'on génère une fois pour ne plus y penser. C'est un contrat technique entre votre site et les moteurs de recherche. Mal rédigé, il ne sert à rien. Cassé, il peut coûter cher.
Points clés à retenir
- Un sitemap XML liste les URL que vous voulez voir indexées, avec des métadonnées facultatives — il n'impose rien à Google, il suggère.
- Plafond technique : 50 000 URL et 50 Mo non compressés par fichier. Au-delà, il faut un index de sitemaps.
- Google ignore
priorityetchangefreqdepuis des années. Seullastmodcompte, et uniquement s'il est fiable. - Déclarer le sitemap dans
robots.txtet le soumettre dans Search Console sont deux gestes complémentaires, pas redondants. - Un sitemap ne compense jamais un mauvais maillage interne. C'est un filet de sécurité, pas une stratégie.
À quoi sert vraiment un plan de site XML (et à quoi il ne sert pas)
Un sitemap est un fichier XML qui énumère les URL de votre site. Point. Le protocole, publié par Google et repris par Bing, Yandex et consorts, définit un vocabulaire de balises simple : <urlset>, <url>, <loc>, et trois balises facultatives dont je reparle plus bas.
Ce qu'il faut comprendre, c'est le rapport de force. Le sitemap est une déclaration d'intention. Vous dites : « Voici les pages qui méritent d'être explorées. » Le moteur décide ensuite, seul, lesquelles il crawle et lesquelles il indexe. Aucune balise ne force une indexation.
Sitemap ou robots.txt : lequel choisir ?
Les deux, et ils ne jouent pas le même rôle. Le fichier robots.txt interdit l'exploration de certaines zones. Le sitemap, lui, propose des zones à explorer. Un fichier qui interdit et un fichier qui suggère : l'articulation est simple, encore faut-il ne pas se contredire.
J'ai vu plusieurs fois le même sabotage involontaire : un Disallow: / laissé en production après une phase de test, avec un sitemap qui continuait à lister 800 URL. Résultat, Google voyait les URL dans le sitemap, ne pouvait pas les crawler, et remontait des erreurs d'exploration en masse. Le sitemap n'était pas en cause ; il révélait le problème.
Comment trouver le sitemap d'un site ?
Trois réflexes, dans cet ordre. Tapez votredomaine.com/robots.txt : la directive Sitemap: y figure presque toujours. Sinon, essayez /sitemap.xml, /sitemap_index.xml (fréquent sur WordPress), /sitemap-index.xml ou /sitemap_index.xml.gz. En dernier recours, l'onglet Sitemaps de Search Console donne l'URL exacte déclarée.
Cette manipulation sert aussi au diagnostic concurrentiel : le sitemap d'un site bien tenu vous montre sa structure de répertoires, ses silos, et parfois des sections qu'il n'expose pas dans son menu.
La structure d'un fichier sitemap valide, balise par balise
Un sitemap minimal tient en cinq lignes. Voici ce que j'écris quand je dois produire un fichier à la main :
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://exemple.fr/article</loc>
<lastmod>2026-06-14</lastmod>
</url>
</urlset> Trois contraintes que l'on découvre généralement trop tard. L'encodage doit être UTF-8. Les URL doivent être absolues, avec le protocole. Et les caractères spéciaux (&, <, apostrophes) doivent être échappés en entités XML — un & dans une URL de filtre produit un fichier invalide si vous ne le transformez pas en &.
lastmod, priority, changefreq : ce qui compte encore
Franchement, la réponse tient en une ligne : Google ignore priority et changefreq. Ces deux balises sont restées dans le protocole mais n'ont plus d'effet sur l'exploration. Les remplir est au mieux décoratif, au pire un signal de négligence quand les valeurs sont aberrantes (tout en priorité 1.0, par exemple).
lastmod est le seul champ qui mérite votre attention, et à une condition stricte : qu'il soit vrai. Si vous le mettez à jour automatiquement à chaque déploiement, y compris pour des pages dont le contenu n'a pas bougé d'un caractère, Google apprend à s'en méfier et finit par l'ignorer. Sur un site où j'avais laissé un générateur écrire la date du jour partout, le taux de pages recrawlées après modification a chuté nettement. Corriger le générateur pour qu'il ne touche à lastmod que sur changement réel de contenu a rétabli la confiance en quelques semaines.
Créer un sitemap : générateur, CMS ou écriture manuelle
Le choix de la méthode dépend d'une seule question : à quelle fréquence votre contenu change-t-il ?
| Méthode | Pour qui | Limite principale |
|---|---|---|
| Extension CMS (Yoast, Rank Math, module natif) | Sites WordPress, PrestaShop, Shopify | Paramétrage par défaut souvent trop large : types de contenus, pages de tags, médias |
| Générateur en ligne | Site vitrine de moins de 100 pages, mise à jour rare | Instantané figé : il faut le régénérer à chaque ajout de page |
| Script sur mesure (crawl + écriture XML) | Catalogue e-commerce, site multilingue, portail | Demande une maintenance, et une gestion propre de lastmod |
| Écriture manuelle | Micro-site, documentation technique | Ingérable au-delà de quelques dizaines d'URL |
Le cas WordPress : ce que cache la génération automatique
Sur WordPress, un plugin produit le sitemap en quelques secondes. Le problème n'est jamais la génération, c'est le périmètre. Par défaut, beaucoup de configurations incluent les archives d'auteur, les pages de tags, les pièces jointes. Sur un blog que j'ai repris, le sitemap listait 2 400 URL pour 190 articles réels. Le reste : des pages de tags vides, des archives de dates, et une centaine de fiches média.
Ce n'est pas neutre. Un sitemap gonflé dilue le budget d'exploration alloué à votre domaine. Nettoyer le fichier pour ne garder que les contenus qui méritent une visite a produit, sur ce site, une amélioration visible du délai de prise en compte des nouveaux articles — de plusieurs jours à moins de 48 heures dans les cas favorables.
Soumettre son sitemap à Google sans se tromper
La procédure dans Search Console tient en quatre gestes : ouvrir le rapport Sitemaps dans le menu de gauche, saisir l'URL complète du fichier (pas seulement son nom), valider, attendre le statut « Réussite ». Le statut est binaire et immédiat pour la lecture — pas pour l'indexation.
C'est là que les malentendus naissent. Un sitemap « Réussite » signifie que Google a récupéré et parsé le fichier. Cela ne dit rien du nombre de pages indexées. J'ai eu des clients convaincus que leur sitemap était « refusé » parce que l'onglet Couverture affichait des pages exclues. Le fichier était parfaitement lu ; les pages étaient simplement jugées non conformes à l'indexation.
« Impossible de lire le sitemap » : les causes réelles
Ce message apparaît pour une poignée de raisons techniques, et l'ordre de vérification compte :
- Code HTTP non-200 — une redirection, une page 404 ou une erreur 500 sur l'URL du fichier. C'est la cause la plus fréquente, de loin.
- Contenu servi en HTML au lieu de XML (réécriture serveur, page d'erreur personnalisée qui renvoie 200).
- XML mal formé : balise non fermée,
&non échappé, BOM en début de fichier. - Fichier trop volumineux ou dépassant 50 000 URL sans index intermédiaire.
- URL déclarée sur un autre domaine que la propriété validée, sans délégation croisée.
Le statut « En attente » est souvent un faux problème : il signifie que Google n'a pas encore traité le fichier, généralement parce qu'il vient d'être soumis. Comptez quelques jours, parfois plus sur un domaine récent ou peu crawlé.
Déclarer dans robots.txt, ou soumettre, ou les deux ?
Les deux. La ligne Sitemap: https://exemple.fr/sitemap.xml dans robots.txt a un avantage que Search Console n'offre pas : elle fonctionne pour tous les moteurs, y compris ceux auxquels vous ne pensez pas. La soumission manuelle, elle, vous donne le retour d'état et les statistiques de lecture. L'une alimente les robots, l'autre vous informe. Rien ne justifie de choisir.
Sitemaps spécialisés : images, vidéos, actualités, multilingue
Le protocole prévoit des extensions. Un sitemap d'actualités (news) ne référence que les articles publiés dans les deux derniers jours et s'adresse aux sites d'information. Le sitemap vidéo exige des balises supplémentaires décrivant la vignette, la durée, la source du fichier. Le sitemap d'images étend chaque <url> avec les visuels présents sur la page.
L'extension la plus utile au quotidien reste xhtml:link pour les sites multilingues : elle déclare, pour chaque URL, ses équivalents dans les autres langues. Sans elle, un site en cinq langues se retrouve avec des centaines de pages quasi identiques aux yeux du moteur. J'ai traité ce cas sur un projet franco-allemand : la déclaration des alternates dans le sitemap a clarifié les regroupements, là où les balises hreflang posées en HTML avaient été partiellement perdues lors d'une refonte de template.
Index de sitemaps, plafonds, et la vérité sur le maillage
Les seuils à connaître : 50 000 URL et 50 Mo par fichier, taille non compressée. Un fichier .xml.gz est accepté et pèse moins lourd sur le réseau, mais le décompte se fait sur le contenu décompressé. Au-delà, on crée un index : un sitemap qui ne contient que des liens vers d'autres sitemaps, un par section ou par langue.
Sur un catalogue de 180 000 références que j'ai accompagné, le découpage s'est fait par famille de produits, avec un index racine. Le gain n'était pas la vitesse de lecture — Google gérait déjà — mais la finesse du diagnostic : une erreur dans une famille n'invalidait plus l'ensemble, et l'onglet Sitemaps affichait un statut par sous-fichier.
Un sitemap remplace-t-il un maillage interne ?
Non, et cette confusion coûte des mois à certains sites. Un sitemap aide à la découverte. Le maillage interne, lui, transmet du contexte et de la valeur entre pages. Une page présente uniquement dans le sitemap, jamais liée depuis le site, reste une page orpheline aux yeux du moteur : il la connaît, mais ne sait pas quoi en faire.
Ma règle personnelle, et je l'assume : une URL qui n'a aucun lien interne entrant n'a rien à faire dans le sitemap. Soit on la lie correctement depuis le contenu, soit on s'interroge sur son utilité. Le sitemap est un filet de sécurité pour le contenu récent ou profond, pas une roue de secours pour une architecture négligée.
Il reste une question que personne ne pose et qui devrait l'être plus souvent : à quoi ressemblerait votre sitemap si vous le lisiez comme un plan de votre site ? S'il vous faut trois niveaux d'index pour vous y retrouver, vos visiteurs s'y perdent aussi. Le fichier XML n'est jamais qu'un miroir.