Vous ouvrez la Google Search Console pour vérifier l'indexation, vous allez dans le rapport de plan de site et vous voyez le statut « Couldn't fetch ». Cela vous dit quelque chose ?

Cette erreur peut provoquer une panique : on a l'impression que Google ne voit plus du tout votre site et que toutes les pages vont disparaître de l'index. En pratique, la situation se résout presque toujours en 10 à 15 minutes, et dans la moitié des cas, le problème ne vient même pas de chez vous.

Voici un algorithme éprouvé : du diagnostic à la résolution complète. Sans blabla, avec des étapes concrètes et de vraies captures d'écran de l'interface Search Console.

💡 Aperçu rapide :

• Vérifiez si l'erreur est réelle : il s'agit souvent d'un bug de Google, et il suffit d'attendre ou de demander une nouvelle exploration
• Testez l'accessibilité du plan de site via l'Inspection d'URL et le Test en direct : cela prend une minute et montre immédiatement si Google voit votre fichier
• Si l'erreur est réelle, passez en revue la checklist : validation XML, robots.txt, plugins, réponse du serveur
• Dans les cas complexes, utilisez des outils de diagnostic tiers et soumettez à nouveau le plan de site via l'interface Search Console

Pourquoi Google n'arrive pas à récupérer le plan de site

Il faut distinguer deux causes racines : une erreur côté Google et une erreur côté site. La différence est fondamentale, car dans le premier cas, vous n'avez absolument rien à faire.

Bug de la Search Console. Depuis la refonte majeure de l'interface Search Console, les situations où le statut « Couldn't fetch » est un faux positif sont devenues plus fréquentes. Google tente de charger le plan de site, quelque chose se passe mal dans le système lui-même, et le rapport affiche une erreur alors que le fichier sur le serveur est parfaitement valide. Les ingénieurs de Google sont conscients de ce problème, et la documentation officielle indique clairement : si la récupération échoue, le système réessaiera dans les jours qui suivent, et ce n'est qu'après une série d'échecs qu'il cessera de vérifier.

Indisponibilité réelle. Le plan de site n'est physiquement pas servi : XML cassé, Content-Type incorrect, blocage dans le robots.txt, un plugin de sécurité qui rejette les requêtes de Googlebot, un CDN ou un pare-feu mal configuré. Cela inclut aussi les certificats SSL expirés sur le domaine, qui empêchent Google d'établir une connexion sécurisée.

Causes indirectes. Certains plugins WordPress (notamment ceux de sécurité et de cache) peuvent accidentellement bloquer le User-Agent Googlebot. Parfois, le coupable n'est pas le plugin auquel on pense en premier ; le problème se manifeste en cascade : un plugin de cache génère une copie statique de la page du plan de site, tandis qu'un plugin de sécurité bloque les requêtes vers cette copie.

Comment vérifier si le plan de site est accessible

Le moyen le plus rapide de distinguer un bug Google d'un problème réel est l'outil d'inspection d'URL directement dans la Search Console. Il montre ce que Googlebot voit lorsqu'il accède au fichier.

Étape 1. Ouvrez la Search Console, collez l'URL complète du plan de site dans la barre d'inspection en haut de l'interface et appuyez sur Entrée.

Étape 2. Si l'URL n'est pas indexée (c'est normal pour les plans de site, car ils ont généralement noindex), cliquez sur le bouton « Tester l'URL en direct ». La Search Console effectuera un test en direct, accédera au fichier en temps réel et affichera le résultat.

Étape 3. Faites défiler la page du test en direct jusqu'à la section « Récupération de la page ». Si elle indique « Réussie », Google voit le fichier, et l'erreur « Couldn't fetch » dans le rapport des plans de site est un bug côté Search Console. Ne faites rien : le statut se mettra à jour lors du prochain cycle de vérification, ou soumettez à nouveau le plan de site via le bouton dans le rapport Plans de site.

Si la récupération de la page affiche une erreur, passez à la section suivante.

Correction étape par étape : une checklist en cinq points

Lorsque le test en direct confirme que Google ne peut vraiment pas récupérer le plan de site, passez en revue les points dans l'ordre. Chaque étape suivante ne s'applique que si la précédente n'a pas résolu le problème.

1. Vérifiez la validité XML

Ouvrez l'URL du plan de site dans votre navigateur. Si vous voyez du XML propre avec des balises <urlset> et <url>, la structure est bonne. Si la page est blanche, génère une erreur PHP ou affiche une page HTML blanche, le plan de site est cassé.

Pour une vérification plus poussée, utilisez XML Sitemap Validator, un outil en ligne gratuit qui montre les erreurs de formatage, les URL cassées dans le plan de site et les non-conformités avec le standard Sitemap Protocol. Il vous dira aussi si la limite de 50 000 URL par fichier est dépassée (auquel cas vous avez besoin d'un index de plan de site).

2. Vérifiez le robots.txt et les en-têtes du serveur

Googlebot doit avoir accès au fichier du plan de site. Ouvrez yoursite.com/robots.txt et assurez-vous qu'il n'y a pas de ligne comme :

1
Disallow: /sitemap.xml
2

Vérifiez également que le User-Agent Googlebot lui-même n'est pas bloqué avec une ligne comme User-agent: Googlebot suivie de Disallow: /.

L'en-tête de réponse du serveur Content-Type doit être application/xml ou text/xml. Si le serveur sert le plan de site en text/html, Google peut ne pas reconnaître le fichier. Vous pouvez vérifier les en-têtes via Fetch & Render de TechnicalSEO, qui montre la page à travers les yeux de Googlebot avec tous les en-têtes HTTP.

3. Vérifiez les plugins WordPress

Les plugins de sécurité (Wordfence, Solid Security, Sucuri) et les plugins de cache (WP Rocket, W3 Total Cache, LiteSpeed Cache) sont les principaux suspects. Algorithme :

• Plugins de cache. Videz le cache, excluez temporairement sitemap.xml de la mise en cache. Dans WP Rocket, il y a un champ « Never cache URLs » ; dans LiteSpeed Cache, l'onglet « Excludes ». Après exclusion, videz à nouveau le cache.

• Plugins de sécurité. Vérifiez les journaux du plugin pour les requêtes bloquées vers sitemap.xml provenant du User-Agent Googlebot. Wordfence affiche ces blocages en temps réel dans « Tools → Live Traffic ».

• Plugins SEO. Parfois, le problème vient du générateur de plan de site lui-même. Yoast SEO, Rank Math, All in One SEO, chacun a son propre gestionnaire. Essayez de régénérer le plan de site : dans Yoast SEO, cela se fait via « Réglages → Fonctionnalités du site → Plans de site XML » (désactivez puis réactivez) ; dans Rank Math, via « Paramètres du plan de site → Enregistrer les modifications ».

4. Écartez un blocage par l'hébergement ou le CDN

Certains hébergeurs et pare-feux (Cloudflare, Sucuri WAF) peuvent bloquer les requêtes de Googlebot par IP ou User-Agent. Vérifiez :

• Cloudflare. Dans la section « Sécurité → Événements », cherchez les requêtes bloquées vers sitemap.xml. Si vous en trouvez, créez une règle WAF autorisant le User-Agent Googlebot pour les URL contenant sitemap.

• Pare-feu de l'hébergement. Certains panneaux de contrôle (cPanel, ISPmanager) ont des règles ModSecurity intégrées qui se déclenchent à tort sur les fichiers XML. Vérifiez les journaux Apache/NGINX pour les erreurs 403 lors de l'accès à sitemap.xml.

5. Soumettez à nouveau le plan de site

Après avoir corrigé la cause, retournez dans Search Console → Plans de site → collez l'URL du plan de site dans le champ « Ajouter un nouveau plan de site » → Envoyer. Le système tentera de charger le fichier immédiatement. Si le statut passe à « Succès », le problème est résolu.

Remarque importante : même après un chargement réussi du plan de site, Google ne garantit pas l'indexation de toutes les URL qui y sont listées. La vitesse et l'exhaustivité de l'indexation dépendent de la taille du site, de son autorité et de la fréquence de mise à jour du contenu.

Outils de diagnostic

En plus des outils intégrés de la Search Console, gardez à portée de main trois outils externes ; ils couvrent pratiquement tous les scénarios de diagnostic :

• Validateur en ligne de XML-Sitemaps, un validateur de structure. Vérifie la syntaxe, le nombre d'URL, les index de plans de site imbriqués et la conformité au standard Sitemaps.org. Gratuit, sans inscription.

• Fetch & Render, un émulateur Googlebot. Montre comment Google voit la page : en-têtes HTTP, code de statut, HTML rendu. Utile lorsque vous devez comprendre si le serveur substitue du contenu pour différents User-Agents.

• PageSpeed Insights, un outil indirect mais important. Si le serveur répond lentement (TTFB supérieur à 1-2 secondes pour un fichier XML statique), Google peut abandonner la connexion lors de la tentative de chargement d'un plan de site volumineux.

⁉️🤔 Questions fréquentes

Pourquoi l'erreur « Couldn't fetch » apparaît et disparaît sans aucune action de ma part ?

C'est un comportement classique d'un bug côté Google. Le système revérifie périodiquement le plan de site selon son propre calendrier, et à certains moments, un problème interne provoque une fausse erreur. La vérification automatique suivante réussit souvent, d'où le clignotement du statut. Si le plan de site est physiquement accessible (vérifié via le Test en direct), ignorez ce clignotement ; cela n'affecte pas l'indexation.

À quelle fréquence Google vérifie-t-il le plan de site après un chargement réussi ?

Le calendrier de revérification n'est pas lié à l'exploration régulière du site. Google ne divulgue pas la fréquence exacte, mais en pratique, pour les sites actifs, elle varie de plusieurs fois par semaine à une fois tous les quelques jours. Si vous avez apporté des modifications majeures au plan de site et souhaitez accélérer le traitement, soumettez-le à nouveau via le bouton Envoyer dans le rapport Plans de site.

L'erreur pourrait-elle être liée à la taille du plan de site ?

Oui. La limite est de 50 000 URL et 50 Mo par fichier. Si le plan de site dépasse l'une ou l'autre limite, Google peut échouer à le traiter. La solution est un index de plan de site : un fichier XML parent qui référence plusieurs fichiers enfants, chacun dans les limites. La plupart des plugins SEO WordPress le font automatiquement lorsque le seuil est dépassé.

Dois-je ajouter le plan de site au robots.txt ?

Fortement recommandé. Ajoutez la directive Sitemap: https://yoursite.com/sitemap.xml au robots.txt ; cela donne à Google un second chemin pour découvrir le fichier. Même si la soumission via l'interface Search Console échoue, Google peut trouver le plan de site lors de l'exploration du robots.txt.

Une erreur de récupération du plan de site affecte-t-elle le classement ?

Pas directement. Google n'applique pas de pénalités pour l'indisponibilité du plan de site. Un impact indirect est possible : sans plan de site, les pages nouvelles ou rarement mises à jour peuvent attendre plus longtemps pour être indexées, surtout sur les grands sites à la structure complexe. Pour les petits sites avec un bon maillage interne, l'absence de plan de site est pratiquement imperceptible.

Plan de site indisponible : que faire maintenant

L'algorithme se résume à trois étapes qui couvrent la grande majorité des cas :

• Test en direct. Collez l'URL du plan de site dans la barre d'inspection de la Search Console → cliquez sur Test en direct. « Récupération de la page : Réussie » → l'erreur est un faux positif, ne faites rien. « Échec » → passez à la suite.

• Diagnostic côté serveur. Ouvrez sitemap.xml dans votre navigateur ; voyez-vous du XML propre ? Vérifiez le robots.txt pour un Disallow ? Videz le cache et vérifiez les journaux du plugin de sécurité ? Passez le fichier dans XML Sitemap Validator ?

• Nouvelle soumission. Corrigez la cause → retournez dans Plans de site → Envoyer. Le statut est passé à « Succès » ? Terminé. Sinon, revenez au point 2 et vérifiez les en-têtes du serveur via Fetch & Render.

Si vous abordez le diagnostic de manière systématique et ne sautez pas d'étapes, le problème se résout en un cycle de vérification. Et les fausses erreurs de la Search Console, qui représentent une bonne moitié des demandes sur ce sujet, ne nécessitent aucune intervention.