Un site internet en maintenance envoie deux messages à la fois : une page d’attente pour vos visiteurs, et un code HTTP pour Google. Le premier rassure vos clients. Le second protège votre référencement, à condition d’être le bon : un code 503, accompagné d’un en-tête Retry-After.
Imaginez : vous ouvrez votre propre site et lisez « Indisponibilité temporaire pour cause de maintenance. Veuillez revenir dans un instant. » Personne ne vous a prévenu. Ce guide explique d’où vient ce message sous WordPress et comment le faire disparaître, puis comment mener une vraie maintenance comme un chantier : le code à renvoyer, la durée tolérable, le sort du robots.txt et le contenu de la page. Chaque règle vient de la documentation de WordPress, de Google ou de MDN, relue le 19 octobre 2026.
Que signifie le message de maintenance qui s’affiche sur votre site WordPress ?
Il signifie qu’une mise à jour est en cours, ou qu’elle s’est arrêtée en route. Pendant une mise à jour, WordPress crée à la racine du site un fichier nommé .maintenance. Tant que ce fichier est récent, chaque visiteur reçoit la page de maintenance, avec un code 503 et l’en-tête Retry-After: 600, autrement dit : revenez dans 600 secondes, soit dix minutes.
Le mécanisme se lit dans le code publié sur developer.wordpress.org. La méthode WP_Upgrader::maintenance_mode écrit ce fichier avec l’heure du moment ; le commentaire qui l’accompagne dit son rôle : « créer le fichier de maintenance pour signaler que nous faisons une mise à jour » (traduit de l’anglais). À la fin de l’opération, la même méthode le supprime.
Entre les deux, la fonction wp_maintenance intercepte chaque visite. Elle envoie l’en-tête Retry-After: 600, puis arrête l’affichage avec le code 503 et le message que vous avez lu, dans sa traduction française officielle. Sur cet en-tête, MDN précise que, dans une réponse 503, il « indique pendant combien de temps le service est censé être indisponible », sous forme de date ou de nombre de secondes.
Vous pouvez remplacer cette page austère : WordPress affiche à la place un fichier maintenance.php placé dans le dossier wp-content. Un détail compte alors pour votre référencement. Le code du cœur charge votre fichier et s’arrête là, sans poser lui-même ni le code 503 ni l’en-tête Retry-After. C’est donc à votre fichier de les envoyer ; demandez-le noir sur blanc à la personne qui l’écrit.
Votre site WordPress reste bloqué en maintenance : que faire ?
Attendez d’abord dix minutes. La fonction wp_is_maintenance_mode compare l’heure inscrite dans le fichier .maintenance à l’heure actuelle : au-delà de dix minutes, le cœur considère la maintenance terminée, même si le fichier est toujours là. Supprimez ensuite ce fichier à la racine, puis vérifiez que la mise à jour est allée au bout.
Voici l’ordre à suivre :
- Patientez dix minutes sans relancer de mise à jour. Chaque nouvelle mise à jour réécrit le fichier avec l’heure du moment, ce qui relance le décompte.
- Cherchez
.maintenanceà la racine de WordPress, dans le dossier qui contientwp-admin, avec le gestionnaire de fichiers de votre hébergement ou un logiciel FTP. Son nom commence par un point : activez l’affichage des fichiers cachés. - Supprimez-le. C’est ce que fait WordPress lui-même à la fin d’une mise à jour ; un fichier resté en place signale une opération qui ne s’est pas terminée.
- Retournez dans l’administration et vérifiez la version de ce qui était en cours de mise à jour. Une mise à jour interrompue se relance.
- Videz les caches éventuels. MDN rappelle qu’une réponse 503 mise en cache peut servir une page d’erreur périmée après la résolution du problème.
Si la page reste affichée après tout cela, elle ne vient pas du mécanisme du cœur décrit ici. Il faut alors trouver ce qui la produit : c’est un travail de diagnostic pour la personne qui gère votre site, pas une manipulation à tenter au hasard.
Quel code HTTP renvoyer pendant une maintenance ?
Un code 503, « service indisponible », accompagné de l’en-tête Retry-After. MDN définit le 503 comme la réponse d’un serveur qui n’est pas prêt à traiter la requête, le plus souvent pour cause de maintenance ou de surcharge. Google demande d’indiquer dans Retry-After « la date ou la durée de la tentative ». Les autres façons de bloquer un site font sortir vos pages de la recherche.
La page de Google Désactiver ou suspendre temporairement un site Web ne laisse aucune place au doute : « Ne bloquez pas le site Web en renvoyant des codes d’état HTTP 403, 404, 410 ni avec une balise robots meta noindex ou un en-tête HTTP x-robots-tag. Dans ce cas, les URL du site Web seront supprimées de la recherche Google. »
Sa documentation sur l’effet des codes d’état HTTP explique la différence. Avec un 5xx, Google ralentit temporairement son exploration et garde vos URL déjà indexées. Avec un 4xx (sauf le 429), il retire de l’index les URL concernées.
| Réponse servie pendant les travaux | Effet décrit par Google | Notre avis |
|---|---|---|
| 503 avec Retry-After | Exploration ralentie, URL déjà indexées conservées pour un temps | La bonne réponse pour une coupure courte |
| 200 sur une page d’accueil d’attente indexable | La page reste trouvable dans la recherche | La voie prévue par Google pour une fermeture plus longue |
| 403, 404 ou 410 | URL supprimées de la recherche | À proscrire |
| Balise noindex ou en-tête x-robots-tag | URL supprimées de la recherche | À proscrire |
Le contrôle tient en une ligne. Google propose de confirmer le 503 avec curl. La première ligne de la réponse doit annoncer le 503 (elle s’écrit HTTP/2 503 sur certains serveurs), et l’en-tête Retry-After doit figurer dans la liste. Ici, 3600 secondes, soit un retour annoncé dans une heure :
curl -I -X GET "https://www.votre-site.fr/"
HTTP/1.1 503 Service Unavailable
(...)
Retry-After: 3600Combien de temps un site peut-il rester en maintenance sans nuire à son référencement ?
Un à deux jours en 503, selon Google, et quelques jours tout au plus si vous fermez tout le site. Au-delà, Google conseille de changer de méthode : une page d’accueil d’attente, indexable, servie avec un code 200. Aucune source ne chiffre la perte de trafic ni le délai de réindexation. Google l’écrit lui-même : « Aucun délai n’est fixé pour la récupération d’un site après une suppression complète. »
Ces repères viennent d’une page pensée pour une boutique en ligne qui suspend ses ventes. Elle ne parle pas de maintenance technique ; ses consignes sur le 503 et le robots.txt sont pourtant celles que nous appliquons à tout chantier de ce type. Sur la fermeture complète, Google ne nuance pas : « il s’agit d’une mesure extrême qui ne devrait être prise que pendant quelques jours tout au plus pour ne pas risquer de nuire à la position de votre site dans la recherche Google. » Sa foire aux questions ajoute : « Même si elle ne dure que quelques semaines, la fermeture complète d’un site peut avoir des conséquences néfastes sur son indexation par Google. »
Deux mécanismes expliquent cette prudence :
- L’index s’effrite. Face à des erreurs 5xx, les URL déjà indexées « sont conservées, mais finissent par être supprimées de l’index », écrit Google, sans donner de durée.
- Vos résultats se figent. Tant que le site renvoie un 503, Google ne peut actualiser ni vos titres, ni vos descriptions, ni vos données structurées.
En pratique, découpez le chantier pour que la coupure tienne en quelques heures, au moment où votre site reçoit le moins de visites. Si le travail doit durer, gardez le site en ligne et préparez la nouvelle version à côté.
Que faire du fichier robots.txt pendant la maintenance ?
Rien : il doit continuer de répondre normalement, en 200, avec ses règles habituelles. Google le dit en une phrase : « Ne renvoyez pas de code d’état de réponse HTTP 503 pour le fichier robots.txt, car cela bloque toute exploration. » N’y ajoutez pas non plus d’interdiction générale le temps des travaux : un robots.txt qui interdit toute exploration risque de faire sortir votre contenu, voire vos URL, de la recherche.
La spécification robots.txt de Google, mise à jour le 11 septembre 2026, détaille ce qui se passe quand le fichier renvoie une erreur 5xx :
- pendant les 12 premières heures, Google cesse d’explorer le site et retente plusieurs fois de récupérer le fichier ;
- ensuite, il se fie pendant 30 jours à la dernière version récupérée, tout en continuant d’essayer ;
- un 503 entraîne de nouvelles tentatives « assez fréquentes ».
L’erreur inverse coûte aussi. Un robots.txt qui répond 404 est traité comme s’il n’existait pas de fichier valide : vos règles d’exclusion cessent de s’appliquer.
Vérifiez donc que votre outil de maintenance laisse passer ce fichier. Pendant la coupure, curl -I "https://www.votre-site.fr/robots.txt" doit répondre 200, alors que la page d’accueil répond 503.
Faut-il fermer tout le site ou seulement certaines fonctions ?
Limitez les fonctions, ne fermez pas tout. C’est l’option recommandée par Google, parce qu’elle « minimise les éventuels effets négatifs sur la présence de votre site dans la recherche Google ». Son exemple : désactiver le panier, une mesure qui « ne modifie en rien la visibilité de votre site dans la recherche ». Vos pages restent en ligne, lisibles et indexées ; seule la fonction en travaux disparaît.
Notre recommandation, selon votre situation :
- Site vitrine en refonte : ne fermez rien. Le nouveau site se construit à une autre adresse, l’ancien reste en ligne jusqu’à la bascule.
- Boutique, réservation ou devis en ligne : coupez la fonction concernée et affichez une bannière sur toutes les pages. Google conseille l’attribut HTML
data-nosnippetpour que son texte n’apparaisse pas dans les extraits de recherche. - Intervention serveur courte (migration, base de données, correctif de sécurité urgent) : là seulement, tout le site passe en 503 avec Retry-After, pour quelques heures.
| Critère | Limiter les fonctions | Fermer tout le site en 503 |
|---|---|---|
| Position de Google | Option recommandée | Approche non recommandée |
| Vos pages dans la recherche | Restent visibles | Titres, descriptions et données structurées figés |
| Ce que voit votre client | Vos pages, plus une bannière qui explique | Une seule page d’attente |
| Durée envisagée par Google | Reprise prévue dans les semaines ou les mois | Un à deux jours en 503, quelques jours tout au plus |
Pensez aussi aux données structurées (un événement annulé, un produit indisponible) et, si vous modifiez des pages, demandez une nouvelle exploration : la Search Console pour quelques pages, un sitemap pour beaucoup.
Que doit contenir une bonne page de maintenance ?
Trois informations, en quelques lignes : ce qui se passe, quand le site revient, comment vous joindre. Google cite des liens vers des informations complémentaires, la date de retour prévue et les coordonnées du service client. La page de MDN consacrée au code 503 demande une page conviviale qui explique le problème, et met en garde contre la mise en cache de cette réponse.
Côté technique, Google donne trois consignes pour alléger la page :
- l’en-tête Retry-After, avec une date ou une durée ;
- du HTML statique ;
- le moins possible de ressources externes : CSS intégré à la page, images codées en base 64.
Sur le cache, MDN est net : un code 503 indique un problème temporaire, et « ces réponses ne doivent généralement pas être mises en cache, car les clients pourraient recevoir des pages d’erreur obsolètes après la résolution du problème ».
Un exemple de texte, à adapter :
Le site revient aujourd’hui à 11 h. Nous installons une nouvelle version ce matin. Vos rendez-vous sont maintenus. Pour une question urgente, écrivez à [votre adresse] : nous répondons dans la matinée.
Sous WordPress, si ce texte vit dans un fichier maintenance.php, rappelez-vous qu’il doit envoyer lui-même le code 503 et l’en-tête Retry-After.
Que se passe-t-il quand le site revient en ligne ?
Google reprend son rythme, progressivement. Sa documentation sur les codes d’état indique que tout contenu reçu avec un code 5xx est ignoré et que, dès que le serveur répond de nouveau en 2xx, Google « augmente progressivement la vitesse d’exploration du site ». Pendant une coupure en 503, Google conserve les URL déjà indexées, sans dire pendant combien de temps : elles « finissent par être supprimées de l’index » si l’erreur dure. Après une suppression complète, en revanche, aucun délai de retour n’est garanti.
Google ajoute qu’il « n’existe aucun mécanisme permettant d’accélérer cette opération ». Raison de plus pour soigner la réouverture :
- Retirez la page de maintenance ;
curl -Isur l’accueil doit répondre 200. - Videz les caches, pour qu’aucun visiteur ne reçoive l’ancienne page d’erreur.
- Ouvrez vos pages clés et le robots.txt.
- Si des pages ont changé, demandez une nouvelle exploration : la Search Console pour quelques pages, un sitemap pour beaucoup.
Quand confier la maintenance à un prestataire ? Dès que votre site fait vivre votre activité et que personne, chez vous, ne sait lire une réponse curl ni retrouver un fichier caché à la racine. Un prestataire qui suit votre site applique les mises à jour, garde des sauvegardes et vous évite de découvrir le message par surprise. C’est ce que couvre notre maintenance de site web, comprise dans chaque pack la première année. Le pack Essentiel, cinq pages dessinées sur mesure, coûte 990 € en une fois pour la première année, puis 180 € par an couvrent l’hébergement, les mises à jour de sécurité, les sauvegardes et un humain qui répond : voir notre offre. Notre méthode décrit chaque étape d’un projet, livré en sept jours. Votre entreprise est à Tours ? Voyez notre page création de site internet à Tours.
