Une maintenance WordPress propre tient en quatre exigences : une sauvegarde que vous savez restaurer, un accès administrateur qui reste ouvert, une réponse HTTP 503 pour les visiteurs anonymes, et une vérification avant réouverture. Masquer le site ne suffit pas — une page de maintenance mal servie coûte parfois plus cher que l’intervention elle-même.

1. Une sauvegarde restaurable, pas seulement récente

Une sauvegarde n’a de valeur que si vous savez où elle est et comment la remettre en place. Avant l’intervention, sachez répondre à quatre questions : que contient-elle (fichiers, base de données, ou les deux), de quand date-t-elle, où est-elle stockée, et par quelle procédure exacte se restaure-t-elle.

Règle simple

Ne testez jamais une procédure de maintenance pour la première fois sur le seul exemplaire d’un site important. Faites-la d’abord sur une copie.

2. Décider ce qui doit rester ouvert

C’est l’étape que les pages « bientôt disponible » ratent le plus souvent. Une page de maintenance concerne les visiteurs anonymes. Tout le reste doit continuer de fonctionner, sinon vous vous coupez les mains pendant l’intervention.

Doivent rester accessibles :

  • la page de connexion wp-login.php et l’administration ;
  • les administrateurs déjà connectés — techniquement, les comptes portant la capacité manage_options ;
  • admin-ajax.php, sans quoi l’administration elle-même se met à échouer par endroits ;
  • l’API REST, WP-CLI et les tâches planifiées, si vous comptez travailler avec ;
  • robots.txt et favicon.ico, pour la raison expliquée plus bas.

Le test qui ne trompe pas se fait dans deux fenêtres. Gardez votre session d’administration ouverte dans l’une, ouvrez une navigation privée dans l’autre. Activez la maintenance. La fenêtre privée doit voir la page temporaire ; la vôtre doit continuer à voir le vrai site.

3. La bonne réponse HTTP

Une page joliment dessinée peut tout de même envoyer un mauvais signal. Ce que lisent les robots et les outils de supervision, ce n’est pas le graphisme : c’est le code de réponse. Pour une indisponibilité temporaire, ce code est 503, accompagné d’un en-tête Retry-After qui suggère un délai raisonnable avant une nouvelle tentative.

Servir cette page avec un statut 200 revient à annoncer que votre contenu habituel a été remplacé par ce message — de façon permanente. Le détail des signaux est traité dans le guide mode maintenance et référencement.

4. Un message qui répond à trois questions

Le visiteur qui tombe sur votre page veut savoir trois choses, et rien d’autre : est-ce temporaire, quand revenir, et existe-t-il un autre moyen de vous joindre.

Deux pièges. Le premier : le compte à rebours. Si vous n’êtes pas certain de l’heure de fin, ne l’affichez pas — une échéance dépassée fait plus de dégâts qu’une formule sobre. Le second : le formulaire ou l’adresse de contact que personne ne surveille pendant l’intervention. Ne proposez un canal que si quelqu’un le lit.

5. Deux chemins qui ne doivent jamais recevoir la page

robots.txt d’abord. Une réponse 5xx prolongée sur ce seul fichier fait cesser l’exploration du site entier — l’effet exact inverse de ce qu’une maintenance temporaire doit signaler. Ce fichier doit continuer de répondre normalement pendant toute la fenêtre.

favicon.ico ensuite, pour une raison plus prosaïque : une requête d’icône qui reçoit un document HTML complet, c’est du transfert inutile à chaque page vue.

Piège vérifié

Sur un site laissé en permaliens simples, les fonctions WordPress is_robots() et is_favicon() restent fausses : elles dépendent de règles de réécriture qui n’existent qu’une fois une structure de permaliens définie. Une exclusion fondée sur elles seules laisse passer le 503. Le chemin de la requête doit être contrôlé aussi.

6. Les tâches planifiées pendant la fenêtre

WP-Cron se déclenche à l’occasion des visites. Pendant une maintenance, les visites cessent — ou sont interceptées. Les tâches ne disparaissent pas, elles s’accumulent et repartent toutes en même temps à la réouverture. Sur une fenêtre courte, c’est sans conséquence. Sur une intervention longue, prévoyez que sauvegardes automatiques, envois programmés et synchronisations se réveilleront d’un coup.

7. Vérifier avant de rouvrir

Le contrôle visuel ne suffit pas : le code HTTP se lit, il ne se voit pas. Deux commandes donnent l’essentiel.

# En maintenance, vu par un visiteur anonyme
curl -I https://votre-site.fr/

# robots.txt doit rester normal
curl -I https://votre-site.fr/robots.txt

La première doit renvoyer 503 avec un Retry-After. La seconde ne doit pas renvoyer 503. Contrôlez ensuite, dans l’ordre : la page d’accueil, la connexion, un formulaire essentiel, et les pages que vous venez de modifier.

8. Rouvrir, puis contrôler encore

Désactivez la maintenance, purgez les caches concernés — extension, hébergeur, puis CDN — et refaites le test en navigation privée. La commande curl -I doit maintenant renvoyer HTTP/2 200.

Un site qui affiche son contenu tout en répondant encore 503 est un cas réel et fréquent : c’est presque toujours un cache qui a enregistré la réponse d’erreur. Le guide de dépannage du message de maintenance détaille les causes par ordre de fréquence.

Récapitulatif

ÉtapeContrôle qui la valide
SauvegardeVous savez la restaurer, pas seulement la trouver
Accès préservéDeux fenêtres : privée en 503, session admin sur le vrai site
Signal temporairecurl -I renvoie 503 et Retry-After
Chemins exclusrobots.txt ne renvoie pas 5xx
RéouvertureRetour en 200 après purge des caches

Ce que fait Mes503 Maintenance Page

La bêta 0.1.5 automatise la partie temporaire : page responsive, statut 503, Retry-After configurable, en-tête X-Robots-Tag: noindex, nofollow, noarchive, en-têtes anti-cache, aperçu réservé aux administrateurs, et exclusion de robots.txt, du favicon, de l’administration, d’AJAX, du cron, de l’API REST, de XML-RPC et de WP-CLI.

Elle ne remplace ni la sauvegarde, ni la vérification fonctionnelle du site. Ces deux-là restent votre travail.