Écran blanc WordPress : causes et solutions

Le site affiche une page totalement vide, sans message : c'est l'écran blanc de WordPress, aussi appelé écran blanc de la mort. Le manuel officiel de WordPress rappelle que, par défaut, PHP n'affiche que les erreurs fatales ou laisse une page blanche quand une erreur survient : le silence n'est donc pas un signe d'absence d'erreur, mais d'erreur non affichée. Cet article s'appuie sur le manuel Debugging in WordPress (mis à jour le 23/09/2026) et sur l'annonce officielle du mode de récupération de WordPress 5.2, lus le 08/10/2026, pour proposer une démarche dans l'ordre, un calcul illustratif et un relevé des recherches en France.

Le mode de récupération : l'outil à essayer en premier

Depuis WordPress 5.2, une erreur fatale doit afficher aux visiteurs un message de difficultés techniques et envoyer un e-mail à l'adresse administrateur du site. Cet e-mail contient un lien secret vers le mode de récupération. Selon l'annonce de l'équipe de développement du noyau, ce mode fonctionne grâce à un cookie posé sur le poste de la personne qui clique : les extensions et les thèmes qui provoquent l'erreur sont mis en pause pour ce poste seulement, ce qui permet de se connecter et de décider quoi faire.

Trois précisions utiles, tirées de la même source. Premièrement, le mode de récupération ne répare rien : l'annonce souligne qu'il est impossible de corriger automatiquement ces erreurs, il permet seulement de les contourner. Deuxièmement, les autres visiteurs voient toujours le site en panne tant que le problème n'est pas résolu. Troisièmement, quitter le mode (bouton dans la barre d'administration) supprime le cookie : si l'extension reste défaillante, l'erreur réapparaît. L'administrateur peut alors désactiver l'extension, la corriger s'il en a les compétences ou contacter son auteur avec le message d'erreur exact. La source date de 2019 : son contenu décrit le principe du mécanisme, à confirmer sur votre version actuelle.

Si l'e-mail n'arrive pas, la page indique que la gestion de l'adresse destinataire peut être modifiée par du code, et qu'une constante permet de désactiver entièrement ce mécanisme. Ces réglages relèvent d'un intervenant technique ; vérifiez surtout l'adresse administrateur et les courriers indésirables.

Activer le journal d'erreurs sans exposer le site

Quand le mode de récupération n'est pas disponible, le manuel officiel décrit les constantes de débogage à placer dans le fichier wp-config.php, avant la ligne qui invite à arrêter de modifier. Le manuel précise aussi, en toutes lettres, qu'il n'est pas recommandé d'utiliser ces outils sur un site en production : ils sont prévus pour des copies locales ou de test, et une sauvegarde ou un environnement de test doit précéder toute modification. Si vous devez intervenir sur le site réel, la combinaison décrite dans le manuel consiste à journaliser les erreurs dans un fichier tout en masquant leur affichage.

Des causes à vérifier, dans l'ordre, une fois le message lu

Le journal donne en général le fichier et la ligne en cause : c'est lui qui désigne l'extension, le thème ou le fichier modifié. Sans journal, les causes ci-dessous restent des hypothèses à tester, de la moins invasive à la plus invasive. Désactiver toutes les extensions en renommant leur dossier par FTP ou depuis le gestionnaire de fichiers de l'hébergeur est une pratique courante, que les pages officielles lues ici ne détaillent pas : à réserver à une personne à l'aise avec ces outils, après sauvegarde.

Un calcul illustratif : combien d'essais pour trouver l'extension en cause ?

Imaginons un site fictif avec 12 extensions actives, une seule fautive, aucune dépendance entre elles, et 4 minutes par essai (modification, rechargement, contrôle). Les durées ci-dessous sont un exemple, pas une mesure de votre site : elles montrent surtout l'intérêt de lire le journal avant d'essayer au hasard.

Lecture : la recherche par moitiés repose sur le fait que 2 puissance 4 vaut 16, donc quatre essais suffisent pour 12 extensions. Elle n'est valable que si une seule extension est en cause ; si deux extensions interagissent, il faut revenir à un test plus fin. Le journal, lui, évite la recherche : il pointe directement le fichier, à condition d'avoir pu l'activer sans risque.

Plan d'action

1. Faites ou vérifiez une sauvegarde avant toute modification, comme le demande le manuel WordPress.
2. Cherchez dans la boîte de l'adresse administrateur l'e-mail de WordPress avec le lien du mode de récupération, y compris dans les courriers indésirables, et utilisez-le.
3. Consultez les journaux d'erreurs de votre hébergement : ils peuvent déjà contenir l'erreur PHP, sans rien modifier sur le site.
4. Si nécessaire, activez WP_DEBUG et WP_DEBUG_LOG, avec WP_DEBUG_DISPLAY sur false, de préférence sur une copie de test ; lisez wp-content/debug.log.
5. Traitez la cause désignée : extension, thème, fichier modifié ou version de PHP. Faites un seul changement à la fois.
6. Remettez le débogage à l'état d'origine, supprimez le journal devenu inutile et vérifiez la page publique ainsi que l'administration.

Si le journal reste muet ou si l'accès au site est perdu, la démarche la plus sûre est de confier l'intervention à un professionnel plutôt que d'enchaîner les essais sur le site en ligne.

Constat : les volumes sont très faibles pour ce type de panne. Les internautes la décrivent surtout par l'expression page blanche ou par le code d'erreur, plus rarement par écran blanc. L'expression écran blanc wordpress, avec accents, est présente dans la base DataForSEO sans volume mesuré ; wp_debug, mode de récupération wordpress, limite de mémoire php wordpress et déboguer wordpress sont absentes de la base : elles sont non mesurées, et non pas nulles. Un article sur un sujet aussi peu recherché sert surtout à répondre précisément au moment de la panne. Données DataForSEO, France, septembre 2025 à août 2026.