Un écran blanc WordPress sans le moindre message d’erreur, c’est la panne la plus vicieuse du CMS. Tu rafraîchis, rien. L’admin ne répond plus, le front est vide, et PHP a décidé de fermer sa gueule. Ce truc a un nom : le WSOD, White Screen of Death. Et contrairement à ce que racontent les forums, il n’y a pas quinze causes différentes, il y en a six vraies. Elles se diagnostiquent dans un ordre précis.
L’écran blanc WordPress, c’est quoi exactement ?
Techniquement, c’est une erreur PHP fatale qui n’est jamais affichée. WordPress tourne, la requête part vers MySQL, le thème se charge, et à un moment PHP rencontre quelque chose qu’il ne digère pas. Au lieu d’afficher l’erreur, il coupe net. Résultat : page blanche, code HTTP 200 ou 500 selon les hébergeurs.
Le piège, c’est que la plupart des hébergeurs désactivent l’affichage des erreurs par défaut. Ton écran blanc WordPress ne dit donc jamais où ça bloque. Il faut aller le chercher soi-même, à la main, avec les bons outils.
Cause n°1 : un plugin ou un thème qui plante
C’est la cause de l’immense majorité des écrans blancs WordPress que je croise. Une mise à jour de plugin, un thème acheté sur un marché douteux, un snippet collé dans functions.php sans vérifier la syntaxe. Une virgule oubliée, un point-virgule manquant, et tout tombe.
Pour tester, tu ne désactives pas les plugins depuis l’admin, puisque l’admin est mort. Tu passes par FTP ou par le gestionnaire de fichiers de ton hébergeur, tu renommes le dossier /wp-content/plugins en /wp-content/plugins-off, et tu recharges. Si le site revient, c’est un plugin. Il ne reste plus qu’à les réactiver un par un.
Même technique pour le thème : renomme /wp-content/themes/ton-theme. WordPress bascule automatiquement sur un thème par défaut s’il en trouve un dans le dossier. S’il n’en trouve aucun, l’écran blanc WordPress reste affiché. Pense à garder un thème par défaut (Twenty Twenty-Four par exemple) toujours installé, ça t’évite ce piège.
Cause n°2 : le manque de mémoire PHP allouée à WordPress
Deuxième cause, très fréquente sur les hébergements mutualisés premier prix : PHP n’a plus assez de RAM pour exécuter la requête. Un plugin lourd, un import de données, un gros WooCommerce avec 3000 produits, et ça saute. L’erreur réelle que personne ne voit est « Allowed memory size exhausted ».
La correction se fait dans wp-config.php, juste avant la ligne qui dit que l’édition est terminée. Tu ajoutes :
define(‘WP_MEMORY_LIMIT’, ‘256M’);
Attention, cette ligne ne marche que si ton hébergeur autorise cette limite. Si le serveur plafonne à 128M côté PHP, elle ne changera strictement rien. Il faut contacter le support et demander une hausse réelle du memory_limit, pas juste un réglage cosmétique.
Cause n°3 : une base de données corrompue
Quand une table ne répond plus correctement, WordPress peut afficher un écran blanc WordPress au lieu du message classique d’erreur de connexion à la base. Les tables wp_options et wp_posts sont les premières à lâcher, souvent après un crash serveur ou une coupure de courant.
La réparation passe par phpMyAdmin ou directement en ligne de commande :
mysqlcheck -u utilisateur -p base_de_donnees -r
Le -r répare, le -a analyse sans rien modifier. Sur une table InnoDB ça passe presque toujours, sur du MyISAM aussi. Vérifie également que le préfixe de table défini dans wp-config.php correspond bien à celui présent dans la base. Un préfixe modifié par erreur, et c’est l’écran blanc garanti.
Cause n°4 : les incompatibilités de version PHP et WordPress
Un thème codé pour PHP 5.6 qui tourne sur PHP 8.2 ou 8.3, c’est une machine à écran blanc WordPress. Les fonctions dépréciées comme create_function() ont purement disparu, et ce qui était un simple warning devient une erreur fatale.
Même logique pour un plugin jamais mis à jour depuis 2019 : il utilise des API WordPress qui n’existent plus dans le core actuel. La fiche du plugin sur WordPress.org affiche les versions testées. Si ton plugin n’est pas marqué comme compatible avec ta version de WordPress ou de PHP, méfie-toi sérieusement.
Cause n°5 : le fichier .htaccess et les permissions de fichiers
Un .htaccess corrompu génère souvent une erreur 500, mais selon la configuration du serveur, il peut aussi produire un écran blanc WordPress. Renomme-le en .htaccess.old et recharge. Si le site revient, régénère-le proprement depuis Réglages puis Permaliens, en cliquant deux fois sur Enregistrer.
Côté permissions, WordPress veut du 755 pour les dossiers et du 644 pour les fichiers. Un 777 sur wp-config.php ne fait pas planter le site, mais un 000 ou une mauvaise propriété de fichier si. Ça arrive systématiquement après une migration de serveur bâclée.
Ma méthode pour identifier la panne en dix minutes
Je commence toujours par activer le débogage avant de toucher à quoi que ce soit. Dans wp-config.php, tu passes ces trois lignes à true :
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
Le fichier /wp-content/debug.log va alors écrire l’erreur fatale exacte, avec le chemin du fichier et le numéro de ligne. À partir de là, tu ne devines plus, tu lis. C’est la différence entre perdre trois heures et régler le problème en cinq minutes.
Ensuite, dans l’ordre :
- Désactivation des plugins par FTP
- Bascule sur un thème par défaut
- Augmentation de la mémoire PHP
- Réparation de la base de données
- Vérification du .htaccess
- Contrôle des permissions de fichiers
Ne cherche pas au hasard. Un écran blanc WordPress, ce n’est pas de la magie noire, c’est une checklist qu’on déroule dans l’ordre.
Ce qui ne sert à rien (et que tout le monde fait quand même)
Réinstaller WordPress par-dessus ne corrige rien du tout. Vider le cache non plus, puisque la panne est côté PHP et non côté navigateur. Et nettoyer ton cache local, tu peux oublier : l’écran blanc WordPress n’a aucun rapport avec ton navigateur.
Ce qui aide vraiment quand tu galères depuis une heure, c’est de restaurer une sauvegarde qui fonctionne, puis de réappliquer les mises à jour une par une. C’est moins glorieux que de dénicher le bug, mais ça remet le site en ligne tout de suite.
Le vrai problème derrière l’écran blanc
WordPress ne montre pas les erreurs par défaut, et cette décision date d’il y a longtemps, pour éviter de balancer des chemins serveur aux visiteurs. Sauf qu’elle rend le diagnostic beaucoup plus lent pour tout le monde, à commencer par toi.
Ma position est claire : sur un site en production, garde WP_DEBUG_DISPLAY à false, mais active le log en permanence. Tu auras toujours un debug.log prêt à lire le jour où un écran blanc WordPress débarque sans prévenir. C’est la seule vraie protection qui tient dans le temps.
Et si après tout ça la page reste blanche, le problème n’est plus dans WordPress. Il est dans PHP, dans MySQL ou dans la configuration du serveur. C’est à l’hébergeur de prendre le relais, pas à toi de bricoler dans le vide en espérant qu’un clic magique règle la situation.
