Comment corriger une erreur 500 sur WordPress ?

Une erreur 500 WordPress, ou 500 Internal Server Error, indique que le serveur a rencontré une condition inattendue qui l’empêche de traiter correctement la requête. Le code 500 reste volontairement générique : l’origine réelle peut se situer dans PHP, une extension, un thème, une configuration serveur, les permissions de fichiers ou les ressources disponibles.

Cet article s’appuie sur mon propre retour d’expérience en dépannage de sites WordPress. L’objectif est de suivre une méthode ordonnée : identifier la portée de la panne, lire les journaux d’erreurs, isoler la cause puis appliquer la correction adaptée.

Note d’actualisation — août 2026 : cet article a été revu afin d’actualiser les méthodes de diagnostic d’une erreur 500 WordPress, notamment l’analyse des logs serveur, le débogage WordPress, les ressources PHP et les différences entre environnements Apache et Nginx.

Comprendre l’erreur 500 Internal Server Error

Une erreur 500 signifie que le serveur n’a pas réussi à terminer le traitement demandé, sans disposer d’un code HTTP plus précis pour décrire le problème. Sur WordPress, elle peut notamment correspondre à une erreur PHP fatale, un conflit d’extension, une modification de configuration, une limite mémoire atteinte ou un composant défaillant.

Une compromission peut également provoquer des erreurs serveur, mais elle ne doit pas être présumée sans indice. Je recommande d’abord d’examiner les logs et les dernières modifications effectuées. Ce diagnostic évite de multiplier les manipulations inutiles et aide à remonter rapidement à la cause réelle.

Notre reco : commencez par conserver une trace de l’heure de la panne, de l’URL concernée et de la dernière action réalisée sur le site. Ces trois informations accélèrent fortement l’analyse des journaux serveur.

Distinguer l’erreur 500 des autres codes 5xx

Les codes HTTP 5xx signalent des erreurs côté serveur, mais ils ne décrivent pas tous la même situation. Les plus utiles à distinguer sur un site WordPress sont :

• 500 Internal Server Error : erreur serveur générique lorsqu’aucun statut plus précis ne convient.
• 501 Not Implemented : fonctionnalité ou méthode non prise en charge par le serveur.
• 502 Bad Gateway : réponse invalide reçue par un serveur intermédiaire.
• 503 Service Unavailable : service temporairement indisponible.
• 504 Gateway Timeout : délai d’attente dépassé entre serveurs.

Les causes fréquentes d’une erreur 500

Sur WordPress, une erreur 500 correspond le plus souvent à un incident d’exécution plutôt qu’à une cause unique. Les journaux serveur permettent généralement de distinguer rapidement l’origine du problème et d’éviter les corrections au hasard.

• Une erreur PHP fatale : une fonction inexistante, une incompatibilité avec la version de PHP, une erreur de syntaxe ou une exception non gérée peut interrompre l’exécution de WordPress.
• Un plugin ou un thème défaillant : une mise à jour, un conflit entre composants ou du code personnalisé peut déclencher l’erreur sur tout le site ou seulement sur certaines pages.
• Une configuration serveur incorrecte : une directive Apache invalide, une règle de réécriture inadaptée ou un paramètre PHP incohérent peut entraîner une réponse HTTP 500.
• Une limite de ressources atteinte : mémoire PHP épuisée, temps d’exécution dépassé ou processus trop coûteux. Le journal d’erreurs indique généralement la ressource concernée.
• Des permissions de fichiers incorrectes : le serveur peut refuser l’accès à un fichier ou à un répertoire lorsque ses droits ne correspondent pas à la configuration de l’hébergement.
• Une anomalie dans wp-config.php ou la base de données : une modification récente, une table endommagée ou une requête défaillante peut également provoquer une erreur serveur.
• Une compromission du site : du code injecté ou des fichiers modifiés peuvent provoquer des erreurs PHP. Cette hypothèse mérite toutefois d’être confirmée par les logs et les indices de sécurité.

Diagnostiquer une erreur 500 WordPress

Une erreur 500 se résout plus efficacement en partant des faits plutôt qu’en testant successivement des corrections au hasard. Commencez par déterminer la portée de la panne, puis confrontez ce constat aux journaux serveur et aux dernières modifications du site.

Vérifier si l’erreur 500 est localisée ou généralisée

Lorsqu’une erreur 500 survient sur le site d’un client, je commence toujours par vérifier si le problème touche une seule URL, l’ensemble du site, l’administration WordPress ou plusieurs services hébergés au même endroit. Cette vérification évite de lancer un diagnostic WordPress complet lorsqu’une panne d’infrastructure est déjà identifiée.

Testez plusieurs pages, puis consultez la page de statut officielle de votre hébergeur. Si plusieurs services sont affectés, suivez l’incident en cours. Si le problème reste limité à votre site ou à une fonctionnalité précise, revenez aux logs et aux dernières modifications réalisées.

Consulter les journaux d’erreurs

Consultez en priorité le journal d’erreurs PHP ou serveur fourni par votre hébergeur. Chez Kinsta, MyKinsta donne notamment accès aux logs d’erreurs et d’accès. Recherchez une entrée correspondant à l’heure de la panne et à l’URL concernée : erreur PHP fatale, mémoire épuisée, timeout, fichier introuvable ou problème de compatibilité.

Activer temporairement le débogage WordPress

Lorsque les logs serveur ne suffisent pas, WordPress peut enregistrer ses propres messages de débogage. La documentation officielle de WordPress décrit les constantes prévues à cet effet. Sur un site en production, mieux vaut journaliser les erreurs sans les afficher aux visiteurs :

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

Après le diagnostic, désactivez ce mode. Query Monitor reste utile lorsque l’administration WordPress fonctionne encore, mais il ne remplace pas les logs lorsqu’une erreur 500 bloque entièrement le site.

Corriger une erreur 500 WordPress

Une fois le diagnostic amorcé, appliquez les corrections dans un ordre cohérent. Commencez par les changements récents et les composants les plus faciles à isoler avant d’intervenir sur la configuration serveur ou la base de données.

Vérifier les plugins et le thème

Si l’erreur 500 apparaît après l’installation ou la mise à jour d’une extension, commencez par ce composant. Lorsque l’administration WordPress reste inaccessible, utilisez un accès SFTP ou le gestionnaire de fichiers de l’hébergeur pour renommer temporairement le dossier du plugin concerné dans wp-content/plugins.

Si l’origine n’est pas évidente, désactivez les extensions puis réactivez-les progressivement en contrôlant les logs entre chaque étape. Notre guide consacré aux conflits entre plugins ou thèmes WordPress détaille cette méthode.

Si WordPress détecte une erreur PHP fatale liée à une extension ou au thème, son mode de récupération peut transmettre à l’adresse d’administration un lien temporaire. Cette session spéciale facilite l’accès au tableau de bord afin de désactiver le composant en cause sans masquer le problème aux autres visiteurs.

Vérifier la mémoire PHP et les ressources

Une erreur PHP fatale peut apparaître lorsque la mémoire allouée à un processus est épuisée. Le log contient alors généralement un message explicite du type Allowed memory size exhausted. Dans ce cas, identifiez d’abord le composant qui consomme la ressource avant d’augmenter la limite.

Une hausse de mémoire peut être légitime pour certaines opérations, mais elle ne corrige pas un plugin défaillant, une boucle ou une requête anormalement coûteuse. Le message présent dans les logs doit guider la décision.

Contrôler la configuration serveur et .htaccess

Sur un serveur Apache, une directive incorrecte dans .htaccess peut provoquer une erreur 500. Vérifiez en priorité les modifications récentes et évitez de remplacer le fichier au hasard sans sauvegarde préalable.

Les environnements Nginx, comme ceux utilisés chez Kinsta, ne reposent pas sur un fichier .htaccess fonctionnel. Dans ce cas, concentrez le diagnostic sur les logs, PHP et la configuration serveur fournie par l’hébergeur.

Contrôler le fichier wp-config.php

Une faute de syntaxe ou une constante mal écrite dans wp-config.php peut bloquer l’exécution de WordPress. Si ce fichier a été modifié récemment, comparez-le à une version fonctionnelle ou revenez sur la dernière intervention. Utilisez SFTP ou le gestionnaire de fichiers de l’hébergeur plutôt qu’un accès FTP non chiffré.

Des identifiants de base de données incorrects produisent généralement le message spécifique « Error establishing a database connection ». Ce cas mérite donc un diagnostic distinct plutôt que d’être assimilé automatiquement à une erreur 500.

Vérifier les permissions des fichiers et dossiers

Des permissions inadaptées peuvent empêcher le serveur web de lire ou d’exécuter correctement certains éléments de WordPress. La documentation de sécurisation WordPress cite couramment des droits 755 pour les répertoires et 644 pour les fichiers, mais la configuration exacte dépend de l’hébergeur et du propriétaire des processus.

Évitez d’appliquer récursivement des permissions larges comme 777. Si les logs signalent un refus d’accès, comparez les droits du fichier concerné à ceux des autres fichiers WordPress fonctionnels ou consultez la documentation de l’hébergement.

Vérifier la base de données WordPress

Une erreur liée à la base de données WordPress doit être confirmée par les logs PHP ou MySQL avant toute réparation. Sauvegardez l’état actuel, identifiez la table ou la requête concernée et évitez une restauration globale tant que la cause n’est pas comprise.

Rechercher une compromission ou un logiciel malveillant

Si les logs, l’intégrité des fichiers ou les événements de sécurité suggèrent une compromission, recherchez aussi les signes d’une injection de spam SEO WordPress. Ne vous contentez pas de supprimer un fichier suspect. Il faut identifier le vecteur d’entrée, nettoyer les éléments touchés, corriger la vulnérabilité exploitée et renouveler les accès potentiellement compromis. Notre guide pour sécuriser son site WordPress détaille les principales couches de protection.

Restaurer une sauvegarde fonctionnelle

La restauration est pertinente lorsqu’une modification récente a clairement déclenché la panne ou lorsqu’un retour à un état connu fait partie du plan de remédiation. Utilisez une sauvegarde complète et restaurable, puis vérifiez que la cause de l’incident a bien été corrigée avant de remettre le site en production.

Chez Evolyon, les sauvegardes de l’hébergement Kinsta et les points de restauration utilisés lors des opérations de maintenance offrent plusieurs niveaux de retour arrière. Pour approfondir ce sujet, consultez notre guide pour sauvegarder son site WordPress.

Prévenir les erreurs 500 WordPress

Une maintenance régulière réduit le risque d’erreurs 500 sans les rendre impossibles. Les actions les plus utiles consistent à maintenir WordPress et ses composants à jour, tester les changements sensibles en staging, disposer de sauvegardes restaurables et surveiller les erreurs serveur.

• Maîtrisez les mises à jour et évitez l’accumulation de composants obsolètes ou inutilisés.
• Surveillez les logs et la disponibilité afin de repérer rapidement une nouvelle erreur ou une dégradation.
• Testez les changements sensibles en préproduction, notamment les mises à jour majeures et les modifications techniques.
• Conservez des sauvegardes restaurables et vérifiez régulièrement votre capacité de retour arrière.
• Suivez les vulnérabilités WordPress et les bugs WordPress susceptibles d’affecter les composants du site.

Notre reco : lorsqu’une erreur 500 apparaît juste après une modification, commencez par les logs et cette dernière action. Une démarche ordonnée évite d’empiler plusieurs corrections et de perdre le véritable point de départ de la panne.

Restaurer durablement la stabilité du site

Une erreur 500 n’indique pas sa propre cause. La méthode la plus fiable consiste à vérifier la portée de la panne, lire les journaux, rapprocher l’erreur des dernières modifications puis intervenir sur le composant réellement concerné. Cette démarche évite les manipulations inutiles et réduit le temps d’indisponibilité.

Si le diagnostic reste incertain ou si l’erreur touche un site critique, notre article consacré au choix d’un prestataire de maintenance WordPress constitue un point de repère utile. L’équipe de notre agence web Lyon intervient également sur les pannes WordPress et accompagne ses clients grâce à une assistance WordPress 7j/7.