Votre serveur lent tue-t-il votre crawl budget sans que vous le sachiez ?

Pourquoi Google ralentit-il le crawl d'un serveur lent ?

Googlebot applique une logique de crawl rate limiting pour protéger les serveurs qu'il explore. Lorsqu'un site met plusieurs secondes à répondre, Google interprète cela comme un signe de capacité d'infrastructure limitée. Le bot réduit alors automatiquement son rythme pour ne pas provoquer de surcharge ou de timeout.

Cette approche vise autant à préserver l'expérience utilisateur du site crawlé qu'à optimiser l'efficacité de Googlebot. Crawl rapide sur serveur lent = risques de 503, pages blanches, perte de requêtes légitimes. Google préfère espacer les visites plutôt que de dégrader la disponibilité du site.

Quel est l'impact réel sur le nombre de pages crawlées ?

Le crawl budget n'est pas une valeur fixe : il fluctue en fonction de la capacité du serveur et de l'intérêt du contenu. Un serveur qui répond en 200 ms peut absorber 10 000 pages crawlées par jour, tandis qu'un serveur à 2 secondes de temps de réponse plafonne à 1 000 pages pour un niveau équivalent de sollicitation.

Les sites à forte volumétrie (e-commerce, annuaires, médias avec archives profondes) subissent un goulot d'étranglement mécanique. Si votre catalogue contient 50 000 produits et que Google ne crawle que 800 pages par jour, vos nouvelles fiches produits mettent des semaines à être indexées. Le problème n'est pas la priorité du contenu, mais la bande passante disponible.

Comment Google détecte-t-il la vitesse d'un serveur ?

Googlebot mesure le time to first byte (TTFB) à chaque requête et agrège ces données sur plusieurs jours. Il ne s'agit pas d'un test ponctuel mais d'une moyenne glissante. Un pic de lenteur occasionnel ne suffit pas à déclencher une réduction durable du crawl, mais une médiane élevée sur 7 jours oui.

Les erreurs 5xx jouent également un rôle : trop de 503 ou 500 signalent un serveur instable. Google diminue le crawl rate même si les temps de réponse restent acceptables, par principe de précaution. Les logs serveur et la Search Console permettent de tracer ces ajustements.

• Crawl rate limiting : Google réduit automatiquement son rythme si le serveur montre des signes de faiblesse (TTFB élevé, erreurs 5xx)
• Proportionnalité directe : serveur 10x plus lent = crawl budget divisé par 10 environ, toutes choses égales par ailleurs
• Mesure continue : TTFB médian sur plusieurs jours, pas un snapshot ponctuel
• Impact maximal sur les gros sites : un catalogue de 100 000 pages avec serveur lent peut voir seulement 2-3 % de son contenu crawlé quotidiennement
• Aucune exception manuelle : même un site d'autorité subit cette limitation si son infrastructure est sous-dimensionnée

Cette déclaration correspond-elle aux observations terrain ?

Oui, et c'est même un point rarement contesté dans la communauté SEO. Les audits techniques confirment systématiquement la corrélation entre TTFB et volume de crawl. Un client e-commerce passé de 1,8 s à 400 ms de TTFB a vu son crawl quotidien tripler en 10 jours, sans aucune autre modification. Les logs Apache/Nginx parlent d'eux-mêmes.

La nuance importante : cette limitation ne touche vraiment que les sites à forte volumétrie. Un blog de 200 articles peut avoir un serveur médiocre sans conséquence visible, car Google crawle l'intégralité du site en quelques minutes même à rythme réduit. Le problème devient critique dès que le ratio pages totales / crawl quotidien dépasse 30 jours.

Quelles zones d'ombre subsistent dans cette déclaration ?

John Mueller ne donne aucun chiffre, aucun seuil. [A vérifier] Quel TTFB déclenche une réduction du crawl ? 500 ms ? 1 seconde ? 2 secondes ? Impossible de le savoir officiellement. Les observations empiriques suggèrent qu'au-delà de 800 ms médian, Google commence à freiner, mais cela varie selon la typologie de site et son autorité globale.

Autre point flou : comment Google arbitre-t-il entre vitesse serveur et importance du contenu ? Un site lent mais d'actualité brûlante (breaking news, événement viral) bénéficie-t-il d'une tolérance temporaire ? Rien dans les déclarations officielles ne le confirme, mais certains cas terrain laissent penser qu'une override manuelle reste possible pour des situations exceptionnelles.

Faut-il prioriser TTFB ou infrastructure globale ?

TTFB reste le marqueur principal, mais ce n'est qu'un symptôme. Un serveur peut répondre vite sur la page d'accueil et s'effondrer sur les fiches produits complexes avec 12 requêtes SQL. Google crawle l'ensemble du site, pas juste les pages rapides. L'optimisation doit donc couvrir toutes les typologies de pages, pas juste les templates stratégiques.

Infrastructure sous-dimensionnée = TTFB erratique. Un CDN améliore la distribution statique mais ne résout pas un serveur applicatif trop lent à générer le HTML. La vraie question est : votre serveur peut-il gérer 20 requêtes simultanées de Googlebot sans dépasser 500 ms ? Si non, l'infrastructure est le goulot, pas la stack technique.

Comment diagnostiquer un problème de vitesse serveur impactant le crawl ?

Premier réflexe : Google Search Console > Statistiques d'exploration. Regarde la courbe "Temps de téléchargement de la page (ms)" sur 90 jours. Si la médiane dépasse 800 ms ou montre une tendance haussière, tu as un problème. Croise avec le volume de pages crawlées : une baisse simultanée du crawl + hausse du TTFB confirme le diagnostic.

Deuxième levier : logs serveur bruts. Extrais les user-agents Googlebot et calcule le TTFB moyen par typologie de page (catégories, fiches produits, articles). Utilise AWStats, GoAccess ou un script Python custom. Les outils tiers comme Oncrawl ou Botify automatisent cette analyse si tu as le budget. L'objectif est d'identifier les sections du site qui freinent le crawl.

Quelles optimisations apportent les gains les plus rapides ?

Serveur applicatif d'abord : passe de PHP-FPM 4 workers à 16, ou migre vers une instance 4 vCPU si tu es sur un VPS 1 vCPU. Les gains sont immédiats et mesurables. Un client est passé de 1,2 s à 350 ms de TTFB en doublant simplement la RAM allouée à MySQL. Infrastructure sous-dimensionnée est la cause n°1.

Cache applicatif ensuite : Varnish, Redis ou même un simple cache HTML statique via plugin WordPress. Google crawle souvent les mêmes URLs (pagination, tri produits) : servir du cache réduit la charge de 60-80 %. Attention à bien configurer les headers Cache-Control pour que Googlebot respecte le cache sans indexer du contenu obsolète.

Quelles erreurs courantes aggravent le problème ?

Erreur classique : CDN mal configuré qui accélère le front-end mais ne touche pas au TTFB du HTML. Cloudflare ou AWS CloudFront ne changent rien si ton serveur origine met 2 secondes à générer la page. Le CDN sert les assets (JS, CSS, images) rapidement, mais Googlebot attend toujours 2 secondes pour le HTML. Fausse impression de rapidité.

Autre piège : optimiser uniquement les pages stratégiques visibles dans GA. Google crawle aussi les archives, les anciennes catégories, les pages de pagination profonde. Si 80 % de ton site a un TTFB catastrophique mais que ta homepage et tes 10 top produits sont rapides, le crawl global reste bridé. L'amélioration doit être systémique, pas cosmétique.

• Mesurer le TTFB médian via Search Console et logs serveur sur l'ensemble du site, pas juste les pages populaires
• Dimensionner l'infrastructure pour absorber 20-30 requêtes Googlebot simultanées sans dépasser 500 ms
• Implémenter un cache applicatif (Varnish, Redis, cache HTML statique) sur les typologies de pages les plus crawlées
• Monitorer les erreurs 5xx : plus de 2-3 % d'erreurs serveur déclenche une réduction préventive du crawl
• Tester le temps de génération HTML côté serveur avec des outils comme Blackfire.io ou New Relic APM
• Vérifier que le CDN ne masque pas un problème de TTFB serveur : teste directement l'IP origine