Pourquoi Googlebot ralentit-il son crawl sur votre site et comment l'éviter ?

Comment Google décide-t-il de la fréquence de crawl ?

Googlebot n'arrive pas sur votre site en mode bulldozer. Il ajuste sa cadence en fonction de multiples signaux, et le temps de réponse serveur en fait partie. Si vos pages mettent 2 secondes à répondre au lieu de 200 millisecondes, le bot va naturellement espacer ses requêtes.

Cette logique repose sur un principe simple : Google ne veut pas être responsable d'un crash serveur ou d'une dégradation de service pour vos vrais utilisateurs. Le crawl budget alloué à votre domaine n'est pas une constante figée, c'est un équilibre dynamique entre ce que Google veut explorer et ce que votre infrastructure peut supporter.

Quelle est la différence entre temps de réponse et vitesse de chargement ?

Le temps de réponse serveur (TTFB) mesure le délai avant le premier octet reçu. C'est ce qui compte pour Googlebot en mode crawl. La vitesse de chargement complète d'une page, elle, inclut le téléchargement de tous les assets, le JavaScript, les CSS.

Google peut crawler une page sans exécuter tout le JavaScript. Ce qui l'intéresse d'abord, c'est le HTML brut. Un TTFB élevé signale un problème backend : requêtes SQL lentes, cache défaillant, serveur sous-dimensionné. Et c'est précisément ce signal qui déclenche la réduction automatique de fréquence.

Cette réduction est-elle temporaire ou permanente ?

Google ne pénalise pas définitivement un site lent. Si vous corrigez vos problèmes de performance, le bot va progressivement réaugmenter sa cadence. Mais ce processus prend du temps, parfois plusieurs semaines selon la taille du domaine.

Le risque réel, c'est le cercle vicieux : moins de crawl = indexation retardée = moins de visibilité = moins de revenus pour investir dans l'infrastructure. Sur un site e-commerce avec 50 000 fiches produit, un crawl ralenti peut signifier des nouveautés invisibles pendant des jours.

• Le TTFB est le signal prioritaire pour Googlebot, pas le temps de chargement complet
• La réduction de crawl est proportionnelle à la lenteur observée, pas binaire
• Le retour à la normale nécessite une amélioration soutenue sur plusieurs jours minimum
• Les gros sites sont plus vulnérables car le volume de pages à crawler multiplie l'impact
• Google ne communique pas de seuil précis, chaque site est évalué dans son contexte propre

Cette déclaration correspond-elle aux observations terrain ?

Oui, et les données Search Console le confirment. On voit régulièrement des sites dont le nombre de pages crawlées quotidiennement chute de 30% à 70% après une migration serveur ratée ou un pic de charge mal géré. Le graphique Statistiques d'exploration montre ces variations clairement.

Ce qui est moins évident, c'est le seuil exact. Google ne dit pas « au-delà de X secondes, on ralentit ». En pratique, on observe des impacts dès que le TTFB moyen dépasse 500-800 ms de manière soutenue. Mais chaque domaine a son crawl budget de référence, calculé selon l'autorité, la fraîcheur des contenus, la fréquence de mise à jour.

Quelles nuances faut-il apporter à cette règle ?

Google ne crawle pas toutes les pages avec la même intensité. Les URLs stratégiques, souvent mises à jour, recevront probablement plus de tentatives même si le serveur traîne. À l'inverse, les pages profondes, rarement modifiées, disparaîtront quasi totalement du crawl si le TTFB se dégrade.

Autre point : la réduction de fréquence peut être sélective par section. Si votre blog est rapide mais que votre catalogue produit rame, Googlebot peut ajuster différemment. Les logs serveur montrent parfois ces patterns : crawl maintenu sur /articles/, effondrement sur /produits/. [A vérifier] car Google ne détaille pas publiquement cette granularité.

Dans quels cas cette logique peut-elle poser problème ?

Imaginons un site d'actualité qui publie 200 articles par jour. Si un problème de performance survient en milieu de matinée, le crawl ralenti peut faire que les contenus du soir ne sont indexés que le lendemain. Sur des sujets d'actu, c'est rédhibitoire.

Autre cas : les plateformes UGC (User Generated Content) avec des millions de pages. Une lenteur même minime entraîne une chute massive du crawl absolu, créant un backlog d'indexation quasi impossible à rattraper. Ces sites doivent maintenir un TTFB proche de la perfection, sous 200 ms idéalement. Tout dérapage coûte cher en visibilité.

Comment diagnostiquer un problème de crawl lié à la performance ?

Direction Search Console, onglet Statistiques d'exploration. Regarde le graphique Temps de réponse moyen sur 90 jours. Si tu vois une courbe qui grimpe corrélée à une baisse du nombre de pages explorées, tu tiens ton coupable. Cross-check avec tes propres outils de monitoring serveur (New Relic, Datadog, etc.).

Les logs serveur donnent encore plus de précision. Filtre les User-Agent Googlebot, analyse le TTFB par URL. Tu découvriras peut-être que 5% de tes pages plombent la moyenne globale. Ce sont elles qu'il faut corriger en priorité. Un problème localisé peut contaminer la perception globale du domaine par le bot.

Quelles actions concrètes pour améliorer le temps de réponse ?

Commence par le cache applicatif. Redis ou Memcached pour stocker les résultats de requêtes répétitives. Ensuite, optimise tes requêtes SQL : index manquants, jointures mal fichues, queries N+1 sur les frameworks type Django ou Laravel. Ces micro-optimisations peuvent diviser le TTFB par 3.

Côté serveur, vérifie que tu n'es pas en sous-capacité CPU ou RAM. Un serveur qui swap régulièrement en mémoire disque va tuer ton TTFB. Scale horizontal si ton architecture le permet. Et active la compression Gzip ou Brotli, même si Googlebot n'en profite pas directement pour le crawl, ça libère de la bande passante.

Faut-il limiter manuellement le crawl pour protéger le serveur ?

Non, mauvaise idée. Si tu configures robots.txt avec Crawl-delay, tu imposes une limite rigide alors que Google adapte dynamiquement. Tu risques de ralentir le crawl même quand ton serveur pourrait encaisser plus. Laisse Google gérer, il est meilleur juge de l'équilibre optimal.

Par contre, tu peux utiliser Search Console pour demander temporairement une réduction si tu sais qu'un pic de charge arrive (soldes, Black Friday). Mais c'est exceptionnel. La vraie solution reste l'infrastructure robuste. Si ton serveur ne tient pas le crawl Google, il ne tiendra pas non plus un pic de trafic réel.

• Monitorer le TTFB dans Search Console et logs serveur sur 30 jours glissants
• Identifier les URLs lentes spécifiques via analyse des logs filtrés Googlebot
• Activer un cache applicatif (Redis/Memcached) et optimiser les requêtes SQL
• Vérifier les ressources serveur (CPU, RAM, I/O disque) et scaler si nécessaire
• Tester la montée en charge avec des outils type Apache Bench ou Locust
• Éviter Crawl-delay dans robots.txt, laisser Google s'auto-réguler