Site WordPress qui ne publie plus : causes et solutions

Un site WordPress qui ne publie plus souffre généralement d’un conflit d’extension, d’une limite mémoire PHP dépassée ou d’un fichier `.maintenance` oublié après une mise à jour ratée. Résoudre un site WordPress qui ne publie plus prend moins de vingt minutes une fois la cause identifiée.

Le diagnostic repose sur une question simple : qu’est-ce qui a changé juste avant que ça s’arrête ? Une mise à jour automatique, une extension activée sans prévenir, un quota d’hébergement atteint en silence.

En Bref

• La majorité des blocages de publication viennent d’un conflit d’extension ou d’une limite mémoire dépassée
• Le diagnostic se fait dans un ordre précis : extensions d’abord, serveur ensuite, base de données en dernier
• Avant toute intervention, sauvegarder la base de données, pas après
• Un fichier `.maintenance` persistant n’est pas une panne : c’est un oubli qui se règle en trente secondes

Ce qui se passe vraiment quand WordPress arrête de publier

WordPress ne « décide » pas de bloquer la publication. Ce qui échoue, c’est une chaîne d’opérations : le clic sur « Publier » déclenche une requête PHP, qui écrit dans la base de données, qui met à jour le cache, qui rend l’article visible. Si l’un de ces maillons cède, le résultat en surface reste le même : rien ne se passe.

Le blocage silencieux est le cas le plus trompeur. Pas de message d’erreur, pas de page blanche, juste un bouton « Publier » qui revient à son état initial. L’éditeur clique trois fois, recharge la page, et pense à un bug de navigateur.

En réalité, PHP n’a souvent pas eu assez de mémoire pour finaliser l’écriture. La sauvegarde du brouillon a échoué à mi-chemin, sans que WordPress ait pu afficher quoi que ce soit d’utile.

Chercher le maillon faible d’une chaîne ordinaire : voilà le bon réflexe. Ne relancez pas la publication à répétition, chaque tentative échouée crée des entrées orphelines en base de données.

Les raisons les plus courantes, classées par fréquence

Mise à jour d’une extension, du thème ou du cœur WordPress

Une extension mise à jour peut introduire un conflit avec une autre ou modifier le comportement de l’éditeur Gutenberg. Vous publiez sans problème en après-midi, la mise à jour tourne le soir, et plus rien le lendemain matin.

C’est la cause la plus fréquente. Vérifiez le journal des mises à jour dans Tableau de bord > Mises à jour et comparez la date avec le moment où le problème a commencé.

Erreur de connexion à la base de données ou quota serveur atteint

Quand WordPress ne peut plus écrire dans sa base de données (connexion coupée, identifiants incorrects ou quota disque épuisé), la publication échoue sans explication claire. Sur un hébergement mutualisé, le quota d’espace est partagé entre tous les sites du compte.

Une base de données corrompue est plus rare mais plus sérieuse. Les tables mal indexées refusent silencieusement les nouvelles insertions.

Site bloqué en mode maintenance ou victime d’une injection de spam

Le fichier `.maintenance` que WordPress crée pendant une mise à jour devrait disparaître automatiquement. S’il reste, le site affiche un message de maintenance pour tous les visiteurs, y compris vous dans l’administration. La confusion est fréquente : ce n’est pas un blocage de publication, c’est un écran qui masque tout.

Une injection de spam est plus grave. Des scripts injectés peuvent réécrire les permissions fichiers WordPress au point d’empêcher toute écriture. Cybermalveillance.gouv.fr signalait en juillet 2026 des failles critiques dans plusieurs versions de WordPress, permettant une prise de contrôle à distance. Si votre site n’est pas à jour, ce scénario n’est pas hypothétique.

Notez ce qui a changé sur votre site dans les 48 heures avant le blocage : la réponse s’y trouve souvent.

Les signaux d’alerte à reconnaître sans être développeur

Écran blanc, erreur 500, message de maintenance qui dure

L’écran blanc signale un problème PHP fatal, une extension qui génère une erreur bloquante, ou une limite mémoire PHP dépassée. L’erreur 500 vient souvent du même endroit, avec un problème de configuration serveur.

Le message de maintenance qui dure plus d’une heure est presque toujours un fichier `.maintenance` oublié. Ce n’est pas une panne : c’est un fichier à supprimer.

Les modifications ne s’enregistrent pas et les médias refusent de s’importer

Quand une image refuse de s’importer dans la médiathèque, le dossier `/wp-content/uploads/` n’est probablement plus accessible en écriture. Les permissions FTP ont été modifiées après une intervention sur le serveur ou une mise à jour d’hébergement.

Si les médias sont bloqués, la publication des articles l’est souvent aussi, pour la même raison.

Le site répond, mais aucun nouvel article n’apparaît côté visiteur

C’est le cas le plus insidieux. L’admin semble fonctionner, la publication semble réussir, mais le visiteur ne voit rien de nouveau. Causes probables : un cache serveur qui ne s’invalide pas, un plugin de cache qui crée un conflit, ou un article publié avec une date future par erreur.

Signal visible	Cause probable	Priorité de diagnostic
Écran blanc complet	Limite mémoire PHP ou erreur PHP fatale	Haute
Erreur 500	Configuration serveur ou `.htaccess` corrompu	Haute
Message maintenance permanent	Fichier `.maintenance` non supprimé	Facile à régler
Publication silencieuse sans effet	Cache non invalidé, plugin conflictuel	Moyenne
Médias non importables	Permissions `/uploads` incorrectes	Moyenne
Admin accessible mais rien côté visiteur	Plugin de cache, article en date future	Faible à moyenne

Reconnaissez-vous l’un de ces signaux ? Passez directement à la section de diagnostic correspondante plutôt que de tout tester dans l’ordre.

Diagnostic rapide : vérifier soi-même en moins de vingt minutes

Désactiver les extensions une par une pour isoler la coupable

Allez dans Extensions > Extensions installées et utilisez l’option « Tout désactiver ». Trente secondes pour tester si une extension est coupable. Si la publication fonctionne, réactivez-les une par une en testant la publication après chaque réactivation.

La majorité commence par chercher sur Google « erreur publication WordPress ». Désactiver toutes les extensions en deux clics résout le problème dans un grand nombre de cas, bien avant que vous finissiez de lire votre première résultat de recherche.

À retenir

• Désactiver toutes les extensions avant toute autre manipulation
• Tester la publication immédiatement après
• Réactiver une extension à la fois pour identifier la coupable
• Si le problème vient d’une extension essentielle, chercher une alternative ou contacter son auteur

Basculer sur un thème par défaut pour écarter un conflit d’affichage

Si la désactivation des extensions ne change rien, activez un thème par défaut WordPress (Twenty Twenty-Four ou équivalent). Un thème mal codé peut interférer avec l’éditeur de blocs. Ce test prend une minute.

Thème par défaut : rapide à tester, souvent innocent. Extensions : lentes à tester une par une, mais coupables dans la plupart des cas.

Lire les journaux d’erreurs et interroger la Search Console

Le fichier `debug.log` dans `/wp-content/` contient les erreurs PHP si vous avez activé `WP_DEBUG_LOG` dans `wp-config.php`. C’est là que WordPress note ce qu’il n’affiche pas à l’écran.

La Search Console indique si Google a détecté des problèmes d’indexation récents. C’est un symptôme indirect mais utile pour confirmer depuis quand le problème existe.

Si après ces trois étapes rien n’est résolu, passez aux interventions du niveau suivant.

Les interventions à tenter avant d’appeler un professionnel

Restaurer une sauvegarde récente et vérifier qu’elle est saine

Avant toute manipulation sur le serveur, restaurez une sauvegarde de la base de données. Une sauvegarde jamais testée en restauration ne vaut rien.

Exportez la base via phpMyAdmin ou via l’outil de votre hébergeur. Gardez cette sauvegarde accessible pendant toute la durée des interventions.

Corriger les droits de fichiers et vider les caches à plusieurs niveaux

Les permissions recommandées : `755` pour les dossiers, `644` pour les fichiers. Le dossier `/wp-content/uploads/` doit être accessible en écriture pour le serveur web.

Videz les caches dans cet ordre : plugin de cache, cache serveur (via le panneau d’hébergement), puis CDN si vous en avez un. Un seul niveau de cache oublié peut masquer une publication réussie.

Supprimer le fichier .maintenance laissé par une mise à jour interrompue

Via FTP ou le gestionnaire de fichiers de votre hébergeur, cherchez un fichier nommé `.maintenance` à la racine du site. S’il est là, supprimez-le et testez immédiatement.

Cette manipulation prend moins de deux minutes et résout le cas « mode maintenance qui dure depuis trois jours » dans presque tous les cas.

Intervention	Niveau requis	Temps estimé	Risque si mal fait
Désactiver extensions	Débutant	5 min	Faible
Changer thème	Débutant	2 min	Faible
Supprimer .maintenance	Débutant	2 min	Très faible
Corriger permissions FTP	Intermédiaire	15 min	Moyen
Restaurer sauvegarde BDD	Intermédiaire	30 min	Élevé si erreur
Réparer tables via phpMyAdmin	Intermédiaire	20 min	Élevé si erreur
Réinstaller WordPress core	Expert	1 h	Élevé

Si les interventions « débutant » n’ont rien changé et que vous n’êtes pas à l’aise avec FTP, c’est le moment d’appeler un professionnel, pas après avoir tenté plusieurs manipulations en parallèle.

Le cas particulier des parcs de sites : quand un site à sec passe inaperçu trop longtemps

Pourquoi l’inactivité éditoriale endommage comme une panne technique

Un site qui ne publie plus rien depuis plusieurs semaines envoie des signaux identiques : une date de dernier article qui vieillit, un trafic qui s’érode, un acheteur qui consulte le dernier billet avant de passer commande et qui s’en va.

Un site à sec se détériore lentement, sans alarme. C’est souvent plus difficile à rattraper qu’une panne franche.

Quand vous gérez dix ou vingt sites en parallèle, le risque n’est pas de ne pas savoir réparer. C’est de ne pas savoir que le problème existe.

Surveiller tous ses sites depuis un seul écran

Un tableau de bord unifié permet de surveiller tous ses sites depuis un seul écran et de voir lequel n’a pas publié depuis trop longtemps, lequel a une alerte ouverte, lequel a perdu du trafic. Sans cet écran, la détection repose sur la mémoire ou le hasard.

Mettez en place une vérification hebdomadaire de l’activité de chaque site, même sommaire. C’est la seule façon de voir venir.

Les erreurs qui transforment un incident mineur en panne durable

Mettre à jour en production sans sauvegarde préalable

Beaucoup font cette erreur et le regrettent à la première mise à jour majeure ratée. Une mise à jour du cœur WordPress qui échoue à mi-chemin laisse le site dans un état inconsistant.

Règle simple : sauvegarde avant mise à jour, pas après. Et testez la sauvegarde en restaurant sur un environnement de test, au moins une fois par trimestre.

Ignorer les alertes de sécurité jusqu’au retrait d’un catalogue

Un site infecté par du spam injecté peut continuer à fonctionner pendant des semaines. Ce n’est pas la publication qui échoue en premier, c’est le catalogue de plateforme qui retire le site, ou un acheteur qui signale du contenu suspect.

La veille de sécurité sur fichiers, comptes administrateurs et domaine permet de détecter une injection avant qu’elle devienne visible. Attendre que le problème soit évident, c’est attendre qu’il soit coûteux.

Tenter plusieurs corrections en même temps sans noter ce qui change

C’est l’erreur de méthode la plus fréquente. On désactive les extensions, on modifie wp-config.php, on vide le cache, on restaure une table. Si ça marche, impossible de savoir ce qui a résolu le problème. Si ça ne marche pas, impossible de revenir à un état stable.

Une correction à la fois, notée avec son résultat.

Attention

• Jamais deux manipulations simultanées sans noter l’état avant chaque intervention
• Un site « réparé » sans sauvegarde préalable reste fragile
• Ignorer une alerte de sécurité parce que le site « fonctionne encore » est un calcul perdant

Empêcher la prochaine panne : routine de maintenance chiffrée

Ce qu’il faut vérifier chaque semaine, chaque mois et à chaque mise à jour majeure

Chaque semaine :

• Vérifier que chaque site a publié au moins un article récent
• Consulter les alertes de sécurité ouvertes
• Vérifier qu’aucun administrateur inconnu n’a été ajouté

Chaque mois :

• Passer les mises à jour des extensions et du thème, une par une
• Tester la restauration d’une sauvegarde sur au moins un site
• Consulter Outils > Santé du site dans WordPress et traiter les points critiques

À chaque mise à jour majeure de WordPress :

• Sauvegarde complète avant toute action
• Mise à jour sur un site de test en premier si vous en avez un
• Vérification de la publication immédiatement après

Budget temps et budget argent réalistes

Périmètre	Temps de maintenance mensuel	Niveau d’intervention
1 à 3 sites simples	1 à 2 heures	Débutant suffisant
5 à 15 sites actifs	4 à 8 heures	Intermédiaire recommandé
20 sites et plus	Outil de monitoring indispensable	Expert ou délégation

Au-delà d’une dizaine de sites, le temps devient le vrai coût. Un incident non détecté pendant trois semaines sur un site actif coûte plus en trafic perdu qu’un abonnement de monitoring annuel.

Pourquoi certaines réparations n’aboutissent pas malgré un diagnostic correct

C’est le cas que personne ne mentionne.

Vous avez isolé la bonne extension, vous l’avez désactivée, la publication fonctionne. Puis vous réinstallez l’extension depuis le répertoire officiel, et le problème revient aussi. Raison : un conflit entre la version de PHP de votre hébergeur et la dernière version de l’extension.

Dans ce cas, désactiver ne suffit pas. Choisissez : garder l’extension et mettre à jour PHP (intervention hébergeur), ou trouver une alternative compatible.

Autre cas : la base de données réparée via phpMyAdmin continue à générer des erreurs parce que le problème n’est pas dans les tables mais dans les droits de l’utilisateur MySQL. `REPAIR TABLE` réussit, mais l’utilisateur WordPress ne peut toujours pas écrire.

Enfin : un site dont la limite mémoire PHP a été augmentée dans `wp-config.php` peut continuer à échouer si l’hébergeur impose une limite inférieure au niveau serveur. Le paramètre local est ignoré sans avertissement.

Questions fréquentes

Comment savoir si un site tourne sous WordPress sans avoir accès à l’administration ?

L’adresse `/wp-login.php` renvoie une page de connexion si le site est sous WordPress. Le fichier `/wp-json/wp/v2/` renvoie une réponse JSON lisible dans le navigateur. Ces deux indices sont accessibles publiquement sur la quasi-totalité des sites WordPress standards, sauf si l’administrateur a renommé les chemins d’accès.

Je ne peux plus me connecter au tableau de bord WordPress : est-ce lié au blocage de publication ?

Pas nécessairement. Une impossibilité de connexion peut venir d’un mot de passe oublié, d’un compte désactivé, d’un plugin de sécurité qui a bloqué votre IP, ou d’une base de données inaccessible. La réinitialisation du mot de passe via l’email suffit dans la plupart des cas. Si la page de connexion ne répond pas du tout, c’est un problème serveur différent.

Comment désactiver temporairement un site WordPress sans le supprimer ?

Activez le mode maintenance en créant un fichier `.maintenance` à la racine, ou installez un plugin de maintenance. L’interface d’administration reste accessible pour vous. C’est utile pendant une réparation pour éviter que les visiteurs voient une page cassée.

Pourquoi un site peut-il être inaccessible sans que vous ayez rien changé ?

Un hébergeur peut subir une panne, un problème de réseau ou une opération de maintenance. Le nom de domaine peut aussi avoir expiré sans alerte. Vérifiez d’abord votre hébergeur via sa page de statut avant d’ouvrir wp-config.php.

Conclusion

Un site WordPress qui ne publie plus n’est presque jamais une catastrophe. C’est un incident dans une chaîne prévisible, avec des causes connues et un ordre de diagnostic qui fonctionne.

Ouvrez Outils > Santé du site sur chaque site de votre parc dès maintenant. Si des points critiques apparaissent, traitez-les dans l’ordre indiqué. C’est là que WordPress liste les problèmes qui deviennent des pannes si on les laisse s’installer.