Erreur 500 sur WordPress : un message qui ne dit rien de sa cause
L’erreur 500 (« Internal Server Error ») est la plus frustrante des erreurs WordPress parce qu’elle ne décrit rien : contrairement à un message PHP classique, elle ne pointe ni un fichier, ni une ligne, ni un plugin. Le serveur a rencontré un problème qui l’empêche de traiter la requête, et s’arrête là. La page peut afficher un message générique du serveur web, une page totalement blanche, ou parfois un mélange des deux selon la configuration.
Ce n’est pas une erreur WordPress au sens strict — c’est un code de statut HTTP générique renvoyé par le serveur quand quelque chose casse en cours d’exécution, avant que WordPress ait pu produire une page complète. La cause se trouve presque toujours dans la couche applicative (plugin, thème, cœur WordPress) plutôt que dans une panne d’infrastructure, ce qui la distingue d’une erreur 502 (serveur en amont injoignable) ou 503 (serveur temporairement surchargé ou en maintenance) : ces deux-là signalent un problème réseau ou de charge, pas un script qui échoue.
Faire apparaître le vrai message d’erreur
Avant de corriger quoi que ce soit, il faut voir ce que WordPress cache par défaut. En production, l’affichage des erreurs PHP est désactivé pour ne pas exposer de détails techniques aux visiteurs — ce qui rend l’erreur 500 muette côté navigateur alors que le serveur, lui, sait exactement ce qui a échoué.
Deux méthodes pour révéler le message réel :
Activer WP_DEBUG_LOG dans wp-config.php, en ajoutant ces lignes avant la ligne /* C'est tout, ne touchez pas à ce qui suit ! */ :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG_DISPLAY à false évite d’afficher l’erreur aux visiteurs pendant que le diagnostic est en cours — seul le fichier wp-content/debug.log reçoit le détail. Reproduisez l’erreur en rechargeant la page concernée, puis ouvrez ce fichier : la dernière entrée indique le fichier, la ligne et la nature exacte du problème (fonction non définie, mémoire épuisée, erreur de syntaxe).
Consulter les journaux d’erreur du serveur (accessibles depuis cPanel, Plesk ou le panneau propriétaire de l’hébergeur, sous une section « Journaux » ou « Erreurs ») donne la même information sans toucher au code, utile si l’accès à wp-config.php est temporairement impossible. Sur un VPS ou un serveur dédié, le fichier se trouve directement dans les logs Apache ou Nginx (error.log).
Les causes les plus fréquentes, par ordre de probabilité
Un plugin ou un thème incompatible est la cause numéro un, en particulier après une mise à jour récente — la sienne ou celle de WordPress lui-même. Une fonction appelée par un plugin qui n’existe plus dans la nouvelle version du cœur, ou un conflit entre deux extensions qui déclarent la même fonction, provoque une erreur fatale que le serveur traduit en 500.
Une limite de mémoire PHP (memory_limit) trop basse pour la charge du site vient ensuite : un thème riche en fonctionnalités ou un plugin de e-commerce peut consommer plus de mémoire que l’hébergement n’en alloue par défaut, avec une erreur qui apparaît de façon intermittente plutôt que systématique — un signe distinctif utile au diagnostic.
Un fichier .htaccess corrompu, fréquemment après une modification manuelle ou l’installation d’un plugin de cache ou de sécurité qui y ajoute des règles, empêche Apache de traiter correctement la requête avant même d’atteindre WordPress. Des fichiers cœur WordPress corrompus ou incomplets, à la suite d’une mise à jour interrompue ou d’un transfert de fichiers incomplet lors d’une migration, produisent le même symptôme. Une incompatibilité de version PHP, en particulier après un changement d’hébergeur ou une mise à jour de PHP côté serveur, fait planter du code écrit pour une version antérieure du langage.
Corriger selon la cause identifiée
Si le journal pointe un plugin : désactivez-le depuis wp-admin si l’accès fonctionne encore, ou renommez son dossier via FTP/gestionnaire de fichiers (wp-content/plugins/nom-du-plugin en nom-du-plugin-désactive) — WordPress désactive automatiquement tout plugin dont le dossier n’est plus trouvé, sans perte de configuration. Si le message ne cible aucun plugin en particulier, désactivez-les tous d’un coup en renommant le dossier plugins entier, puis réactivez-les un par un jusqu’à reproduire l’erreur : celui qui la déclenche est identifié en quelques minutes.
Si le thème est en cause, basculez temporairement vers un thème par défaut de WordPress (Twenty Twenty-Four ou équivalent) via FTP en renommant le dossier du thème actif dans wp-content/themes — WordPress revient automatiquement au thème par défaut disponible.
Si la mémoire est épuisée, augmentez la limite dans wp-config.php :
define( 'WP_MEMORY_LIMIT', '256M' );
Cette limite reste plafonnée par la configuration PHP du serveur (memory_limit dans php.ini) : si l’hébergement impose une limite plus basse au niveau serveur, la valeur définie dans WordPress ne peut pas la dépasser — contactez l’hébergeur pour l’augmenter côté serveur si le plafond global est trop bas pour le site.
Si le .htaccess est suspect, renommez-le temporairement (.htaccess.bak) puis régénérez-en un neuf depuis Réglages > Permaliens dans wp-admin, en cliquant simplement sur « Enregistrer » sans rien modifier : WordPress recrée le fichier avec les règles de réécriture standard.
Si les fichiers cœur sont suspectés corrompus, téléchargez une archive neuve de la même version de WordPress depuis wordpress.org et remplacez les dossiers wp-admin et wp-includes par leur contenu — ces deux dossiers ne contiennent jamais de personnalisation et peuvent être remplacés sans risque pour le contenu du site, à condition de ne pas toucher à wp-content ni à wp-config.php.
Quand contacter l’hébergeur directement
Si aucune des causes ci-dessus n’est identifiable dans les journaux, ou si l’erreur survient uniquement sous forte charge (plusieurs visiteurs simultanés, import volumineux), le problème peut venir d’une limite serveur non visible depuis WordPress : quota de processus PHP simultanés, timeout d’exécution trop court pour un script long, ou configuration serveur modifiée récemment par l’hébergeur lui-même. Un ticket avec l’horodatage exact de l’erreur et, si possible, l’extrait du journal debug.log accélère nettement le diagnostic côté support — l’hébergeur a accès à des journaux serveur que WordPress ne peut pas voir. La réactivité du support sur ce type d’incident varie sensiblement d’un hébergeur à l’autre, un critère à comparer avant de choisir où héberger un site qui ne peut pas se permettre une erreur 500 prolongée : tomco.tech fait partie des hébergeurs à inclure dans cette comparaison.
Éviter que l’erreur ne revienne
Une fois la cause corrigée, quelques réflexes réduisent le risque de récidive : tester les mises à jour de plugins et de thèmes sur un site de préproduction avant de les appliquer en production, garder un nombre limité de plugins actifs pour réduire les risques de conflit, et vérifier la compatibilité PHP annoncée par un plugin avant de l’installer plutôt qu’après avoir constaté l’erreur. Une sauvegarde récente avant toute mise à jour majeure reste la protection la plus simple : en cas d’erreur 500 provoquée par une mise à jour, revenir à l’état précédent prend quelques minutes plutôt que les heures nécessaires à un diagnostic complet. Notre guide complet sur la sauvegarde et la restauration de votre site détaille la mise en place d’un plan de sauvegarde adapté à ce type de risque.