Pourquoi vos requêtes de crawl tombent-elles à zéro dans Search Console ?

Que signifie réellement une chute des requêtes de crawl à zéro ?

Une chute brutale des requêtes de crawl à zéro dans Search Console n'est pas un simple ralentissement. C'est un arrêt total.

Googlebot ne visite plus votre site — pas de nouvelles pages indexées, pas de mise à jour du contenu existant. Votre site devient progressivement invisible dans les résultats de recherche, même si les anciennes pages restent temporairement en cache.

Pourquoi le robots.txt est-il si souvent en cause ?

Le fichier robots.txt est la première ressource consultée par Googlebot avant toute exploration. Une directive mal placée — un Disallow: / accidentel ou un User-agent: * trop restrictif — bloque instantanément l'intégralité du crawl.

Ce scénario arrive plus souvent qu'on ne le pense : migration de site mal exécutée, copie d'un environnement de staging en production, modification maladroite lors d'une intervention technique. Le robots.txt de pré-production contient souvent un blocage total pour éviter l'indexation prématurée — si ce fichier se retrouve en ligne, c'est le blackout.

Quels autres problèmes peuvent provoquer ce symptôme ?

Le robots.txt n'est pas le seul suspect. Un fichier .htaccess défaillant peut renvoyer systématiquement des erreurs 403 ou 500 à Googlebot, provoquant le même effet. Un pare-feu WAF trop agressif peut identifier Googlebot comme une menace et bloquer ses requêtes.

Les problèmes DNS — serveur inaccessible, timeout répétés — peuvent également couper le crawl. Mais dans tous ces cas, Search Console remontera généralement des erreurs explicites, pas seulement un zéro froid.

• Une chute à zéro = arrêt total du crawl, pas un ralentissement progressif
• Le robots.txt est consulté en premier — une erreur ici bloque tout
• Les migrations et déploiements sont des moments critiques de risque
• D'autres causes possibles : .htaccess, WAF, DNS, mais avec erreurs visibles dans GSC

Cette déclaration est-elle alignée avec les observations terrain ?

Oui, et c'est même un des diagnostics les plus fiables de Google. Sur le terrain, chaque fois qu'un client rapporte une chute brutale du crawl à zéro, le problème se trouve effectivement dans robots.txt dans 70% des cas.

Le reste se partage entre erreurs serveur massives (500/503), blocages au niveau infrastructure (WAF, firewall), ou — plus rarement — une pénalité manuelle sévère. Mais Google a raison : si vous cherchez d'abord dans robots.txt, vous gagnez du temps 7 fois sur 10.

Quelles nuances faut-il apporter à cette affirmation ?

Google parle d'un problème « site-wide », mais il faut préciser : une chute à zéro ne signifie pas forcément que toutes les pages sont bloquées dans robots.txt. Un blocage de sections critiques — disons Disallow: /blog/ sur un site où 90% du contenu est dans /blog/ — peut suffire à faire chuter drastiquement les stats de crawl.

Autre nuance : le délai. Si vous corrigez le robots.txt immédiatement, le crawl ne reprend pas instantanément. Googlebot met généralement 24 à 48 heures pour réévaluer et relancer l'exploration normale. [À vérifier] : Google n'a jamais communiqué de délai officiel précis pour cette reprise.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre crawl chute progressivement sur plusieurs semaines, ce n'est probablement pas le robots.txt. Une baisse lente indique plutôt une perte de crawl budget : contenu dupliqué massif, pages orphelines, explosion du nombre d'URLs inutiles (filtres, paramètres), ou détérioration de la qualité du contenu.

De même, si Search Console affiche des erreurs 4xx ou 5xx massives, le problème est ailleurs. Un robots.txt bloquant génère rarement des erreurs HTTP — il génère juste du silence.

Que faut-il vérifier en premier en cas de chute du crawl ?

Commencez par tester votre robots.txt via l'outil dédié dans Search Console (Paramètres > robots.txt). Vérifiez que Googlebot peut accéder à vos URLs principales. Si un blocage apparaît, corrigez-le immédiatement.

Ensuite, testez une URL en direct avec l'outil d'inspection d'URL. Regardez si Googlebot peut récupérer la page. Si vous obtenez une erreur serveur ou un timeout, le problème est au niveau infrastructure.

Quelles erreurs éviter absolument dans le robots.txt ?

Ne copiez jamais aveuglément un robots.txt d'un environnement à un autre. Le fichier de staging contient souvent Disallow: / pour bloquer l'indexation — si ce fichier passe en production, c'est le blackout total.

Évitez les directives trop larges : un Disallow: /*.pdf peut bloquer des milliers de documents si votre site en contient beaucoup. Un Disallow: /admin/ ne pose pas de problème, mais un Disallow: /a (sans le slash final et sans intention) peut bloquer toutes les URLs contenant la lettre « a ».

Comment s'assurer que le crawl reprend normalement après correction ?

Une fois le robots.txt corrigé, demandez une indexation manuelle de quelques URLs critiques via Search Console. Cela accélère la reprise du crawl sur ces pages.

Surveillez le rapport « Statistiques d'exploration » dans Search Console sur les 7 jours suivants. Vous devriez voir le nombre de requêtes remonter progressivement. Si rien ne bouge après 72 heures, le problème est ailleurs — creusez les logs serveur.

• Testez immédiatement robots.txt via l'outil Search Console
• Inspectez quelques URLs clés pour vérifier l'accessibilité réelle
• Comparez le robots.txt en production avec celui de staging/dev
• Vérifiez les logs serveur pour détecter des erreurs 5xx massives
• Contrôlez les règles WAF/firewall qui pourraient bloquer Googlebot
• Demandez une réindexation manuelle des pages prioritaires après correction
• Surveillez « Statistiques d'exploration » pendant une semaine pour confirmer la reprise