Sitemap « Impossible de récupérer » : les trois causes avancées par Google

L’essentiel

• Martin Splitt soumet à John Mueller le cas de sitemaps XML valides, publics et déclarés dans le robots.txt, mais marqués « Impossible de récupérer ».
• Mueller cite trois causes : la charge du serveur, une faible demande d’exploration, un sitemap dont Google n’a pas besoin.
• La demande d’exploration repose « très souvent sur la qualité perçue d’un site » (traduction), selon lui.
• Google n’annonce aucune modification du libellé dans la Search Console.

Un statut d’erreur qui ne signale pas toujours une erreur

La question vient de Martin Splitt, dans un échange avec John Mueller rapporté le 6 octobre 2026 par Search Engine Journal. Il décrit un fichier que l’on peut valider, accessible publiquement et référencé dans le robots.txt. Et pourtant la Search Console affiche parfois « impossible de récupérer ». D’où sa question : « pourquoi ce statut apparaît-il alors que le sitemap XML est valide ? » (traduction).

Pour Mueller, la réponse n’est « pas purement technique » (traduction). Le libellé laisse pourtant penser à un échec de téléchargement du fichier. Roger Montti, l’auteur de l’article, estime que le message ne correspond pas à la cause réelle, que les utilisateurs de la Search Console en sortent perdus, et que Google le sait sans rien changer.

Les trois causes avancées par John Mueller

La première est la charge du serveur, ce que Google appelle le host load. Mueller explique que les systèmes de Google peuvent ne pas avoir le temps d’explorer le sitemap « parce que nous sommes trop occupés par d’autres choses » (traduction). Le statut affiché est alors le même. Montti y ajoute un cas de figure qui n’est pas de Google : un serveur submergé par des robots, légitimes ou non, qui finit par répondre en erreur 500.

La deuxième tient à la demande d’exploration. Si Google juge qu’il a déjà assez récupéré sur un site, il saute le sitemap. Cette demande est, d’après Mueller, « très souvent fondée sur la qualité perçue d’un site » (traduction), avec un effet important sur le volume exploré et indexé. Il la présente comme liée à la charge du serveur. Montti, lui, dit ne pas être sûr de suivre ce rapprochement.

La troisième est la plus sèche. Google n’a pas forcément besoin du sitemap, ni envie de s’en servir. « Peut-être que nous n’en voulons tout simplement pas » (traduction), résume Mueller. Il précise que si la qualité du site progresse nettement avec le temps, Google finira par utiliser le fichier.

Ce que Google ne précise pas

Aucune méthode n’est donnée pour savoir laquelle des trois causes s’applique à un site. Pas de seuil, pas d’indicateur dédié pour distinguer une surcharge serveur d’un simple désintérêt. L’article de Search Engine Journal n’indique pas non plus où l’échange a eu lieu et ne renvoie vers aucun enregistrement. Les propos cités ici sont donc traduits à partir de ce relais, sans vérification sur la source d’origine.

Ce que j’en retiens

Je lis cette réponse comme un aveu : « Impossible de récupérer » est parfois un arbitrage de priorité, pas une panne. Avant de réécrire le fichier, je conseille de vérifier dans cet ordre. C’est ma méthode de diagnostic, pas une consigne de Google :

1. ouvrir l’URL du sitemap et s’assurer qu’elle renvoie un code 200 avec un XML lisible ;
2. contrôler que le robots.txt ne bloque pas le fichier ;
3. consulter le rapport Statistiques sur l’exploration de la Search Console pour repérer des erreurs 5xx ou des soucis de disponibilité de l’hôte ;
4. chercher dans les logs serveur les requêtes de Googlebot vers le sitemap ;
5. regarder enfin, dans le rapport d’indexation des pages, la part des URL du sitemap réellement indexées.

Si les quatre premiers points sont au vert et que l’indexation reste faible, le fichier n’est plus en cause. C’est la qualité perçue du site qu’il faut travailler, et le statut du sitemap devient un indicateur parmi d’autres.