# Erreur 500 Internal Server Error sur WordPress : solutions

> Erreur 500 Internal Server Error sur WordPress : trouvez la cause dans les journaux (.htaccess, PHP, extensions, droits) et corrigez-la étape par étape.

- Auteur : WordPress Développement
- Publié le : 2026-10-02
- Mis à jour le : 2026-10-02
- URL : https://www.wpmoderne.fr/erreurs-wordpress/erreur-500/

> Le serveur a rencontré une erreur qu’il ne sait pas détailler : le plus souvent un .htaccess invalide, une erreur PHP fatale (extension, thème) ou une limite de ressources. Le journal d’erreurs du serveur donne la cause exacte.

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](https://www.wpmoderne.fr/erreurs-wordpress/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](https://www.wpmoderne.fr/hebergement/centraliser-logs-nginx-php-wordpress-diagnostiquer/) 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](https://www.wpmoderne.fr/elementor/erreur-500-apres-activation-elementor-pro-diagnostic/) 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](https://www.wpmoderne.fr/erreurs-wordpress/memoire-epuisee/) : 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