Un client m'appelle un lundi matin, paniqué : « J'ai 8 400 erreurs d'exploration dans Search Console. C'est la fin. » Je regarde le rapport. 7 600 de ces « erreurs » pointent vers les mêmes pages de filtres à facettes de sa boutique en ligne, toutes générées par un paramètre d'URL que plus personne n'utilise depuis deux ans. Rien de vital. Zéro impact sur ses pages produits.
Corriger les erreurs d'exploration Google, c'est rarement traiter le chiffre affiché en rouge. C'est comprendre pourquoi Googlebot n'arrive pas à faire son travail, puis décider quoi réparer en premier. Et ça, personne ne vous le dit clairement.
Points clés à retenir
- Une erreur d'exploration signalée par Google ne veut pas dire que votre site est cassé : elle dit que le robot n'a pas pu accéder à cette URL, à ce moment-là.
- Le rapport « Indexation des pages » de Search Console a remplacé l'ancien outil « Erreurs d'exploration », qui listait ses résultats par lots de 1 000 URL.
- 404 et 5xx ne se corrigent pas de la même façon : une 404 peut être volontaire, une 5xx annonce un problème serveur qu'il faut traiter hier.
- Le re-crawl après correction prend de quelques jours à plusieurs semaines selon l'autorité du site et la fréquence de mise à jour.
- Priorisez : une erreur sur votre page de vente vaut mille erreurs sur des archives oubliées.
Qu'est-ce qu'une erreur d'exploration, vraiment ?
Le mécanisme est simple à retenir : Google envoie un robot (Googlebot) demander une page à votre serveur. Le serveur répond par un code HTTP. Si ce code dit « tout va bien » (200), la page peut passer à l'étape suivante : l'indexation. S'il dit autre chose, le robot note l'échec et repasse plus tard.
Une erreur d'exploration, donc, n'est pas un virus ni un bogue. C'est une conversation ratée entre Googlebot et votre serveur. Le robot a frappé à la porte, personne n'a répondu correctement.
Pourquoi ça touche le référencement même quand la page existe
Parce qu'une page non explorée n'est pas indexée. Et une page non indexée ne se classe nulle part. Une fiche produit parfaitement optimisée qui renvoie une 500 depuis trois semaines est invisible, peu importe la qualité de son contenu.
J'ai vu un cas où la moitié d'un catalogue s'était déconnecté d'un coup : une migration serveur mal configurée renvoyait des 503 intermittents. Le trafic organique a chuté de 34 % en dix jours. Pas parce que Google avait « pénalisé » le site. Parce qu'il avait arrêté d'en voir la moitié.
Où voir ces erreurs aujourd'hui dans Search Console
L'ancien rapport « Erreurs d'exploration » a disparu. La correspondance actuelle est éclatée entre plusieurs endroits :
- Indexation des pages : le gros du sujet, avec les motifs de non-indexation, dont les erreurs serveur et les redirections.
- Sitemaps : utile pour repérer les URL déclarées que Google n'a jamais pu lire.
- Statistiques d'exploration : montre combien de requêtes le robot envoie et où il prend du retard.
Le piège classique : chercher un rapport nommé « erreurs » et ne rien trouver. Il faut lire les libellés de motifs, pas un seul écran dédié.
Comment corriger une erreur d'exploration, type par type
Voilà le cœur du sujet, et l'endroit où la plupart des articles restent vagues. Chaque code HTTP a son propre remède. Confondre les deux cas les plus fréquents vous fait perdre des semaines.
Erreur 404 : page introuvable
La fameuse « 404 Not Found ». Googlebot demande une URL qui n'existe plus. Trois scénarios, trois corrections.
- La page a été supprimée par erreur ou déplacée. On remet une redirection 301 de l'ancienne URL vers la nouvelle. C'est la correction la plus courante.
- La page n'existe plus et ne reviendra pas. On la laisse en 404, proprement. Ce n'est pas une erreur à « corriger » : c'est une réponse honnête. Google finit par cesser de la demander.
- Le lien vient de votre propre site. Là, on corrige la source : un menu mal pointé, un lien interne cassé dans un vieil article.
Un détail que j'ai mis des mois à comprendre : une 404 volontaire n'est pas un problème. J'ai longtemps « réparé » des 404 qui ne dérangeaient personne, par réflexe. Perte de temps. Franchement, mieux vaut rediriger ce budget d'attention vers les vrais problèmes serveur.
Erreurs 5xx : le serveur ne suit pas
500, 502, 503, 504. Ici, on ne parle plus de contenu manquant mais de machinerie qui craque. Le robot n'a pas pu obtenir de réponse valable parce que votre hébergement a lâché, qu'un plugin a planté, ou que la base de données a dépassé son quota de connexions.
La correction ne se fait jamais dans Search Console. Elle se fait côté serveur : logs d'erreurs, ressources CPU, configuration PHP, cache. Une 503 temporaire pendant une maintenance est acceptable si vous prévenez Google correctement. Un 500 permanent qui traîne, c'est la fuite qu'on ignore jusqu'à ce que le plancher cède.
Les soft 404 : le faux positif le plus vicieux
La page renvoie bien un code 200. Mais son contenu est vide, ou renvoie vers une autre page, ou affiche « aucun résultat ». Google le détecte et range la page du côté des erreurs malgré le code correct.
Correction : soit on remplit la page, soit on la passe en 404 assumée. Les pages de résultats de recherche interne, les filtres vides et les catégories sans produit tombent presque toujours dans ce piège. Ce sont d'ailleurs les premières que je désavoue avec une balise noindex.
Quel diagnostic pour quel code de retour ?
Un tableau vaut mieux qu'un long paragraphe quand il s'agit de réagir vite.
| Code renvoyé | Cause probable | Correction | Urgence |
|---|---|---|---|
| 404 | Page supprimée ou déplacée | Redirection 301 ou laisser en 404 | Moyenne |
| 5xx | Serveur, base de données, plugin | Intervention technique côté hébergement | Haute |
| Soft 404 | Contenu vide ou page de renvoi | Remplir ou noindex | Basse à moyenne |
| Bloqué par robots.txt | Règle d'exclusion trop large | Assouplir la directive | Variable |
| Redirection en boucle | Chaîne de redirections mal formée | Réduire à une seule 301 directe | Moyenne |
Le cas des redirections en chaîne
Trois redirections successives pour arriver à la bonne page, c'est une perte de budget d'exploration. Chaque saut consomme une requête. Sur un site de 20 000 URL, ces chaînes invisibles peuvent représenter une part énorme de l'activité du robot, détournée de vos pages qui comptent.
Je vérifie toujours les redirections une fois par trimestre. Ma règle : une seule 301, directe, entre l'ancienne et la nouvelle URL. Pas de détour.
Prioriser : quelles erreurs corriger en premier
Toutes les erreurs ne se valent pas. Passer trois jours sur des archives sans trafic pendant qu'une page de vente renvoie une 500, c'est travailler à l'envers.
Voici l'ordre que j'applique, et je ne le changerai pas :
- Les 5xx sur les pages stratégiques. Priorité absolue. Aucune discussion.
- Les erreurs sur les pages qui reçoivent du trafic ou convertissent. Vous savez lesquelles. Regardez vos rapports de performance.
- Les liens internes cassés que vous contrôlez vous-même. Facile, rapide, propre.
- Les redirections en boucle et chaînes. Gain de budget d'exploration sur la durée.
- Le reste, en lot, quand vous avez une demi-journée à consacrer au nettoyage.
Le critère n'est jamais le volume d'erreurs. C'est l'impact de chaque URL concernée. Un collègue m'avait montré fièrement un « passage de 12 000 à 900 erreurs » sur un site… sans aucun changement de trafic. Il avait nettoyé des pages mortes. Le score du rapport avait baissé. Le chiffre d'affaires, non.
Combien de temps après correction avant que ça disparaisse ?
Question qu'on me pose systématiquement, et la réponse honnête n'est pas rassurante : de quelques jours à plusieurs semaines. Google décide de son propre calendrier.
Comment accélérer la re-exploration
Trois leviers concrets :
- Soumettre l'URL corrigée via l'inspection d'URL et demander un nouvel indexage.
- Vérifier que votre sitemap est à jour et pointe vers les pages valides.
- S'assurer que la page corrigée reçoit des liens internes : plus une page est liée, plus vite le robot revient.
Un mot sur mon expérience : sur un petit site, la correction d'une 404 a été prise en compte en cinq jours. Sur un site de 80 000 pages, certaines corrections ont mis plus de six semaines à disparaître du rapport. La taille du site joue énormément. Ne paniquez pas si rien ne bouge la première semaine.
Les erreurs que je recommence à faire (et comment les éviter)
Avouons-le, personne ne maîtrise ça parfaitement du premier coup.
Ma bêtise récurrente : corriger la redirection mais oublier les liens internes qui pointaient encore vers l'ancienne URL. Résultat, la redirection reste sollicitée en boucle au lieu de disparaître. Maintenant, je traite toujours les deux ensemble : la 301 et la mise à jour des liens.
Autre piège : désavouer en masse des pages avec noindex, puis découvrir six mois plus tard qu'une d'elles générait en réalité des conversions par un canal détourné. Avant de noindexer, exportez toujours la liste des URL concernées et gardez-la de côté. Un fichier texte. Ça sauve.
Enfin, le plus sournois : supposer que Search Console dit la vérité sur votre serveur. Elle dit la vérité sur ce que Googlebot a observé, à un instant donné. Un problème intermittent — une 503 qui n'arrive que sous charge — peut être invisible dans le rapport et bien réel dans vos logs. Les logs serveur, eux, ne mentent pas.
Ce qu'il faut garder en tête
Corriger les erreurs d'exploration Google n'est pas une chasse au chiffre. C'est un travail de tri : comprendre le code, identifier les URL qui comptent, réparer dans le bon ordre, puis laisser le temps à Googlebot de revenir.
Le rapport vous montre un symptôme. Vos logs serveur et vos statistiques de trafic montrent la maladie. Et si je devais ne retenir qu'une chose de toutes ces années : le nombre d'erreurs affiché impressionne, mais ce qui compte, c'est combien de vos pages rentables sont bloquées là-dedans. Le reste attendra.
