Google indique qu'un site d'environ 500 pages ou moins, bien relié en interne, peut se passer de sitemap, et John Mueller recommande malgré tout de le laisser activé : il ne coûte rien et la plupart des CMS le produisent seuls. Seuls l'adresse et la date de modification comptent, priority et changefreq sont ignorés, et la date n'est lue que si elle est exacte. Un « Impossible de récupérer » sur un fichier valide tient souvent à la demande d'exploration, donc à la qualité perçue du site. Quant à llms.txt, il ne se soumet pas comme un sitemap, et d'après Mueller aucun système d'IA ne l'utilise.
Sommaire
Le 1er octobre 2026, Martin Splitt a reçu John Mueller pour un épisode de Search Off the Record consacré aux sitemaps, intitulé Do sitemaps still matter?1 Le podcast est celui de Google Search Central, le site officiel de Google pour les propriétaires de sites et les professionnels du référencement.2 Splitt y est developer advocate et Mueller dirige l'équipe Search Relations.3 Le point de départ est le courrier que reçoit Splitt : des propriétaires de sites s'inquiètent de ce qu'ils voient dans Search Console à propos de leur sitemap, et l'épisode passe en revue ce que Google attend d'un sitemap en 2026.
01Un petit site a-t-il besoin d'un sitemap ?
C'est la question que tout propriétaire de petit site finit par se poser.
Ce que dit la documentation
La documentation range le sitemap parmi les aides à la découverte des pages. Il sert surtout aux grands sites, où relier chaque page devient difficile, aux sites récents qui reçoivent peu de liens, et à ceux qui publient des vidéos, des images ou de l'actualité.4
Un site de 500 pages ou moins, dont toutes les pages importantes sont accessibles depuis la page d'accueil, peut ne pas en avoir besoin, précise-t-elle.4 Cette condition d'accessibilité dépend de la façon dont les liens internes distribuent les pages importantes depuis l'accueil.
Ce que dit Mueller
Mueller en convient : les petits sites n'ont probablement pas besoin d'un sitemap, puisque Google peut les explorer sans aide. Il pointe toutefois un vrai problème, celui du seuil. Dix pages, c'est petit. Cinquante, on hésite.1
Sa consigne habituelle est donc simple : activez-le. Presque tous les CMS, y compris les hébergeurs de sites statiques, génèrent un sitemap par défaut tant qu'on ne le coupe pas. Si le site grossit, le fichier est déjà en place, et s'il reste petit, il ne gêne personne.1
Quand il devient vraiment utile
L'intérêt grandit avec le volume de contenu et le rythme des changements. Mueller prend l'exemple d'une boutique : sans sitemap, Google doit retrouver par l'exploration classique la fiche dont le prix vient de changer, et il y arrive parfois trop tard. Avec un sitemap, la date de modification lui indique directement la page à revisiter.1
C'est l'un des premiers réglages à vérifier dans le référencement d'une boutique en ligne.
Les sites d'actualité sont le cas le plus net. Google prévoit pour eux un sitemap dédié, qui ne liste que les articles des deux derniers jours et ne dépasse pas 1 000 balises news.5
02L'adresse et la date : tout le reste est tombé
Le format a beaucoup maigri depuis ses débuts. Il reste deux informations utiles par page, et Google n'attend qu'une chose d'elles : qu'elles soient exactes.
Deux champs abandonnés
Dans l'épisode, Splitt et Mueller expliquent pourquoi priority et changefreq ont disparu. Demandez à des référenceurs la priorité de leurs pages : tout est au maximum. Demandez la fréquence de changement : tout change en permanence, d'autant qu'une page produite côté serveur est techniquement recalculée à chaque visite.1
Résultat, ces deux champs n'apprenaient rien à Google. La documentation indique que Google les ignore.6
La date : lue seulement si elle est crédible
Mueller décrit la date comme celle de la dernière modification importante de la page. Si vous affichez la date du jour sur toutes vos URL, Google s'en aperçoit et cesse de s'y fier.1
Aucun système antispam ne classe pour autant le fichier comme mauvais : Google se rabat sur les URL elles-mêmes et traite chaque nouvelle page qui apparaît.1
La documentation dit la même chose, avec plus de précision. La valeur doit refléter la dernière mise à jour significative, date et heure, et Google n'utilise le champ que si les dates sont régulièrement exactes. Modifier le contenu principal, les données structurées ou les liens compte. Changer l'année du copyright ne compte pas.6
Mueller prévient que c'est sa compréhension du moment, qu'elle a pu évoluer, et que Google entretient une relation ambivalente avec ce champ, parce que beaucoup de sites le renseignent mal.1
Concrètement, la date doit venir de la modification réelle du contenu et jamais de l'heure de génération du fichier. Un sitemap régénéré chaque nuit avec la date du jour retombe dans le cas décrit plus haut.
Y mettre les adresses canoniques
Le sitemap sert à déclarer les adresses telles que vous voulez les voir indexées. Mueller prend l'exemple d'une URL à laquelle on ajoute une date pour forcer l'affichage de la dernière version : Google tentera d'indexer la version sans date comme canonique.1
Il ajoute, toujours d'après sa compréhension, que lister une URL dans le sitemap la rend un peu plus susceptible d'être retenue comme canonique parmi plusieurs adresses voisines.1 La documentation demande des URL absolues, avec le protocole, et un fichier encodé en UTF-8.6
| Champ | Lu par Google ? | Condition |
|---|---|---|
| URL de la page | oui | adresse absolue, version canonique |
lastmod | oui, si fiable | dernière modification significative |
priority | non | ignoré |
changefreq | non | ignoré |
| Versions linguistiques | oui | déclarables dans le sitemap |
| Images et vidéos | pris en charge | moins déterminants qu'avant |
Mueller mentionne en passant qu'on peut aussi déclarer les versions linguistiques dans le sitemap, ce que la documentation range parmi les informations acceptées.4
Pour les images et les vidéos, les sitemaps dédiés restent pris en charge, mais il doute de leur importance aujourd'hui : Google reconnaît mieux qu'avant ces contenus directement sur les pages.1
03Formats, limites et emplacement du fichier
Les formats acceptés, les limites de taille et l'endroit où déclarer le fichier : l'essentiel tient en quelques points.
Les formats acceptés
Google lit les sitemaps XML, les flux RSS et Atom et les fichiers texte. Le XML est le plus polyvalent, parce qu'il peut aussi porter les données d'images, de vidéos et d'actualité.6
Mueller juge le flux RSS très proche d'un sitemap. Il liste les URL récemment modifiées avec une date, souvent plafonné à une dizaine ou une vingtaine d'entrées, et il se soumet dans Search Console comme un sitemap.1
Son avantage apparaît sur un gros site : au lieu de parcourir un à un des centaines de fichiers sitemap, un système lit le flux et voit d'un coup les pages qui ont bougé.1
Les limites de taille
Un fichier sitemap ne dépasse pas 50 000 URL ni 50 Mo non compressés.6 Mueller cite ces chiffres de mémoire et précise que la limite de poids porte sur le fichier décompressé : on peut compresser en gzip, mais on ne peut pas viser une taille compressée.1
Au-delà, on répartit les URL dans plusieurs fichiers rattachés par un fichier d'index, qui peut lister jusqu'à 50 000 sitemaps. Search Console accepte jusqu'à 500 fichiers d'index par site.7 Les deux animateurs en concluent qu'un site qui en arrive à plusieurs fichiers d'index a de toute façon assez d'URL pour justifier un sitemap.
Où le déclarer
Le fichier peut porter n'importe quel nom, mais sitemap.xml reste celui que beaucoup de systèmes devinent d'eux-mêmes. Pour le faire connaître, on le déclare dans le robots.txt ou on le soumet dans Search Console.6
Un nom confidentiel soumis uniquement dans Search Console garde le fichier discret, mais Bing et les autres moteurs doivent alors être prévenus séparément.1
Les crawlers d'IA n'ont en général aucune console où soumettre un fichier. Mueller a constaté dans ses journaux serveur que certains lisent son sitemap et ses flux RSS, sans que ce comportement soit documenté et sans qu'il sache ce qu'ils en font.1
Le plan de site HTML ne remplace rien
Un plan de site HTML est une carte du site destinée aux visiteurs. Google en suit les liens comme tous les autres, ce qui aide l'exploration, mais il ne peut pas le traiter comme un sitemap, faute de structure stricte, et il ne se soumet pas.1
Mueller ajoute qu'un plan HTML ne liste pas tout : sur une boutique, il montre les catégories, rarement chaque produit.1
04« Impossible de récupérer » alors que le fichier est valide
C'est le point de départ de l'épisode. Le fichier se valide, il est public, il est déclaré dans le robots.txt, et Search Console affiche pourtant « Impossible de récupérer ».8
Mueller dit voir ce cas revenir souvent dans les forums d'aide. Il en donne deux causes principales, toutes deux liées à ce que Google s'autorise à explorer sur un site.1
Google n'a pas eu le temps
Il existe une limite à ce que Google explore sur un hôte. Si ses robots sont occupés par d'autres pages, le sitemap n'est pas récupéré, et Search Console l'affiche comme impossible à récupérer, faute de temps pour le faire.1
Google n'en voit pas l'utilité
Seconde cause : la demande d'exploration est faible, et Google saute le fichier parce qu'il a déjà ce qu'il lui faut. Cette demande repose très souvent sur la qualité perçue du site.1
Si les systèmes jugent la qualité d'ensemble moyenne, ils dépensent peu de ressources à explorer et à indexer, et ne s'occupent donc pas du sitemap pour le moment. Si la qualité progresse nettement avec le temps, ils finiront par l'utiliser.1
La documentation de Search Console confirme cette lecture. Parmi les causes listées pour ce statut figure une demande d'exploration faible, avec cette précision : plus la qualité du contenu du site est élevée, plus la demande d'exploration est forte.8
Les causes ordinaires à écarter d'abord
Avant de conclure à un problème de qualité, il faut éliminer les causes courantes, que la même page de documentation liste : un sitemap bloqué par le robots.txt, une action manuelle non résolue sur le site, une adresse de sitemap incorrecte qui renvoie une erreur 404, des erreurs serveur ponctuelles.8
Elle recommande d'ouvrir le détail du sitemap dans le rapport, puis de tester l'adresse avec l'outil d'inspection d'URL.8 Ces contrôles d'exploration et d'indexation forment aussi le premier bloc d'un audit technique mené soi-même avec une checklist.
Pour un site de quelques dizaines de pages bien reliées, rappelons que la documentation le dispense de sitemap, et que Google continue de découvrir les pages par les liens.4
05llms.txt ne remplace pas le sitemap
Splitt pose la question frontalement : le sitemap XML va-t-il disparaître au profit de llms.txt ? Mueller commence par décrire le fichier. C'est un document markdown qui renvoie vers des contenus, un peu comme un plan de site HTML, dans l'espoir qu'un système d'IA s'en serve pour mieux comprendre le site.1
À son avis, l'espoir dépasse la réalité, même si cela peut changer. Les systèmes de Google ne peuvent pas l'utiliser comme un sitemap, faute de format strict. Il pourrait un jour être lu comme du markdown dont on suit les liens, mais pour l'instant rien de tel n'a lieu.1
Son conseil : concentrer l'énergie sur ce qui fonctionne et ce qui est documenté, plutôt que sur un état futur espéré. Si votre CMS produit un llms.txt tout seul, très bien, mais il ne faut ni s'y fier ni en faire une priorité.1
Ses prises de position publiques vont dans le même sens. En juin 2025, il écrivait sur Bluesky qu'aucun système d'IA n'utilisait llms.txt, et il invitait à vérifier dans ses journaux serveur : les chatbots y récupèrent des pages, jamais ce fichier.9 En juin 2026, sur Reddit, il qualifiait le fichier de purement spéculatif pour l'instant.10
Quant au sitemap XML, Mueller ne le voit pas disparaître : son caractère exhaustif garde son utilité.1