Google ajuste-t-il vraiment le crawl si votre serveur rame ?

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

Googlebot surveille en permanence les temps de réponse lors de ses requêtes HTTP. Si le serveur met plus de temps que d'habitude à répondre, ou si des erreurs 5xx apparaissent de manière répétée, le robot interprète cela comme un signal de charge excessive.

Le mécanisme n'est pas binaire. Google ne coupe pas brutalement le crawl : il le réduit progressivement, en espaçant les requêtes. Si la situation s'améliore, le crawl remonte. Si elle empire, il descend encore. C'est un ajustement dynamique qui peut fluctuer plusieurs fois par jour.

Pourquoi cette limitation affecte-t-elle l'indexation de nouvelles pages ?

Moins de crawl signifie mécaniquement moins de pages découvertes ou rafraîchies par visite. Si votre serveur répond lentement, Googlebot explore moins d'URLs par session. Les nouvelles pages, notamment celles qui ne sont pas liées depuis la home ou des hubs stratégiques, peuvent attendre des jours voire des semaines avant d'être crawlées.

Le cas des pages AMP est intéressant. Leur indexation dépend souvent d'un crawl spécifique et, si le serveur ralentit, ces URLs passent en queue de priorité. Résultat : un délai d'indexation qui explose, surtout lors de déploiements massifs ou de refontes techniques.

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

Non. Un site avec un crawl budget élevé, beaucoup de backlinks et un historique de fiabilité technique aura plus de marge. Google peut tolérer quelques ralentissements ponctuels sans trop réduire le crawl. À l'inverse, un site jeune ou avec peu d'autorité sera bridé rapidement.

La localisation du serveur et sa latence réseau jouent aussi. Un hébergement géographiquement éloigné des crawlers Google peut amplifier les temps de réponse mesurés, même si votre serveur n'est pas réellement surchargé. C'est un point rarement discuté, mais observable sur des logs détaillés.

• Googlebot ajuste le crawl en temps réel selon les performances serveur mesurées
• Les nouvelles pages AMP sont particulièrement sensibles aux baisses de crawl
• Le crawl budget existant influence la tolérance de Google face aux ralentissements
• Les erreurs 5xx répétées déclenchent une réduction plus brutale que des temps de réponse lents
• La latence réseau peut fausser la perception de surcharge par Googlebot

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

Oui, et c'est même une des rares affirmations de Google qui colle parfaitement aux données de logs. On observe régulièrement des chutes de crawl corrélées à des pics de temps de réponse serveur, notamment lors de déploiements mal préparés ou de migrations sans tests de charge.

Par contre, Google ne précise pas les seuils exacts. Un temps de réponse de 500 ms déclenche-t-il une réduction ? Ou faut-il monter à 2 secondes ? [À vérifier] Aucune donnée officielle ne cadre ces valeurs. En pratique, on constate que des TTFB autour de 1 seconde maintiennent un crawl stable, mais au-delà de 2 secondes, ça se dégrade vite.

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

Google peut prioriser certaines sections même sur un serveur lent. Si votre home et vos catégories principales restent rapides, mais que vos pages produits rament, Googlebot continuera à crawler les zones critiques. La réduction de crawl n'est pas uniforme sur tout le site.

Autre point : un serveur peut être techniquement performant mais mal configuré côté rate limiting. Si votre WAF ou votre CDN ralentit artificiellement Googlebot (pour limiter les bots), vous créez vous-même le problème. J'ai vu des sites avec des serveurs sous-utilisés mais un crawl ridicule à cause de règles Cloudflare trop agressives.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Les contenus pushés via l'API Indexing (ex: offres d'emploi, livestreams) contournent partiellement ce mécanisme. Google indexe ces URLs même si le crawl général est bridé. C'est un contournement officiel, mais limité à quelques verticales.

Les sitemaps XML peuvent aussi forcer la main. Si vous déclarez une URL avec lastmod récent et priorité élevée, Googlebot peut crawler cette page même si le quota général est réduit. Ça reste marginal, mais observable sur des sites à fort volume.

Que faut-il faire concrètement pour éviter ce bridage ?

Première étape : monitorer les temps de réponse serveur vus par Googlebot, pas uniquement ceux de vos outils de monitoring habituels. Search Console affiche ces données dans le rapport "Statistiques d'exploration", mais c'est agrégé. Pour du détail, analysez vos logs serveur et isolez l'user-agent Googlebot.

Deuxième levier : optimiser les ressources serveur sur les URLs à fort potentiel SEO. Si vos fiches produits sont lentes, cache-les agressivement. Si vos listings paginent mal, revois la logique backend. Un serveur qui répond en 200 ms au lieu de 1 seconde peut multiplier le crawl par 2 ou 3.

Quelles erreurs éviter lors d'une migration ou d'un déploiement massif ?

Ne jamais pousser des milliers de nouvelles URLs sans avoir testé la capacité serveur à encaisser un pic de crawl. Google peut décider de crawler 500 pages en 10 minutes pour découvrir votre nouveau contenu. Si votre serveur s'effondre, vous créez un cercle vicieux : crawl réduit, indexation lente, relance impossible.

Autre erreur classique : ajouter massivement des pages AMP ou des versions mobiles alternatives sans ajuster les ressources serveur. Ces formats demandent souvent des rendus supplémentaires et, si le backend n'est pas dimensionné, le crawl chute immédiatement.

Comment vérifier que votre site n'est pas déjà bridé par Google ?

Comparez le nombre de pages crawlées par jour (dans Search Console) au nombre de pages indexables de votre site. Si Googlebot ne crawle que 5 % de votre inventaire par semaine, c'est un signal. Ensuite, croisez avec les temps de réponse moyens : s'ils dépassent 1 seconde, vous êtes probablement dans la zone rouge.

Testez aussi avec un crawl de contrôle via Screaming Frog ou Oncrawl depuis une IP différente. Si votre serveur répond rapidement à ces outils mais lentement à Googlebot, c'est soit un problème de rate limiting, soit une surcapacité ponctuelle que Google évite de solliciter.

• Activer un monitoring spécifique des temps de réponse pour l'user-agent Googlebot
• Limiter les ressources serveur consommées par les pages de faible valeur SEO (facettes, filtres, archives)
• Tester la charge serveur avant tout déploiement massif de nouvelles URLs
• Ajuster les règles de cache et CDN pour prioriser les URLs stratégiques
• Vérifier que le WAF ou les règles de sécurité ne ralentissent pas artificiellement Googlebot
• Analyser régulièrement les logs pour détecter des patterns de crawl anormaux