503 — service indisponible

Pourquoi 503 est le bon statut pour une maintenance planifiée, comment l’en-tête Retry-After guide Googlebot, comment Google ralentit l’exploration sur les 503 et comment éviter une désindexation accidentelle.

Première publication : 28 juin 2026 · Dernière mise à jour : 8 août 2026 · Advanced
Langues

503 Service Unavailable est le bon code de statut pour une indisponibilité temporaire et planifiée — Google le recommande explicitement plutôt qu’une 404 ou qu’une page 200 « bientôt de retour ». Associez-lui un en-tête Retry-After pour indiquer à Googlebot quand revenir, gardez robots.txt accessible (ne lui renvoyez jamais 503) et considérez 1 à 2 jours comme la limite supérieure pour un 503 sur tout le site. Au-delà de quelques jours, Google commence à lire la 503 comme permanente, vos titres et descriptions indexés restent figés au lieu d’être actualisés et les pages peuvent sortir de l’index, sans garantie de rétablissement un pour un. Pour une fermeture plus longue, passez plutôt à un espace réservé 200 indexable.

TL;DR — 503 est le bon code pour une indisponibilité temporaire, et Google le préfère explicitement à 404/410 (permanentes) ou à une page d’erreur 200 (contenu indexable sans intérêt). Associez-le à Retry-After. Le plafond recommandé par Google pour une 503 sur tout le site est de 1 à 2 jours ; au-delà de « quelques jours », Google la traite comme permanente et retire les URL. Une 503 fige aussi vos métadonnées indexées — titres, descriptions et données structurées ne seront pas actualisés tant qu’elle est servie. Ne renvoyez jamais 503 pour votre robots.txt. Google traite 429 et 503 de la même manière pour le ralentissement de l’exploration. Le rétablissement après une longue panne est probable, mais pas garanti un pour un. Au-delà d’un jour ou deux, servez plutôt un espace réservé 200 indexable.

Ce que 503 est — et n’est pas

Une 503 est une condition serveur temporaire, et non un signal de suppression définitive. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: RFC 9110: 503 Le comportement de la recherche dépend de la durée et de la répétition des réponses ; le délai de rétablissement n’est pas garanti. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Pause an online business

La RFC 9110 emploie volontairement un langage prudent : le serveur est actuellement incapable de traiter la requête, le rétablissement est décrit comme probable, et non certain, et l’en-tête Retry-After est facultatif — un MAY, pas une obligation. La norme n’oblige pas un robot à revenir à un moment particulier, et un serveur peut même éviter complètement la 503 et simplement refuser la connexion. Cela compte pour toute cette page : tout ce qui suit sur le comportement d’exploration de Google et le délai de rétablissement décrit ce qui tend à se produire, et non une garantie contractuelle.

503 sert à signaler une indisponibilité côté serveur temporaire. Ce n’est pas un outil général pour « cacher cette page », et ce code n’est pas interchangeable avec ses voisins :

  • 404 / 410 — suppression définitive. Pendant une maintenance, ces codes disent à Google que vos pages ont disparu, et il commencera à les retirer (la 410 un peu plus vite que la 404).
  • 200 avec contenu d’erreur — une page « nous revenons bientôt » renvoyant 200 OK ressemble à du vrai contenu. Google l’indexe et, si chaque URL renvoie la même page, peut la considérer comme dupliquée.
  • 503 — « je suis là, simplement temporairement indisponible ». C’est le code qui dit pause, et non suppression.

Ce que Google recommande réellement (dans l’ordre)

Les recommandations actuelles et activement maintenues de Google (Mettre temporairement en pause ou désactiver un site) décrivent un ordre de préférence que la plupart des articles concurrents oublient. Commençons par là :

1. Ne mettez pas tout le site dans le noir — limitez plutôt les fonctionnalités. La recommandation principale de Google est de laisser le site en ligne et de désactiver seulement les parties risquées (désactiver le panier, afficher une bannière, mettre à jour vos données structurées ou votre flux Merchant Center), car cela “minimizes any negative effects on your site’s presence in Search.” (traduction) : « minimise tout effet négatif sur la présence de votre site dans la recherche ». La 503 sur tout le site est le recours, et non le choix par défaut.

2. Si vous devez désactiver tout le site : la règle des 1 à 2 jours. Google qualifie une coupure complète de “an extreme measure that should only be taken for a very short period of time (a few days at most),” (traduction) : « une mesure extrême qui ne devrait être prise que pendant une très courte période (quelques jours au maximum) », et précise le mécanisme : “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code instead of all content.” (traduction) : « si vous devez désactiver d’urgence le site pendant 1 à 2 jours, renvoyez une page d’erreur informative avec un code de réponse HTTP 503 au lieu de tout le contenu ».

3. Au-delà : passez à un espace réservé 200 indexable. Une fois un jour ou deux dépassés, cessez de servir des 503. Google dit : “If you need to disable the site for a longer time, then provide an indexable home page as a placeholder for users to find in Search by using the 200 HTTP status code.” (traduction) : « si vous devez désactiver le site plus longtemps, fournissez une page d’accueil indexable comme espace réservé que les utilisateurs pourront trouver dans la recherche, en utilisant le code de statut HTTP 200 ».

Le spectre des durées (il n’existe pas de seuil unique et ferme)

Les différentes sources de Google donnent un spectre, et non un chiffre magique — il est indicatif, pas une garantie de conformité. Le seul chiffre provenant de la documentation actuelle de Google est le plafond de 1 à 2 jours ci-dessous ; les chiffres à la minute ou à la journée sont des commentaires de membres de Google relayés par Search Engine Journal dans des sessions de questions-réponses, et non des déclarations issues d’une source primaire auxquelles vous pourriez opposer Google.

  • Quelques minutes, occasionnellement. Gary Illyes, selon une retranscription secondaire : “Serving a 503 status code for an extended period of time will cause a decrease in crawl rate. Fortunately for you, 10-15 minutes every now and then is not ‘extended’ by any means, so you should be fine.” (traduction) : « Servir un code 503 pendant une période prolongée entraînera une baisse du rythme d’exploration. Heureusement, une fenêtre de 10 à 15 minutes de temps en temps ne constitue en aucun cas une période prolongée, vous pouvez donc rester serein. »
  • Un jour environ. John Mueller, selon une retranscription secondaire : “For an outage of maybe a day or so, using a 503 result code is a great way to tell us that we should check back.” (traduction) : « Pour une panne d’un jour environ, utiliser un code de résultat 503 est un excellent moyen de nous dire que nous devons revenir vérifier. »
  • 1 à 2 jours. Le plafond documenté par Google pour une 503 urgente sur tout le site — le seul chiffre de cette liste provenant des recommandations actuelles et primaires de Google.
  • « Quelques jours » et au-delà. C’est là que la situation bascule. Mueller, selon une retranscription secondaire : “after a couple of days we think this is a permanent result code, and we think your pages are just gone, and we will drop them from the index.” (traduction) : « après quelques jours, nous pensons qu’il s’agit d’un code de résultat permanent, que vos pages ont simplement disparu et nous les retirerons de l’index ».
  • Des semaines. Perte d’index presque garantie et — selon la documentation — le rétablissement après une suppression complète prend “no fixed time … and there’s no mechanism to speed that up.” (traduction) : « un temps indéterminé… et il n’existe aucun mécanisme pour l’accélérer ».

Tout cela ne constitue pas un compte à rebours de zone sûre. Cela décrit ce qui tend à se produire, et non une règle dont vous pouvez déduire un résultat précis — considérez le chiffre de 1 à 2 jours comme la limite extérieure à prendre en compte, et non comme la garantie que tout ce qui se trouve en dessous est sans risque.

Le gel des métadonnées (le risque dont personne ne parle)

Même une 503 courte et correcte a un coût souvent oublié : pendant que vous servez des 503, Google ne peut pas actualiser ce qu’il possède déjà. La documentation dit clairement : “it’s not possible for Google’s systems to refresh titles, descriptions, metadata, or structured data included on a website if a page returns a 503 HTTP response status code.” (traduction) : « il n’est pas possible pour les systèmes de Google d’actualiser les titres, descriptions, métadonnées ou données structurées d’un site si une page renvoie un code de réponse HTTP 503 ».

Une 503 fige donc vos métadonnées indexées — elle ne les efface pas et ne les met pas à jour. Si vous avez modifié un titre ou un balisage de données structurées juste avant la maintenance, un extrait SERP obsolète peut persister pendant toute la fenêtre. « Sûr » signifie « pas de dommage permanent si la durée est brève », et non « invisible ».

Ne renvoyez jamais 503 pour robots.txt

C’est un piège fréquent : certains plugins de mode maintenance et certaines règles CDN globales renvoient 503 pour tout, y compris robots.txt. Ne le faites pas. Google est explicite : “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.” (traduction) : « ne renvoyez pas de code de réponse HTTP 503 pour le fichier robots.txt, car cela bloque toute l’exploration ». Un robots.txt en 503 empêche Google d’explorer quoi que ce soit — y compris la nouvelle exploration qui confirmerait votre retour. Gardez robots.txt en 200, même pendant une panne complète du site.

503 contre 429 — Google les traite de la même manière

Dans le contexte de la limitation de débit, les gens recherchent indifféremment « 429 ou 503 ». Pour le rythme d’exploration, ils sont équivalents pour Google. Mueller (sur une page qu’il a lui-même marquée plus tard comme ancienne) : “we treat them both about the same. We see both as a temporary issue, and tend to slow down crawling if we see a bunch of them.” (traduction) : « nous les traitons à peu près de la même manière. Nous les considérons tous deux comme un problème temporaire et avons tendance à ralentir l’exploration si nous en voyons beaucoup ». Même logique de ralentissement ; une 429 Too Many Requests et une 503 disent toutes deux à Googlebot de lever le pied. (Leurs cousines 502/504, les autres erreurs transitoires de passerelle ou de délai, reçoivent un traitement proche — des 5xx persistantes, quelle que soit leur variante, ralentissent l’exploration.)

Le rétablissement est probable — pas garanti

Le meilleur antidote aux mythes sur ce sujet : si une longue panne fait sortir vos pages de l’index, elles reviennent généralement, mais pas toujours à l’identique. Mueller : “when the pages come back we will crawl them again and we will try to index them again. But it’s essentially during that time we will probably drop a lot of the pages from the website from our index, and there’s a pretty good chance that it’ll come back in a similar way but it’s not always guaranteed.” (traduction) : « lorsque les pages reviendront, nous les explorerons et tenterons à nouveau de les indexer. Mais pendant cette période nous retirerons probablement beaucoup de pages du site de notre index ; il y a de bonnes chances qu’elles reviennent de manière similaire, mais ce n’est pas toujours garanti ». Planifiez vos fenêtres de maintenance comme si le rétablissement pouvait être imparfait, car c’est possible.

Quelques FAQ à traiter directement

  • Une 503 nuit-elle au SEO ? Pas lorsqu’elle est brève et correcte. Une 503 courte avec Retry-After est le signal prévu pour une indisponibilité planifiée. Le dommage vient du fait de la laisser active trop longtemps ou de renvoyer 503 pour robots.txt.
  • 503 ou 404 est-elle préférable pour une maintenance ? 503, à chaque fois. Une 404 dit « disparu » et commence la désindexation ; une 503 dit « de retour bientôt ».
  • WordPress renvoie-t-il 503 pendant les mises à jour ? Oui — WordPress sert automatiquement une 503 pendant la mise à jour du cœur ou des plugins. C’est le comportement correct ; la fenêtre dure normalement quelques secondes.
  • Puis-je simplement afficher une page « bientôt de retour » en 200 ? Non. Une page d’erreur 200 est indexée comme du contenu et, si elle est identique pour chaque URL, Google peut considérer ces URL comme des doublons.

La seule règle à retenir

Le plafond fixé par Google pour une 503 urgente sur tout le site est de 1 à 2 jours — prenez-le comme la limite extérieure à planifier, et non comme une fenêtre garantie sans risque. Même dans cette fenêtre, une 503 met en pause votre rythme d’exploration et fige vos métadonnées, et rien ici ne promet un résultat précis en matière de classement, d’indexation ou de rétablissement. Au-delà de cette limite, passez à un espace réservé 200 indexable avant que Google ne décide que vos pages ont disparu. Tout le reste de cette page est une précision autour de cette règle.

Pour les codes voisins, consultez le reste du cluster des codes de statut HTTP.

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.