Erreur 500 : causes et solutions (WordPress, nginx, Apache)

Qu'est-ce que l'erreur HTTP 500 ?

L'erreur HTTP 500 (Internal Server Error) signifie que quelque chose a cassé sur le serveur web pendant le traitement de votre requête, et que le serveur n'a pas dit quoi. C'est l'erreur serveur la plus générique.

La norme HTTP la définit en une phrase : « The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request » (RFC 9110 §15.6.1), c'est-à-dire que le serveur a rencontré une condition inattendue qui l'a empêché de traiter la requête. Contrairement à un 503, il ne dit rien sur le caractère temporaire ou non du problème.

C'est presque toujours un bug, une mauvaise configuration ou un plantage du code côté serveur, et non la conséquence d'une action du visiteur. La correction doit venir du propriétaire ou de l'administrateur du site.

À quoi ressemble une erreur 500

Le message dépend du serveur et de l'application :

• 500 Internal Server Error — la ligne de statut standard
• 500 Internal Server Error avec « nginx » en dessous — la page d'erreur propre à nginx
• The server encountered an internal error or misconfiguration and was unable to complete your request. — la page par défaut d'Apache
• Il y a eu une erreur critique sur ce site. — la page d'erreur fatale de WordPress, telle qu'elle s'affiche en français (en anglais : « There has been a critical error on this website. »)
• HTTP Error 500.19 - Internal Server Error — IIS, où le nombre après le point indique la raison (500.19 : données de configuration non valides)
• Cette page ne fonctionne pas · Impossible de traiter cette demande via example.com à l'heure actuelle. · HTTP ERROR 500 — Chrome, quand la réponse 500 n'a pas de page propre
• Request failed with status code 500 — Axios et d'autres codes JavaScript qui appellent une API
• 500. That's an error. — la page d'erreur de Google

Erreur 500 Internal Server Error sur nginx

Le plus souvent, nginx ne fait que relayer un 500 renvoyé par l'application derrière lui (PHP-FPM, Node.js, Python) ; avec PHP-FPM, le message d'erreur de PHP atterrit dans le log de nginx. nginx génère aussi lui-même un 500 dans quelques cas. Les lignes à chercher dans le log d'erreurs :

# What did nginx log?
sudo tail -n 50 /var/log/nginx/error.log

# Look for loops in the loaded config
sudo nginx -T | grep -nE 'try_files|rewrite'

(Source : le code de nginx ; un backend planté ou surchargé donne un 502 ou un 504, pas un 500.)

Causes courantes de l'erreur HTTP 500

Un 500 peut venir de dizaines de problèmes côté serveur. Les plus courants :

• Un fichier .htaccess cassé — une directive invalide ou une mauvaise RewriteRule fait répondre 500 à Apache pour ce dossier et tout ce qui se trouve en dessous.
• Des erreurs fatales PHP — erreurs de syntaxe, exceptions non interceptées ou appels à des fonctions non définies arrêtent le script.
• Les limites de mémoire ou de temps de PHP — un script qui dépasse memory_limit (128M par défaut) ou max_execution_time (30 secondes) est arrêté.
• Des lignes php_value sur un serveur PHP-FPM — elles ne fonctionnent qu'avec le mod_php d'Apache ; sous PHP-FPM, Apache les rejette avec un 500.
• De mauvaises permissions de fichiers — PHP ne peut pas lire un fichier qu'il inclut, ou un hébergement suPHP/suEXEC refuse les fichiers modifiables par tous (777). (Un fichier que le serveur web lui-même ne peut pas lire donne un 403.)
• Un plugin ou un thème — une extension WordPress, Joomla ou Drupal nouvelle ou mise à jour qui fait planter tout le site.
• Des échecs de connexion à la base de données — identifiants erronés, serveur de base de données arrêté ou trop de connexions.
• Des fichiers du noyau corrompus — après une mise à jour échouée ou un envoi interrompu.
• Un disque plein — le serveur ne peut plus écrire les logs, les sessions ni les fichiers temporaires.
• Les déclencheurs propres à nginx — une boucle de réécriture, un fichier de mots de passe illisible ou une écriture de fichier temporaire qui échoue (souvent un disque plein) ; voir la section nginx ci-dessus.

Comment corriger une erreur 500 (en tant que visiteur)

Si vous voyez une erreur 500 sur le site de quelqu'un d'autre, le problème vient du serveur, pas de votre côté. Cependant, voici quelques actions que vous pouvez tenter avant d'abandonner.

• Rechargez une fois après une minute (F5, ou Cmd+R sur Mac). Beaucoup de 500 ne durent que le temps d'un déploiement ou d'un redémarrage.
• Vérifiez si le site est en panne pour tout le monde — le Vérificateur de site en panne ouvre la page depuis 11 endroits, et le Vérificateur d'en-têtes HTTP affiche le code de statut exact que reçoit notre serveur.
• Supprimez les cookies du site, ou essayez une fenêtre privée. Un cookie de session corrompu peut faire échouer certaines applications sur toutes les pages, pour vous seul.
• Réessayez plus tard — la correction se fait côté serveur, laissez du temps au propriétaire.
• Prévenez le propriétaire du site si cela dure des heures, en indiquant l'adresse de la page et l'heure à laquelle c'est arrivé.

Solution 1 : consultez les logs d'erreur du serveur

Les logs d'erreur sont l'outil de débogage le plus important pour les erreurs 500. Ils vous indiquent exactement ce qui s'est mal passé, y compris le chemin du fichier, le numéro de ligne et le message d'erreur. Consultez toujours les logs en premier avant de tenter quoi que ce soit d'autre.

# Apache (PHP errors appear here too, as "AH01071: Got error 'PHP message: …'")
sudo tail -n 100 /var/log/apache2/error.log      # Debian/Ubuntu
sudo tail -n 100 /var/log/httpd/error_log        # RHEL/Alma/Rocky

# nginx (PHP errors appear here as "FastCGI sent in stderr")
sudo tail -n 100 /var/log/nginx/error.log

# PHP errors on RHEL-family PHP-FPM
sudo tail -n 100 /var/log/php-fpm/www-error.log

# PHP-FPM process log (pool restarts, pm.max_children)
sudo tail -n 100 /var/log/php8.3-fpm.log         # Debian/Ubuntu

# WordPress debug log (with WP_DEBUG_LOG on)
tail -n 100 /path/to/wordpress/wp-content/debug.log

Solution 2 : testez et réparez le fichier .htaccess

Un fichier .htaccess cassé est une cause classique de 500 sur Apache : une faute de frappe, une directive que le serveur ne gère pas ou une mauvaise RewriteRule met le dossier hors service. Le log d'erreurs d'Apache nomme le fichier .htaccess et la directive fautive, par exemple Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration.

Le test le plus rapide consiste à renommer temporairement le fichier. Si le site se charge après le renommage, le .htaccess était bien le problème.

# Rename to disable .htaccess
mv .htaccess .htaccess_backup

# If site loads, regenerate a clean .htaccess
# For WordPress, go to Settings > Permalinks and click Save

Solution 3 : corrigez les permissions des fichiers

Les permissions provoquent un 500 quand PHP ne peut pas lire un fichier qu'il inclut, ou sur les hébergements suPHP/suEXEC qui refusent les fichiers modifiables par tous. Les réglages habituels sont 644 pour les fichiers et 755 pour les dossiers. N'utilisez jamais 777 : c'est un risque de sécurité, et sur les hébergements suEXEC/suPHP il provoque à lui seul un 500.

# Set correct directory permissions
find /path/to/webroot -type d -exec chmod 755 {} \;

# Set correct file permissions
find /path/to/webroot -type f -exec chmod 644 {} \;

# WordPress wp-config.php (extra security; 440 only if the PHP user owns the file or is in its group)
chmod 440 wp-config.php

Solution 4 : augmentez la mémoire PHP et les limites d'exécution

PHP arrête les scripts qui dépassent la limite de mémoire ou la durée d'exécution maximale, et le visiteur obtient un 500. Les valeurs par défaut, 128M de mémoire et 30 secondes, sont souvent trop basses pour les pages lourdes.

Augmentez-les là où votre serveur les lit. Pour PHP-FPM, modifiez le php.ini de FPM (par exemple /etc/php/8.3/fpm/php.ini) et rechargez php-fpm ; les changements dans .user.ini peuvent mettre jusqu'à 5 minutes à s'appliquer.

# Option 1: php.ini (best)
memory_limit = 256M
max_execution_time = 300

# Option 2: .htaccess (Apache with mod_php only; under PHP-FPM these lines cause a 500)
php_value memory_limit 256M
php_value max_execution_time 300

# Option 3: .user.ini (PHP-FPM and other FastCGI setups)
memory_limit = 256M

# Option 4: wp-config.php (WordPress)
define( 'WP_MEMORY_LIMIT', '256M' );

Solution 5 : désactivez les plugins et le thème (CMS)

Si vous utilisez WordPress, Joomla ou un autre CMS, un plugin ou un thème défectueux est l'une des causes les plus courantes des erreurs 500. Le moyen le plus rapide de tester est de désactiver tous les plugins d'un coup, puis de les réactiver un par un.

# Disable all WordPress plugins (via the file system)
cd /path/to/wordpress/wp-content
mv plugins plugins_disabled

# Or with WP-CLI, without loading the plugin that crashes the site
wp plugin deactivate --all --skip-plugins --skip-themes

# Switch to a default theme (installs it if it was deleted)
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

# Check WordPress's own files, and reinstall them without touching wp-content
wp core verify-checksums
wp core download --skip-content --force

Solution 6 : vérifiez et réparez la connexion à la base de données

Une erreur 500 peut survenir lorsque l'application ne parvient pas à se connecter à sa base de données. Cela se produit quand les identifiants sont erronés, le serveur de base de données est en panne ou les tables sont corrompues.

Vérifiez d'abord vos identifiants de base de données dans votre fichier de configuration (wp-config.php pour WordPress, .env pour Laravel). Testez ensuite la connexion et réparez les tables corrompues si nécessaire.

# Test the MySQL connection
mysql -u username -p -h localhost database_name -e "SELECT 1;"

# Check tables (REPAIR only fixes MyISAM/Aria tables; for InnoDB, restore from a backup)
mysqlcheck -u username -p --check --auto-repair database_name

# WordPress: add to wp-config.php, then visit /wp-admin/maint/repair.php
# Remove this line when you're done: the repair page needs no login.
define( 'WP_ALLOW_REPAIR', true );

Solution 7 : vérifiez la compatibilité de la version PHP

Du code écrit pour une ancienne version de PHP peut provoquer des erreurs fatales sur une version plus récente (ou l'inverse). Après une mise à jour de PHP, les fonctions supprimées et les comportements modifiés sont les coupables habituels ; les fonctions obsolètes ne déclenchent que des avis.

Vérifiez quelle version de PHP votre site utilise réellement. php -v en ligne de commande peut afficher un autre PHP que celui de votre site : regardez aussi dans votre panneau d'hébergement ou sur une page phpinfo() temporaire :

# Command-line PHP (may differ from the site's PHP-FPM)
php -v

# PHP-FPM versions installed (Debian/Ubuntu)
ls /etc/php/

# Modules loaded in the command-line PHP
php -m

Solution 8 : vérifiez l'espace disque

Quand un serveur manque d'espace disque (ou d'inodes), il ne peut plus écrire les logs, les fichiers temporaires ni les données de session, et les requêtes se mettent à échouer avec des 500.

# Check disk space, and inodes (they can run out too)
df -h
df -i

# What's using the space?
sudo du -sh /var/log /tmp

# Free space without deleting the log you're reading
sudo find /var/log -name "*.gz" -mtime +14 -delete
sudo journalctl --vacuum-size=200M

500 vs 502 vs 503 vs 504 : quelle différence ?

La distinction clé : 500 = le serveur a planté en interne. 502 = le proxy a reçu une réponse invalide du backend. 503 = le serveur est actif mais occupé. 504 = le proxy a abandonné l'attente. Vous pouvez vérifier le code de statut exact que renvoie votre serveur avec le Vérificateur d'en-têtes HTTP de DNS Robot.

Quand l'erreur est un 502, l'application peut très bien fonctionner et le problème se situer entre le proxy et l'application. Notre guide du 502 Bad Gateway traite ce cas.

Impact des erreurs 500 sur le SEO

La documentation de Google décrit elle-même ce qui se passe (documentation de Google sur les robots d'exploration) :

• L'exploration ralentit. Sur des erreurs 5xx, Google réduit le rythme d'exploration du site, proportionnellement au nombre d'URL qui renvoient des erreurs.
• Les pages indexées restent d'abord. Les URL déjà indexées sont conservées un temps, mais celles qui renvoient durablement une erreur serveur sont supprimées.
• La reprise est progressive. Dès que le serveur répond de nouveau en 2xx, Google réaugmente progressivement l'exploration.
• Utilisez un 503 pour une indisponibilité prévue d'un jour ou deux, avec un en-tête Retry-After (Google), pour qu'elle soit lue comme temporaire (guide du 503).

Comment prévenir les erreurs 500

Mieux vaut prévenir que guérir. Suivez ces bonnes pratiques pour minimiser le risque d'erreurs 500 sur votre site web.

• Mettez en place un monitoring de disponibilité — Utilisez des outils comme UptimeRobot ou Pingdom pour vérifier votre site toutes les 1 à 5 minutes. Recevez des alertes instantanées en cas d'erreur 500.
• Testez toujours en environnement de staging — Ne déployez jamais directement en production. Testez les mises à jour de plugins, les montées de version PHP et les changements de configuration dans un environnement de pré-production.
• Utilisez le contrôle de version (Git) — Commitez chaque modification pour pouvoir annuler instantanément un mauvais déploiement avec une seule commande.
• Implémentez une gestion d'erreurs appropriée — Encapsulez les requêtes de base de données et les appels API dans des blocs try-catch. Enregistrez les traces complètes côté serveur pour chaque erreur.
• Surveillez l'espace disque et les ressources du serveur — Configurez des alertes pour une utilisation du disque supérieure à 80 %, un CPU élevé et une pression sur la mémoire.
• Maintenez vos logiciels à jour — Les versions obsolètes de CMS, plugins et logiciels serveur contiennent des bugs connus qui provoquent des plantages.
• Maintenez des sauvegardes automatisées — Testez régulièrement votre procédure de restauration. Une sauvegarde que vous n'avez jamais testée n'est pas une sauvegarde.
• Configurez les limites PHP de manière appropriée — Configurez memory_limit et max_execution_time en fonction de votre charge de travail réelle, pas des valeurs par défaut.
• Utilisez des pipelines CI/CD — Automatisez les tests avant le déploiement. Si les tests échouent, le déploiement ne doit pas avoir lieu.