Pendant une maintenance, servez vos pages en HTTP 503 avec un en-tête Retry-After, laissez robots.txt répondre normalement, et empêchez la mise en cache de la réponse. Le reste — le graphisme de la page, la formulation du message — n’a aucun effet sur ce que comprennent les moteurs de recherche.
Le code HTTP est le vrai message
Un robot ne lit pas votre page comme un visiteur. Il lit d’abord le code de réponse, et ce code raconte une histoire différente selon sa valeur. Quatre situations, quatre interprétations :
| Réponse servie | Ce que le moteur en déduit |
|---|---|
200 OK | Cette page a changé. Son nouveau contenu est ce message de maintenance, et il est permanent. |
301 vers une page unique | Toutes vos URL ont été fusionnées en une seule, définitivement. |
404 ou 410 | Ces pages n’existent plus. |
500 | Ce site est en panne. Rien n’indique que quelqu’un s’en occupe, ni quand cela finira. |
503 | Le service est momentanément indisponible. Reviens plus tard, rien n’a changé. |
Seule la dernière ligne décrit une maintenance. Les autres décrivent des changements permanents ou une défaillance, et un moteur qui les prend au mot met du temps à revenir sur sa conclusion.
La distinction entre les deux dernières lignes est celle qu’on néglige le plus souvent. Un site laissé en erreur 500 pendant la durée d’un dépannage envoie exactement le mauvais signal, alors qu’un 503 assumé ne coûte rien.
Ce que dit exactement la norme
Le statut 503 signifie que le serveur est momentanément incapable de traiter la requête, en raison d’une surcharge ou d’une maintenance. La spécification HTTP précise deux points utiles : cette condition est supposée temporaire, et le serveur peut indiquer une durée d’attente via Retry-After.
C’est bien un code d’erreur serveur, pas un code informatif. Il n’est donc pas gratuit : il est fait pour durer des minutes ou des heures, pas des semaines.
Retry-After : deux formats, une seule règle
L’en-tête accepte soit un nombre de secondes, soit une date HTTP absolue. Les deux sont valides :
Retry-After: 3600
Retry-After: Wed, 20 Aug 2026 22:00:00 GMTLa règle unique : ne pas inventer une précision que vous ne tiendrez pas. Une valeur prudente et large vaut mieux qu’un horizon dépassé. Si l’intervention se prolonge, la valeur annoncée devient un mensonge que vos outils de supervision, eux, remarqueront.
Noindex est une ceinture, pas le moteur
La consigne noindex — en balise meta ou en en-tête X-Robots-Tag — indique que la page temporaire n’a pas vocation à entrer dans les résultats. C’est une précaution utile, pas le mécanisme principal.
Le signal qui compte reste le 503. Et il y a une subtilité : un moteur qui reçoit un 503 n’est pas censé indexer la page du tout, donc la consigne arrive en renfort plutôt qu’en première ligne. Elle protège surtout contre le cas où votre page de maintenance se retrouverait servie en 200 par une couche intermédiaire — un cache, un CDN, un proxy.
Le piège qui coûte le plus cher : robots.txt en erreur
C’est le point le plus important de cette page, et le plus souvent manqué. Si votre mécanisme de maintenance intercepte toutes les requêtes, il intercepte aussi robots.txt. Or une réponse 5xx prolongée sur ce fichier ne fait pas cesser l’exploration d’une page : elle fait cesser l’exploration du site entier.
Vous obtenez alors l’inverse exact de ce que vous vouliez : au lieu de dire « je reviens », vous dites « ne regarde plus rien ici ». robots.txt doit conserver sa réponse normale pendant toute la fenêtre de maintenance.
Sur un WordPress laissé en permaliens simples, l’exclusion habituelle de robots.txt ne fonctionne pas : is_robots() dépend de règles de réécriture qui n’existent pas encore. Le défaut est invisible sur un site en permaliens jolis, et bien réel sur l’autre. Le chemin de la requête doit être contrôlé en plus de la condition WordPress.
Ne laissez pas cacher la réponse
Une page de maintenance mise en cache survit à la maintenance. C’est la cause numéro un des sites qui restent « en travaux » après la réouverture. La réponse doit porter des en-têtes qui l’interdisent :
Cache-Control: no-cache, must-revalidate, max-age=0, no-store, privateEt à la réouverture, purgez tout de même dans l’ordre : extension de cache, cache de l’hébergeur, puis CDN.
Combien de temps peut durer une maintenance
Quelques heures ne posent aucun problème. Une journée reste raisonnable. Au-delà de plusieurs jours consécutifs, le message change de nature : un service durablement indisponible finit par être traité comme tel, et l’expérience utilisateur se dégrade bien avant que le référencement ne bouge.
Pour une refonte longue, la bonne réponse n’est pas un 503 qui dure : c’est un site de remplacement qui répond en 200 sur les URL que vous voulez conserver.
La vérification minimale
curl -I https://votre-site.fr/
curl -I https://votre-site.fr/robots.txt- La page publique renvoie
503depuis une session non connectée. Retry-AfteretX-Robots-Tagsont présents.robots.txtne renvoie pas 5xx.- La connexion et l’administration restent accessibles.
- Le retour en
200est confirmé après désactivation.
Ces contrôles font partie de la procédure appliquée à la bêta 0.1.5 de Mes503 Maintenance Page, qui envoie le 503, le Retry-After, le X-Robots-Tag et les en-têtes anti-cache, et laisse robots.txt intact. La méthode complète d’une intervention est détaillée dans le guide mettre WordPress en maintenance proprement.