Faire une page de maintenance propre

Une refonte, une migration d'hébergeur ou une mise à jour technique imposent parfois de couper l'accès au site pendant quelques minutes, voire quelques heures. Le réflexe courant est d'afficher une page blanche ou un message improvisé : le visiteur croit à une panne, et le moteur de recherche reçoit un signal que vous n'avez pas choisi. Une page de maintenance propre répond à deux lecteurs à la fois : la personne qui arrive sur votre adresse et le robot qui lit le code de réponse du serveur.

Cet article s'appuie sur le code source de WordPress 7.1, sur la page officielle de Google consacrée aux codes d'état HTTP (mise à jour le 05/03/2026) et sur un relevé de recherche DataForSEO pour la France. Pour activer ou quitter le mode maintenance proprement dit, un guide existe déjà : mode maintenance WordPress : activer, quitter. Ici, on traite ce que la page doit contenir, le code qu'elle doit renvoyer, et les pièges d'une coupure qui dure plus longtemps que prévu.

Ce que WordPress fait réellement pendant une mise à jour

Lors d'une mise à jour du noyau, d'une extension ou d'un thème, WordPress crée à la racine du site un fichier nommé .maintenance. Ce fichier contient une variable $upgrading, qui mémorise l'heure de sa création. Tant que ce fichier existe et qu'il a moins de 10 minutes, le site est en mode maintenance. Passé ce délai, le code source considère la maintenance comme terminée, même si le fichier est encore là. C'est une sécurité : une mise à jour interrompue ne bloque pas le site indéfiniment.

Dans sa version par défaut, WordPress envoie un en-tête Retry-After: 600 (10 minutes, exprimées en secondes) et affiche un message court qui invite à revenir dans une minute, avec le code de réponse 503. Le visiteur voit un écran sobre et le moteur de recherche reçoit le bon signal : indisponibilité temporaire.

Le piège du fichier maintenance.php

WordPress permet de remplacer ce message par un gabarit maison : il suffit de déposer un fichier maintenance.php dans le dossier wp-content. Le code source montre cependant un point que de nombreux tutoriels omettent : dans ce cas, WordPress charge le fichier puis arrête l'exécution, sans ajouter lui-même le code 503 ni l'en-tête Retry-After. Ils appartiennent au chemin par défaut uniquement. Votre gabarit doit donc les envoyer lui-même, par exemple avec http_response_code(503); et header('Retry-After: 3600'); placés avant tout affichage. Sans cela, la jolie page de marque répond en 200 : elle ressemble à une maintenance pour l'humain, mais pas pour le robot.

Ce que Google fait d'un code 5xx

La page officielle de Google sur l'effet des codes d'état HTTP (mise à jour le 05/03/2026) décrit le comportement en trois points. Les erreurs serveur de type 5xx, ainsi que le code 429, invitent les robots à ralentir temporairement l'exploration. Pour la recherche Google, les URL déjà indexées sont conservées, mais finissent par être retirées de l'index si l'erreur dure. Tout contenu reçu depuis une URL qui répond en 5xx est ignoré. Dès que le serveur répond de nouveau en 2xx, Google augmente progressivement la vitesse d'exploration du site.

La page ne fixe aucun nombre de jours avant le retrait de l'index : il serait faux d'en citer un. Le message pratique est plutôt celui-ci : une coupure courte et annoncée en 503 est la situation prévue par le protocole, une coupure qui s'éternise ne l'est pas. À l'inverse, une page de maintenance qui répond en 200 est lue comme une vraie page : son texte peut remplacer celui des pages réelles lors du passage suivant du robot.

Un calcul illustratif : une coupure plus longue que la fenêtre de 10 minutes

Prenons un site fictif dont l'équipe planifie une migration. Les durées ci-dessous sont des hypothèses de travail, pas des mesures. Elles servent à comparer la durée de l'intervention à la fenêtre de 10 minutes que WordPress accorde au fichier .maintenance.

Le résultat se lit simplement : l'intervention dure six fois la fenêtre prévue par le fichier automatique. Pour une coupure de cette taille, on ne peut pas compter sur le mécanisme de mise à jour : il faut une maintenance volontaire, avec un gabarit ou une extension qui envoie bien le code 503, et un message qui annonce une durée prudente. Mieux encore, on découpe l'opération : la sauvegarde et les tests peuvent se faire sans couper le site, seule la bascule justifie la page de maintenance.

Lecture : l'expression exacte « page de maintenance wordpress » ne dépasse pas 10 recherches par mois, alors que « erreur 503 » en atteint 4 400. Le sujet se joue donc moins sur le mot « page » que sur la compréhension du code 503, côté visiteur comme côté propriétaire de site. C'est la raison pour laquelle cet article place le code de réponse avant le design de la page.

Le plan d'action avant la coupure

• Décider si la coupure est vraiment nécessaire : une sauvegarde, un test sur une copie ou une préparation de contenu se font site en ligne.
• Choisir la méthode : message par défaut pour quelques minutes, gabarit maintenance.php ou extension pour une coupure volontaire plus longue.
• Vérifier le code reçu : ouvrir la page en navigation privée et contrôler que la réponse est un 503, pas un 200.
• Rédiger un message court, avec un moyen de contact et une formulation prudente sur la durée.
• Prévoir la sortie : noter l'heure de début, l'heure de fin visée et la personne qui retire la maintenance.
• Après la bascule : vérifier l'accueil, une page interne, le formulaire et l'administration, puis relire la Search Console les jours suivants.

Ne pas la laisser en place trop longtemps

Une page de maintenance est faite pour une coupure courte. Plus elle dure, plus la situation s'éloigne de celle que le protocole prévoit, et plus le risque de retrait des URL de l'index augmente, selon la documentation de Google citée plus haut. Si les travaux dépassent quelques jours, publier une version partielle du site vaut mieux que prolonger l'attente.