Comment corriger les erreurs d'exploration Google Search Console

Vous ouvrez le rapport « Indexation des pages » dans Search Console, et là, le chiffre vous saute au visage : sur 420 pages, 180 sont marquées « Explorée, non indexée ». Vous cliquez, vous lisez, vous ne comprenez pas. Vous avez un sitemap propre, des balises correctes, un site qui charge vite. Et Google vous ignore.

J'ai connu ça sur un site client : 38 % des URLs bloquées dans un statut que personne ne regarde jamais. Trois semaines plus tard, après un travail méthodique sur les causes réelles, on était retombé à 6 %. Pas de magie. Juste une lecture correcte des codes et un ordre de priorité.

Voici comment je m'y prends, concrètement, pour corriger les erreurs d'exploration dans Google Search Console — sans cliquer au hasard sur « Valider la correction » en espérant que ça passe.

Comprendre les erreurs d'exploration avant de vouloir les corriger

Googlebot est un robot. Il demande une page. Soit le serveur répond correctement, soit il répond mal, soit il ne répond pas du tout. Tout le reste découle de là.

Une erreur d'exploration, c'est le moment où Googlebot essaie d'accéder à une URL et que quelque chose bloque. Une erreur d'indexation, c'est quand Googlebot a bien récupéré la page mais décide de ne pas la mettre dans son index. La nuance paraît scolaire. Elle ne l'est pas : dans le premier cas, vous avez un problème de plomberie ; dans le second, un problème de contenu ou de signal.

Les trois familles qu'on rencontre réellement

Sur les dizaines de propriétés que j'ai auditées, les erreurs se répartissent presque toujours en trois blocs :

• Côté serveur — codes 5xx, timeouts, DNS. Googlebot n'a rien pu récupérer. Cause technique, correctif technique.
• Côté accès — blocage par robots.txt, blocage par authentification, blocage par pare-feu. Le contenu existe, mais l'accès est refusé.
• Côté choix volontaire — balise noindex, canonical pointant ailleurs. Ce n'est pas une erreur, c'est une décision. Parfois mal appliquée.

Le piège classique : traiter une balise noindex comme un bug serveur. J'ai vu un développeur passer deux jours à chercher une configuration nginx alors que le problème était une balise laissée en staging. Ça arrive plus souvent qu'on ne le croit.

Exploration contre indexation : la confusion qui coûte cher

Quand une page est bloquée par le robots.txt, Googlebot ne la lit pas du tout. Elle n'apparaît donc pas comme « explorée » — elle est simplement invisible. Et si cette page contenait une directive noindex, Google ne la verra jamais non plus. Le noindex posé sur une page déjà bloquée par robots.txt ne sert à rien.

Conséquence pratique : avant de corriger, demandez-vous à quel niveau le blocage intervient. Le diagnostic change du tout au tout.

Lire le rapport « Indexation des pages » sans se tromper

Le rapport se trouve dans le menu de gauche, section Indexation. Vous voyez un graphique, puis deux listes : « Pourquoi les pages ne sont pas indexées » et « Pourquoi les pages sont indexées ».

La première liste est celle qui compte. Elle affiche chaque motif avec un compteur. Cliquez sur un motif, vous obtenez la liste des URLs concernées, avec un bouton « Valider la correction » et un lien vers un exemple.

Les statuts qui ne sont pas des erreurs

Avant de paniquer, sachez ceci : cinq statuts sur la liste sont parfaitement normaux. Ils ne demandent aucune action.

• Page avec redirection — l'URL pointe vers une autre. Comportement voulu.
• Autre page avec balise canonical — Google a choisi une autre URL comme version principale. Normal si vous avez posé le canonical vous-même.
• Exclue par balise noindex — si c'est volontaire (page de remerciement, page de connexion), parfait.
• Page en double sans URL canonique sélectionnée par l'utilisateur — Google a dédupliqué. Souvent acceptable.
• Introuvable (404) — un 404 sur une URL qui n'existe plus, c'est sain. Un 404 sur une URL qui devrait exister, c'est un problème de lien interne.

J'ai un client qui s'acharnait à « corriger » 60 pages en 404 qui correspondaient à des anciennes catégories supprimées. Il n'y avait rien à corriger. Il aurait mieux fait de travailler sur son maillage interne.

Les statuts qui méritent une vraie intervention

Quatre motifs, en revanche, exigent souvent du travail :

• Explorée, non indexée — Googlebot a lu la page mais n'a pas jugé utile de l'indexer. Cause probable : contenu jugé faible ou redondant, absence de liens internes, page trop récente.
• Détectée, non indexée — Google sait que l'URL existe (via un lien) mais ne l'a pas encore explorée. Question de budget de crawl.
• Erreur serveur (5xx) — Googlebot a reçu une réponse serveur en erreur. Toujours technique.
• Bloquée par robots.txt — l'accès est refusé. À vérifier ligne par ligne.

Comment corriger chaque type d'erreur, cas par cas

Erreur serveur 5xx : ça se règle côté hébergement

Une 500, une 502, une 503. Aucune de ces erreurs ne se corrige dans Search Console. Si vous voyez ce motif apparaître en masse, la première chose à faire est de vérifier que votre site répond normalement depuis un navigateur, en navigation privée, et depuis un outil de test d'accessibilité.

Sur un projet, on avait 240 URLs en 5xx après une migration. La cause : une règle de réécriture Apache qui renvoyait une erreur 500 sur les anciennes URLs sans paramètre. Corrigée en une heure. Le compteur dans Search Console, lui, a mis huit jours à se stabiliser.

Ne cliquez pas sur « Valider la correction » avant d'avoir corrigé la cause. Google revérifie les URLs concernées, constate que l'erreur persiste, et marque la validation comme échouée. Ça complique le suivi inutilement.

404 contre 410 : choisir le bon code

Une page supprimée définitivement renvoie naturellement un 404. C'est acceptable. Mais si la suppression est définitive et que vous voulez accélérer la disparition de l'index, le code 410 Gone est plus explicite. Google le traite plus rapidement qu'un 404 — de mon expérience, plusieurs jours de différence sur des volumes modestes.

Pour les petites séries d'URLs obsolètes, la solution la plus propre reste la redirection 301 vers la page équivalente la plus proche. Pas vers l'accueil. Vers une page réellement similaire. Une redirection massive vers l'accueil est interprétée comme un soft 404 par Google, ce qui est pire que le 404 initial.

« Explorée, non indexée » : le statut le plus frustrant

C'est celui qui fait perdre le plus de temps. Et, avouons-le, celui que j'ai le plus mal compris au début.

Googlebot a bien exploré la page. Il a décidé de ne pas l'indexer. Pourquoi ? Les raisons les plus fréquentes, dans l'ordre où je les rencontre :

1. La page n'a aucun lien interne qui pointe vers elle. Google la connaît via le sitemap mais aucun signal de contexte.
2. Son contenu est trop proche d'une autre page déjà indexée. Google déduplique.
3. Elle est très récente. C'est un statut transitoire. Attendez quelques jours avant de toucher quoi que ce soit.
4. Le site a un budget de crawl très limité (grande quantité d'URLs, faible autorité), et Google ne juge pas prioritaire l'indexation de cette page.

La correction, dans ce cas, n'est pas technique. Elle est éditoriale : ajoutez des liens internes depuis des pages indexées et fréquentées, étoffez le contenu si nécessaire, différenciez-le de la page concurrente en interne.

Bloquée par robots.txt

Ouvrez votre fichier texte à la racine du domaine. Cherchez les lignes Disallow. Une règle trop large du type Disallow: / pendant un test en staging, oubliée en production, bloque tout.

Autre piège plus subtil : un blocage de paramètres d'URL dans le robots.txt qui empêche Googlebot d'explorer des pages dynamiques utiles. J'ai vu un site perdre 22 % de son trafic organique en deux mois à cause de ça, sans qu'aucune alerte ne m'ait été signalée dans Search Console. Le rapport montrait juste un grand nombre d'URLs bloquées, sans signal d'alarme visible.

Vérificateur d'URL et demande d'indexation : quand les utiliser

Le rapport global vous donne la vue d'ensemble. Pour une URL précise, utilisez l'inspection d'URL : zone de recherche en haut de Search Console, vous collez l'adresse complète.

Vous obtenez un verdict, un statut d'exploration, une date du dernier crawl, et un bouton « Demander l'indexation ». Ce bouton n'accélère pas magiquement l'indexation. Il place l'URL en file d'attente prioritaire. Google peut explorer dans les heures qui suivent, ou dans les jours. Et si Google juge la page inutile, il ne l'indexera pas, quelle que soit votre demande.

Faut-il demander l'indexation systématiquement ?

Non. J'en vois trop qui demandent l'indexation sur chaque page publiée, puis s'étonnent que rien ne change. Deux cas seulement justifient une demande manuelle :

• Une page récemment corrigée dont vous voulez vérifier le nouveau traitement.
• Une page à fort enjeu (page commerciale, nouvelle catégorie) publiée dans un contexte de site à faible trafic.

Pour un site qui publie vingt articles par semaine, laisser le crawl naturel faire son travail est plus sain. Le quota de demandes est limité quotidiennement, autant le garder pour les cas qui comptent.

« Valider la correction » : le bouton qui ne fait pas le travail

Ce bouton, présent sur chaque motif d'erreur, lance une revérification des URLs concernées. Il ne corrige rien. Si votre configuration serveur est encore cassée, Google revérifie, constate que l'erreur persiste, et le motif reste.

Ma règle personnelle : corriger d'abord, valider ensuite, et vérifier soi-même que la correction est effective — en testant l'URL manuellement, en vérifiant le code HTTP renvoyé. Une fois la validation lancée, comptez plusieurs jours avant d'espérer un changement de statut.

Motif	Cause probable	Action concrète	Délai de répercussion
Erreur serveur (5xx)	Configuration serveur, surcharge, erreur applicative	Corriger côté hébergement, pas dans GSC	Quelques jours à une semaine
Bloquée par robots.txt	Règle Disallow trop large	Éditer le fichier, tester, valider	Quelques jours
Explorée, non indexée	Contenu faible, pas de lien interne, page récente	Renforcer le maillage, étoffer, attendre	1 à 3 semaines
Détectée, non indexée	Budget de crawl saturé	Réduire les URLs inutiles, améliorer la structure	Variable, plusieurs semaines
404 sur URL active	Lien interne cassé	Corriger le lien ou rediriger en 301	1 à 2 semaines

La routine de suivi que j'applique

Une erreur corrigée n'est pas une erreur réglée tant que le compteur n'a pas bougé. Le suivi compte autant que la correction.

Ce que je fais sur chaque site dont j'ai la charge :

• Un export CSV du rapport Indexation des pages tous les quinze jours, avec les compteurs par motif. Comparaison avec l'export précédent.
• Un suivi des URLs critiques via inspection manuelle, une fois par semaine, sur les 10 pages à plus fort enjeu commercial.
• Une revue du robots.txt après chaque déploiement. C'est là que les erreurs arrivent.
• Une vérification des 5xx dès qu'un pic apparaît — sans attendre le rapport, un pic de 5xx signale presque toujours un incident serveur en cours.

Sur mon dernier projet, cette routine a permis de détecter un blocage robots.txt trois jours après sa mise en production plutôt que trois semaines plus tard. Trois jours, c'est déjà trop. Mais trois semaines, c'est une hémorragie.

Si vous ne devez retenir qu'une chose de cet article : une erreur d'exploration dans Search Console est un symptôme, pas une maladie. Le vrai travail se passe sur le serveur, dans le fichier robots.txt, ou dans la structure de liens internes. La console vous montre où chercher — elle ne répare rien. Et à force de voir des sites avec des centaines de statuts « non indexée » qui ne gênent personne, je me demande si le vrai problème n'est pas notre obsession du compteur à zéro. Une page non indexée qui n'a aucun intérêt pour personne n'a pas besoin d'exister.