
WordPress Page Blanche : Solutions pour le WSOD
La page blanche WordPress, connue sous le nom de White Screen of Death (WSOD), est l'une des erreurs les plus frustrantes pour les proprietaires de sites. L'ecran est completement blanc, sans message d'erreur, sans indication de la cause. Le site est inaccessible et le tableau de bord peut l'etre aussi.
Ce guide vous accompagne dans le diagnostic systematique et la resolution de chaque cause possible de la page blanche WordPress. Des solutions simples aux interventions avancees par FTP, chaque etape est detaillee pour vous permettre de recuperer votre site.
Comprendre la Page Blanche WordPress (WSOD)
Qu'est-ce que le WSOD ?
Le WSOD se manifeste par un ecran entierement blanc lorsque vous tentez d'acceder a votre site ou a son tableau de bord WordPress. Contrairement a une erreur 500 qui affiche un message du serveur, le WSOD ne montre strictement rien. C'est le resultat d'une erreur fatale PHP que WordPress ne parvient pas a gerer.
Le WSOD peut affecter :
- Le front-end uniquement : le site public est blanc mais
/wp-adminfonctionne. - Le back-end uniquement : le tableau de bord est blanc mais le site fonctionne.
- Les deux : aucune page ne s'affiche, front-end et back-end sont blancs.
Pourquoi la Page Blanche WordPress se Produit-elle ?
Le WSOD est toujours cause par une erreur PHP fatale qui interrompt l'execution du script. En production, l'affichage des erreurs est desactive (display_errors = Off), ce qui produit une page blanche au lieu d'un message d'erreur explicite.
Les causes les plus frequentes :
| Cause | Frequence | Diagnostic |
|---|---|---|
| Conflit de plugin | 40 % | Survient apres activation/mise a jour d'un plugin |
| Erreur de theme | 25 % | Survient apres changement/mise a jour de theme |
| Epuisement memoire PHP | 20 % | Le site ralentit progressivement avant le WSOD |
| Fichiers core corrompus | 8 % | Survient apres une mise a jour interrompue |
| Incompatibilite PHP | 5 % | Survient apres changement de version PHP |
| Erreur base de donnees | 2 % | Message "Error establishing database connection" parfois visible |
Impact de la Page Blanche sur Votre Site
Une page blanche WordPress ne se limite pas a un desagrement visuel. Les consequences sont multiples :
- Perte de trafic : chaque minute d'indisponibilite eloigne vos visiteurs.
- Impact SEO : si Googlebot rencontre un WSOD, votre site risque une desindexation temporaire et une chute de positionnement.
- Perte de revenus : pour un site e-commerce ou un site generant des leads, l'impact financier est immediat.
- Degradation de la confiance : les utilisateurs qui tombent sur une page blanche ne reviennent pas toujours.
Agir rapidement est donc essentiel. Suivez les etapes ci-dessous dans l'ordre pour identifier et corriger la cause.
Etape 1 : Activer le Mode Debug WordPress
Le mode debug est la premiere etape diagnostique cruciale. Il transforme un symptome generique (la page blanche) en une erreur PHP specifique et tracable. Sans cette information, vous avancez a l'aveugle.
Via wp-config.php (Acces FTP)
Connectez-vous a votre serveur par FTP ou SFTP et editez le fichier wp-config.php a la racine de votre installation WordPress.
<?php
// Remplacer ces lignes dans wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Avec cette configuration :
WP_DEBUGactive le mode debug.WP_DEBUG_LOGecrit les erreurs dans le fichierwp-content/debug.log. Ce fichier est la source d'information principale pour le diagnostic et sera votre guide pour les etapes suivantes.WP_DEBUG_DISPLAYreste surfalsepour eviter d'afficher les erreurs aux visiteurs. Laisser cette valeur atrueen production expose des informations sensibles (chemins serveur, noms de fichiers) et peut creer des failles de securite.
Via WP-CLI (Acces SSH)
# Activer le debug
wp config set WP_DEBUG true --raw --path=/var/www/html
wp config set WP_DEBUG_LOG true --raw --path=/var/www/html
wp config set WP_DEBUG_DISPLAY false --raw --path=/var/www/html
# Consulter le log d'erreurs
tail -50 /var/www/html/wp-content/debug.logLire le Log d'Erreurs
Apres avoir active le debug, rechargez la page blanche. Consultez ensuite le fichier wp-content/debug.log :
# Voir les dernieres erreurs
tail -100 /var/www/html/wp-content/debug.log
# Chercher les erreurs fatales
grep -i "fatal" /var/www/html/wp-content/debug.logExemples de messages d'erreur courants :
PHP Fatal error: Allowed memory size of 67108864 bytes exhausted
PHP Fatal error: Uncaught Error: Call to undefined function
PHP Fatal error: Cannot redeclare function_name()
PHP Parse error: syntax error, unexpected '}' in /path/to/file.php
Chaque message pointe vers une cause specifique. La suite de ce guide traite chaque cause individuellement.
Etape 2 : Resoudre l'Epuisement de la Memoire PHP
Symptomes
Le message d'erreur dans debug.log contient Allowed memory size of X bytes exhausted. C'est l'une des causes les plus courantes de la page blanche WordPress.
Solution Immediate : Augmenter la Limite Memoire
Avant toute modification, il est imperatif de realiser une sauvegarde complete de votre site (fichiers et base de donnees). Tentez les solutions dans cet ordre de preference :
1. Via wp-config.php (controle direct, methode recommandee) :
<?php
// Dans wp-config.php
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');WP_MEMORY_LIMIT gere la memoire allouee au front-end (pages publiques), tandis que WP_MAX_MEMORY_LIMIT controle la memoire pour l'interface d'administration (/wp-admin), qui necessite generalement plus de ressources.
2. Via .htaccess (si wp-config.php ne suffit pas ou est ignore par le serveur) :
# Dans .htaccess
php_value memory_limit 256M3. Via php.ini (necessite souvent un acces serveur ou une demande a l'hebergeur) :
; Dans php.ini ou .user.ini
memory_limit = 256M# Via WP-CLI
wp config set WP_MEMORY_LIMIT '256M' --path=/var/www/html
wp config set WP_MAX_MEMORY_LIMIT '512M' --path=/var/www/htmlSolution Long Terme
L'augmentation de la memoire est un palliatif. La cause racine est generalement :
- Un plugin mal optimise qui consomme trop de memoire. Identifiez-le avec le plugin Query Monitor qui affiche la consommation memoire par plugin.
- Trop de plugins actifs : chaque plugin charge du code PHP a chaque requete. Realisez un audit regulier pour supprimer les plugins inutilises ou redondants.
- Un theme lourd avec des fonctionnalites integrees excessives. Envisagez un theme plus leger ou optimisez le theme actuel via des outils de performance.
- Un hebergement sous-dimensionne pour votre trafic. Verifiez les metriques de ressources dans le tableau de bord de votre hebergeur et envisagez une mise a niveau si necessaire.
Etape 3 : Diagnostiquer un Conflit de Plugin
Les conflits de plugins sont la cause numero un du WSOD WordPress. Un plugin peut entrer en conflit avec un autre plugin, avec le theme actif, ou avec la version PHP du serveur.
Avant de proceder, consultez le fichier debug.log. Souvent, le log peut directement nommer le fichier ou le dossier du plugin fautif, ce qui permet de cibler la desactivation sans tout reinitialiser. Pensez aussi a sauvegarder votre site avant toute manipulation.
Methode 1 : Desactiver Tous les Plugins via FTP
Si le tableau de bord est inaccessible, desactivez tous les plugins en renommant leur dossier :
# Via FTP ou SSH : renommer le dossier plugins
mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_backupSi le site revient, c'est confirme : un plugin est en cause.
# Recreer le dossier plugins
mv /var/www/html/wp-content/plugins_backup /var/www/html/wp-content/pluginsMethode 2 : Desactiver les Plugins via WP-CLI
# Desactiver tous les plugins
wp plugin deactivate --all --path=/var/www/html
# Verifier si le site fonctionne, puis reactiver un par un
# Remplacez "akismet" par le slug de chaque plugin a tester
wp plugin activate akismet --path=/var/www/html
wp plugin activate woocommerce --path=/var/www/html
# ... continuer jusqu'a identifier le plugin problematiqueMethode 3 : Desactiver via la Base de Donnees
Si ni FTP ni WP-CLI ne sont disponibles, desactivez les plugins via phpMyAdmin, Adminer ou tout autre outil de gestion de base de donnees :
-- Sauvegarder d'abord la valeur actuelle
SELECT option_value FROM wp_options WHERE option_name = 'active_plugins';
-- Desactiver tous les plugins
UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';Identifier le Plugin Fautif
Apres avoir desactive tous les plugins, reactivez-les un par un en verifiant le site entre chaque activation. Le plugin qui provoque le retour de la page blanche est le coupable.
Actions possibles :
- Verifiez si une mise a jour du plugin est disponible.
- Contactez le developpeur du plugin pour signaler le bug.
- Cherchez un plugin alternatif offrant la meme fonctionnalite.
- Verifiez la compatibilite avec votre version de PHP.
Etape 4 : Resoudre une Erreur de Theme
Symptomes
La page blanche WordPress apparait apres :
- L'activation d'un nouveau theme.
- La mise a jour du theme actif.
- La modification du fichier
functions.phpdu theme.
Solution : Basculer vers un Theme par Defaut
# Via WP-CLI
wp theme activate twentytwentyfour --path=/var/www/html
# Ou via FTP : renommer le dossier du theme actif
mv /var/www/html/wp-content/themes/mon-theme /var/www/html/wp-content/themes/mon-theme_backupWordPress basculera automatiquement vers un theme par defaut si le theme actif n'est plus trouvable.
Via la Base de Donnees
-- Changer le theme actif en base de donnees
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';Corriger une Erreur dans functions.php
Si le WSOD est cause par une modification recente du fichier functions.php :
# Voir les dernieres modifications
ls -la /var/www/html/wp-content/themes/mon-theme/functions.php
# Editer le fichier pour retirer le code problematique
# Utilisez un editeur de texte via FTP/SSH
nano /var/www/html/wp-content/themes/mon-theme/functions.phpCauses frequentes dans functions.php :
- Erreur de syntaxe (accolade manquante, point-virgule oublie).
- Fonction deja declaree dans un plugin (conflit de noms).
- Appel a une fonction qui n'existe plus apres mise a jour.
- Code copie-colle avec des caracteres invisibles (guillemets typographiques).
Etape 5 : Verifier le Fichier .htaccess
Le fichier .htaccess est souvent neglige lors du diagnostic de la page blanche WordPress, mais une erreur dans ce fichier peut provoquer un WSOD ou une erreur 500.
Diagnostic
# Renommer temporairement le fichier .htaccess
mv /var/www/html/.htaccess /var/www/html/.htaccess_backupSi le site revient apres avoir renomme le fichier, le .htaccess est en cause.
Regenerer le .htaccess
# Via WP-CLI : regenerer les regles de reecriture
wp rewrite flush --path=/var/www/htmlOu manuellement, creez un nouveau fichier .htaccess avec le contenu par defaut de WordPress :
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressEtape 6 : Reparer les Fichiers Core Corrompus
Symptomes
Le WSOD survient apres une mise a jour interrompue ou un transfert de fichiers incomplet. Les fichiers core de WordPress sont endommages ou manquants. Ce probleme peut aussi etre lie a une erreur 504 Gateway Timeout si la mise a jour a expire.
Verification de l'Integrite
# Verifier l'integrite des fichiers core via WP-CLI
wp core verify-checksums --path=/var/www/htmlCette commande compare chaque fichier core avec les versions officielles de WordPress.org et signale toute difference.
Reinstallation du Core
# Reinstaller les fichiers core sans toucher a wp-content
wp core download --force --skip-content --path=/var/www/html
# Verifier apres reinstallation
wp core verify-checksums --path=/var/www/htmlReinstallation Manuelle via FTP
Si WP-CLI n'est pas disponible :
- Telechargez la meme version de WordPress depuis wordpress.org.
- Decompressez l'archive.
- Uploadez tous les fichiers sauf le dossier
wp-contentet le fichierwp-config.php. - Ecrasez les fichiers existants.
Etape 7 : Resoudre les Problemes de Version PHP
Symptomes
La page blanche WordPress apparait apres un changement de version PHP sur le serveur. Des fonctions depreciees ou supprimees provoquent des erreurs fatales.
Diagnostic
# Verifier la version PHP actuelle
php -v
# Verifier les erreurs liees a la version PHP
grep -i "deprecated\|removed\|undefined function" /var/www/html/wp-content/debug.logSolutions
Retrograder temporairement la version PHP :
La plupart des hebergeurs permettent de changer la version PHP depuis le panneau de controle (cPanel, Plesk). Revenez a la version precedente pour restaurer le site.
Mettre a jour les plugins et themes :
# Mettre a jour tout pour la compatibilite avec la nouvelle version PHP
wp plugin update --all --path=/var/www/html
wp theme update --all --path=/var/www/html
wp core update --path=/var/www/htmlCompatibilite PHP recommandee :
| Version WordPress | PHP minimum | PHP recommande |
|---|---|---|
| WordPress 6.5+ | PHP 7.4 | PHP 8.2 - 8.3 |
| WordPress 6.3-6.4 | PHP 7.4 | PHP 8.1 - 8.2 |
| WordPress 6.0-6.2 | PHP 7.4 | PHP 8.0 - 8.1 |
Etape 8 : Diagnostiquer les Erreurs de Base de Donnees
Symptomes
Le message "Error establishing a database connection" peut apparaitre a la place de la page blanche, ou le WSOD peut etre cause par des tables corrompues.
Verification de la Connexion
# Tester la connexion a la base de donnees
wp db check --path=/var/www/htmlReparation de la Base de Donnees
<?php
// Ajouter temporairement dans wp-config.php
define('WP_ALLOW_REPAIR', true);Accedez ensuite a votre-site.com/wp-admin/maint/repair.php pour lancer la reparation.
# Ou via WP-CLI
wp db repair --path=/var/www/html
# Optimiser la base de donnees
wp db optimize --path=/var/www/htmlN'oubliez pas de retirer la constante WP_ALLOW_REPAIR apres la reparation, car cette page n'est pas protegee par authentification.
Verifier les Identifiants de Connexion
# Verifier les parametres de connexion dans wp-config.php
grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST" /var/www/html/wp-config.phpRecuperation via FTP Quand le Dashboard est Inaccessible
Quand ni le site ni le tableau de bord WordPress ne sont accessibles, le client FTP (ou SFTP) est votre outil de secours.
Procedure Complete de Recuperation
# 1. Se connecter via FTP/SFTP au serveur
# 2. Activer le debug pour identifier l'erreur
# Editer wp-config.php et ajouter :
# define('WP_DEBUG', true);
# define('WP_DEBUG_LOG', true);
# 3. Verifier le log d'erreurs
# Telecharger wp-content/debug.log
# 4. Si l'erreur pointe vers un plugin :
# Renommer wp-content/plugins en wp-content/plugins_off
# 5. Si l'erreur pointe vers le theme :
# Renommer wp-content/themes/mon-theme en mon-theme_off
# 6. Si les fichiers core sont corrompus :
# Telecharger WordPress depuis wordpress.org
# Uploader tous les fichiers SAUF wp-content et wp-config.php
# 7. Tester le site
# 8. Desactiver le debug une fois le probleme resoluAcces d'Urgence via le Fichier PHP de Secours
Si toutes les methodes echouent, creez un fichier PHP de diagnostic :
<?php
// emergency-check.php - a placer a la racine du site
// SUPPRIMER IMMEDIATEMENT APRES UTILISATION
echo "<h1>Diagnostic WordPress</h1>";
// Verifier PHP
echo "<h2>PHP</h2>";
echo "Version : " . phpversion() . "<br>";
echo "Memoire : " . ini_get('memory_limit') . "<br>";
echo "Extensions : " . implode(', ', get_loaded_extensions()) . "<br>";
// Verifier la connexion DB
echo "<h2>Base de donnees</h2>";
$config = file_get_contents('wp-config.php');
preg_match("/define.*DB_HOST.*'(.+?)'/", $config, $host);
preg_match("/define.*DB_NAME.*'(.+?)'/", $config, $name);
preg_match("/define.*DB_USER.*'(.+?)'/", $config, $user);
preg_match("/define.*DB_PASSWORD.*'(.+?)'/", $config, $pass);
$conn = @mysqli_connect($host[1], $user[1], $pass[1], $name[1]);
if ($conn) {
echo "Connexion : OK<br>";
echo "Version MySQL : " . mysqli_get_server_info($conn) . "<br>";
mysqli_close($conn);
} else {
echo "Connexion : ECHEC - " . mysqli_connect_error() . "<br>";
}
// Verifier les fichiers critiques
echo "<h2>Fichiers</h2>";
$files = ['wp-config.php', 'wp-load.php', 'wp-blog-header.php', 'wp-settings.php'];
foreach ($files as $f) {
echo $f . " : " . (file_exists($f) ? "OK (" . filesize($f) . " bytes)" : "MANQUANT") . "<br>";
}Supprimez ce fichier immediatement apres utilisation car il expose des informations sensibles.
Prevention : Eviter la Page Blanche WordPress
Maintenance Reguliere
- Testez sur un staging avant de mettre a jour en production.
- Sauvegardez avant chaque intervention (base de donnees + fichiers). Notre guide de maintenance WordPress detaille les bonnes pratiques de sauvegarde.
- Mettez a jour regulierement : les mises a jour mineures sont rarement problematiques.
Plugins et Themes Fiables
- Limitez le nombre de plugins : chaque plugin ajoute une surface d'attaque et des bugs potentiels.
- Choisissez des plugins de qualite : verifiez la date de derniere mise a jour, le nombre d'installations, la compatibilite avec votre version PHP.
- Utilisez un theme enfant pour les personnalisations : les modifications du theme parent seront ecrasees a la prochaine mise a jour.
Surveillance des Performances et du Serveur
- Verifiez les metriques serveur : memoire PHP, utilisation CPU et espace disque via le tableau de bord de votre hebergeur.
- Configurez un monitoring pour etre alerte immediatement en cas de page blanche.
# Script de monitoring basique
#!/bin/bash
SITE_URL="https://votre-site.com"
ALERT_EMAIL="admin@votre-site.com"
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" $SITE_URL)
if [ "$HTTP_CODE" != "200" ]; then
echo "ALERTE : $SITE_URL retourne HTTP $HTTP_CODE" | mail -s "Site down" $ALERT_EMAIL
fiPlanifiez ce script en cron toutes les 5 minutes pour etre alerte rapidement en cas de WSOD.
Gerer Correctement les Mises a Jour
- Ne jamais interrompre une mise a jour WordPress en cours.
- Desactivez les mises a jour automatiques pour les plugins critiques et mettez-les a jour manuellement apres verification sur un staging.
- Verifiez la compatibilite avant de changer la version PHP de votre hebergement.
FAQ
Comment trouver quel plugin est responsable de la page blanche ?
Consultez d'abord le fichier wp-content/debug.log : il contient generalement le chemin exact du fichier fautif. Si le log n'est pas assez precis, desactivez tous les plugins (via FTP ou WP-CLI), puis reactivez-les un par un en rechargeant le site a chaque activation. Le plugin qui fait revenir la page blanche est le responsable.
La page blanche WordPress peut-elle impacter mon referencement SEO ?
Oui. Si Googlebot rencontre un WSOD lors du crawl, votre page est interpretee comme une erreur serveur. Si le probleme persiste, Google peut desindexer les pages concernees et votre classement chute. De plus, un site inaccessible degrade l'experience utilisateur, un signal negatif pour le SEO. Corrigez la page blanche le plus rapidement possible.
Que faire si je n'ai pas de sauvegarde recente de mon site WordPress ?
Sans sauvegarde, vous pouvez toujours intervenir par les methodes de ce guide (debug, desactivation de plugins, basculement de theme). Si les fichiers core sont corrompus, une reinstallation via wp core download --force --skip-content remplace le core sans toucher a vos contenus (dossier wp-content). Pour la base de donnees, contactez votre hebergeur : certains conservent des sauvegardes automatiques sur 7 a 30 jours.
Est-il dangereux d'activer le mode debug sur un site en production ?
Le mode debug lui-meme n'est pas dangereux si vous configurez WP_DEBUG_DISPLAY a false. Avec cette valeur, les erreurs sont ecrites dans le fichier debug.log mais ne sont jamais affichees aux visiteurs. Le risque survient uniquement si vous laissez WP_DEBUG_DISPLAY a true, ce qui expose des chemins de fichiers et des informations techniques. Desactivez toujours le debug apres le diagnostic.
Quelle est la difference entre le WSOD et l'erreur 500 ?
L'erreur 500 affiche un message du serveur ("Internal Server Error"), tandis que le WSOD affiche un ecran completement blanc. Les causes sont souvent similaires (erreurs PHP), mais l'erreur 500 apparait quand le serveur intercepte l'erreur, alors que le WSOD survient quand PHP echoue silencieusement avec l'affichage des erreurs desactive. Pour les solutions a l'erreur 500, consultez notre guide dedie.
Retrouvez un Site Fonctionnel
La page blanche WordPress est intimidante mais rarement irreversible. En suivant la methodologie de diagnostic presentee dans ce guide, de l'activation du debug a la verification systematique des plugins, du theme, de la memoire PHP et des fichiers core, vous identifierez et resoudrez la cause dans la grande majorite des cas.
Pour un diagnostic professionnel et une resolution rapide, notre equipe intervient sur les cas les plus complexes. Consultez aussi notre guide sur les bugs WordPress les plus courants et nos solutions pour l'erreur 500 pour couvrir d'autres scenarios de depannage.
