Un site qui affiche une erreur 500 peut transformer une journée de travail normale en enquête de detective. Pas parce que c’est mystérieux, mais parce que ça peut venir de dizaines d’endroits différents: serveur, droits, mémoire PHP, plug-in qui plante, base de données en vrac, ou même un script qui a tourné trop longtemps après une mise à jour WordPress ratée. J’ai déjà vu des erreurs 500 apparaître juste après un changement de thème, et d’autres fois juste après une modification “anodine” côté hébergement, comme l’activation d’un module ou un ajustement des limites PHP.
Dans ce billet, je raconte une méthode de dépannage réaliste quand votre WordPress tombe avec une erreur 500, puis je détaille comment optimiser la mémoire pour éviter que ça ne revienne. Et, parce que les boutiques ne jouent pas à “croisons les doigts”, je fais aussi des ponts utiles pour un site PrestaShop (page blanche, boutique PrestaShop inaccessible, maintenance PrestaShop) et pour WooCommerce en panne.
D’abord, clarifier ce que signifie vraiment “erreur 500” sur WordPress
Sur WordPress, une erreur critique WordPress de type “500” est un symptôme. Ce n’est pas une cause. Le serveur dit “j’ai un problème interne”, mais il ne vous dit pas lequel. En pratique, les causes les plus fréquentes que je vois sur le terrain se regroupent en quelques familles.
La première, ce sont les limites PHP et la mémoire. Un site peut “tenir” un jour, puis exploser après une mise à jour WordPress ratée ou après l’installation d’un plug-in gourmand, surtout si un script commence à charger trop de données en une fois. Dans ce cas, le serveur renvoie 500 même si WordPress n’arrive pas à afficher un message propre.
La deuxième famille, ce sont les fichiers qui ne peuvent pas s’exécuter ou qui cassent l’exécution. Mauvais droits, fichier corrompu, mise à jour interrompue, ou un plugin qui contient une erreur fatale. J’ai déjà vu un “simple” mini-serveur de cache qui tournait en boucle et faisait tomber le site. J’ai aussi vu un fichier .htaccess partiellement réécrit lors d’un réglage de sécurité, ce qui suffit pour casser tout le trafic.
La troisième, plus délicate, c’est quand le site WordPress piraté déclenche des comportements inattendus: webshell, backdoor, requêtes externes, ou usage massif de ressources pour miner. Dans ces scénarios, on peut avoir un 500 parce que PHP atteint une limite, parce que le serveur sature, ou parce que le code malveillant plante. Et il faut agir vite, non seulement pour restaurer la page, mais pour nettoyer durablement.
Avant de toucher à quoi que ce soit, je commence toujours par observer. Pas au feeling, au moyen d’indices.
Les indices qui orientent le diagnostic, sans perdre du temps
Quand un site WordPress en panne affiche 500, je cherche d’abord des traces dans deux endroits: les logs d’erreur serveur, et les traces d’exécution PHP si vous y avez accès.
Selon votre hébergeur, vous verrez une forme de détail dans les logs: erreur PHP fatale, mémoire épuisée, problème de permission, appel de fonction introuvable, ou chargement d’un fichier manquant. Sans logs, on peut bricoler, mais c’est plus lent et plus risqué.
Voici ce que je vérifie en premier, dans un ordre qui évite les fausses pistes.
- Heure approximative du déclenchement: juste après une mise à jour WordPress ratée, après une modification de thème, après une purge de cache, après un déploiement?
- Est-ce que l’erreur arrive aussi en mode connecté administrateur, ou seulement pour les visiteurs?
- Le site est-il complètement inaccessible, ou seulement certaines pages (page d’accueil, WooCommerce, back-office)?
- Si vous avez plusieurs domaines pointant vers la même instance, est-ce que tous affichent la même erreur 500?
- La charge serveur a-t-elle augmenté récemment, ou y a-t-il eu une hausse de trafic, ou un bot agressif?
Ces questions ne remplacent pas les logs, mais elles réduisent énormément le champ des possibles. Un 500 total, instantané après une mise à jour, ressemble souvent à une erreur PHP fatale ou à un fichier de plug-in corrompu. Un 500 qui apparaît sous charge ressemble davantage à un problème de mémoire ou à un traitement qui devient trop lourd.
Récupération d’un site WordPress après une erreur 500: la stratégie “ne pas aggraver”
Quand je dépanne un site internet, mon objectif est double: rétablir rapidement la consultation, puis réparer proprement. Je traite le “rétablir” comme une phase de stabilisation, même si ça veut dire faire des désactivations temporaires.
Je commence par isoler la partie qui casse l’exécution.
Si vous avez accès à l’espace d’administration WordPress, c’est plus simple. Sinon, on passe par le FTP ou le gestionnaire de fichiers.
La règle d’or que j’applique: désactiver ce qui peut provoquer une erreur, sans supprimer ce qui peut servir de preuve. Autrement dit, je préfère “mettre en sommeil” un plug-in ou un thème, plutôt que d’effacer des fichiers en mode panique.
Étape rapide: mettre WordPress au régime “sécurisé”
Souvent, un 500 se produit parce qu’un plug-in ou un thème exécute du code dès le chargement. Dans ce cas, désactiver automatiquement ce code peut sauver le site.
Voici la logique que j’utilise (sans entrer dans des commandes trop techniques, parce que chaque hébergeur a ses interfaces):
J’ai une anecdote qui revient souvent: sur un site WordPress qui faisait 2 000 visiteurs par jour, l’erreur 500 apparaissait uniquement sur la page produit. Après investigation, le plug-in de mise en page du catalogue chargeait un flux trop lourd, et au moment d’un changement d’API externe, le code devenait instable. La désactivation temporaire a restauré le site immédiatement. L’analyse plus fine a ensuite révélé un problème de requête et des appels répétitifs. C’est exactement ce que cette stratégie permet: revenir à un fonctionnement stable pendant que vous diagnostiquez.
Quand l’erreur 500 cache un problème de mémoire PHP
Même si vous résolvez la cause immédiate, un site qui s’effondre par manque de mémoire finira par recommencer. La mémoire est rarement “le seul” problème, mais elle révèle souvent une mauvaise pratique, un plug-in trop gourmand, ou un traitement mal configuré.
Les symptômes que je reconnais:
- la page 500 arrive surtout quand vous générez quelque chose (recherche, panier WooCommerce, filtres, pages de catégories très chargées);
- l’erreur mentionne “Allowed memory size” dans les logs;
- le site fonctionne au calme, mais casse dès qu’il y a un peu de charge.
Dans WordPress, la mémoire peut être consommée par le chargement de thèmes, par des requêtes SQL répétées, par des shortcodes qui appellent des contenus externes, ou par des plug-ins de sauvegarde, de cache, ou de sécurité qui font des parcours sur de grosses tables.
Et si vous venez de vivre une mise à jour WordPress ratée, il y a un cas fréquent: le site a été partiellement mis à jour, et certains composants n’ont pas la compatibilité attendue. Résultat, WordPress charge plus de choses qu’avant, ou exécute deux fois certaines tâches. Là encore, la mémoire saute.
Optimiser la mémoire sur WordPress sans casser l’existant
Optimiser la mémoire, ce n’est pas juste augmenter la valeur de memory_limit. Augmenter peut dépanner, mais si vous corrigez la racine, vous stabilisez vraiment. Sur un site vivant, je vise un équilibre entre performance et stabilité, parce qu’un site qui “survit” avec une mémoire trop basse finira par revenir en 500 dès qu’un pic arrive.
Ce que je fais en pratique
Je commence par identifier les éléments qui consomment le plus. Selon l’accès que vous avez, cela peut passer par:
- un examen des logs d’erreur pour voir si la mémoire explose pendant un traitement précis;
- une vérification du cache (cache total, cache des pages, cache d’objets si c’est supporté);
- une liste des plug-ins récemment ajoutés ou mis à jour.
Ensuite, j’applique des changements qui réduisent les volumes chargés et la quantité de traitements.
Voici un mini-axe de travail, utile quand on ne veut pas tout réécrire:
- désactiver temporairement les plug-ins “lourds” pour confirmer qu’ils ne sont pas la cause;
- vérifier et limiter les requêtes dans les parties critiques (recherche, pages produits, pages de filtres);
- optimiser la base de données si certaines tables gonflent (révisions, transients obsolètes);
- activer ou ajuster un mécanisme de cache adapté (page cache d’abord, puis cache applicatif si nécessaire);
- garder une approche prudente avec les limites PHP, en préférant corriger le code ou la configuration plutôt que d’augmenter indéfiniment.
Ce Cliquez pour plus d’informations n’est pas magique, mais c’est efficace, surtout quand vous avez un site qui a déjà montré des signes de fragilité.
Rétablir rapidement sans perdre les données: la logique de sauvegarde
Quand un site WordPress en panne s’affiche, la tentation est de “tout remettre comme avant”. C’est souvent la bonne direction, mais avec une contrainte: il faut préserver ce que vous avez, y compris l’état actuel, au moins le temps de comprendre.
Sur un dépannage WordPress, je demande presque toujours au client une ou deux informations clés: la dernière modification connue, et si une sauvegarde existe juste avant.
Si vous avez une sauvegarde (automatique ou manuelle), je la compare en priorité aux fichiers actuels si possible. Dans certains cas, une restauration complète est trop brutale, surtout si la base de données a été partiellement modifiée. Je préfère alors restaurer la partie fichiers (thèmes, plug-ins, noyau WordPress) pour retrouver un socle propre, tout en investiguant la base à part.
Et si vous soupçonnez un site WordPress piraté, je ne restaure pas un “backup” sans nettoyer ou vérifier la contamination. Restaurer une base infectée, c’est repartir pour la prochaine erreur 500, et potentiellement refaire entrer du trafic malveillant.
Et si c’était lié à un thème, un plug-in, ou une mise à jour ratée?
Les erreurs 500 sur WordPress après une mise à jour sont très fréquentes. Il y a une différence entre “le site ne démarre plus” et “le site démarre mais certaines pages cassent”.
Quand c’est global, je me méfie des composants exécutés au chargement: plug-ins qui hookent trop tôt, autoload qui sature, ou fonctions incompatibles.
Quand c’est localisé (par exemple WooCommerce en panne, ou la page panier), je suspecte un plug-in spécifique ou un thème qui interagit mal avec WooCommerce.
Un exemple que j’ai vu sur une boutique: après un changement de version PHP côté hébergement, le site n’affichait plus correctement les pages de checkout. La page 500 n’était pas systématique, mais elle apparaissait lors de calculs de taxes ou de frais. Les logs mentionnaient des appels de fonctions devenues obsolètes. Le correctif a consisté à mettre à jour le plug-in de paiement et à adapter un template du thème. Le fait d’avoir “augmenté la mémoire” a peut-être masqué le problème temporairement, mais la cause était l’incompatibilité.
Sécurité: quand le 500 est un signal, pas seulement un crash
Parfois, l’erreur 500 est le début d’une histoire plus inquiétante: site WordPress piraté, réparation site WordPress piraté, backdoor. Je ne “conclus” pas sans preuves, mais je ne minimise pas.
Quelques indices qui m’orientent vers un examen sécurité:
- un pic de trafic anormal vers des fichiers étranges;
- des fichiers modifiés récemment, dans des répertoires inattendus;
- des appels sortants (requêtes externes) qui n’ont aucun sens pour le site;
- des erreurs PHP qui changent de forme, comme si quelque chose ajoutait du code.
Dans ce cas, la récupération doit aller plus vite que la “simple réparation”. La priorité devient: arrêter l’exécution du code suspect, rétablir un environnement propre, puis patcher.
Même si vous ne voulez pas tout faire vous-même, demandez au prestataire d’avoir un plan clair: vérification des fichiers, contrôle des hooks et des contenus injectés, changement des mots de passe, et validation du nettoyage.
Point pratique: WordPress et WooCommerce en panne, où regarder en premier
Si votre boutique affiche un 500 mais que WordPress “général” semble accessible, je me concentre en priorité sur WooCommerce. Les erreurs peuvent venir de:
- plug-ins de paiement;
- plug-ins de livraison;
- règles de panier et de taxes;
- thème qui surchargerait des templates.
La logique de dépannage reste la même, mais je repère mieux les symptômes: page de produit OK, panier KO, checkout KO, ou au contraire le back-office WooCommerce KO.
Dans les cas de mémoire, WooCommerce peut consommer beaucoup lors de la génération de contenus, du calcul des variations, ou de l’affichage de listes produits très chargées. Un plug-in de filtres catalogues mal optimisé peut multiplier les requêtes. Si vous avez déjà vu une mémoire épuisée, l’action la plus rentable est souvent de remplacer ou de mettre à jour le plug-in gourmand, plutôt que d’augmenter la limite.
Et si votre site est PrestaShop en panne aussi? Les erreurs blanches et la maintenance
Les dépannages WordPress et dépannage PrestaShop se ressemblent sur la forme, mais pas sur le fond. Sur PrestaShop, une page blanche PrestaShop peut masquer un crash du PHP, un problème de configuration, ou un module qui tombe.
Si votre boutique PrestaShop inaccessible affiche une page vide, je traite ça comme un crash d’exécution: activer temporairement le mode debug si c’est possible, regarder les logs, puis désactiver les modules récents. Les erreurs 500 ne sont pas identiques, mais l’idée reste la même: stabiliser, isoler, puis corriger.
Et si le site devait passer par une maintenance PrestaShop, la mise à jour PrestaShop ratée peut aussi provoquer des incohérences. Un module partiellement mis à jour, ou des permissions incorrectes dans les répertoires, peuvent rendre le front instable.
Quand PrestaShop est en panne, l’optimisation mémoire existe aussi, surtout pour les pages de catalogue qui chargent beaucoup de produits, ou pour certaines fonctions de cache.
Le parallèle utile avec WordPress, c’est la discipline de diagnostic: logs d’erreur, isolation des composants, vérification des changements récents. Le reste, c’est de la technique spécifique à la plateforme.
Ajuster l’environnement: PHP, permissions, et configuration serveur
Un dépannage site internet sérieux ne s’arrête pas à “casser le problème”. Il faut aussi vérifier l’environnement.
Sur WordPress, l’erreur 500 peut venir de:
- un changement de version PHP côté hébergement;
- des permissions incorrectes sur certains dossiers (wp-content, uploads, caches);
- un .htaccess qui pointe vers des règles invalides;
- un cron mal configuré ou des tâches en boucle.
Pour PrestaShop, c’est similaire sur la partie serveur, mais vous regardez plus souvent les répertoires de cache, les permissions et les modules.
Le point délicat, c’est que ces erreurs peuvent être silencieuses jusqu’au moment où un module fait une action coûteuse. Par exemple, un cron qui purge trop tard, un plugin qui reconstruit des caches au mauvais moment, ou un processus qui n’a plus la permission d’écrire.
Quand vous travaillez sur un site en urgence WordPress, vous devez agir vite, mais sans transformer le serveur en chantier permanent. Je fais donc toujours les changements par petites touches, et je teste après chaque étape.
Un cas réel, typique: restauration, puis stabilisation mémoire
Je vous raconte un scénario fréquent, parce qu’il ressemble beaucoup à ce que rencontrent les équipes marketing et e-commerce.
Le client m’appelle un matin: “la boutique est en panne, erreur 500 sur WordPress, et depuis la dernière mise à jour, tout a dérapé”. À l’ouverture, l’erreur est globale. Les logs mentionnent une erreur fatale liée à un plug-in. En parallèle, il y a aussi un message “memory exhausted” sur un autre horodatage.
Je fais d’abord un retour au stable: je désactive les plug-ins en masse, puis je remets les plug-ins essentiels, et j’identifie celui qui plante. Une fois le site accessible, je ne me contente pas de “c’est réparé”. Je replonge dans les logs et je vois que le plug-in de mise en cache ou celui de génération de pages est aussi à l’origine du pic mémoire, surtout quand certains contenus sont demandés.
Le correctif final ne consiste pas uniquement à augmenter mémoire_limit. Il consiste à:
- mettre à jour le plug-in en cause vers une version compatible;
- ajuster la manière dont le cache est généré;
- nettoyer des transients accumulés et des révisions inutiles;
- activer une stratégie de cache cohérente.
Résultat: le site revient, puis il reste stable. Et le client n’a plus cette peur quotidienne de la prochaine mise à jour ou du prochain pic.
Validation après réparation: s’assurer que ce n’est pas “juste une page qui revient”
Une erreur 500 peut disparaître parce que WordPress a “contourné” le point de rupture, mais le site peut rester fragilisé. J’ai déjà vu un site redevenir accessible, puis planter à nouveau lors de la génération d’une page spécifique.
Après chaque réparation, je teste au minimum:
- une navigation front complète sur les pages les plus visitées;
- les actions dynamiques (panier WooCommerce, recherche, formulaires);
- l’accès back-office et la sauvegarde d’un brouillon;
- la régénération de cache si elle existe.
Ce test n’est pas un luxe. C’est ce qui évite de livrer un “site réparé” qui casse dès le lendemain.
Prévenir la récidive: discipline de maintenance WordPress et maintenance PrestaShop
Une récupération réussie est toujours suivie par une question: comment éviter que ça recommence?
Sur WordPress, ma base de prévention s’articule autour de trois axes: compatibilités, ressources, et changements.
D’abord, je recommande de planifier les mise à jour WordPress ratée avant qu’elles ne deviennent un risque: tester sur un environnement de staging quand c’est possible, et garder une fenêtre de mise à jour courte. Beaucoup d’erreurs viennent de mises à jour qui ont été lancées en même temps que d’autres changements, plugins nouveaux et modifications de thème.
Ensuite, je surveille la mémoire et les caches. Un site qui consomme trop n’est pas “cassé”, mais il est fragile. Quand une limite approche, un changement de trafic ou une nouvelle fonctionnalité le fait tomber.
Enfin, je garde une trace des interventions. Même si vous travaillez avec un prestataire, notez les dates, les plug-ins concernés, les réglages serveur modifiés. Dans les dépannages WordPress ou dépannages PrestaShop, c’est cette chronologie qui accélère le diagnostic.
Quand contacter un professionnel, et quoi demander (sans perdre le contrôle)
Vous pouvez faire beaucoup en interne si vous avez accès aux logs et aux fichiers. Mais quand il y a des signaux de piratage, des restaurations compliquées, ou des erreurs persistantes malgré une désactivation en cascade, vous gagnerez du temps à faire intervenir quelqu’un.
Ce que j’attends d’un bon prestataire, c’est un rapport clair, pas juste “c’est bon”. Je veux qu’on me dise ce qui a été testé, ce qui a été identifié, et ce qui a été modifié. Pour un cas d’ urgence WordPress, je demande aussi une restitution sur la mémoire: qu’est-ce qui consommait, quel levier a été ajusté, et quelles limites sont désormais fixées.
Voici un court cadre de questions que je trouve utile au moment de lancer une réparation site WordPress ou réparation site PrestaShop:
- Où sont les causes exactes dans les logs (erreur fatale, permissions, mémoire, plugin spécifique)?
- Qu’est-ce qui a été désactivé ou remplacé pour restaurer l’accès?
- La correction traite la racine ou seulement le symptôme (par exemple, mémoire augmentée au lieu d’optimiser)?
- Si sécurité il y a, qu’est-ce qui a été nettoyé et comment a-t-on vérifié l’absence de persistance?
- Quelles mesures de maintenance ou d’optimisation mémoire seront mises en place pour éviter un retour du problème?
Cas particulier: récupération quand vous n’avez aucune sauvegarde récente
Il arrive qu’une entreprise lance une maintenance, fasse une mise à jour, et découvre le problème sans backup récent. Là, la stratégie change légèrement.
Vous pouvez restaurer le code (noyau WordPress, thèmes connus, plug-ins) à partir des sources officielles, puis remettre progressivement les composants. Sur WordPress, cela revient à reconstruire un environnement propre et vérifier à chaque étape.
Sur PrestaShop et PrestaShop maintenance, c’est pareil: vous remettez les fichiers de base connus, puis les modules.
Le point crucial reste la base de données. Sans sauvegarde, vous pouvez parfois revenir en arrière sur la structure, mais si les données sont corrompues ou si des tables ont été modifiées, la restauration peut devenir plus complexe. C’est une raison de plus pour intégrer des routines de sauvegarde et de staging à votre maintenance.
En bref, ce que j’ai appris en dépannant des sites en cascade
Un dépannage site internet efficace n’est pas une course à la suppression. C’est une enquête guidée par des preuves, et un plan d’action qui évite l’escalade. Quand l’erreur 500 WordPress tombe, je traite d’abord l’exécution cassée (plug-in, thème, permissions, .htaccess), puis je regarde la mémoire et les routines (cache, transients, requêtes). Et si je suspecte un site WordPress piraté, je passe en mode correction sécurité avant de “faire semblant que c’est revenu”.
Sur PrestaShop, page blanche PrestaShop et boutique PrestaShop inaccessible suivent la même philosophie: logs, modules, configuration, maintenance PrestaShop. Et sur WooCommerce en panne, je cible ce qui est branché sur les pages dynamiques et ce qui surcharge les calculs.
Si vous venez de vivre une erreur 500 WordPress, retenez ceci: la correction immédiate rétablit l’accès, l’optimisation mémoire empêche la récidive, et la maintenance bien cadrée réduit la probabilité que la prochaine mise à jour WordPress ou mise à jour PrestaShop ratée vous replonge dans le noir.
Si vous voulez, dites-moi ce que vous voyez dans vos logs (même en copiant une ou deux lignes clés), et si l’erreur apparaît sur toute la navigation ou seulement sur certaines pages. Avec ces deux infos, on peut généralement resserrer le diagnostic très vite.