Comment Google ajuste-t-il son crawl en fonction de votre serveur ?

Qu'est-ce que le crawl budget et pourquoi Google le régule ?

Le crawl budget représente le nombre de pages que Google accepte de crawler sur votre site durant une période donnée. Ce n'est pas un chiffre fixe arbitrairement décidé par Google, mais une variable qui s'adapte en permanence. La logique est simple : Googlebot ne veut pas faire tomber votre infrastructure.

Google surveille deux indicateurs principaux. D'abord, le temps de réponse de votre serveur : si vos pages mettent 2 secondes au lieu de 200 millisecondes à charger, le bot ralentit. Ensuite, le taux d'erreurs serveur : une avalanche d'erreurs 500, 502 ou 503 déclenche une baisse immédiate du rythme de crawl. Cette régulation protège votre infrastructure mais crée une contrainte SEO majeure.

Comment Google détecte-t-il qu'un serveur est en difficulté ?

Googlebot analyse en temps réel les signaux de santé de votre serveur pendant qu'il crawle. Chaque requête HTTP renvoie un code de statut et un temps de réponse. Ces métriques sont agrégées et comparées aux performances historiques de votre site. Une dégradation progressive déclenche une réduction proportionnelle du crawl.

Le bot utilise également des patterns d'erreurs : si 15% de ses requêtes renvoient des 503 sur une fenêtre de 10 minutes, il considère que le serveur est saturé. La réaction est quasi instantanée : le nombre de requêtes par seconde diminue jusqu'à retrouver un taux d'erreur acceptable. Ce mécanisme s'applique site par site, voire sous-domaine par sous-domaine sur les grosses infrastructures.

Cette régulation s'applique-t-elle de la même façon à tous les sites ?

Non. Google ajuste sa tolérance selon la taille et l'autorité du site. Un site de 50 pages n'a pas le même traitement qu'un site de 500 000 URLs. Sur les petites structures, Googlebot est moins agressif par défaut et réagit plus vite aux signaux de faiblesse. Sur les gros portails avec beaucoup d'autorité, le crawl initial est massif mais la sensibilité aux erreurs reste identique.

Les sites avec un taux de fraîcheur élevé (actualités, e-commerce avec beaucoup de rotation) bénéficient d'un crawl plus fréquent. Mais cette faveur disparaît dès que le serveur montre des signes de faiblesse. Un média qui publie 200 articles par jour mais dont le serveur rame verra son crawl budget bridé, retardant potentiellement l'indexation des nouveaux contenus de plusieurs heures.

• Le crawl budget n'est pas fixe : il varie selon la santé technique du site et sa capacité à répondre rapidement
• Les erreurs 5xx sont le déclencheur principal : un taux supérieur à 10% pendant quelques minutes suffit à ralentir Googlebot
• Les temps de réponse comptent autant : passer de 200ms à 2s impacte le crawl même sans erreur HTTP
• La régulation est granulaire : elle peut s'appliquer différemment selon les sous-domaines ou sections du site
• L'historique joue un rôle : un site avec des performances stables bénéficie d'une tolérance légèrement supérieure lors d'incidents ponctuels

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument. Les tests en conditions réelles montrent que Googlebot réduit effectivement son rythme dès qu'un serveur montre des signes de faiblesse. Sur des sites e-commerce de taille moyenne, on observe régulièrement des baisses de crawl de 40 à 60% suite à des ralentissements serveur liés à des pics de charge. Les logs confirment : moins de requêtes Googlebot, espacées dans le temps.

Ce qui est moins documenté par Google, c'est la vitesse de récupération. Une fois la performance serveur rétablie, combien de temps faut-il pour retrouver un crawl budget normal ? [A vérifier] Les observations varient de 48 heures à une semaine selon les sites. Google n'a jamais fourni de chiffre officiel sur cette fenêtre de récupération, et ça pose problème pour les gros sites qui subissent des incidents temporaires.

Quelles nuances Google ne mentionne pas dans cette déclaration ?

Premier point : la déclaration reste floue sur les seuils précis. À partir de quel pourcentage d'erreurs 5xx Googlebot ralentit-il ? Quelle latence déclenche une réduction du crawl ? Google garde ces paramètres secrets, probablement pour éviter les manipulations. Mais cette opacité complique le diagnostic quand on constate une baisse inexpliquée du crawl.

Deuxième nuance : tous les Googlebots ne se comportent pas pareil. Le bot mobile peut avoir une tolérance légèrement différente du bot desktop. Le bot Googlebot-Image ou le crawler pour les découvertes de nouveaux contenus suivent des règles distinctes. Sur certains sites, on observe un crawl normal pour le bot principal mais un ralentissement marqué pour les bots secondaires lors de périodes de charge élevée.

Dans quels cas cette régulation pose-t-elle problème en SEO ?

Le scénario classique : un site avec un contenu très frais mais une infrastructure sous-dimensionnée. Typiquement, un média d'actualité avec des serveurs limités. Le matin, quand les articles du jour sortent, le trafic utilisateur explose, le serveur rame, Googlebot ralentit. Résultat : les nouveaux articles mettent 3 à 6 heures à être indexés au lieu de 20 minutes. Dans un contexte d'actualité chaude, c'est rédhibitoire.

Autre cas problématique : les sites avec une architecture technique bancale. Un CMS mal optimisé qui génère des temps de réponse variables selon les types de pages. Google crawle les pages rapides normalement, mais réduit drastiquement le crawl sur les sections lentes. On se retrouve avec un crawl budget inégalement réparti : certaines catégories sont crawlées quotidiennement, d'autres toutes les deux semaines. Ça crée des distorsions dans la fraîcheur de l'index.

Comment vérifier si votre serveur limite votre crawl budget ?

Commencez par croiser deux sources dans la Search Console : le rapport "Statistiques sur l'exploration" et les logs serveur bruts. Dans Search Console, regardez l'évolution du nombre de pages crawlées par jour et le temps de téléchargement moyen. Une baisse du crawl couplée à une augmentation du temps de réponse, c'est le signal typique.

Côté logs serveur, filtrez les user-agents Googlebot et calculez le taux d'erreurs 5xx par tranche horaire. Si vous dépassez 5-10% d'erreurs durant les pics de charge, vous avez votre coupable. Analysez aussi la distribution des temps de réponse : si votre médiane passe de 300ms à 1,5s aux heures de pointe, Googlebot va nécessairement ralentir. Ces données sont rarement visibles dans Search Console, d'où l'importance des logs bruts.

Quelles actions concrètes mettre en place pour optimiser le crawl ?

Première priorité : stabiliser les performances serveur. Ça passe par un audit d'infrastructure complet. Identifiez les requêtes lentes dans vos logs applicatifs, optimisez les queries SQL qui traînent, mettez en cache ce qui peut l'être. Sur un site WordPress avec WooCommerce, par exemple, activer un cache objet (Redis ou Memcached) peut diviser les temps de réponse par 3.

Ensuite, utilisez le fichier robots.txt de façon stratégique. Si certaines sections de votre site sont peu importantes pour le SEO mais consomment beaucoup de ressources serveur (filtres de recherche infinis, pages de pagination profonde), bloquez-les. Vous libérez du crawl budget pour vos pages critiques. Attention : ne bloquez jamais aveuglément, vérifiez d'abord dans Search Console quelles URLs Google crawle le plus.

Que faire en cas de pic de charge prévisible ?

Si vous savez qu'un événement va générer un pic de trafic (soldes, lancement produit, actualité chaude), prévenez votre hébergeur et provisionnez temporairement plus de ressources. Certains hébergements cloud permettent de scaler automatiquement, mais configurez les seuils à l'avance. Un serveur qui tient la charge utilisateur mais plante sous Googlebot est un cas classique : le bot peut crawler 10 pages par seconde pendant qu'il y a déjà 500 utilisateurs simultanés.

Pendant le pic, surveillez vos métriques en temps réel. Si malgré tout le serveur faiblit, activez temporairement un rate limiting différencié : laissez passer les utilisateurs normalement mais ralentissez les bots (Googlebot inclus) via un reverse proxy. C'est un pansement, pas une solution pérenne, mais ça peut éviter une chute totale du site. Une fois le pic passé, retirez ces limitations rapidement pour ne pas brider le crawl plus longtemps que nécessaire.

• Auditez vos temps de réponse serveur et votre taux d'erreurs 5xx via logs bruts et Search Console
• Optimisez les requêtes lentes côté base de données et activez un système de cache robuste
• Bloquez dans robots.txt les sections non critiques qui consomment du crawl budget inutilement
• Provisionnez des ressources serveur supplémentaires avant les pics de charge prévisibles
• Surveillez en temps réel les métriques pendant les événements critiques pour réagir vite
• Testez la charge serveur en simulant un crawl massif avec Screaming Frog ou un outil similaire