Erreur critique et erreur 500 WordPress : causes et remèdes

L’erreur critique WordPress et l’erreur 500 ont presque toujours la même origine : une erreur PHP fatale, provoquée par une extension, le thème, un manque de mémoire ou une version de PHP incompatible. Pour réparer, on identifie d’abord le coupable, grâce à l’e-mail de récupération envoyé par WordPress ou au journal du mode débogage, puis on le désactive, depuis l’administration ou par FTP. Vos contenus, eux, sont intacts dans la base de données.

Voici la démarche dans l’ordre où je la suis, de la plus simple à la plus technique. Arrêtez-vous dès que le site revient, et notez ce qui a fonctionné.

Que veulent dire ces messages ?

« Il y a eu une erreur critique sur ce site. » C’est le message qu’affiche WordPress quand une erreur PHP fatale interrompt le chargement d’une page. Il remplace l’ancien « écran blanc », une page totalement vide. Il invite souvent à consulter la boîte de réception de l’adresse d’administration.

« Erreur 500 » ou « Internal Server Error ». Ce message vient du serveur. Il signifie que le serveur n’a pas pu produire la page, sans dire pourquoi. Sur un site WordPress, les causes sont les mêmes que pour l’erreur critique, auxquelles s’ajoutent un fichier .htaccess défectueux ou un réglage du serveur.

Un écran blanc sans aucun message. Même famille : une erreur fatale dont l’affichage est masqué.

Dans les trois cas, le message ne donne pas la cause. Il faut aller la chercher.

Qu’est-ce qui a changé juste avant la panne ?

Cette première question est souvent la plus efficace. Un site tombe rarement en panne sans raison. Qu’est-ce qui s’est passé juste avant ?

• une mise à jour d’extension, de thème ou de WordPress, lancée par vous ou automatiquement ;
• l’installation d’une nouvelle extension ;
• une modification du fichier functions.php du thème, souvent un bout de code copié depuis un tutoriel ;
• un changement de version de PHP par l’hébergeur, parfois annoncé dans un e-mail passé inaperçu ;
• un déménagement du site chez un autre hébergeur.

Prenons un cas type : un plombier de Lamballe met à jour son extension de formulaire un vendredi soir, et le lundi matin, son site affiche l’erreur critique. La réponse à « qu’est-ce qui a changé ? » tient alors en une ligne, et le diagnostic aussi. Si l’erreur n’apparaît que sur certaines pages (le panier, un formulaire, l’administration), c’est un autre indice à noter.

Étape 1 : utiliser l’e-mail de récupération de WordPress

Depuis la version 5.2, WordPress détecte les erreurs fatales et envoie un e-mail à l’adresse d’administration du site, celle qui figure dans Réglages > Général. Ce message désigne l’extension ou le thème en cause et contient un lien vers le mode de récupération.

Ce lien ouvre une session d’administration où l’élément fautif est mis en pause, pour vous seul. Vous pouvez alors aller dans Extensions, désactiver l’extension signalée ou appliquer une mise à jour corrective si elle existe, puis quitter le mode de récupération. Le lien n’est valable qu’un temps limité.

Deux pièges fréquents :

1. L’e-mail n’arrive pas. L’adresse d’administration est celle d’un ancien prestataire, ou le serveur envoie mal les e-mails et le message part en indésirables. Vérifiez les dossiers spam de toutes les adresses possibles. Pour l’avenir, la constante RECOVERY_MODE_EMAIL, ajoutée dans wp-config.php, permet de désigner une autre adresse pour ces alertes.
2. Le fichier désigné n’est pas toujours la cause. Une extension peut planter parce qu’une autre a été mise à jour. Désactiver remet le site en ligne ; comprendre évite la rechute.

Étape 2 : activer le mode débogage (WP_DEBUG)

Sans l’e-mail, le journal d’erreurs de WordPress donne la même information, en plus précis. Connectez-vous en FTP, ou par le gestionnaire de fichiers de votre hébergement, et téléchargez d’abord une copie du fichier wp-config.php situé à la racine du site. Ouvrez-le, cherchez la ligne define( 'WP_DEBUG', false ); et remplacez-la par :

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

Ces lignes doivent rester au-dessus de la ligne « C’est tout, ne touchez pas à ce qui suit ! ». Rechargez la page en erreur, puis ouvrez le fichier wp-content/debug.log. Cherchez la ligne qui commence par PHP Fatal error. Elle donne le message et le chemin du fichier fautif, par exemple wp-content/plugins/nom-de-l-extension/…. Le nom du dossier désigne l’extension ou le thème en cause.

Le réglage WP_DEBUG_DISPLAY à false évite d’afficher les erreurs à vos visiteurs. Une fois le problème réglé, remettez WP_DEBUG à false et supprimez debug.log : ce fichier est souvent lisible depuis le web et révèle des informations sur votre installation.

Si debug.log reste vide, l’erreur se produit peut-être avant le démarrage de WordPress. Le journal d’erreurs du serveur, accessible dans l’espace client de la plupart des hébergeurs, prend alors le relais.

Étape 3 : désactiver les extensions par FTP

Quand l’administration est inaccessible, on désactive les extensions sans elle. Dans wp-content, renommez le dossier plugins en plugins-off. WordPress ne trouve plus aucune extension et les traite comme désactivées.

1. Rechargez le site. S’il revient, le problème vient d’une extension.
2. Connectez-vous à l’administration et ouvrez la page Extensions : WordPress y enregistre la désactivation.
3. Renommez le dossier en plugins.
4. Réactivez les extensions une par une, en rechargeant le site entre chaque. Celle qui fait revenir l’erreur est la coupable.

Si le journal désigne déjà une extension, inutile de tout couper : renommez seulement son dossier. Avec un accès SSH, la commande wp plugin deactivate nom-de-l-extension fait la même chose.

Sur une boutique WooCommerce ou un site bâti avec un constructeur de pages, tout désactiver laisse temporairement le site sans panier ou sans mise en page. Rien n’est perdu, tout revient à la réactivation, mais faites-le à une heure creuse.

Étape 4 : écarter le thème

Si les extensions ne sont pas en cause, testez le thème. Dans wp-content/themes, renommez le dossier du thème actif (ou du thème enfant, s’il y en a un). WordPress bascule alors sur un thème par défaut de la famille « Twenty », à condition qu’il soit présent dans le dossier. Si le site revient, même avec une autre allure, le thème est en cause : le plus souvent une modification récente de functions.php ou une mise à jour incompatible.

Étape 5 : vérifier le fichier .htaccess

Pour une erreur 500 qui touche tout le site, administration comprise, le fichier .htaccess est un suspect classique sur les serveurs Apache. Une règle ajoutée par une extension de cache ou de sécurité, ou une directive que le serveur ne comprend pas, suffit à tout bloquer.

1. Renommez .htaccess, à la racine, en .htaccess-old. Le nom commence par un point : activez l’affichage des fichiers cachés dans votre logiciel FTP si vous ne le voyez pas.
2. Rechargez le site. La page d’accueil devrait revenir ; les autres pages peuvent afficher une erreur 404, c’est normal à ce stade.
3. Dans l’administration, ouvrez Réglages > Permaliens et cliquez sur « Enregistrer les modifications » sans rien changer. WordPress recrée un .htaccess propre.
4. Si l’ancien fichier contenait des règles personnalisées (redirections, sécurité), reprenez-les une à une pour trouver celle qui bloquait.

Sur un serveur Nginx, ce fichier n’est pas utilisé : la configuration se règle côté hébergeur.

Désactiver remet le site en ligne. Comprendre évite la rechute.

Étape 6 : augmenter la limite de mémoire PHP

Si le journal affiche Allowed memory size of … bytes exhausted, PHP a manqué de mémoire. Cela arrive avec les constructeurs de pages, les boutiques WooCommerce ou les imports volumineux. Dans wp-config.php, au même endroit que les lignes de débogage, ajoutez :

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

Pour l’administration, la constante équivalente est WP_MAX_MEMORY_LIMIT. Ces réglages ne peuvent pas dépasser la limite fixée par l’hébergeur (memory_limit). Si rien ne change, elle se règle dans l’espace client de l’hébergement, ou sur demande au support. Gardez un œil critique : une extension qui dévore toute la mémoire a souvent un défaut qu’une limite plus haute ne fait que masquer.

Étape 7 : contrôler la version de PHP

Les hébergeurs font évoluer PHP pour des raisons de sécurité. Un thème ou une extension ancienne peut alors appeler des fonctions qui n’existent plus. Le journal affiche typiquement Call to undefined function suivi d’un nom comme create_function(), supprimée en PHP 8.

La version utilisée apparaît dans Outils > Santé du site, onglet Infos, et se change le plus souvent dans l’espace client de l’hébergement. Revenir temporairement à la version précédente peut remettre le site en ligne dans l’urgence. Ce retour en arrière n’achète qu’un sursis : les anciennes versions de PHP ne reçoivent plus de correctifs de sécurité, et l’hébergeur finira par les retirer. La correction durable consiste à mettre à jour ou à remplacer l’élément incompatible.

Et si aucune de ces étapes ne suffit ?

Plus rare, mais possible :

• Des fichiers du cœur corrompus, après une mise à jour interrompue. On remplace les dossiers wp-admin et wp-includes par ceux d’une archive officielle de la même version, sans toucher à wp-content ni à wp-config.php.
• Une base de données endommagée. WordPress propose un outil de réparation, qu’on active temporairement avec la constante WP_ALLOW_REPAIR avant d’ouvrir la page wp-admin/maint/repair.php.
• Des droits de fichiers incorrects après une migration : certains serveurs refusent d’exécuter un fichier aux permissions trop ouvertes.
• Un problème côté serveur : disque plein, service en panne, limite de ressources atteinte. Le support de l’hébergeur le voit dans ses journaux.
• Un piratage. Du code injecté peut provoquer des erreurs fatales. Si vous repérez des fichiers inconnus ou des extensions aux noms étranges, lisez que faire quand un site WordPress est piraté.

Quelle piste suivre selon le symptôme ?

Que faut-il éviter pendant la réparation ?

• Réinstaller WordPress entièrement ou supprimer des dossiers au hasard. L’erreur n’a pas touché vos contenus ; une fausse manœuvre, si.
• Restaurer une sauvegarde sans avoir compris. Vous reviendrez au même point à la prochaine mise à jour. La restauration a sa place quand la cause est identifiée et qu’aucune correction n’est disponible tout de suite.
• Modifier un fichier sans copie préalable, qu’il s’agisse de wp-config.php ou de .htaccess.
• Laisser le mode débogage actif une fois le site réparé.

Comment éviter la prochaine erreur critique ?

La plupart des erreurs critiques surviennent au moment d’une mise à jour appliquée directement sur le site en ligne. La parade est connue : une sauvegarde avant chaque mise à jour, et des mises à jour testées sur une copie avant d’arriver sur le vrai site. Je détaille la méthode dans sauvegarder et mettre à jour WordPress sans casser son site. C’est aussi ce que je fais pour les sites que je suis en maintenance WordPress.

Questions fréquentes

L’erreur critique WordPress efface-t-elle mes contenus ?

Non. Vos pages, articles, produits et commandes sont stockés dans la base de données, que l’erreur ne touche pas. Le site ne s’affiche plus, mais tout est là. Raison de plus pour éviter les manipulations radicales.

Puis-je réparer une erreur 500 sans logiciel FTP ?

Oui, le plus souvent. La plupart des hébergeurs proposent un gestionnaire de fichiers dans leur espace client, qui permet de renommer un dossier ou de modifier wp-config.php. Sans aucun accès à l’hébergement, il ne reste que l’e-mail de récupération : récupérer cet accès devient alors la priorité.

Les mises à jour automatiques peuvent-elles provoquer une erreur critique ?

Oui. Une mise à jour automatique appliquée la nuit peut casser le site sans que personne ne le voie avant le matin. WordPress envoie un e-mail récapitulatif après ses mises à jour automatiques : lisez-le, il dit ce qui a changé et oriente le diagnostic.

Le site est toujours en erreur, ou vous préférez ne pas toucher au FTP ? Le dépannage WordPress se fait à distance, partout en France : je cherche la cause, je répare et je vous explique ce qui s’est passé. Si votre activité est bloquée, appelez le 06 75 19 96 92 ; sinon, écrivez-moi. Devis gratuit, réponse sous 48 h ouvrées.

Thomas, fondateur d’ArWeb

Développeur WordPress et consultant SEO depuis 2010, à Jugon-les-Lacs. Il conçoit, référence et maintient des sites pour des entreprises, associations et communes, en Bretagne et partout en France.