Le 6 octobre 2026, Google a réécrit sa documentation « Réduire la vitesse d'exploration de Google ». D'après le journal des modifications, la section sur la réduction d'urgence a été restructurée, et des explications et des exemples sur l'en-tête Retry-After ont été ajoutés directement au guide. Le journal précise aussi que la prise en charge de Retry-After n'est pas nouvelle : elle figurait déjà dans la page « Suspendre ou désactiver temporairement un site web », et elle est simplement placée là où on la trouvera. Si votre site tourne sur une petite machine, c'est le frein officiel à garder sous la main.

Trouver la cause avant de freiner

D'après les signalements reçus par Google, la documentation indique que les causes les plus fréquentes d'une hausse soudaine de l'exploration tiennent à la structure des URL du site lui-même : navigation à facettes et autres fonctions de tri et de filtrage, calendriers générant de nombreuses URL pour des dates précises, et cibles d'annonces dynamiques du Réseau de Recherche. Google recommande de se renseigner auprès de son hébergeur et d'examiner les journaux d'accès récents du serveur pour voir si le trafic correspond à l'un de ces cas. Pour plonger dans les journaux, voir diagnostiquer un CPU à 100 % sur un VPS ; si le trafic provient en réalité de robots d'IA ou de robots se faisant passer pour des robots d'exploration, c'est un autre problème, traité dans les robots d'IA dévorent la bande passante de votre serveur.

Le frein d'urgence : renvoyer 500, 503 ou 429

  • Comment : pendant une courte période (les exemples de la documentation sont quelques heures, ou 1 à 2 jours), renvoyez 500, 503 ou 429 aux requêtes d'exploration de Google au lieu de 200.
  • Effet : lorsque les robots de Google rencontrent un nombre important de ces codes d'état, ils réduisent la vitesse d'exploration sur l'ensemble du nom d'hôte (par exemple subdomain.example.com), y compris pour les URL qui renvoient des erreurs et celles qui renvoient du contenu, puis l'augmentent à nouveau automatiquement quand les erreurs diminuent.
  • Retry-After : avec 503 ou 429, vous pouvez ajouter un en-tête Retry-After, soit en secondes (par exemple Retry-After: 120), soit sous forme de date et d'heure UTC absolues, pour indiquer aux robots quand revenir.

Les coûts sont eux aussi écrits noir sur blanc

  • Pour la recherche, Googlebot découvre moins de nouvelles pages tant que le frein est serré, les pages existantes sont actualisées moins souvent (les changements de prix et de disponibilité, par exemple, mettent plus de temps à apparaître) et les pages supprimées peuvent rester plus longtemps dans l'index. Pour Google Ads, les campagnes peuvent être annulées ou mises en veille, et les annonces peuvent ne pas être diffusées.
  • Ne le maintenez pas plus de 1 à 2 jours. Si Googlebot voit ces codes d'état sur la même URL pendant plusieurs jours, cette URL peut être retirée de l'index.
  • S'il n'est pas possible de renvoyer des erreurs aux robots, vous pouvez déposer une demande spéciale signalant une vitesse d'exploration anormalement élevée, mais vous ne pouvez pas demander une vitesse plus élevée, et l'examen peut prendre plusieurs jours.

La mise en pratique sur un VPS

Renvoyez le 503 au niveau du serveur web ou de l'application, uniquement pour les robots et uniquement pendant l'urgence, et pensez à le retirer ensuite. Les chaînes User-Agent peuvent être usurpées ; Google documente comment vérifier ses robots par une résolution DNS inverse ou à l'aide de ses adresses IP publiées. Si la charge provoque déjà des erreurs 502 / 504, rétablissez d'abord le service avec le guide de dépannage des erreurs 502 / 504. À plus long terme, si la machine ne supporte pas une exploration normale, il est temps de redimensionner le VPS selon l'usage ou de confier les ressources statiques à un CDN.