Écran blanc WordPress : 5 correctifs faciles

par | WordPress

Si votre site WordPress affiche soudainement une page entièrement blanche, sans message, vous n’êtes pas “maudit” : vous êtes juste face à une erreur fatale que WordPress n’arrive pas à afficher proprement.

Le problème

Le “WSOD” (White Screen of Death, écran blanc) ressemble à une absence totale de contenu. Parfois, vous avez un équivalent côté serveur, par exemple une erreur 500, ou un message minimal du type :

HTTP ERROR 500

Ou, si l’hébergement affiche les erreurs PHP (rare en production), quelque chose comme :

Fatal error: Uncaught Error: Call to undefined function ... in /home/.../wp-content/themes/.../functions.php:123

Où et quand ça apparaît :

  • Front-end : page d’accueil blanche, ou seulement certaines pages (souvent une page avec un shortcode, un widget, un template spécifique).
  • Admin (/wp-admin) : écran blanc au login, tableau de bord inaccessible, ou écran blanc sur une page précise (Extensions, Apparence, Éditeur…).
  • Cron / tâches planifiées : le site “marche” mais certaines actions (emails, imports) cessent, et vous trouvez des erreurs dans les logs.
  • REST API / AJAX : Elementor/Divi/Avada n’arrivent plus à charger l’éditeur, les requêtes XHR échouent, ou l’aperçu ne se charge pas.

Circonstances typiques que je vois le plus :

  • Juste après une mise à jour (WordPress 6.9.4, un plugin, un thème, un builder).
  • Après l’ajout d’un snippet dans functions.php ou via un plugin de snippets.
  • Après l’activation d’un plugin “lourd” (cache, sécurité, builder, e-commerce).
  • Après un changement côté serveur (version PHP, module OPcache, limites mémoire).

À qui ça s’adresse : si vous débutez, mais que vous pouvez accéder à votre FTP/gestionnaire de fichiers (ou au moins à l’admin), vous allez pouvoir diagnostiquer proprement et remettre le site en ligne. À la fin, vous saurez retrouver l’erreur exacte, isoler le coupable (plugin/thème/snippet), et éviter les faux écrans blancs liés au cache.

Résumé rapide

  • Ne devinez pas : activez le debug et lisez l’erreur (Solution 1).
  • Isoler : désactivez tous les plugins et repassez sur un thème par défaut (Solution 2).
  • Vérifiez la mémoire : beaucoup de WSOD viennent d’un Allowed memory size exhausted (Solution 3).
  • Snippets : un point-virgule manquant dans functions.php suffit à tout blanchir (Solution 4).
  • Cache : vous pouvez “corriger” le site sans le voir si OPcache/CDN sert l’ancienne version (Solution 5).

Les symptômes

Un WSOD n’est pas toujours “juste une page blanche”. Voici les signaux concrets à repérer (et ce qu’ils suggèrent).

  • Page blanche totale (front) mais /wp-admin fonctionne : souvent un problème dans le thème, un template, un shortcode, ou un cache de page corrompu.
  • /wp-admin blanc aussi : plus souvent une erreur fatale PHP (plugin, thème, snippet) ou une limite mémoire.
  • Erreur 500 dans le navigateur : souvent une erreur PHP fatale, une config serveur, ou un module (OPcache) qui sert du code obsolète.
  • Éditeur Elementor/Divi/Avada qui ne charge plus : erreurs REST API/AJAX, mémoire, conflit plugin (sécurité/caching), ou erreurs JS masquées.
  • Le site marche en local mais pas en production : différences de version PHP, extensions PHP, limites mémoire, cache serveur, permissions fichiers.
  • Seulement certaines pages : shortcode cassé, requête trop lourde, boucle infinie, ou image/ressource qui fait exploser la mémoire.

Diagnostic rapide côté navigateur : ouvrez la console (F12) et regardez :

  • Console : erreurs JavaScript (utile surtout pour les builders).
  • Network : requêtes XHR vers /wp-json/ (REST API) ou admin-ajax.php en 500/403.

Pourquoi ça arrive

Explication simple (débutant)

WordPress exécute du code PHP (thèmes + plugins). Si PHP rencontre une erreur fatale, l’exécution s’arrête net. Selon la configuration de votre serveur, l’erreur peut être cachée (sécurité), et vous ne voyez qu’un écran blanc.

Le WSOD est donc rarement “mystique”. C’est presque toujours :

  • un bug de code (plugin/thème/snippet),
  • un manque de ressources (mémoire/temps),
  • ou un cache qui vous montre une version cassée alors que vous avez corrigé.

Explication technique (intermédiaire/pro)

En coulisses, l’erreur se produit souvent pendant le chargement des hooks WordPress. Un hook est un point d’extension : une action exécute du code à un moment donné, un filtre modifie une valeur (ex : le contenu) avant qu’elle ne soit utilisée.

Les causes (du plus fréquent au plus rare), avec ce que j’observe en dépannage WordPress 6.9.4 :

  • Plugin incompatible PHP 8.1+ (ou bug après mise à jour).
  • Thème / thème enfant : code dans functions.php, template, ou surcharge WooCommerce.
  • Snippet copié d’un vieux tutoriel (fonction obsolète, hook incorrect, ou code exécuté trop tôt).
  • Mémoire PHP insuffisante (builders + WooCommerce + plugins de sécurité = combo classique).
  • Cache serveur (OPcache) / CDN qui sert une version non mise à jour.
  • Permissions (plus rare pour un vrai WSOD, mais peut provoquer des erreurs 500).

Pour vous aider à trier, voici un tableau de diagnostic “symptôme → vérification → solution”.

Symptôme Cause probable Vérification Solution
Écran blanc partout Erreur fatale PHP Activer WP_DEBUG + lire debug.log Solution 1 + 2
Erreur 500 Fatal PHP / limite mémoire / cache serveur Logs serveur + debug.log Solution 1 + 3 + 5
Admin OK, front blanc Thème / shortcode / cache de page Changer temporairement de thème + vider cache Solution 2 + 5
Elementor/Divi n’ouvre plus l’éditeur REST/AJAX en erreur, mémoire Console + Network (XHR 500/403) Solution 3 + “Si ça ne marche toujours pas”
WSOD après ajout d’un snippet Syntax error / hook trop tôt Dernier fichier modifié, logs Solution 4

Prérequis avant de commencer

Sauvegardez avant de modifier quoi que ce soit. Si vous devez intervenir sur des fichiers, faites au minimum une copie de :

  • wp-config.php
  • le dossier wp-content (ou au moins themes et plugins)

Pré-requis techniques recommandés (WordPress 6.9.4 en avril 2026) :

  • PHP 8.1+ (minimum recommandé). Si vous êtes en dessous, vous augmentez fortement le risque de bugs et failles.
  • Accès à FTP/SFTP ou au gestionnaire de fichiers de l’hébergeur.
  • Idéalement un staging (site de test). Beaucoup d’hébergeurs le proposent en 1 clic.

Outils utiles (gratuits) :

Règle d’or : ne modifiez jamais le core (les fichiers de WordPress dans wp-includes / wp-admin). On corrige dans un plugin, un thème enfant, ou la configuration.

Solution 1 : Activer le debug proprement (et retrouver l’erreur exacte)

Un écran blanc sans erreur visible vous force à deviner. Le but ici est d’obtenir un message exploitable dans un fichier log.

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

Sauvegardez avant de modifier. Une faute de frappe dans wp-config.php peut rendre le site indisponible.

AVANT (configuration typique qui cache tout)

Beaucoup de sites n’ont rien, ou ont un debug incomplet :

<?php
// ... contenu existant ...

/* C'est tout : aucune trace d'erreur exploitable. */

APRÈS (debug orienté dépannage, sans afficher aux visiteurs)

Ajoutez (ou ajustez) ces constantes. Placez-les avant la ligne /* That's all, stop editing! */ si elle existe dans votre fichier.

<?php
// ... contenu existant ...

/**
 * Debug WordPress (WordPress 6.9.4+ / PHP 8.1+)
 * Objectif : écrire les erreurs dans wp-content/debug.log sans les afficher aux visiteurs.
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Évite d'afficher des erreurs PHP directement dans le HTML.
@ini_set( 'display_errors', '0' );

Ensuite :

  1. Rechargez la page blanche (front ou admin).
  2. Ouvrez wp-content/debug.log et cherchez la dernière erreur.

Exemples d’erreurs que vous pouvez voir :

PHP Fatal error:  Uncaught Error: Call to undefined function my_plugin_helper() in /wp-content/plugins/mon-plugin/mon-plugin.php:88
PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wpdb.php on line ...

Pourquoi ça corrige le problème : parfois, le “WSOD” n’est pas corrigé par cette étape, mais vous récupérez l’information qui permet une correction rapide (plugin précis, fichier précis, ligne précise). Sans ça, vous perdez du temps.

Quand vous avez fini : remettez WP_DEBUG à false sur un site en production. Garder le log actif peut exposer des chemins serveur et informations sensibles si le fichier est mal protégé.

Source officielle : Debug WordPress

Solution 2 : Isoler un conflit plugin/thème (méthode débutant + méthode “sans accès admin”)

Dans mon expérience, le WSOD vient très souvent d’un plugin mis à jour (ou d’un builder) qui déclenche une erreur fatale. L’objectif : revenir à une configuration minimale, puis réactiver un par un.

Méthode A (débutant) : depuis l’admin si vous y avez accès

  1. Allez dans Extensions > Extensions installées.
  2. Sélectionnez tout, puis Désactiver.
  3. Testez le site.
  4. Réactivez une extension à la fois jusqu’à reproduire le WSOD.

Ensuite, passez temporairement sur un thème standard :

  • Apparence > Thèmes &gt activez un thème officiel (souvent un Twenty*).
  • Testez à nouveau.

Si vous utilisez Divi 5, Elementor ou Avada : ces thèmes/builders ajoutent beaucoup de code. Un conflit avec un plugin de cache/sécurité est courant. Le test “thème standard + plugins désactivés” est le moyen le plus rapide d’arrêter de tourner en rond.

Méthode B (sans accès admin) : via FTP/SFTP

Si /wp-admin est blanc, passez par FTP/SFTP.

Étape 1 : désactiver tous les plugins d’un coup

Où intervenir : renommez le dossier wp-content/plugins en plugins.off. WordPress considérera les plugins comme absents et les désactivera.

# Exemple (le nom exact dépend de votre outil FTP)
wp-content/plugins  →  wp-content/plugins.off

Testez le site. Si ça revient, vous avez confirmé “plugin(s) en cause”. Remettez ensuite :

wp-content/plugins.off  →  wp-content/plugins

Puis, à l’intérieur de plugins, renommez les dossiers un par un (ex : elementor → elementor.off) pour trouver le coupable.

Étape 2 : forcer un thème de secours si le thème plante

Si le site est toujours blanc avec les plugins off, le thème (ou thème enfant) est suspect.

Option simple : renommez le dossier du thème actif (ou du thème enfant). WordPress basculera sur un autre thème disponible.

wp-content/themes/mon-theme-enfant  →  wp-content/themes/mon-theme-enfant.off

Pourquoi ça corrige : vous stoppez le chargement du code qui plante. Une erreur fatale dans un plugin/thème empêche WordPress d’aller plus loin.

Si vous voulez une référence officielle sur le dépannage : FAQ Troubleshooting (WordPress.org)

Solution 3 : Corriger un plantage par manque de mémoire (PHP/WordPress)

Le manque de mémoire est un grand classique sur des sites avec Elementor/Divi/Avada + WooCommerce + plugins de sécurité/cache. Le symptôme est parfois un WSOD, parfois une erreur 500, parfois un éditeur qui refuse de charger.

Le message typique dans debug.log :

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate ...)

Étape 1 : augmenter la mémoire côté WordPress (rapide)

Où intervenir : dans wp-config.php, avant “stop editing”.

AVANT (pas de limite explicite)

<?php
// ...

APRÈS (demande à WordPress d’utiliser plus de mémoire)

<?php
// ...

/**
 * Augmente la mémoire pour WordPress.
 * Attention : si PHP a une limite plus basse, cela ne suffira pas.
 */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Utile pour l'admin et certaines tâches lourdes.

Pourquoi ça marche : WP_MEMORY_LIMIT indique à WordPress la mémoire cible. Mais si votre serveur impose une limite inférieure, WordPress ne pourra pas la dépasser.

Étape 2 : augmenter la mémoire côté PHP (souvent indispensable)

Selon votre hébergeur, cela se fait via :

  • le panneau d’hébergement (recommandé),
  • un fichier php.ini ou .user.ini,
  • ou la configuration PHP-FPM (si vous administrez le serveur).

Exemple (fichier .user.ini sur beaucoup d’hébergements mutualisés) :

memory_limit = 512M
max_execution_time = 120

Référence officielle PHP (memory_limit) : php.net memory_limit

Ce que je teste après avoir augmenté la mémoire

  • Chargement de la page blanche.
  • Ouverture de l’éditeur (Elementor/Divi/Avada).
  • Si WooCommerce : ajout au panier, checkout, et une page produit.

Si le site redevient accessible mais reste lent, vous avez peut-être une requête qui explose (Query Monitor aide beaucoup).

Solution 4 : Réparer un snippet cassé (functions.php / plugin de snippets) sans tout casser

Le scénario le plus frustrant : vous ajoutez 10 lignes de code “pour améliorer WordPress”, vous sauvegardez… et tout devient blanc. J’ai souvent vu ça sur des sites où le code est collé dans le mauvais fichier, ou avec une parenthèse manquante.

Termes :

  • Snippet : petit bout de code ajouté au thème (souvent functions.php) ou via un plugin.
  • Erreur de syntaxe : PHP n’arrive pas à lire le fichier (point-virgule oublié, accolade en trop…). C’est fatal.

Cas A : le code a été ajouté dans functions.php (thème enfant)

Où intervenir : wp-content/themes/VOTRE-THEME-ENFANT/functions.php

Erreur très réaliste : oublier un point-virgule, ou fermer une accolade.

AVANT (cassé : point-virgule manquant)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' )
}

APRÈS (corrigé)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' );
}

Pourquoi ça corrige : PHP exige le point-virgule pour terminer l’instruction. Sans ça, il déclenche une erreur de parse et WordPress ne peut plus charger.

Cas B : le code utilise un hook trop tôt (fonction “pas encore chargée”)

Autre cas que je croise : un tutoriel ancien vous fait appeler une fonction qui n’existe pas encore au moment où votre code s’exécute.

AVANT (cassé : exécution immédiate trop tôt)

<?php
// Mauvaise idée : ce code s'exécute dès le chargement du fichier.
ma_fonction_qui_depend_de_wordpress();

function ma_fonction_qui_depend_de_wordpress() {
	// Exemple : vous faites des appels à des APIs WordPress non disponibles à cet instant
	update_option( 'test', 'ok' );
}

APRÈS (corrigé : exécution via une action)

<?php
/**
 * On utilise une action pour attendre que WordPress soit chargé.
 * Une "action" est un hook qui déclenche votre code à un moment précis.
 */
add_action( 'init', 'ma_fonction_qui_depend_de_wordpress' );

function ma_fonction_qui_depend_de_wordpress() {
	update_option( 'test', 'ok' );
}

Pourquoi ça corrige : init s’exécute après le chargement de WordPress. Vous évitez des appels prématurés.

Cas C : snippet via un plugin (WPCode, Code Snippets, etc.)

Si vous utilisez un plugin de snippets, l’avantage est qu’il peut parfois désactiver automatiquement un snippet fatal. Mais si l’admin est inaccessible, désactivez le plugin de snippets via FTP (Solution 2), puis corrigez le snippet.

Référence (hooks) : developer.wordpress.org/plugins/hooks

Solution 5 : Éliminer un faux WSOD causé par le cache (page cache, CDN, OPcache)

Celui-ci piège beaucoup de débutants : vous corrigez le bug, mais vous voyez encore l’écran blanc. En réalité, un cache sert une version cassée.

Je vois ça souvent sur :

  • sites derrière Cloudflare (ou autre CDN),
  • hébergeurs avec cache serveur agressif,
  • sites avec OPcache activé et mal invalidé après déploiement.

Étape 1 : vider les caches “visibles”

  • Videz le cache de votre plugin (LiteSpeed Cache, WP Rocket, W3TC…).
  • Videz le cache CDN (Cloudflare : “Purge Everything” ou purge ciblée).
  • Testez en navigation privée + en ajoutant un paramètre : ?nocache=1

Étape 2 : OPcache (côté serveur)

Si vous avez un accès serveur, le plus efficace est de redémarrer PHP-FPM (selon votre stack). Exemple (Linux) :

sudo systemctl reload php8.2-fpm

Si vous êtes en mutualisé, vous n’aurez pas cette commande. Dans ce cas :

  • cherchez une option “vider OPcache” dans le panel,
  • ou demandez au support de purger OPcache (c’est souvent une demande standard).

Pourquoi ça corrige : OPcache peut conserver en mémoire une ancienne version d’un fichier PHP. Vous corrigez le fichier… mais PHP exécute encore l’ancienne version.

Référence officielle OPcache : php.net OPcache

Vérifications après correction

Une fois le site revenu, je fais toujours les mêmes tests “basiques mais efficaces” :

  1. Front : page d’accueil + 2-3 pages internes + recherche.
  2. Admin : tableau de bord, Extensions, Apparence, Éditeur (si utilisé).
  3. Builders :
    • Elementor : ouvrir l’éditeur + sauvegarder une modification.
    • Divi 5 : ouvrir Visual Builder + vérifier l’aperçu responsive.
    • Avada : ouvrir Fusion Builder + vérifier l’édition d’un conteneur.
  4. Formulaires : soumettre un formulaire (contact/newsletter).
  5. REST API : test rapide en visitant /wp-json/ (vous devez voir du JSON, pas une page blanche).

Ensuite :

  • Relisez wp-content/debug.log : s’il continue de grossir, vous avez encore des erreurs (même si le site “marche”).
  • Désactivez le debug si vous l’avez activé en production (Solution 1).

Si ça ne marche toujours pas

Quand les 5 solutions “débutant” ne suffisent pas, je passe sur une procédure plus systématique. Elle reste accessible, mais demande un peu de méthode.

1) Vérifiez les logs serveur (souvent plus parlants que debug.log)

Sur beaucoup d’hébergeurs, vous avez un “error log” Apache/Nginx dans le panel. Cherchez :

  • PHP Fatal error
  • Premature end of script headers
  • Allowed memory size

2) Utilisez Health Check (mode dépannage)

Si vous avez accès à l’admin, le plugin Health Check permet de désactiver plugins/thème uniquement pour vous, sans impacter les visiteurs. C’est très pratique sur un site en production.

Plugin : Health Check & Troubleshooting

3) Vérifiez la version PHP réelle

Un site peut “croire” être en PHP 8.1, mais un sous-domaine ou un cron tourne en 7.4 (je l’ai déjà vu). Vérifiez dans :

  • Outils > Santé du site
  • ou le panel de l’hébergeur

4) Désactivez temporairement les mu-plugins

Les mu-plugins (must-use plugins) sont chargés automatiquement depuis wp-content/mu-plugins. Ils sont invisibles dans la liste des extensions classiques. Certains hébergeurs y mettent des caches/sécurités.

Test : renommez mu-plugins en mu-plugins.off via FTP, puis testez.

5) Permaliens / rewrite rules (cas “admin OK, pages 404/500”)

Ce n’est pas le WSOD le plus pur, mais ça se mélange souvent après une migration ou un plugin. Allez dans :

Réglages > Permaliens puis cliquez Enregistrer (sans rien changer).

Doc officielle : WP-CLI (pour les pros) (utile si vous avez un accès SSH, mais optionnel ici).

6) Vérifiez les permissions fichiers (rare, mais réel)

Des permissions trop strictes peuvent provoquer des erreurs serveur. En mutualisé Linux, on voit souvent :

  • Dossiers : 755
  • Fichiers : 644

Si votre hébergeur a des recommandations différentes, suivez-les.

Pièges et erreurs courantes

Symptôme Cause probable Solution recommandée
Vous avez activé WP_DEBUG mais debug.log n’apparaît pas wp-content non inscriptible / mauvaise config / erreur avant chargement Vérifiez permissions, puis regardez les logs serveur
WSOD juste après avoir collé un code Point-virgule/accolade manquant, code collé au mauvais endroit Solution 4 (corriger le snippet), idéalement dans un plugin custom
Ça marche en navigation privée mais pas “normalement” Cache navigateur / plugin / CDN Solution 5 (purges) + désactiver minification temporairement
Elementor/Divi/Avada n’ouvre plus l’éditeur Mémoire, REST/AJAX bloqué par sécurité, conflit plugin Solution 3 + vérifier console + désactiver plugin de sécurité
Vous avez suivi un vieux tuto Code incompatible WordPress 6.9.4 / PHP 8.1 Remplacer par une approche via hooks actuels, tester en staging
Vous avez modifié le thème parent Perte des modifications à la mise à jour, risque de casse Revenir en thème enfant, ou plugin custom (voir section “Éviter”)
Le WSOD revient après “correction” OPcache/CDN sert encore l’ancienne version Solution 5 (purge + reload PHP-FPM si possible)

Erreurs “humaines” que je vois le plus :

  • Coller un snippet dans un mauvais fichier (ex : dans un template au lieu de functions.php).
  • Oublier une parenthèse ou un point-virgule.
  • Confondre action et filtre (ex : utiliser add_action au lieu de add_filter).
  • Tester directement sur production sans sauvegarde.
  • Oublier de vider le cache après correction.

Variante / alternative

Méthode sans code (recommandée si vous débutez)

Si vous pouvez accéder à l’admin, installez :

C’est la voie la plus “safe” sur un site en ligne : vous investiguez sans casser l’expérience des visiteurs.

Méthode plus avancée (développeurs) : mu-plugin de secours

Si vous dépannez souvent (ou si vous gérez plusieurs sites), vous pouvez créer un mu-plugin (chargé automatiquement) pour forcer un log minimal et éviter l’affichage d’erreurs.

Où coller le code : créez le fichier wp-content/mu-plugins/00-rescue.php (créez le dossier s’il n’existe pas).

<?php
/**
 * Plugin Name: Rescue minimal
 * Description: Aide au dépannage : loggue des infos minimales si le site plante tôt.
 * Author: Votre Nom
 *
 * Attention : ceci ne remplace pas WP_DEBUG. C'est un filet de sécurité.
 */

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

// Exemple : log simple pour confirmer que WordPress charge bien les mu-plugins.
error_log( '[Rescue] mu-plugin chargé' );

Risques : écrire trop dans les logs peut les saturer. Gardez ce fichier minimal, et supprimez-le après dépannage.

Référence officielle sur les mu-plugins : developer.wordpress.org/advanced-administration/plugins/mu-plugins

Éviter ce problème à l’avenir

Les WSOD reviennent quand on corrige “à l’arrache” sans changer les habitudes. Voici ce qui réduit réellement le risque.

1) Faites vos modifications dans un plugin custom, pas dans functions.php

Pour des snippets réutilisables, je préfère un petit plugin “maison”. Avantage : vous pouvez le désactiver en 1 clic, sans toucher au thème.

Où coller le code : créez wp-content/plugins/mon-plugin-custom/mon-plugin-custom.php, puis activez-le.

<?php
/**
 * Plugin Name: Mon plugin custom
 * Description: Snippets stables pour ce site (WordPress 6.9.4+ / PHP 8.1+).
 * Version: 1.0.0
 */

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

/**
 * Exemple : on accroche un code sur une action.
 */
add_action( 'init', function () {
	// Code sûr : exécuté après le chargement de WordPress.
} );

2) Mettez en place un staging

Testez les mises à jour (WordPress, plugins, thèmes, builders) sur un staging. C’est la différence entre “5 minutes de stress” et “2 heures de panique”.

3) Surveillez la compatibilité PHP 8.1+

Un plugin non maintenu peut casser après une montée de version PHP. Vérifiez la compatibilité sur la page du plugin (wordpress.org) et gardez un œil sur les changelogs.

4) Gardez un accès de secours

  • Accès SFTP/FTP fonctionnel
  • Accès au panel hébergeur (logs, version PHP, cache)
  • Une sauvegarde quotidienne (idéalement externe)

5) Cache : documentez votre “chemin de purge”

Sur les sites avec CDN + cache plugin + cache serveur, notez noir sur blanc où purger. Sinon, vous allez “corriger” sans voir la correction.

Ressources

Questions fréquentes

Le WSOD vient-il forcément d’un plugin ?

Non. Un thème, un thème enfant, un snippet, un manque de mémoire, ou un cache serveur peuvent produire exactement le même symptôme. La méthode la plus rapide reste : debug.log + désactivation en masse (Solution 1 + 2).

Pourquoi je n’ai aucun message d’erreur ?

Parce que la plupart des serveurs masquent les erreurs PHP en production. C’est normal (sécurité). Activez un log via WP_DEBUG_LOG pour récupérer l’erreur sans l’afficher aux visiteurs.

Est-ce que je peux corriger ça sans FTP ?

Oui si vous avez accès à l’admin : Health Check + désactivation des plugins suffit souvent. Sans admin, l’accès fichiers (FTP/SFTP) est le chemin le plus direct.

Mon site est blanc seulement sur une page, pas partout. Pourquoi ?

Cette page déclenche probablement un code spécifique : shortcode, widget, template, requête lourde, ou contenu qui explose la mémoire. Activez le debug, puis rechargez précisément cette page pour obtenir une trace exploitable.

Elementor affiche un écran blanc dans l’éditeur : c’est pareil ?

Souvent oui, mais le problème peut être côté REST API/AJAX. Regardez l’onglet Network : si les requêtes vers /wp-json/ ou admin-ajax.php renvoient 500, cherchez une erreur PHP (Solution 1) ou un manque de mémoire (Solution 3).

Après avoir corrigé, je vois encore l’écran blanc. Je fais quoi ?

Pensez cache : navigation privée, purge plugin, purge CDN, et si possible purge OPcache (Solution 5). C’est un piège très fréquent.

Est-ce dangereux d’activer WP_DEBUG sur un site en production ?

Si vous affichez les erreurs à l’écran, oui (vous pouvez exposer des infos sensibles). Si vous logguez uniquement (WP_DEBUG_DISPLAY à false), le risque est surtout de générer un gros fichier log. Désactivez-le après dépannage.

Je dois modifier quel fichier : functions.php, wp-config.php, ou .htaccess ?

Pour diagnostiquer : wp-config.php (Solution 1). Pour corriger un snippet : functions.php du thème enfant, ou mieux un plugin custom (Solution 4 / “Éviter”). .htaccess est plutôt pour des soucis de réécriture/permalinks, pas pour la majorité des WSOD.

Le site revient quand je désactive un plugin, mais j’en ai besoin. Que faire ?

Notez l’erreur exacte (fichier/ligne) et mettez à jour le plugin, puis contactez l’éditeur avec la trace. En attendant, cherchez une alternative, ou désactivez uniquement la fonctionnalité qui déclenche l’erreur (souvent cache/minification/sécurité).

Articles connexes

Envoyer Un Commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.