En Bref<\/strong><\/p> WordPress ne \u00ab\u00a0d\u00e9cide\u00a0\u00bb pas de bloquer la publication. Ce qui \u00e9choue, c’est une cha\u00eene d’op\u00e9rations : le clic sur \u00ab\u00a0Publier\u00a0\u00bb d\u00e9clenche une requ\u00eate PHP, qui \u00e9crit dans la base de donn\u00e9es, qui met \u00e0 jour le cache, qui rend l’article visible. Si l’un de ces maillons c\u00e8de, le r\u00e9sultat en surface reste le m\u00eame : rien ne se passe.<\/p>\n\n\n\n Le blocage silencieux est le cas le plus trompeur. Pas de message d’erreur, pas de page blanche, juste un bouton \u00ab\u00a0Publier\u00a0\u00bb qui revient \u00e0 son \u00e9tat initial. L’\u00e9diteur clique trois fois, recharge la page, et pense \u00e0 un bug de navigateur.<\/p>\n\n\n\n En r\u00e9alit\u00e9, PHP n’a souvent pas eu assez de m\u00e9moire pour finaliser l’\u00e9criture. La sauvegarde du brouillon a \u00e9chou\u00e9 \u00e0 mi-chemin, sans que WordPress ait pu afficher quoi que ce soit d’utile.<\/p>\n\n\n\n Chercher le maillon faible d’une cha\u00eene ordinaire : voil\u00e0 le bon r\u00e9flexe. Ne relancez pas la publication \u00e0 r\u00e9p\u00e9tition, chaque tentative \u00e9chou\u00e9e cr\u00e9e des entr\u00e9es orphelines en base de donn\u00e9es.<\/p>\n\n\n\n Une extension mise \u00e0 jour peut introduire un conflit avec une autre ou modifier le comportement de l’\u00e9diteur Gutenberg. Vous publiez sans probl\u00e8me en apr\u00e8s-midi, la mise \u00e0 jour tourne le soir, et plus rien le lendemain matin.<\/p>\n\n\n\n C’est la cause la plus fr\u00e9quente. V\u00e9rifiez le journal des mises \u00e0 jour dans Tableau de bord > Mises \u00e0 jour<\/em> et comparez la date avec le moment o\u00f9 le probl\u00e8me a commenc\u00e9.<\/p>\n\n\n\n Quand WordPress ne peut plus \u00e9crire dans sa base de donn\u00e9es (connexion coup\u00e9e, identifiants incorrects ou quota disque \u00e9puis\u00e9), la publication \u00e9choue sans explication claire. Sur un h\u00e9bergement mutualis\u00e9, le quota d’espace est partag\u00e9 entre tous les sites du compte.<\/p>\n\n\n\n Une base de donn\u00e9es corrompue est plus rare mais plus s\u00e9rieuse. Les tables mal index\u00e9es refusent silencieusement les nouvelles insertions.<\/p>\n\n\n\n Le fichier `.maintenance` que WordPress cr\u00e9e pendant une mise \u00e0 jour devrait dispara\u00eetre 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\u00e9quente : ce n’est pas un blocage de publication, c’est un \u00e9cran qui masque tout.<\/p>\n\n\n\n Une injection de spam est plus grave. Des scripts inject\u00e9s peuvent r\u00e9\u00e9crire les permissions fichiers WordPress au point d’emp\u00eacher toute \u00e9criture. Cybermalveillance.gouv.fr signalait en juillet 2026 des failles critiques dans plusieurs versions de WordPress<\/a>, permettant une prise de contr\u00f4le \u00e0 distance. Si votre site n’est pas \u00e0 jour, ce sc\u00e9nario n’est pas hypoth\u00e9tique.<\/p>\n\n\n\n Notez ce qui a chang\u00e9 sur votre site dans les 48 heures avant le blocage : la r\u00e9ponse s’y trouve souvent.<\/p>\n\n\n\n L’\u00e9cran blanc signale un probl\u00e8me PHP fatal, une extension qui g\u00e9n\u00e8re une erreur bloquante, ou une limite m\u00e9moire PHP d\u00e9pass\u00e9e. L’erreur 500 vient souvent du m\u00eame endroit, avec un probl\u00e8me de configuration serveur.<\/p>\n\n\n\n Le message de maintenance qui dure plus d’une heure est presque toujours un fichier `.maintenance` oubli\u00e9. Ce n’est pas une panne : c’est un fichier \u00e0 supprimer.<\/p>\n\n\n\n Quand une image refuse de s’importer dans la m\u00e9diath\u00e8que, le dossier `\/wp-content\/uploads\/` n’est probablement plus accessible en \u00e9criture. Les permissions FTP ont \u00e9t\u00e9 modifi\u00e9es apr\u00e8s une intervention sur le serveur ou une mise \u00e0 jour d’h\u00e9bergement.<\/p>\n\n\n\n Si les m\u00e9dias sont bloqu\u00e9s, la publication des articles l’est souvent aussi, pour la m\u00eame raison.<\/p>\n\n\n\n C’est le cas le plus insidieux. L’admin semble fonctionner, la publication semble r\u00e9ussir, mais le visiteur ne voit rien de nouveau. Causes probables : un cache serveur qui ne s’invalide pas, un plugin de cache qui cr\u00e9e un conflit, ou un article publi\u00e9 avec une date future par erreur.<\/p>\n\n\n\n Reconnaissez-vous l’un de ces signaux ? Passez directement \u00e0 la section de diagnostic correspondante plut\u00f4t que de tout tester dans l’ordre.<\/p>\n\n\n\n Allez dans Extensions > Extensions install\u00e9es<\/em> et utilisez l’option \u00ab\u00a0Tout d\u00e9sactiver\u00a0\u00bb. Trente secondes pour tester si une extension est coupable. Si la publication fonctionne, r\u00e9activez-les une par une en testant la publication apr\u00e8s chaque r\u00e9activation.<\/p>\n\n\n\n La majorit\u00e9 commence par chercher sur Google \u00ab\u00a0erreur publication WordPress\u00a0\u00bb. D\u00e9sactiver toutes les extensions en deux clics r\u00e9sout le probl\u00e8me dans un grand nombre de cas, bien avant que vous finissiez de lire votre premi\u00e8re r\u00e9sultat de recherche.<\/p>\n\n\n\n \u00c0 retenir<\/strong><\/p> Si la d\u00e9sactivation des extensions ne change rien, activez un th\u00e8me par d\u00e9faut WordPress (Twenty Twenty-Four ou \u00e9quivalent). Un th\u00e8me mal cod\u00e9 peut interf\u00e9rer avec l’\u00e9diteur de blocs. Ce test prend une minute.<\/p>\n\n\n\n Th\u00e8me par d\u00e9faut : rapide \u00e0 tester, souvent innocent. Extensions : lentes \u00e0 tester une par une, mais coupables dans la plupart des cas.<\/p>\n\n\n\n Le fichier `debug.log` dans `\/wp-content\/` contient les erreurs PHP si vous avez activ\u00e9 `WP_DEBUG_LOG` dans `wp-config.php`. C’est l\u00e0 que WordPress note ce qu’il n’affiche pas \u00e0 l’\u00e9cran.<\/p>\n\n\n\n La Search Console indique si Google a d\u00e9tect\u00e9 des probl\u00e8mes d’indexation r\u00e9cents. C’est un sympt\u00f4me indirect mais utile pour confirmer depuis quand le probl\u00e8me existe.<\/p>\n\n\n\n Si apr\u00e8s ces trois \u00e9tapes rien n’est r\u00e9solu, passez aux interventions du niveau suivant.<\/p>\n\n\n\n Avant toute manipulation sur le serveur, restaurez une sauvegarde de la base de donn\u00e9es. Une sauvegarde jamais test\u00e9e en restauration ne vaut rien.<\/p>\n\n\n\n Exportez la base via phpMyAdmin ou via l’outil de votre h\u00e9bergeur. Gardez cette sauvegarde accessible pendant toute la dur\u00e9e des interventions.<\/p>\n\n\n\n Les permissions recommand\u00e9es : `755` pour les dossiers, `644` pour les fichiers. Le dossier `\/wp-content\/uploads\/` doit \u00eatre accessible en \u00e9criture pour le serveur web.<\/p>\n\n\n\n Videz les caches dans cet ordre : plugin de cache, cache serveur (via le panneau d’h\u00e9bergement), puis CDN si vous en avez un. Un seul niveau de cache oubli\u00e9 peut masquer une publication r\u00e9ussie.<\/p>\n\n\n\n Via FTP ou le gestionnaire de fichiers de votre h\u00e9bergeur, cherchez un fichier nomm\u00e9 `.maintenance` \u00e0 la racine du site. S’il est l\u00e0, supprimez-le et testez imm\u00e9diatement.<\/p>\n\n\n\n Cette manipulation prend moins de deux minutes et r\u00e9sout le cas \u00ab\u00a0mode maintenance qui dure depuis trois jours\u00a0\u00bb dans presque tous les cas.<\/p>\n\n\n\n Si les interventions \u00ab\u00a0d\u00e9butant\u00a0\u00bb n’ont rien chang\u00e9 et que vous n’\u00eates pas \u00e0 l’aise avec FTP, c’est le moment d’appeler un professionnel, pas apr\u00e8s avoir tent\u00e9 plusieurs manipulations en parall\u00e8le.<\/p>\n\n\n\n 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’\u00e9rode, un acheteur qui consulte le dernier billet avant de passer commande et qui s’en va.<\/p>\n\n\n\n Un site \u00e0 sec se d\u00e9t\u00e9riore lentement, sans alarme. C’est souvent plus difficile \u00e0 rattraper qu’une panne franche.<\/p>\n\n\n\n Quand vous g\u00e9rez dix ou vingt sites en parall\u00e8le, le risque n’est pas de ne pas savoir r\u00e9parer. C’est de ne pas savoir que le probl\u00e8me existe.<\/p>\n\n\n\nCe qui se passe vraiment quand WordPress arr\u00eate de publier<\/h2>\n\n\n\n
Les raisons les plus courantes, class\u00e9es par fr\u00e9quence<\/h2>\n\n\n\n
Mise \u00e0 jour d’une extension, du th\u00e8me ou du c\u0153ur WordPress<\/h3>\n\n\n\n
Erreur de connexion \u00e0 la base de donn\u00e9es ou quota serveur atteint<\/h3>\n\n\n\n
Site bloqu\u00e9 en mode maintenance ou victime d’une injection de spam<\/h3>\n\n\n\n
![\"Infographie](\"https:\/\/robinet.app\/blog\/wp-content\/uploads\/2026\/10\/infographie-site-wordpress-qui-ne-publie-plus-causes.png\")
<\/figure>\n\n\n\nLes signaux d’alerte \u00e0 reconna\u00eetre sans \u00eatre d\u00e9veloppeur<\/h2>\n\n\n\n
\u00c9cran blanc, erreur 500, message de maintenance qui dure<\/h3>\n\n\n\n
Les modifications ne s’enregistrent pas et les m\u00e9dias refusent de s’importer<\/h3>\n\n\n\n
Le site r\u00e9pond, mais aucun nouvel article n’appara\u00eet c\u00f4t\u00e9 visiteur<\/h3>\n\n\n\n
Signal visible<\/th> Cause probable<\/th> Priorit\u00e9 de diagnostic<\/th><\/tr><\/thead> \u00c9cran blanc complet<\/td> Limite m\u00e9moire PHP ou erreur PHP fatale<\/td> Haute<\/td><\/tr> Erreur 500<\/td> Configuration serveur ou `.htaccess` corrompu<\/td> Haute<\/td><\/tr> Message maintenance permanent<\/td> Fichier `.maintenance` non supprim\u00e9<\/td> Facile \u00e0 r\u00e9gler<\/td><\/tr> Publication silencieuse sans effet<\/td> Cache non invalid\u00e9, plugin conflictuel<\/td> Moyenne<\/td><\/tr> M\u00e9dias non importables<\/td> Permissions `\/uploads` incorrectes<\/td> Moyenne<\/td><\/tr> Admin accessible mais rien c\u00f4t\u00e9 visiteur<\/td> Plugin de cache, article en date future<\/td> Faible \u00e0 moyenne<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Diagnostic rapide : v\u00e9rifier soi-m\u00eame en moins de vingt minutes<\/h2>\n\n\n\n
D\u00e9sactiver les extensions une par une pour isoler la coupable<\/h3>\n\n\n\n
Basculer sur un th\u00e8me par d\u00e9faut pour \u00e9carter un conflit d’affichage<\/h3>\n\n\n\n
Lire les journaux d’erreurs et interroger la Search Console<\/h3>\n\n\n\n
Les interventions \u00e0 tenter avant d’appeler un professionnel<\/h2>\n\n\n\n
Restaurer une sauvegarde r\u00e9cente et v\u00e9rifier qu’elle est saine<\/h3>\n\n\n\n
Corriger les droits de fichiers et vider les caches \u00e0 plusieurs niveaux<\/h3>\n\n\n\n
Supprimer le fichier .maintenance laiss\u00e9 par une mise \u00e0 jour interrompue<\/h3>\n\n\n\n
Intervention<\/th> Niveau requis<\/th> Temps estim\u00e9<\/th> Risque si mal fait<\/th><\/tr><\/thead> D\u00e9sactiver extensions<\/td> D\u00e9butant<\/td> 5 min<\/td> Faible<\/td><\/tr> Changer th\u00e8me<\/td> D\u00e9butant<\/td> 2 min<\/td> Faible<\/td><\/tr> Supprimer .maintenance<\/td> D\u00e9butant<\/td> 2 min<\/td> Tr\u00e8s faible<\/td><\/tr> Corriger permissions FTP<\/td> Interm\u00e9diaire<\/td> 15 min<\/td> Moyen<\/td><\/tr> Restaurer sauvegarde BDD<\/td> Interm\u00e9diaire<\/td> 30 min<\/td> \u00c9lev\u00e9 si erreur<\/td><\/tr> R\u00e9parer tables via phpMyAdmin<\/td> Interm\u00e9diaire<\/td> 20 min<\/td> \u00c9lev\u00e9 si erreur<\/td><\/tr> R\u00e9installer WordPress core<\/td> Expert<\/td> 1 h<\/td> \u00c9lev\u00e9<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Le cas particulier des parcs de sites : quand un site \u00e0 sec passe inaper\u00e7u trop longtemps<\/h2>\n\n\n\n
Pourquoi l’inactivit\u00e9 \u00e9ditoriale endommage comme une panne technique<\/h3>\n\n\n\n
Surveiller tous ses sites depuis un seul \u00e9cran<\/h3>\n\n\n\n