Corriger l’écran blanc WordPress en 5 étapes simples

Si votre site WordPress affiche soudainement une page blanche (ou une 500 sans message), vous n’êtes pas “maudit” : vous êtes face à une erreur PHP, un conflit, ou une limite serveur… et on peut presque toujours l’identifier en moins de 15 minutes.

Le problème

Le “WSOD” (White Screen of Death) désigne un écran blanc (ou une page vide) côté site public et/ou côté administration. Parfois, le serveur renvoie une erreur 500, parfois rien du tout.

Selon l’hébergeur, vous verrez l’un de ces messages (ou aucun) :

HTTP ERROR 500
Internal Server Error

There has been a critical error on this website.

Fatal error: Uncaught Error: Call to undefined function ...
Parse error: syntax error, unexpected '}' ...
Allowed memory size of X bytes exhausted ...

Où et quand ça apparaît :

Front-end : page blanche sur la page d’accueil, un article, ou uniquement certaines pages.
Admin (/wp-admin) : page blanche après connexion, ou sur une page précise (Extensions, Apparence, Elementor, Divi, etc.).
AJAX/REST : l’éditeur de blocs ne charge plus, Elementor reste sur “Loading…”, Divi Builder tourne dans le vide, erreurs dans la console.
CRON : tâches planifiées qui plantent (sauvegardes, envois d’e-mails) sans symptôme visible sauf dans les logs.

Circonstances typiques que je rencontre le plus :

Juste après une mise à jour (WordPress 6.9.4, un plugin, un thème, PHP).
Après activation d’un plugin “simple” (cache, sécurité, snippets, redirections).
Après avoir collé un code trouvé sur un forum dans functions.php.
Après migration (nouvel hébergeur, nouvelle version PHP, nouveaux droits fichiers).

À qui s’adresse ce guide : si vous débutez, vous allez apprendre à faire parler WordPress (activer les logs), isoler la cause (plugin/thème), corriger les cas les plus fréquents (mémoire, snippet cassé), et récupérer l’accès admin sans empirer la situation. Le tout sur WordPress 6.9.4 et PHP 8.1+.

Résumé rapide

Un WSOD est presque toujours un fatal PHP masqué (ou une 500 serveur). Il faut d’abord voir l’erreur.
Activez WP_DEBUG + WP_DEBUG_LOG et consultez wp-content/debug.log ou les logs de l’hébergeur.
Le diagnostic le plus rentable : désactiver tous les plugins puis réactiver un par un, puis tester un thème par défaut.
Beaucoup de WSOD viennent d’une limite mémoire ou d’un snippet cassé dans functions.php.
Pour récupérer l’admin : utilisez le mode récupération, un MU-plugin de secours, ou WP-CLI.

Les symptômes

Le WSOD n’est pas un seul bug. C’est un symptôme qui peut cacher plusieurs causes. Voici les signaux que vous pouvez observer.

Écran blanc complet (aucun HTML, parfois le titre de l’onglet est vide).
Erreur 500 côté navigateur, parfois uniquement sur certaines URLs.
Message “There has been a critical error…” (WordPress détecte un fatal et essaie de vous sauver via un e-mail).
Admin inaccessible mais le front fonctionne, ou l’inverse.
Éditeur de blocs qui charge à l’infini (souvent un fatal sur une route REST).
Elementor : écran blanc dans l’éditeur, ou “Preview could not be loaded”.
Divi 5 : le builder ne se lance pas, ou page vide après sauvegarde.
Avada : Fusion Builder qui n’affiche pas les éléments, ou page blanche en édition.
Console navigateur (F12) : erreurs du type 500 (Internal Server Error) sur /wp-json/ ou admin-ajax.php.
Logs serveur : erreurs PHP “Allowed memory size…”, “Call to undefined function…”, “Cannot redeclare…”, “Class not found…”.

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
Écran blanc partout (front + admin)	Fatal PHP global, plugin auto-load, erreur de thème	Activer logs + renommer `plugins`	Solution 1 + 2
Admin KO, front OK	Plugin d’admin, snippet lié à l’admin, mémoire sur pages lourdes	Tester /wp-admin + logs	Solution 2 + 3 + 5
Front KO, admin OK	Thème, cache, hook front, template	Changer de thème temporairement	Solution 2 + 4
Bloc editor / Elementor charge à l’infini	Fatal sur REST/AJAX, sécurité, cache agressif	Console + logs + tester `/wp-json/`	Solution 1 + 2 + “Si ça ne marche toujours pas”
Erreur “Allowed memory size…”	Limite mémoire PHP trop basse	Logs PHP / debug.log	Solution 3
Après collage d’un code	Erreur de syntaxe (;	Parse error dans logs	Solution 4

Pourquoi ça arrive

Version débutant : WordPress est du PHP. Si le PHP rencontre une erreur “fatale”, le serveur arrête d’exécuter la page. Selon votre configuration, l’erreur est affichée… ou masquée. Résultat : une page blanche.

Voici ce qui se passe en coulisses (version plus technique) : un plugin, un thème, ou un bout de code déclenche une exception non gérée, une erreur fatale, ou dépasse une limite (mémoire/temps). PHP stoppe l’exécution. WordPress n’a pas toujours le temps d’afficher une page d’erreur propre, surtout si l’erreur arrive tôt (au chargement des plugins, ou lors de l’initialisation du thème).

Causes classées du plus fréquent au plus rare

Plugin en conflit (cache, sécurité, builder, snippets) après mise à jour.
Thème ou thème enfant : functions.php cassé, template incompatible, fonction appelée trop tôt.
Limite mémoire PHP trop basse (site “lourd”, WooCommerce, Elementor, Divi, gros imports).
Incompatibilité PHP (site sur PHP 8.0 ou 7.4, ou code ancien non compatible PHP 8.1+).
Cache agressif (plugin, cache serveur, CDN) qui sert une réponse vide/500.
Fichiers corrompus après une mise à jour interrompue (FTP instable, espace disque plein).
Droits fichiers incorrects (lecture impossible, erreurs silencieuses selon serveur).
Règles de réécriture (permalinks) cassées : plus rare pour un WSOD total, mais fréquent pour des 404/500 sur certaines routes.

Prérequis avant de commencer

Sauvegarde : fichiers + base de données. Si vous n’avez pas d’outil, demandez à l’hébergeur un snapshot, ou exportez la DB via phpMyAdmin.
Ne modifiez jamais le cœur WordPress (wp-includes, wp-admin). On ne corrige pas un WSOD en “bidouillant” le core.
Accès : idéalement FTP/SFTP + accès au panneau d’hébergement (logs) + accès à la base (phpMyAdmin) si nécessaire.
Versions : WordPress 6.9.4 et PHP 8.1+ recommandés. Si vous êtes sur une version PHP plus ancienne, vous cumulez les risques.

Outils utiles (gratuits) :

Health Check & Troubleshooting (plugin officiel) pour tester sans impacter les visiteurs : Health Check & Troubleshooting.
Query Monitor pour afficher erreurs PHP, hooks, requêtes, REST : Query Monitor.
WP-CLI si votre hébergeur le propose (très efficace en WSOD) : WP-CLI.

Solution 1 : Activer le debug proprement et trouver l’erreur exacte

Un WSOD sans logs, c’est du tâtonnement. Votre objectif est simple : obtenir une ligne d’erreur exploitable (fichier + ligne).

Où agir : dans le fichier wp-config.php à la racine de WordPress (au même niveau que wp-content). Sauvegardez le fichier avant modification.

Avant (cassé / insuffisant)

J’ai souvent vu ce cas : un site en WSOD, et WP_DEBUG est absent ou mal configuré. Parfois, il est activé mais sans logs, donc vous ne voyez rien.

<?php
// wp-config.php (extrait) - configuration insuffisante
define('WP_DEBUG', false);

Après (corrigé : logs activés, affichage désactivé)

En production, je recommande de logger sans afficher à l’écran (évite d’exposer des chemins, versions, secrets). WordPress 6.9.4 supporte parfaitement ce set.

<?php
// wp-config.php (extrait)
// Sauvegardez avant de modifier. Ne laissez pas l'affichage d'erreurs en production.

define('WP_DEBUG', true);

// Écrit les erreurs dans wp-content/debug.log
define('WP_DEBUG_LOG', true);

// N'affiche pas les erreurs aux visiteurs (sécurité)
define('WP_DEBUG_DISPLAY', false);

// Désactive l'affichage PHP direct si le serveur le permet
@ini_set('display_errors', '0');

Pourquoi ça corrige le problème : vous ne “réparez” pas encore, mais vous obtenez enfin la cause réelle. Dans 80% des WSOD, la ligne d’erreur pointe directement le plugin/le thème/le fichier fautif.

Où lire l’erreur

Fichier WordPress : wp-content/debug.log
Logs serveur : “error_log” PHP dans le panneau d’hébergement (souvent plus complet)

Exemples d’erreurs utiles (réalistes) :

PHP Fatal error:  Uncaught Error: Call to undefined function my_custom_function()
in /home/site/public_html/wp-content/themes/mon-theme-enfant/functions.php:87

PHP Parse error: syntax error, unexpected token "else"
in /wp-content/plugins/mon-plugin/mon-plugin.php on line 214

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 4096 bytes)
in /wp-includes/class-wpdb.php on line ...

Explications simples (termes)

Fatal error : erreur bloquante. PHP stoppe tout.
Parse error : erreur de syntaxe (souvent un ; manquant, une accolade en trop, une parenthèse oubliée).
Uncaught Error : une erreur non gérée (fonction inexistante, classe non chargée, etc.).

Sources officielles :

Solution 2 : Isoler un conflit plugin/thème sans casser le site

Le conflit extension/thème est le cas n°1. Le piège : désactiver “au hasard” et empirer. Ici, on fait une isolation propre.

Deux méthodes : avec accès admin (Health Check) ou sans accès admin (FTP/SFTP).

Méthode A (recommandée si vous avez accès admin) : Health Check en mode dépannage

Où agir : dans l’admin, Extensions > Ajouter, installez “Health Check & Troubleshooting”.

Activez le mode dépannage : il désactive plugins/thème uniquement pour vous, pas pour les visiteurs.
Réactivez vos plugins un par un jusqu’à reproduire le WSOD.
Notez le plugin déclencheur, puis cherchez une mise à jour ou une alternative.

Source : Health Check & Troubleshooting

Méthode B (sans accès admin) : désactiver tous les plugins via FTP

Où agir : via FTP/SFTP, dans wp-content/.

Renommez le dossier plugins en plugins.off. WordPress désactive automatiquement toutes les extensions car il ne les trouve plus.

# Ce n'est pas une commande à exécuter sur votre PC.
# C'est l'idée : renommer le dossier via FTP/SFTP.
wp-content/plugins  ->  wp-content/plugins.off

Testez votre site :

Si le site revient : c’est bien un plugin. Remettez plugins.off en plugins, puis renommez les plugins un par un (ou utilisez WP-CLI, voir Solution 5).
Si le site reste blanc : passez au test du thème.

Tester le thème (sans admin)

Beaucoup de WSOD viennent d’un thème enfant (surtout après collage de snippets). Le test le plus rapide : forcer un thème par défaut.

Où agir :

Option 1 : renommer le dossier du thème actif dans wp-content/themes/ (WordPress basculera sur un autre thème disponible).
Option 2 (plus propre) : changer le thème via base de données (Solution 5, WP-CLI).

Astuce que j’utilise souvent : si vous avez un thème par défaut installé (ex. Twenty Twenty-Five / Twenty Twenty-Six selon votre installation), WordPress bascule automatiquement dessus quand le thème actif devient indisponible.

Compatibilité builders (Divi 5 / Elementor / Avada)

Elementor : un conflit avec un plugin de sécurité/caching peut casser wp-json et donner un écran blanc dans l’éditeur.
Divi 5 : j’ai vu des WSOD après minification agressive (JS/CSS) ou optimisation “tout-en-un”. Testez sans plugin de perf.
Avada : certaines options de performance + plugins de cache doublent la minification et créent des pages vides (surtout en édition).

Dans tous les cas : isolez d’abord en désactivant cache/sécurité/optimisation, puis testez le builder.

Source utile : FAQ Troubleshooting (WordPress.org)

Solution 3 : Augmenter la mémoire PHP et éviter le fatal “Allowed memory size…”

Quand vous voyez “Allowed memory size exhausted”, le WSOD est mécanique : PHP n’a plus de mémoire. Sur des sites avec Elementor/Divi/Avada + quelques plugins, c’est fréquent si l’hébergement est serré.

Où vérifier : dans wp-content/debug.log ou les logs PHP.

Avant (symptôme)

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)
in /wp-includes/class-wp-query.php on line ...

Après (corrigé côté WordPress, puis côté serveur si nécessaire)

Commencez par définir la mémoire WordPress. Ça ne contourne pas les limites serveur, mais ça règle beaucoup de cas.

Où agir : wp-config.php (sauvegardez avant).

<?php
// wp-config.php (extrait)
// Augmente la mémoire disponible pour WordPress.
// Si votre hébergeur impose une limite plus basse, cela ne suffira pas.

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

// Utile pour l'administration (imports, builders, mises à jour)
define('WP_MAX_MEMORY_LIMIT', '512M');

Si ça ne suffit pas, c’est que la limite est imposée par PHP côté serveur. Selon hébergeur :

Augmenter memory_limit dans le panneau d’hébergement (recommandé).
Modifier un php.ini / .user.ini si votre offre le permet.

Exemple (si votre hébergeur utilise .user.ini dans la racine du site) :

memory_limit = 512M
max_execution_time = 120

Pourquoi ça corrige : WordPress et vos plugins ont besoin d’un budget mémoire. Quand il est trop bas, des opérations comme la génération de CSS, l’édition builder, ou un gros WP_Query provoquent un crash.

Source PHP : memory_limit (php.net)

Solution 4 : Réparer un snippet cassé (functions.php) et le sécuriser

Le cas que je vois tout le temps : un snippet copié/collé dans functions.php du thème enfant, une virgule ou un point-virgule manque, et tout le site tombe.

Où agir : wp-content/themes/votre-theme-enfant/functions.php (ou le thème actif si vous n’avez pas de thème enfant). Travaillez via SFTP/FTP si l’admin est inaccessible.

Avant (cassé : erreur de syntaxe)

Exemple réaliste : un hook (action) ajouté, mais une parenthèse manque.

<?php
// functions.php (mauvais exemple)
// Objectif : ajouter un message dans le footer.
// Problème : parenthèse manquante => Parse error => WSOD

add_action('wp_footer', function () {
	echo '<p>Hello</p>';
};

Après (corrigé + plus robuste)

On corrige la syntaxe et on évite les “fonctions anonymes” si vous débutez (plus simple à relire). On ajoute aussi une condition pour ne pas exécuter en admin si non nécessaire.

<?php
// functions.php (exemple corrigé)
// Sauvegardez avant de modifier. Une erreur ici peut casser tout le site.

function bpcab_afficher_message_footer() : void {
	// Ne fait rien dans l'administration
	if ( is_admin() ) {
		return;
	}

	echo '<p>Hello</p>';
}

add_action( 'wp_footer', 'bpcab_afficher_message_footer', 10 );

Pourquoi ça corrige : une “Parse error” empêche PHP de charger le fichier. En corrigeant la syntaxe, WordPress peut à nouveau initialiser le thème.

Un autre classique : fonction appelée trop tôt (hook inadapté)

Définition rapide : un hook est un “point d’accroche” dans WordPress. Une action exécute du code à un moment donné. Un filtre modifie une valeur (et doit la retourner).

Erreur fréquente : appeler une fonction qui n’est pas encore disponible.

Avant (cassé)

<?php
// functions.php (mauvais exemple)
// Problème : wp_get_environment_type() est OK, mais certains codes appellent des fonctions
// de plugin avant que le plugin soit chargé (fatal "Call to undefined function").

ma_fonction_de_plugin_qui_n_est_pas_chargee();

Après (corrigé : attendre le bon moment)

<?php
// functions.php (exemple corrigé)
// On attend que tous les plugins soient chargés avant d'appeler une fonction de plugin.

function bpcab_appeler_fonction_plugin_apres_chargement() : void {
	if ( function_exists( 'ma_fonction_de_plugin_qui_n_est_pas_chargee' ) ) {
		ma_fonction_de_plugin_qui_n_est_pas_chargee();
	}
}

add_action( 'plugins_loaded', 'bpcab_appeler_fonction_plugin_apres_chargement', 10 );

Dans mon expérience, ce simple function_exists() évite beaucoup de WSOD après désactivation d’un plugin “par erreur”.

Source hooks : Hooks (developer.wordpress.org)

Solution 5 : Restaurer l’accès à l’admin en cas de fatal (recovery mode, MU-plugin, WP-CLI)

Quand l’admin est KO, vous avez besoin d’une “porte de service”. WordPress a un mode récupération, mais selon le type de fatal, il peut ne pas suffire. Je vous donne trois options, de la plus simple à la plus efficace.

Option A : le mode récupération WordPress (email “critical error”)

Si WordPress détecte un fatal, il peut envoyer un e-mail à l’adresse admin avec un lien de récupération. Ce lien permet d’entrer dans l’admin avec des plugins désactivés (selon le cas) pour corriger.

Si vous ne recevez pas l’e-mail :

Vérifiez le dossier spam.
Vérifiez que le site peut envoyer des mails (souvent bloqué sur certains hébergeurs).
Passez aux options B/C.

Source : Fatal errors & recovery (WordPress documentation)

Option B : créer un MU-plugin de secours (désactiver un plugin fautif)

Un MU-plugin (Must-Use) est un plugin chargé automatiquement depuis wp-content/mu-plugins/. Il est très utile en dépannage car il se charge tôt.

Où agir : créez le dossier wp-content/mu-plugins/ s’il n’existe pas, puis ajoutez un fichier wsod-rescue.php.

Exemple : désactiver automatiquement un plugin identifié dans les logs (remplacez le slug).

<?php
/**
 * Plugin Name: WSOD Rescue (dépannage)
 * Description: Désactive un plugin problématique pour récupérer l'accès. À supprimer après usage.
 */

// Sécurité : empêche l'accès direct
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

function bpcab_wsod_rescue_desactiver_plugin() : void {
	// Remplacez par le chemin du plugin (dossier/fichier principal)
	$plugin_cible = 'mon-plugin/mon-plugin.php';

	// On évite d'appeler des fonctions non chargées trop tôt
	if ( ! function_exists( 'is_plugin_active' ) ) {
		require_once ABSPATH . 'wp-admin/includes/plugin.php';
	}

	if ( function_exists( 'deactivate_plugins' ) ) {
		deactivate_plugins( array( $plugin_cible ), true );
	}
}

// admin_init est un bon compromis : l'admin charge, et les API plugins sont là.
add_action( 'admin_init', 'bpcab_wsod_rescue_desactiver_plugin' );

Pourquoi ça corrige : vous forcez la désactivation d’un plugin qui fait planter l’admin avant que vous puissiez cliquer quoi que ce soit.

Attention : supprimez ce MU-plugin après dépannage, sinon vous risquez d’oublier qu’il désactive encore quelque chose.

Option C : WP-CLI (la méthode la plus propre quand disponible)

Si votre hébergeur propose WP-CLI, vous pouvez désactiver un plugin ou changer de thème sans charger l’interface web.

Où agir : terminal SSH (ou outil “Terminal” dans le panel).

# Vérifier que WP-CLI voit l'installation
wp core version

# Désactiver tous les plugins (diagnostic)
wp plugin deactivate --all

# Réactiver un plugin à la fois
wp plugin activate query-monitor

# Changer de thème (remplacez par un thème installé)
wp theme activate twentytwentyfive

Dans mon expérience, WP-CLI vous fait gagner un temps énorme quand le WSOD empêche toute page de charger.

Vérifications après correction

Front-end : chargez la page d’accueil + 2-3 pages internes + une page “lourde” (contact, boutique, landing builder).
Admin : allez sur Extensions, Apparence, et la page du builder (Elementor/Divi/Avada) si vous l’utilisez.
REST API : testez https://votre-site.tld/wp-json/. Vous devez obtenir du JSON, pas une 500.
Console navigateur : F12 > Console + Réseau, vérifiez l’absence de 500 sur wp-json et admin-ajax.php.
Logs : relisez wp-content/debug.log. Des “warnings” peuvent rester, mais vous ne devez plus avoir de “Fatal error”.

Une fois stable, pensez à remettre une configuration de debug adaptée :

Gardez WP_DEBUG_LOG si vous surveillez, mais évitez d’accumuler un fichier énorme (rotation côté serveur).
Ne laissez pas WP_DEBUG_DISPLAY à true sur un site public.

Si ça ne marche toujours pas

Quand les 5 solutions ci-dessus ne suffisent pas, le problème est souvent côté serveur, ou c’est un enchaînement de causes (cache + plugin + PHP). Voici une procédure que j’applique sur site client.

Videz tous les caches :
- Cache plugin (WP Rocket, LiteSpeed Cache, etc.).
- Cache serveur (Varnish, Nginx fastcgi_cache, LiteSpeed) via le panel hébergeur.
- CDN (Cloudflare) : purge.
- Cache navigateur : test en navigation privée.
Confirmez la version PHP : passez en PHP 8.1, 8.2 ou 8.3 selon support de l’hébergeur. Un code ancien peut casser en PHP 8.1+ ; un code moderne peut refuser PHP trop ancien.
Regardez les logs serveur (pas seulement debug.log) : parfois l’erreur est un segfault, un timeout, ou un module manquant.
Testez sans .htaccess (Apache) :
- Renommez .htaccess en .htaccess.off (temporairement).
- Si le site revient, régénérez les permaliens ensuite (Admin > Réglages > Permaliens > Enregistrer).
Désactivez l’optimisation JS/CSS (minification, combine, defer) : j’ai vu des pages “blanches” qui étaient en réalité du HTML chargé, mais un JS critique cassé empêchait l’affichage du builder.
Vérifiez les droits fichiers :
- Dossiers : souvent 755
- Fichiers : souvent 644
Les valeurs exactes dépendent de l’hébergeur, mais un dossier en 000 ou un propriétaire incorrect peut créer des comportements bizarres.
Réinstallez le core WordPress (sans toucher wp-content) si vous suspectez des fichiers corrompus :
- Téléchargez WordPress depuis wordpress.org/download.
- Remplacez wp-admin et wp-includes + fichiers racine (sauf wp-config.php et wp-content).
Utilisez Query Monitor dès que le site redevient accessible : vous verrez les erreurs, appels REST, hooks, et souvent le plugin responsable.

Si vous avez un WSOD uniquement sur une URL précise, regardez aussi :

Un shortcode qui appelle une fonction inexistante.
Un template de page (builder) qui déclenche une requête énorme.
Une boucle infinie (redirection) masquée par un cache/CDN.

Pièges et erreurs courantes

Symptôme	Cause probable	Erreur courante observée	Solution recommandée
WSOD juste après avoir collé un snippet	Parse error	Code collé dans le mauvais fichier (plugin vs thème), ou `;` oublié	Solution 4 (corriger syntaxe via FTP)
WSOD après mise à jour plugin	Conflit / incompatibilité	Réactiver “tout” d’un coup sans isoler	Solution 2 (désactiver tout, réactiver 1 par 1)
Admin KO, front OK	Mémoire / plugin admin	Tester uniquement la home et croire que “c’est réglé”	Solution 3 + vérifs admin
Elementor/Divi ne charge plus	REST/AJAX en 500	Oublier la console navigateur et les requêtes réseau	Solution 1 + vérifier `/wp-json/`
WSOD aléatoire	Cache/CDN, timeout, ressources	Ne pas purger Cloudflare / cache serveur	Procédure “Si ça ne marche toujours pas”
WSOD après “optimisation”	Minification trop agressive	Activer combine+defer partout sans exclusions	Désactiver optimisation JS/CSS, puis réactiver progressivement
WSOD après changement de PHP	Code ancien incompatible PHP 8.1+	Suivre un tutoriel de 2018 avec fonctions/approches obsolètes	Mettre à jour plugins/thème, corriger code, rester sur PHP 8.1+

Variante / alternative

Méthode sans code : plugin de gestion de snippets (et rollback)

Si vous ajoutez souvent du code, évitez de le coller dans functions.php. Utilisez plutôt un plugin de snippets qui permet de désactiver un snippet sans casser le thème. Beaucoup de WSOD viennent d’un thème enfant modifié en production.

Je ne vous impose pas un plugin précis, mais cherchez des fonctionnalités :

Activation/désactivation snippet unitaire
Exécution conditionnelle (front/admin)
Historique / rollback

Méthode plus avancée : surveiller les fatals et les régressions

Pour les sites pro, mettez en place :

Un environnement de staging (préproduction) et un workflow de déploiement.
Une surveillance des erreurs (logs centralisés, alertes).
Des tests de base après mise à jour (front + admin + checkout si e-commerce).

Éviter ce problème à l’avenir

Vous ne supprimerez jamais 100% des risques, mais vous pouvez réduire drastiquement les WSOD.

1) Faites vos changements dans un plugin “custom” (pas dans le thème)

Un thème change. Un plugin custom reste. Pour des snippets métiers, je préfère un mini-plugin.

Où agir : créez wp-content/plugins/mon-site-custom/mon-site-custom.php, puis activez-le.

<?php
/**
 * Plugin Name: Mon site - Custom
 * Description: Snippets stables du site (WordPress 6.9.4+, PHP 8.1+).
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

add_action( 'init', function () : void {
	// Exemple : point d'entrée sûr (init) pour vos personnalisations.
} );

2) Utilisez des garde-fous (function_exists, class_exists)

Si votre code dépend d’un plugin (Elementor, WooCommerce…), protégez l’appel. Ça évite un WSOD si le plugin est désactivé.

<?php
// Exemple de garde-fou
if ( class_exists( 'WooCommerce' ) ) {
	// Code WooCommerce ici
}

3) Mettez à jour intelligemment

Faites les mises à jour sur staging, puis en production.
Évitez de mettre à jour 15 plugins d’un coup sans point de restauration.
Surveillez les changelogs des plugins critiques (cache, sécurité, builder).

4) Gardez un budget serveur réaliste

PHP 8.1+ (idéalement 8.2/8.3 selon hébergeur et compatibilité)
memory_limit adapté (souvent 256M minimum, 512M confortable pour builders)
Stockage suffisant (une mise à jour interrompue par disque plein, je l’ai déjà vu plusieurs fois)

Ressources

Questions fréquentes

Mon site est blanc, mais seulement pour moi. Pourquoi ?

Souvent un cache (navigateur/CDN) ou un problème de session/cookies. Testez en navigation privée, puis purgez cache plugin + CDN. Vérifiez aussi si vous êtes connecté : certaines erreurs ne se déclenchent que pour les admins (barre d’admin, modules d’édition).

Je n’ai pas de fichier debug.log, c’est normal ?

Oui, si aucune erreur n’est loggée, ou si wp-content n’est pas inscriptible. Vérifiez les droits, et consultez les logs PHP côté hébergeur (souvent plus fiables).

Est-ce que je peux laisser WP_DEBUG activé en permanence ?

Vous pouvez laisser WP_DEBUG à true si vous n’affichez pas les erreurs à l’écran (WP_DEBUG_DISPLAY à false) et si vous gérez les logs. Sur un site public, afficher les erreurs est un risque de sécurité.

Pourquoi un plugin de cache peut provoquer un WSOD ?

Parce qu’il peut minifier/combiner des scripts critiques, ou servir une réponse mise en cache vide/incorrecte. Sur des builders (Divi 5, Elementor, Avada), une optimisation trop agressive casse souvent l’éditeur avant de casser le front.

J’ai désactivé tous les plugins, mais c’est toujours blanc. Et maintenant ?

Testez le thème (Solution 2), puis la mémoire (Solution 3), puis renommez temporairement .htaccess (Apache). Si rien ne bouge, regardez les logs serveur : vous êtes probablement sur un problème PHP/serveur (timeout, module manquant, fichier corrompu).

Est-ce que renommer le dossier plugins peut casser mon site ?

Ça désactive tout, donc certaines fonctionnalités disparaissent (formulaires, SEO, cache). Mais c’est réversible et très efficace pour récupérer l’accès. Renommez simplement plugins.off en plugins ensuite.

Que faire si le WSOD arrive après une mise à jour WordPress 6.9.4 ?

C’est rarement WordPress “seul”. Cherchez d’abord une extension incompatible, puis un thème. Activez les logs (Solution 1) : l’erreur pointe presque toujours vers wp-content/plugins/... ou wp-content/themes/....

Elementor affiche blanc, mais le site public est OK. Où regarder ?

Regardez la console (F12) et l’onglet Réseau : si /wp-json/ ou une requête AJAX renvoie 500, c’est un fatal côté serveur. Activez les logs et désactivez temporairement sécurité/cache.

Divi 5 ne se lance plus après optimisation. Je fais quoi en premier ?

Désactivez minification/combine/defer, purgez tous les caches, puis testez. Ensuite, réactivez l’optimisation progressivement avec exclusions. Les WSOD “visuels” de builder sont souvent des JS cassés, pas un vrai HTML vide.

Quand faut-il contacter l’hébergeur ?

Dès que vous suspectez une limite serveur (mémoire/CPU), un module manquant, un WAF qui bloque, ou si les logs montrent des erreurs sans rapport avec WordPress. Donnez-leur l’heure exacte et l’extrait de log : ça accélère énormément.