Erreur 500 WordPress : diagnostic complet (htaccess, wp-admin, PHP)

L’erreur 500 WordPress (HTTP 500 Internal Server Error) signifie que le serveur a rencontré une condition inattendue qui l’empêche de traiter la requête. Contrairement à une erreur 404 ou 403, le serveur ne donne aucun détail dans la réponse HTTP. Pour diagnostiquer une erreur 500 WordPress, commencez toujours par trois vérifications rapides : renommer le fichier .htaccess (via FTP) pour l’exclure, désactiver tous les plugins en renommant le dossier wp-content/plugins/, puis augmenter la limite mémoire PHP dans wp-config.php. Ces trois actions résolvent plus de 80 % des cas.

Ce guide couvre l’ensemble du diagnostic : .htaccess corrompu, wp-admin inaccessible, erreur 500 après une mise à jour PHP, logs d’erreur Apache/Nginx, et les cas rares liés au thème ou à la configuration serveur.

Qu’est-ce que l’erreur 500 Internal Server Error WordPress ?

Le code HTTP 500 est un statut générique côté serveur. Il indique que le serveur web (Apache ou Nginx) a tenté d’exécuter le code PHP de WordPress, mais qu’une erreur fatale non gérée s’est produite. Le serveur refuse alors de renvoyer la page et affiche une page blanche, le message « 500 Internal Server Error » ou, sur certains hébergeurs, « There has been a critical error on this website » (voir notre guide sur l’erreur critique WordPress).

Contrairement à l’erreur de connexion à la base de données, l’erreur 500 n’implique pas MySQL. Le problème vient presque toujours du code PHP, de la configuration Apache ou de la limite de ressources.

L’erreur peut toucher :

• L’ensemble du site (front-end et back-end)
• Uniquement l’administration WordPress (/wp-admin/)
• Uniquement certaines pages (article spécifique, page panier WooCommerce)
• Uniquement les requêtes AJAX (formulaire de contact, ajout au panier)

Les six causes principales de l’erreur 500 WordPress

Voici les causes classées par fréquence d’occurrence :

1. Fichier .htaccess corrompu : une règle de réécriture invalide bloque toutes les requêtes sur Apache.
2. Plugin incompatible ou bogué : un plugin provoque une erreur PHP fatale (fonction inexistante, conflit de version).
3. Limite mémoire PHP trop basse : WordPress et ses plugins consomment plus que la limite allouée (memory_limit dans php.ini).
4. Mise à jour PHP incompatible : passage de PHP 7.4 à PHP 8.x sans vérifier la compatibilité des plugins et du thème.
5. Thème avec erreur PHP : le thème actif utilise une fonction dépréciée ou absente dans la version PHP du serveur.
6. Permissions de fichiers incorrectes : les fichiers WordPress ne sont pas lisibles par l’utilisateur Apache (www-data).

Méthode 1 : diagnostiquer et corriger le fichier .htaccess

Le fichier .htaccess est souvent la première cause d’une erreur 500 sur Apache. Une mise à jour WordPress ratée, un plugin de sécurité ou une modification manuelle peut y injecter une directive invalide.

Étape 1 : connectez-vous en FTP (FileZilla, WinSCP) ou via le gestionnaire de fichiers cPanel. Naviguez vers la racine WordPress (dossier public_html ou www).

Étape 2 : renommez .htaccess en .htaccess.bak (clic droit, renommer). Rechargez le site.

• Si l’erreur 500 disparaît : le .htaccess était corrompu.
• Si l’erreur persiste : passez à la méthode suivante.

Étape 3 : pour régénérer un .htaccess propre, allez dans WordPress Réglages > Permaliens et cliquez « Enregistrer les modifications ». WordPress crée automatiquement un nouveau .htaccess valide. Vous pouvez aussi utiliser notre générateur de .htaccess WordPress pour obtenir un fichier adapté à votre configuration.

# Contenu .htaccess WordPress standard (sans plugin de cache)
# 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

Si votre hébergeur utilise Nginx, le fichier .htaccess n’est pas lu. Dans ce cas, l’erreur 500 a une autre origine.

Méthode 2 : résoudre l’erreur 500 dans wp-admin

Quand l’erreur 500 n’affecte que l’administration WordPress (/wp-admin/) et que le front-end fonctionne, le problème vient le plus souvent d’un plugin actif uniquement en contexte admin.

Désactivation d’urgence via FTP :

1. Connectez-vous en FTP.
2. Naviguez vers wp-content/.
3. Renommez le dossier plugins en plugins.bak.
4. Rechargez /wp-admin/ : WordPress détecte l’absence de plugins et les désactive tous.
5. Reconnectez-vous en admin, puis renommez plugins.bak en plugins.
6. Réactivez les plugins un par un pour identifier le fautif.

# Via WP-CLI (si disponible sur l'hébergeur)
# Désactiver tous les plugins
wp plugin deactivate --all

# Lister les plugins désactivés
wp plugin list

# Réactiver un plugin spécifique pour tester
wp plugin activate nom-du-plugin

# Réactiver tous les plugins d'un coup après le diagnostic
wp plugin activate --all

Si la désactivation des plugins ne résout pas l’erreur dans wp-admin, basculez temporairement vers un thème par défaut (Twenty Twenty-Four) via FTP : renommez votre dossier de thème actif dans wp-content/themes/ et WordPress utilisera automatiquement un thème de repli.

Méthode 3 : erreur 500 après une mise à jour PHP

C’est une cause fréquente en 2025-2026 : les hébergeurs font évoluer la version PHP (PHP 7.4 vers PHP 8.1, 8.2 ou 8.3) et certains plugins ou thèmes ne sont pas compatibles. PHP 8.x est plus strict sur la syntaxe et supprime des fonctions dépréciées de PHP 7.

Fonctions supprimées en PHP 8.x les plus courantes dans les plugins WordPress :

• create_function() (supprimée en PHP 8.0)
• each() (supprimée en PHP 8.0)
• ereg(), split() (supprimées en PHP 7.0)
• Arguments nommés en conflit avec ...$args

# Activer WP_DEBUG pour voir l'erreur exacte
# Dans wp-config.php, avant "/* That's all, stop editing! */"
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );   // Log dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // Ne pas afficher en front
@ini_set( 'display_errors', 0 );

Solution : si vous ne pouvez pas rétablir une ancienne version PHP (risque sécurité), identifiez le plugin ou le thème via les logs (voir section suivante), puis :

1. Mettez à jour le plugin vers sa dernière version (souvent corrigée pour PHP 8.x).
2. Si aucune mise à jour n’est disponible, remplacez-le par un équivalent compatible.
3. Pour le thème : mettez à jour ou basculez temporairement vers un thème par défaut.

Méthode 4 : lire les logs d’erreur Apache et PHP

Les logs d’erreur contiennent toujours la cause exacte de l’erreur 500. C’est la méthode la plus efficace pour un diagnostic précis.

Accéder aux logs selon l’hébergeur :

• cPanel (o2switch, OVH mutualisé) : connectez-vous à cPanel, allez dans « Logs » puis « Journal des erreurs ».
• FTP : cherchez error_log ou php_error.log à la racine WordPress ou dans wp-content/.
• SSH : tail -f /var/log/apache2/error.log ou tail -f /var/log/nginx/error.log.
• WP_DEBUG_LOG : activez-le (voir méthode 3) et consultez wp-content/debug.log.

# Lire les 50 dernières lignes du log d'erreur WordPress
tail -n 50 wp-content/debug.log

# Filtrer uniquement les Fatal Error
grep "Fatal error" wp-content/debug.log | tail -20

# Sur un VPS : log Apache en temps réel
sudo tail -f /var/log/apache2/error.log | grep -i "wordpress|php|500"

# Sur un VPS : log Nginx
sudo tail -f /var/log/nginx/error.log

Un message type dans le log pourrait ressembler à :

[Thu Jul 11 10:23:45 2026] [error] [client 192.0.2.1] PHP Fatal error:
Call to undefined function woocommerce_cart() in
/home/user/public_html/wp-content/themes/my-theme/functions.php on line 42

Ce message indique exactement le fichier (functions.php du thème) et la ligne (42) responsable de l’erreur 500.

Méthode 5 : augmenter la limite mémoire PHP

WordPress recommande une limite mémoire PHP d’au moins 256 Mo. Sur de nombreux hébergements mutualisés, la valeur par défaut est 64 Mo ou 128 Mo, ce qui est insuffisant dès que WooCommerce, Elementor ou des plugins lourds sont actifs.

# Option 1 : dans wp-config.php (avant le commentaire final)
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Limite admin

# Option 2 : dans .htaccess (Apache uniquement)
php_value memory_limit 256M

# Option 3 : dans php.ini (si vous avez un accès)
memory_limit = 256M

# Option 4 : dans un fichier user.ini à la racine
memory_limit = 256M

# Vérifier la limite active
wp eval 'echo WP_MEMORY_LIMIT;'

Si l’hébergeur mutualisé impose un plafond que vous ne pouvez pas dépasser, la solution est de passer à un plan supérieur ou de migrer vers un VPS.

Méthode 6 : vérifier les permissions de fichiers

Des permissions trop restrictives (ou au contraire trop permissives) peuvent provoquer une erreur 500. Les permissions correctes pour WordPress sont :

• Dossiers : 755 (rwxr-xr-x)
• Fichiers PHP : 644 (rw-r–r–)
• Fichier wp-config.php : 640 ou 600

# Corriger les permissions via SSH (remplacer /path/to/wordpress par votre chemin)
find /path/to/wordpress -type d -exec chmod 755 {} ;
find /path/to/wordpress -type f -exec chmod 644 {} ;

# wp-config.php plus restrictif
chmod 640 /path/to/wordpress/wp-config.php

# Vérifier le propriétaire des fichiers (doit être l'utilisateur Apache)
ls -la /path/to/wordpress/wp-config.php
# Attendu : -rw-r----- www-data www-data

Sur un hébergement mutualisé cPanel, les fichiers téléversés par FTP appartiennent à votre compte utilisateur (ex : wami5543). L’utilisateur Apache (nobody ou apache) doit pouvoir les lire.

Récapitulatif : arbre de décision pour l’erreur 500 WordPress

Voici l’ordre recommandé pour un diagnostic rapide :

1. Renommer .htaccess en .htaccess.bak via FTP. Site OK ? Régénérer via Réglages > Permaliens.
2. Renommer wp-content/plugins/ en plugins.bak. Site OK ? Réactiver les plugins un par un.
3. Augmenter la limite mémoire : ajouter define( 'WP_MEMORY_LIMIT', '256M' ); dans wp-config.php.
4. Activer WP_DEBUG_LOG et lire wp-content/debug.log.
5. Lire les logs d’erreur Apache/PHP via cPanel ou SSH.
6. Vérifier les permissions fichiers (755 dossiers, 644 fichiers).
7. Si l’erreur est apparue après une mise à jour PHP, tester la compatibilité des plugins via les logs.

Si aucune de ces étapes ne résout le problème, comparez avec les autres erreurs courantes : l’erreur critique PHP WordPress ou l’erreur de connexion à la base de données.

Prévenir l’erreur 500 WordPress : bonnes pratiques

Une fois votre site rétabli, quelques mesures évitent les récidives :

• Environnement de staging : testez chaque mise à jour (WordPress core, plugins, thème) en staging avant la production.
• Sauvegardes automatiques : activez des sauvegardes quotidiennes (fichiers + base de données) avec des outils comme UpdraftPlus ou la fonctionnalité JetBackup de cPanel.
• Monitoring de disponibilité : utilisez UptimeRobot (gratuit) pour être alerté dès qu’une erreur 500 survient.
• Compatibilité PHP : avant de passer à une nouvelle version PHP, vérifiez la compatibilité de vos plugins actifs sur plugintests.com ou avec WP-CLI (wp cli info).
• Fichier .htaccess : conservez une copie de sauvegarde horodatée de votre .htaccess après chaque modification.

FAQ : erreur 500 WordPress

L’erreur 500 WordPress est-elle grave ?

L’erreur 500 bloque l’accès à votre site mais ne cause pas de perte de données. La base de données et les fichiers restent intacts. Elle est toutefois urgente à corriger car chaque minute d’indisponibilité impacte le SEO (Googlebot log l’erreur et peut désindexer la page si elle persiste plusieurs jours) et l’expérience utilisateur. La plupart des cas se résolvent en 5 à 15 minutes avec les méthodes décrites dans cet article.

Comment résoudre une erreur 500 sans accès FTP ni SSH ?

Si vous n’avez accès ni au FTP ni au SSH, utilisez le gestionnaire de fichiers de votre panneau d’hébergement (cPanel File Manager, Plesk). Vous pouvez renommer .htaccess, modifier wp-config.php et renommer le dossier plugins/ directement depuis l’interface web. Activez également WP_DEBUG_LOG depuis cet éditeur pour accéder aux logs sans terminal.

Pourquoi l’erreur 500 apparaît-elle uniquement dans wp-admin ?

Quand l’erreur 500 n’affecte que l’administration WordPress et que le front-end fonctionne, un plugin actif provoque une erreur PHP fatale en contexte d’administration. Certains plugins s’initialisent uniquement en back-office (plugins de sécurité, analytics, optimisation). La solution : désactiver tous les plugins via FTP (renommer le dossier plugins/), puis les réactiver un par un en testant wp-admin après chaque réactivation.

L’erreur 500 peut-elle venir de l’hébergeur ?

Oui, dans des cas moins fréquents : surcharge du serveur mutualisé, mise à jour côté hébergeur, configuration Nginx/Apache mal appliquée après une migration. Si vous avez déjà exclu .htaccess, plugins, thème et limite mémoire, contactez le support de votre hébergeur en transmettant les logs d’erreur. Demandez-leur de vérifier les logs Apache au niveau serveur, car votre accès cPanel ne montre parfois qu’une partie des erreurs.

Comment éviter l’erreur 500 après une mise à jour de plugin ?

Trois réflexes avant de mettre à jour un plugin : vérifiez que la version testée indiquée dans le dépôt WordPress.org est compatible avec votre version de WordPress actuelle, lisez les commentaires récents de la page du plugin pour détecter des signalements de bugs, et réalisez la mise à jour sur un environnement de staging avant de la déployer en production. Sur un hébergement cPanel, la fonctionnalité « Rollback » de certains plugins (comme UpdraftPlus) permet de revenir en arrière rapidement si une mise à jour casse le site.

Sources

• WordPress Developer : Debugging in WordPress
• IETF RFC 9110 : HTTP Semantics, section 15.6.1 (500 Internal Server Error)
• WordPress Developer : Nginx configuration
• WordPress.org : Troubleshooting guide
• PHP.net : Incompatible changes in PHP 8.0
• Patchstack Vulnerability Database : WordPress