Déboguer une erreur 500 sur WordPress : résoudre le problème

Sommaire

• Comprendre l’erreur 500 sur WordPress avant d’agir
• Activer le mode debug et consulter les logs pour un fatal error
• Fichier.htaccess corrompu et plugin en conflit
• Comment déboguer WordPress via les limites PHP et la version PHP
• Permissions, thème défaillant et réinstallation du core WordPress
• Foire aux questions

Chaque étape vise une cause précise, pour une erreur 500 wordpress traitée durablement, sans manipulation inutile.

Comprendre l’erreur 500 sur WordPress avant d’agir

Avant de modifier le moindre fichier, il faut cerner ce que recouvre réellement ce message d’erreur. Une 500 internal server error signale un problème côté serveur, donc au niveau de l’hébergement ou de l’exécution de WordPress, sans détail exploitable dans le navigateur.

Qu’est-ce qu’une erreur 500 et pourquoi elle survient

L’erreur 500 sur WordPress correspond à un arrêt brutal du script côté serveur. Le navigateur affiche alors un internal server error ou un http error 500, sans exposer les causes réelles. Le diagnostic révèle souvent plusieurs pistes : configuration défaillante, erreurs PHP, conflit de plugin, thème incompatible ou version PHP inadaptée.

• Fichier.htaccess corrompu : une erreur de syntaxe dans ce fichier peut bloquer tout le site WordPress, car la configuration du serveur n’est plus interprétée correctement.
• Mémoire PHP insuffisante : lorsque la mémoire PHP allouée est trop basse, certaines pages ou tâches lourdes cessent de répondre et déclenchent une erreur 500 WordPress.
• Plugin ou extensions incompatibles : après une mise à jour, un plugin peut provoquer une erreur 500 sur WordPress s’il n’est plus compatible avec le cœur, le thème ou la version de PHP.
• Version de PHP obsolète : une version PHP trop ancienne, ou au contraire trop récente pour certains composants, déclenche parfois des erreurs PHP fatales traduites en erreur http 500 ou en 500 internal server.

La panne vient souvent de détails moins visibles : délai d’exécution dépassé, fichier.maintenance resté en place après une mise à jour, ou ressource serveur saturée. Dès que l’incident apparaît, l’heure exacte et l’action effectuée juste avant donnent un repère utile pour résoudre une erreur 500 plus vite.

Premiers réflexes avant toute intervention technique

Avant d’ouvrir un client FTP, il faut écarter les faux signaux. Rechargez la page et attendez quelques minutes; tester depuis un autre navigateur ou un autre appareil permet d’écarter un incident temporaire sur l’hébergement. Vider le cache en parallèle permet d’écarter un affichage obsolète masquant une page déjà rétablie.

En parallèle, consultez l’état des services de l’hébergeur. OVH, o2switch ou Infomaniak publient généralement les incidents en cours, et la remise en ligne dépend parfois d’une intervention côté infrastructure plutôt que d’une correction sur le site WordPress.

Erreur 500, erreur 400 et autres statuts : bien faire la différence

L’erreur 400 n’a pas la même origine. Elle signale une requête mal formée côté client, alors que la 500 internal server error relève du serveur et de sa configuration. À l’inverse, une 404 indique qu’une ressource manque, sans remettre en cause le fonctionnement global du serveur.

Sans accès aux journaux, au fichier concerné ou aux traces d’erreurs PHP, le problème reste flou. Pour déboguer erreur 500, l’analyse des logs reste la première étape indispensable.

Activer le mode debug et consulter les logs pour un fatal error

Le débogage de l’erreur 500 dans WordPress s’appuie sur deux sources fiables : les logs côté hébergement et le fichier debug.log généré par WordPress. Dès que l’une de ces pistes est accessible, le message d’erreur devient exploitable et le diagnostic peut progresser.

Lire les logs serveur pour localiser l’erreur

La cause apparaît souvent dès la lecture du fichier error.log, selon la configuration de l’hébergeur. Ce fichier se trouve en général dans /logs ou dans wp-content, et il remonte la nature des erreurs PHP, le script en cause, parfois même la ligne exacte.

Avant toute modification, consultez ces journaux depuis le gestionnaire de fichiers du panneau d’hébergement ou en FTP.

Configurer WP_DEBUG dans wp-config.php

Lorsque les logs serveur restent inaccessibles, le mode débogage prend le relais. Un fatal error masqué sur une page blanche redevient visible après modification du fichier wp-config.php : remplacez define('WP_DEBUG', false) par define('WP_DEBUG', true).

• WP_DEBUG à true : active l’affichage des erreurs PHP et des alertes WordPress, ce qui rend lisible le message d’erreur bloquant.
• WP_DEBUG_LOG à true : crée un fichier debug.log dans wp-content, utile pour enregistrer les anomalies sans les afficher aux visiteurs.
• WP_DEBUG_DISPLAY à true : affiche les erreurs à l’écran pendant le diagnostic. À l’inverse, ce réglage doit être coupé en production.
• Permissions du dossier wp-content : si debug.log reste vide, la panne vient souvent de l’écriture bloquée par le serveur; un contrôle des droits du dossier, souvent en 755, s’impose selon la configuration.

Laisser le mode débogage actif sur un site en ligne expose des informations sensibles : chemins de fichier, configuration serveur et environnement d’hébergement. Dès la fin du diagnostic, WP_DEBUG doit repasser à false.

Le journal debug.log permet ensuite d’identifier le plugin ou le thème concerné, le fichier précis et la ligne qui déclenche le fatal error. Pour les cas plus lourds, déboguer erreur 500 sur l’accès à l’administration peut exiger une intervention directe côté serveur.

Fichier.htaccess corrompu et plugin en conflit

Deux causes reviennent en tête quand une erreur 500 WordPress apparaît côté logiciel : un fichier.htaccess mal formé et un plugin activé au mauvais moment. Ces deux problèmes se traitent via FTP, sans intervenir sur la base de données ni sur le cœur du site.

Régénérer le fichier.htaccess via FTP

Le débogage de l’erreur 500 WordPress commence souvent par ce fichier : un espace en trop, une directive incomplète ou une règle ajoutée par un outil de cache peut suffire à bloquer l’ensemble. La panne vient souvent de modifications automatiques faites après l’installation de certaines extensions de sécurité ou d’optimisation.

• Renommer le fichier : via FTP, renommez le fichier.htaccess en.htaccess-backup pour le neutraliser sans le perdre.
• Vérifier le comportement du site : si l’accès revient, les causes du problème se trouvent bien dans ce fichier.
• Générer un fichier propre : une fois le diagnostic posé, ouvrez Réglages → Permaliens dans WordPress puis enregistrez sans changer les options pour recréer un fichier valide.

À l’inverse, si l’erreur 500 WordPress persiste après régénération, le problème vient plus probablement d’un plugin incompatible.

Désactiver les plugins pour isoler le responsable

Une erreur serveur 500 Elementor, comme d’autres conflits après mise à jour, apparaît souvent lorsqu’un plugin ne suit plus la version PHP ou la version de WordPress en place. Pour corriger l’erreur 500, renommez le dossier /wp-content/plugins/ en /wp-content/plugins_old/ via FTP : si le site revient, le responsable se trouve bien parmi les extensions.

Dès la première intervention, il faut ensuite réactiver les extensions une par une afin d’identifier celle qui déclenche la panne. Si l’administration reste accessible, le menu Extensions → Extensions installées permet de désactiver chaque plugin sans FTP. En parallèle, Health Check & Troubleshooting sert à corriger une erreur 500 sur un site en production sans impacter les visiteurs.

Comment déboguer WordPress via les limites PHP et la version PHP

Quand les logs ne désignent aucun fichier précis et qu’aucun plugin n’apparaît en cause, le diagnostic révèle souvent un manque de ressources côté serveur ou une incompatibilité de version de PHP. Ces causes produisent un 500 internal server error difficile à interpréter sans contrôle préalable de la configuration du site WordPress et de l’hébergement.

Augmenter la mémoire PHP dans wp-config.php

Pour déboguer wordpress lors d’un blocage lié aux ressources, ajoutez define('WP_MEMORY_LIMIT', '256M'); dans wp-config.php, avant la ligne /* That’s all, stop editing! */. À l’inverse, augmenter cette valeur sans vérification masque parfois le problème : cette action ne corrige que les erreurs php et l’ erreur 500 wordpress liées à une allocation insuffisante.

• Valeur minimale recommandée : 256 Mo pour un site WordPress standard, à définir dans le fichier wp-config.php via FTP ou le gestionnaire de fichiers cPanel.
• WooCommerce et sites e-commerce : la mémoire PHP doit atteindre au minimum 512 Mo pour éviter un 500 internal pendant le panier ou la commande.
• Alternative via.user.ini : si la modification de wp-config.php reste sans effet, créez un fichier.user.ini à la racine avec memory_limit = 256M et max_execution_time = 300.
• Timeout PHP : une fois le problème traité, ramenez max_execution_time à 60 secondes pour ne pas couvrir de futurs ralentissements.

Vérifier la compatibilité de la version PHP active

Parmi les problèmes wordpress les plus fréquents après migration ou mise à jour automatique, les conflits de version php restent en tête. La panne vient souvent de là : une version de PHP obsolète, ou non compatible avec les extensions et le thème actif, peut provoquer une erreur 500 internal server sur tout le site.

WordPress recommande au minimum PHP 7.4 et préconise PHP 8.2 pour WordPress 6.x. En parallèle, le passage sur cette version demande une validation de chaque plugin, du thème et de leur configuration dans un environnement de staging, car une incompatibilité suffit à déclencher un internal server error.

La version active se vérifie depuis le panneau d’hébergement, notamment dans cPanel, ou via l’outil Santé du site. Dès que la version de php est confirmée comme cause du problème, revenir provisoirement à une branche stable permet de résoudre l’erreur 500 sans toucher aux fichiers cœur de WordPress. La remise en ligne dépend ensuite de la mise à jour progressive des extensions.

Permissions, thème défaillant et réinstallation du core WordPress

Quand les causes déjà testées ne donnent rien, le diagnostic révèle deux pistes solides : les droits d’accès sur chaque fichier et répertoire, puis le thème actif. Ces points passent souvent sous le radar. Pourtant, ils expliquent une part importante des cas de 500 internal server error, d’ internal server error et d’ erreur 500 wordpress sur un hébergement mutualisé.

Corriger les permissions des fichiers et répertoires

Après une migration, une restauration ou un changement de configuration, les permissions peuvent dériver. La panne vient souvent de là : PHP n’a plus les droits nécessaires pour exécuter un fichier, ce qui déclenche une erreur 500 internal server, parfois signalée comme 500 internal ou 500 internal server. Sur un hébergement OVH, ce schéma apparaît régulièrement dans les cas d’ erreur 500 wordpress ovh. Si les journaux affichent un message d’erreur de type « Permission denied », l’origine est alors confirmée par les logs.

• Répertoires en 755 : les dossiers WordPress se règlent en général sur 755, parfois 750 selon la configuration du serveur. La modification se fait depuis un client FTP ou depuis cPanel.
• Fichiers en 644 : chaque fichier doit en principe être en 644, ou 640 selon l’hébergement, afin de laisser le serveur lire et exécuter ce qu’il faut sans ouvrir trop d’accès.
• wp-config.php en 440 : ce fichier de configuration mérite un réglage plus strict, en 440 ou 400, pour limiter les risques de sécurité.

Une fois les droits remis en ordre, il faut recharger le site puis relire les logs. À l’inverse, si le code persiste malgré des permissions cohérentes, il faut déplacer le diagnostic vers le thème, un plugin ou les fichiers du cœur de WordPress.

Changer de thème ou réinstaller le core WordPress

Un thème défaillant suffit à provoquer une panne nette. Le même symptôme peut d’ailleurs apparaître avec un plugin, mais ici le test le plus propre consiste à basculer sur un thème par défaut. Si l’administration reste accessible, l’opération se fait depuis WordPress. Sinon, le changement passe par phpMyAdmin, en modifiant les champs template et stylesheet dans la table wp_options.

Si le site revient en ligne après ce basculement, la cause est identifiée : le thème en place n’est plus compatible avec la version php ou avec la version de WordPress installée. Une fois le diagnostic posé, il faut d’abord tenter sa mise à jour ou sa réinstallation propre. La remise en ligne dépend souvent de ce point précis, surtout après une montée de version côté serveur.

Quand le thème n’est pas en cause, il reste le core. Pour traiter une erreur 500 liée à des fichiers WordPress corrompus, il faut télécharger exactement la même version depuis wordpress.org, puis remplacer uniquement wp-admin et wp-includes via un client FTP. Le répertoire wp-content, qui contient le thème, les extensions et les médias, ne doit pas être écrasé.

Avant toute manipulation, une sauvegarde de la base de données reste indispensable.

Foire aux questions