WordPress & CMS
Écran blanc WordPress (WSOD) : le diagnostic dans l'ordre
Le White Screen of Death n'est presque jamais une fatalité. Voici comment isoler la cause réelle en quelques minutes — du plus probable au plus rare — sans aggraver la panne.
Un matin, la page d'accueil est blanche. Pas d'erreur, pas de logo, rien. Réponse directe : l'écran blanc WordPress (WSOD) est presque toujours une erreur PHP fatale que WordPress masque, causée dans 9 cas sur 10 par un plugin, sinon par le thème ou une limite mémoire. La première étape n'est donc pas de bricoler, mais de rendre l'erreur visible — ensuite, la cause tombe en quelques minutes. Voici la procédure exacte, dans l'ordre.
Comment voir l'erreur que WordPress cache ?
Par défaut, WordPress masque les erreurs PHP en production : c'est ce masquage qui produit le blanc. Rendez l'erreur visible en modifiant wp-config.php (juste avant la ligne /* That's all, stop editing! */) :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Rechargez la page, puis ouvrez wp-content/debug.log. La dernière ligne ressemble à ceci, et elle nomme le fichier et la ligne exacts du plantage :
PHP Fatal error: Uncaught Error: Call to undefined function some_plugin_init()
in /var/www/wp-content/plugins/mon-plugin/mon-plugin.php:42Vous venez de transformer un mystère en une adresse précise. Remettez WP_DEBUG à false une fois réglé — laisser les logs actifs en production expose des chemins serveur.
Pourquoi un plugin est-il le suspect n°1 ?
Si l'erreur pointe vers wp-content/plugins/, vous tenez le coupable. Le réflexe destructeur — tout désactiver d'un coup depuis phpMyAdmin — vous fait perdre l'information sur *quel* plugin est en cause.
À la place, renommez le dossier de l'extension suspecte via FTP (ou le gestionnaire de fichiers de l'hébergeur) : woocommerce → woocommerce_off. WordPress la désactive au rechargement. Si le site revient, la cause est isolée sans toucher aux autres extensions. En WP-CLI, c'est encore plus rapide :
wp plugin deactivate mon-pluginEt si ce n'est pas un plugin : thème ou mémoire ?
Si le renommage des plugins ne change rien, l'arbre de décision continue :
- Thème : renommez le dossier du thème actif dans
wp-content/themes/. WordPress bascule sur un thème par défaut. Site de retour ? Le coupable est le thème — souvent sonfunctions.phpmodifié à la main ou cassé par une mise à jour. - Mémoire PHP : un blanc sans erreur claire sur une page lourde (admin, page builder) sent la limite mémoire. Ajoutez
define( 'WP_MEMORY_LIMIT', '256M' );. Si ça débloque, c'est un pansement : une extension consomme trop, à identifier ensuite. - Cœur WordPress : si l'erreur pointe vers
wp-includes/, ne modifiez jamais ces fichiers à la main — c'est le signal d'un fichier corrompu ou d'un piratage.
Checklist express
- [ ]
WP_DEBUG_LOGactivé,debug.loglu (le fichier + la ligne du plantage) - [ ] Plugin suspect renommé/désactivé → site revient ?
- [ ] Thème actif renommé → site revient ?
- [ ]
WP_MEMORY_LIMITaugmenté → site revient ? - [ ] Erreur qui pointe vers
wp-includes/→ stop, ne pas bricoler - [ ]
WP_DEBUGremis àfalseaprès résolution
Questions fréquentes
Comment réparer un écran blanc WordPress sans accès à l'admin ?
Passez par le FTP ou le gestionnaire de fichiers de l'hébergeur : activez WP_DEBUG_LOG dans wp-config.php, lisez wp-content/debug.log, puis renommez le dossier du plugin ou du thème fautif. WordPress désactive automatiquement une extension dont le dossier a été renommé — vous récupérez l'accès sans passer par le back-office.
L'écran blanc peut-il venir d'une mise à jour PHP ?
Oui. Si l'hébergeur a basculé sur une version PHP plus récente, une extension utilisant une fonction supprimée provoque une erreur fatale. Le debug.log le confirme (« Call to undefined function » ou « expects parameter »). La solution est de mettre à jour l'extension ou, en dépannage, de redescendre temporairement la version PHP.
Pourquoi je ne vois toujours rien après avoir activé WP_DEBUG ?
Parce que WP_DEBUG_DISPLAY est à false (recommandé en production) : l'erreur ne s'affiche pas à l'écran mais est écrite dans wp-content/debug.log. C'est ce fichier qu'il faut ouvrir. Si le fichier n'existe pas, vérifiez les droits d'écriture sur wp-content/.
Faut-il restaurer une sauvegarde ?
Seulement si le diagnostic échoue ou si un piratage est suspecté. Dans la majorité des cas (plugin/thème/mémoire), on corrige la cause sans restauration. Gardez néanmoins une sauvegarde à jour avant toute manipulation, par sécurité.
Quand faire appel à HelpApp Pro
Trois signaux disent qu'il faut passer la main : l'erreur pointe vers le cœur de WordPress, un piratage est suspecté, ou le checkout est cassé et chaque heure coûte des ventes. HelpApp Pro intervient sur ce type de blocage sans refonte : on lit le debug.log avec vous, on corrige la cause réelle, et on vérifie que rien d'autre ne casse. Décrivez le symptôme via le devis en ligne, ou passez en urgence si le site est à l'arrêt.
Cet article vous a été utile ?
Besoin d'une intervention ciblée ?
Décrivez le blocage — devis sans engagement, ou rappel sous 2 h ouvrées. Supplément urgence possible.
À lire aussi
WordPress & CMS
Bug WordPress en urgence : que faire avant d'appeler un expert
Checkout à l'arrêt, wp-admin inaccessible, écran blanc ou site qui redirige vers un domaine inconnu : la checklist pour isoler la cause en sécurité, ce qu'il ne faut jamais toucher, et le moment précis où arrêter de bricoler.
8 min de lectureWordPress & CMS
Une mise à jour de plugin a cassé le site : le rollback propre
Revenir en arrière après une mise à jour ratée s'improvise mal. Voici la méthode pour restaurer la version précédente sans perdre de données, puis remettre à jour proprement.
4 min de lecture