Erreur 500 sur WordPress : Causes et solutions rapides

Dernière mise à jour : septembre 2026

L’erreur 500 — Internal Server Error — est la panne la plus courante et la plus opaque sur un site WordPress. La page affiche un message générique (« 500 Internal Server Error », une page blanche, ou le message WordPress « Il y a eu une erreur critique sur votre site »). Le serveur sait que quelque chose a échoué, mais le message au visiteur ne dit pas quoi. C’est au propriétaire du site — ou à la personne qui le maintient — de trouver la cause.

Sur WordPress, les erreurs 500 ont presque toujours une origine identifiable : un plugin incompatible, un fichier .htaccess corrompu, une limite mémoire PHP dépassée, une mise à jour qui s’est mal passée. Le diagnostic est méthodique, pas intuitif. Chaque cause a une signature dans les logs serveur, et chaque signature pointe vers une correction précise.

Ce qu’une erreur 500 signifie techniquement

Le code HTTP 500 appartient à la famille des erreurs serveur (5xx). Il indique que le serveur a rencontré une condition inattendue qui l’a empêché de traiter la requête. Ce n’est pas un problème de réseau, pas un problème de navigateur, pas un problème DNS — c’est le serveur lui-même qui échoue à générer la page demandée.

Sur un stack WordPress, la chaîne est la suivante : le serveur web (OpenLiteSpeed, Nginx, Apache) reçoit la requête, la transmet à PHP, PHP exécute WordPress (core, thème, plugins), WordPress interroge la base de données, puis renvoie le HTML au serveur web qui le sert au navigateur. L’erreur 500 peut survenir à n’importe quel maillon de cette chaîne — mais sur WordPress, c’est presque toujours au niveau de l’exécution PHP que ça casse.

Le message « 500 Internal Server Error » affiché dans le navigateur ne contient aucune information utile pour le diagnostic. L’information est dans les logs du serveur — le fichier error.log du serveur web et le log d’erreurs PHP. C’est toujours la première chose à consulter.

Lire les logs : le réflexe qui fait gagner du temps

Avant de toucher à quoi que ce soit — avant de désactiver des plugins, de modifier des fichiers, de chercher sur Google — lire le log d’erreurs. Sur un serveur géré via ServerAvatar, les logs sont accessibles dans le panneau de contrôle. En SSH, les emplacements standards :

# Log d'erreurs du serveur web (OpenLiteSpeed)
/usr/local/lsws/logs/error.log

# Log d'erreurs PHP (emplacement courant)
/var/log/php8.3-fpm/error.log

# Log WordPress (si WP_DEBUG_LOG est activé)
/chemin/vers/wordpress/wp-content/debug.log

La dernière entrée du log au moment de l’erreur 500 donne la cause exacte dans la majorité des cas : un fichier PHP qui ne peut pas être chargé, une fonction qui n’existe pas, une allocation mémoire qui dépasse la limite, une requête SQL qui échoue. Un message comme PHP Fatal error: Allowed memory size of 67108864 bytes exhausted pointe directement vers la cause — pas besoin de deviner.

Pour activer le log de débogage WordPress, ajouter ces lignes dans wp-config.php :

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

WP_DEBUG_DISPLAY à false empêche l’affichage des erreurs aux visiteurs — les erreurs sont écrites uniquement dans wp-content/debug.log. Sur un site en production, ne jamais laisser WP_DEBUG activé plus longtemps que nécessaire : le fichier de log grossit rapidement et certaines informations de débogage peuvent exposer des chemins de fichiers ou des détails de configuration.

Les causes fréquentes et leur diagnostic

Plugin incompatible ou défaillant

C’est la cause numéro un des erreurs 500 sur WordPress. Un plugin qui se met à jour et introduit un bug, un conflit entre deux plugins qui modifient les mêmes hooks, un plugin qui nécessite une version PHP que le serveur ne fournit pas. Le log d’erreurs PHP montre généralement un Fatal error avec le chemin du fichier responsable — et le nom du plugin est dans le chemin : /wp-content/plugins/nom-du-plugin/fichier.php.

Si le tableau de bord WordPress est inaccessible (ce qui est souvent le cas lors d’une erreur 500), la désactivation se fait en renommant le dossier du plugin via SSH ou le gestionnaire de fichiers :

cd /chemin/vers/wordpress/wp-content/plugins
mv nom-du-plugin nom-du-plugin.disabled

Si le site revient, le plugin est la cause. La question suivante est : est-ce un bug dans la mise à jour (vérifier le changelog et les forums de support), un conflit avec un autre plugin (réactiver les plugins un par un pour identifier le conflit), ou une incompatibilité PHP (vérifier les exigences du plugin).

Quand le log ne pointe pas vers un plugin spécifique, la méthode par élimination s’impose : renommer le dossier plugins en plugins.disabled pour désactiver tous les plugins d’un coup. Si le site revient, réactiver les plugins un par un jusqu’à identifier le coupable. C’est systématique, pas élégant — mais fiable.

Fichier .htaccess corrompu

Le fichier .htaccess à la racine de WordPress contient les règles de réécriture d’URL (permaliens) et les directives ajoutées par les plugins (cache, sécurité, redirections). Un plugin qui écrit mal dans ce fichier, une modification manuelle avec une erreur de syntaxe, ou une mise à jour interrompue — et le serveur ne peut plus interpréter les règles. Résultat : erreur 500 sur toutes les pages.

Le diagnostic est simple : renommer le fichier et tester.

cd /chemin/vers/wordpress
mv .htaccess .htaccess.backup

Si le site revient (la page d’accueil fonctionne, mais les sous-pages renvoient des 404 — ce qui est normal sans les règles de réécriture), le .htaccess était la cause. Régénérer un fichier propre depuis le tableau de bord WordPress : Réglages → Permaliens → cliquer sur Enregistrer sans rien modifier. WordPress réécrit le .htaccess avec les règles de base.

Note : sur OpenLiteSpeed, les fichiers .htaccess sont interprétés nativement — contrairement à Nginx qui les ignore. Les règles ajoutées par les plugins de cache ou de sécurité restent fonctionnelles, mais une règle incompatible avec la syntaxe supportée par OpenLiteSpeed peut provoquer une erreur 500 là où Apache l’aurait tolérée.

Limite mémoire PHP dépassée

WordPress recommande un minimum de 256 Mo de mémoire PHP. Un site avec un page builder, WooCommerce, et une dizaine de plugins peut facilement dépasser cette limite — surtout lors d’opérations lourdes (import de contenu, génération de miniatures, calcul de rapports).

Le log montre : PHP Fatal error: Allowed memory size of XXXXX bytes exhausted.

La correction immédiate : augmenter la limite dans wp-config.php.

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

Si cela ne suffit pas, modifier la configuration PHP directement (dans php.ini ou la configuration du pool PHP-FPM) :

memory_limit = 512M

Mais augmenter la mémoire ne traite que le symptôme. Si un site a besoin de plus de 256 Mo pour afficher une page, le problème de fond est un plugin mal optimisé ou un thème qui charge des ressources excessives. L’augmentation de la limite achète du temps — elle ne remplace pas l’audit de ce qui consomme cette mémoire.

Erreur de syntaxe dans wp-config.php ou functions.php

Une modification manuelle d’un fichier PHP avec une erreur de syntaxe — un point-virgule manquant, une parenthèse non fermée, un guillemet mal échappé — provoque une erreur fatale PHP. Le log est explicite : Parse error: syntax error, unexpected ... in /chemin/fichier.php on line XX.

La correction : accéder au fichier via SSH ou le gestionnaire de fichiers (le tableau de bord WordPress est inaccessible), aller à la ligne indiquée, corriger l’erreur de syntaxe. Si le fichier est trop modifié pour être récupéré, le restaurer depuis la dernière sauvegarde.

Ce scénario est la raison pour laquelle les modifications de code doivent être testées sur un environnement de staging avant d’être appliquées en production — pas directement dans l’éditeur de thème WordPress, qui peut rendre le site inaccessible en une seule sauvegarde.

Version PHP incompatible

Un thème ou un plugin qui utilise des fonctionnalités d’une version PHP récente (8.2, 8.3) échouera sur un serveur qui exécute une version antérieure. Inversement, un ancien plugin qui utilise des fonctions dépréciées ou supprimées dans PHP 8.x provoquera des erreurs fatales après une mise à jour PHP.

Le log montre typiquement : Fatal error: Uncaught Error: Call to undefined function ou des erreurs liées à des types stricts ou des paramètres nommés non supportés.

La correction dépend du sens de l’incompatibilité : mettre à jour le plugin/thème pour qu’il supporte la version PHP du serveur, ou — en dernier recours — rétrograder temporairement la version PHP le temps de résoudre le conflit. Sur un serveur géré via ServerAvatar, le changement de version PHP se fait en quelques clics.

Fichiers WordPress core corrompus

Plus rare, mais pas exceptionnel : un fichier du core WordPress modifié (par un malware, une mise à jour interrompue, ou une manipulation maladroite). Le diagnostic passe par la vérification de l’intégrité des fichiers via WP-CLI :

wp core verify-checksums

Cette commande compare les fichiers du core avec les versions officielles de WordPress. Tout fichier modifié ou manquant est signalé. La correction : réinstaller le core WordPress sans toucher à wp-content (thèmes, plugins, uploads) ni à wp-config.php.

wp core download --force --skip-content

Si des fichiers du core ont été modifiés par un malware, c’est un signe qu’il faut aller plus loin : un audit complet de sécurité du serveur et des comptes d’accès est nécessaire.

Problème de base de données

Une table corrompue, une connexion à la base de données qui échoue, ou un timeout sur une requête SQL lourde peuvent déclencher une erreur 500. Le message dans les logs peut varier : Error establishing a database connection (erreur WordPress spécifique, pas toujours un 500), ou des erreurs MySQL dans le log PHP.

WordPress inclut un outil de réparation de base de données. Pour l’activer, ajouter dans wp-config.php :

define('WP_ALLOW_REPAIR', true);

Puis accéder à https://mon-site.fr/wp-admin/maint/repair.php. L’outil propose une réparation simple et une réparation avec optimisation. Retirer la ligne de wp-config.php après la réparation — cette page est accessible sans authentification.

Quand l’erreur 500 est intermittente

Une erreur 500 permanente est paradoxalement plus facile à diagnostiquer qu’une erreur intermittente. Quand le site fonctionne la plupart du temps et plante de manière aléatoire, les causes sont différentes.

Ressources serveur insuffisantes. Un pic de trafic, un cron WordPress qui se déclenche en même temps qu’un archivage, un bot qui crawle agressivement — le serveur manque de mémoire ou de processus PHP disponibles. Le log montre des erreurs de type 503 mélangées à des 500, ou des timeouts PHP-FPM. La solution passe par l’ajustement des paramètres PHP-FPM (nombre de workers, mémoire par processus) et la mise en place d’un cache de page pour réduire la charge PHP.

Timeout PHP. Une opération qui dépasse le temps d’exécution maximum de PHP (max_execution_time, par défaut 30 secondes) est interrompue. Sur les pages de contenu, 30 secondes est largement suffisant. Mais un import WooCommerce, une conversion d’image en masse, ou un plugin de sauvegarde qui traite une base de données volumineuse peut dépasser cette limite. Augmenter le timeout pour les opérations d’administration tout en le maintenant court pour le front-end.

Plugin de cache mal configuré. Un plugin de cache qui tente de servir un fichier cache corrompu, ou qui entre en conflit avec le cache natif d’OpenLiteSpeed — le résultat est une erreur 500 sur certaines pages seulement, ou une erreur qui apparaît et disparaît en fonction de l’état du cache. Vider complètement le cache (fichiers et cache objet) est le premier test. Si le problème disparaît, c’est la configuration du cache qu’il faut revoir — pas un autre plugin.

Prévention : ne pas attendre la prochaine erreur 500

Une erreur 500 sur un site en production, c’est du trafic perdu, des ventes manquées, et — si la panne dure — un impact sur le référencement. Les mesures préventives ne sont pas optionnelles sur un site professionnel.

Sauvegardes restaurables. La première ligne de défense. Une sauvegarde complète (fichiers + base de données) quotidienne, stockée hors du serveur, dont la restauration est testée régulièrement. Quand une erreur 500 résiste au diagnostic, restaurer la dernière sauvegarde saine est souvent la voie la plus rapide vers la résolution — à condition que la sauvegarde existe et qu’elle fonctionne.

Mises à jour sur staging. Tester chaque mise à jour (core, plugins, thème, PHP) sur un environnement de staging avant de l’appliquer en production élimine la cause la plus fréquente d’erreur 500 : la mise à jour qui casse le site. Le staging reproduit l’environnement de production — même version PHP, mêmes plugins, mêmes données — et permet de vérifier que tout fonctionne avant de toucher au site live.

Monitoring de disponibilité. Un outil de monitoring qui vérifie la disponibilité du site toutes les minutes et envoie une alerte en cas d’indisponibilité. L’erreur 500 est détectée en moins d’une minute au lieu d’être découverte par un client ou un prospect.

Ces mesures font partie d’une stratégie de maintenance structurée — préventive et corrective. L’erreur 500 est un incident technique, pas une fatalité. Avec les bons outils et les bons réflexes, le temps entre la panne et la résolution se mesure en minutes, pas en heures.

FAQ

L’erreur 500 peut-elle être causée par l’hébergeur ?

Oui. Un serveur mutualisé surchargé, une maintenance réseau non planifiée, une mise à jour PHP imposée par l’hébergeur, ou un pare-feu applicatif (WAF) trop strict qui bloque des requêtes légitimes — ces causes sont côté hébergeur, pas côté WordPress. Si le log d’erreurs est vide et que rien n’a changé côté WordPress, contacter l’hébergeur. Sur un serveur dédié ou VPS managé, le contrôle est total — les causes côté hébergeur se limitent aux pannes hardware ou réseau, qui sont rares.

Faut-il restaurer une sauvegarde ou chercher la cause ?

Si le site est critique (e-commerce, génération de leads active) et que l’erreur dure plus de quelques minutes sans cause identifiée dans les logs, la restauration est la bonne décision — remettre le site en ligne d’abord, diagnostiquer ensuite. Pour un site vitrine sans urgence, prendre le temps de diagnostiquer la cause évite de la reproduire. Dans les deux cas, conserver les fichiers et logs de la version en erreur avant de restaurer — ils seront nécessaires pour comprendre ce qui s’est passé et éviter la récidive.

Une erreur 500 peut-elle affecter le référencement du site ?

Oui, si elle dure. Google tolère des indisponibilités courtes — quelques minutes ne posent pas de problème. Mais si Googlebot rencontre des erreurs 500 de manière répétée sur une période de plusieurs heures ou jours, il réduit la fréquence de crawl et peut déclasser les pages affectées. Le rapport de couverture dans Google Search Console signale les erreurs serveur rencontrées par Googlebot. Un pic d’erreurs 500 dans ce rapport, même résolu depuis, indique que le site a été affecté pendant cette période.

Votre site WordPress affiche une erreur 500 et vous ne trouvez pas la cause ?