Corriger les erreurs d'exploration et d'indexation : le guide qui débloque tout

Vous ouvrez la Search Console un lundi matin, et là : 1 247 pages « Explorée, actuellement non indexée ». Vous n'avez rien changé au site depuis six mois. Vous n'avez pas touché au robots.txt. Et pourtant, vos nouvelles fiches produit ne sortent plus dans Google. Ça vous parle ?

Ce scénario, je l'ai vécu sur un site e-commerce de 4 800 URL. Le trafic organique avait chuté de 31 % en trois semaines, sans pénalité, sans mise à jour d'algo, sans rien de visible. La cause : un paramètre de tri dans l'URL qui avait généré 40 000 pages quasi identiques, et Googlebot qui passait ses journées à explorer ces doublons au lieu de découvrir les vraies pages. Corriger les erreurs d'exploration et d'indexation, ce n'est pas cocher des cases dans la Search Console. C'est un travail de diagnostic, souvent contre-intuitif, et parfois très ingrat.

Voici comment je m'y prends aujourd'hui, avec les erreurs que j'ai commises en chemin.

Exploration et indexation : pourquoi la confusion vous coûte cher

La majorité des gens que j'accompagne mélangent les deux notions. Normal : la Search Console les présente côte à côte dans le même rapport, avec des libellés qui se ressemblent. Sauf que le traitement n'a rien à voir.

Deux étapes, deux problèmes

L'exploration (crawl), c'est Googlebot qui vient lire votre page. L'indexation, c'est Google qui décide de la garder dans son index et de la servir. Une page peut très bien être explorée dix fois et jamais indexée. Elle peut aussi n'être jamais explorée du tout.

Le statut « Explorée, actuellement non indexée » est le plus mal compris de tous. Il ne signale pas une erreur technique. Il dit : « Google a lu cette page, il l'a jugée non prioritaire ou redondante. » Dans 90 % des cas que j'ai traités, ça veut dire contenu trop faible ou trop similaire à une autre page, pas problème de serveur.

Franchement, quand j'ai débuté, je passais des heures à chercher des erreurs 500 sur des pages signalées ainsi. Perte de temps totale. Elles répondaient parfaitement, en 180 ms.

Où regarder en premier

Le rapport « Indexation des pages » de la Search Console classe les URL par motif. Ne lisez pas les 12 catégories dans l'ordre : filtrez d'abord celles qui concernent vos pages stratégiques. Une fiche produit à fort chiffre d'affaires en « Exclue par une balise noindex » est une urgence. La même chose sur une page de mentions légales ? Aucun impact.

Le tri par « Pages avec du trafic en baisse » est souvent plus parlant que la liste brute des erreurs. J'y ai trouvé, sur un site client, 340 pages qui avaient perdu leur indexation après une refonte de template. Le noindex était dans un include oublié. Zéro erreur affichée en rouge, juste des pages qui disparaissent silencieusement.

Le tableau que j'aurais aimé avoir dès le début

Aucun guide ne m'a jamais donné ça sous cette forme, alors je le construis ici. Un code d'état HTTP, une cause probable, une action. Pas de blabla.

Code / statut	Cause probable	Action corrective
5xx (500, 502, 503)	Surcharge serveur, base de données saturée, plugin qui plante	Corriger l'erreur serveur en priorité. Googlebot revient moins souvent après plusieurs 5xx.
429 (Too Many Requests)	Limitation de débit trop agressive côté hébergeur	Relever le seuil pour les IP Googlebot vérifiées, ne jamais bloquer par plage d'IP sans vérification.
4xx (403, 404)	Page supprimée, permission mal configurée, lien mort	404 naturelle = OK, Google nettoie. 403 sur une page utile = à corriger absolument.
Soft 404	Page vide, « aucun résultat », contenu introuvable affiché avec un code 200	Renvoyer un vrai 404 ou un 410, ou enrichir la page avec du contenu réel.
Explorée, non indexée	Contenu faible, doublon, cannibalisation	Fusionner, enrichir, ou désindexer volontairement. Ce n'est pas un bug.
Détectée, non indexée	Google sait que l'URL existe, mais ne l'a jamais explorée	Liens internes à ajouter, sitemap à jour, demande d'indexation manuelle.

Ce tableau m'a fait gagner un temps fou sur un audit récent. La moitié des « erreurs » signalées étaient en réalité des soft 404 sur des pages de recherche interne. On a bloqué ces URL au crawl, et le nombre de pages indexées est passé de 2 100 à 3 400 en cinq semaines. Le crawl budget libéré allait enfin où il fallait.

Le crawl budget : ce que personne ne mesure vraiment

« Optimiser son crawl budget », tout le monde en parle. Personne ne le mesure concrètement. C'est pourtant le cœur du sujet quand on dépasse quelques milliers d'URL.

Les logs serveur, seul vrai thermomètre

Ouvrez vos logs d'accès et filtrez par user-agent Googlebot. Puis observez deux choses :

1. La répartition du crawl : combien de requêtes sur des pages produit, combien sur des paramètres de tri, des paginations, des URLs de session ?
2. Les codes de réponse : un pourcentage élevé de 5xx sur une période courte peut faire chuter la fréquence d'exploration durablement.

Sur le site de 4 800 URL dont je parlais en ouverture, les logs montraient que 74 % des requêtes Googlebot portaient sur des URLs paramétrées. Une seule ligne dans le robots.txt (avec les bonnes règles, pas celles qui bloquent les ressources CSS/JS) et le ratio s'est inversé en trois semaines. Le nombre de nouvelles pages découvertes par jour a triplé.

Attention : bloquer tout et n'importe quoi dans robots.txt est une erreur classique. J'ai vu un client bloquer /? en pensant « supprimer tous les paramètres ». Il a bloqué sa pagination. Six semaines plus tard, il s'en est rendu compte parce que ses fiches produit en page 2 avaient disparu de l'index.

La fréquence d'exploration, effet secondaire d'un site lent

Un serveur qui répond en 4 secondes envoie un signal clair à Googlebot : ce site est lent, je reviendrai moins. Inversement, une réponse en 200 ms vous fait gagner en fréquence sans rien faire d'autre. Sur une boutique à 2 000 fiches, j'ai fait passer le TTFB moyen de 1,8 s à 340 ms en changeant simplement de cache serveur. Le nombre de pages explorées par jour est passé de 1 200 à 6 800 en trois semaines. Sans une ligne de SEO technique.

Le vérificateur d'URL Google, et comment l'utiliser à bon escient

Le vérificateur d'URL de la Search Console fait deux choses : il vous montre l'état d'indexation d'une URL précise, et il permet de demander une réindexation. Simple. Mal utilisé, c'est un piège.

Quand demander une indexation à Google

Demander une indexation à Google n'a de sens que sur quelques pages très stratégiques. La file d'attente est limitée par site. Si vous demandez 200 URL d'un coup, vous saturez le quota et vos vraies urgences passent à la traîne.

Ma règle : uniquement les pages qui remplissent deux conditions. Un, elles ont perdu leur indexation récemment. Deux, elles généraient du trafic réel. Le reste, laissez Google faire son travail.

L'autre usage du vérificateur, plus précieux : tester une URL avant et après correction. Vous corrigez un noindex accidentel ? Vérifiez d'abord, puis demandez. Le « Test de l'URL en direct » affiche le code d'état réel et le rendu. C'est là qu'on repère les erreurs d'inclusion de ressources, par exemple un fichier JS bloqué dans robots.txt qui casse le rendu de la page.

Combien de temps une correction met-elle à produire effet ?

Ça dépend, et j'aimerais pouvoir vous donner un chiffre magique. Sur les sites que j'ai suivis, un noindex retiré suivait une réindexation dans les 24 à 72 heures après demande manuelle. Une erreur 5xx résolue sur une catégorie entière prenait souvent deux à quatre semaines, parce que la fréquence d'exploration de la section avait chuté. Et une correction de contenu faible (fusion de doublons) : comptez un mois avant de voir l'effet sur le trafic.

Ce qu'il faut mesurer après une correction

Trois indicateurs, pas un : le nombre de pages indexées (Search Console), le nombre de pages explorées par jour (logs serveur), et le trafic organique sur les URL concernées (analytics). Une seule de ces courbes ne suffit jamais à conclure.

Trois erreurs que j'ai faites, et que vous ferez peut-être

Je préfère le dire : j'ai perdu des semaines sur des pistes fausses. Les voici, pour que vous les évitiez.

• Faire confiance aveuglément au sitemap. Un sitemap qui déclare 40 000 URL dont 12 000 renvoient des 404, c'est un signal de qualité désastreux. Google finit par ignorer le fichier. La première fois, j'ai mis six mois à comprendre.
• Confondre « Détectée, non indexée » et un vrai problème serveur. Non. Cette catégorie signifie souvent que la page n'a aucun lien interne. Ajouter trois liens entrants bien placés suffit dans beaucoup de cas, et ça coûte zéro.
• Corriger sans vérifier le rendu. Googlebot rend les pages en JavaScript. Une page qui répond en 200 mais qui casse côté JS affichera un contenu pauvre à l'exploration. J'ai corrigé un serveur entier pour réaliser que le problème était un noindex injecté par script.

Bref, le diagnostic doit se faire sur les logs et sur le rendu, pas seulement sur les codes HTTP affichés dans une interface.

Par quoi commencer, concrètement

Dans l'ordre que j'applique aujourd'hui sur un site que je ne connais pas encore :

1. Filtrer le rapport d'indexation par les 50 pages qui génèrent le plus de trafic et vérifier leur statut.
2. Extraire une semaine de logs, filtrer Googlebot, calculer la répartition des codes de réponse.
3. Identifier les catégories d'URL qui consomment du crawl pour rien (paramètres, paginations, pages de recherche interne).
4. Corriger d'abord les 5xx et les soft 404 massifs. Le reste attend.
5. Demander l'indexation des pages stratégiques une fois les corrections faites, pas avant.

Sur un site de 10 000 URL avec un crawl budget mal réparti, cette séquence a identifié la vraie cause en neuf jours. Le client, lui, cherchait depuis quatre mois dans la mauvaise direction.

Le vrai piège de l'exploration et de l'indexation, ce n'est pas la complexité technique. C'est que les erreurs sont silencieuses. Rien ne casse, rien ne s'affiche en rouge côté utilisateur. Les pages disparaissent simplement de l'index, une à une, et vous ne le remarquez que quand le trafic du trimestre a déjà fondu. Alors j'ai une question pour vous : regardez votre Search Console. Combien de pages sont en « Explorée, actuellement non indexée » ? Et surtout, savez-vous pourquoi ?