Le temps de réponse serveur dicte-t-il vraiment la fréquence de crawl de Googlebot ?

Qu'entend Google par « temps de réponse serveur » dans le contexte du crawl ?

On parle ici du Time To First Byte (TTFB), c'est-à-dire le délai entre la requête HTTP de Googlebot et la réception du premier octet de réponse. Ce n'est pas le temps de rendu complet de la page, ni la vitesse perçue par l'utilisateur final — juste le délai initial de réaction de votre infrastructure.

Google mesure ce TTFB en permanence pendant ses sessions de crawl. Si votre serveur répond en 50 ms, Googlebot considère qu'il peut envoyer davantage de requêtes simultanées sans vous mettre à genoux. Si vous mettez 2 secondes à renvoyer le premier octet, le crawler réduit la pression pour ne pas provoquer de timeout ou de saturation.

Pourquoi Google limite-t-il le nombre de demandes simultanées ?

Googlebot n'a aucun intérêt à crasher vos serveurs. Un serveur qui tombe, c'est un crawl qui échoue, des pages non indexées, et au final une perte d'information pour le moteur. Google applique donc un throttling dynamique : il observe votre capacité de réponse et ajuste en temps réel le taux de requêtes.

Cette logique est bienveillante en apparence, mais elle a un effet direct sur la vitesse de découverte de vos contenus. Si vous publiez 10 000 nouvelles URLs et que votre serveur est poussif, Googlebot va les crawler… mais sur plusieurs jours au lieu de quelques heures. Pour un site d'actualité ou un e-commerce avec un catalogue volatile, c'est un handicap réel.

Ce mécanisme s'applique-t-il uniformément à tous les sites ?

Non. Google module aussi en fonction du PageRank global du site, de la fréquence de mise à jour historique, et du « crawl budget » alloué. Un site autoritaire avec un bon TTFB bénéficie d'un crawl agressif. Un site faible avec un serveur lent se retrouve au ralenti sur les deux fronts.

Les sites sur hébergement mutualisé bas de gamme ou sur des CMS mal configurés (WordPress sans cache objet, par exemple) subissent souvent ce double handicap : peu de légitimité perçue, et des temps de réponse catastrophiques qui freinent encore plus le crawl.

• Le TTFB serveur conditionne le taux de requêtes simultanées de Googlebot.
• Un serveur lent ralentit l'indexation, même si le contenu est excellent.
• Ce mécanisme protège votre infrastructure, mais pénalise la découverte rapide de nouvelles pages.
• Le crawl budget global reste aussi influencé par le PageRank, la fraîcheur des contenus et l'historique de mise à jour.
• Les sites sur hébergement partagé de mauvaise qualité souffrent doublement : TTFB élevé et crawl timide.

Cette déclaration correspond-elle aux observations terrain ?

Absolument. On le voit dans les logs : un site qui passe d'un TTFB moyen de 1,5 s à 200 ms observe une explosion du nombre de hits Googlebot dans les semaines qui suivent, toutes choses égales par ailleurs. Ce n'est pas anecdotique — c'est mesurable, répétable, et cohérent avec ce que Splitt affirme.

Par contre, Google ne dit rien sur les seuils exacts qui déclenchent une réduction du taux de crawl. Est-ce qu'un TTFB de 500 ms suffit à brider le crawler ? Faut-il dépasser 1 seconde ? [A vérifier] Aucun chiffre officiel n'a jamais été communiqué, et c'est probablement variable selon la typologie de site et la charge globale du datacenter Google à l'instant T.

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

Améliorer le TTFB ne suffit pas à garantir un crawl optimal si le reste de votre architecture SEO est bancal. Un site avec 90 % de contenu dupliqué ou thin, même ultra-rapide, verra son crawl budget rationné pour d'autres raisons. Le TTFB est une condition nécessaire, pas suffisante.

Deuxième point : attention à ne pas confondre TTFB serveur et LCP utilisateur. On peut avoir un TTFB correct (< 200 ms) et un LCP catastrophique (> 4 s) si le rendu côté client est lourd. Google crawle avec un navigateur headless chromium, donc il mesure aussi le temps de rendu complet — mais la logique de throttling du nombre de requêtes simultanées repose d'abord sur le TTFB initial, avant même l'exécution du JavaScript.

Dans quels cas cette optimisation devient-elle secondaire ?

Si vous gérez un petit site de 50 pages mises à jour une fois par trimestre, franchement, vous pouvez avoir un TTFB de 800 ms sans que ça change grand-chose à votre indexation. Google crawlera vos 50 URLs en une session, même lentement. Le crawl budget n'est critique que pour les gros sites : e-commerce à catalogue mouvant, médias d'actualité, annuaires, marketplaces.

Autre cas : les sites où le crawl n'est pas le goulot d'étranglement, mais plutôt le rendu ou l'indexabilité. Si vos pages sont bloquées par un robots.txt mal fichu, un noindex accidentel ou un JS qui plante, optimiser le TTFB ne résoudra rien. Commence par auditer la couche indexation avant de t'attaquer à la latence réseau.

Que faut-il faire concrètement pour réduire le TTFB serveur ?

Première étape : mesurer l'existant. Utilise les logs serveur bruts (Apache, Nginx) pour calculer ton TTFB médian et 95e percentile. PageSpeed Insights ou GTmetrix te donnent une idée, mais rien ne remplace l'analyse des vraies requêtes Googlebot extraites des access logs. Si tu vois des pics à 2-3 secondes de manière récurrente, tu as un problème.

Côté infra, la première optimisation, c'est souvent le cache serveur. Varnish, Redis, Memcached, ou un simple reverse proxy bien configuré peuvent diviser le TTFB par 10. Sur WordPress, un combo Redis pour le cache objet + un CDN pour les assets statiques fait des miracles. Sur des stacks custom, regarde du côté de l'OPcache PHP, du pooling de connexions SQL, et de la réduction des requêtes BDD inutiles.

Quelles erreurs éviter dans cette optimisation ?

Ne confonds pas CDN et cache serveur. Un CDN (Cloudflare, Fastly) sert les assets statiques depuis des edge nodes, mais ne réduit pas le TTFB de ton HTML dynamique si ton serveur origine est lent. Il faut d'abord optimiser l'origine, ensuite mettre un CDN devant.

Autre piège classique : activer un plugin de cache sans purger intelligemment. Si ton cache ne s'invalide jamais, Googlebot crawlera des versions obsolètes de tes pages. Inversement, si tu purges tout le cache à chaque modification mineure, tu perds l'intérêt de la mise en cache. Configure des règles de purge ciblées par type de contenu ou taxonomie.

Comment vérifier que les optimisations portent leurs fruits ?

Deux indicateurs : le TTFB moyen dans tes logs, et le nombre de pages crawlées par jour dans la Search Console (Paramètres > Statistiques sur l'exploration). Si ton TTFB passe de 1,2 s à 150 ms et que tu vois le crawl quotidien doubler en 3-4 semaines, bingo — ta config fonctionne.

Surveille aussi les erreurs serveur (codes 5xx) pendant les pics de crawl. Si Googlebot envoie 50 requêtes/s et que ton serveur commence à timeout, ton optimisation TTFB a créé un nouveau goulot : la capacité de traitement parallèle. Il faut alors ajuster les workers/threads de ton serveur web ou passer sur une instance plus puissante.

• Mesurer le TTFB réel dans les logs serveur (médiane et 95e percentile)
• Implémenter un cache serveur (Varnish, Redis, reverse proxy)
• Optimiser les requêtes BDD et activer OPcache PHP si applicable
• Configurer un CDN pour les assets statiques, mais ne pas compter uniquement dessus
• Monitorer le crawl quotidien dans la Search Console après déploiement
• Vérifier l'absence de 5xx pendant les pics de crawl Googlebot