Ce qu'il faut retenir.
- L'erreur 500 ne précise jamais la cause elle-même : il faut activer un mode debug pour voir le détail.
- Sur WordPress, le .htaccess, un plugin ou la mémoire PHP sont les suspects principaux.
- Sur PrestaShop, le mode debug se configure dans config/defines.inc.php, et le cache var/cache doit être vidé après.
- Les logs du serveur (Apache, Nginx, PHP-FPM) donnent souvent la réponse quand l'application reste muette.
Résumé généré par IA
Erreur 500 Internal Server Error. Le message le plus frustrant qui existe : il ne dit rien sur la cause. Il touche aussi bien WordPress que PrestaShop, avec des réflexes de diagnostic différents selon la plateforme. Ce guide couvre les deux. Pour les autres pannes WordPress, voyez aussi notre panorama des 12 erreurs fréquentes.
Ce que signifie une erreur 500
Le code 500 veut dire : le serveur a rencontré un problème interne et ne sait pas quoi vous répondre d'autre. C'est une erreur générique, renvoyée aussi bien par Apache, Nginx que PHP-FPM, quelle que soit l'application derrière. Ni WordPress ni PrestaShop ne la génèrent volontairement : elle apparaît quand quelque chose plante avant que l'application ait pu produire une page normale.
Les causes les plus fréquentes
Sur WordPress
- Un fichier
.htaccesscorrompu ou mal réécrit par un plugin. - La limite mémoire PHP dépassée par un plugin ou un thème lourd.
- Une incompatibilité entre un plugin et la version de PHP du serveur, souvent après une mise à jour.
- Un fichier core ou plugin corrompu après un transfert SFTP interrompu.
Sur PrestaShop
- Un module tiers qui plante au chargement, notamment après une mise à jour de PrestaShop ou de PHP.
- Un cache Smarty (
var/cache) corrompu après une modification de template. - Une règle
.htaccessincorrecte, en particulier après un changement de structure d'URL. - Une limite PHP (mémoire, temps d'exécution) trop basse pour la taille du catalogue ou un import en cours.
Si l'erreur 500 s'accompagne de redirections en boucle plutôt que d'un blocage net, voyez notre guide ERR_TOO_MANY_REDIRECTS. Et si le site redirige vers des pages suspectes ou est signalé par Google, consultez site piraté signalé dangereux par Google.
Un point commun aux deux plateformes : l'erreur 500 apparaît souvent juste après une action identifiable, une mise à jour de plugin ou de module, un changement d'hébergement, une modification de template. Avant toute manipulation, demandez-vous ce qui a changé dans les heures précédentes. Cette simple question oriente la moitié du diagnostic sans toucher à un seul fichier.
Ce que vous pouvez tenter seul, sans risque
Étape 1 : sauvegardez. Fichiers et base de données, avant toute manipulation, via l'hébergeur ou en SFTP.
Sur WordPress
Renommez .htaccess en .htaccess.bak via SFTP, puis rechargez. Si le site revient, régénérez les permaliens depuis Réglages > Permaliens dans wp-admin. Si le blocage persiste, augmentez la mémoire PHP dans wp-config.php :
define('WP_MEMORY_LIMIT', '256M');Toujours bloqué ? Renommez wp-content/plugins en plugins_old pour tester en désactivant tout, puis réactivez les plugins un par un.
Sur PrestaShop
Activez le mode debug dans config/defines.inc.php en passant la constante suivante à true :
define('_PS_MODE_DEV_', true);Rechargez la page : PrestaShop affiche alors la pile d'erreur PHP complète, avec le fichier et la ligne en cause. Pensez à repasser cette constante à false une fois le diagnostic terminé, pour ne pas exposer ces informations aux visiteurs.
Videz ensuite le cache applicatif en supprimant le contenu de var/cache/dev et var/cache/prod (pas les dossiers eux-mêmes) via SFTP. Un cache Smarty corrompu provoque souvent une 500 qui disparaît après ce simple nettoyage.
Si un module est suspecté, désactivez-le depuis l'admin PrestaShop si l'accès fonctionne encore, ou renommez son dossier dans modules/ en SFTP sinon.
Sur une boutique volumineuse, vérifiez aussi les limites PHP globales : memory_limit, max_execution_time et upload_max_filesize. Un import de catalogue ou une synchronisation de stock trop lourde pour la configuration PHP en place déclenche exactement le même code 500 qu'un module défaillant, sans que le code lui-même soit en cause.
Dans tous les cas
Consultez les logs du serveur : error_log d'Apache ou de Nginx, logs PHP-FPM, accessibles depuis le panel de l'hébergeur ou en SSH. Quand l'application reste muette, le serveur, lui, note presque toujours la cause exacte.
Ce qu'il ne faut surtout pas faire
- Ne laissez pas le mode debug (
WP_DEBUG_DISPLAYou_PS_MODE_DEV_) activé en production au-delà du diagnostic : c'est une faille d'information exploitable. - Ne supprimez pas les dossiers
var/cache/devouvar/cache/prodeux-mêmes sur PrestaShop, seulement leur contenu : l'application doit pouvoir les recréer. - Ne réécrivez pas le
.htaccessà la main sans comprendre les règles existantes : une ligne mal placée recrée l'erreur 500 immédiatement. - N'augmentez pas indéfiniment les limites PHP sans chercher la cause réelle : un script qui boucle finira par saturer le serveur autrement.
Quand appeler un professionnel
Si les logs restent muets, si le mode debug ne s'affiche pas, ou si l'erreur touche une boutique PrestaShop en pleine vente, chaque minute compte. Un dépannage de site internet permet de poser un diagnostic précis avant d'aggraver la situation. Sur une boutique e-commerce, le coût d'une heure d'indisponibilité dépasse vite celui d'un diagnostic professionnel : mieux vaut appeler dès les premiers essais infructueux que de perdre une journée de ventes à chercher seul la cause.
Questions fréquentes
L'erreur 500 vient-elle toujours de l'application (WordPress, PrestaShop) ?
Pas toujours. Elle peut aussi venir d'une limite serveur (mémoire, temps d'exécution, PHP-FPM saturé) ou d'une mauvaise configuration Apache ou Nginx, indépendamment du code applicatif.
Le mode debug PrestaShop est-il risqué à activer ?
Seulement si vous l'oubliez activé en production : les visiteurs verraient alors des informations techniques sur votre serveur. Activez-le le temps du diagnostic, puis repassez _PS_MODE_DEV_ à false.
Vider le cache PrestaShop peut-il faire perdre des données ?
Non. Le cache var/cache est entièrement régénéré par l'application ; il ne contient aucune donnée de catalogue, de commande ou de client.
Combien de temps pour corriger une erreur 500 ?
Une fois la cause identifiée via les logs ou le mode debug, la correction prend généralement moins d'une heure, ce qui entre dans le Dépannage Express, à partir de 30 € HT.