TL;DRUne erreur 500 sur WordPress n'est qu'un symptôme : la cause se lit presque toujours dans les logs. Voici la méthode, dans l'ordre, pour la trouver sans aggraver la situation.

Ce que « erreur 500 » recouvre sur WordPress#

Le code HTTP 500 signifie que le serveur a rencontré une condition inattendue et n'a pas pu traiter la requête. Il ne dit rien de la cause. La théorie du protocole est détaillée dans notre article sur l'erreur HTTP 500, ses causes et ses solutions ; ici, on se concentre sur ce qui se passe quand le serveur exécute WordPress.

Sur WordPress, la même panne se présente sous plusieurs visages :

  • La page « Internal Server Error » ou « HTTP ERROR 500 » affichée par le navigateur ou par le serveur web (Apache, nginx) : PHP s'est arrêté avant que WordPress ne puisse répondre.
  • Le message d'erreur critique de WordPress, du type « Il y a eu une erreur critique sur ce site » (la formulation exacte varie selon la version et la langue) : WordPress a intercepté une erreur fatale PHP et affiche sa propre page.
  • La page blanche (« white screen of death ») : une erreur fatale s'est produite mais aucun message n'est affiché, souvent parce que l'affichage des erreurs est désactivé.
  • Une erreur 500 limitée à l'administration ou à une seule page : le fautif est alors presque toujours une extension ou une fonctionnalité précise.

Dans tous les cas, la démarche est la même : trouver l'erreur PHP réelle, puis isoler le composant responsable.

Le mode de récupération et le courriel d'alerte#

Depuis WordPress 5.2, un mécanisme de protection contre les erreurs fatales envoie un courriel à l'adresse d'administration du site (et à celle du super administrateur en multisite) lorsqu'une erreur fatale survient. Ce message contient un lien secret vers le mode de récupération. En cliquant dessus, un cookie est déposé dans votre navigateur ; vous vous connectez ensuite normalement. Pendant cette session, les extensions et thèmes qui provoquent l'erreur fatale sont mis en pause pour vous uniquement : les visiteurs continuent de voir le site cassé tant que le problème n'est pas résolu.

Le courriel indique généralement quelle extension ou quel thème est en cause. Depuis le tableau de bord en mode de récupération, vous pouvez désactiver ce composant, ce qui règle le problème pour tout le monde. Deux réserves pratiques :

  • Le courriel part vers l'adresse d'administrateur enregistrée dans WordPress. Si elle n'est plus relevée, ou si les courriels du site n'arrivent pas, vous ne verrez rien : vérifiez aussi les indésirables.
  • Ce mécanisme ne couvre pas tous les cas. Une erreur 500 due à un fichier .htaccess invalide, par exemple, se produit avant même que WordPress ne s'exécute.

Avant de toucher à quoi que ce soit#

1. Sauvegarder l'état actuel#

Même cassé, le site contient des données. Copiez les fichiers (au minimum wp-content et wp-config.php) et exportez la base de données. Un site en panne n'est pas un site sans valeur : un diagnostic hasardeux peut transformer une panne réversible en perte de données.

2. Lire les journaux d'erreurs#

C'est l'étape la plus rentable. Cherchez, dans cet ordre :

  • le journal d'erreurs PHP de votre hébergement (souvent un fichier error_log à la racine du site ou dans un dossier de logs, selon l'hébergeur ; le panneau d'hébergement l'indique) ;
  • les journaux du serveur web (Apache ou nginx), qui contiennent la ligne de l'erreur au moment de la requête ;
  • le fichier wp-content/debug.log, s'il a été activé (voir ci-dessous).

Une ligne du type « PHP Fatal error: Uncaught Error ... in /wp-content/plugins/nom-du-plugin/... » désigne directement le coupable : le chemin contient le nom du dossier de l'extension ou du thème. Une ligne « Allowed memory size ... exhausted » oriente vers la mémoire. Une erreur de syntaxe dans .htaccess apparaît, elle, dans le journal d'erreurs Apache.

3. Activer le débogage de WordPress, correctement#

Si les logs de l'hébergeur ne suffisent pas, WordPress sait écrire ses propres erreurs dans un fichier. Dans wp-config.php, avant la ligne « That's all, stop editing! », ajoutez :

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

Rôle de chaque ligne, d'après la documentation officielle :

  • WP_DEBUG active le mode débogage (il est à false par défaut) ;
  • WP_DEBUG_LOG enregistre les erreurs dans wp-content/debug.log (un chemin personnalisé peut aussi être fourni) ; il nécessite que WP_DEBUG soit actif ;
  • WP_DEBUG_DISPLAY à false évite d'afficher les erreurs dans les pages : vos visiteurs ne voient rien, tout part dans le journal.

Rechargez la page en erreur, puis lisez la fin de debug.log. La documentation de WordPress précise que ces outils sont conçus pour des installations locales ou de préparation et déconseille de les laisser sur un site en production. Une fois le problème identifié, remettez WP_DEBUG à false (ou retirez ces lignes) et supprimez ou protégez debug.log, qui peut contenir des chemins et des informations techniques.

Les causes classiques, de la plus à la moins probable#

Un plugin fautif#

C'est la cause la plus fréquente : mise à jour d'une extension, conflit entre deux extensions, extension incompatible avec la version de PHP. Si vous ne pouvez pas accéder au tableau de bord :

  1. En FTP ou SSH : renommez le dossier wp-content/plugins en wp-content/plugins-off. WordPress ne trouve plus les extensions et les désactive. Si le site revient, renommez le dossier à son nom d'origine, puis renommez les sous-dossiers un par un pour isoler l'extension coupable.
  2. Avec WP-CLI (si vous avez un accès SSH) :
wp plugin list --status=active
wp plugin deactivate nom-du-plugin
wp plugin deactivate --all

La commande wp plugin deactivate accepte un ou plusieurs noms d'extensions, ou l'option --all pour toutes les désactiver ; --exclude permet d'en épargner certaines. Après désactivation globale, réactivez les extensions une à une en testant le site à chaque fois. Si WP-CLI lui-même échoue à cause de l'extension fautive, l'option globale --skip-plugins empêche leur chargement pendant la commande.

Le thème#

Un thème (ou son fichier functions.php) peut aussi déclencher une erreur fatale, typiquement après une modification manuelle ou une mise à jour. Pour basculer sur un thème par défaut installé :

wp theme activate slug-du-theme-par-defaut

Sans WP-CLI, renommez le dossier du thème actif dans wp-content/themes : WordPress se rabat sur un thème par défaut s'il en trouve un. Si le site revient, l'origine est dans le thème ou dans le code qui y a été ajouté.

Un fichier .htaccess corrompu#

Sur un serveur Apache, une règle invalide dans .htaccess provoque une erreur 500 immédiate, y compris avant le chargement de WordPress. Symptôme typique : le journal d'erreurs Apache mentionne une directive inconnue ou une erreur de syntaxe. Renommez le fichier en .htaccess-old : si le site répond, régénérez-le depuis Réglages > Permaliens en enregistrant sans rien modifier. Voici le bloc par défaut d'une installation WordPress simple, d'après la documentation officielle :

# BEGIN WordPress

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Attention : si vous aviez ajouté des règles personnalisées (redirections, en-têtes, restrictions), elles étaient dans l'ancien fichier. Conservez-le pour les réintégrer une à une, en testant.

La limite de mémoire#

Une erreur « Allowed memory size of ... bytes exhausted » signifie qu'un script PHP a dépassé la directive memory_limit. Selon le manuel PHP, cette directive peut être modifiée dans php.ini, dans .htaccess, à l'exécution avec ini_set() ou dans la configuration du serveur, et la valeur -1 supprime toute limite (à éviter en production). Côté WordPress, la constante WP_MEMORY_LIMIT se règle dans wp-config.php :

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

WordPress tente par défaut d'allouer 40 Mo pour un site simple ; la constante n'a d'effet que si vous la fixez au-dessus de cette valeur, et certains hébergeurs empêchent tout relèvement automatique. WP_MAX_MEMORY_LIMIT concerne les tâches d'administration. La documentation prévient qu'augmenter la mémoire peut masquer la vraie cause : si une extension consomme des centaines de mégaoctets, relever la limite retarde le problème sans le résoudre.

Une version de PHP incompatible#

Après un changement de version de PHP côté hébergement (ou une mise à jour de WordPress qui exige une version plus récente), une extension ou un thème ancien peut générer des erreurs fatales. Le journal l'indique clairement : appel à une fonction supprimée, erreur de syntaxe dans un fichier de l'extension. Deux issues : mettre à jour ou remplacer le composant, ou repasser temporairement à la version de PHP précédente le temps de le faire. Le retour en arrière est une mesure de secours, pas une solution durable.

Les permissions de fichiers#

Des droits trop restrictifs (ou une propriété de fichiers modifiée après une restauration ou un transfert) empêchent PHP de lire des fichiers. La documentation de durcissement de WordPress recommande 755 pour les dossiers, 644 pour les fichiers, et 400 ou 440 pour wp-config.php. Comparez ces valeurs à celles de votre installation, sans jamais aller vers un 777 « pour tester » : c'est une faille de sécurité, pas un diagnostic.

Une mise à jour interrompue#

Pendant une mise à jour, WordPress crée un fichier .maintenance à la racine du site et le supprime à la fin. Si l'opération est interrompue (timeout, fermeture du navigateur, plusieurs mises à jour lancées ensemble), le site peut rester bloqué sur « Briefly unavailable for scheduled maintenance » (ou son équivalent français). Supprimez le fichier .maintenance (fichier caché : activez l'affichage des fichiers masqués dans votre client FTP), puis vérifiez que la mise à jour s'est bien terminée : supprimer le fichier ne prouve pas que les fichiers sont cohérents. Une mise à jour d'extension à moitié écrite peut, elle, provoquer une vraie erreur 500 ; réinstallez alors le composant depuis une source fiable.

La base de données#

Une table corrompue peut interrompre WordPress. WordPress propose un outil de réparation, activable dans wp-config.php :

define( 'WP_ALLOW_REPAIR', true );

La page se trouve ensuite à l'adresse /wp-admin/maint/repair.php de votre site. La documentation insiste : n'activez cette constante que si nécessaire et retirez-la dès que le problème est résolu, car tant qu'elle est active, la page est accessible sans être connecté. Faites toujours un export de la base avant.

Les quotas et limites de l'hébergement#

Enfin, si rien ne ressort côté WordPress, regardez côté hébergement : espace disque plein, quota d'inodes ou de processus atteint, limites de ressources PHP. Ces situations produisent des erreurs 500 sporadiques, souvent aux heures de forte affluence. Le panneau de votre hébergeur ou son support permettent de le confirmer. Si l'erreur est plutôt un 503, consultez notre article sur l'erreur HTTP 503.

Quelques scénarios types#

Les cas suivants sont des situations représentatives, décrites à titre d'illustration ; ce ne sont pas des témoignages.

Scénario 1 : erreur 500 juste après la mise à jour d'un plugin#

Le site répond en erreur critique immédiatement après une mise à jour. Le courriel d'alerte de WordPress nomme l'extension. Utilisez le lien du mode de récupération, désactivez l'extension, vérifiez le site, puis attendez un correctif ou cherchez une alternative. Si le courriel n'est pas arrivé, renommez son dossier en FTP.

Scénario 2 : page blanche après une modification de functions.php#

Une ligne ajoutée manuellement contient une erreur de syntaxe. debug.log indique le fichier et la ligne exacts. Annulez la modification (d'où l'intérêt de la sauvegarde préalable), ou activez un thème par défaut le temps de corriger.

Scénario 3 : erreur 500 sur toutes les pages, administration comprise, après édition du .htaccess#

Le journal Apache signale une directive non reconnue. Renommez le fichier, régénérez-le via Réglages > Permaliens, puis réintroduisez les règles personnalisées une par une.

Scénario 4 : erreur 500 uniquement en important un gros fichier ou en ouvrant une page lourde#

Le journal mentionne « Allowed memory size exhausted ». Relevez temporairement la mémoire, mais identifiez ce qui la consomme (extension d'import, constructeur de pages, requête lourde). Notre article sur le cache objet Redis ou Memcached sur WordPress aide à réduire la charge quand la lenteur en est l'origine.

Scénario 5 : site bloqué en maintenance après une mise à jour groupée#

Plusieurs mises à jour lancées ensemble ont dépassé le temps d'exécution. Supprimez .maintenance, puis relancez les mises à jour une par une, en commençant par celle qui a échoué.

Scénario 6 : erreur 500 après un passage à une version de PHP plus récente#

Le journal cite une fonction supprimée dans un vieux thème. Repassez à la version précédente de PHP pour remettre le site en ligne, puis mettez à jour ou remplacez le thème avant de retenter la migration sur un environnement de préparation.

Quand l'erreur 500 cache autre chose#

Si, malgré tout cela, le journal montre des fichiers inconnus, des noms de fichiers étranges ou du code obscurci dans wp-content, ne vous contentez pas de « faire revenir » le site : une compromission peut provoquer des erreurs 500. Consultez notre guide sur la récupération d'un site WordPress piraté.

Prévenir la prochaine erreur 500#

  • Un environnement de préparation (staging) : testez chaque mise à jour sur une copie du site avant la production, y compris les changements de version de PHP.
  • Des mises à jour une par une, avec vérification du site entre chaque. En cas de problème, le coupable est immédiatement connu.
  • Des sauvegardes testées : une sauvegarde qui n'a jamais été restaurée est une hypothèse. Vérifiez régulièrement qu'elle se restaure, base de données comprise, et conservez-la hors du serveur.
  • Une supervision : une sonde qui teste la page d'accueil et une page profonde vous alerte avant vos visiteurs, avec la consultation régulière des journaux d'erreurs.
  • Un parc d'extensions réduit : chaque extension est une source potentielle de panne. Retirez celles qui ne servent plus. Notre analyse des avantages et inconvénients de WordPress pour un site professionnel revient sur ce compromis.

Si vous préférez ne pas gérer ces opérations vous-même, notre page sur la maintenance évolutive WordPress présente l'accompagnement que nous proposons.

Questions fréquentes#

Que signifie « Il y a eu une erreur critique sur ce site » ?#

WordPress a intercepté une erreur fatale PHP, le plus souvent causée par une extension ou un thème. Un courriel envoyé à l'administrateur contient un lien vers le mode de récupération, qui met en pause le composant fautif pour votre session. Le journal d'erreurs précise la cause exacte.

Comment trouver la cause d'une erreur 500 sur WordPress ?#

Lisez d'abord le journal d'erreurs PHP de votre hébergement et ceux d'Apache ou nginx. Sinon, activez WP_DEBUG et WP_DEBUG_LOG dans wp-config.php avec WP_DEBUG_DISPLAY à false, puis lisez wp-content/debug.log. Désactivez le débogage ensuite.

Comment désactiver tous les plugins sans accéder à l'administration ?#

En FTP ou SSH, renommez le dossier wp-content/plugins pour que WordPress ne trouve plus les extensions. Avec WP-CLI, la commande wp plugin deactivate --all les désactive toutes. Réactivez-les ensuite une par une en testant le site.

Comment régénérer le fichier .htaccess de WordPress ?#

Renommez l'ancien fichier, puis ouvrez Réglages > Permaliens dans l'administration et enregistrez sans modifier : WordPress réécrit le bloc par défaut. Réintégrez ensuite vos règles personnalisées une par une.

Faut-il laisser WP_DEBUG activé sur un site en production ?#

Non. La documentation de WordPress déconseille de laisser ces outils sur un site en ligne. Activez-les le temps du diagnostic avec l'affichage désactivé, puis remettez WP_DEBUG à false.

Augmenter WP_MEMORY_LIMIT suffit-il à corriger une erreur 500 ?#

Seulement si le journal indique un dépassement de mémoire, et la valeur doit dépasser la valeur par défaut de WordPress pour avoir un effet. Cela peut masquer un composant trop gourmand : identifiez-le plutôt que de relever la limite indéfiniment.

Article rédigé le 29/09/2026 par l'équipe Websource à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.