Page blanche sur ton site : diagnostic complet toutes plateformes

Une page vide, et aucun message d’erreur

Tu tapes ton adresse, la page se charge visiblement (l’onglet cesse de tourner), et il n’y a rien. Pas de message rouge, pas de code d’erreur, juste du blanc. C’est l’un des bugs les plus déroutants du web parce qu’il ne te donne aucun indice : contrairement à une erreur 500 ou une erreur 403, il n’y a littéralement rien à lire.

Bonne nouvelle : ce silence n’est pas aléatoire. Une page blanche a toujours une cause précise, et dans la grande majorité des cas elle se trouve dans l’une de ces quatre familles : un cache qui te sert une version cassée, une erreur PHP masquée par la configuration de production, un script JavaScript qui plante avant d’avoir pu afficher quoi que ce soit, ou une ressource critique (CSS, JS, police) qui répond en 404. Ce guide s’applique que ton site tourne sous WordPress, sous un framework JavaScript (React, Vue, Next), ou qu’il soit hébergé sur Vercel ou Netlify.

Pourquoi ça arrive : les causes qui pèsent

Avant de plonger dans les solutions, voici les scénarios les plus fréquents, à peu près dans l’ordre où ils se présentent réellement :

• Le navigateur ou un CDN sert une version en cache de la page, figée au moment d’un déploiement raté ou d’une purge incomplète.
• Une erreur PHP fatale (mémoire épuisée, plugin incompatible, fonction manquante) est bien produite côté serveur, mais l’affichage des erreurs est désactivé en production — donc rien ne remonte à l’écran.
• Un script JavaScript lève une exception avant même d’avoir injecté le contenu dans la page (fréquent sur les sites générés par IA ou les single-page apps).
• Une ressource critique répond en 404 : le bundle JS principal, la feuille de style, ou une police, souvent après une migration ou un renommage de fichier mal propagé.
• Un build a échoué sur Vercel ou Netlify, mais l’ancienne version en cache CDN masque temporairement le problème avant de finir par afficher du vide.
• Un mix de contenu HTTP/HTTPS bloque le chargement d’une ressource essentielle par le navigateur, silencieusement.

1. Élimine d’abord le cache : côté toi, puis côté serveur

C’est le réflexe le plus rapide et il résout une bonne partie des cas. Ouvre la page en navigation privée, ou fais un rechargement forcé (Ctrl+Maj+R sur Windows, Cmd+Maj+R sur Mac). Si la page s’affiche correctement, le problème vient d’un cache navigateur ou d’un cache CDN (Cloudflare notamment) qui te servait une ancienne version cassée.

Si tu utilises Cloudflare, purge le cache depuis le dashboard (Caching > Configuration > Purge Everything). Si ton site WordPress utilise un plugin de cache, vide-le également — c’est une cause si récurrente qu’on lui a consacré un comparatif complet des plugins de cache. Teste aussi depuis un autre appareil ou via un outil en ligne qui charge la page sans passer par ton cache local : si toi seul vois du blanc, l’urgence baisse d’un cran, mais il faut quand même comprendre pourquoi le cache a figé une version défaillante.

2. Ouvre la console du navigateur : la piste la plus rentable

Clic droit sur la page, “Inspecter”, puis onglet Console. C’est l’endroit où 80 % des pages blanches livrent immédiatement leur cause. Tu y trouveras généralement l’une de ces situations :

• Une ligne rouge type Uncaught TypeError ou Uncaught ReferenceError : un script JavaScript a planté. Note le nom du fichier et la ligne indiqués — c’est ton point de départ pour isoler le script fautif.
• Une ressource en rouge dans l’onglet Réseau (Network) avec un code 404 : un fichier CSS, JS ou une police ne charge pas. Vérifie son chemin exact et compare-le à l’arborescence réelle de ton hébergement.
• Un avertissement de contenu mixte (“Mixed Content”) : une ressource en HTTP est bloquée sur une page en HTTPS. Ce cas précis est traité en détail dans notre guide sur le contenu mixte HTTPS.

Si tu ne vois rien du tout dans la console ni dans l’onglet réseau, c’est un signe que le problème vient du serveur avant même que le navigateur ne reçoive du contenu à afficher — passe à l’étape suivante.

3. Regarde le code source brut de la page

Fais Ctrl+U (ou Cmd+Option+U sur Mac) pour afficher le code source tel qu’il arrive du serveur, avant toute exécution de JavaScript. Deux cas de figure :

• Le code source est vide ou quasi vide (juste une balise <div id="root"> sans contenu) : le HTML de base est bien envoyé, mais c’est le JavaScript qui devait remplir la page qui a échoué. C’est typique des sites générés par des outils IA type React/Vite qui reposent entièrement sur le rendu côté client — voir notre analyse du vibe coding face à un site pro.
• Le code source est réellement vide, une simple page blanche HTML : le problème est côté serveur, avant même la génération de la page. C’est le signe d’une erreur PHP fatale ou d’un crash applicatif — direction l’étape suivante.

4. Active l’affichage des erreurs PHP si ton site tourne dessus

Sur un site PHP (WordPress ou autre CMS), une page blanche pure signifie presque toujours une erreur fatale masquée parce que display_errors est désactivé en production — un choix volontaire pour ne pas exposer de détails techniques aux visiteurs, mais qui te prive aussi du diagnostic.

Pour WordPress, ouvre wp-config.php à la racine et ajoute juste avant la ligne /* That's all, stop editing! */ :

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

WP_DEBUG_DISPLAY à false garde les erreurs hors de la page publique (pour ne pas effrayer un visiteur) mais WP_DEBUG_LOG les écrit dans /wp-content/debug.log. Ouvre ce fichier après avoir rechargé la page cassée : la dernière ligne indique presque toujours le fichier et la fonction en cause. Pense à repasser WP_DEBUG sur false une fois le diagnostic terminé — ne laisse jamais ce mode actif en permanence.

Sur un hébergement mutualisé, tu peux aussi activer display_errors temporairement via un fichier .htaccess (php_flag display_errors on) ou depuis le panneau PHP de ton hébergeur. Si l’écran blanc concerne spécifiquement WordPress, notre guide dédié à l’écran blanc de la mort WordPress détaille les cas plugin par plugin.

5. Vérifie la mémoire PHP : la cause n°1 des blancs silencieux

Une part importante des pages blanches PHP vient d’un dépassement de memory_limit : le script a besoin de plus de mémoire que ce qui lui est alloué, PHP arrête l’exécution net, et comme rien n’a été affiché, tu obtiens du blanc pur. Le log mentionnera Allowed memory size of X bytes exhausted.

Pour aller plus loin sur l’ensemble de ces réglages, notre article sur les directives PHP de WordPress détaille chacune avec ses valeurs recommandées selon la taille du site.

6. Cas des sites JavaScript purs (React, Vue, sites générés par IA)

Si le Ctrl+U révèle un HTML quasi vide et que la console affiche une erreur JavaScript, le problème est presque toujours l’un de ces trois : une variable d’environnement manquante au build, un import cassé vers un module qui n’existe plus, ou une API externe qui ne répond pas et bloque le rendu au lieu d’afficher un état de secours. Ce genre de fragilité est fréquent sur les sites assemblés rapidement avec des outils IA — notre comparatif Lovable, Bolt et v0 revient sur ces limites structurelles.

7. Cas des sites hébergés sur Vercel ou Netlify

Si ton site est déployé sur l’une de ces plateformes et affiche du blanc après une mise à jour, vérifie d’abord le tableau des déploiements : un build en échec peut laisser l’ancienne version en cache CDN temporairement visible, avant qu’elle finisse par disparaître. Consulte les logs de build directement dans le dashboard. Nos guides dédiés couvrent ce cas précis : problème de déploiement Vercel et problème de déploiement Netlify. Si un domaine personnalisé vient d’être branché, vérifie aussi la configuration DNS/SSL décrite dans notre guide sur le domaine personnalisé Vercel/Netlify.

Tableau récapitulatif : cause → solution

FAQ

Quand passer la main à un pro

Si après avoir activé le debug tu obtiens un message technique que tu ne comprends pas, si le fichier log grossit sans que tu identifies le fichier en cause, ou si le site tourne sur une stack que tu ne maîtrises pas (build JS, déploiement continu), c’est le moment de faire intervenir quelqu’un qui lit ces logs tous les jours. Une page blanche mal diagnostiquée peut cacher une erreur de connexion à la base de données ou une compromission du site — deux situations où bricoler sans comprendre la cause exacte peut aggraver les choses plutôt que les réparer.