Googlebot ignore-t-il vraiment la directive crawl-delay dans votre robots.txt ?

Qu'est-ce que la directive crawl-delay et pourquoi existe-t-elle ?

La directive crawl-delay a été introduite dans le standard robots.txt pour permettre aux webmasters de définir un délai minimum entre deux requêtes consécutives d'un bot. Elle vise à protéger les serveurs fragiles contre une surcharge causée par un crawl trop agressif.

Initialement supportée par des moteurs comme Bing ou Yandex, cette directive a toujours été ignorée par Google. La déclaration officielle le confirme sans ambiguïté : Googlebot ne l'interprète pas, point final.

Comment Google gère-t-il alors la fréquence de crawl ?

Google utilise un système d'ajustement dynamique basé sur les signaux de santé de votre infrastructure. Si votre serveur répond rapidement sans erreur, Googlebot accélère. Si des erreurs 5xx apparaissent ou que les temps de réponse s'allongent, le bot ralentit automatiquement.

Cette approche repose sur l'hypothèse que les serveurs modernes sont capables de gérer des pics de trafic. Google estime qu'une pause fixe entre requêtes est obsolète comparée à un mécanisme réactif.

Pourquoi Google maintient-il cette position ?

La réponse tient en un mot : efficacité. Google veut explorer le web le plus rapidement possible sans attendre des délais arbitraires. Un serveur bien configuré avec CDN, cache et infrastructure scalable n'a pas besoin de crawl-delay.

Le problème ? Tous les sites ne disposent pas d'une infrastructure moderne. Les petits sites sur hébergements mutualisés ou serveurs sous-dimensionnés peuvent souffrir de cette politique.

• Googlebot ignore crawl-delay : aucune exception à cette règle
• L'ajustement est automatique : basé sur les performances réelles du serveur
• Aucun contrôle manuel direct : vous ne pouvez pas forcer un ralentissement via robots.txt
• Search Console reste votre seul levier : modification du taux de crawl pour cas critiques
• Infrastructure déterminante : serveurs lents pénalisés de facto

Cette déclaration correspond-elle à la réalité terrain ?

Oui, et c'est cohérent avec ce qu'on observe depuis des années. Googlebot n'a jamais respecté crawl-delay, même quand des webmasters configuraient des valeurs de 5 ou 10 secondes. Les logs serveur confirment que le bot enchaîne les requêtes sans tenir compte de cette directive.

Par contre, l'affirmation selon laquelle "les serveurs sont suffisamment dynamiques" mérite nuance. En pratique, des milliers de sites tournent sur des hébergements partagés à 5€/mois qui ne supportent pas 20 requêtes/seconde. Google sous-estime cette réalité ou préfère l'ignorer.

L'ajustement automatique fonctionne-t-il vraiment ?

Dans la majorité des cas, oui. Quand votre serveur commence à renvoyer des erreurs 503 ou 504, Googlebot réduit effectivement son intensité. J'ai constaté des réductions de 70% du crawl après une série d'erreurs serveur sur plusieurs clients.

Le hic : ce mécanisme est réactif, pas préventif. Google attend que votre serveur montre des signes de faiblesse pour ralentir. Entre-temps, votre site a déjà subi une surcharge, avec potentiellement des impacts sur les utilisateurs réels. [À vérifier] : Google ne communique pas sur les seuils exacts déclenchant le ralentissement.

Quelles alternatives concrètes pour contrôler le crawl ?

La Search Console permet encore (pour combien de temps ?) d'ajuster le taux de crawl, mais uniquement à la baisse et dans des cas exceptionnels. Cette option disparaît progressivement de l'interface, remplacée par un message invitant à améliorer l'infrastructure.

Les vraies solutions passent par l'optimisation technique : mise en place d'un CDN pour les ressources statiques, configuration agressive du cache serveur, monitoring des temps de réponse. Si votre serveur tient sous charge normale, Googlebot n'a aucune raison de ralentir — et vous n'avez aucun moyen de le forcer à le faire.

Que faire si votre serveur souffre d'un crawl trop agressif ?

Première étape : analysez vos logs serveur pour confirmer que Googlebot est bien responsable de la surcharge. Parfois, d'autres bots (Bing, SEMrush, Ahrefs) sont plus gourmands. Isolez le user-agent Googlebot et comptez les requêtes par tranche horaire.

Si le crawl Google est effectivement problématique, concentrez-vous sur l'optimisation des temps de réponse. Activez la compression GZIP, optimisez vos requêtes BDD, réduisez le TTFB. Plus votre serveur répond vite, moins Googlebot reste longtemps connecté.

Quelles erreurs éviter absolument ?

Ne bloquez pas Googlebot dans robots.txt en espérant réduire la charge. Vous tuerez votre référencement. Ne configurez pas de rate limiting au niveau firewall trop agressif : risque de bannir temporairement le bot et de ralentir l'indexation de vos nouveaux contenus.

Évitez aussi de croire qu'ajouter crawl-delay changera quoi que ce soit pour Google. Cette directive ne sert qu'à contrôler Bingbot, Yandex ou des crawlers tiers. Pour Googlebot, elle est invisible.

Comment vérifier que votre infrastructure est adaptée ?

Consultez la section Statistiques d'exploration dans Search Console. Si vous voyez des pics d'erreurs serveur (5xx) corrélés à des hausses de crawl, votre infrastructure est sous-dimensionnée. Objectif : maintenir un taux d'erreur inférieur à 1%.

Testez la capacité de charge avec des outils comme Apache Bench ou Load Impact. Simulez 50 requêtes concurrentes et observez les temps de réponse. S'ils explosent au-delà de 2 secondes, investissez dans l'upgrade serveur ou la migration vers un hébergement scalable.

• Analysez les logs pour isoler les requêtes Googlebot et quantifier la charge
• Optimisez TTFB, compression, et cache serveur pour réduire le temps de crawl par page
• Surveillez les erreurs 5xx dans Search Console et corrigez immédiatement les sources
• Ne comptez jamais sur crawl-delay pour ralentir Google — investissez dans l'infrastructure
• Envisagez un CDN pour soulager votre serveur origine des ressources statiques
• Documentez les patterns de crawl pour anticiper les pics et adapter les ressources