Écran blanc WordPress (WSOD) : récupérer son site

L’écran blanc de la mort : une page blanche qui dit tout, sauf ce qui se passe

Page blanche. Aucun message d’erreur. Aucune indication. Juste le vide — que vous chargiez le front-office, le back-office, ou les deux. C’est ce que la communauté WordPress appelle le WSOD (White Screen of Death), et c’est probablement l’une des pannes les plus déstabilisantes parce qu’elle ne donne rien à quoi se raccrocher.

La bonne nouvelle : dans 95 % des cas, c’est récupérable sans réinstaller WordPress, sans perdre de contenu, et sans toucher à la base de données. Le problème vient quasi systématiquement d’un plugin, d’un thème ou d’une limite mémoire PHP franchie. Ce guide suit une progression logique : du diagnostic le plus rapide au plus technique.

Pourquoi un écran blanc apparaît

WordPress affiche une page blanche (et rien d’autre) quand PHP plante avant d’avoir pu envoyer la moindre réponse au navigateur. Sans erreur visible, parce que le mode debug est désactivé par défaut.

Les causes les plus fréquentes :

• Erreur PHP fatale : une fonction inexistante, un conflit de classe, une syntaxe incorrecte dans un fichier de thème ou de plugin.
• Mémoire PHP épuisée : le paramètre memory_limit est trop bas pour charger l’ensemble des fichiers. WordPress réclame au moins 64 Mo, souvent 128 Mo ou plus sur les sites avec beaucoup d’extensions.
• Plugin incompatible ou corrompu : après une mise à jour WordPress, un plugin peut appeler une fonction supprimée du cœur.
• Thème avec une erreur de code : modification manuelle d’un fichier functions.php, mise à jour partielle ou thème enfant mal configuré.
• Mise à jour WordPress interrompue : coupure réseau en pleine mise à jour, fichiers core partiellement remplacés.
• Fichier .htaccess corrompu : plus rare, mais provoque parfois un écran blanc côté front uniquement.

Solution 1 — Activer WP_DEBUG pour voir l’erreur

Avant de toucher quoi que ce soit, forcez WordPress à vous dire ce qui se passe. Connectez-vous en FTP (ou via le gestionnaire de fichiers de votre hébergeur) et ouvrez wp-config.php à la racine.

Trouvez la ligne :

define( 'WP_DEBUG', false );

Remplacez-la par :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

• WP_DEBUG : active le mode debug.
• WP_DEBUG_LOG : écrit les erreurs dans /wp-content/debug.log au lieu de les afficher à l’écran (ce qui évite d’exposer vos erreurs aux visiteurs).
• WP_DEBUG_DISPLAY false : n’affiche rien en front, mais consigne tout dans le log.

Rechargez votre site, puis consultez /wp-content/debug.log via FTP. Vous verrez quelque chose comme :

Fatal error: Uncaught Error: Call to undefined function get_field()
in /wp-content/plugins/mon-plugin/includes/class-mon-plugin.php on line 47

Le fichier et la ligne indiqués vous donnent la cause exacte. La suite du diagnostic dépend de ce que vous lisez.

Pensez à remettre WP_DEBUG à false dès que le problème est résolu — laisser le mode debug actif sur un site en production expose des informations sensibles.

Solution 2 — Désactiver tous les plugins par FTP

Si le log pointe vers un plugin (ou si vous n’avez pas accès à l’admin du tout), la méthode la plus rapide est la désactivation en masse via FTP, sans passer par le tableau de bord.

1. Connectez-vous en FTP et naviguez jusqu’à /wp-content/.
2. Renommez le dossier plugins en plugins_OFF (WordPress ne trouvera plus aucun plugin, ils seront tous désactivés d’un coup).
3. Rechargez votre site : s’il réapparaît, un plugin était responsable.
4. Renommez plugins_OFF en plugins pour les remettre en place.
5. Réactivez les plugins un par un depuis l’admin (qui est maintenant accessible), en rechargeant le site à chaque activation. Le WSOD revient ? Le dernier plugin activé est coupable.

Cette méthode est aussi efficace quand un plugin casse le site après une mise à jour — même logique, même chemin FTP.

Solution 3 — Passer au thème par défaut

Si la désactivation des plugins n’a rien changé, le thème actif est suspect. Même procédure par FTP :

1. Naviguez jusqu’à /wp-content/themes/.
2. Renommez le dossier de votre thème actif (ex : mon-theme → mon-theme_OFF).
3. WordPress va automatiquement chercher un thème de repli. S’il en trouve un (Twenty Twenty-Four, par exemple), il l’utilisera.
4. Si aucun thème de repli n’existe, WordPress retourne une erreur explicite — ce qui est déjà plus utile qu’une page blanche.

Si le site revient avec le thème par défaut, le problème est dans votre thème. Vérifiez en priorité le fichier functions.php : une modification récente (même minime) peut provoquer un WSOD immédiat si elle contient une erreur de syntaxe.

Solution 4 — Augmenter la limite mémoire PHP

Un WSOD déclenché par un memory_limit trop bas s’accompagne souvent d’un message dans le log du type :

Fatal error: Allowed memory size of 67108864 bytes exhausted

Trois endroits où vous pouvez relever cette limite :

Dans wp-config.php (méthode la plus simple, prioritaire) :

define( 'WP_MEMORY_LIMIT', '256M' );

Dans .htaccess (si votre hébergeur le permet) :

php_value memory_limit 256M

Dans php.ini (si vous avez accès au fichier) :

memory_limit = 256M

La valeur 256M est un point de départ raisonnable pour un site WordPress avec une dizaine de plugins actifs. Sur un site WooCommerce chargé ou avec un page builder lourd, montez à 512M.

Pour les autres directives PHP qui peuvent provoquer des comportements similaires :

Si vous êtes sur un hébergement mutualisé sans accès à php.ini, ces réglages passent souvent par le panneau de contrôle (cPanel, Plesk). Sur Plesk, l’accès SSH vous permettra aussi de diagnostiquer plus finement ce qui se passe côté serveur.

Solution 5 — Regénérer le fichier .htaccess

Un .htaccess corrompu peut provoquer un écran blanc uniquement en front-office (l’admin reste accessible). Solution rapide :

1. Via FTP, renommez .htaccess en .htaccess_OLD à la racine de WordPress.
2. Rechargez le site : si ça revient, le .htaccess était le problème.
3. Dans l’admin WordPress, allez dans Réglages > Permaliens et cliquez simplement sur Enregistrer les modifications — WordPress régénère un .htaccess propre.

Solution 6 — Vérifier les fichiers core WordPress

Si rien de ce qui précède ne fonctionne, une mise à jour interrompue a peut-être laissé des fichiers core corrompus. Téléchargez la même version de WordPress depuis wordpress.org, et remplacez manuellement via FTP les dossiers wp-admin et wp-includes — sans toucher à wp-content (vos thèmes, plugins et uploads sont là).

Ne remplacez pas wp-config.php ni les fichiers à la racine comme index.php ou .htaccess sans les avoir sauvegardés.

Récapitulatif : cause → solution

Quand passer la main à un pro

Si après toutes ces étapes l’écran blanc persiste — ou si vous n’avez tout simplement pas accès au FTP (prestataire injoignable, accès non communiqués) — le diagnostic devient plus complexe : erreur dans un fichier mu-plugin, conflit au niveau du serveur web, base de données partiellement corrompue. Ce sont des situations où gratter sans les bons outils fait plus de dégâts que le WSOD lui-même.

Dans ce cas précis, la priorité est de récupérer les accès avant tout. Le guide sur comment récupérer un site quand votre prestataire a disparu couvre exactement ce scénario. Et si vous n’avez jamais eu les accès FTP/hébergeur en main, l’article sur les 7 accès à exiger de votre agence vous évitera de vous retrouver bloqué la prochaine fois.