Blog
2026
Erreur 500 WordPress – comment déboguer...

Erreur 500 WordPress – comment déboguer votre site web ?

Une erreur 500 WordPress ne révèle pas sa cause. Découvrez comment vérifier les logs, activer WP_DEBUG, identifier les problèmes liés aux extensions, au thème, à PHP et au fichier .htaccess, puis les corriger en toute sécurité.

Vous ouvrez votre site WordPress et, au lieu de la page d’accueil, du tableau de bord ou de la page produit, vous voyez 500 Internal Server Error. Le message est frustrant par son manque de précision. Il vous indique que le serveur n’a pas pu terminer la requête, mais il ne vous dit pas si le problème a été causé par une extension, un thème, une erreur PHP, la configuration du serveur ou des ressources épuisées.

La façon la plus efficace de traiter une erreur 500 WordPress n’est donc pas de deviner, mais de collecter des informations de diagnostic et de lire les logs. Dans ce guide, vous apprendrez à déboguer WordPress en toute sécurité, à activer ses outils de débogage intégrés, à interpréter les messages d’erreur courants et à isoler le problème jusqu’à un composant précis.

Vous apprendrez également quoi faire lorsque vous ne pouvez pas accéder à wp-admin, comment le mode de récupération de WordPress peut vous aider après une erreur PHP fatale, et quand le problème doit être transmis à votre hébergeur ou à votre développeur.

Que signifie une erreur 500 dans WordPress ?

HTTP 500 Internal Server Error est une erreur générale côté serveur. Elle signifie que le serveur a reçu la requête du navigateur, mais qu’il a rencontré une condition inattendue qui l’a empêché de générer une réponse valide.

La spécification HTTP n’attribue pas une cause précise à une réponse 500. Il s’agit essentiellement d’une erreur serveur générique, ce qui explique pourquoi le message affiché dans le navigateur contient généralement très peu d’informations de diagnostic utiles. Vous pouvez en savoir plus sur ce code de statut dans la documentation MDN sur HTTP 500.

Sur un site WordPress, les causes courantes incluent :

une erreur PHP fatale dans une extension, un thème ou du code personnalisé,
un conflit après la mise à jour de WordPress, d’une extension ou d’un thème,
une incompatibilité avec la version de PHP utilisée par le serveur,
des règles incorrectes dans le fichier .htaccess,
une limite de mémoire PHP épuisée,
un script qui dépasse son temps d’exécution maximal,
des permissions de fichiers ou de répertoires incorrectes,
des fichiers WordPress manquants ou corrompus,
un problème de configuration du serveur ou de PHP,
un déploiement échoué ou une mise à jour incomplète,
des modifications malveillantes ou non autorisées des fichiers du site.

Une erreur 500 n’affecte pas nécessairement l’ensemble du site. Elle peut se produire uniquement lorsque vous ouvrez wp-admin, enregistrez une page, traitez une commande, téléversez une image, lancez une importation, exécutez une tâche planifiée ou appelez un endpoint REST API particulier.

Notez l’action exacte qui déclenche l’erreur. Il sera ainsi beaucoup plus facile de faire correspondre l’échec à l’entrée correspondante dans le log du serveur ou de WordPress.

Avant de déboguer WordPress, protégez votre site

Avant de modifier des fichiers ou la configuration, déterminez ce qui s’est passé immédiatement avant l’apparition de l’erreur. Une modification récente est souvent l’indice le plus rapide.

WordPress a-t-il été mis à jour ?
Une extension ou un thème a-t-il été installé ou mis à jour ?
La version de PHP a-t-elle été modifiée ?
Du code PHP personnalisé a-t-il été ajouté ?
Le fichier functions.php, wp-config.php ou .htaccess a-t-il été modifié ?
Le site a-t-il été migré ou restauré à partir d’une sauvegarde ?
Le problème a-t-il commencé pendant une importation, une sauvegarde ou un autre processus gourmand en ressources ?

Avant de modifier des fichiers, créez une sauvegarde à la fois des fichiers du site et de la base de données. Si le site a une importance commerciale, envisagez de reproduire le problème sur un environnement de staging avant d’apporter des modifications plus importantes en production.

Soyez prudent avec la restauration d’une ancienne sauvegarde comme première réaction. Sur une boutique en ligne active ou un site avec espace membres, restaurer toute la base de données peut également supprimer les nouvelles commandes, les comptes, les soumissions de formulaires et le contenu créés après la sauvegarde.

Bonne pratique. Modifiez une seule chose à la fois et testez le site après chaque changement. Désactiver plusieurs extensions, changer PHP et remplacer .htaccess simultanément peut permettre au site de fonctionner à nouveau, mais vous ne saurez pas quel changement a réellement corrigé le problème.

Commencez par le log d’erreurs du serveur

Le log d’erreurs du serveur est généralement le meilleur point de départ. Selon votre environnement d’hébergement, il peut être disponible via un control panel d’hébergement, un gestionnaire de fichiers, SSH ou un service de gestion des logs.

Recherchez un fichier error.log ou un log d’erreurs PHP/serveur web équivalent, puis reproduisez le problème dans un deuxième onglet du navigateur. Actualisez ensuite le log et vérifiez les entrées créées au même moment que la réponse HTTP 500.

Les messages utiles contiennent souvent des expressions comme :

PHP Fatal error – PHP a arrêté l’exécution à cause d’une erreur critique,
Uncaught Error – une erreur n’a pas été gérée par l’application,
Uncaught TypeError – PHP a reçu ou renvoyé un type inattendu,
Allowed memory size exhausted – la limite de mémoire PHP a été atteinte,
Maximum execution time exceeded – le script s’est exécuté trop longtemps,
Parse error ou syntax error – PHP ne peut pas analyser une partie du code,
Permission denied – l’application ne peut pas accéder à un fichier ou répertoire requis.

Faites particulièrement attention aux chemins de fichiers. Par exemple, une erreur faisant référence à :

/wp-content/plugins/example-plugin/includes/example.php

suggère fortement que l’extension est impliquée. Cela ne prouve pas automatiquement que l’extension elle-même est défectueuse. La cause réelle peut toujours être un conflit avec une autre extension, le thème, le cœur de WordPress ou la version de PHP.

N’analysez pas uniquement la dernière ligne. Une erreur fatale peut être précédée d’avertissements ou d’une autre exception qui explique mieux ce qui s’est passé.

Comment activer le débogage de WordPress

WordPress inclut son propre système de débogage. L’interrupteur principal est la constante WP_DEBUG dans le fichier wp-config.php.

Pour dépanner un site, il est généralement plus sûr de consigner les erreurs dans un log plutôt que d’afficher des détails techniques aux visiteurs. Ajoutez ou mettez à jour les paramètres suivants dans wp-config.php :

define( 'WP_DEBUG', true ); 

define( 'WP_DEBUG_LOG', true ); 

define( 'WP_DEBUG_DISPLAY', false ); 

@ini_set( 'display_errors', 0 );

Placez ces définitions avant la ligne qui termine la section de configuration modifiable de wp-config.php.

Lorsque WP_DEBUG_LOG est défini sur true, WordPress écrit normalement les informations de débogage dans :

/wp-content/debug.log

Reproduisez maintenant l’action qui provoque l’erreur et inspectez debug.log. La documentation WordPress permet également de configurer WP_DEBUG_LOG avec un chemin de log personnalisé. Consultez la documentation officielle actuelle sur le débogage de WordPress pour plus de détails.

Important : la documentation officielle de WordPress recommande d’utiliser les outils de débogage principalement dans des environnements de développement ou de staging. Ne laissez pas le débogage activé indéfiniment sur un site en production.

Après le dépannage, désactivez à nouveau le débogage :

define( 'WP_DEBUG', false );

Assurez-vous également que les erreurs PHP ne sont pas affichées publiquement. Les messages d’erreur peuvent révéler des chemins absolus sur le serveur, des noms d’extensions et d’autres détails techniques que les visiteurs n’ont pas besoin de voir.

Pourquoi debug.log n’existe-t-il pas ?

Le fichier peut ne pas apparaître tant que WordPress n’a rien à consigner. Après avoir activé le débogage, reproduisez à nouveau l’action qui échoue.

Si debug.log est toujours absent, vérifiez le log d’erreurs PHP du serveur. Certains échecs se produisent avant que WordPress puisse initialiser son propre mécanisme de journalisation, et les permissions de fichiers peuvent également empêcher WordPress de créer le log ou d’y écrire.

Vérifiez le mode de récupération de WordPress

WordPress inclut le mode de récupération, qui peut aider lorsqu’une erreur PHP fatale empêche l’accès normal au site. WordPress prend en charge ce mécanisme depuis la version 5.2.

Lorsque WordPress détecte certaines erreurs PHP fatales pendant une requête de page normale, il peut envoyer un e-mail à l’administrateur du site. Le message peut contenir des informations sur le composant qui a déclenché l’échec ainsi qu’un lien spécial permettant à un administrateur de se connecter avec le mode de récupération activé.

Dans le mode de récupération, l’extension ou le thème problématique peut être mis en pause pour votre session administrateur afin que vous puissiez examiner le site et corriger le problème sans utiliser immédiatement SFTP ou un gestionnaire de fichiers.

Si vous voyez le message WordPress Une erreur critique est survenue sur ce site, vérifiez l’adresse e-mail de l’administrateur et le dossier spam. N’oubliez pas que le mode de récupération ne gère pas tous les types d’échec, et que l’e-mail lui-même peut ne pas vous parvenir.

Vous trouverez plus de détails dans la documentation officielle du mode de récupération de WordPress.

Comment corriger les causes les plus courantes d’une erreur 500 WordPress

Une fois les logs vérifiés, utilisez le message d’erreur pour réduire le champ d’investigation. Les scénarios suivants couvrent de nombreuses erreurs 500 WordPress parmi les plus courantes.

Une extension provoque l’erreur 500

Si l’erreur a commencé immédiatement après l’installation ou la mise à jour d’une extension et que le log pointe vers son répertoire, désactivez d’abord cette extension.

Si le tableau de bord WordPress reste accessible, désactivez-la depuis l’écran Extensions. Si wp-admin renvoie également une erreur 500, utilisez SFTP ou le gestionnaire de fichiers de votre hébergeur et renommez temporairement le répertoire de l’extension, par exemple :

/wp-content/plugins/example-plugin 

/wp-content/plugins/example-plugin-disabled

WordPress ne pourra plus charger cette extension. Si le site recommence à fonctionner, vérifiez les prérequis système de l’extension, les notes de compatibilité et les mises à jour récentes avant de la réactiver.

Si vous disposez de SSH et de WP-CLI, vous pouvez également désactiver une extension depuis la ligne de commande :

wp plugin deactivate plugin-slug

Vous pouvez désactiver toutes les extensions standard à des fins de diagnostic avec :

wp plugin deactivate --all

Si le site fonctionne avec toutes les extensions désactivées, réactivez-les une par une et testez après chaque activation. Sur un site en production, utilisez cette méthode avec prudence, car la désactivation d’extensions peut supprimer temporairement des fonctions importantes telles que les paiements, les formulaires, la mise en cache ou les fonctions de sécurité.

Le thème actif provoque une erreur fatale

Un thème peut provoquer le même type d’échec PHP qu’une extension. C’est particulièrement probable après la modification de functions.php, l’ajout d’un snippet personnalisé ou le changement de version de PHP.

Si le log pointe vers votre thème actif, annulez d’abord la modification de code la plus récente. Lorsque c’est nécessaire, passez temporairement à un thème connu comme fonctionnel. Ne supprimez pas le thème actuel avant de l’avoir sauvegardé et d’avoir confirmé la cause.

Le fichier .htaccess contient une règle invalide

Sur les environnements basés sur Apache, une directive invalide dans .htaccess peut générer une erreur serveur avant que WordPress ait fini de se charger.

Si le problème a commencé après la modification de ce fichier, faites-en une copie et renommez-le temporairement :

.htaccess 

.htaccess-backup

Si le site commence à fonctionner, vous avez considérablement réduit le périmètre du problème. Une fois l’accès à WordPress rétabli, l’enregistrement des paramètres des permaliens peut recréer les règles de réécriture standard de WordPress.

N’écrasez pas aveuglément le fichier d’origine s’il contient des règles de sécurité supplémentaires, des redirections ou une configuration propre à l’application. Comparez les règles et restaurez uniquement ce qui est nécessaire.

N’oubliez pas non plus que .htaccess est spécifique aux configurations de serveurs web compatibles. Les sites fonctionnant sur Nginx, par exemple, utilisent une configuration serveur plutôt que des règles .htaccess de style WordPress.

L’erreur est apparue après un changement de PHP

Une ancienne extension, un ancien thème ou du code personnalisé peut utiliser une fonctionnalité qui n’est plus compatible avec la version de PHP configurée pour le site. L’inverse peut également se produire : une extension plus récente peut nécessiter une version de PHP plus récente que celle actuellement utilisée par le serveur.

Vérifiez dans le log d’erreurs le fichier et la fonction concernés, puis comparez les exigences de WordPress, du thème actif et des extensions.

Si l’échec a commencé immédiatement après un changement de version de PHP, revenir temporairement à la version qui fonctionnait auparavant peut aider à confirmer le diagnostic. Considérez cela comme une étape de diagnostic ou de récupération à court terme, et non comme une raison de conserver indéfiniment un logiciel non pris en charge. La bonne solution consiste à mettre à jour, remplacer ou corriger le composant incompatible.

La mémoire PHP est épuisée

Si le log contient :

Allowed memory size exhausted

le processus a essayé d’utiliser plus de mémoire que PHP n’était autorisé à allouer.

Augmenter la limite de mémoire peut être approprié si la charge de travail nécessite réellement plus de ressources, mais ne partez pas du principe qu’une limite plus élevée corrige la cause racine. Une croissance soudaine de la mémoire peut être causée par une boucle dans une extension, une opération coûteuse sur la base de données, une importation volumineuse, une tâche de traitement d’images ou un code personnalisé défectueux.

Vérifiez quelle requête a causé le problème et si l’utilisation de la mémoire a augmenté après une mise à jour ou une modification de configuration précise.

Un script dépasse le temps d’exécution

Le message :

Maximum execution time exceeded

signifie que PHP a arrêté un processus qui prenait trop de temps. Cela peut se produire pendant des importations, des sauvegardes, des tâches d’optimisation, des requêtes API, le traitement d’images ou des opérations de base de données inefficaces.

Augmenter la limite de temps peut aider pour des tâches longues légitimes, mais identifiez d’abord pourquoi le processus a besoin d’autant de temps. Un timeout peut être un symptôme plutôt que le problème réel.

Les permissions de fichiers sont incorrectes

Un propriétaire ou des permissions incorrects peuvent empêcher PHP ou le serveur web de lire ou d’exécuter les fichiers requis.

Des valeurs comme 644 pour les fichiers et 755 pour les répertoires sont courantes dans de nombreux environnements d’hébergement, mais elles ne doivent pas être considérées comme des paramètres universels à imposer sur chaque serveur. La configuration correcte dépend de l’architecture du serveur et du modèle de propriété.

Si les permissions ont changé de manière inattendue, cherchez pourquoi. Des changements inexpliqués dans les fichiers du site peuvent également justifier un audit de sécurité.

Des fichiers du cœur de WordPress sont manquants ou corrompus

Une mise à jour interrompue, une erreur de déploiement ou une modification manuelle peut laisser des fichiers du cœur de WordPress incomplets.

Si les logs pointent vers des fichiers du cœur et que le dépannage des extensions ou du thème n’explique pas le problème, comparez l’installation WordPress avec une copie propre de la même version. Avec WP-CLI, les administrateurs expérimentés peuvent également vérifier les checksums du cœur de WordPress.

N’écrasez pas wp-config.php ni le répertoire wp-content lorsque vous remplacez les fichiers du cœur de WordPress.

Comment déboguer une erreur 500 lorsque wp-admin ne fonctionne pas

Un tableau de bord WordPress défectueux ne vous empêche pas de diagnostiquer le site. Vous pouvez toujours travailler via le système de fichiers, le control panel d’hébergement ou SSH.

Une séquence pratique est la suivante :

Vérifiez le log d’erreurs du serveur.
Vérifiez si WordPress a envoyé un e-mail de mode de récupération.
Créez une sauvegarde actuelle si possible.
Activez WP_DEBUG_LOG sans afficher publiquement les erreurs.
Reproduisez la requête qui échoue.
Lisez error.log et wp-content/debug.log.
Si le log identifie une extension, désactivez cette extension via SFTP, un gestionnaire de fichiers ou WP-CLI.
Si l’erreur pointe vers le thème, annulez la modification récente ou changez temporairement de thème.
Si le problème a suivi un changement de PHP, vérifiez la compatibilité.
Si .htaccess a été modifié récemment, testez-le séparément.
Examinez les erreurs de mémoire, de temps d’exécution et de permissions uniquement lorsque les logs pointent dans ces directions.

Cet ordre est plus fiable que la désactivation aléatoire de composants, car chaque étape tente de préserver les éléments de preuve concernant l’échec initial.

Quand devez-vous contacter votre hébergeur ou votre développeur ?

Certaines erreurs 500 WordPress peuvent être corrigées en quelques minutes. D’autres nécessitent un accès aux logs au niveau serveur, à la configuration ou au code de l’application.

Contactez votre hébergeur lorsque les éléments disponibles pointent vers l’environnement d’hébergement, par exemple :

le log d’erreurs du serveur ne vous est pas accessible,
plusieurs sites sur le même service échouent en même temps,
PHP lui-même ne semble pas démarrer correctement,
l’erreur est causée par une configuration au niveau serveur que vous ne pouvez pas modifier,
les permissions ou le propriétaire ne peuvent pas être corrigés depuis votre compte,
vous suspectez des limites de ressources ou un autre problème d’infrastructure.

Contactez un développeur lorsque les logs identifient du code PHP défectueux, un conflit d’extension/thème ou une intégration personnalisée qui doit être corrigée.

Pour accélérer le dépannage, fournissez :

l’URL exacte qui renvoie l’erreur 500,
l’heure approximative à laquelle l’erreur s’est produite,
l’action qui déclenche le problème,
la date ou l’heure à laquelle le problème est apparu pour la première fois,
les détails des changements récents d’extension, de thème, de WordPress ou de PHP,
la section pertinente du log d’erreurs du serveur,
la section pertinente de wp-content/debug.log,
une liste des actions de dépannage que vous avez déjà effectuées.

Un horodatage est particulièrement utile. Il permet à la personne qui analyse le problème de faire correspondre votre requête à une entrée de log précise au lieu de parcourir des milliers de messages sans rapport.

Cela signifie que le serveur a rencontré un problème inattendu lors du traitement d’une requête. Le statut HTTP 500 lui-même n’identifie pas la cause. Dans WordPress, les causes courantes incluent les erreurs PHP, les conflits d’extensions ou de thèmes, les versions de PHP incompatibles, les règles serveur invalides, les ressources épuisées et les problèmes de configuration.

Commencez par le log d’erreurs du serveur ou de PHP et reproduisez la requête qui échoue. Les entrées créées au même moment que la réponse HTTP 500 identifient souvent le fichier, l’extension, le thème ou la limite de ressources concerné.

Dans wp-config.php, définissez WP_DEBUG sur true, WP_DEBUG_LOG sur true et WP_DEBUG_DISPLAY sur false. Cela écrit normalement les informations de débogage de WordPress dans wp-content/debug.log sans afficher d’erreurs techniques aux visiteurs.

Avec le paramètre standard WP_DEBUG_LOG activé, le fichier est normalement créé sous wp-content/debug.log. Il peut ne pas apparaître tant que WordPress n’a pas une erreur, un avertissement ou une notice à y écrire.

Oui. Une erreur PHP fatale ou un conflit de compatibilité dans une extension est une cause courante. Si le log pointe vers une extension, désactivez-la via le tableau de bord, WP-CLI ou en renommant temporairement son répertoire lorsque wp-admin n’est pas disponible.

Non. Les outils de débogage WordPress sont principalement destinés au développement et au dépannage. Désactivez WP_DEBUG lorsque l’investigation est terminée et évitez d’afficher publiquement les erreurs PHP sur un site en production.

Erreur 500 WordPress – diagnostiquez la cause avant de modifier le site

Une erreur 500 Internal Server Error vous indique que quelque chose a échoué sur le serveur, mais le navigateur ne peut pas vous dire quoi. Les outils de dépannage les plus importants sont donc le log d’erreurs du serveur, le log de débogage de WordPress et les informations sur les changements effectués immédiatement avant l’échec.

Commencez par les preuves. Reproduisez le problème, comparez les horodatages et identifiez le fichier ou le processus concerné. Ensuite seulement, passez à la désactivation d’une extension, au test du thème, à la vérification de .htaccess, à la validation de la compatibilité PHP ou à l’ajustement des limites de ressources.

Une fois le site à nouveau fonctionnel, désactivez le débogage, vérifiez à la fois le frontend et wp-admin, testez les fonctions critiques comme les formulaires ou le paiement, et assurez-vous que la cause sous-jacente a réellement été corrigée plutôt que simplement masquée.

Lire la documentation sur le débogage de WordPress