Le code 500 Internal Server Error signifie que le serveur a rencontré une condition imprévue et n’a pas pu traiter la requête. Il ne dit pas laquelle. L’application a levé une erreur qu’elle ne sait pas transformer en réponse propre : erreur fatale PHP, exception non rattrapée, ou configuration que le serveur web refuse de charger. Le visiteur voit une page générique. Le diagnostic est dans un journal, pas à l’écran.
Ce n’est pas un délai de passerelle et ce n’est pas une maintenance annoncée.
Pannes qui finissent en 500
- Une erreur fatale PHP après une mise à jour d’extension ou de thème : fonction absente, classe manquante, incompatibilité de version.
- La mémoire PHP épuisée. Le journal contient « Allowed memory size exhausted ». La page la plus lourde tombe, les autres tiennent.
- Une erreur de syntaxe dans
.htaccess. Apache répond alors 500 sur tout le site, parfois avant même d’exécuter PHP. Le journal Apache cite le fichier et la ligne. - Une extension PHP appelée par le code mais absente du serveur (
gd,intl,mbstring) après un changement d’hébergement. - Une option WordPress dont la valeur sérialisée est tronquée. Le code fait un
unserializeet tombe. Souvent juste après un import ou un couper-coller en base. - Un chemin de fichier codé en dur vers un dossier qui n’existe plus sur le nouveau serveur.
Le point commun est une faute dans l’application ou sa configuration, pas un proxy qui attend trop longtemps.
Lire le journal avant de désactiver au hasard
- Reproduisez sur une seule URL. Notez l’heure à la seconde.
- Ouvrez le journal d’erreurs PHP de l’hébergeur, ou
wp-content/debug.logsiWP_DEBUG_LOGest actif. La ligne utile cite le fichier et le numéro de ligne. - Si tout le site est en 500 juste après une édition de
.htaccess, renommez ce fichier et retestez. S’il revient, la faute est dans les directives, pas dans WordPress. - Si le journal cite une extension, désactivez-la en renommant son dossier, via le gestionnaire de fichiers. Ne désactivez pas les vingt extensions « pour voir ».
- Comparez avec un test d’URL extérieur. Un 500 vu seulement sur votre poste peut être un cache local. Un 500 vu de l’extérieur est bien servi par le site.
Gardez display_errors à l’arrêt en production. Le message à l’écran aide l’attaquant autant que vous, et le journal suffit.
Remettre la page en état
| Cause lue dans le journal | Correctif |
|---|---|
| Erreur fatale dans une extension | Revenir à la version précédente, ou la désactiver le temps du correctif |
| Mémoire épuisée | Traiter la page qui consomme, puis seulement ensuite relever la limite si le besoin est réel |
Syntaxe .htaccess | Restaurer la dernière version valide |
| Extension PHP manquante | L’activer chez l’hébergeur, ne pas réécrire le code autour |
| Donnée sérialisée cassée | Restaurer la ligne depuis une sauvegarde, ne pas la réparer à la main sans copie |
Après le correctif, l’URL doit répondre 200 avec le contenu attendu. Contrôlez aussi une seconde URL du même modèle, par exemple une autre fiche, pour vérifier que le correctif n’est pas local à un seul contenu.
Ce qu’il ne faut pas faire
N’affichez pas la pile d’erreur aux visiteurs. Ne remplacez pas un 500 subi par un 200 qui montre « une erreur est survenue » : pour un moteur, la page existe et son texte d’erreur peut être indexé. Une coupure voulue se fait en 503 avec Retry-After, le temps de corriger. N’augmentez pas les délais du proxy : le 500 revient souvent en quelques millisecondes, la requête n’attend pas.
Vérifiez ensuite que la page tient dans le temps, pas seulement dans votre navigateur. La méthode pour tester si un site répond vraiment distingue un 500 réel d’une page d’erreur affichée avec un code 200.