curl -I https://exemple.test/ renvoie HTTP/1.1 200 OK. Pourtant, dans le navigateur, la page reste blanche. Pas de message d’erreur, pas de trace visible, rien. C’est l’un des scénarios les plus déstabilisants pour qui reprend un site WordPress sans documentation : le serveur fonctionne, la base de données répond, mais l’affichage final est vide.
Ce cas est réel et représentatif d’une catégorie de pannes fréquentes dans les reprises de projet : un plugin ou un thème obsolète entre en conflit silencieux avec une version de PHP plus récente, et l’erreur fatale qui devrait apparaître est masquée par la configuration de production. Voici la méthode suivie pour remonter à la cause sans rien casser au passage.
Symptôme : page blanche, code HTTP correct
Premier réflexe face à une page blanche : vérifier que le serveur répond bien et que ce n’est pas un problème réseau ou DNS. Un code 200 avec un corps vide écarte ces hypothèses et pointe vers l’exécution PHP elle-même. Le symptôme classique du « White Screen of Death » se distingue d’une erreur 500 : ici, PHP a terminé son exécution sans lever d’erreur visible, généralement parce que display_errors est désactivé en production, ce qui est la bonne pratique de sécurité mais complique le diagnostic.
Diagnostic : remonter aux logs sans casser la prod
Sans documentation sur la configuration du site, la première étape consiste à activer le journal d’erreurs WordPress sans modifier le comportement visible pour les visiteurs :
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --rawCette combinaison écrit les erreurs dans wp-content/debug.log sans jamais les afficher au visiteur. Un rechargement de la page suffit ensuite à faire apparaître, dans le fichier de log, la trace exacte : le plus souvent une erreur fatale du type Call to undefined function ou Uncaught Error: Class not found, signe qu’un plugin appelle une fonction supprimée dans la version de PHP installée.
Confirmer l’origine par bissection
Une fois l’erreur localisée dans le log, encore faut-il confirmer quel composant la déclenche, surtout sur un site sans inventaire des extensions actives. La méthode par bissection, sans risque pour le contenu :
- Lister les extensions actives avec
wp plugin list --status=active, sans encore rien désactiver. - Désactiver la moitié des extensions listées via
wp plugin deactivate, recharger la page et vérifier si l’erreur disparaît du log. - Répéter la bissection sur la moitié restante jusqu’à isoler le plugin ou la combinaison de plugins responsable.
- Faire de même avec le thème actif en basculant temporairement vers un thème par défaut avec
wp theme activate twentytwentyonesi le doute persiste côté template.
Cette approche évite de désactiver les extensions une par une, ce qui serait long sur un site qui en compte plusieurs dizaines sans documentation pour orienter les recherches.
Correctif : traiter la cause, pas seulement le symptôme
Une fois l’extension fautive identifiée, deux options : une mise à jour si une version compatible existe, ou un remplacement si le plugin est abandonné. Dans le cas d’une fonction PHP supprimée (comme certaines fonctions dépréciées puis retirées entre PHP 7.4 et PHP 8.0), un correctif temporaire consiste à redéclarer la fonction manquante dans un plugin maison, le temps de trouver une alternative durable.
- Ne jamais laisser
WP_DEBUG_DISPLAYactif en production, même temporairement, pour éviter d’exposer des chemins serveur aux visiteurs. - Consigner la cause trouvée quelque part, même sommairement, pour la prochaine personne qui reprendra le site.
- Vérifier la compatibilité PHP de chaque extension avant toute montée de version du serveur.
Une page blanche n’est jamais silencieuse : elle parle dans un fichier de log que la production a simplement choisi de ne pas montrer au visiteur.
Prévention : ne plus repartir de zéro la prochaine fois
Le vrai problème d’une reprise sans documentation n’est pas la panne elle-même, mais le temps perdu à comprendre un système qu’on découvre en même temps qu’on le répare. Un inventaire minimal — liste des extensions actives, thème utilisé, version de PHP ciblée — pris à froid, avant tout incident, réduit considérablement le temps de diagnostic la prochaine fois qu’un symptôme silencieux comme celui-ci se reproduit.
En résumé
Face à une page blanche avec un code HTTP correct, la séquence gagnante reste : activer le log d’erreurs sans l’afficher, isoler par bissection des extensions et du thème, corriger la cause plutôt que redémarrer le service, puis documenter ce qui vient d’être appris pour la prochaine reprise.
