Pour activer un mode maintenance WordPress sans plugin, la méthode la plus simple consiste à créer un fichier .maintenance à la racine du site. WordPress le détecte automatiquement et affiche une page de maintenance aux visiteurs. Pour une maintenance plus propre, vous pouvez aussi utiliser WP-CLI avec wp maintenance-mode activate, ajouter une règle .htaccess temporaire, ou afficher une page HTML statique pendant une intervention serveur. Ce guide détaille les méthodes fiables, les pièges à éviter et les commandes exactes pour intervenir sans casser l’accès administrateur.
Pourquoi éviter un plugin de maintenance
Un plugin de maintenance peut être pratique pour une landing page visuelle, mais il ajoute une dépendance de plus à un moment où le site doit rester prévisible. Pendant une mise à jour critique, une migration, un changement de thème ou une correction d’urgence, l’objectif n’est pas d’avoir un écran animé. L’objectif est de réduire la surface de risque : moins de PHP chargé, moins de hooks WordPress, moins d’options à déboguer.
Sans plugin, vous gardez le contrôle sur trois choses importantes : le code affiché aux visiteurs, les adresses IP autorisées, et le moment exact où le site revient en ligne. C’est aussi utile quand le tableau de bord WordPress est inaccessible. Si une extension provoque une erreur critique, vous ne pouvez pas compter sur un autre plugin pour protéger l’intervention. Dans ce cas, FTP, SSH ou cPanel restent les accès de secours.
Le mode maintenance manuel est particulièrement adapté aux sites WordPress hébergés sur mutualisé, aux blogs techniques, aux petits WooCommerce et aux environnements de staging. Pour les sites à fort trafic, il faut aller plus loin : préserver les codes HTTP corrects, ne pas bloquer Google inutilement, et éviter de couper les webhooks de paiement ou les callbacks API.
Méthode 1 : le fichier .maintenance natif de WordPress
WordPress utilise déjà un fichier .maintenance pendant les mises à jour du core, des plugins et des thèmes. Quand ce fichier existe à la racine de l’installation, WordPress affiche un message temporaire aux visiteurs. C’est le mécanisme natif le plus simple.
<?php
// Fichier : .maintenance
// A placer à la racine WordPress, au même niveau que wp-config.php
$upgrading = time();
Placez ce fichier à la racine du site via FTP, SSH ou le gestionnaire de fichiers cPanel. Dès qu’il est présent, WordPress passe en maintenance. Pour désactiver le mode maintenance, supprimez simplement le fichier.
# Activer la maintenance manuellement
cd /home/votre-user/public_html
printf '<?php $upgrading = time();' > .maintenance
# Vérifier que le fichier existe
ls -la .maintenance
# Désactiver la maintenance
rm .maintenance
Cette méthode est rapide, mais elle a une limite : le message affiché par WordPress est minimal. Il convient pour une intervention courte de quelques minutes. Pour une maintenance plus longue ou plus propre côté SEO, préférez une page HTML dédiée avec un statut HTTP contrôlé.
Méthode 2 : WP-CLI pour activer et désactiver proprement
Si vous avez un accès SSH, WP-CLI est la méthode la plus propre. La commande officielle crée et supprime le fichier .maintenance sans manipulation manuelle. Elle limite les erreurs de chemin et s’intègre facilement dans un script de déploiement.
# Aller dans le dossier WordPress
cd /home/votre-user/public_html
# Activer le mode maintenance
wp maintenance-mode activate
# Vérifier l'état
wp maintenance-mode status
# Faire l'intervention
wp plugin update --all
wp theme update --all
wp cache flush
# Désactiver le mode maintenance
wp maintenance-mode deactivate
Pour les mises à jour, combinez toujours maintenance, sauvegarde et vérification. Un workflow minimal ressemble à ceci :
#!/usr/bin/env bash
set -euo pipefail
cd /home/votre-user/public_html
echo "Backup base de données"
wp db export "../backup-$(date +%Y%m%d-%H%M%S).sql"
echo "Activation maintenance"
wp maintenance-mode activate
echo "Mises à jour"
wp core update
wp plugin update --all
wp theme update --all
wp core update-db
echo "Purge caches"
wp cache flush
wp rewrite flush --hard
echo "Désactivation maintenance"
wp maintenance-mode deactivate
echo "Vérification"
curl -I https://exemple.com/
Le point critique est le set -euo pipefail : si une commande échoue, le script s’arrête. En production, ajoutez un trap pour désactiver automatiquement la maintenance en cas d’erreur, sinon le site peut rester bloqué.
trap 'wp maintenance-mode deactivate || true' EXIT
Pour aller plus loin sur l’administration en ligne de commande, le guide WP-CLI : 20 commandes essentielles pour administrer WordPress couvre les commandes utiles en production.
Méthode 3 : page maintenance HTML avec .htaccess
Le fichier .maintenance charge encore WordPress. Si votre intervention concerne justement PHP, les plugins ou la base de données, il est plus sûr de court-circuiter WordPress avec Apache. Une règle .htaccess peut rediriger les visiteurs vers une page HTML statique pendant que vous intervenez.
Créez d’abord un fichier maintenance.html à la racine du site :
<!doctype html>
<html lang="fr">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="robots" content="noindex, follow">
<title>Maintenance en cours</title>
<style>
body{font-family:system-ui,sans-serif;margin:0;display:grid;place-items:center;min-height:100vh;background:#f6f1e8;color:#19170f}
main{max-width:640px;padding:32px}
h1{font-size:clamp(2rem,5vw,3.5rem);line-height:1}
p{font-size:1.1rem;line-height:1.6}
</style>
</head>
<body>
<main>
<h1>Maintenance en cours</h1>
<p>Le site revient dans quelques minutes. Merci pour votre patience.</p>
</main>
</body>
</html>
Ajoutez ensuite ces règles au début du .htaccess :
# Mode maintenance temporaire
RewriteEngine On
# Autoriser votre IP à voir le site réel
RewriteCond %{REMOTE_ADDR} !^203.0.113.42$
# Ne pas rediriger la page de maintenance elle-même
RewriteCond %{REQUEST_URI} !^/maintenance.html$
# Ne pas bloquer les fichiers statiques utiles à la page
RewriteCond %{REQUEST_URI} !.(css|js|png|jpg|jpeg|gif|svg|ico|webp)$ [NC]
# Envoyer tout le reste vers la page statique
RewriteRule ^.*$ /maintenance.html [R=302,L]
Remplacez 203.0.113.42 par votre IP publique. Vous pouvez la récupérer avec curl ifconfig.me. Le statut 302 est volontaire : il indique une redirection temporaire. N’utilisez pas un 301, car les navigateurs et les moteurs peuvent le garder en cache.
Si vous devez modifier souvent votre fichier Apache, utilisez une sauvegarde avant chaque intervention. Le guide générateur htaccess WordPress explique comment structurer les règles sans casser les permaliens.
Méthode 4 : retourner un vrai statut 503
Pour une maintenance planifiée, le meilleur signal HTTP est 503 Service Unavailable avec un header Retry-After. Cela indique aux robots que l’indisponibilité est temporaire et qu’ils doivent revenir plus tard. C’est plus propre qu’une redirection 200 vers une page vide.
Avec Apache, vous pouvez utiliser une page PHP légère :
<?php
// maintenance.php
http_response_code(503);
header('Retry-After: 1800'); // 30 minutes
header('Content-Type: text/html; charset=utf-8');
?><!doctype html>
<html lang="fr">
<head>
<meta charset="utf-8">
<meta name="robots" content="noindex, follow">
<title>Maintenance temporaire</title>
</head>
<body>
<h1>Maintenance temporaire</h1>
<p>Retour prévu dans environ 30 minutes.</p>
</body>
</html>
Puis dans .htaccess :
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203.0.113.42$
RewriteCond %{REQUEST_URI} !^/maintenance.php$
RewriteRule ^.*$ /maintenance.php [L]
Ce montage garde le bon statut HTTP. Il est préférable pour les maintenances de plus de 10 ou 15 minutes, surtout sur un site déjà indexé. Pour une intervention de deux minutes, le fichier .maintenance natif suffit.
Ne pas bloquer l’administration par erreur
Le piège classique consiste à bloquer tout le site, y compris /wp-admin/, /wp-login.php ou les appels AJAX nécessaires à la vérification. Si vous avez encore besoin du tableau de bord pendant la maintenance, prévoyez une exception par IP ou par chemin.
RewriteEngine On
# Laisser passer votre IP
RewriteCond %{REMOTE_ADDR} ^203.0.113.42$ [OR]
# Laisser passer wp-admin et wp-login
RewriteCond %{REQUEST_URI} ^/wp-admin/ [OR]
RewriteCond %{REQUEST_URI} ^/wp-login.php$
RewriteRule ^ - [L]
# Maintenance pour les autres visiteurs
RewriteCond %{REQUEST_URI} !^/maintenance.html$
RewriteRule ^.*$ /maintenance.html [R=302,L]
Sur certains sites WooCommerce, attention aux endpoints de paiement, webhooks Stripe, PayPal ou transporteurs. Une maintenance globale peut interrompre des callbacks attendus. Dans ce cas, préférez une maintenance courte, ou laissez passer les chemins critiques comme /wc-api/, /?wc-api= ou les routes REST utilisées par vos prestataires.
Nettoyer après l’intervention
Un mode maintenance doit être temporaire. Après l’intervention, vérifiez systématiquement que rien ne reste actif :
# Vérifier l'absence du fichier natif
test ! -f .maintenance && echo "OK: pas de .maintenance"
# Tester la home
curl -I https://exemple.com/
# Tester une URL d'article
curl -I https://exemple.com/mon-article/
# Chercher les règles maintenance restantes
grep -n "maintenance" .htaccess
# Purger le cache
wp cache flush
wp rewrite flush --hard
Si le site reste bloqué en maintenance après une mise à jour ratée, le coupable est presque toujours le fichier .maintenance oublié à la racine. Supprimez-le via FTP ou SSH. Si l’erreur persiste, il s’agit probablement d’une erreur PHP déclenchée par la mise à jour. Dans ce cas, consultez le guide erreur critique WordPress : que faire pour reprendre la main.
Checklist maintenance WordPress sans plugin
Avant l’intervention :
- Prévenir les personnes concernées si le site reçoit du trafic ou des commandes.
- Faire une sauvegarde base de données et fichiers.
- Noter votre IP publique si vous utilisez une exception.
- Préparer la commande de retour arrière.
- Tester la page de maintenance sur un navigateur privé.
Pendant l’intervention :
- Garder une session SSH ou FTP ouverte.
- Limiter la fenêtre de maintenance.
- Ne pas empiler plusieurs changements risqués en même temps.
- Consigner les commandes exécutées.
- Surveiller les erreurs PHP et les logs serveur.
Après l’intervention :
- Supprimer
.maintenanceou retirer les règles.htaccess. - Purger le cache serveur et navigateur.
- Tester la home, un article, le login et une page mobile.
- Vérifier le statut HTTP :
200pour les pages normales. - Documenter ce qui a été modifié.
FAQ : mode maintenance WordPress sans plugin
Combien de temps peut durer une maintenance WordPress ?
Pour une mise à jour simple, visez moins de 10 minutes. Pour une migration ou une réparation, utilisez un statut 503 avec Retry-After. Au-delà de quelques heures, il faut une vraie page de statut ou une communication claire, surtout pour un site e-commerce.
Le fichier .maintenance bloque-t-il Google ?
Il signale une indisponibilité temporaire. Pour une courte intervention, ce n’est pas un problème. Pour une maintenance longue, préférez une réponse 503 contrôlée avec Retry-After, afin d’éviter que Google interprète mal la page temporaire.
Pourquoi mon site reste bloqué en maintenance ?
La cause la plus fréquente est un fichier .maintenance oublié après une mise à jour interrompue. Connectez-vous en FTP ou SSH à la racine WordPress et supprimez ce fichier. Si le site affiche ensuite une erreur critique, désactivez le plugin ou le thème mis à jour.
Faut-il désactiver le cache pendant la maintenance ?
Oui, ou au minimum le purger après l’intervention. Un cache serveur peut continuer à servir l’ancienne page de maintenance alors que WordPress est revenu en ligne. Sur LiteSpeed, Cloudflare ou Varnish, purgez explicitement le cache après avoir retiré le mode maintenance.
Peut-on faire une maintenance sans couper wp-admin ?
Oui. Ajoutez une exception par IP ou laissez passer /wp-admin/ et /wp-login.php dans les règles .htaccess. Pour une intervention sensible, l’exception par IP reste plus sûre qu’une ouverture complète de l’administration.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.