L’« écran blanc de la mort » a perdu son statut d’énigme depuis WordPress 5.2 : une erreur fatale de PHP y déclenche désormais un message lisible. Si votre page est réellement vide, c’est donc que ce mécanisme n’a pas pu jouer — et cette information est déjà la moitié du diagnostic.

Les deux vérifications à faire d’abord

Affichez le code source de la page (Ctrl+U), et relevez le code de réponse. Une page vide qui répond 200 avec du HTML tronqué n’a rien à voir avec une page de zéro octet qui répond 500.

Le code de réponse partage le diagnostic en deux

C’est la lecture décisive, et celle que presque personne ne fait. Une commande suffit :

curl -I https://votre-site.fr/

Sans terminal, le testeur d’en-têtes donne la même réponse depuis le navigateur. Deux issues, deux enquêtes différentes :

  • 500 — PHP est mort. Mais il est mort avant que WordPress ne puisse afficher son message d’erreur critique. Le coupable se trouve donc très tôt dans le chargement.
  • 200 — PHP a terminé sa course normalement, du point de vue du serveur. Le problème n’est pas un plantage mais un rendu qui ne produit rien, ou qui s’interrompt en cours de route.

Le cas 200 est le plus dangereux pour le référencement. Un 500 dit à Google « repasse plus tard » ; une page vide en 200 lui dit « voici ma page, elle est vide », et elle finit indexée comme telle. Ce que chaque code raconte à un moteur est détaillé ici.

Le code source finit le tri

Ouvrez la source de la page. Trois cas, trois directions :

  • Zéro octet. PHP n’a rien eu le temps d’écrire. Le plantage est antérieur au premier affichage.
  • Du HTML qui s’arrête net, souvent au milieu d’une balise. PHP est mort en cours de page — mémoire épuisée, ou erreur dans un élément affiché tardivement. Le dernier bloc rendu vous dit où.
  • Une page complète mais sans contenu, avec l’en-tête et le pied de page. Rien n’a planté : c’est la boucle de contenu ou le gabarit du thème qui ne renvoie rien.

Page vide en 500 : le plantage précoce

Le gestionnaire d’erreurs de WordPress ne peut afficher un message que s’il a lui-même été chargé. Tout ce qui casse avant lui produit une page muette. Par ordre de fréquence :

1. Une erreur de syntaxe dans wp-config.php

C’est la cause la plus fréquente et la plus mal identifiée. Ce fichier est lu tout au début, bien avant que WordPress n’installe la moindre protection. Une accolade manquante, un guillemet non fermé, un accent collé dans une constante : la page est vide, sans un mot d’explication.

Le contrôle se fait sans navigateur, si vous avez un accès SSH :

php -l wp-config.php

La réponse attendue est No syntax errors detected. Sinon, le numéro de ligne est donné. Le même contrôle vaut pour le functions.php du thème et pour tout fichier modifié à la main.

2. Un mu-plugin

Les extensions déposées dans wp-content/mu-plugins se chargent avant les autres, ne peuvent pas être désactivées depuis l’administration et sont invisibles dans la liste habituelle des extensions. Beaucoup d’hébergeurs en installent un. Renommez le dossier pour l’écarter le temps du test.

3. Le gestionnaire d’erreurs a été désactivé

Cherchez WP_DISABLE_FATAL_ERROR_HANDLER dans wp-config.php. S’il est à true, WordPress ne rattrape plus rien et vous avez affaire à une erreur critique ordinaire : la marche à suivre est celle-ci.

Page vide en 200 : le rendu qui ne rend rien

1. La mémoire épuisée

Symptôme caractéristique : une page qui s’interrompt toujours au même endroit, et un statut 200 malgré le plantage. L’explication tient en une phrase : les en-têtes étaient déjà partis quand PHP s’est arrêté, et un statut envoyé ne se rattrape pas.

Relevez la limite dans wp-config.php :

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

Ces constantes ne peuvent pas dépasser la limite fixée par le serveur (memory_limit de PHP). Si rien ne change, c’est là qu’il faut agir, dans le panneau de l’hébergeur ou dans un fichier .user.ini. Et retenez qu’augmenter la mémoire ne soigne rien : c’est un pansement le temps de trouver ce qui la consomme.

2. Un espace après la balise fermante

Un fichier PHP qui se termine par ?> suivi d’une ligne vide envoie ce blanc au navigateur avant tout le reste. Selon le contexte, cela provoque un avertissement « headers already sent », une redirection cassée ou une page vide. La convention de WordPress est claire : dans un fichier qui ne contient que du PHP, on ne ferme pas la balise. Un marqueur d’ordre d’octets (BOM) déposé par un éditeur produit le même effet, en invisible. Le même défaut casse l’éditeur de blocs, qui affiche alors « La réponse n’est pas une réponse JSON valide ».

3. Le thème ne renvoie rien

Si la page contient l’en-tête et le pied de page mais rien entre les deux, basculez sur un thème par défaut. Sans accès à l’administration, renommez le dossier du thème actif dans wp-content/themes : WordPress retombe sur un thème par défaut, s’il en reste un.

Cas voisin, souvent négligé : le blanc n’apparaît que sur certaines pages — les articles, une catégorie, la recherche. Le gabarit correspondant est alors seul en cause, et la lecture se restreint à un fichier.

Localiser en trois questions

Avant de désactiver quoi que ce soit, situez la panne. Chaque réponse élimine une moitié du terrain.

  • L’administration s’ouvre-t-elle ? Si oui, le cœur et la base vont bien : cherchez du côté du thème ou d’une extension de rendu. Si elle est blanche aussi, remontez vers le chargement.
  • Le blanc touche-t-il toutes les pages ? Une page d’accueil vide alors qu’un article s’affiche désigne un gabarit précis.
  • Qu’est-ce qui a changé en dernier ? Une mise à jour, un fichier enregistré, une version de PHP relevée par l’hébergeur. Dans neuf cas sur dix, la réponse est là — y compris quand personne n’a « rien touché » : les hébergeurs changent la version de PHP sans prévenir.

Faire parler PHP

Le journal reste la seule méthode qui donne le fichier et la ligne. Dans wp-config.php :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Rechargez, puis ouvrez wp-content/debug.log. Attention toutefois : ce journal ne peut rien enregistrer d’une erreur survenue dans wp-config.php lui-même, puisque les constantes n’ont pas encore été lues. Dans ce cas précis, seul le journal d’erreurs du serveur — souvent error_log à la racine, ou une rubrique du panneau de l’hébergeur — contient la ligne utile.

Retirez ces trois lignes une fois le problème réglé, et ne passez jamais WP_DEBUG_DISPLAY à true sur un site en ligne.

Pendant que vous cherchez

Une page blanche servie en 200 pendant plusieurs jours finit par être prise pour du contenu. Si le diagnostic doit durer, fermez le site explicitement avec un statut 503 : c’est le seul code qui demande aux moteurs de revenir plus tard sans rien retenir de ce qu’ils ont vu.