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.
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 — Une réponse 503 Service Unavailable dit aux moteurs de recherche « le site est temporairement indisponible — revenez bientôt », et non « cette page a disparu ». Lorsque vous devez mettre votre site hors ligne pour une maintenance planifiée, une 503 est le bon code à renvoyer. Ajoutez un en-tête
Retry-Afterpour indiquer à Googlebot quand revenir, gardez votrerobots.txtaccessible et ne laissez pas la 503 active plus d’un ou deux jours.
Que signifie réellement une 503 ?
HTTP 503 signifie que le serveur est temporairement incapable de traiter la requête, et la norme autorise un en-tête Retry-After. 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 Google recommande 503 pour une courte indisponibilité, mais avertit qu’une absence prolongée peut affecter l’indexation. 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
Une 503 est un code d’état HTTP de la famille 5xx — le groupe « quelque chose ne va pas côté serveur ».
Plus précisément, le serveur est suffisamment disponible pour répondre, mais il ne peut pas servir la
requête pour le moment, généralement parce qu’il est surchargé ou que vous l’avez placé en mode
maintenance.
Le mot clé est temporaire. C’est ce qui distingue une 503 des autres codes auxquels vous pourriez recourir lorsqu’une page n’est pas disponible :
- 200 OK dit « voici le contenu » — même si ce « contenu » est un message « nous revenons bientôt ». Les moteurs de recherche le prennent au pied de la lettre et peuvent indexer la page d’erreur.
- 404 Not Found / 410 Gone disent « cette page n’existe pas / a disparu définitivement ». Les utiliser pendant une maintenance revient à dire à Google de supprimer la page.
- 503 Service Unavailable dit “I exist, I’m just busy — come back later.” (traduction) : « j’existe, je suis simplement occupée — revenez plus tard ». C’est celui qu’il faut utiliser pour une indisponibilité planifiée.
Pourquoi 503 est le bon choix pour une maintenance
Lorsque vous faites un déploiement, déplacez un serveur ou effectuez une maintenance programmée, vous voulez que les moteurs de recherche mettent en pause l’exploration, et non qu’ils concluent que vos pages sont mortes. Une 503 vous accorde cette pause. Google le dit directement : si vous devez mettre un site hors ligne brièvement, renvoyez 503, et non 404 ni une page d’erreur 200.
Imaginez un panneau « De retour dans 10 minutes » sur la porte d’un magasin. Une 404 revient à raser le magasin ; une page 200 « bientôt de retour » revient à remplacer tout votre stock par un panneau unique en espérant que les clients pensent toujours que vous vendez des chaussures. La 503 est le panneau qui conserve votre place.
L’en-tête Retry-After
Avec la 503, vous pouvez envoyer un en-tête Retry-After qui indique approximativement aux robots
quand revenir. Il peut contenir un nombre de secondes ou une date/heure précise :
HTTP/1.1 503 Service Unavailable
Retry-After: 3600Cet exemple demande aux robots d’attendre environ une heure. Google peut l’utiliser comme indication pour choisir le moment de la nouvelle exploration. Il ne reviendra pas à la seconde exacte, mais ne reviendra pas avant ce moment non plus.
Les trois erreurs à ne pas commettre
- Ne renvoyez pas 503 trop longtemps. Un jour ou deux conviennent. Beaucoup plus longtemps, Google commence à penser que la panne est permanente et peut retirer vos pages.
- Ne renvoyez pas 503 pour votre fichier
robots.txt. Si ce fichier renvoie 503, Google ne peut rien explorer — y compris la vérification qui lui indiquerait que vous êtes de nouveau en ligne. - N’utilisez pas une 404 ni une simple page 200 « bientôt de retour » à la place. Ces réponses envoient le mauvais signal et peuvent vous coûter plus cher que la 503.
Vous voulez les seuils de durée, les citations exactes de Google et l’implémentation par plateforme ? Passez à l’onglet Advanced.
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 votrerobots.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 OKressemble à 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-Afterest le signal prévu pour une indisponibilité planifiée. Le dommage vient du fait de la laisser active trop longtemps ou de renvoyer 503 pourrobots.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.
Résumé par IA
Une synthèse de la version Advanced :
- 503 = indisponibilité temporaire. C’est le bon code pour une maintenance planifiée — Google le préfère à 404/410 (permanentes) et à une page d’erreur 200 (qui est indexée comme contenu, souvent comme doublon).
- Associez-le à
Retry-After(secondes ou date HTTP), même si la RFC 9110 rend l’en-tête facultatif (unMAY) — Googlebot peut l’utiliser comme indication pour une nouvelle exploration et ralentit son rythme, mais rien ne lui impose un retour à une heure précise. - La durée est un spectre, pas une garantie : le seul chiffre venant de la documentation actuelle de Google est 1 à 2 jours, son plafond documenté pour une 503 urgente sur tout le site. Les commentaires de membres de Google relayés par Search Engine Journal présentent les fenêtres brèves (10 à 15 minutes, environ un jour) comme généralement acceptables et situent « quelques jours » et au-delà au moment où Google commence à traiter la 503 comme permanente et retire les pages — lisez cela comme une direction, et non comme un engagement de source primaire. Pour une fermeture plus longue, servez plutôt un espace réservé 200 indexable.
- Les métadonnées se figent : pendant qu’une 503 est servie, Google ne peut pas actualiser les titres, descriptions ou données structurées — des extraits obsolètes peuvent donc persister.
- Ne renvoyez jamais 503 pour
robots.txt— cela bloque toute l’exploration, y compris celle qui confirmerait votre retour. - 429 ≈ 503 pour le ralentissement de l’exploration ; Google les traite de la même manière.
- Le rétablissement après une longue panne est probable, mais « pas toujours garanti » un pour un (Mueller) ; la suppression complète de l’index n’a pas de délai de rétablissement fixe.
- Bonne pratique générale : la recommandation principale de Google est d’éviter complètement la coupure et de limiter les fonctionnalités tout en restant en ligne.
Documentation officielle
Recommandations issues de sources primaires sur 503 et les indisponibilités planifiées.
- Mettre temporairement en pause ou désactiver un site — recommandations actuelles et canoniques de Google : ordre de préférence, règle des 1 à 2 jours,
Retry-After, exception robots.txt, gel des métadonnées et conseil de vérification avec curl. - Gérer une interruption planifiée du site (article de blog de 2011) — article d’origine, désormais accompagné d’une bannière « obsolète, voir les bonnes pratiques ». Source de l’exemple PHP classique avec
Retry-After. - Guide détaillé du fonctionnement de Google Search — contexte sur le ralentissement du rythme d’exploration : les erreurs de la famille 500 signifient « ralentissez ».
RFC / référence technique
- MDN — 503 Service Unavailable — définition du code de statut fondée sur les normes.
- MDN — en-tête Retry-After — syntaxe des formes en secondes et en date HTTP.
Bing / Microsoft
- Bing ne publie pas de recommandations de maintenance par 503 aussi détaillées que Google.
Retry-Afterest un en-tête RFC standard (et non propre à Google), et Bingbot ralentit également l’exploration face à des réponses5xx/429répétées — mais considérez tout comportement précis de Bing comme déduit des sémantiques HTTP standard plutôt que comme une affirmation documentée.
Citations des sources
Déclarations attribuées provenant de Google. Chaque lien est un lien profond qui saute au passage cité sur la page source.
Documentation Google — règle des 1 à 2 jours
- “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. » Aller à la citation
- “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. » Aller à la citation
Documentation Google — robots.txt et métadonnées
- “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. » Aller à la citation
- “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) : « Les systèmes de Google ne peuvent pas 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. » Aller à la citation
- “removing a site completely from Google’s index is a significant change that can take quite some time to recover from.” (traduction) : « Retirer complètement un site de l’index de Google est un changement important dont le rétablissement peut prendre beaucoup de temps. » Aller à la citation
Blog Google Search Central (2011)
- “instead of returning an HTTP result code 404 (Not Found) or showing an error page with the status code 200 (OK) when a page is requested, it’s better to return a 503 HTTP result code (Service Unavailable) which tells search engine crawlers that the downtime is temporary.” (traduction) : « Au lieu de renvoyer un code HTTP 404 (Not Found) ou d’afficher une page d’erreur avec le code 200 (OK) lorsqu’une page est demandée, il vaut mieux renvoyer un code HTTP 503 (Service Unavailable), qui indique aux robots des moteurs de recherche que l’indisponibilité est temporaire. » Aller à la citation
- “If known, the length of the downtime in seconds or the estimated date and time when the downtime will be complete can be specified in an optional Retry-After header, which Googlebot may use to determine when to recrawl the URL.” (traduction) : « Si elle est connue, la durée de l’indisponibilité en secondes ou la date et l’heure estimées de sa fin peuvent être indiquées dans un en-tête Retry-After facultatif, que Googlebot peut utiliser pour déterminer quand réexplorer l’URL. » Aller à la citation
John Mueller, Google
- “please return a ‘503 Service unavailable’ HTTP result code… they’re generally more than happy to give your site some time to catch up again.” (traduction) : « veuillez renvoyer un code de résultat HTTP “503 Service unavailable”… ils sont généralement tout à fait disposés à laisser à votre site le temps de rattraper son retard. » Aller à la citation Depuis johnmu.com/503s/ (2013), republication personnelle par Mueller d’un message Google+. La page actuelle affiche des apostrophes typographiques ; le lien profond reste court pour garantir une correspondance exacte du texte.
- “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) : « Pour ces deux codes, la réaction est pratiquement identique : ils signalent une difficulté temporaire et nous ralentissons généralement l’exploration lorsqu’ils se multiplient. » (à propos de 429 contre 503) Aller à la citation Depuis johnmu.com/429-or-503/ (2015), une page que Mueller qualifie lui-même d’« ancienne, probablement obsolète ».
- “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 ». Aller à la citation Relaté par Search Engine Journal depuis une session de questions-réponses de Search Central ; confirmez-le dans la source originale avant de le considérer comme définitif.
Gary Illyes, Google
- “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) : « Une longue période de réponse 503 réduit le rythme d’exploration. Pour une fenêtre occasionnelle de 10 à 15 minutes, toutefois, on ne parle pas d’une durée prolongée : la situation devrait rester acceptable. » Aller à la citation Relaté par Search Engine Journal depuis une session SEO Office Hours de Google Search Central.
Checklist de maintenance planifiée en 503
Suivez-la avant, pendant et après la fenêtre de maintenance :
- Avez-vous décidé si une coupure complète est réellement nécessaire — pouvez-vous limiter les fonctionnalités et rester en ligne (option préférée par Google) ?
- La page de maintenance renvoie-t-elle réellement le statut
503(vérifié avec curl, et pas seulement observé dans un navigateur) ? - Un en-tête
Retry-Afterest-il défini (secondes ou date HTTP) avec une estimation réaliste ? -
robots.txtrenvoie-t-il toujours200et reste-t-il accessible — ne lui renvoyez jamais 503. - La page 503 est-elle légère : HTML statique, CSS intégré, pas de ressources lourdes (les robots la consulteront à répétition) ?
- Une échéance interne stricte est-elle définie pour passer à un espace réservé 200 indexable si la fenêtre dépasse environ 1 à 2 jours ?
- Aucune page ne renvoie-t-elle
404/410ni une page 200 « bientôt de retour » à la place de la 503 ? - Surveillez-vous Indexation des pages et Statistiques d’exploration de Search Console
pendant et après la fenêtre pour détecter les pics de
5xx? - Après la maintenance : avez-vous confirmé le retour des pages en
200, demandé une nouvelle exploration des URL importantes via l’inspection d’URL et vérifié l’actualisation des métadonnées/extraits ?
SOP : placer correctement votre site en mode maintenance planifiée
Une procédure reproductible pour une courte fenêtre de maintenance sûre.
Avant la fenêtre
- Déterminez l’étendue. Si vous pouvez laisser le site en ligne et désactiver seulement la partie risquée (panier, paiement, fonctionnalité défaillante), faites-le — c’est la recommandation principale de Google et cela évite tous les risques ci-dessous. Ne passez à une 503 complète que si vous devez vraiment tout mettre hors ligne.
- Estimez honnêtement la durée. Si elle dépassera vraisemblablement 1 à 2 jours, ne prévoyez pas une 503 sur tout le site — prévoyez plutôt une page d’accueil 200 indexable comme espace réservé.
- Construisez une page de maintenance légère. HTML statique, CSS intégré, images en base64 ou aucune image. Les robots (et les utilisateurs) la demanderont à répétition ; elle ne doit donc pas alourdir le serveur.
Configurer la réponse
- Renvoyez une vraie 503 pour le contenu du site. Exemples :
- Apache (
.htaccess) : redirigez tout vers la page de maintenance et forcez le statut —RewriteEngine On RewriteCond %{REQUEST_URI} !^/maintenance\.html$ RewriteCond %{REQUEST_URI} !^/robots\.txt$ RewriteRule ^ /maintenance.html [R=503,L] ErrorDocument 503 /maintenance.html Header always set Retry-After "3600" - Nginx :
location / { return 503; } error_page 503 /maintenance.html; location = /maintenance.html { internal; add_header Retry-After 3600; } location = /robots.txt { } # keep robots.txt serving 200 - PHP (forme de l’exemple de Google) :
header('HTTP/1.1 503 Service Unavailable'); header('Retry-After: 3600');
- Apache (
- Définissez
Retry-Aftersur une estimation réaliste — secondes (3600) ou date HTTP. - Exemptez
robots.txt. Vérifiez querobots.txtrenvoie toujours200(voir les conditions de réécriture ci-dessus). C’est l’étape que la plupart des gens oublient.
Vérifier
- Confirmez le statut avec curl, et non avec le navigateur :
curl -I -X GET "https://www.example.com/" # expect: HTTP/1.1 503 Service Unavailable + Retry-After: ... curl -I "https://www.example.com/robots.txt" # expect: HTTP/1.1 200 OK
Pendant et après
- Surveillez l’horloge. Si vous approchez du plafond de 1 à 2 jours, passez à un espace réservé
200indexable avant que Google ne commence à traiter la 503 comme permanente. - Rétablissez le site. Supprimez la règle 503 et confirmez que les pages renvoient de nouveau
200. - Revérifiez. Utilisez l’inspection d’URL de GSC sur les pages importantes, surveillez les
Statistiques d’exploration jusqu’à la résorption du pic de
5xxet confirmez l’actualisation des titres/descriptions/données structurées (ils étaient figés pendant la 503).
Ce qu’il ne faut pas faire — et les mythes associés
Mythe : « Une 503 pendant plus de quelques jours est totalement sûre si j’utilise Retry-After. »
Retry-After améliore la précision ; il ne repousse pas le plafond de Google. La documentation limite
une 503 urgente sur tout le site à 1 ou 2 jours, et Mueller dit : “after a couple of days we think this
is a permanent result code… and we will drop them from the index.” (traduction) : « après quelques
jours, nous pensons qu’il s’agit d’un code permanent… et nous les retirerons de l’index ». Passez à un
espace réservé 200 avant d’y arriver.
Mythe : « Une 503 n’a aucun effet SEO si elle est correctement implémentée. » Même une 503 courte et correcte met en pause l’actualisation des métadonnées — titres, descriptions et données structurées ne peuvent pas être mis à jour pendant qu’elle est servie — et toute 503 fait baisser le rythme d’exploration. Dans ce contexte, « sans danger » signifie « pas de dommage permanent si la durée est brève », et non « invisible ».
Mythe : « Une page 404 ou 200 “bientôt de retour” est tout aussi bonne pendant une maintenance. »
Non. 404/410 signalent une suppression définitive et font retirer les pages plus vite. Une page
d’erreur 200 générale est indexée comme contenu — et si chaque URL renvoie la même page, Google peut
les considérer comme des doublons.
Mythe : « Il faut aussi renvoyer 503 pour robots.txt, par souci de rigueur. »
C’est l’inverse. Un robots.txt en 503 bloque toute l’exploration, y compris celle qui confirmerait
le retour du site. Gardez-le en 200.
Mythe : « Si Google retire mes pages pendant la panne, elles reviendront exactement à l’identique. » C’est probable, mais “not always guaranteed” (traduction) : « ce n’est pas toujours garanti », et le rétablissement après une suppression complète n’a pas de délai fixe ni de moyen de l’accélérer.
Mythe : « 429 et 503 sont des signaux totalement différents. » Pour le ralentissement de l’exploration, Google “treat[s] them both about the same.” (traduction) : « les traite à peu près de la même manière ».
L’anti-pattern à retenir : servir une simple page 200 OK « site en maintenance ». C’est l’erreur
la plus fréquente et celle contre laquelle Google met le plus directement en garde.
503 pour une maintenance — aide-mémoire
Quel code pour quelle situation
| Situation | Code | Pourquoi |
|---|---|---|
| Maintenance planifiée courte (≤ 1 à 2 jours) | 503 + Retry-After | « Temporaire — revenez vérifier » |
| Maintenance de plus de 1 à 2 jours | 200 espace réservé indexable | 503 serait lue comme permanente |
| Page supprimée définitivement | 404 / 410 | Suppression réelle |
| Désactiver le panier ou une seule fonctionnalité | rester en 200, limiter les fonctionnalités | Recommandation principale de Google |
| Serveur surchargé ou limitation de débit | 503 ou 429 | Google les traite de la même manière |
Spectre des durées
| Fenêtre | Verdict |
|---|---|
| 10 à 15 min, occasionnellement | Sans problème (Illyes) |
| Environ un jour | Sans problème (Mueller) |
| 1 à 2 jours | Plafond documenté par Google pour une 503 sur tout le site |
| « Quelques jours » et au-delà | Google traite 503 comme permanente — pages retirées |
| Semaines | Perte d’index presque certaine ; pas de délai de rétablissement fixe |
La ligne 1 à 2 jours est le plafond documenté actuel de Google. Les lignes à la minute et à la journée proviennent de commentaires de membres de Google relayés par Search Engine Journal, et non de la documentation primaire de Google — lisez ce spectre comme une direction, et non comme une fenêtre garantie sans risque.
Formes de Retry-After
- Secondes :
Retry-After: 3600 - Date HTTP :
Retry-After: Sat, 8 Oct 2011 18:27:00 GMT
Règles à ne pas oublier
robots.txtreste en 200 — ne lui renvoyez jamais 503.- Page 503 = HTML statique, CSS intégré (les robots la demandent à répétition).
- 503 fige les titres/descriptions/données structurées indexés — ils ne seront pas actualisés.
- Vérifiez avec
curl -I, et non avec le navigateur.
Vérifier que votre 503 est réellement une 503
Un navigateur peut afficher une page de maintenance alors que le serveur renvoie discrètement 200.
Vérifiez le vrai code de statut et les en-têtes avec curl.
macOS / Linux
# Site content should return 503 with a Retry-After header
curl -I -X GET "https://www.example.com/"
# expect: HTTP/1.1 503 Service Unavailable
# Retry-After: 3600
# robots.txt must stay reachable (200), NOT 503
curl -I "https://www.example.com/robots.txt"
# expect: HTTP/1.1 200 OKWindows (PowerShell)
# -SkipHttpErrorCheck lets PowerShell show the 503 instead of throwing
(Invoke-WebRequest -Uri "https://www.example.com/" -Method Head -SkipHttpErrorCheck).StatusCode
(Invoke-WebRequest -Uri "https://www.example.com/robots.txt" -Method Head).StatusCodeRéponses 503 minimales
PHP (forme de l’exemple de Google)
<?php
header('HTTP/1.1 503 Service Unavailable');
header('Retry-After: 3600'); // or an HTTP date: 'Sat, 8 Oct 2011 18:27:00 GMT'
?>
<!DOCTYPE html>
<title>We'll be right back</title>
<h1>Down for scheduled maintenance</h1>
<p>We expect to be back within the hour. Thanks for your patience.</p>Nginx (contenu 503, robots.txt exempté)
location / {
return 503;
}
error_page 503 /maintenance.html;
location = /maintenance.html {
internal;
add_header Retry-After 3600;
}
location = /robots.txt { } # keep serving robots.txt normally (200)Gardez la page de maintenance statique, avec du CSS intégré et sans ressources lourdes — les robots la demanderont à répétition et vous ne voulez pas qu’elle surcharge elle-même le serveur.
Outils pour gérer et vérifier une 503
curl -I— le moyen le plus rapide de confirmer le vrai code de statut et l’en-têteRetry-After(un navigateur peut masquer la réalité). Voir l’onglet Scripts.- Google Search Console — inspection d’URL — vérifiez le dernier statut exploré d’une URL précise et demandez une nouvelle exploration une fois le site de nouveau en ligne.
- GSC — rapport Statistiques d’exploration — surveillez le pic de
5xx/503pendant la fenêtre et confirmez sa résorption ensuite. - GSC — rapport Indexation des pages — repérez les pages retirées si la fenêtre a duré trop longtemps.
- Screaming Frog SEO Spider — explorez votre propre site pour confirmer quelles URL renvoient 503
contre 200 (et que
robots.txtne renvoie pas 503). - Ahrefs Site Audit / Ahrefs Webmaster Tools — fait remonter les réponses
5xxdu site afin de détecter une 503 oubliée après la fenêtre. - Plugins WordPress de mode maintenance (par exemple WP Maintenance Mode) — WordPress renvoie déjà
503 automatiquement pendant les mises à jour du cœur ou des plugins ; un plugin offre une page de
maintenance contrôlée — vérifiez simplement qu’il ne renvoie pas 503 à
robots.txt.
Ressources qui valent votre temps
Mes articles associés
- Codes de statut HTTP : la liste complète pour le SEO — mon guide complet des codes importants pour le SEO, avec 503 dans le contexte
5xx. Cette analyse consacrée à un seul sujet développe le traitement en une ligne de ce guide. - Guide du SEO technique pour débutants — place de l’exploration, des codes de statut et de la maintenance dans une vue d’ensemble.
Dans le reste du secteur
- Mettre temporairement en pause ou désactiver un site (Google Search Central) — recommandation actuelle et canonique ; commencez par cette page.
- Gérer une interruption planifiée du site (blog Google Search Central, 2011) — article d’origine et exemple PHP classique de
Retry-After. - 503s (John Mueller, johnmu.com) — explication simple de Mueller sur l’intérêt de renvoyer 503 pendant une indisponibilité.
- L’impact SEO des codes de statut 503 (Search Engine Journal) — Gary Illyes sur le repère « 10 à 15 minutes ne posent pas de problème ».
- Google désindexera les pages si le site est indisponible plusieurs jours (Search Engine Journal) — le seuil de Mueller « quelques jours… nous les retirerons ».
- HTTP 503 : gérer correctement la maintenance d’un site pour le SEO (Yoast) — guide pratique, orienté WordPress, du fonctionnement de
Retry-After. - 503 Service Unavailable (MDN) — référence normative du code de statut lui-même.
Vidéos
- Google Search Central (YouTube) — la série How Google Search Works et les archives SEO Office Hours, où Mueller et Illyes ont répondu aux questions sur la maintenance en 503 et les délais de désindexation cités dans cette page. Chaîne
Statistiques à citer
- 1 à 2 jours — plafond documenté par Google pour utiliser une 503 sur tout le site lors d’une désactivation urgente ; au-delà, passez à un espace réservé 200. Source
- 10 à 15 minutes, occasionnellement = sans problème — Gary Illyes sur la brièveté possible d’une fenêtre 503 sans baisse du rythme d’exploration. Source
- « Quelques jours » — moment où Google commence à traiter 503 comme permanente et à retirer les pages de l’index (John Mueller). Source
- Aucun délai de rétablissement fixe — documentation de Google sur le rétablissement après une suppression complète de l’index : aucun calendrier défini et aucun moyen de l’accélérer. Source
Testez-vous : 503 Service Unavailable
Cinq questions rapides sur l’utilisation de 503 pour une maintenance planifiée. Choisissez une réponse pour chaque question, puis vérifiez.
Journal des modifications
Mis à jour le 8 août 2026.
Résumé éditorial et détails enregistrés des changements.Détails des changements
-
Les notes détaillées des changements sont actuellement disponibles en anglais.
Comparaison complète indisponible — aucun instantané antérieur n’a été archivé pour cette révision.
Mis à jour le 17 juil. 2026.
Résumé éditorial et détails enregistrés des changements.Détails des changements
-
Les notes détaillées des changements sont actuellement disponibles en anglais.
Comparaison complète indisponible — aucun instantané antérieur n’a été archivé pour cette révision.
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.