Erreur 500 Internal Server Error : causes et solutions

Ce que tu vas résoudre ici

Ce matin, un site sous WordPress affichait une page blanche avec une seule ligne : “500 Internal Server Error”. Aucun autre indice. Pas de message de plugin, pas de log visible depuis l’admin, pour cause, l’admin lui-même était injoignable. Le code 500 signifie « Internal Server Error » : le serveur a rencontré une condition inattendue qui l’empêche de répondre, sans en dire davantage au client (source : MDN, 500 Internal Server Error). C’est le scénario le plus fréquent d’erreur 500 : un message générique qui ne dit rien de la vraie cause, et qui peut venir d’à peu près n’importe quel étage de la stack (serveur, PHP, thème, plugin, base de données).

Cet article s’adresse à qui doit remettre un site en ligne vite, en avançant du diagnostic le plus simple au plus technique, sans supposition, sans redémarrer le serveur “au cas où” en espérant que ça passe. À la fin, tu sauras localiser la cause exacte et la corriger proprement.

Prérequis

• Accès FTP/SFTP ou au gestionnaire de fichiers de ton hébergeur
• Accès à l’administration WordPress (ou au moins à la base de données via phpMyAdmin)
• Accès SSH si possible (voir nos guides SSH sur Plesk ou SSH sur Gandi)
• Une sauvegarde récente du site avant toute manipulation
• 20 à 40 minutes selon la complexité de la cause

Étape 1 : vérifier le fichier .htaccess

Le .htaccess est la cause la plus fréquente et la plus rapide à corriger. La documentation WordPress le désigne d’ailleurs comme la cause la plus probable d’une Internal Server Error, et recommande exactement la manipulation qui suit (source : WordPress.org, Common WordPress Errors). Une règle de réécriture cassée, une directive mal fermée, ou un ajout manuel maladroit (souvent après une modification de permaliens ou une migration) suffit à provoquer une 500.

1. Connecte-toi en FTP à la racine du site (là où se trouvent wp-config.php et les dossiers wp-content, wp-admin).
2. Renomme temporairement .htaccess en .htaccess_old.
3. Recharge le site. Si l’erreur disparaît, le problème vient bien de ce fichier.
4. Régénère un .htaccess propre depuis Réglages > Permaliens dans l’admin WordPress (clique sur “Enregistrer” sans rien changer).

Si l’admin lui-même est inaccessible à cause de la 500, régénère manuellement le contenu standard WordPress :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Ce cas se croise aussi souvent en combinaison avec une erreur 404 sur toutes les pages : les deux symptômes partagent la même racine, une réécriture d’URL cassée.

Étape 2 : vérifier et augmenter la mémoire PHP

La directive memory_limit désigne la quantité maximale de mémoire qu’un script PHP a le droit de consommer, réglable dans php.ini (source : PHP, directives de configuration du noyau). Une erreur 500 peut venir d’un dépassement de cette limite. C’est fréquent après l’ajout d’un plugin gourmand, une montée en volume de contenu, ou un thème mal optimisé.

1. Ouvre wp-config.php à la racine du site.
2. Ajoute juste avant la ligne /* That's all, stop editing! */ :

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

3. Si le fichier php.ini est accessible (VPS, serveur dédié, ou hébergement avec accès complet), vérifie aussi :

memory_limit = 256M

4. Recharge le site après chaque modification, une à la fois.

Si tu n’es pas sûr de la différence entre ces différentes directives PHP (limite mémoire, temps d’exécution, taille d’upload), notre guide complet des directives PHP WordPress détaille chacune et où la modifier selon ton hébergeur.

Étape 3 : isoler un plugin ou un thème fautif

Si le .htaccess et la mémoire PHP ne sont pas en cause, le problème vient très probablement d’un plugin ou du thème actif, souvent après une mise à jour automatique ou manuelle.

1. Renomme le dossier wp-content/plugins en plugins_old via FTP.
2. Recharge le site. S’il revient, tous les plugins étaient désactivés en bloc, le fautif est parmi eux.
3. Renomme le dossier en plugins et réactive les extensions une par une depuis l’admin, en testant le site après chaque activation.
4. Si le thème est suspecté, bascule temporairement sur un thème par défaut (Twenty Twenty-Four par exemple) en renommant le dossier du thème actif dans wp-content/themes.

Ce protocole d’élimination est identique à celui qu’on utilise pour un site cassé après une mise à jour automatique ou pour un plugin qui casse le site après une MAJ. La logique de rollback y est détaillée si tu dois revenir à une version antérieure.

Étape 4 : consulter les logs serveur

Si les trois premières étapes n’ont rien donné, il faut arrêter de deviner et lire ce que le serveur dit réellement. Le message affiché au visiteur (“500 Internal Server Error”) est volontairement vague pour des raisons de sécurité, le vrai détail est dans les logs. Les codes de la classe 5xx signifient que le serveur sait avoir échoué ou ne peut pas traiter la requête, là où les 4xx incriminent le client (source : RFC 9110, IETF, 2022).

1. Active le mode debug de WordPress dans wp-config.php :

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

2. Recharge la page en erreur, puis consulte wp-content/debug.log.
3. Si rien n’apparaît côté WordPress, va chercher les logs serveur : dans cPanel via “Erreurs”, dans Plesk via “Journaux”, ou en SSH via :

tail -n 100 /var/log/apache2/error.log
# ou selon la config
tail -n 100 /var/log/nginx/error.log

4. Cherche la ligne horodatée correspondant au moment de l’erreur : elle mentionne généralement le fichier PHP exact et la ligne fautive.

Cette étape est aussi celle qu’on recommande pour distinguer une 500 d’une erreur 502 ou d’une erreur 503 : les logs révèlent si la cause est applicative (PHP) ou liée à la communication entre le serveur web et le processus PHP-FPM.

Étape 5 : vérifier les fichiers core et les permissions

Si aucune des étapes précédentes n’a résolu le problème, deux causes plus rares restent à vérifier :

• Fichiers core corrompus : une mise à jour interrompue peut laisser des fichiers WordPress incomplets. Retélécharge une version propre de WordPress depuis le site officiel et remplace les dossiers wp-admin et wp-includes (jamais wp-content, qui contient tes données), la procédure d’installation officielle décrivant l’arborescence attendue (source : WordPress.org, How to install WordPress).
• Permissions incorrectes : des dossiers en 777 ou des fichiers PHP en 644 mal configurés peuvent déclencher une 500 selon la configuration du serveur. Les permissions recommandées sont 755 pour les dossiers et 644 pour les fichiers.

Si le site a été compromis récemment, une 500 peut aussi être la conséquence d’un fichier malveillant injecté, vérifie ce point avec notre guide sur un site WordPress piraté avant de conclure trop vite à un simple bug.

Tableau récapitulatif : cause → solution

Pièges courants

• Réactiver tous les plugins d’un coup après le test : tu perds le bénéfice du diagnostic. Réactive un par un, sans exception.
• Modifier php.ini sans accès réel : sur de l’hébergement mutualisé, les modifications passent souvent par un fichier .user.ini ou l’interface de l’hébergeur, pas directement le php.ini système.
• Confondre 500 et écran blanc : les deux se ressemblent mais n’ont pas toujours la même cause profonde. Si l’écran est totalement blanc sans code d’erreur, consulte plutôt notre article sur l’écran blanc de la mort WordPress.
• Oublier de désactiver le mode debug une fois le problème résolu : laisser WP_DEBUG_DISPLAY actif expose des informations techniques aux visiteurs, un risque de sécurité inutile.
• Ne jamais regarder les logs serveur et se contenter de deviner : la majorité des 500 “mystères” se résolvent en cinq minutes une fois la bonne ligne de log identifiée.

FAQ

Une erreur 500 non résolue en quelques minutes n’est jamais “juste de la malchance” : c’est toujours une cause identifiable, du fichier de configuration au serveur lui-même. La méthode compte plus que la vitesse, corriger au hasard un .htaccess ou un plugin sans passer par les logs, c’est risquer de masquer temporairement un problème qui reviendra sous une autre forme.