Mettre son site WordPress en pause : l'interrupteur .htaccess que je laisse à mes clients
Aucun hébergeur mutualisé ne fournit de bouton pause, et un plugin de maintenance ne sert à rien quand c'est WordPress qui est compromis. Trois lignes, un fichier à renommer, et le site bascule proprement en 503.
Un client sort d’un piratage. Son site est nettoyé, remis en ligne, il repart en congés le lendemain. Et il me pose la seule question qui compte : « si je vois quelque chose de bizarre pendant que vous n’êtes pas là, je fais quoi ? »
Réponse : rien. Il n’avait aucun moyen de couper son propre site. Pas de bouton dans son espace d’hébergement, pas d’accès en ligne de commande, et surtout pas la certitude que son WordPress soit encore digne de confiance. Un site compromis, on l’éteint d’abord, on le répare ensuite. Encore faut-il avoir un interrupteur.
Alors je lui en ai posé un. Trois lignes dans un fichier .htaccess, un fichier témoin à renommer depuis son navigateur, et le site bascule proprement en « je reviens plus tard ». Voici le code, la manip, et les trois pièges qui m’ont coûté une nuit de recette.
Prestataire référencé sur cybermalveillance.gouv.fr, le dispositif national d'assistance aux victimes.
Pourquoi les plugins de maintenance ne servent à rien ici
Tapez « mode maintenance WordPress » et vous trouverez quinze plugins. Ils font tous la même chose : ils s’installent dans WordPress, et quand un visiteur arrive, WordPress démarre, charge sa base, charge ses plugins, puis affiche une jolie page « nous revenons bientôt ».
Relisez la phrase. WordPress démarre. C’est exactement ce qu’on ne veut pas quand WordPress est le suspect.
Un site compromis, ce sont des fichiers PHP déposés dans les répertoires d’upload, parfois une porte dérobée dans un plugin légitime, parfois une tâche planifiée qui réinjecte le code toutes les heures. Le plugin de maintenance ne bloque rien de tout ça : il repeint la façade pendant que la cave brûle. Pire, sur un site en erreur fatale (le cas classique quand l’antimalware de l’hébergeur a vidé les fichiers infectés), le plugin ne se charge même pas. Il n’y a plus de WordPress pour l’exécuter.
L’interrupteur qu’il faut agit avant PHP. Au niveau du serveur web, sur le chemin de la requête. Apache reçoit l’appel, vérifie une condition, répond « service indisponible » et referme la porte. WordPress n’est jamais réveillé.
C’est la même logique que celle de ma clé USB d’intervention : on gèle la scène avant de toucher quoi que ce soit. Un site coupé en 503, c’est un site dont les fichiers, les journaux et les traces d’intrusion restent intacts pour l’analyse. Un site « nettoyé » à la hâte, c’est une plainte sans preuves.
Le principe : un fichier qu'on renomme
L’interrupteur tient en deux états, et c’est tout le sujet :
- Le fichier s’appelle
PAUSE-OFF.txt: le site est en ligne. - Le fichier s’appelle
PAUSE.txt: le site est en pause.
Le client ne touche jamais au .htaccess, ne tape aucune commande, n’installe rien. Il renomme un fichier depuis le gestionnaire de fichiers de son hébergeur, dans un sens ou dans l’autre. Effet immédiat, réversible, sans dommage.
Le code
Voici le bloc, anonymisé, tel qu’il tourne en production. Il se place en haut du .htaccess, avant le bloc # BEGIN WordPress.
# =========================================================
# INTERRUPTEUR DE MAINTENANCE
# Site EN LIGNE : le fichier temoin s'appelle PAUSE-OFF.txt
# Mettre EN PAUSE: le renommer en PAUSE.txt
# Remettre en ligne : le renommer en PAUSE-OFF.txt
# =========================================================
<IfModule mod_rewrite.c>
RewriteEngine On
# GARDE 1 : n'agir que sur CE domaine.
# Sur un mutualise, plusieurs sites peuvent vivre sous le meme
# docroot : sans cette ligne, la regle les coupe tous.
RewriteCond %{HTTP_HOST} ^(www\.)?votre-site\.fr$ [NC]
# GARDE 2 : chemin ABSOLU du fichier temoin.
# Les deux casses sont tolerees : le champ de renommage arrive vide
# chez certains hebergeurs, le client tape le nom en entier.
RewriteCond /kunden/homepages/NN/dXXXXXXXXX/htdocs/PAUSE.txt -f [OR]
RewriteCond /kunden/homepages/NN/dXXXXXXXXX/htdocs/pause.txt -f
# On laisse passer la page de maintenance (sinon : boucle)
# et robots.txt (les robots doivent pouvoir le lire).
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteRule ^ - [E=JW_MAINT:1,R=503,L]
</IfModule>
ErrorDocument 503 /maintenance.html
<IfModule mod_headers.c>
# Les DEUX lignes sont necessaires : ErrorDocument declenche une
# sous-requete interne, la variable d'environnement y est prefixee.
Header always set Retry-After "3600" env=JW_MAINT
Header always set Retry-After "3600" env=REDIRECT_JW_MAINT
</IfModule>
# Le fichier temoin n'a rien a faire sur le Web
<FilesMatch "^(PAUSE\.txt|pause\.txt|PAUSE-OFF\.txt)$">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order allow,deny
Deny from all
</IfModule>
</FilesMatch>Il vous faut aussi une page maintenance.html à la racine. Autonome, sans CSS externe, sans police Google, sans image distante : elle doit s’afficher même si le reste du site est mort. Et un <meta name="robots" content="noindex, follow"> dedans, par précaution.
Le code complet (interrupteur, durcissement anti-reshell, en-têtes de sécurité, page de maintenance, fichier témoin) est sur GitHub, en licence MIT. Prenez, forkez, adaptez.
Les trois pièges qui m'ont coûté une nuit
Les recettes qu’on trouve en ligne, y compris celle du wiki Apache, sont écrites pour un serveur qu’on administre. Sur un mutualisé, elles échouent. Silencieusement, ce qui est pire.
1. %{DOCUMENT_ROOT} ment
Toutes les recettes publiques écrivent le test comme ça :
RewriteCond %{DOCUMENT_ROOT}/maintenance.enable -fChez IONOS, cette ligne ne marchera jamais, et vous ne saurez pas pourquoi. J’y ai laissé une soirée, vous n’êtes pas obligés. Mesuré le 30 juillet 2026 sur trois hôtes du même espace : %{DOCUMENT_ROOT} vaut /var/www/html pour tous les vhosts, quelle que soit l’arborescence réelle. Le test -f échoue donc systématiquement, l’interrupteur ne se déclenche jamais, et le fichier ressemble pourtant à toutes les documentations du monde.
Le détail qui rend le piège vicieux : %{DOCUMENT_ROOT} -d répond vrai. Si vous testez avec -d pour déboguer, vous concluez que la variable est correcte. Elle ne l’est pas.
Seul %{REQUEST_FILENAME} est correctement résolu par vhost. Pour un test de présence de fichier, il ne reste que le chemin absolu en dur. Peu élégant, parfaitement fiable.
2. La cascade sur les sites voisins
Sur un hébergement mutualisé, le .htaccess de la racine s’applique à tout ce qui vit dessous. Si votre espace héberge plusieurs domaines dans des sous-dossiers (ce que fait IONOS avec ses installations en un clic), une règle écrite sans garde d’hôte coupe l’ensemble.
C’est arrivé, chez moi, la veille de la mise en production : trois sites éteints d’un coup au lieu d’un. D’où la première condition du bloc :
RewriteCond %{HTTP_HOST} ^(www\.)?votre-site\.fr$ [NC]Et d’où le fait que chaque site a son propre chemin de fichier témoin. Deux gardes, deux raisons différentes, aucune des deux n’est décorative.
3. La redirection canonique mange le 503
Celui-là est joli. Votre .htaccess contient probablement une redirection canonique vers https://www. :
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^votre-site\.fr$ [NC]
RewriteRule ^ https://www.votre-site.fr%{REQUEST_URI} [R=301,L]En pause, ErrorDocument 503 /maintenance.html déclenche une sous-requête interne vers /maintenance.html. Cette sous-requête repasse dans le jeu de règles, la canonique l’attrape, et renvoie un 301. Résultat : sur les hôtes non canoniques, le visiteur reçoit une redirection au lieu du 503. Le code HTTP correct est perdu, et avec lui tout le bénéfice SEO de l’opération.
Le correctif tient en une ligne, à placer dans le bloc canonique avant la paire [OR] (sinon vous cassez son groupement) :
RewriteCond %{REQUEST_URI} !^/maintenance[.]html$http:// et https://, en www et non-www. Les quatre combinaisons doivent rendre 503. Trois sur quatre, c'est un bug qui ne se voit pas depuis votre navigateur.La manip, côté client
Une fois le code posé, le client n’a plus qu’un geste. Voici les trois écrans, chez IONOS, dont le gestionnaire de fichiers s’appelle WebTransfert.
Il se connecte à son espace d’hébergement et ouvre le gestionnaire de fichiers. Le fichier PAUSE-OFF.txt est à la racine, juste sous les lignes qui commencent par .htaccess :
AGRANDIR
Au bout de la ligne, le menu à trois points, puis Renommer :
AGRANDIR
Et oui, il y a bien un « Editar » en espagnol au milieu d’un menu en français. Chez IONOS aussi, il y a des vendredis après-midi.
Le champ « Nouveau nom » arrive vide : il faut taper le nom en entier, extension comprise. C’est là que ça se joue, et c’est pour ça que la règle tolère les minuscules :
AGRANDIR
Enregistrer. Le site est en pause, immédiatement. Pour le rallumer : même chemin, dans l’autre sens.
Trente secondes, sans nous, depuis n’importe quel navigateur.
Et chez votre hébergeur ?
Tout ce mécanisme repose sur une condition : que le client puisse renommer un fichier sans installer de logiciel. Autrement dit, que son hébergeur fournisse un gestionnaire de fichiers dans le navigateur.
Et là, il y a une mauvaise nouvelle.
| Hébergeur | Gestionnaire de fichiers web | Nom de l'outil |
|---|---|---|
| IONOS | ✅ Oui | WebTransfert |
| o2switch | ✅ Oui | Gestionnaire de fichiers (cPanel) |
| Infomaniak | ✅ Oui | Web FTP |
| Hostinger | ✅ Oui | Gestionnaire de fichiers (hPanel) |
| LWS | ✅ Oui | Gestionnaire de fichiers |
| PlanetHoster | ✅ Oui | Gestionnaire de fichiers N0C |
| Tout hébergeur cPanel ou Plesk | ✅ Oui | File Manager |
| Gandi | ❌ Non | client sFTP requis |
| OVHcloud | 🔴 Non, retiré | FTP Explorer / Net2FTP désactivé |
OVHcloud a supprimé son explorateur de fichiers en ligne. Ce n’est pas une interprétation, c’est dans leur documentation officielle, mise à jour le 31 mars 2026, sous un encart « Désactivation de l’outil FTP Explorer/Net2FTP » qui renvoie les clients vers FileZilla ou Cyberduck. L’avertissement ne distingue aucune offre : il vise les hébergements web en bloc, et aucun remplaçant n’a été intégré au Manager.
Concrètement, pour un client OVHcloud non technique qui voit son site se comporter bizarrement un dimanche : installer un logiciel FTP, retrouver ses identifiants dans le Manager, comprendre hôte, port et protocole, puis trouver le bon dossier. Depuis un téléphone, c’est mort. Le geste d’urgence redevient un appel au prestataire.
Je suis moi-même chez OVHcloud pour mes propres sites, et je le dis sans plaisir : retirer cet outil a transformé un dépannage de trente secondes en intervention. Gandi n’en a jamais eu, ce qui est différent : OVHcloud a repris quelque chose que ses clients avaient.
Si votre hébergeur est dans la colonne « Non », l’interrupteur reste installable, mais il faudra un client FTP pour l’actionner. Prévoyez-le, et prévoyez surtout que la personne qui l’actionnera ne sera pas forcément vous.
Et si vous administrez le serveur ?
Tout ce qui précède part du principe que vous n’avez pas la main sur la machine. Si vous l’avez, le .htaccess n’est plus le bon endroit : il est relu à chaque requête et n’importe qui ayant accès aux fichiers peut le neutraliser. La même logique se met dans la configuration du serveur, et elle y est plus rapide et plus difficile à contourner.
Apache, en vhost plutôt qu'en .htaccess
<VirtualHost *:443>
ServerName votre-site.fr
DocumentRoot /var/www/votre-site
# Plus besoin de garde d'hote : on est deja dans le vhost du site.
# Et le chemin est connu, donc plus de piege DOCUMENT_ROOT.
RewriteEngine On
RewriteCond /var/www/votre-site/PAUSE.txt -f
RewriteCond %{REQUEST_URI} !^/(maintenance\.html|robots\.txt)$
RewriteRule ^ - [E=JW_MAINT:1,R=503,L]
ErrorDocument 503 /maintenance.html
Header always set Retry-After "3600" env=JW_MAINT
Header always set Retry-After "3600" env=REDIRECT_JW_MAINT
# Bonus : sans .htaccess a relire, Apache sert le site plus vite.
# ⚠️ AllowOverride None coupe la lecture de TOUS les .htaccess, dont
# celui de WordPress : ses regles de permaliens doivent etre
# remontees ici, sinon toutes les URLs tombent en 404.
# Vhost complet avec ce bloc deja remonte : voir le depot.
<Directory /var/www/votre-site>
AllowOverride None
</Directory>
</VirtualHost>Un systemctl reload apache2 suffit, il n’y a pas de coupure. Et AllowOverride None ferme au passage une porte : un attaquant qui dépose un .htaccess dans un répertoire d’upload ne peut plus rien réécrire.
Attention quand même, parce que c’est le genre de ligne qu’on copie sans réfléchir : couper AllowOverride, c’est couper la lecture de tous les .htaccess, y compris celui de WordPress. Ses règles de permaliens doivent être remontées dans le vhost, sinon toutes vos URLs tombent en 404 dès le rechargement. Le dépôt contient le vhost complet avec ce bloc déjà remonté. Si vous n’êtes pas certain, laissez AllowOverride All : vous perdez le gain de vitesse, l’interrupteur fonctionne quand même.
Nginx, qui n'a pas de .htaccess du tout
C’est la question qu’on me pose le plus souvent, alors voici l’équivalent exact, à placer dans le bloc server :
server {
server_name votre-site.fr;
root /var/www/votre-site;
set $maintenance 0;
# Chemin ABSOLU, surtout pas $document_root : quand ce test tourne, la
# location n'est pas encore choisie et nginx utilise celle du serveur
# par defaut. Ca marche tant que root est declare au niveau server, et ca
# casse EN SILENCE si quelqu'un le declare seulement dans ses location.
if (-f /var/www/votre-site/PAUSE.txt) { set $maintenance 1; }
# $uri (normalise, SANS query string) et non $request_uri : avec
# $request_uri, "/robots.txt?v=2" ne matche pas et robots.txt part en 503.
if ($uri = "/robots.txt") { set $maintenance 0; }
# Sans cette ligne, une pause de quelques semaines fait echouer le
# renouvellement Let's Encrypt : certificat expire par-dessus le marche.
if ($uri ~ "^/\.well-known/") { set $maintenance 0; }
if ($maintenance = 1) { return 503; }
# PAS de "=" apres 503. "error_page 503 = @maintenance" ferait ADOPTER le
# code du handler, donc 200 : le site se ferait desindexer. La doc nginx
# illustre pourtant les locations nommees avec un "=" : ne pas le recopier.
error_page 503 @maintenance;
location @maintenance {
root /var/www/votre-site;
# "always" obligatoire : sans lui, add_header ignore les codes d'erreur
# (503 n'est pas dans sa liste blanche) et l'en-tete serait absent.
add_header Retry-After 3600 always;
# "=503", et surtout pas "rewrite ^ /maintenance.html break" : si le
# fichier manque, le client recevrait un 404 silencieux au lieu du 503.
try_files /maintenance.html =503;
}
}Trois choses méritent d’être dites, parce qu’elles ne sont dans aucune des recettes qu’on trouve en ligne.
Le if n’est pas « evil » ici. La page qui a donné sa mauvaise réputation à cette directive s’intitule littéralement « If is Evil… when used in location context », et elle précise noir sur blanc qu’on peut remonter les if au niveau server, « où c’est sûr ». C’est exactement ce bloc. Ne les redescendez pas dans une location. Bonus : au niveau server, le test tourne avant le choix de la location, donc le 503 court-circuite tout, y compris PHP-FPM et un éventuel webshell déposé dans les uploads.
N’utilisez pas $document_root. C’est le raccourci que j’allais vous vendre, et il est faux : cette variable vaut « la racine pour la requête courante », or à cet instant la location n’est pas encore choisie et Nginx utilise celle du serveur par défaut. Ça marche tant que root est déclaré au niveau server, et ça casse en silence chez quiconque le déclare uniquement dans ses location. Chemin absolu en dur, exactement comme côté Apache.
Le piège du mode dégradé. Beaucoup d’exemples écrivent rewrite ^ /maintenance.html break;. Ça marche, jusqu’au jour où le fichier est absent ou mal placé : la documentation d’error_page précise que « le statut de la dernière erreur survenue est renvoyé au client », donc le visiteur reçoit un 404 à la place du 503. Silencieusement, et précisément le jour où ça compte. try_files /maintenance.html =503; est la seule des trois formes courantes qui ne peut pas dégrader le code de statut.
Dernier détail, et il est méchant : error_page 503 @maintenance; s’écrit sans signe égal. La documentation Nginx illustre pourtant les locations nommées avec error_page 404 = @fallback;. Recopiez ce = et vous demandez à Nginx d’adopter le code du gestionnaire : votre 503 devient un 200, et le site se fait désindexer par la manœuvre censée l’en protéger.
Un nginx -t avant de recharger, toujours. Une accolade oubliée dans un fichier de conf coupe tous les sites de la machine, pas seulement celui que vous vouliez mettre en pause.
Plusieurs serveurs derrière un répartiteur
Si le site tourne sur plusieurs machines, ne posez pas le fichier témoin sur chacune : vous obtiendrez un site à moitié en pause, ce qui est pire que les deux états francs. La bascule se fait un cran au-dessus, sur le répartiteur de charge, en sortant les serveurs du pool ou en renvoyant un 503 depuis lui. Le principe ne change pas, seul l’endroit où vit l’interrupteur change.
Ce que ça préserve
Couper un site, ça fait peur. Trois questions reviennent à chaque fois.
Le référencement. Le code 503 Service Unavailable signifie « indisponible temporairement », pas « disparu ». C’est la recommandation explicite de Google pour une interruption planifiée : l’indexation est mise en pause, les positions ne sont pas purgées. L’en-tête Retry-After indique quand repasser. Un 404 ou une page blanche, eux, font des dégâts durables. Et robots.txt reste servi, volontairement : un robot doit toujours pouvoir lire les règles.
Les données. Rien n’est touché. Les commandes, les produits, les comptes clients, la base : tout reste en place. Seule la consultation publique est suspendue. L’administration reste accessible si vous en avez besoin, puisque la règle ne bloque que le trafic entrant sur le domaine.
Les preuves. C’est le point que les clients découvrent le plus tard. Un site coupé en 503 est un site figé : les fichiers déposés par l’attaquant, les horodatages, les journaux d’accès restent exploitables. Si vous déposez plainte, ou si votre assurance demande un rapport, c’est cette matière qui compte. Nettoyer avant de constater, c’est effacer le dossier. J’en parle plus longuement dans l’article sur mon arsenal de réponse à incident.
Ce que ça ne fait pas
Et maintenant le paragraphe que personne n’a envie de lire, parce que c’est là que les malentendus commencent.
L’interrupteur arrête l’hémorragie. Il ne répare rien, il ne désinfecte rien, et il n’empêche pas une réinfection quand le site redémarre. Si le vecteur d’entrée était un mot de passe volé sur un poste infecté, le site retombera : c’est le poste qu’il faut traiter d’abord, comme je l’explique dans l’article sur les virus voleurs de mots de passe.
Ce n’est pas non plus un outil de maintenance quotidienne. C’est un geste de sécurité. Quand un client l’actionne, il me prévient : la coupure est un signal, pas une fin en soi.
Et l’ordre des opérations ne change pas : couper, sauvegarder (fichiers et base, avant toute intervention, cf. le guide de sauvegarde), constater, puis nettoyer. Dans cet ordre. Toujours.
Questions pratiques, réponses courtes
- Ça marche sur autre chose que WordPress ?
- Oui. La règle est au niveau d'Apache, elle ignore ce qui tourne derrière. PrestaShop, Joomla, un site statique, une application PHP maison : même comportement.
- Et si mon hébergeur est sous Nginx ?
- Le
.htaccessn'existe pas sous Nginx : la configuration est centralisée, donc il faut un accès à la machine (VPS ou dédié). L'équivalent exact est plus haut, dans la section sur l'administration du serveur. Sur un mutualisé Nginx, vous n'avez pas cet accès : demandez à l'hébergeur, la plupart proposent un mode maintenance dans leur panneau. - Le client peut-il casser son site en se trompant ?
- Non, et c'est voulu. S'il supprime le fichier au lieu de le renommer, le site reste en ligne : la condition n'est simplement plus jamais vraie. L'échec du mécanisme est silencieux et sans conséquence. C'est l'inverse qui serait dangereux.
- Combien de temps peut-on rester en pause ?
- Quelques jours sans risque SEO mesurable. Au-delà d'une semaine, Google commence à traiter le 503 comme un état durable. Si l'arrêt se prolonge, il faut une vraie page d'information en 200, pas un 503 permanent.
- Faut-il prévenir ses visiteurs ?
- La page de maintenance le fait. Ajoutez-y un moyen de contact si le site prend des commandes : un client qui ne peut plus payer et ne sait pas pourquoi appelle son banquier avant de vous appeler.
- Pourquoi tolérer
pause.txten minuscules ? - Parce que le champ de renommage arrive vide et que le client tape le nom complet, souvent sur un téléphone, souvent sous stress. Une faute de casse ne doit pas transformer un geste d'urgence en échec silencieux.
🔌 Open source · Prêt à coller
molokoloco / htaccess-kill-switch
Tout est public : le bloc commenté, un .htaccess durci complet, la page de maintenance, le fichier témoin et le mode d'emploi 1 page à remettre au client. Adaptez trois chaînes et c'est en place.
Licence MIT : prenez, forkez, adaptez. Trois chaînes à changer (votre domaine, le chemin absolu de votre docroot, la durée annoncée) et l’interrupteur est en place. Le dépôt contient aussi le tutoriel client d’une page en PDF, prêt à remettre tel quel, et le comparatif des hébergeurs tenu à jour. molokoloco/htaccess-kill-switch
Prenez-le, il est à vous
Le code est sur GitHub en licence MIT : le bloc commenté, un .htaccess complet durci, la page de maintenance et le fichier témoin avec son mode d'emploi. Si votre site vient de se faire pirater, ne bricolez pas : coupez, ne nettoyez rien, appelez.
