# Un sitemap natif invisible dans Search Console : diagnostiquer le blocage > Le sitemap XML natif répond bien dans le navigateur, mais Search Console refuse de le lire. Voici la méthode pour trouver ce qui bloque réellement. - Auteur : Clément Hadrot - Publié le : 2020-03-19 - Mis à jour le : 2020-03-19 - Catégorie : SEO & GEO - URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/sitemap-natif-invisible-search-console-diagnostic/ ## L’essentiel - Un sitemap qui « répond » au navigateur ne veut pas dire qu'il est lisible par Googlebot - Le user-agent et l'en-tête Content-Type sont les deux premiers suspects - Un test en ligne de commande évite les fausses conclusions du navigateur Le symptôme est déroutant : on ouvre l'URL du sitemap dans son navigateur, le XML s'affiche parfaitement, avec toutes les URL attendues. Pourtant, dans Search Console, la ligne du sitemap reste bloquée sur « Récupération impossible » ou pire, sur un silence complet, sans aucune erreur explicite. Le réflexe naturel est de re-soumettre le sitemap en boucle, sans effet. Ce cas s'est présenté sur un projet où le sitemap natif de WordPress semblait fonctionner à l'œil nu, mais où Search Console n'en tirait jamais aucune URL indexée. Le diagnostic a demandé de sortir du navigateur et de regarder exactement ce que reçoit un robot, pas un humain. ## Pourquoi le navigateur ment sur l'état réel du fichier Un navigateur suit les redirections, ignore certains en-têtes non standards, et affiche un contenu même si le `Content-Type` renvoyé est incorrect. Googlebot est plus strict sur certains points : il vérifie l'en-tête `Content-Type`, respecte scrupuleusement les redirections (y compris les chaînes multiples), et peut être bloqué par des règles qui ne concernent que certains user-agents. Le premier réflexe à adopter est donc de ne jamais se fier à l'affichage navigateur pour un diagnostic de sitemap. Il faut interroger le serveur directement, comme le ferait un robot, avec un outil qui n'interprète rien. ## La commande qui révèle ce que Googlebot voit vraiment La commande `curl` en mode verbeux permet de voir les en-têtes bruts de la réponse, sans qu'un navigateur ne les corrige ou ne les masque : ``` curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://exemple.fr/wp-sitemap.xml ``` Sur le projet concerné, cette commande a révélé le problème en quelques secondes : le serveur renvoyait un code `200` avec un `Content-Type: text/html` au lieu de `application/xml`. La cause : un plugin de cache de page servait une version HTML mise en cache par erreur pour cette URL, générée avant l'activation du sitemap natif de WordPress. Le cache n'avait jamais été purgé pour cette route spécifique. > L'essentiel à retenir : Un sitemap qui « répond » au navigateur ne veut pas dire qu'il est lisible par Googlebot ; Le user-agent et l'en-tête Content-Type sont les deux premiers suspects ; Un test en ligne de commande évite les fausses conclusions du navigateur ## Les autres causes fréquentes à vérifier dans l'ordre Une fois le `Content-Type` écarté, il faut vérifier méthodiquement : - Le fichier `robots.txt` ne doit contenir aucune règle `Disallow` qui couvre l'URL du sitemap elle-même, ce qui empêcherait Googlebot de la lire même si elle est correctement déclarée. - Une redirection en chaîne (HTTP vers HTTPS, puis www vers sans-www, par exemple) ralentit ou bloque la récupération ; une seule redirection directe est tolérée, deux ou plus posent souvent problème. - Un plugin de sécurité qui bloque les user-agents inconnus ou limite le débit de requêtes peut confondre Googlebot avec un robot indésirable si sa liste blanche est trop stricte. - Une authentification HTTP au niveau serveur (fréquente sur un environnement encore semi-public) bloque tout accès, y compris celui de Googlebot, sans que le navigateur du développeur, déjà authentifié, ne le remarque. ## Vérifier le contenu XML lui-même Une fois l'accès confirmé propre, il reste à valider que le XML est syntaxiquement correct. Un caractère mal encodé dans un titre d'article (une esperluette non échappée, par exemple) peut invalider tout le fichier alors qu'un navigateur l'affiche quand même en mode tolérant. Un outil de validation XML en ligne de commande évite ce piège : ``` xmllint --noout https://exemple.fr/wp-sitemap.xml ``` Si cette commande renvoie une erreur de parsing, la cause est presque toujours un contenu de titre ou d'extrait mal échappé, injecté directement dans le XML par un filtre personnalisé sans passer par les fonctions d'échappement adéquates. ## Une fois le blocage levé La resoumission manuelle dans Search Console n'est pas nécessaire : Google reteste un sitemap déjà déclaré à intervalle régulier, sans action de l'utilisateur. En revanche, forcer un nouveau passage via le bouton « Envoyer » permet de confirmer visuellement que la correction fonctionne, sans attendre plusieurs jours. Sur le cas traité ici, le statut est passé de « Récupération impossible » à « Réussite » en moins de deux heures après la purge du cache. > Avant de conclure à un bug de Search Console, testez toujours l'URL avec le user-agent exact de Googlebot : neuf fois sur dix, le problème est du côté du serveur, pas de l'outil Google. ## Prévenir la récidive Pour éviter que ce genre de blocage ne repasse inaperçu, il est utile d'ajouter une vérification automatisée post-déploiement qui contrôle le code de statut et le `Content-Type` de l'URL du sitemap, en plus des tests fonctionnels habituels. Un simple test dans la chaîne d'intégration continue, qui échoue si le `Content-Type` n'est pas `application/xml`, aurait détecté ce problème avant même la mise en production. ## En résumé Un sitemap qui s'affiche bien dans un navigateur ne garantit rien du point de vue d'un robot d'exploration. Le diagnostic passe systématiquement par une requête brute avec le bon user-agent, une vérification des en-têtes, puis une validation XML stricte, dans cet ordre précis pour ne pas perdre de temps sur de fausses pistes.