Erreurs d'exploration : comment les corriger

Une erreur d'exploration, c'est un obstacle technique qui empêche un robot comme Googlebot d'atteindre une page ou d'en récupérer correctement le contenu : un serveur qui ne répond pas, une redirection qui tourne en boucle sur elle-même, une ressource bloquée par le fichier robots.txt. Ce n'est pas la même chose qu'un problème d'indexation, et la confusion coûte du temps. Une page peut être parfaitement explorée — le robot la récupère sans difficulté, reçoit un code 200, lit le contenu en entier — et rester malgré tout absente de l'index, parce que Google juge le contenu trop proche d'une autre page, de trop faible valeur, ou parce qu'une balise noindex le lui interdit explicitement. L'exploration, c'est l'accès à la page. L'indexation, c'est la décision, prise une fois l'accès obtenu, de la conserver ou non.

Ce guide reste concentré sur le premier point : reconnaître une erreur d'exploration, savoir où elle apparaît, comprendre ce qui la cause selon sa nature, et surtout apprendre à trier une longue liste plutôt que de viser un chiffre nul — un objectif d'ailleurs illusoire, puisqu'un site vivant génère en permanence des erreurs sans conséquence.

Où observer vos erreurs d'exploration

Deux rapports de Search Console couvrent la question, et ils ne racontent pas la même histoire. Le rapport d'indexation des pages liste chaque URL connue de Google avec la raison précise de sa non-indexation ; plusieurs de ces raisons sont en réalité des erreurs d'exploration déguisées en statut d'indexation, comme Erreur serveur (5xx), Erreur de redirection ou Bloquée par robots.txt. Le rapport Statistiques d'exploration montre lui la répartition des codes réponse reçus par Googlebot sur les 90 derniers jours, ventilée par type de fichier, par objectif de la requête et par hôte.

Ce même rapport contient un panneau distinct, l'état de l'hôte, qui sépare trois signaux que beaucoup de sites confondent : la récupération du fichier robots.txt, la résolution DNS et la connectivité au serveur. Un problème sur l'un de ces trois points bloque l'exploration de tout le site, pas d'une page isolée — le premier endroit à vérifier en cas de chute brutale du nombre de pages explorées.

• Rapport Pages (Indexation) : la raison exacte, URL par URL.
• Statistiques d'exploration : la tendance des codes réponse dans le temps.
• État de l'hôte : robots.txt, DNS, connectivité — trois pannes distinctes.
• Journaux serveur : la source la plus fiable des quatre, chaque requête de chaque robot avec son code réel, sans l'échantillonnage ni le décalage de quelques heures à deux jours propres à Search Console.

Erreurs serveur (5xx) : la priorité absolue

Un code 5xx signifie que le serveur a reçu la requête mais n'a pas su y répondre : 500 pour une erreur générique côté application, 502 quand un serveur intermédiaire reçoit une réponse invalide de l'origine, 503 quand le service est temporairement indisponible, 504 quand l'origine met trop de temps à répondre. C'est la catégorie la plus urgente, parce qu'elle touche potentiellement l'ensemble du site, et parce que Google ralentit volontairement sa fréquence d'exploration dès qu'il rencontre trop d'erreurs 5xx sur un domaine — un mécanisme de protection qui, laissé sans réponse, réduit encore la visibilité du site.

La question à trancher est celle de la fréquence : une poignée de 500 ponctuels sur une fenêtre de quelques minutes correspond en général à un pic de charge ou à un déploiement. Un taux élevé et constant pointe vers autre chose — ressources saturées, règle de pare-feu bloquant le user-agent du robot, chemin de code cassé par un déploiement récent — à situer en croisant la courbe du rapport avec vos propres journaux.

Une exception mérite d'être connue : un 503 volontaire pendant une maintenance planifiée est le comportement correct, pas une erreur à corriger. C'est même le code recommandé, parce qu'il indique explicitement au robot qu'il s'agit d'une interruption temporaire.

Pages introuvables (404) : un problème, ou pas

Un 404 signale qu'une URL demandée n'existe plus, ou n'a jamais existé à cette adresse. C'est la catégorie où le réflexe de vouloir tout corriger fait le plus perdre de temps : un 404 sur une page supprimée volontairement, sans remplacement prévu, n'est pas un problème à résoudre — c'est le comportement attendu. Un produit retiré du catalogue, une page de campagne expirée, un contenu obsolète effacé sans successeur : ce sont des 404 sains, que Google traite comme un signal normal plutôt qu'une pénalité.

Ce qui distingue un 404 anodin d'un 404 qui mérite une action, c'est le contexte de l'URL, pas le code lui-même.

• 404 atteint uniquement par un lien externe ancien ou une recherche directe : généralement sans conséquence.
• 404 atteint par un lien interne encore actif sur le site : corrigez le lien, pas la page.
• 404 sur une URL avec un historique de trafic organique ou des backlinks entrants : une redirection 301 vers l'équivalent le plus proche préserve la valeur acquise.
• Vague soudaine de 404 sur tout un répertoire : presque toujours un problème de déploiement, pas des suppressions individuelles.

Chaînes et boucles de redirection

Une chaîne de redirection, c'est une URL A qui redirige vers B, qui redirige vers C, qui redirige enfin vers D : le robot suit chaque saut, ce qui consomme du budget d'exploration à chaque étape. Une boucle, elle, ne se résout jamais — A renvoie vers B, qui renvoie vers A — et le robot finit par abandonner, ce qui rend la page inaccessible au même titre qu'une erreur serveur.

Ces situations s'accumulent toujours de la même façon : une règle ajoutée à chaque migration sans nettoyer les précédentes, jusqu'à ce qu'une URL empile trois ou quatre règles héritées — souvent les combinaisons www/non-www et http/https posées en couches par-dessus des redirections spécifiques.

La correction ne consiste pas à ajouter une règle de plus, mais à retrouver la destination finale réelle et à faire pointer la source directement vers elle, en un seul saut. Un audit du fichier de configuration après chaque migration évite que ces chaînes ne se reconstituent.

Bloqué par robots.txt

Une exclusion par robots.txt n'est pas automatiquement une erreur : c'est souvent un choix délibéré, pour tenir les robots à l'écart des pages d'administration, des résultats de recherche interne, des URLs à facettes ou d'un environnement de préproduction. Le problème apparaît quand la règle est trop large et attrape, sans intention, des ressources dont Google a besoin pour comprendre la page — feuilles de style, scripts, images — ou pire, des pages de contenu que vous voulez réellement voir indexées.

Le cas le plus courant reste la règle de préproduction copiée telle quelle en production, ou un motif générique mal placé qui recoupe une portion de contenu réel sans que personne ne l'ait remarqué. L'outil d'inspection d'URL indique la règle exacte qui bloque une adresse donnée — le moyen le plus direct de confirmer l'origine du blocage.

• Resserrez le motif au lieu de supprimer la règle entière : une exception Allow ciblée règle souvent le cas.
• Vérifiez qu'aucune ligne héritée d'un environnement de test ne subsiste en production.

Erreurs DNS et de connectivité

Ces deux catégories sont plus rares mais plus sévères, parce qu'elles empêchent le robot d'atteindre le site tout entier, avant même qu'un code réponse ait pu être émis. Une erreur DNS signifie que le nom de domaine ne s'est pas résolu au moment de la tentative — souvent un changement d'enregistrements mal propagé ou une migration d'hébergeur incomplète. Une erreur de connectivité signifie que le serveur a été contacté mais n'a pas établi la connexion à temps, souvent à cause d'une règle de limitation de débit ou de blocage de bots trop agressive, qui ne distingue pas un robot légitime d'un trafic indésirable.

Le panneau état de l'hôte isole ces deux signaux des codes réponse classiques. Faites correspondre le moment précis de l'incident avec tout changement récent de DNS, de pare-feu ou de CDN, et vérifiez que les plages d'IP et le user-agent des robots légitimes figurent parmi les exceptions de toute règle de gestion de bots.

Soft 404 : la page qui répond mais ne dit rien

Un soft 404 est une page qui répond avec un code 200, comme si tout allait bien, alors que son contenu dit l'inverse : une fiche produit vide affichant article non disponible, une page de résultats de recherche interne sans résultat, une annonce expirée dont le contenu a été retiré mais dont le gabarit reste en ligne. Google détecte ce décalage entre le code technique et le contenu réel, et traite la page comme si elle n'existait pas — sans jamais renvoyer un vrai 404, ce qui le rend plus difficile à repérer qu'une erreur classique.

La correction dépend de ce que la page devrait réellement être. Si le contenu a définitivement disparu, le bon geste est de renvoyer un vrai code 404 ou 410. Si la page doit rester valide — un produit provisoirement en rupture, par exemple — la solution est de la remplir d'un contenu utile : produits alternatifs, disponibilité annoncée, articles proches, plutôt que de la vider et de compter sur le code réponse pour porter le message à sa place.

Trier la liste et vérifier qu'un correctif a vraiment fonctionné

Un site actif affichera toujours des erreurs d'exploration ; viser zéro n'est pas seulement irréaliste, ce n'est pas non plus l'objectif utile. La bonne question n'est pas combien d'erreurs reste-t-il, mais lesquelles comptent.

Une fois le correctif déployé, corriger le code ne suffit pas à clore le dossier : encore faut-il confirmer que Google le voit. L'outil d'inspection d'URL propose une fonction Tester l'URL en direct, qui interroge la page telle que Google la reçoit à l'instant présent — utile parce qu'un cache navigateur ou un nœud CDN en retard peuvent donner l'illusion d'une correction alors que le robot voit encore l'ancienne version. Une demande d'indexation peut ensuite être envoyée depuis ce même outil ; c'est une requête, pas une garantie.

Le vrai signal de confirmation vient du suivi dans le temps : surveillez la courbe des Statistiques d'exploration sur les jours suivants, et croisez-la avec vos journaux serveur pour vérifier que les requêtes des robots reçoivent bien désormais le code attendu. Un mot de prudence : l'affichage de Search Console reste en retard sur la réalité de quelques heures à deux jours, parce qu'il s'agit d'un rapport agrégé et non d'un flux en direct — voir une erreur corrigée subsister encore un jour ou deux dans le tableau de bord n'est pas un échec du correctif, c'est simplement le rapport qui n'a pas encore rattrapé son retard.

• L'impact d'abord : une erreur sur une URL avec un historique de trafic organique réel ou des backlinks entrants passe avant une erreur sur une page qui n'a jamais généré la moindre visite.
• Le volume et la portée : une erreur qui touche un gabarit ou un répertoire entier — des milliers d'URLs d'un coup — prime sur une erreur isolée.
• La fraîcheur : une erreur apparue juste après une mise en production récente mérite d'être vérifiée en priorité, parce qu'elle sent la régression plutôt que le bruit de fond habituel.
• Le type : les 5xx et les pannes DNS ou de connectivité passent avant tout le reste, parce qu'elles menacent l'accès au site entier ; viennent ensuite les boucles de redirection, puis les 404 à historique, puis les blocages robots.txt mal calibrés, et enfin les soft 404 isolés.