Écran blanc WordPress : retrouver l’erreur sans l’afficher au public

Un écran blanc signifie que la réponse ne contient pas le rendu attendu. Il peut masquer une erreur fatale, une mémoire épuisée, une sortie interrompue, un template vide ou un cache défectueux. Le statut HTTP et les journaux sont plus fiables que l’apparence.

Ce que ce symptôme signifie réellement

Un 500 vide et un 200 vide n’orientent pas vers la même couche.

Activer l’affichage des erreurs en production peut révéler chemins et données ; utilisez un journal protégé ou le mode de récupération.

Avant toute modification : préserver les preuves et le retour arrière

Notez l’heure, l’URL, le message exact, le code HTTP et le dernier changement connu. Vérifiez ensuite qu’une sauvegarde récente couvre bien les fichiers et la base de données, qu’elle est lisible et qu’un retour arrière limité est possible. Une sauvegarde non testée ne suffit pas pour une intervention risquée.

• Ne transmettez jamais de mot de passe, clé privée, jeton, fichier wp-config.php ou export de base dans un formulaire ou une capture.
• Travaillez d’abord sur un staging ou une copie isolée lorsque le diagnostic exige une mise à jour, une modification de code ou une opération de base de données.
• Conservez les journaux et les fichiers suspects avant nettoyage : ils peuvent être nécessaires pour comprendre la cause ou vérifier l’étendue d’un incident.

Diagnostic : avancer du signal le plus fiable au test le moins intrusif

Tester frontend, administration, REST et une ressource statique, puis relever le statut et la taille de réponse.

1. Corréler les journaux à la requête.
2. Utiliser le mode de récupération si WordPress l’a déclenché.
3. Comparer connecté/non connecté et cache contourné.
4. Isoler le dernier composant changé avec rollback.

Correction : appliquer une action ciblée et réversible

Restaurez le composant fautif ou corrigez l’erreur confirmée sur staging.

1. Utiliser la restauration automatique ou désactivation ciblée.
2. Corriger syntaxe, mémoire ou template à la source.
3. Purger uniquement le cache qui contenait la réponse vide.
4. Ajouter un test HTTP qui vérifie aussi le contenu attendu.

Contrôles après correction

Une page qui se recharge ne suffit pas à prouver que le problème est résolu. Contrôlez le parcours concerné, une page non connectée, l’administration, les erreurs console et réseau, les journaux serveur, le cache et les redirections. Vérifiez aussi les écrans mobile et desktop si le symptôme touchait le rendu.

• Statut, HTML et éléments critiques présents.
• Mode connecté, mobile et sans JavaScript vérifiés.
• Logs sans fatale et cache cohérent.

Quand arrêter et demander une intervention

Si l’écran blanc suit une intrusion ou une modification inconnue, conservez les preuves et auditez l’intégrité avant restauration définitive.

Sources de référence

• WordPress — Recovery Mode
• WordPress — Debugging

Continuer le diagnostic

• Erreur 500 WordPress
• Erreur de syntaxe PHP
• Urgence WordPress