Un client m'appelle un mardi matin, paniqué : « Le site a perdu 40 % de son trafic en dix jours, et je n'ai touché à rien. » Je me connecte à sa Search Console. Le rapport « Statistiques de l'exploration » affiche une courbe de téléchargements qui s'est effondrée à partir du 3 du mois. Aucune alerte. Aucun e-mail. Juste une ligne qui plonge, et personne ne l'avait regardée.
C'est le problème numéro un de la Search Console : l'outil ne vous prévient pas. Il vous montre. Encore faut-il savoir où regarder, et surtout comment lire les chiffres. Utiliser Google Search Console pour détecter les problèmes de crawl, ce n'est pas consulter un tableau de bord une fois par trimestre. C'est une méthode de diagnostic, avec des seuils, des corrélations et des pièges.
Points clés à retenir
- Le rapport Statistiques de l'exploration vit dans Paramètres, tout en bas — c'est l'endroit que tout le monde oublie.
- Une chute du nombre de crawls ne veut pas dire « problème » : elle veut souvent dire « Google a fini son travail ».
- Le vrai signal, c'est le temps de réponse moyen et la taille des réponses téléchargées, pas le volume brut.
- Différencier une erreur DNS, un timeout, un blocage robots.txt et un 403 demande de croiser le rapport crawl avec le rapport d'indexation.
- Corriger une anomalie serveur sans redemander une exploration laisse le problème visible pendant des semaines.
Où se cachent réellement les données de crawl dans la Search Console
Franchement, l'emplacement est contre-intuitif. On s'attend à un rapport « Crawl » dans le menu de gauche, entre « Indexation » et « Expérience ». Il n'existe pas. Il faut aller dans Paramètres, puis descendre dans la section « Statistiques de l'exploration », et cliquer sur « Ouvrir le rapport ».
Je l'ai cherché pendant vingt minutes la première fois. Avouons-le, c'est mal fichu.
Ce que le rapport affiche vraiment
Trois graphiques, et c'est tout. Nombre total de requêtes d'exploration, taille des réponses téléchargées en kilo-octets, et temps de réponse moyen en millisecondes. Chacun filtrable par type de fichier (HTML, image, CSS, JavaScript, PDF) et par état de réponse.
Ces courbes couvrent les trois derniers mois. Pas plus. Si votre incident date de quatre mois, vous ne verrez rien — d'où l'intérêt d'enregistrer une capture d'écran chaque début de mois. Oui, à la main. Je le fais pour une dizaine de sites, ça me prend dix minutes et ça m'a sauvé deux fois.
Lire les bonnes lignes, pas la plus visible
La courbe du haut, celle du volume, attire tous les regards. C'est une erreur. Un site de 800 pages correctement optimisé voit son nombre de crawls baisser après une phase de nettoyage. Google a exploré ce qu'il devait explorer, il espace ses visites. Rien d'anormal.
Ce qu'il faut surveiller :
- Le temps de réponse moyen, qui doit rester sous la barre des 400-500 ms pour du HTML ; au-delà de 1 500 ms, Googlebot ralentit tout seul son rythme.
- La taille moyenne des réponses, qui explose quand un plugin épaissit le HTML sans que personne ne s'en aperçoive.
- La répartition des états de réponse : une part de 2xx qui recule au profit des 5xx est un signal d'alerte immédiat.
- Le ratio entre explorations d'images et explorations de pages.
Comment diagnostiquer une anomalie d'exploration, étape par étape
Le rapport vous dit qu'il y a un problème. Il ne vous dit jamais pourquoi. Voici la démarche que j'applique, dans cet ordre précis, parce que l'inverse fait perdre des heures.
Étape 1 : isoler le composant touché
Filtrez par type de fichier. Si les requêtes HTML s'effondrent mais que les images continuent d'être explorées normalement, vous avez éliminé d'un coup toute la famille des problèmes réseau et DNS. Le serveur répond, il répond juste mal aux pages.
Si tout chute en même temps — HTML, CSS, images, JS — alors le problème est en amont : hébergement, pare-feu, certificat, ou blocage global. Sur un site e-commerce que je suivais, cette simultanéité avait mis trois jours à être comprise : un WAF mal configuré renvoyait un 403 à l'IP de Googlebot après une mise à jour de sécurité. Le site fonctionnait parfaitement dans un navigateur. Seul le rapport de crawl le voyait.
Étape 2 : croiser avec le rapport d'indexation
Une anomalie de crawl n'a d'impact réel que si des pages sortent de l'index. Comparez la période suspecte avec le rapport « Pages » de la section Indexation. Si les explorations reprennent mais que le nombre de pages indexées continue de baisser, vous avez un problème de qualité, pas d'accès. Deux causes radicalement différentes.
Étape 3 : reproduire la requête manuellement
L'inspection d'URL vous donne le verdict de Google sur une page précise. Le plus utile : le champ « Dernière exploration » et le statut de récupération. Si une page testée en direct renvoie 200 alors que le rapport de crawl affiche des 5xx sur cette même URL, vous cherchez un problème intermittent — timeouts de base de données, montée en charge, cron mal placé.
Ce type d'erreur est le plus pénible. Elle apparaît à 3 h du matin et disparaît à 9 h.
Tableau de diagnostic : quel signal pour quelle cause
| Signal observé | Cause probable | Premier réflexe |
|---|---|---|
| Temps de réponse moyen > 2 000 ms sur HTML uniquement | Requêtes SQL lentes, cache absent | Activer un cache page, profiler la base |
| Chute simultanée de tous les types de fichiers | Pare-feu, DNS, certificat | Vérifier les logs serveur aux heures de crawl |
| Beaucoup de 403 sur un type d'URL précis | Règle de sécurité ciblée | Autoriser l'IP de Googlebot sur ce chemin |
| Volume stable, taille des réponses en hausse de 60 % | HTML gonflé par un module | Comparer une page avant/après la mise à jour |
| Explorations en baisse, indexation stable | Comportement normal, budget maîtrisé | Ne rien faire, surveiller |
Un mot sur les redirections. Une chaîne de trois redirections successives ne produit pas d'erreur dans le rapport de crawl. Elle consomme simplement du budget pour rien. J'ai nettoyé une chaîne de cinq redirections sur un ancien blog : 1 200 pages concernées, un tiers du budget de crawl gaspillé, aucune ligne rouge nulle part. Le rapport ne vous le dira jamais. Il faut le chercher dans les données de performance, en filtrant les pages qui reçoivent des clics sans se positionner.
Après correction : le piège du rapport qui reste rouge
Vous corrigez. Le serveur va mieux. Le rapport continue d'afficher l'anomalie. Normal — les données de crawl ont jusqu'à quelques jours de décalage, et le graphique conserve l'historique.
Ce qui compte, c'est de redemander explicitement une exploration. Sans cette demande, Google reviendra quand il reviendra, parfois dans trois semaines sur une page de faible priorité. Dans la Search Console, l'inspection d'URL permet de soumettre une page individuelle. Pour un lot, vous pouvez resoumettre un sitemap, ce qui n'est pas une garantie mais accélère le mouvement.
Combien de temps avant de voir un retour à la normale ?
Sur les cas que j'ai traités, comptez entre sept et vingt et un jours avant que la courbe reprenne sa pente. Un site d'actualité, exploré en continu, remonte en une semaine. Un site vitrine de 200 pages met facilement trois semaines. Ne tirez aucune conclusion avant ce délai, sinon vous allez « corriger » un problème déjà réglé et en créer un vrai.
Les données de crawl ne vivent pas seules
Deux compléments que personne n'utilise assez. D'abord, la Search Console expose une API : vous pouvez aspirer les données de crawl tous les jours et les stocker sur plusieurs années. C'est la seule façon de comparer cette année à l'an dernier, puisque l'interface n'affiche que trois mois.
Ensuite, le rapport de crawl de Bing s'obtient par un outil distinct, avec sa propre inscription. Utile quand vous suspectez un blocage côté robots.txt : si Bing explore sans souci et Google non, la règle en cause est presque toujours une directive propre à Googlebot. Inversez le test pour confirmer.
Et cette question qu'on me pose souvent : à quoi sert vraiment la Search Console, au fond ? Pas à mesurer le trafic — d'autres outils le font mieux. Elle sert à voir le site tel que Google le voit, et ce regard-là n'est disponible nulle part ailleurs. Le crawl en est la couche la plus basse, la plus technique, celle qu'on ne consulte que le jour où ça casse. C'est précisément pour ça qu'il faut la regarder tous les mois, quand tout va bien.
Une dernière chose. Ce client du mardi matin avait un serveur qui saturait entre 2 h et 4 h du matin, à cause d'une sauvegarde automatique mal planifiée qui écrasait les ressources exactement pendant la fenêtre de crawl. Coût de la correction : déplacer un cron de quatre heures. Personne n'avait pensé à regarder l'heure des pics sur le graphique. Elle était là, en abscisse, depuis le début.
