Votre site affiche « Il y a eu une erreur critique sur ce site. » Que la cause soit une extension, le thème, la version de PHP (le langage dans lequel WordPress est écrit) ou un manque de mémoire, la panne se répare sans rien perdre de votre contenu.

Ce que signifie ce message, et ce que voient vos visiteurs

WordPress affiche ce message quand une erreur grave (une « erreur fatale », en termes techniques) interrompt l’affichage d’une page. Depuis WordPress 5.2, au lieu d’une page blanche, il affiche une page d’erreur et tente de prévenir l’administrateur par e-mail.

Le texte change selon l’endroit. Sur les pages publiques, vos visiteurs ne lisent que la phrase courte citée plus haut. Dans l’administration et sur la page de connexion, WordPress ajoute : « Veuillez vérifier la boîte de réception de votre e-mail d’administration pour obtenir des instructions. Si vous continuez à avoir des problèmes, essayez le forum de support. » Dans les anciennes versions, le message disait « Une erreur critique est survenue sur votre site ». Il s’agit de la même erreur.

Cette page est envoyée avec le code 500, par lequel le serveur signale qu’il a échoué. Notre article sur l’erreur 500 explique ce que Google fait de vos pages pendant la panne, et pourquoi une page blanche ou coupée net peut venir de la même erreur.

Une extension de cache, qui garde une copie de vos pages pour les afficher plus vite, peut même masquer la panne. Ces copies continuent de s’afficher normalement pendant que le reste du site est en erreur, si bien que votre page d’accueil peut sembler intacte.

Dans quels cas WordPress envoie l’e-mail

WordPress n’envoie pas d’e-mail à chaque erreur critique. Dans sa version actuelle, il n’en envoie un que si toutes ces conditions sont réunies :

l’erreur vient d’une extension ordinaire ou d’un thème. Une erreur située dans les fichiers de WordPress lui-même, dans son fichier de réglages (wp-config.php) ou dans une extension de l’onglet « Indispensables » ne déclenche aucun e-mail ;
quelqu’un l’a rencontrée dans l’administration ou sur la page de connexion. Tant que l’erreur ne survient que sur les pages publiques, ou pendant une tâche planifiée (une opération que WordPress lance de lui-même en arrière-plan), aucun e-mail ne part ;
aucun e-mail de ce type n’est parti dans les dernières 24 heures ;
le site ne fait pas partie d’un réseau multisite, c’est-à-dire de plusieurs sites gérés depuis une seule installation de WordPress ;
l’e-mail peut partir. WordPress l’envoie depuis l’adresse wordpress@votredomaine, que certains hébergeurs bloquent si elle n’existe pas. Le message se perd alors sans que rien ne vous le signale.

L’e-mail part vers l’adresse indiquée dans Réglages, puis Général, champ « Adresse e-mail d’administration ». Si c’est l’adresse d’un ancien prestataire ou d’une boîte que plus personne ne lit, vous ne le verrez jamais.

Avant de cliquer sur le lien de récupération

L’e-mail, si vous l’avez reçu, contient un lien vers le « mode de récupération ». Avant de cliquer, sachez trois choses :

le lien est valable un jour, et une seule fois. Un deuxième clic affiche « Mode de récupération non initialisé. » Un logiciel de sécurité qui ouvre les liens des e-mails pour les analyser pourrait même l’utiliser avant vous ;
le mode de récupération ne répare rien pour vos visiteurs. Il met l’extension fautive en pause pour vous seul, dans votre navigateur, pendant votre session. Le site public reste en erreur ;
ne sortez pas trop tôt du mode de récupération. Dans la liste des extensions, le filtre « Mis en pause » affiche l’extension en cause, avec la mention « Cette extension n’a pas pu se charger correctement et a été mise en pause dans le cadre du mode de récupération. » Désactivez-la. C’est ce geste qui rend le site à vos visiteurs, si cette extension était seule en cause. Cliquez ensuite sur « Sortir du mode de récupération ». Si vous sortez avant, l’erreur revient pour vous aussi.

Sans e-mail : trouver vous-même la cause

1. Lire le journal d’erreurs de l’hébergeur

C’est le geste le plus rapide. Si votre hébergeur enregistre les erreurs PHP, l’erreur y est inscrite avec le fichier en cause : une ligne qui contient /wp-content/plugins/nom-de-l-extension/ désigne directement l’extension.

OVHcloud : espace client, votre hébergement, onglet « Statistiques et logs », rubrique « Logs du site web », puis « Logs erreur ». Les erreurs y apparaissent avec environ cinq minutes de décalage ;
o2switch : quand il existe, un fichier error_log dans le dossier principal du site, à côté de wp-config.php, lisible dans le gestionnaire de fichiers de cPanel (l’interface de votre hébergement) ;
Infomaniak : dans le Manager, votre site, « Avancé », « Journaux », « Erreurs ». Les journaux sont gardés au moins sept jours.

2. Activer WP_DEBUG sans montrer les erreurs à vos visiteurs

Si le journal de l’hébergeur est vide, demandez à WordPress de noter les erreurs. Ouvrez wp-config.php, qui contient les réglages de base de WordPress, par FTP (une connexion directe aux fichiers du site, avec un logiciel comme FileZilla) ou dans le gestionnaire de fichiers de votre hébergeur. Faites-en d’abord une copie, car une faute de frappe dans ce fichier suffit à bloquer tout le site. Remplacez ensuite la ligne qui contient WP_DEBUG, un peu au-dessus de celle qui demande de ne plus rien modifier, par ces quatre lignes :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

La troisième ligne est essentielle, car sans elle les erreurs s’affichent à tous vos visiteurs, avec l’emplacement de vos fichiers sur le serveur. Rechargez ensuite la page en erreur, puis lisez le fichier wp-content/debug.log. Il ne contient que les erreurs survenues depuis que vous avez activé le journal.

Une fois la cause trouvée, remettez WP_DEBUG à false et supprimez debug.log. Sauf protection particulière, n’importe qui peut télécharger ce fichier, et il révèle la structure de votre site. Tant que le journal est activé, l’outil Santé du site (menu Outils) le signale comme un problème critique ; une fois WP_DEBUG remis à false, il ne voit plus le fichier resté en place. Notre analyse gratuite, elle, recherche les journaux laissés accessibles.

3. Désactiver les extensions sans passer par l’administration

Toujours par FTP ou dans le gestionnaire de fichiers, renommez le dossier wp-content/plugins, par exemple en plugins.hold. Toutes les extensions sont désactivées d’un coup. Connectez-vous à l’administration, remettez le nom d’origine, puis réactivez les extensions une par une. Si vous utilisez Maintena, ce renommage l’arrête aussi : réactivez-la en premier, vos réglages sont conservés. WordPress affichera au passage le message « L’extension … a été désactivée en raison d’une erreur : Le fichier de l’extension n’existe pas. » C’est normal.

Si WordPress refuse d’en activer une avec le message « L’extension n’a pas pu être activée, car elle a déclenché une erreur fatale. », vous avez trouvé l’extension en cause. Si l’erreur réapparaît juste après une activation, désactivez cette extension, ou renommez son seul dossier si l’administration ne s’ouvre plus.

4. Vérifier si le thème est en cause

Vérifiez d’abord, dans le dossier wp-content/themes, qu’un thème de WordPress comme Twenty Twenty-Five (dossier twentytwentyfive) s’y trouve encore, car c’est vers lui que WordPress basculera. Renommez ensuite le dossier de votre thème, puis ouvrez aussitôt Apparence, puis Thèmes. C’est seulement à ce moment que WordPress change de thème, avec le message « Le thème courant est endommagé. Retour au thème par défaut. » Une fois le problème réglé et le nom du dossier rétabli, réactivez votre thème.

Les causes d’une erreur critique

Une mise à jour d’extension

Une extension mise à jour peut ne plus être compatible avec une autre, ou avec votre thème. Les extensions vendues en deux parties, une gratuite et un module payant, comportent un piège de plus. Sans licence active sur le site, le module payant ne se met plus à jour (WordPress affiche « Le téléchargement a échoué. », suivi du refus de l’éditeur, par exemple « Unauthorized »), alors que la partie gratuite continue de le faire. Les deux versions peuvent alors ne plus fonctionner ensemble. Notre article sur un site cassé après une mise à jour explique comment revenir à la version précédente, et pourquoi WordPress n’annule de lui-même qu’une partie des mises à jour qui provoquent une erreur.

La version de PHP, changée par l’hébergeur

PHP 8 a supprimé plusieurs fonctions anciennes. Une vieille extension qui les appelle provoque une erreur « Call to undefined function » dès que l’hébergeur passe à PHP 8. La solution durable est de mettre à jour ou de remplacer l’extension. Revenir à PHP 7.4, comme on le conseille parfois sur les forums, laisserait le site sur une version qui ne reçoit plus aucun correctif de sécurité depuis le 28 novembre 2022. Notre article sur WordPress 7 aide à choisir la bonne version de PHP, et montre comment revenir en arrière quelques jours, le temps de corriger.

La mémoire

Une erreur « Allowed memory size of 134217728 bytes exhausted » signifie qu’une page a demandé plus de mémoire de travail que le serveur ne lui en accorde. Le nombre affiché (134 217 728 octets, soit 128 Mo) est la limite réellement appliquée sur votre site, quelle que soit celle que vous pensez avoir réglée. S’il est inférieur au maximum annoncé pour votre formule d’hébergement, une ligne comme define( 'WP_MEMORY_LIMIT', '256M' ); dans wp-config.php peut relever la limite. Ce réglage ne la baisse jamais, si bien qu’une valeur plus petite, parfois conseillée en ligne, n’a aucun effet. Si votre site utilise déjà tout ce que permet votre formule, cherchez l’extension qui consomme tant de mémoire.

Quand personne n’a touché au site

Une mise à jour automatique, faite par WordPress ou par votre hébergeur, ou du code ajouté par un pirate, peut provoquer une erreur critique sans aucune intervention de votre part. Si le journal cite un fichier que vous ne connaissez pas, lisez notre guide du site piraté avant d’aller plus loin.

Questions fréquentes

L’erreur n’apparaît que dans l’administration, pas sur le site. Est-ce grave ?

Moins qu’une panne de tout le site, mais ne la laissez pas durer. Elle vient d’un code qui ne s’exécute que dans l’administration, par exemple une partie d’extension réservée au tableau de bord. Le site public fonctionne, mais vous ne pouvez plus gérer le site normalement, ni lancer vous-même les mises à jour. Traitez-la de la même façon, en commençant par le journal d’erreurs.

Le lien de récupération ne fonctionne plus. Comment en recevoir un autre ?

WordPress n’en envoie un nouveau que si l’erreur se reproduit dans l’administration ou sur la page de connexion, et pas plus d’un par jour, sauf si vous êtes sorti du mode de récupération entre-temps. Sans attendre, renommez par FTP le dossier de l’extension en cause, ou tout le dossier des extensions, comme expliqué plus haut. Cette méthode ne demande ni e-mail ni accès à l’administration.

Mon navigateur affiche « Ce site est inaccessible ». Est-ce la même panne ?

Non. Ce message vient de votre navigateur : il n’a reçu aucune réponse du serveur, ou la connexion a échoué. Avec une erreur critique, le serveur répond, et c’est WordPress qui affiche son message. Vérifiez d’abord que votre nom de domaine n’a pas expiré, puis essayez d’ouvrir le site avec les données mobiles de votre téléphone, pour savoir si le problème vient de votre réseau.

« Il y a eu une erreur critique sur ce site » : la réparer pas à pas