Erreur 500 (Internal Server Error)

L'erreur 500 (Internal Server Error) est un code de statut HTTP par lequel un serveur signale qu'une condition inattendue l'a empêché de traiter la requête. C'est l'erreur serveur générique : contrairement aux 502, 503 et 504, qui décrivent un intermédiaire ou une indisponibilité, elle vient du site lui-même, de son code, de sa configuration ou de ses ressources. Pour Google, une 500 ponctuelle est sans conséquence ; une 500 qui se répète ralentit l'exploration, puis fait sortir les pages de l'index.

Définition détaillée de l'erreur 500

Les codes HTTP de la classe 5xx signifient que le serveur sait qu'il a échoué, ou qu'il est incapable d'exécuter la méthode demandée. Le code 500 est le premier de cette classe et le plus général : la RFC 9110, qui définit la sémantique de HTTP depuis juin 2022, le décrit comme le signal d'« une condition inattendue qui a empêché le serveur de satisfaire la requête ». Le serveur ne dit pas ce qui s'est passé, seulement que quelque chose a cassé de son côté.

C'est ce qui distingue la 500 de ses voisines. Une 503 annonce une indisponibilité temporaire, souvent volontaire (maintenance, surcharge). Une 502 ou une 504 vient d'un intermédiaire, proxy, répartiteur de charge ou CDN, qui n'obtient pas de réponse valide de l'origine ou l'obtient trop tard. Une 522 est un code propre à Cloudflare pour une connexion à l'origine qui échoue. La 500, elle, est produite par l'application ou le serveur web du site : le script a planté, la configuration est invalide, une ressource manque. En pratique, c'est aussi le code que renvoient par défaut Apache, nginx ou PHP quand une erreur fatale survient sans qu'un code plus précis ait été prévu.

Le visiteur voit une page blanche, une page d'erreur du serveur ou, sur un CMS, un message du type « Une erreur critique est survenue sur ce site ». Le robot d'un moteur, lui, ne voit que le code : le contenu qui accompagne une réponse 500 est ignoré, quel qu'il soit.

D'où vient une erreur 500

Parce qu'elle est générique, la 500 a beaucoup de causes possibles. Les plus fréquentes sur un site éditorial ou marchand :

• Une erreur dans le code de l'application : erreur fatale PHP, exception non gérée, appel à une fonction absente après une mise à jour. Sur un CMS, le coupable est le plus souvent une extension ou un thème incompatible avec la version du cœur ou de PHP.
• Un fichier de configuration invalide : une directive mal écrite dans le .htaccess d'Apache suffit à mettre tout le site en 500, y compris les fichiers statiques. C'est la cause classique après l'installation d'une extension de cache, de sécurité ou de réécriture d'URL.
• Des ressources épuisées : limite de mémoire PHP atteinte, temps d'exécution maximal dépassé, disque plein, trop de connexions ouvertes vers la base de données.
• Des droits de fichiers incorrects : après une migration ou un déploiement, des fichiers que le serveur web ne peut ni lire ni exécuter.
• Une dépendance en panne : base de données inaccessible, service tiers appelé de manière synchrone qui ne répond plus, certificat ou clé d'API expirés.
• Un déploiement incomplet : fichiers manquants, version de PHP changée par l'hébergeur, variable d'environnement absente en production.

Deux traits aident au diagnostic. Une 500 sur tout le site, fichiers statiques compris, pointe vers la configuration du serveur ou le .htaccess. Une 500 sur certaines URL seulement (une catégorie, une fonction de recherche, le panier) pointe vers le code qui traite ces pages ou vers les données qu'elles chargent.

Ce que Google fait d'une erreur 500

La documentation Google Search Central sur les codes de statut HTTP range la 500 avec les autres erreurs serveur, et décrit un traitement en deux temps.

D'abord, le ralentissement du crawl. Les erreurs 5xx, ainsi que la 429, incitent les robots de Google à ralentir temporairement l'exploration du site. La baisse est proportionnelle au nombre d'URL qui renvoient une erreur serveur : quelques pages en 500 ont un effet limité, un site entier en 500 fait chuter la fréquence de passage de Googlebot. Google a précisé, dans un billet du 24 novembre 2023 annonçant la fin du limiteur de vitesse d'exploration de la Search Console, que ce ralentissement est « presque immédiat » quand le serveur renvoie durablement des codes 500 sur une plage d'URL. C'est d'ailleurs, depuis le 8 janvier 2024, le seul moyen rapide de faire baisser la pression de Googlebot : sa documentation recommande de renvoyer 500, 503 ou 429 en cas d'urgence, pour quelques heures ou un à deux jours au plus.

Ensuite, le retrait de l'index. Les URL déjà indexées sont conservées dans un premier temps, mais celles qui renvoient continuellement une erreur serveur finissent par être supprimées de l'index. Google ne publie pas de délai précis ; sa documentation sur la réduction de la vitesse d'exploration indique qu'une URL qui répond en erreur « pendant plusieurs jours » peut être retirée. Le contenu reçu avec un code 500 n'est jamais pris en compte : une page d'erreur bien rédigée ne change rien.

Quand le serveur répond de nouveau en 200, Google augmente progressivement la vitesse d'exploration. Le retour à la normale n'est donc pas instantané : les pages sorties de l'index y reviennent après réexploration, et la fréquence de crawl remonte par paliers.

Le cas particulier du robots.txt

Une 500 sur le fichier robots.txt a un effet à part, décrit dans la documentation de Google sur ce fichier. Pendant les douze premières heures, Google cesse d'explorer le site tout en réessayant de récupérer le fichier. Ensuite, et pendant trente jours, il utilise la dernière version valide qu'il avait en cache, tout en continuant ses tentatives. Passé trente jours, si le site est accessible par ailleurs, Google se comporte comme s'il n'y avait pas de robots.txt ; si le site présente des problèmes de disponibilité générale, il cesse de l'explorer. Un robots.txt qui tombe en 500 à cause d'une règle de réécriture mal écrite bloque donc tout le crawl pendant une demi-journée, alors que les pages elles-mêmes répondent peut-être correctement.

Comment diagnostiquer une erreur 500

La 500 étant muette par construction, le diagnostic passe par ce que le serveur a écrit ailleurs.

• Le journal d'erreurs du serveur (error.log d'Apache ou de nginx, journal PHP-FPM) contient presque toujours la cause exacte : nom du fichier, ligne, message. C'est le premier endroit à ouvrir, avant toute manipulation.
• Le journal d'accès dit quelles URL, quels user-agents et quelles heures sont concernés. L'analyse de logs permet de savoir si Googlebot a rencontré les 500, sur combien d'URL et depuis quand.
• La reproduction : ouvrir l'URL dans un navigateur, puis avec curl -I, pour vérifier le code réel. Une page qui affiche « erreur » en code 200 n'est pas une 500 pour Google, c'est un soft 404 potentiel.
• La Search Console signale les erreurs serveur rencontrées par Googlebot dans le rapport « Pages » et dans les statistiques d'exploration. Les données arrivent avec un délai, ce qui en fait un outil de suivi plus que d'alerte.
• Le mode débogage du CMS (par exemple WP_DEBUG sur WordPress) affiche le message d'erreur à la place de la page blanche, à n'activer que le temps du diagnostic.
• Une supervision externe qui interroge quelques URL clés toutes les minutes prévient dès la première 500, bien avant que le trafic ou la Search Console ne la révèlent.

Comment corriger une erreur 500

La correction dépend de la cause, mais l'ordre des opérations est à peu près toujours le même.

• Revenir au dernier état stable : si la 500 suit un déploiement ou une mise à jour, la première action est de la retirer. Un site en erreur coûte plus que le retard d'une mise à jour.
• Isoler l'extension ou le thème : sur un CMS, désactiver les extensions une par une (ou renommer leur dossier via FTP si l'administration est elle-même en 500) jusqu'à ce que le site réponde.
• Restaurer le .htaccess à partir d'une sauvegarde, ou le vider temporairement pour vérifier qu'il est en cause.
• Relever les limites de mémoire et de temps d'exécution si le journal les cite, en gardant à l'esprit que c'est un pansement : le code qui consomme autant a un problème.
• Rétablir les droits des fichiers et dossiers selon les recommandations de l'hébergeur.
• Vérifier les dépendances : base de données joignable, services tiers appelés avec un délai d'expiration court et un comportement de repli, secrets à jour.
• Contrôler après correction avec curl sur les URL touchées, robots.txt compris, puis demander une réexploration des pages importantes via l'inspection d'URL de la Search Console.

Les erreurs à éviter côté SEO

• Servir la page d'erreur en code 200. Certains thèmes et certaines configurations interceptent l'erreur et affichent un message rassurant avec un code de succès. Google prend alors ce message pour le contenu de la page, le signale en soft 404 ou l'indexe. Une erreur doit s'annoncer comme une erreur.
• Rediriger les erreurs vers l'accueil. Une redirection systématique masque le problème, fait perdre l'URL d'origine et brouille les signaux. Le code 500 est préférable : il dit à Google de conserver la page et de repasser.
• Utiliser la 500 pour une maintenance. Pour une interruption prévue, le code adapté est la 503 avec un en-tête Retry-After. La 500 est une panne, pas un état annoncé.
• Laisser durer. Le ralentissement du crawl commence tout de suite, le retrait de l'index suit après quelques jours, et la remontée est progressive. Chaque jour de 500 se paie en semaines de crawl réduit.
• Oublier les URL secondaires. Un site peut répondre 200 sur ses pages et 500 sur son robots.txt, son sitemap, ses images ou ses fichiers CSS et JavaScript. Le rendu des pages par Google en dépend ; le contrôle après incident doit les inclure.
• Confondre absence de trafic et absence d'erreur. Une 500 intermittente sous charge, la nuit ou lors du passage de Googlebot, n'apparaît pas forcément lors d'un test manuel. Seuls les journaux et une supervision continue la révèlent.

FAQ

Une erreur 500 fait-elle perdre des positions ?

Pas immédiatement. Google conserve d'abord les pages déjà indexées et se contente de ralentir son exploration. Si la 500 persiste plusieurs jours sur les mêmes URL, elles sont retirées de l'index, donc des résultats. Une fois le site rétabli, elles reviennent après réexploration, mais la fréquence de crawl met du temps à remonter.

Quelle différence entre une erreur 500 et une erreur 503 ?

La 500 est une panne inattendue du site lui-même : code, configuration ou ressources. La 503 annonce une indisponibilité temporaire, souvent volontaire, et peut s'accompagner d'un en-tête Retry-After qui dit aux robots quand revenir. Pour une maintenance, c'est la 503 qu'il faut utiliser. Pour Google, les deux sont des erreurs serveur temporaires et déclenchent le même ralentissement du crawl.

Comment savoir si Googlebot a vu mes erreurs 500 ?

Par les journaux d'accès du serveur, filtrés sur le user-agent Googlebot et le code 500, qui donnent les URL et les heures exactes. La Search Console signale aussi les erreurs serveur dans le rapport « Pages » et dans les statistiques d'exploration, avec quelques jours de délai.

Peut-on renvoyer volontairement des 500 pour calmer Googlebot ?

Oui, c'est ce que Google recommande en cas d'urgence : renvoyer 500, 503 ou 429 aux robots d'exploration fait baisser la vitesse de crawl presque immédiatement. Mais pas plus d'un à deux jours : au-delà, les URL concernées risquent d'être retirées de l'index. La 503 reste le code le plus propre pour cet usage.

Une erreur 500 sur le robots.txt est-elle grave ?

Oui, plus qu'une 500 sur une page. Pendant les douze premières heures, Google arrête d'explorer le site. Ensuite il utilise pendant trente jours la dernière version du fichier qu'il avait en cache. C'est une des premières URL à vérifier après un incident ou une modification de la configuration serveur.

En résumé

• Erreur 500 : code HTTP d'erreur serveur générique, défini par la RFC 9110 ; le serveur a rencontré une condition inattendue, sans préciser laquelle.
• Origine : le site lui-même (code, extension, .htaccess, mémoire, droits, base de données), à la différence des 502, 503, 504 et 522.
• Effet sur Google : ralentissement quasi immédiat du crawl, proportionnel au nombre d'URL en erreur ; contenu ignoré ; retrait de l'index si l'erreur persiste plusieurs jours ; remontée progressive après retour en 200.
• Robots.txt : une 500 sur ce fichier arrête le crawl pendant douze heures, puis Google utilise la version en cache pendant trente jours.
• Diagnostic : journal d'erreurs du serveur, analyse de logs, test curl, Search Console, supervision externe.
• À éviter : page d'erreur en 200, redirection vers l'accueil, 500 utilisée pour une maintenance (préférer la 503), erreur laissée en place plusieurs jours.

Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !