Page blanche : simple panne PHP ou site compromis ?
Une page blanche après une mise à jour est souvent une erreur fatale PHP. La même page blanche avec un `.htaccess` réécrit ou un `index.php` gonflé oriente vers un piratage. Le White Screen of Death n’est pas un diagnostic : c’est un écran sans message. Le journal, lui, parle.
Une page blanche après une mise à jour est souvent une erreur fatale. La même page blanche avec un .htaccess réécrit ou un index.php gonflé oriente vers un piratage.
Ce qu’une page blanche veut dire techniquement
Le navigateur a reçu une réponse presque vide : souvent HTTP 200 ou 500, corps nul, parce que PHP a fatal sans `display_errors`. Ce n’est pas une page « vide de contenu éditorial ». C’est un processus mort. WordPress, PrestaShop, un PHP maison : même symptôme. On l’appelle White Screen of Death par habitude, pas parce que c’est spécifique à un piratage.
Donc « page blanche WordPress » dans Google mène à deux familles d’articles : augmenter la mémoire, et chercher un hack. Les deux existent. On les sépare avec l’horloge (quoi s’est passé juste avant), le journal, et l’état des fichiers d’entrée (`index.php`, `.htaccess`, `.user.ini`).
Si un client dit « page blanche » en vous envoyant une capture d’alerte Chrome, ce n’est pas une WSoD. C’est Safe Browsing. Si la barre d’adresse a déjà changé de domaine, c’est une redirection. Demandez la capture avant de déboguer PHP.
- WSoD vraie : HTML vide, souvent 500, log Fatal.
- Alerte navigateur : ce n’est pas une blanche PHP.
- Redirection : l’URL n’est plus la vôtre.
- Maintenance plugin : parfois un blanc mal configuré.
Juste après une mise à jour : le scénario panne
Extension, thème, cœur, version PHP : la blanche dans l’heure qui suit est une incompatibilité jusqu’à preuve du contraire. Renommez le dossier `plugins` en `plugins.off` via le gestionnaire de fichiers. Si ça revient, réactivez par paquets. C’est le test le plus court. Notez laquelle casse.
Un thème enfant avec une fonction retirée du parent produit le même blanc. Passez temporairement à un thème par défaut (renommer le thème actif). Si le site revient, le thème — pas « tout WordPress est mort ».
Dans ce scénario, inutile de changer tous les mots de passe ni d’ouvrir un ticket malware. Copiez quand même `error.log` : si le Fatal cite `eval` ou `uploads/*.php`, vous changerez d’avis en une ligne. L’article erreur 500 détaille cette lecture.
Le `.htaccess` réécrit et l’index gonflé
Piratage probable quand la blanche arrive sans update, et que `.htaccess` contient `auto_prepend_file`, un `RewriteRule` vers un domaine tiers, ou des `Deny` qui se mordent. Ou quand `index.php` à la racine pèse 40–80 Ko au lieu des ~2 Ko du cœur WordPress. Ou quand un `index.php` apparaît dans chaque sous-dossier d’uploads.
Ces fichiers d’entrée sont les premiers à ouvrir, avant de balayer vingt plugins. Comparez `index.php` au zip de votre version (`wget` du cœur, ou le paquet dans le panel « réinstaller les fichiers cœur » en lecture seule — sans cliquer restore compte). Un diff de trois lignes `eval` suffit.
Un `.user.ini` ou un `php.ini` dans le vhost avec `auto_prepend_file=/home/…/wp-tmp.php` produit une blanche si le prepend a été mal encodé ou retiré à moitié. Cherchez ces trois noms : `.htaccess`, `.user.ini`, `php.ini`. Beaucoup de « cleaners » les laissent.
Mémoire saturée ou payload qui boucle
Le log `Allowed memory size exhausted` oriente vers un plugin gourmand, un export, ou un générateur de pages spam qui construit 10 000 URLs en une requête. Le contexte tranche : un pic CPU sans trafic + memory = plutôt minage / générateur qu’un simple Yoast.
Une boucle d’includes (A inclut B qui inclut A) après injection se voit dans un Fatal `Nesting` ou une 504. Un scan qui « répare » en doublant des `require` produit le même effet. Repartez du fichier officiel, pas d’une deuxième réparation.
Augmenter `memory_limit` à 512M pour « voir si ça passe » est un test de cinq minutes, pas une solution. Si ça passe et que le site sert du spam, vous avez juste donné plus de RAM au payload.
Activer les logs sans les montrer aux visiteurs
Dans `wp-config.php` : `WP_DEBUG` true, `WP_DEBUG_LOG` true, `WP_DEBUG_DISPLAY` false, `display_errors` off. Rechargez une fois la home. Lisez `wp-content/debug.log`. Remettez `WP_DEBUG` à false après. Un debug affiché après incident expose chemins et parfois secrets.
Si vous n’avez plus wp-config accessible en écriture, l’hébergeur peut activer le log PHP du vhost. Demandez ça plutôt qu’un « repair WordPress » immédiat. Voir debug laissé en ligne pour ne pas oublier l’interrupteur.
PrestaShop : mode debug dans `defines.inc.php` ou les paramètres avancés, jamais en prod publique plus d’un quart d’heure. Même règle : log fichier, pas écran.
Checklist pour trancher en vingt minutes
1) Capture + code HTTP + URL. 2) Y a-t-il eu update / change PHP aujourd’hui ? 3) error.log ou debug.log : quel fichier ? 4) Date et taille de `index.php` et `.htaccess` vs une archive ou le zip officiel. 5) Un deuxième canal (site:, admin fantôme, email abus) ?
Update + Fatal dans l’extension + fichiers d’entrée intacts + pas d’autre canal = panne. Pas d’update + index gonflé ou prepend + autre canal = compromis. Zone grise : Fatal dans `functions.php` d’un thème rarement touché — lisez les vingt dernières lignes du fichier avant de conclure.
Deux « piratage » ou une zone grise avec prepend : basculez sur l’ordre constater, copier, panel. Ne restez pas dans la boucle « encore un plugin à désactiver » pendant que le shell tourne.
- HTTP et URL notés.
- Horloge : action humaine récente ou pas.
- Ligne de log copiée.
- index / htaccess / user.ini contrôlés.
- Un contrôle Google ou comptes.
Ce qu’il ne faut pas faire sur un écran blanc
Réinstaller tout le CMS depuis le bouton panel. Vider `.htaccess` sans copie. Passer `chmod 777` « pour voir ». Installer Wordfence maintenant (le plugin peut lui-même fatal, et n’explique pas la ligne de log). Restaurer la dernière sauvegarde sans l’ouvrir.
Multiplier les plugins « white screen fix » trouvés sur Google : vous ajoutez du code sur un site déjà instable, parfois déjà compromis. Un seul levier à la fois, noté sur papier.
Si vos isolations ont empiré les choses, repartez de la copie d’avant, pas d’une troisième réinstall. La blanche d’origine avait un log. Le désastre actuel n’en a plus.
Quand la « blanche » n’est pas du PHP
CDN / Cloudflare : challenge mal bouclé, cache d’une réponse vide, mode « under attack » qui échoue. Testez en contournant (hosts, IP d’origine). WAF hébergeur qui drop le body. Quota : page vide sans Fatal. DNS vers un parking blanc.
Un thème qui n’imprime rien (boucle vide après injection en base sur `show_on_front`) peut donner l’impression d’une WSoD avec un 200 et un HTML de 200 octets (doctype + rien). Affichez le source. S’il y a un doctype, ce n’est pas un Fatal : c’est le contenu ou le template.
Dans le doute, une inspection Search Console dit si Googlebot reçoit du HTML. S’il reçoit un kit ou du spam alors que vous voyez blanc, vous n’êtes plus sur une panne locale. Créer un dossier avec le log et le source évite de tourner en rond.