Erreur 500 Internal Server Error sur WordPress : solutions

500 Internal Server Error

En anglais : 500 Internal Server Error

Une page vide ou un texte du type « 500 Internal Server Error » remplace votre site. Selon le navigateur, vous pouvez lire « HTTP ERROR 500 », et Apache affiche « Internal Server Error », nginx « 500 Internal Server Error ». L’erreur peut toucher tout le site, seulement l’administration, ou une seule URL (une page, une route de l’API, une action admin-ajax.php).

Contrairement à la page d’erreur critique de WordPress, ce message est volontairement vague : il protège les détails techniques des visiteurs. La cause réelle se lit dans les journaux, pas dans le navigateur.

Ce que signifie cette erreur

Le code HTTP 500 est une réponse générique du serveur, qui dit « j’ai échoué, et je ne peux pas faire plus précis ». Plusieurs couches peuvent le produire :

• Le serveur web (Apache ou nginx), quand une règle de configuration est invalide : un .htaccess avec une directive inconnue, une boucle de réécriture, un module manquant ;
• PHP (module Apache ou PHP-FPM), quand un script se termine par une erreur fatale alors que l’affichage des erreurs est coupé : le serveur n’a rien à envoyer et répond 500 ;
• WordPress lui-même : la fonction wp_die() répond par défaut avec un code 500 (hors requête Ajax), et la page d’erreur critique du gestionnaire d’erreurs fatales (wp-includes/class-wp-fatal-error-handler.php) l’envoie explicitement. Voir la fiche erreur critique ;
• Un contrôle de prérequis : si la version de PHP est trop ancienne ou si une extension requise manque, wp_check_php_mysql_versions() (wp-includes/load.php) envoie un en-tête 500 et un message brut en anglais, sans passer par le thème.

Une erreur 500 se distingue des 502, 503 et 504, qui indiquent un problème entre le serveur web et PHP-FPM (passerelle défaillante, service indisponible, délai dépassé).

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
Tout le site est en 500, y compris les images et fichiers statiques	Configuration du serveur ou .htaccess invalide	Journal d’erreurs Apache ou nginx ; renommer .htaccess
Les fichiers statiques s’affichent, les pages PHP échouent	Erreur PHP fatale, version de PHP, extension manquante	debug.log, journal PHP, version de PHP
Seul /wp-admin/ ou une page précise est en 500	Extension, thème ou gabarit spécifique	Journal à l’heure de l’erreur, désactivation par SFTP
Apparu après une mise à jour d’extension ou de PHP	Incompatibilité de code	Retour arrière, journal PHP
Journal : « Permission denied » ou « Premature end of script headers »	Droits ou propriétaire des fichiers, exécution CGI	ls -l, droits 755 / 644
Erreur sporadique, aux heures chargées	Limites de ressources (mémoire, processus)	Fiche mémoire épuisée, quotas de l’hébergeur

Les causes les plus fréquentes

1. Un fichier .htaccess corrompu ou contenant une directive que le serveur ne comprend pas (par exemple php_value alors que PHP tourne en FPM).
2. Une erreur PHP fatale dans une extension, un thème ou un snippet, sans affichage des erreurs.
3. Une limite de mémoire ou de ressources dépassée.
4. Des droits ou un propriétaire erronés sur les fichiers et dossiers.
5. Une version de PHP incompatible ou une extension PHP manquante.
6. Des fichiers du cœur ou wp-config.php corrompus, par exemple après un transfert interrompu.
7. Un pare-feu applicatif (ModSecurity) ou une règle de l’hébergeur qui bloque une requête légitime.

Solutions pas à pas

Faites une sauvegarde de vos fichiers et de la base avant d’intervenir. Du moins invasif au plus technique :

1. Lire le journal d’erreurs du serveur

C’est l’étape qui évite de tâtonner. Chaque erreur 500 laisse une ligne dans le journal. Sur un serveur dont vous avez la main (le chemin dépend de la distribution et du site) :

# Apache (Debian / Ubuntu)
sudo tail -n 50 /var/log/apache2/error.log
# Apache (famille Red Hat)
sudo tail -n 50 /var/log/httpd/error_log
# nginx
sudo tail -n 50 /var/log/nginx/error.log
# PHP-FPM : le fichier dépend de la version
sudo ls /var/log | grep -i php

Sur un hébergement mutualisé, le journal est dans le panneau (rubrique « Journaux » ou « Erreurs ») ou dans un fichier error_log à la racine du site. Complétez avec le journal WordPress en ajoutant ces lignes à wp-config.php au-dessus de « That’s all, stop editing! » :

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

Rechargez la page, puis lisez wp-content/debug.log. Notre article sur la centralisation des journaux nginx, PHP et WordPress montre comment croiser ces sources.

2. Régénérer le fichier .htaccess (Apache)

Si le journal contient « Invalid command » ou « .htaccess: … », ou en cas de doute, renommez le fichier par SFTP :

.htaccess  →  .htaccess.sauvegarde

Rechargez le site. S’il revient, régénérez un fichier propre depuis l’administration (Réglages > Permaliens > Enregistrer les modifications) ou avec WP-CLI :

wp rewrite flush --hard

Voici le bloc standard de WordPress si vous devez le recréer à la main (placez-y vos règles personnelles en dehors des lignes BEGIN et END) :

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

Équivalent nginx : il n’y a pas de .htaccess. Vérifiez la syntaxe avec sudo nginx -t, puis le bloc de réécriture du site :

location / {
    try_files $uri $uri/ /index.php?$args;
}

Rechargez ensuite avec sudo systemctl reload nginx.

3. Désactiver les extensions et revenir à un thème par défaut

Renommez le dossier wp-content/plugins en plugins.off, ou désactivez-les avec WP-CLI :

wp plugin deactivate --all
wp theme list
wp theme activate slug-du-theme-par-defaut

Si le site revient, réactivez les extensions une par une pour isoler la fautive. Consultez notre article Erreur 500 après activation d’Elementor Pro pour un exemple de diagnostic complet.

4. Augmenter la mémoire PHP

Si le journal cite « Allowed memory size », suivez la fiche mémoire épuisée : un define( 'WP_MEMORY_LIMIT', '256M' ); dans wp-config.php règle souvent le problème.

5. Corriger les droits et le propriétaire des fichiers

Les dossiers doivent généralement être en 755 et les fichiers en 644 ; wp-config.php peut être plus restrictif (640 ou 600). Le propriétaire doit être l’utilisateur sous lequel tourne PHP. En SSH, depuis la racine du site :

ls -l
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

Vérifiez que wp-config.php reste lisible par PHP : si votre hébergeur exige un autre mode, adaptez-le. Évitez de corriger un blocage en passant tout en 777, ce qui ouvre le site à toute modification.

6. Vérifier la version de PHP et ses extensions

php -v
php -m

Comparez avec les prérequis de WordPress et de vos extensions. Si l’erreur est apparue après un changement de version de PHP, repassez à la précédente depuis le panneau de l’hébergeur, le temps de mettre le code à jour. Rappel : sur un serveur dont PHP est trop ancien, WordPress s’arrête avec un message en anglais « Your server is running PHP version … but WordPress … requires at least … ».

7. Réinstaller le cœur de WordPress

wp core verify-checksums
wp core download --force --skip-content

La première commande liste les fichiers modifiés ou manquants ; la seconde remplace le cœur sans toucher à wp-content ni à wp-config.php.

8. Contacter l’hébergeur avec les bons éléments

Si le journal évoque ModSecurity, un quota de processus ou un blocage au niveau du serveur, transmettez au support l’heure précise, l’URL et la ligne du journal. C’est le moyen le plus rapide d’obtenir une réponse utile.

Prévenir l’erreur

• Gardez le journal d’erreurs actif (hors affichage public) et consultez-le après chaque mise à jour.
• Testez les mises à jour et les changements de PHP en préproduction avant la production.
• Faites une copie de .htaccess et de wp-config.php avant toute modification, et notez ce que vous changez.
• Surveillez la disponibilité avec une sonde externe qui contrôle le code HTTP, pas seulement la présence d’une page.
• Respectez les droits recommandés et évitez les modifications en direct depuis l’administration.

Questions fréquentes