Googlebot : Google documente l’en-tête Retry-After pour ralentir le crawl

L’essentiel

• Google a mis à jour sa page « Reduce the Google crawl rate » le 6 octobre 2026.
• Un en-tête Retry-After peut accompagner un 503 ou un 429, avec un délai en secondes ou une date UTC.
• Ces codes ne doivent pas être renvoyés plus d’un ou deux jours, sous peine de voir des URL sortir de l’index.
• Seule la documentation change : les 500, 503 et 429 servaient déjà à ralentir le crawl.

Retry-After : un délai en secondes ou une date précise

La modification touche la section « Urgently reduce crawler traffic (for emergencies) » (réduire d’urgence le trafic des robots) de la page de Google consacrée à la fréquence d’exploration. Un site qui répond par un 503 ou un 429 peut y joindre l’en-tête HTTP Retry-After, au sens de la RFC 9110, pour signaler aux robots le moment où ils peuvent revenir.

Deux syntaxes sont acceptées. La première donne un délai en secondes, par exemple Retry-After: 120. La seconde fixe une date et une heure absolues en UTC, comme dans l’exemple de Google : Retry-After: Wed, 21 Oct 2026 07:28:00 GMT. Le journal des modifications résume l’opération ainsi : la section sur la réduction d’urgence a été « restructurée », avec « des informations et des exemples sur l’en-tête HTTP Retry-After » (traduction).

Googlebot : un mécanisme inchangé

Google l’écrit lui-même dans ce journal : la prise en charge de Retry-After « n’est pas nouvelle » (traduction). L’en-tête était déjà mentionné dans la page « Temporarily pause or disable a website » (mettre un site en pause temporairement). Il a été recopié dans le guide sur la fréquence d’exploration pour qu’on le trouve plus vite en cas d’urgence.

Sur le fond, rien ne bouge. Pendant une courte période, de quelques heures à un ou deux jours, le site peut répondre aux robots par un 500, un 503 ou un 429 au lieu d’un 200. Google ralentit alors l’exploration sur tout le nom d’hôte, y compris sur les URL qui renvoient normalement leur contenu. Le rythme se rétablit seul une fois les erreurs disparues. Un détail : la page n’associe Retry-After qu’au 503 et au 429, jamais au 500. Barry Schwartz a relayé la mise à jour le jour même sur Search Engine Roundtable.

Au-delà d’un ou deux jours, des URL peuvent sortir de l’index

L’avertissement reste en place : pas plus d’un ou deux jours. Si Googlebot reçoit ces codes sur une même URL plusieurs jours d’affilée, elle peut disparaître de l’index. La page détaille aussi le prix d’un crawl ralenti. Les nouvelles pages sont découvertes moins vite. Les pages existantes sont rafraîchies moins souvent, si bien qu’un prix ou une disponibilité modifiés tardent à s’afficher. Les pages supprimées restent plus longtemps indexées. Côté Google Ads, des campagnes peuvent être suspendues ou annulées, et des annonces cesser de s’afficher.

Si renvoyer des erreurs n’est pas possible, Google laisse une autre porte : une demande exceptionnelle déposée depuis le rapport Googlebot de la Search Console, en précisant la fréquence souhaitée. L’examen peut prendre plusieurs jours, et ce canal ne sert pas à réclamer davantage de crawl. Avant d’en arriver là, la page invite à chercher dans les journaux du serveur la cause d’une hausse soudaine. Les suspects habituels sont la navigation à facettes, les tris et filtres, les calendriers qui produisent une URL par date, ou encore une cible de Dynamic Search Ads (annonces dynamiques du Réseau de Recherche).

Exemple de configuration pour une maintenance

Google ne donne aucune configuration serveur, seulement des réponses HTTP brutes. Voici donc, à titre d’exemple, les directives que je propose pour une maintenance d’une heure (3 600 secondes), avec une page d’attente maintenance.html à la racine du site.

Serveur	Renvoyer le 503	Ajouter Retry-After	Servir la page d’attente
Nginx (bloc server)	return 503; dans location /	add_header Retry-After 3600 always; au niveau du bloc server	error_page 503 /maintenance.html; et location = /maintenance.html { internal; }
Apache (.htaccess, mod_rewrite et mod_headers)	RewriteEngine On, puis RewriteCond %{REQUEST_URI} !=/maintenance.html et RewriteRule ^ – [R=503,L]	Header always set Retry-After « 3600 »	ErrorDocument 503 /maintenance.html

Dans les deux cas, le mot always est obligatoire. Sans lui, Nginx comme Apache omettent l’en-tête sur les réponses d’erreur. Sous Apache, la condition qui exclut maintenance.html empêche la page d’attente de tourner en boucle. Pour contrôler le résultat, une requête curl -I sur quelques URL suffit : elle doit afficher le 503 et la ligne Retry-After.

Ce que j’en retiens

Google n’ajoute aucune règle. Il range une consigne qui existait déjà là où on la cherche quand le serveur sature. Pour une maintenance programmée, la réponse attendue est un 503 accompagné d’un Retry-After réaliste, pas une page « site en maintenance » servie en 200, ni une redirection vers l’accueil. Je garderais le délai sous les 24 heures. Ensuite, un passage par les statistiques d’exploration de la Search Console permet de vérifier que la part de réponses 5xx est bien retombée.

Le vrai risque se trouve ailleurs, du côté des 429 qu’un pare-feu ou un CDN renvoie en continu pour limiter le débit. Google les prend pour une demande de ralentir. Passé quelques jours, la menace de désindexation est la même que pour une maintenance qui traîne. Quand le crawl pèse sur le serveur de façon chronique, il vaut mieux supprimer les URL inutiles, comme le rappelait déjà la refonte de la documentation sur le budget de crawl, plutôt que de laisser tourner les codes d’erreur.