Vous tapez l’adresse de votre site, la page charge, et rien. Pas de message, pas de menu, pas d’erreur. Juste un écran entièrement vide, comme si votre site n’avait jamais existé. Vous rafraîchissez, vous testez sur votre téléphone, vous videz le cache du navigateur : toujours ce vide. Cette panne porte un nom chez les habitués, le White Screen of Death, et elle paralyse chaque jour des milliers de sites.

Face à une WordPress page blanche, la démarche efficace tient en quatre étapes : activer l’affichage des erreurs avec WP_DEBUG, lire le journal d’erreurs PHP du serveur, augmenter la limite de mémoire, puis désactiver les extensions et le thème par FTP si le tableau de bord est inaccessible. Dans la grande majorité des cas, la cause est une erreur PHP fatale provoquée par une extension, un thème ou un manque de mémoire, et le site revient sans perte de données. Ce guide déroule chaque solution dans l’ordre, avec les commandes exactes.

Pourquoi WordPress affiche une page blanche

Une page blanche n’est pas un bug mystérieux, c’est une erreur PHP fatale dont l’affichage est masqué. Quand PHP rencontre un problème bloquant (fonction inexistante, mémoire épuisée, incompatibilité de version), il interrompt la génération de la page. Et comme la configuration de production cache les messages d’erreur aux visiteurs, ce qui est une bonne pratique de sécurité, il ne reste rien à afficher : un document vide, souvent accompagné d’un code HTTP 500 invisible à l’œil nu.

Les déclencheurs les plus fréquents, constatés sur des années de dépannage :

  • une extension qui vient d’être installée ou mise à jour et qui entre en conflit ;
  • un thème incompatible avec la version de PHP ou de WordPress ;
  • une limite de mémoire PHP atteinte, typique des petits hébergements mutualisés ;
  • une mise à jour interrompue qui laisse des fichiers à moitié remplacés ;
  • une montée de version PHP côté hébergeur qui casse du code ancien.

Avant toute manipulation, testez aussi une page d’administration : si /wp-admin répond alors que la partie publique est blanche, le coupable est presque toujours le thème. Si tout est blanc, cherchez côté extensions ou mémoire.

Étape 1 : activer WP_DEBUG pour voir l’erreur cachée

Impossible de réparer ce qu’on ne voit pas. La première action consiste à demander à WordPress d’écrire les erreurs dans un fichier journal, sans les exposer aux visiteurs. Éditez wp-config.php à la racine du site, par FTP ou via le gestionnaire de fichiers de votre hébergeur, et remplacez la ligne define( 'WP_DEBUG', false ); par :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Rechargez la page blanche une fois, puis ouvrez le fichier wp-content/debug.log. La dernière ligne contient presque toujours la réponse, par exemple :

PHP Fatal error: Uncaught Error: Call to undefined function get_field()
in /home/site/public_html/wp-content/themes/montheme/single.php:42

Ici, le chemin désigne le fichier fautif : un thème qui appelle une fonction d’une extension désactivée. Le journal vous dit quoi désactiver ou corriger. Pour une méthode plus détaillée, notre guide pour activer le mode debug WordPress couvre aussi le débogage des requêtes et des scripts.

Étape 2 : lire le journal d’erreurs du serveur

Si debug.log reste vide, l’erreur se produit avant que WordPress ne charge sa configuration. Le journal PHP du serveur prend alors le relais. Sur un hébergement cPanel, ouvrez l’outil Erreurs, ou cherchez un fichier error_log à la racine et dans wp-admin. En ligne de commande :

tail -n 20 ~/public_html/error_log

Les mentions Fatal error, Allowed memory size exhausted ou Parse error orientent immédiatement le diagnostic. Notez le fichier et la ligne indiqués : c’est votre cible pour la suite. Une erreur dans un fichier du cœur de WordPress après une mise à jour suggère des fichiers corrompus, on y revient plus bas.

Étape 3 : augmenter la mémoire PHP

Le message Allowed memory size of 134217728 bytes exhausted signifie que PHP a épuisé ses 128 Mo. WordPress recommande d’augmenter la limite dans wp-config.php, au-dessus de la ligne qui mentionne « Happy publishing » :

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

Si cela ne suffit pas, la limite est peut-être imposée plus haut. Créez ou éditez le fichier .user.ini à la racine, ou la section PHP de votre panneau d’hébergement :

memory_limit = 256M

Une consommation mémoire anormale reste un symptôme : si le site exigeait 512 Mo du jour au lendemain, une extension boucle probablement. L’augmentation débloque le site, le journal d’erreurs identifie le responsable.

Étape 4 : désactiver toutes les extensions sans wp-admin

Tableau de bord inaccessible ? Les extensions se désactivent aussi par FTP. Renommez simplement le dossier qui les contient :

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

Rechargez le site. S’il revient, une extension est en cause. Restaurez le nom plugins, puis renommez les extensions une par une (par exemple woocommerce en woocommerce-off) en testant à chaque fois, en commençant par celles installées ou mises à jour récemment. WordPress désactive automatiquement une extension dont le dossier disparaît, sans toucher à ses réglages.

Avec WP-CLI, disponible chez la plupart des hébergeurs, le même test prend dix secondes :

wp plugin deactivate --all
wp plugin activate nom-extension

Étape 5 : basculer sur un thème par défaut

Si les extensions sont hors de cause, testez le thème. Par FTP, renommez le dossier de votre thème actif dans wp-content/themes : WordPress bascule alors sur un thème par défaut comme Twenty Twenty-Five, à condition qu’il soit présent. Sinon, installez-en un en téléversant son dossier. En WP-CLI :

wp theme activate twentytwentyfive

Site revenu ? Le thème contient du code incompatible, souvent après une montée de version PHP. Contactez son auteur ou faites corriger le fichier incriminé, que l’étape 1 vous a déjà désigné.

Page blanche après une mise à jour ou une migration

Une mise à jour interrompue laisse parfois le site dans un état hybride : une partie des fichiers en nouvelle version, l’autre en ancienne. Le remède consiste à réinstaller proprement le cœur de WordPress, sans toucher à wp-content ni à la base de données :

wp core download --skip-content --force

Sans WP-CLI, téléchargez WordPress depuis le site officiel, supprimez les dossiers wp-admin et wp-includes du serveur, puis téléversez les versions fraîches ainsi que les fichiers de la racine, en préservant wp-config.php et wp-content. Après une migration, vérifiez aussi que la version PHP du nouveau serveur correspond à l’ancienne : un site qui tournait en PHP 7.4 peut casser en PHP 8.3. Ce scénario justifie à lui seul une sauvegarde complète avant chaque mise à jour.

wp-admin blanc mais site visible, ou l’inverse

Une page blanche limitée à l’administration pointe vers une extension qui ne s’exécute que dans le tableau de bord, ou vers un fichier functions.php du thème qui bloque une fonction d’admin. Le test des extensions de l’étape 4 s’applique tel quel. À l’inverse, un site public blanc avec une administration fonctionnelle désigne le thème ou le cache. Profitez d’un wp-admin accessible pour activer un thème par défaut depuis Apparence, c’est le même diagnostic sans FTP.

Si l’écran affiche « Une erreur critique est survenue sur ce site » plutôt qu’un vide total, le mécanisme de récupération de WordPress a pris le relais : suivez alors notre guide dédié à l’erreur critique WordPress, qui exploite l’email de récupération envoyé à l’administrateur.

Le cache qui sert une page blanche aux visiteurs

Dernier cas vicieux : le problème d’origine est corrigé, mais votre serveur de cache a mémorisé la page vide et continue de la servir. Les visiteurs voient un site blanc alors que vous le voyez réparé, ou l’inverse. Purgez systématiquement toutes les couches après réparation : extension de cache (LiteSpeed Cache, WP Rocket), cache serveur de l’hébergeur, CDN éventuel. Un test propre se fait en navigation privée ou avec un paramètre neutre du type ?test=1 en fin d’URL. Si la page blanche s’accompagnait d’un code 500 intermittent, complétez avec notre diagnostic complet de l’erreur 500 WordPress.

Prévenir la prochaine page blanche

  • mettez à jour extensions et thèmes un par un, jamais en lot, pour identifier immédiatement un fautif ;
  • testez toute montée de version PHP sur une copie de préproduction ;
  • gardez moins d’extensions, mieux choisies : chaque ajout est un risque de conflit ;
  • conservez une sauvegarde restaurable et testée, fichiers et base ;
  • surveillez le site avec un service de disponibilité qui vous alerte avant vos visiteurs.

Un site qui tombe en page blanche et revient en dix minutes grâce à un journal d’erreurs bien lu, c’est un incident. Le même site sans journal, sans sauvegarde et sans méthode, c’est un week-end perdu.

FAQ : page blanche WordPress

Pourquoi mon site WordPress affiche une page toute blanche ?

Une erreur PHP fatale interrompt la génération de la page et la configuration de production masque le message d’erreur. Les causes dominantes sont un conflit d’extension, un thème incompatible ou une mémoire PHP épuisée. Activez WP_DEBUG_LOG pour lire l’erreur exacte.

Comment corriger une page blanche sans accès à wp-admin ?

Par FTP : renommez wp-content/plugins pour désactiver toutes les extensions, puis le dossier du thème actif pour forcer un thème par défaut. Éditez wp-config.php pour activer le journal de débogage et augmenter la mémoire. Aucune de ces actions ne supprime de données.

La page blanche peut-elle venir de l’hébergeur ?

Oui. Une montée de version PHP automatique, une limite de mémoire abaissée ou un module serveur défaillant produisent le même symptôme. Le journal d’erreurs du serveur tranche : si l’erreur cite une extension ou un thème, c’est votre site ; sinon, ouvrez un ticket avec la ligne du journal.

Est-ce que mes articles sont perdus quand le site est blanc ?

Non. Le contenu vit dans la base de données, qui n’est pas touchée par une erreur PHP. La page blanche bloque l’affichage, pas le stockage. Une fois l’erreur corrigée, tout réapparaît à l’identique.

Combien de temps Google tolère un site en page blanche ?

Quelques heures n’ont pas d’impact durable. Au-delà de un à deux jours, les pages vides peuvent être désindexées progressivement. Réparez vite, puis laissez Google recrawler naturellement : les positions reviennent avec le contenu.

Sources

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.