Guides robots.txt

Crawl-delay dans robots.txt : Googlebot le prend-il en charge ?

Comprendre Crawl-delay, pourquoi Googlebot ne prend pas cette directive en charge et comment diagnostiquer une charge d’exploration excessive.

Par Robots.txt Tools Editorial TeamDernière vérification le 2026-09-133 min de lecture
Crawl-delay dans robots.txt : Googlebot le prend-il en charge ?

Crawl-delay apparaît dans de nombreux exemples robots.txt, mais son support n’est pas universel. Pour Google, le point essentiel est clair : Googlebot ne prend pas en charge Crawl-delay dans robots.txt. Ajouter un nombre de secondes n’impose donc pas cet intervalle entre les requêtes Googlebot.

D’autres crawlers peuvent l’implémenter comme extension. Vérifiez la documentation de l’opérateur concerné plutôt que d’appliquer la directive à tous les bots.

Exemple courant

User-agent: ExampleBot
Crawl-delay: 10

L’intention est généralement de demander environ dix secondes entre les requêtes. RFC 9309 standardise le cœur du protocole — groupes User-agent et règles Allow/Disallow — sans rendre universels tous les champs historiques.

Pourquoi Crawl-delay peut donner un faux sentiment de contrôle

Si le crawler ignore la directive, rien ne change. La cause réelle d’une surcharge peut être :

  • explosion d’URL de filtres ou facettes ;
  • calendriers, recherches ou paramètres quasi infinis ;
  • réponses 5xx déclenchant des tentatives ;
  • bot ne respectant pas robots.txt ;
  • autre User-agent que celui ciblé ;
  • application lente rendant coûteux un volume normal.

Commencez par les logs : User-agent, fréquence, chemins et codes HTTP.

Ne pas utiliser 401 ou 403 pour ralentir Googlebot

Google traite la plupart des 4xx sur /robots.txt, sauf 429, comme l’absence de fichier robots.txt valide. Cela peut supprimer les restrictions que vous vouliez justement transmettre.

HTTP/1.1 403 Forbidden

n’est donc pas une méthode de réglage du rythme de Googlebot.

429 et 5xx sont différents

429 Too Many Requests et les erreurs serveur signalent surcharge ou indisponibilité et peuvent réduire temporairement l’exploration. Ils ne remplacent pas une architecture saine.

Corrigez d’abord les espaces d’URL accidentels, bloquez uniquement les chemins inutiles, améliorez cache/capacité et utilisez les contrôles documentés par le fournisseur lorsque disponibles.

Pour des chemins inutiles, utiliser Disallow avec précision

User-agent: *
Disallow: /recherche-interne/
Disallow: /cart/
Disallow: /session/

Sitemap: https://example.com/sitemap.xml

Cela réduit les requêtes vers ces zones au lieu d’espacer toutes les requêtes. Disallow ne remplace pas noindex.

Sur les grands sites, viser l’efficacité d’exploration

Pour les boutiques, marketplaces et médias, surveillez surtout si les crawlers atteignent les pages canoniques importantes sans gaspiller leur activité sur filtres, tris, sessions, previews ou paginations à faible valeur.

Diagnostic recommandé

  • identifier le crawler dans les logs ;
  • confirmer son éventuel support de Crawl-delay ;
  • mesurer volume et chemins les plus sollicités ;
  • rechercher les explosions d’URL ;
  • vérifier statut, taille et encodage de /robots.txt ;
  • confirmer que pages et ressources essentielles restent accessibles ;
  • analyser 429 et 5xx ;
  • tester les modifications sur des URL réelles ;
  • suivre les logs après déploiement.

Pour Googlebot : ne comptez pas sur Crawl-delay; utilisez les mécanismes réellement pris en charge et corrigez les causes structurelles de la charge.

Guides associés