Tous les codes de réponse HTTP rendent un verdict sur une adresse. Le 200 dit que la page existe et la voici. Le 301 dit qu'elle a déménagé et voici où. Le 404 dit qu'elle n'existe pas. Le 410 dit qu'elle n'existe plus et que c'est définitif.

La famille 5xx ne rend aucun verdict. Elle dit autre chose, et c'est la seule à le dire : revenez plus tard. Un 503 ne parle pas du contenu de la page, il parle de l'état du serveur à l'instant de la demande. Il ne décrit pas une adresse, il demande un délai.

Une demande de délai n'a de sens que si quelqu'un l'entend et revient. C'est là que la question devient intéressante pour un moteur génératif, parce qu'un moteur génératif a deux couches et qu'une seule revient.

Ce blog a déjà établi que dans toute la famille des sujets de performance, une seule variable franchit la frontière entre l'humain et la machine : les Core Web Vitals ne mesurent rien qu'un robot puisse éprouver, et le code de réponse reste le seul signal qui compte pour lui. Le 5xx est ce code. C'est donc le point où cette famille de sujets cesse d'être décorative.

Le 17 septembre 2026, j'ai cherché ce que les éditeurs de ces moteurs disent du 5xx. J'ai trouvé un éditeur qui en publie le mode d'emploi complet sur trois pages, trois éditeurs qui n'en disent pas un mot, et un modèle qui invente un chiffre quand on lui pose la question de mémoire.

Ce que la SERP « erreur 503 » raconte

Relevé du 17 septembre 2026 sur Google France. Le champ sémantique du 5xx est l'un des plus volumineux que ce blog ait visés : « erreur 500 » à 5 400 recherches par mois, « erreur 503 » à 4 400, « erreur 502 » à 2 900, puis « http 500 » à 720, « code erreur http » à 210, « erreur serveur » à 170 pour un CPC de 26,27 EUR, « site indisponible » à 40. La concurrence publicitaire est à l'indice 1 sur les trois plus gros termes, le plancher de l'échelle.

À côté, le vocabulaire des professionnels du référencement est confidentiel : « crawl budget » à 50 recherches mensuelles, « budget de crawl » à 20. L'écart est d'un facteur cent entre le mot que les gens tapent et le mot que le métier emploie.

La SERP « erreur 503 » compte huit résultats organiques, surmontés d'un Aperçu IA, avec un bloc de questions associées, un bloc vidéo et des recherches connexes.

Le classement : MDN en rang 1, un fil Reddit de r/csharp en rang 2, Microsoft Learn en rang 3, puis l'agence datashake, la base d'aide de l'hébergeur LWS, l'Agence Chocolat, le guide IONOS daté de mars 2023, et la documentation de Gandi.

Les huit traitent la même question, et c'est une question de dépannage. Comment réparer, quelles extensions désactiver, comment augmenter la mémoire allouée, comment vider le cache. Deux registres cohabitent, celui du visiteur qui tombe sur la page et celui de l'administrateur qui doit remettre le service debout.

Aucun des huit ne parle de recherche. Ni classement, ni indexation, ni robot, ni moteur génératif. Le 503 y est un incident d'exploitation et rien d'autre.

L'Aperçu IA confirme le diagnostic par son comportement. Il cite sept sources, dont cinq pages d'hébergeurs ou d'agences et deux YouTube Shorts, l'un d'eux en portugais sur une requête française. Puis il fait quelque chose que je vois rarement : il termine par une question posée à l'utilisateur, « Est-ce que cette erreur s'affiche sur un site que vous visitez ou sur votre propre site web ? ». Le moteur ne sait pas à qui il parle, parce que le corpus dont il dispose mélange les deux publics et n'en sert aucun troisième.

Ce troisième public existe pourtant. C'est celui qui se demande ce que devient sa visibilité pendant que le serveur répond 503.

Ce que Google publie, et c'est un mode d'emploi complet

Google traite la question dans trois documents distincts, et le niveau de détail est celui d'une spécification.

Le premier est la page sur les codes de statut HTTP, dont la dernière mise à jour affichée est le 4 février 2026. J'ai déjà utilisé sa moitié 4xx pour expliquer ce qu'un moteur fait d'une page 404. Sa moitié 5xx dit ceci :

« 5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped. »

Deux temps sont donc prévus. Le ralentissement est immédiat, la perte est différée. C'est exactement la différence avec le 404, où la même page précise que le pipeline d'indexation retire l'URL de l'index sans délai. Un 5xx vous achète du temps, un 4xx n'en achète pas.

La phrase suivante est plus brutale et moins citée :

« Any content Google receives from URLs that return a 5xx status code is ignored. »

Beaucoup de pages de maintenance servent un contenu, parfois soigné, sous un code 503. Ce contenu n'existe pas pour le robot. Le code est lu, la charge est jetée.

Le deuxième document est la page consacrée à la réduction de la fréquence d'exploration, et il inverse la perspective. Google n'y décrit pas le 5xx comme un accident subi, il le recommande comme un outil :

« If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests. »

Le 5xx est donc, dans la doctrine de Google, un levier volontaire. Avec un avertissement explicite sur la durée, « we don't recommend that you do this for a long period of time (meaning, longer than 1-2 days) ».

La même page contient la phrase qui devrait être affichée dans toutes les salles de mise en production, parce qu'elle contredit l'intuition la plus répandue :

« The reduced crawl rate affects the whole hostname of your site, both the crawling of the URLs that return errors, as well as the URLs that return content. »

Le ralentissement ne frappe pas les URL en panne, il frappe l'hôte. Une poignée d'adresses en 500 ralentit l'exploration de vos pages saines. C'est une propriété d'échelle que la lecture page par page fait complètement manquer, et c'est le même raisonnement d'hôte que celui qui gouverne le choix entre un sous-domaine et un sous-répertoire.

Le troisième document est la spécification du robots.txt, et il réserve au 5xx un traitement à part. Si Google trouve le fichier mais ne peut pas le lire, il applique une procédure en trois paliers.

Pendant les douze premières heures, il cesse d'explorer le site, tout en continuant à tenter la lecture. Pendant les trente jours suivants, il utilise la dernière version valide du fichier. Passé trente jours, la règle bifurque : si le site répond, Google considère qu'il n'y a aucune restriction ; s'il ne répond pas, Google cesse d'explorer. Le texte ajoute qu'un 503 « results in fairly frequent retrying ».

Le plus petit fichier de votre site peut donc en éteindre l'exploration entière pendant une demi-journée. Et si vous n'avez jamais eu de version en cache, Google en déduit qu'il n'y a aucune restriction, ce qui est l'inverse exact du comportement prudent que la plupart des équipes imaginent. C'est le prolongement direct de ce que j'écrivais sur robots.txt et les crawlers d'IA.

Dernier détail, et il est savoureux. Le 429 « too many requests » appartient à la famille 4xx dans la norme HTTP. Google le range explicitement ailleurs : « Google's crawlers treat the 429 status code as a signal that the server is overloaded, and it's considered a server error ». Et la page précise que les 4xx, 429 excepté, n'ont aucun effet sur la fréquence d'exploration. Le seul 4xx qui compte pour le débit est celui que Google a décidé de compter comme un 5xx.

Ce que les éditeurs de moteurs génératifs publient

J'ai compté les mêmes termes dans les documents qui régissent l'accès des robots d'IA. Corps de page seulement : les barres latérales de ces sites reproduisent des sommaires entiers et gonflent tous les comptages, un piège que j'avais déjà rencontré. Chaque zéro est accompagné de deux témoins non nuls, qui prouvent que le bon document a bien été récupéré et lu.

document (corps seul)      503  5xx  500  429  R-After  C-delay
-------------------------  ---  ---  ---  ---  -------  -------
Google, codes HTTP           1    4    1    5        0        0
Google, reduire le crawl     2    0    2    2        0        0
Google, robots.txt           1    2    1    2        0        1
OpenAI, bots                 0    0    0    0        0        0
Perplexity, crawlers         0    0    0    0        0        0
Anthropic, crawler           0    0    0    0        0        3

temoins (crawl / robots.txt)
Google codes HTTP 17/4    Google reduire 40/5
Google robots.txt 65/69   OpenAI 7/11
Perplexity 7/3            Anthropic 14/5

Le résultat est net. Les trois éditeurs qui font tourner GPTBot, PerplexityBot et ClaudeBot ne prononcent jamais les chaînes 500, 503, 5xx ni 429 dans les pages qui expliquent aux propriétaires de sites comment leurs robots se comportent. Les témoins écartent l'hypothèse d'une récupération ratée : OpenAI écrit « crawl » sept fois et « robots.txt » onze fois dans un corps de 4 234 caractères, Anthropic quatorze et cinq dans 4 203 caractères, Perplexity sept et trois.

Ce sont des documents courts, denses, entièrement consacrés au sujet. Ils décrivent les noms de robots, les plages d'adresses IP, les directives du robots.txt, les différences entre exploration d'entraînement et récupération à la demande. Ils ne disent pas un mot de ce qui se passe quand le serveur en face répond mal.

Une seule exception, et elle mérite d'être lue de près. Anthropic emploie trois fois le terme Crawl-delay, dans cette phrase : « We aim for minimal disruption by being thoughtful about how quickly we crawl the same domains and respecting Crawl-delay where appropriate. » C'est le seul éditeur qui nomme un signal de débit. Il nomme une directive du robots.txt que Google, de son côté, ne prend pas en charge, et il l'assortit de « where appropriate », qui est une réserve et non un engagement.

Le trou du Retry-After

La colonne la plus intéressante du tableau est celle où tout le monde est à zéro.

Retry-After est un en-tête HTTP standard. Il existe pour une raison et une seule : accompagner un 503 ou un 429 d'une indication de délai, en secondes ou en date. C'est le mécanisme que la norme a prévu pour que « revenez plus tard » devienne « revenez dans 3 600 secondes ». Il est le complément naturel du seul code qui demande un rendez-vous.

Il n'apparaît pas une fois dans les six documents, ni côté Google ni côté moteurs génératifs. Pas dans la page des codes HTTP, qui détaille pourtant le comportement du crawler face au 503. Pas dans la page sur la réduction du débit d'exploration, qui recommande le 503 comme outil et compte 40 occurrences de « crawl ». Pas dans la spécification du robots.txt, qui en compte 65.

Le constat vaut d'être posé clairement. L'en-tête conçu pour dire à un robot quand revenir n'est documenté par aucun des quatre acteurs qui font revenir des robots. Vous pouvez l'envoyer, rien ne vous l'interdit, mais personne ne s'est engagé à le lire.

Le test : la même question posée à deux couches

Restait à savoir ce qui se passe quand on pose la question directement aux moteurs. J'ai utilisé pour cela le commutateur de recherche web de l'API DataForSEO, qui permet d'interroger deux fois le même modèle, une fois sur sa mémoire seule et une fois avec accès au web. C'est le meilleur instrument dont dispose ce blog, parce qu'il isole la couche figée à la fin de l'entraînement de la couche qui va chercher.

Question posée le 17 septembre 2026, en français, à gpt-4o : « Combien de temps GPTBot, le robot d'exploration d'OpenAI, attend-il avant de réessayer une URL qui lui a répondu un code HTTP 503 ? Réponds précisément et cite ta source. »

Sans recherche web, la réponse est celle-ci, intégralement :

GPTBot attend 24 heures avant de reessayer une URL qui a
repondu avec un code HTTP 503. Cette information est tiree
de la documentation officielle d'OpenAI.

Un chiffre rond, une affirmation sans réserve, une source nommée. J'ai rejoué la requête pour vérifier qu'il ne s'agissait pas d'un tirage : le même chiffre est revenu, avec la même attribution. Lors d'un premier passage, le modèle avait même fourni l'adresse, openai.com/gptbot.

Avec la recherche web activée, le même modèle, le même jour, sur la même question, répond ceci :

Je n'ai trouve aucune information officielle precisant le
temps exact que GPTBot attend avant de reessayer une URL
ayant repondu avec un code HTTP 503. A ce jour, ni la
documentation publique d'OpenAI, ni les retours techniques
disponibles ne detaillent ce delai.

Les 24 heures ont disparu. Le modèle a formulé une requête de recherche que l'API me rend en clair, GPTBot HTTP 503 retry delay site:openai.com, il est donc allé regarder chez OpenAI, et il n'a rien trouvé.

Deux précautions sur ce que j'affirme ici. Je ne peux pas certifier le contenu de openai.com/gptbot : cette adresse m'a répondu 403 aux trois tentatives, avec un agent de navigateur comme avec un agent GPTBot. Ce que je peux affirmer, c'est que la documentation des robots d'OpenAI que j'ai réellement récupérée et lue, celle de platform.openai.com, ne contient aucune occurrence de 503, 5xx ni Retry-After, avec les témoins donnés plus haut. Et que le modèle lui-même, une fois branché sur le web, dit qu'il n'a rien trouvé.

Le point n'est pas que le modèle se trompe. Le point est que sa mémoire produit un nombre précis, plausible et sourcé là où aucun texte connu n'en contient, et que seul le passage par la couche de recherche le rétracte. C'est la même mécanique à deux couches que celle que j'avais mesurée sur les redirections 301 et les adresses périmées, et elle produit ici un cas d'école : la question est technique, la réponse est chiffrée, et le chiffre n'existe nulle part.

Ce que les moteurs vont chercher à la place

Reste le plus instructif : quand la documentation officielle est muette, le moteur ne renonce pas. Il cite autre chose.

La réponse de gpt-4o avec recherche web porte deux citations. Toutes les deux pointent vers le même site, geodocs.dev, deux pages qui traitent précisément des codes HTTP et du Retry-After pour les robots d'IA. Zéro citation d'openai.com. Sur une question qui porte sur le robot d'OpenAI, l'éditeur du robot n'est pas cité une seule fois, et un site tiers l'est deux fois.

J'ai posé la même question à Perplexity, modèle sonar, recherche web active. La réponse renvoie vingt sources. Le décompte mérite d'être détaillé.

Vingt sources rapportees par Perplexity (17/09/2026)
-------------------------------------------------------
openai.com                                            0
MDN Web Docs (Retry-After, 503)                       2
pages d'explication generique de l'erreur 503        15
sans rapport, appariees sur le seul nombre 503        3

Les trois de la dernière ligne valent qu'on les nomme, parce qu'elles disent quelque chose sur l'état du corpus : une décision du Conseil constitutionnel, la n° 2015-503 QPC du 4 décembre 2015 ; un test de VTT Wilier Triestina 503 ; et une référence produit « Fix 503 » chez un fabricant italien. Sur une question technique parfaitement définie, trois sources sur vingt ont été retenues sur la seule correspondance d'un nombre à trois chiffres.

Et la réponse que Perplexity construit avec ce matériau est la suivante : « La seule règle normative applicable est que, si la réponse inclut l'en-tête Retry-After, le robot doit attendre la durée indiquée. » La source de cette règle est MDN, c'est-à-dire la norme HTTP générale. Le moteur substitue la norme au comportement de l'éditeur, faute de disposer du second.

C'est, pour qui publie du contenu technique, une démonstration à retenir. Un vide documentaire ne reste pas vide. Il est occupé par ce qui traîne, et sur ce sujet précis ce qui traîne est un mélange de MDN, de tutoriels WordPress et de coïncidences numériques. Le moteur cite ce qu'il trouve, et il trouve ce que quelqu'un a écrit.

Ce que répond le web quand on le sonde

J'ai voulu vérifier la fréquence réelle du phénomène avant d'en tirer des consignes. Le 17 septembre 2026, j'ai interrogé la page d'accueil de trente sites français à forte audience, répartis entre e-commerce, presse, services en ligne, télécoms, banque (Boursorama, Qonto) et administration (Ameli, service-public.fr, impots.gouv.fr, pole-emploi.fr), avec quatre agents utilisateurs : GPTBot, ClaudeBot, PerplexityBot et un Chrome de bureau.

Trente hotes francais, 17 septembre 2026
----------------------------------------------
200 OK                                      11
403 interdit                                10
301 / 308 redirection                        7
202 accepte                                  1
echec de connexion                           1
----------------------------------------------
codes 5xx                                    0
divergences robot / navigateur               0

Deux enseignements, dont un négatif qu'il faut assumer.

Le négatif d'abord : aucun 5xx, sur trente hôtes et quatre agents. Le 503 permanent, celui qui dirait à un moteur « revenez plus tard » pendant des semaines, n'est pas un phénomène de masse sur les grands sites français. La consigne opérationnelle qui suit ne corrige donc pas une épidémie, elle prépare un épisode ponctuel.

Le second est plus net : dix hôtes sur trente refusent l'accès, et ils le refusent à l'identique, pour un robot comme pour un navigateur. Zéro divergence sur les quatre agents. Ces 403 ne sont donc pas des règles anti-IA, ce sont des filtres qui bloquent l'adresse IP d'où part la requête, quel que soit l'agent déclaré. Le tri par nom de robot, celui que les articles de méthode décrivent volontiers, n'est pas ce qui est à l'oeuvre ici.

Et il y a un cas que je ne peux pas passer sous silence, parce qu'il est le meilleur résumé de l'article : l'adresse que gpt-4o désigne comme sa source, openai.com/gptbot, fait partie des adresses qui répondent 403.

Ce que ça change en pratique

De tout ce qui précède, six consignes se déduisent sans extrapolation.

Servez un 503, pas un 200, pendant une maintenance. Une page de maintenance en 200 déclare au moteur que le contenu affiché est le contenu de l'adresse. Il peut l'indexer, et il peut le citer. Le 503 protège l'adresse : Google conserve les URL déjà indexées et ignore la charge reçue.

Ne servez pas un 503 plus de deux jours. C'est la limite que Google écrit lui-même. Au-delà, la page des codes HTTP prévoit la suppression de l'index, et la version de repli du robots.txt expire à trente jours.

Surveillez le robots.txt à part. Un 5xx sur ce fichier arrête l'exploration du site entier pendant douze heures. Il mérite son propre contrôle, indépendant de celui des pages.

Raisonnez par hôte, pas par URL. Le ralentissement s'applique au nom d'hôte complet. Quelques adresses en erreur pèsent sur l'exploration de tout le reste.

Envoyez quand même un Retry-After. Il ne coûte rien, il est conforme à la norme, et il est le seul moyen d'exprimer un délai. Mais ne construisez aucun plan sur l'idée qu'il sera respecté : aucun des quatre acteurs ne s'y est engagé par écrit.

Regardez vos journaux plutôt que les documentations. Puisque aucun éditeur ne publie sa politique de nouvelle tentative, le seul endroit où elle est observable est votre serveur. Le délai entre un 503 servi à GPTBot et sa requête suivante est dans vos logs, et il n'est nulle part ailleurs. C'est précisément le genre de question que l'analyse des logs de crawlers d'IA permet de trancher sans attendre qu'un éditeur se prononce.

Ce que cet article n'établit pas

Trois limites, qu'il vaut mieux nommer que laisser deviner.

Je n'ai mesuré aucun comportement réel de robot face à un 503. Tout ce que j'avance sur Google vient de sa documentation, et tout ce que j'avance sur les trois autres est un constat d'absence dans la leur. Il est parfaitement possible que GPTBot applique en interne une politique de réessai raisonnable. Ce que je montre est qu'elle n'est pas publiée, pas qu'elle n'existe pas.

Le sondage des trente hôtes est un instantané, pris un jour, depuis une seule origine réseau, sur des pages d'accueil. Un 503 est par nature transitoire, et un relevé ponctuel a toutes les chances de le manquer. Le zéro que je rapporte dit que le 5xx permanent est rare sur ces sites, il ne dit pas que ces sites ne renvoient jamais de 5xx.

Enfin, les réponses de modèles sont datées. Les 24 heures de gpt-4o sont stables sur deux exécutions le 17 septembre 2026, ce qui en fait une réponse de stock et non un tirage, mais rien ne garantit qu'une version ultérieure du modèle produira la même chose. La méthode, elle, reste valable : poser deux fois la même question, une fois à la mémoire et une fois à la recherche, et lire l'écart.

Ce qu'il faut retenir

Le 5xx est le seul code HTTP qui demande un délai au lieu de rendre un verdict, et c'est aussi le seul dont les moteurs génératifs ne disent rien.

Google en publie le mode d'emploi sur trois documents : ralentissement immédiat, perte différée, contenu ignoré, effet sur l'hôte entier, douze heures d'arrêt si le robots.txt tombe, deux jours de tolérance maximum, et un 429 reclassé en erreur serveur. OpenAI, Perplexity et Anthropic en disent zéro mot, avec des témoins qui prouvent que ce zéro est un silence éditorial et non une lecture manquée. L'en-tête Retry-After, conçu exactement pour ce cas, n'est nommé par aucun des quatre.

Interrogé sur ce vide, gpt-4o répond de mémoire « 24 heures » avec une source qui répond 403, et rétracte tout dès qu'il va chercher. Perplexity rapporte vingt sources dont aucune n'est celle de l'éditeur concerné et dont trois ne parlent pas du sujet.

La conséquence opérationnelle tient en une phrase, et elle est inhabituelle pour ce blog : sur cette question, personne ne peut vous répondre à partir d'un document, parce que le document n'existe pas. La réponse est dans vos journaux de serveur, et elle n'y sera que si vous les gardez.

Chez Orbite, nous instrumentons les journaux de nos clients pour observer ce que les robots d'IA font réellement de vos codes de réponse, y compris pendant les incidents. Si vous voulez savoir ce que les vôtres racontent : parlons de votre visibilité générative. Les termes employés ici sont définis dans le glossaire GEO.