Erreur 500 sur un site Web : Comment la corriger
Un guide étape par étape pour diagnostiquer et corriger une erreur interne du serveur 500 en vérifiant .htaccess, les plugins, les thèmes et les limites du serveur.
Erreur 500 sur un site Web : comment la corriger - Guide étape par étape
Vous vous demandez comment corriger l'erreur interne du serveur 500 sur un site Web ? Elle apparaît souvent non pas un jour calme de la semaine, mais juste au moment où le trafic augmente, qu'une campagne publicitaire se lance ou juste après une autre mise à jour. L'erreur 500 signifie une erreur interne du serveur : la page n'a pas renvoyé de réponse, mais le navigateur n'a pas non plus obtenu de raison précise - juste un signal d'échec générique. C'est frustrant, mais cela peut être diagnostiqué. Presque toujours.
La bonne nouvelle est qu'une erreur 500 n'apparaît que rarement de nulle part. La plupart du temps, elle est causée par un code défectueux, un processus PHP échoué, un fichier .htaccess endommagé, des plugins ou un thème en conflit, ou un serveur atteignant des limites de mémoire et de temps d'exécution. L'hôte peut également être le coupable. Ou le dernier commit.
Si le site génère déjà des prospects ou des ventes, même 10 minutes d'indisponibilité nuisent à la fois aux revenus et à la confiance. C'est pourquoi l'ordre des actions compte plus que des suppositions : d'abord isoler le problème, puis changer les paramètres. Pas de chaos.
1. Ce que signifie une erreur 500 et pourquoi elle apparaît
L'erreur interne du serveur n'est pas un diagnostic, mais un terme générique pour plusieurs pannes. Le serveur a reçu la demande, a essayé de la traiter et a rencontré un problème qu'il n'a pas pu montrer à l'utilisateur de manière appropriée. Extérieurement, tout semble identique : une page blanche, un message d'erreur, parfois un écran vide.
Il y a 5 causes les plus courantes. La première est une erreur de code PHP après avoir modifié un modèle ou une fonction. La deuxième est des règles incorrectes dans .htaccess. La troisième est un conflit de plugin ou de thème. La quatrième est un manque de ressources : memory_limit, max_execution_time, temps CPU. La cinquième est une défaillance côté serveur ou hébergement. Et il y a une sixième, très ordinaire : les permissions de fichier sont mal définies.
Sur WordPress et des plateformes CMS similaires, cela est particulièrement visible après des mises à jour. Un plugin se met à jour, un autre ne le fait pas, le cache reste ancien, et le thème appelle une fonction qui a déjà été supprimée. Le résultat est une courte mais désagréable cascade. L'erreur 500 aime ce genre de combinaison, c'est pourquoi Dépannage de l'erreur 500 de WordPress commence souvent par des mises à jour, le cache et des vérifications de compatibilité.
Si le site est construit comme une application web, la chaîne peut être plus longue : API, file d'attente de tâches, base de données, service de paiement externe. Dans des projets comme ça, il est utile de penser à l'avance à la sécurité des sites web et à la logique de récupération de sauvegarde, car un incident sans journaux d'événements transforme le dépannage en devinette.
2. Tout d'abord, vérifiez où exactement l'erreur se produit
La première étape est de comprendre l'étendue. L'erreur 500 est-elle seulement sur une page ? Ou sur l'ensemble du site ? Ou peut-être apparaît-elle dans la zone admin tandis que la partie publique se charge encore ? Ces 3 cas pointent vers des causes différentes, et cette vérification de l'étendue est le plus rapide solution d'erreur 500 du site web point de départ.
Si l'erreur apparaît seulement sur une page, recherchez du code local : un shortcode, un widget, un formulaire, un modèle personnalisé ou un script intégré. Si l'ensemble du site est hors ligne, vérifiez .htaccess, PHP et les limites système. Si la zone admin ne s'ouvre pas, inspectez les plugins et le thème. Après une mise à jour, le problème se cache souvent là.
Une erreur 500 apparaît également souvent après un déménagement vers un nouvel hébergeur. Les paramètres PHP peuvent différer, les permissions de dossier peuvent également différer, et les anciennes règles de configuration ne s'adaptent pas toujours au nouvel environnement. Une migration. Une surprise.
Il est utile de noter quand tout a cassé : après l'installation d'un plugin, le changement de thème, le passage à une version PHP différente ou le déménagement du site. Cette petite chronologie fait gagner des heures. Parfois, une journée entière.
3. Comment vérifier .htaccess et les plugins
.htaccess est un coupable courant. Une mauvaise directive suffit pour que le serveur commence à renvoyer des erreurs 500 sur presque chaque page. Surtout si les redirections, les règles de mise en cache ou les permaliens jolis ont été modifiés manuellement.
Le test le plus simple consiste à renommer temporairement le fichier .htaccess, par exemple en .htaccess_old. Si le site revient à la vie, vous avez probablement trouvé la cause. Ensuite, créez un nouveau fichier et enregistrez à nouveau les paramètres de permalien dans le panneau d'administration du CMS. Dans WordPress, cela se fait via la section Permaliens, sans copier manuellement les règles.
Si l'erreur disparaît après avoir recréé les règles, il est préférable de ne pas remettre l'ancien fichier. Il peut encore contenir une ligne supplémentaire, par exemple d'un ancien plugin qui a déjà été supprimé. Une directive supplémentaire peut faire tomber l'ensemble du site. Pas seulement en théorie.
Lorsqu'un site utilise une structure de redirection complexe, surtout après une refonte, il vaut la peine de vérifier à l'avance comment se comportent les anciennes URL et les liens canoniques. Pour les projets avec un rafraîchissement structurel, il peut être utile de lire sur comment choisir un studio web pour une refonte de site web, afin de ne pas se retrouver avec de la confusion dans les règles du serveur et les routes internes.
4. Désactiver les plugins et vérifier le thème
Si .htaccess est propre, passez aux plugins. Sur WordPress, c'est rapide : renommez le dossier des plugins via le gestionnaire de fichiers ou FTP. Tous les plugins seront désactivés d'un coup. Si l'erreur 500 disparaît, la cause est l'un d'eux.
Ensuite, activez les plugins un par un. Vérifiez le site après chaque activation. C'est ainsi que vous trouvez le module en conflit, même s'il y en a 17. Fastidieux ? Oui. Efficace ? Oui aussi.
Les coupables typiques sont les plugins de mise en cache, de sécurité, de SEO, de création de pages, et toutes les extensions qui interfèrent avec le routage ou la génération de contenu. Parfois, le problème n'est pas le plugin lui-même, mais une version obsolète de celui-ci. Cela a tendance à se manifester surtout après une mise à jour.
Faites de même avec le thème : passez temporairement au thème par défaut du CMS. Si la zone d'administration est indisponible, renommez le dossier du thème actif via FTP afin que le système revienne à une option de sauvegarde. Si l'erreur 500 disparaît, le thème contient un modèle cassé, un hook incompatible ou un appel de fonction obsolète.
Lorsque le site est lié à des services externes, tels que les paiements, le code d'intégration peut parfois déclencher l'erreur. Dans de tels cas, il est utile d'évaluer le flux de paiement et de mettre à jour les risques à l'avance. Par exemple, jetez un œil à combien cela coûte de connecter Stripe à un site web si vous avez une logique d'intégration et de redirection similaire.
5. Vérifiez les erreurs PHP et les limites du serveur
Si les plugins et le thème ne posent pas de problème, regardez les journaux. Les journaux d'erreurs PHP montrent généralement quel fichier, ligne ou fonction a échoué. Parfois, ils le disent directement : taille de mémoire autorisée épuisée. Parfois : erreur fatale. Parfois : rien du tout, ce qui est pire.
Les journaux peuvent se trouver dans le panneau de contrôle d'hébergement, dans un dossier séparé du site ou dans les rapports système du serveur. Différents fournisseurs les stockent à différents endroits, donc le panneau d'hébergement est généralement nécessaire ici. Vérifiez au moins 2 endroits : le journal des erreurs du site et le journal système du compte.
Maintenant, passons aux paramètres PHP. Recherchez memory_limit, max_execution_time, upload_max_filesize, post_max_size, et la version PHP. Si le site a commencé à planter après une mise à jour de la version PHP, revenir à une version compatible résout souvent le problème. Si la mémoire est trop faible, une page lourde, un import ou un plugin n'a tout simplement pas assez de temps pour finir.
Le memory_limit ce paramètre est particulièrement important pour les magasins et les grands catalogues. Un export de produit peut utiliser l'intégralité des ressources. Un formulaire d'importation peut également le faire. Si le site utilise des analyses, des files d'attente, des tâches en arrière-plan et de la surveillance, il vaut la peine d'avoir un plateforme d'analyse et de surveillance de site · comme partie de votre pile d'observation, afin que vous puissiez voir les pannes à partir des journaux plutôt qu'à partir d'une plainte de client.
Si vous n'êtes pas sûr de l'endroit où vérifier les paramètres, demandez à votre hébergeur de montrer la configuration PHP actuelle et les limites du serveur. Vérifiez non seulement la version PHP, mais aussi la limite de mémoire réelle, le temps d'exécution et la taille de téléchargement. Il est surprenant de voir à quel point le problème est souvent juste une valeur.
6. Videz le cache et examinez les modifications récentes
Le cache peut cacher à la fois le problème et le fait qu'il est résolu. Donc, après avoir apporté des modifications, videz le cache du site, le cache du navigateur et le cache CDN si vous en utilisez un. Sinon, vous regarderez une ancienne version de l'erreur et penserez que rien n'a changé.
Commencez par vider le cache dans le panneau CMS ou dans le plugin de mise en cache. Ensuite, videz le cache du navigateur, de préférence en mode incognito. Si le site est servi via un CDN, purgez-le aussi. Trois endroits, trois caches, un résultat — seulement après un nettoyage complet pouvez-vous faire confiance au test.
Ensuite, passez en revue les dernières modifications. Avez-vous ajouté un nouveau bloc ? Modifié une fonction dans le modèle ? Téléchargé un fichier frais dans la bibliothèque ? Revenez à la dernière modification et testez à nouveau. Une erreur 500 apparaît souvent après une petite ligne de code, pas après une « mise à jour majeure ».
Dans les projets avec un support continu, ces problèmes sont généralement moins courants car les modifications de code et de paramètres passent par un contrôle. Si votre site est actif et régulièrement amélioré, l'article sur support du site après le lancement peut vous aider à voir comment ne pas laisser le cache et les mises à jour dériver vers un état de panne.
Vérifiez également si le CDN a été rompu après des modifications SSL, des redirections ou une mise à jour de la politique de sécurité. Un mauvais en-tête de réponse peut déclencher une erreur 500 pour seulement une partie de vos utilisateurs. Et c'est beaucoup plus difficile à détecter.
7. Que faire si l'erreur 500 ne disparaît pas
Si le site continue de planter après toutes les vérifications, il est temps de travailler de manière systématique. Commencez par contacter le support d'hébergement et demandez des journaux pour l'heure exacte de la panne. Donnez l'heure, la date et la page où l'erreur 500 s'est produite. Sans cela, le support mettra plus de temps à le trouver.
Vérifiez ensuite les permissions des fichiers et des dossiers. Les gens définissent souvent les dossiers sur 777 « temporairement » et oublient ensuite de les changer. C'est une mauvaise pratique, et pas seulement à cause de l'erreur 500 : le serveur peut bloquer de telles permissions pour des raisons de sécurité. Les fichiers et les répertoires doivent avoir des permissions correctes.
Si vous avez une sauvegarde récente, restaurez la version fonctionnelle du site et voyez si le problème disparaît. Cela est particulièrement utile après une mauvaise mise à jour du noyau, d'un plugin ou d'une migration de serveur. Un retour en arrière fait gagner plus de temps que d'essayer de corriger manuellement 12 changements incompatibles.
Lorsque le site est important pour l'entreprise, ne retardez pas la récupération. Parfois, il est moins cher de restaurer la copie d'hier que de passer une demi-journée à chercher une ligne de code. Et si le projet dépend de requêtes externes, de formulaires et d'APIs, vérifiez également le côté réseau : parfois, le problème ne se trouve pas dans le CMS, mais dans l'infrastructure. Pour des cas comme celui-ci, un infrastructure de réseau privé peut aider lorsque une partie de la complexité se déplace dans un environnement contrôlé.
La dernière étape pratique consiste à passer temporairement le site à une configuration minimale. Gardez uniquement le noyau, un thème, un plugin fonctionnel et les règles de base. Si l'erreur 500 disparaît dans ce mode, ajoutez les composants un par un. De cette façon, vous trouverez l'élément problématique sans deviner inutilement. C'est lent, mais honnête.
