500 — erreur interne du serveur

TL;DR — Une 500 — erreur interne du serveur — signifie que le serveur a rencontré un problème en essayant de construire la page ; ce n’est pas un problème de votre URL, de votre navigateur ou du robot de recherche. Une 500 isolée est généralement réessayée par Google et aucune règle ne dit qu’elle vous coûte quelque chose. Le danger documenté apparaît lorsque beaucoup de pages renvoient des 500 pendant un certain temps : Google ralentit alors l’exploration et peut finir par retirer les pages de la recherche. Commencez la correction par les journaux d’erreur du serveur, pas par le navigateur.

Qu’est-ce qu’une erreur 500 ?

Une 500 — erreur interne du serveur est la version Web de « quelque chose s’est mal passé et je ne peux pas vous dire exactement quoi ». Le serveur a reçu votre requête, a commencé à construire la page, a rencontré un problème puis a abandonné — en renvoyant une erreur générique au lieu de la page. Dans le guide des codes de statut HTTP d’Ahrefs, je l’ai formulé ainsi : “500 Internal Server Error – The server encounters some kind of issue and doesn’t have a better or more specific error code.” (traduction) : « Erreur interne du serveur 500 — le serveur rencontre un problème quelconque et ne dispose pas d’un code d’erreur meilleur ou plus précis. » Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

C’est le point essentiel : une 500 est un fourre-tout. Elle vous indique que quelque chose a cédé côté serveur, mais pas quoi. Trouver ce « quoi » est tout le travail.

C’est un problème de serveur, pas le vôtre (généralement)

Les erreurs 500 appartiennent à la famille 5xx — les erreurs serveur. C’est différent des erreurs 4xx, comme la 404 (page introuvable), qui concernent la requête (URL incorrecte ou manquante). Avec une 500, l’URL peut être parfaitement correcte ; le serveur n’a simplement pas pu terminer le travail. Vous rencontrerez aussi les cousines de 500 — 502, 503 et 504 — qui sont elles aussi côté serveur, mais renvoient à des situations plus précises (mauvaise passerelle, serveur temporairement indisponible ou délai d’attente dépassé).

Une erreur 500 nuit-elle au SEO ?

Une 500 unique et occasionnelle sur une page ? Google reviendra généralement essayer à nouveau et, si la page se charge correctement lors de cette nouvelle tentative, l’incident s’arrête souvent là. Google ne publie pas de promesse générale selon laquelle une panne isolée est sans conséquence ; il ne documente simplement aucun mécanisme qui pénaliserait un incident ponctuel.

Le risque réellement documenté concerne les 500 persistantes sur beaucoup de pages. Dans ce cas :

1. Google réessaie, constate que les erreurs continuent et ralentit la vitesse d’exploration de votre site.
2. Si les erreurs ne disparaissent toujours pas, Google finit par retirer ces pages de l’index — elles cessent alors d’apparaître dans la recherche. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

La bonne nouvelle : la documentation Google décrit un rétablissement progressif une fois le problème sous-jacent corrigé et les explorations redevenues fructueuses — mais elle ne garantit ni calendrier ni résultat. “Recovery is usually quick” (traduction) : « Le rétablissement est généralement rapide ». Cela décrit le cas courant, pas une promesse.

Par où commencer pour corriger le problème

• Consultez d’abord les journaux d’erreur du serveur. C’est là que se trouve la vraie raison — pas dans le navigateur. Un navigateur vous montre seulement « 500 » ; les journaux vous disent pourquoi.
• Regardez ce qui a changé récemment. Nouveau plugin, thème ou module ? Déploiement récent ? Modification d’un fichier de configuration comme .htaccess ? Les changements récents sont les suspects habituels.
• Consultez Google Search Console. Le rapport d’indexation des pages comporte une section « Erreur serveur (5xx) » qui indique les URL sur lesquelles Google voit des 500.
• Demandez à votre hébergeur. En hébergement mutualisé notamment, de nombreuses 500 viennent des limites de mémoire ou de ressources ; votre hébergeur peut souvent le confirmer de son côté.

Vous voulez la version détaillée — l’escalade exacte de Google, la règle empirique d’environ 1 %, la différence 500/503 et un ordre complet de diagnostic ? Passez à l’onglet Advanced.

TL;DR — La RFC 9110 définit 500 comme une condition inattendue qui a empêché le serveur de satisfaire la requête — c’est toute la limite du code de statut lui-même ; la cause, la durée et l’opportunité d’une nouvelle tentative relèvent du diagnostic, pas de la sémantique. La réaction documentée de Google est progressive : les 500 isolées sont généralement réessayées ; les 500 persistantes à l’échelle du site ralentissent l’exploration et, si elles ne sont pas résolues, entraînent un retrait de l’index. Mueller a proposé une règle empirique personnelle — des taux d’erreur supérieurs à environ 1 % indiquent probablement un problème — mais ce n’est pas un seuil Google documenté, et la séquence nouvelle tentative → exploration ralentie → retrait décrit des comportements documentés, pas un minuteur fixe. Diagnostiquez d’abord depuis les journaux serveur, puis avec le rapport « Erreur serveur (5xx) » de GSC et les statistiques d’exploration « par réponse ». La distinction 500/503 compte : 503 est le code reconnu pour dire « revenez plus tard » avec une fenêtre de grâce d’environ 2 jours ; une 500 incontrôlée ne bénéficie pas de cette grâce.

Ce qu’est réellement une 500

Commencez par la spécification, et non par le raccourci des praticiens. La RFC 9110 — la norme de sémantique HTTP — définit une 500 Internal Server Error comme une condition inattendue qui a empêché le serveur de satisfaire la requête. C’est toute la limite de ce que le code de statut vous dit. Il n’identifie ni la cause racine, ni le composant défaillant, ni la durée probable du problème, ni la réussite éventuelle de la même requête après une nouvelle tentative, ni la probabilité du rétablissement. Tout ce qui dépasse « le serveur a rencontré quelque chose qu’il ne pouvait pas gérer » relève du diagnostic, et non de la sémantique du code — le diagnostic se trouve dans vos journaux d’erreur serveur, pas dans la spécification ou le navigateur.

Dans le guide des codes de statut HTTP d’Ahrefs, je garde volontairement la définition destinée aux praticiens très directe : le serveur “encounters some kind of issue and doesn’t have a better or more specific error code.” (traduction) : « rencontre un problème quelconque et ne dispose pas d’un code d’erreur meilleur ou plus précis ». C’est une paraphrase en langage clair de la même limite RFC — toujours un fourre-tout, toujours un symptôme plutôt qu’un diagnostic.

Le statut appartient à la famille 5xx aux côtés de 502 (mauvaise passerelle), 503 (service indisponible) et 504 (délai de passerelle dépassé) — tous côté serveur, mais 500 est celui qui signifie « aucun meilleur code ne s’applique ». Puisque le statut lui-même ne contient aucun détail de diagnostic, recharger la page dans un navigateur ne vous apprend pas pourquoi l’erreur est survenue ; vos journaux serveur sont la source de vérité.

Comment Googlebot traite une 500

Le robot de Google est conçu pour rester prudent : il adapte son rythme à la santé de votre serveur, et les réponses 5xx font partie des signaux qu’il lit comme « ralentissez ». La documentation actuelle de Google confirme la forme de cette réaction : les réponses 5xx et 429 provoquent une réduction temporaire du rythme d’exploration (proportionnelle au nombre d’URL touchées), et les URL qui continuent à échouer peuvent finir par être retirées de l’index, tandis que le contenu déjà indexé est conservé entre-temps dans l’attente d’une actualisation réussie. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers John Mueller a décrit cette même progression avec ses propres mots, lors d’une session Google SEO Office Hours relayée par Search Engine Journal :

“We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (traduction) : « Aucun seuil ferme n’est fixé à ce sujet. En pratique, Google réessaie les erreurs 500 ; lorsqu’elles persistent, il ralentit l’exploration, puis retire les URL de l’index si elles continuent. »

Lisez cela comme une description de comportements documentés — nouvelle tentative, exploration plus lente, retrait possible — et non comme un minuteur fixe en trois étapes avec transitions ou délais garantis ; Google ne publie pas les seuils exacts auxquels une étape devient la suivante. Une 500 isolée sur une URL est généralement réessayée, et la récupération lors de l’exploration suivante met habituellement fin à l’incident — mais c’est une description du cas courant, pas la garantie qu’une panne ponctuelle n’a aucun coût. Le risque réellement documenté réside dans les erreurs qui ne disparaissent pas.

Pourquoi les 500 à l’échelle du site sont pires que les erreurs isolées

Une dynamique plus dangereuse apparaît lorsqu’une grande partie du site renvoie 500 en même temps. La documentation actuelle de Google confirme que la réduction du rythme dépend du nombre d’URL touchées — plus la partie défaillante du site est grande, plus l’exploration ralentit. Mueller a formulé le raisonnement de manière plus précise, en présentant l’hypothèse que l’exploration de Google pourrait elle-même participer à la surcharge :

“But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (traduction) : « Lorsqu’une grande partie d’un site renvoie constamment des erreurs 500, Google peut soupçonner que son exploration contribue au problème ; il ralentit alors l’exploration de tout le site et finit par retirer les pages qui semblent réellement disparues. »

Traitez cette formulation causale précise — « nous supposons que nous en sommes la cause » — comme la caractérisation personnelle de Mueller, et non comme une formulation reprise mot pour mot de la documentation officielle actuelle de Google : le mécanisme sous-jacent est documenté (davantage d’URL en échec, davantage de réduction du rythme), même si le raisonnement causal exact est plus facile à vérifier dans sa déclaration que dans les documents. Dans tous les cas, la boucle pratique mérite d’être retenue : une exploration agressive en situation d’épuisement des ressources peut déclencher davantage de 500 → Google ralentit l’exploration de tout le site → et, si les erreurs persistent malgré tout, les pages sortent de l’index. Cela signifie aussi qu’un problème 500 n’est pas toujours un bug de code : le serveur peut parfois plier sous une charge concurrente qui ne se manifeste que lors de pics de robots ou de trafic.

À partir de quel niveau est-ce « trop » ?

Il n’existe pas de limite ferme — la documentation de dépannage de Google ne publie aucun seuil de taux d’erreur. Mueller a proposé une règle empirique personnelle dans SEO Office Hours (à nouveau relayée par Search Engine Journal, et non publiée officiellement par Google) :

“My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (traduction) : « J’ai le sentiment que si vous voyez quelque chose de supérieur à 1 %, cela ressemble à un problème quelconque. »

Traitez ~1 % comme un test olfactif officieux attribué à Mueller, et non comme une limite Google documentée ou appliquée. En dessous, tout va probablement bien ; au-dessus, cela mérite une enquête — mais ne considérez pas le dépassement de 1 % comme un déclencheur automatique et ne considérez pas le fait de rester en dessous comme une garantie. Le seul nombre auquel Google s’engage publiquement est l’absence de nombre : “we don’t have any strong thresholds.” (traduction) : « nous n’avons pas de seuils fermes ».

500 contre 503 : la distinction qui compte

C’est là que beaucoup se trompent. Une 503 Service Unavailable est la manière reconnue de dire à un robot « je suis temporairement indisponible, revenez plus tard ». Google la traite comme intentionnelle et lui accorde une fenêtre de grâce. La documentation de dépannage de Google est explicite :

“Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (traduction) : « Renvoyez temporairement des codes de réponse HTTP 503 ou 429 aux requêtes de Googlebot lorsque votre serveur est surchargé. Googlebot réessaiera ces URL pendant environ 2 jours. Notez que renvoyer des codes d’“indisponibilité” pendant plus de quelques jours amènera Google à ralentir ou arrêter définitivement l’exploration des URL de votre site. »

Le contraste est le suivant : 503 est intentionnelle et bénéficie d’une grâce de nouvelle tentative d’environ 2 jours ; une 500 incontrôlée est involontaire et n’en bénéficie pas — elle est simplement réessayée jusqu’à ce que Google abandonne. Conséquence pratique : pour une maintenance planifiée ou une défense délibérée contre une surcharge, renvoyez 503 (idéalement avec un en-tête Retry-After), et non 500 ni une page d’erreur 200. Ne maquillez jamais une panne réelle en 200.

Comment diagnostiquer une 500

Procédez par couches — application/code, plateforme/CMS, infrastructure et ressources, puis configuration — en commençant par ce qui est le moins coûteux et le plus susceptible d’apporter une réponse. Les étapes marquées (spécifique à WordPress) sont des pratiques WordPress courantes, et non des correctifs universels ; adaptez-les à votre pile réelle.

1. Journaux d’erreur serveur. error.log / access.log (ou le lecteur de journaux de votre plateforme). Faites correspondre les horodatages aux requêtes en échec. C’est ici que se trouve la trace de pile, l’erreur fatale PHP ou l’échec de connexion DB. Tout le reste est une hypothèse tant que vous ne les avez pas lus.
2. GSC — rapport « Erreur serveur (5xx) ». Le rapport d’indexation des pages de Google Search Console signale les URL sur lesquelles Google voit lui-même des 500. Ouvrez ensuite Statistiques d’exploration et lisez la ventilation « par réponse » dans le temps — c’est ainsi que vous distinguez un incident ponctuel d’un vrai problème persistant de disponibilité.
3. Bing Webmaster Tools. Ses alertes d’erreur d’exploration regroupent les erreurs serveur (5xx) et vous orientent vers les URL concernées et l’outil d’informations d’exploration.
4. Reproduisez le problème comme un robot, pas seulement dans un navigateur. Une page peut renvoyer 500 à Googlebot tout en se chargeant pour vous — sous l’effet d’une charge déclenchée par l’exploration, d’une mauvaise configuration de détection de robots ou de pare-feu, ou de limites de capacité qui n’apparaissent que sous trafic robot concurrent. Utilisez l’inspection d’URL (GSC), Fetch as Bingbot ou curl avec un user-agent de robot pour trouver les échecs propres aux robots. « Cela fonctionne dans mon navigateur » ne suffit pas.
5. Conflits de plugins, thèmes ou modules (schéma spécifique à WordPress ; adaptez ailleurs). Faites d’abord une sauvegarde — prévoyez toujours un retour arrière avant de désactiver quoi que ce soit. Désactivez ensuite les extensions et réactivez-les une par une pour isoler la coupable, en vérifiant les permissions et la propriété des fichiers que vous touchez. Les guides de dépannage WordPress des hébergeurs rapportent souvent ce schéma, mais c’est une observation propre à une pile et non une preuve qu’il s’agit partout de la cause principale — sur un autre CMS ou une application personnalisée, l’équivalent peut être un conflit de module tiers, de package ou de middleware.
6. Épuisement des ressources. Limites de mémoire PHP, limites de connexions à la base de données, capacité d’hébergement mutualisé, pics de trafic ou d’exploration. Votre hébergeur peut souvent le confirmer de son côté.
7. Configuration et changements récents. .htaccess cassé, mauvaise modification de configuration serveur, déploiement récent ou identifiants de base de données erronés. Les changements récents sont le meilleur endroit où chercher en premier.

Comment la corriger (adaptez le correctif à la cause)

Faites correspondre le correctif à la couche désignée par le diagnostic. Voici des schémas courants rapportés dans les écrits de praticiens, et non une liste classée ou universelle de ce qui est le plus probable dans votre pile précise :

• La configuration ou le déploiement a causé l’erreur → annulez le changement ; corrigez .htaccess, la configuration ou les identifiants.
• Épuisement des ressources → augmentez les limites (mémoire PHP, connexions DB) ou passez à une offre d’hébergement supérieure ; si l’exploration déclenche la surcharge, c’est aussi une question de rythme d’exploration.
• Conflit de plugin ou de module → retirez ou remplacez l’extension fautive.
• Bug de code → corrigez le code et ajoutez la gestion d’erreur manquante.
• Vous ne parvenez pas à l’identifier → transmettez à votre hébergeur les horodatages exacts et les lignes de journal. Ne devinez pas en production.

Éviter la réapparition

Superviser et alerter sur les taux de 5xx, tester les changements en préproduction avant leur mise en production, tester la charge avant les pics de trafic connus et — si l’exploration de Googlebot est elle-même le déclencheur — gérer la charge d’exploration (et renvoyer délibérément 503/429 pendant une vraie surcharge, au lieu de laisser le serveur émettre des 500 incontrôlées).

FAQ

Une erreur 500 nuit-elle au SEO ? Le risque documenté concerne surtout la persistance à grande échelle. Les 500 isolées sont généralement réessayées, sans pénalité documentée pour un incident ponctuel ; des 500 persistantes à l’échelle du site ralentissent l’exploration et peuvent entraîner une désindexation.

Au bout de combien de temps Google désindexe-t-il une page qui renvoie 500 ? Il n’existe pas de calendrier fixe. Google réessaie d’abord et ralentit l’exploration ; le retrait de l’index ne survient que si les erreurs continuent. Corrigez le problème et les pages reviennent généralement une fois les explorations redevenues fructueuses.

Pourquoi mon site renvoie-t-il 500 à Googlebot mais se charge-t-il dans mon navigateur ? Les 500 propres aux robots indiquent généralement un problème de capacité ou de gestion des robots — charge déclenchée par l’exploration, règles de pare-feu ou de détection, ou limites qui ne se déclenchent que sous trafic robot concurrent. Fiez-vous aux journaux, et non à un contrôle manuel dans un navigateur.

Les 500 peuvent-elles ralentir l’exploration de tout mon site, et pas seulement des pages touchées ? Oui — la documentation de Google confirme que la réduction du rythme dépend du nombre d’URL en échec ; une grande partie du site qui renvoie 500 ralentit donc l’exploration partout. Mueller a également présenté le raisonnement comme une suspicion de Google que sa propre exploration participe à la surcharge — sa caractérisation personnelle, et non une formulation reprise mot pour mot des documents officiels actuels.

Qu’est-ce qui provoque une 500 dans WordPress ? Sur WordPress précisément, les hébergeurs et la communauté WordPress citent le plus souvent les conflits de plugins ou de thèmes, un .htaccess corrompu ou l’atteinte de la limite de mémoire PHP — c’est ce qui est rapporté pour cette plateforme, et non l’affirmation que ce sont les causes principales universelles de toute 500. L’ordre de diagnostic ci-dessus (journaux d’abord, puis changements récents) reste le même quel que soit le CMS.

Est-il sûr de réessayer automatiquement une requête après une 500 ? Seulement après avoir vérifié la méthode et l’idempotence de la requête — le statut 500 lui-même n’autorise aucune politique de nouvelle tentative. GET, HEAD, PUT et DELETE sont généralement sûres à réessayer parce qu’elles sont idempotentes (les répéter ne devrait pas produire d’effets secondaires supplémentaires) ; un POST simple ne l’est généralement pas, sauf si votre API garantit explicitement l’idempotence (par exemple avec une clé d’idempotence) — le réessayer aveuglément risque de créer une commande en double, un e-mail en double ou un paiement débité deux fois. Lorsque vous réessayez, utilisez un backoff exponentiel avec jitter, plafonnez le nombre de tentatives et définissez un budget de nouvelles tentatives afin qu’un serveur en difficulté ne subisse pas une tempête de retentatives en plus de ce qui échoue déjà.

Résumé par IA

Une synthèse de la version Advanced :

• 500 = la limite de condition inattendue de la RFC 9110. C’est toute la portée du statut lui-même — aucune cause racine, aucune durée, aucune indication de possibilité de nouvelle tentative. C’est un symptôme, pas un diagnostic ; cherchez la cause dans les journaux serveur, et non dans le navigateur. Le statut se distingue des erreurs 4xx (client ou requête) et de ses cousines 5xx 502/503/504.
• La réaction documentée de Google est progressive : réduction temporaire du rythme d’exploration (proportionnelle au nombre d’URL touchées), puis retrait possible de l’index pour les URL qui continuent à échouer, avec rétablissement lorsque les explorations réussissent à nouveau. Mueller décrit cela comme nouvelle tentative → exploration ralentie → retrait de l’index — description de comportements documentés, et non minuteur fixe. Une 500 isolée est généralement réessayée ; rien ne promet qu’elle est gratuite, mais le risque documenté réel est la persistance à grande échelle.
• Les 500 à l’échelle du site sont pires : la réduction du rythme dépend du nombre d’URL en échec. Mueller présente le raisonnement comme une suspicion que l’exploration de Google participe à la surcharge — sa caractérisation personnelle, et non la formulation mot pour mot des documents officiels — et, dans tous les cas, la charge d’exploration peut déclencher davantage de 500.
• Règle empirique, pas seuil : Mueller a dit que des taux d’erreur supérieurs à environ 1 % sont « probablement un problème », mais c’est sa formulation personnelle issue de SEO Office Hours, pas une limite Google documentée — Google indique ne pas avoir de seuils fermes.
• 500 contre 503 : 503 (ou 429) est le signal reconnu « revenez plus tard », avec une grâce de nouvelle tentative d’environ 2 jours selon Google ; une 500 incontrôlée n’a pas cette grâce. Utilisez 503 (avec Retry-After) pour une interruption planifiée.
• Ordre du diagnostic (par couche) : journaux serveur → rapport GSC « Erreur serveur (5xx) » et statistiques d’exploration « par réponse » → Bing Webmaster Tools → reproduction comme un robot (inspection d’URL / curl) → conflits de plugins ou modules (schéma WordPress à adapter, sauvegarde préalable) → épuisement des ressources → changements de configuration ou de déploiement.
• La sécurité des nouvelles tentatives dépend de la requête, et non du statut. Les méthodes idempotentes (GET/HEAD/PUT/DELETE) sont généralement sûres à réessayer ; un POST simple ne l’est généralement pas sans clé d’idempotence. Utilisez un backoff, un plafond de tentatives et un budget de nouvelles tentatives.
• Le rétablissement est généralement rapide après correction — les pages retirées tendent à revenir lorsque les explorations réussissent, même si Google ne garantit ni calendrier ni résultat.

Documentation officielle

Documentation issue des sources primaires des moteurs de recherche et de la spécification HTTP.

Google

• Dépanner les erreurs d’exploration de Google Search — traitement des erreurs serveur par Google et usage reconnu de 503/429 pour une surcharge temporaire.
• Guide détaillé du fonctionnement de Google Search — planification de l’exploration et fait que les réponses 5xx sont lues comme « ralentissez ».
• Rapport Statistiques d’exploration — ventilation « par réponse » (dont Erreur serveur (5xx)) pour distinguer un incident ponctuel d’un problème persistant.
• Réduire le rythme d’exploration de Googlebot — manière correcte et délibérée de ralentir l’exploration, plutôt que de laisser le serveur émettre des 500 incontrôlées.

Bing / Microsoft

• Bing Webmaster Tools — liste des alertes d’erreur d’exploration — regroupement des erreurs serveur (5xx) par Bing et emplacement d’inspection des URL concernées.

Spécification HTTP / référence

• MDN — 500 Internal Server Error — définition du code de statut lui-même.
• RFC 9110 §15.6.1 — 500 Internal Server Error — sémantique HTTP faisant autorité.

Citations de la source

Déclarations attribuées. Lorsqu’une page source est rendue en JavaScript ou que la formulation est relayée par une source secondaire, une réserve <small> le signale.

Google — la trajectoire d’escalade

• “We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (traduction) : « Aucun seuil ferme n’est fixé à ce sujet. En pratique, Google réessaie les erreurs 500 ; lorsqu’elles persistent, il ralentit l’exploration, puis retire les URL de l’index si elles continuent. » — John Mueller, Google. Lire le compte rendu Relaté par la transcription d’une session Google SEO Office Hours publiée par Search Engine Journal ; confirmez la formulation exacte dans la vidéo source avant de la considérer comme définitive.
• Selon John Mueller : “But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (traduction) : « Lorsqu’une grande partie d’un site renvoie constamment des erreurs 500, Google peut soupçonner que son exploration contribue au problème ; il ralentit alors l’exploration de tout le site et finit par retirer les pages qui semblent réellement disparues. » — John Mueller, Google. Consulter le compte rendu Search Engine Journal relaie cette déclaration ; vérifiez sa formulation mot pour mot dans la vidéo d’origine.
• “My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (traduction) : « À mon avis, dépasser 1 % donne à penser qu’un élément est probablement défaillant. » — John Mueller, Google, au sujet d’une règle empirique approximative du taux d’erreur. Lire le compte rendu Relaté par Search Engine Journal ; vérifiez la formulation mot pour mot dans la vidéo d’origine.

Google — le signal reconnu « ralentissez » (documentation vérifiée)

• D’après la documentation Google : “Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (traduction) : « En cas de surcharge, utilisez provisoirement les codes de réponse HTTP 503 ou 429 pour les requêtes de Googlebot. Google réessaiera ces URL pendant environ 2 jours ; au-delà de quelques jours avec un code d’“indisponibilité”, il ralentira ou cessera définitivement d’explorer les URL de votre site. » — Documentation Google Search Central. Aller à la citation

Patrick Stox — la définition (Ahrefs, vérifiée)

• “500 Internal Server Error – The server encounters some kind of issue and doesn’t have a better or more specific error code.” (traduction) : « Erreur interne du serveur 500 — le serveur rencontre un problème quelconque et ne dispose pas d’un code d’erreur meilleur ou plus précis. » — mon guide des codes de statut HTTP sur le blog Ahrefs. Aller à la citation

Checklist de triage des erreurs 500

Suivez-la de haut en bas dès que des 500 apparaissent :

• Consultez les journaux d’erreur serveur et trouvez l’erreur réelle (trace de pile / fatal PHP / panne DB) — pas seulement le « 500 » du navigateur.
• Vérifiez ce qui a changé récemment — nouveau plugin, thème ou module, déploiement récent, modification de .htaccess ou de la configuration serveur, identifiants DB modifiés.
• Ouvrez GSC → Indexation des pages → Erreur serveur (5xx) pour voir les URL sur lesquelles Google voit des 500.
• Lisez GSC Statistiques d’exploration « par réponse » dans le temps afin de distinguer un incident ponctuel d’un problème persistant.
• Consultez les alertes d’erreur d’exploration de Bing Webmaster Tools pour les mêmes URL.
• Reproduisez le problème comme un robot (inspection d’URL / Fetch as Bingbot / curl avec un user-agent de robot) — pas seulement dans un navigateur.
• Écartez l’épuisement des ressources (mémoire PHP, connexions DB, capacité d’hébergement) avec votre hébergeur.
• Isolez tout conflit de plugin ou de module en désactivant puis réactivant les éléments un par un.
• Vérifiez que vous n’émettez pas de 500 incontrôlées pendant une interruption planifiée — utilisez plutôt 503 (avec Retry-After).
• Confirmez que le taux d’erreur est repassé sous le test olfactif officieux d’environ 1 % (règle empirique de Mueller, et non seuil Google documenté) après le correctif, et que GSC montre à nouveau des explorations réussies.

Runbook : « Le site renvoie des 500 — que dois-je vérifier en premier ? »

Un ordre d’opérations sans panique. Faites-les dans l’ordre et arrêtez-vous lorsque vous avez trouvé et corrigé la cause.

0. Délimitez le problème (2 minutes). S’agit-il d’une URL, d’un modèle ou d’une section ou de tout le site ? Une URL est un cas peu urgent (Google réessaie). Un site entier est l’urgence — c’est le schéma qui fait ralentir l’exploration de Google.

1. Lisez les journaux d’erreur du serveur. Commencez par error.log. Faites correspondre les horodatages aux échecs. Vous cherchez la vraie cause : erreur fatale PHP, échec de connexion DB, segmentation fault ou arrêt pour manque de mémoire. Tout ce qui suit est une hypothèse tant que vous ne l’avez pas fait.

2. Faites le lien avec « ce qui a changé ». Triez les changements récents : dernier déploiement, plugin/thème/module ajouté ou mis à jour, modification de .htaccess, identifiants DB renouvelés, changement de configuration. La plupart des 500 remontent à un changement des dernières heures ou des derniers jours. Si possible, annulez d’abord le changement et diagnostiquez ensuite — rétablir le service vous donne du temps.

3. Confirmez la vue des moteurs de recherche. GSC → Indexation des pages → Erreur serveur (5xx) pour les URL touchées, puis Statistiques d’exploration → par réponse pour voir s’il s’agit d’un incident ponctuel ou persistant. Vérifiez aussi les alertes d’erreur d’exploration de Bing Webmaster Tools. Cela indique l’urgence SEO.

4. Reproduisez le problème comme le robot le voit. Si les humains obtiennent la page mais que Googlebot reçoit 500, testez comme un robot : inspection d’URL, Fetch as Bingbot ou curl -A "Googlebot" <url>. Les 500 propres aux robots indiquent une capacité insuffisante, des règles de pare-feu ou de gestion des robots, ou une charge déclenchée par l’exploration — correctif différent d’un bug de code.

5. Isolez les suspects habituels.

• Plugins/modules : désactivez tout, puis réactivez un élément à la fois jusqu’à reproduire l’erreur.
• Ressources : vérifiez avec votre hébergeur la limite de mémoire PHP, le plafond de connexions DB et la capacité d’hébergement — surtout si les 500 se concentrent pendant des pics de trafic ou d’exploration.
• Configuration : rétablissez .htaccess ou la configuration serveur dans une version connue comme saine.

6. Si l’exploration déclenche le problème, ne l’absorbez pas simplement. Lorsque le volume d’exploration de Googlebot vous surcharge, le levier temporaire correct est de renvoyer 503/429 (avec Retry-After) — pas de laisser le serveur émettre des 500 incontrôlées. Google respecte 503 comme « revenez plus tard » pendant environ 2 jours ; une 500 ne bénéficie pas de cette grâce.

7. Vérifiez le rétablissement. Taux d’erreur revenu sous le test olfactif officieux d’environ 1 %, journaux propres et GSC Statistiques d’exploration montrant à nouveau des récupérations réussies. Les pages retirées reviennent généralement lorsque les explorations réussissent — aucun calendrier garanti, mais le rétablissement est généralement rapide.

Schéma d’escalade à garder en tête : 500 occasionnelle → généralement réessayée, risque documenté faible → 500 persistante → ralentissement de l’exploration → persistance → retrait des URL de l’index. Google ne publie pas le calendrier exact de ces transitions ; votre travail consiste à briser la chaîne avant qu’elle n’aille aussi loin.

Quel code serveur dois-je renvoyer ?

Utilisez cet arbre lorsque vous décidez quoi servir ou que vous interprétez ce que vous observez.

L’échec est-il intentionnel (maintenance ou défense délibérée contre une surcharge) ?

• Oui → Renvoyez 503 Service Unavailable avec un en-tête Retry-After. Google le traite comme temporaire et réessaie pendant environ 2 jours. Ne servez pas une page d’erreur 200 et ne laissez pas le problème retomber sur une 500.
• Non (il s’agit d’un échec réel et inattendu) → continuez.

Tout le monde reçoit-il l’erreur, ou seulement le robot ?

• Tout le monde → C’est un problème de code, de configuration ou de DB. Consultez les journaux d’erreur serveur et la liste « ce qui a changé ». Annulez les changements récents.
• Seulement Googlebot/Bingbot → Suspectez la capacité, les règles de détection de robots ou de pare-feu, ou une charge déclenchée par l’exploration. Reproduisez comme un robot ; vérifiez les ressources serveur et les règles de robots.

S’agit-il d’une URL ou d’une grande partie du site ?

• Une URL / occasionnel → Faible urgence. Google réessaie ; corrigez à votre rythme, mais confirmez que le problème est réellement isolé.
• Tout le site / persistant → Urgence. C’est le schéma qui fait ralentir l’exploration de tout le site et finit par provoquer une désindexation. Rétablissez le service d’abord (annulez le changement), cherchez la cause ensuite.

Le taux d’erreur est-il supérieur à ~1 % ?

• Oui → Cela mérite une enquête comme problème probablement réel — c’est la règle empirique personnelle et officieuse de Mueller, et non un seuil Google documenté.
• Non → C’est probablement acceptable — mais surveillez la tendance, pas seulement l’instantané.

Prompt : corréler une 500 avec les journaux et un déploiement

Diagnose this HTTP 500 incident from the sanitized evidence I provide. Build a
timeline across deployment events, request IDs, access logs, application errors,
resource signals, and affected URL patterns. Rank likely causes by evidence, separate
the fastest service-restoration action from the root-cause fix, and give exact
validation and rollback checks. Do not invent missing stack traces or thresholds.

[PASTE TIMELINE, HEADERS, LOGS, AND RECENT CHANGES]

Prompt : transformer une trace de pile en plan de test sûr

Explain this stack trace in plain language, identify the failing component and its
inputs, and propose the smallest reversible test that distinguishes code, dependency,
configuration, and resource-exhaustion causes. Include what evidence would falsify
each hypothesis and how to confirm the URL returns a stable non-5xx response afterward.
Redact secrets and do not suggest exposing debug output publicly.

[PASTE SANITIZED STACK TRACE]

Shell : échantillonner une liste d’URL pour les réponses 5xx

Exécutez ceci avec une URL absolue par ligne dans urls.txt.

while IFS= read -r url; do
  curl -sS -o /dev/null -w '%{http_code},%{time_total},%{url_effective}\n' "$url"
done < urls.txt

La sortie sépare les routes isolées d’un échec généralisé et enregistre la latence sans télécharger les corps de réponse.

PowerShell : exporter le même échantillon de statuts

Get-Content .\urls.txt | ForEach-Object {
  $r = Invoke-WebRequest -Uri $_ -SkipHttpErrorCheck
  [PSCustomObject]@{ Status = $r.StatusCode; Url = $_ }
} | Export-Csv .\status-sample.csv -NoTypeInformation

Shell : compter les statuts 5xx dans un journal d’accès

Adaptez la position du champ de statut à votre format de journal documenté avant de vous fier au résultat.

awk '$9 ~ /^5[0-9][0-9]$/ { count[$9]++ } END { for (code in count) print code, count[code] }' access.log

Outils pour trouver et diagnostiquer les 500

• Journaux d’erreur serveur — error.log / access.log, ou le lecteur de journaux de votre hébergeur ou plateforme. L’outil le plus important : la vraie cause se trouve ici.
• Google Search Console — Indexation des pages — la section « Erreur serveur (5xx) » liste les URL sur lesquelles Google voit des 500.
• GSC — rapport Statistiques d’exploration — la ventilation « par réponse » dans le temps sépare un incident ponctuel d’un vrai problème persistant de disponibilité.
• GSC — Inspection d’URL — récupérez une URL comme Google pour reproduire une 500 propre aux robots.
• Bing Webmaster Tools — les alertes d’erreur d’exploration regroupent les erreurs serveur (5xx) et vous orientent vers l’outil d’informations d’exploration.
• curl — reproduisez avec un user-agent quelconque : curl -I -A "Googlebot" <url> pour voir le statut comme un robot.
• Robots d’exploration / audits de site — Ahrefs Site Audit et Screaming Frog SEO Spider détectent les réponses 5xx à l’échelle du site et permettent de repérer les schémas (modèle ou section entière en échec).
• Supervision de disponibilité / statut — alertez sur les taux de 5xx pour apprendre le pic avant Google.

Ressources utiles

Mes articles connexes

• Codes de statut HTTP : guide de leur impact sur le SEO et l’UX — ma référence complète des codes de statut, avec la définition de 500 et la place plus large de l’exploration face aux 5xx.
• Le guide du débutant en SEO technique — place des erreurs serveur dans le contexte technique plus large.

Mes conférences

• Comment fonctionne la recherche (SlideShare) — mon parcours de l’exploration et de la manière dont la santé du serveur se répercute sur elle. (Mon avertissement habituel s’applique : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) : « Voici ma compréhension des systèmes… elle ne sera pas complète ni exacte à 100 %. »)

Dans le secteur

• Comment les codes d’erreur 500 peuvent nuire à l’indexation (Search Engine Journal) — article de Matt G. Southern avec les citations de John Mueller sur nouvelle tentative → exploration ralentie → retrait de l’index et la règle empirique d’environ 1 %.
• Comment corriger l’erreur « Erreur serveur (5xx) » dans Google Search Console (Search Engine Land) — guide étape par étape du rapport GSC.
• Comment corriger « Erreur serveur (5xx) » dans Google Search Console (Onely) — nature des erreurs 5xx, emplacement dans GSC et chemin de correction.
• Comment corriger une erreur interne du serveur 500 sur votre site (Kinsta) — liste détaillée centrée sur l’hébergement WordPress (journaux serveur, plugins/thèmes, mémoire PHP, .htaccess, permissions).
• Erreurs serveur 5xx : guide pour trouver et corriger les problèmes 5xx (Lumar) — angle d’audit technique et d’entreprise, particulièrement utile pour les journaux et le budget d’exploration.
• Comment corriger l’erreur serveur 5xx dans Google Search Console (Sitechecker) — autre guide du rapport GSC.

Vidéos

• Google Search Central (YouTube) — les archives de SEO Office Hours, où prennent leur origine les conseils de John Mueller sur les erreurs serveur et l’exploration (la séquence nouvelle tentative → exploration ralentie → retrait de l’index citée plus haut). Chaîne

Testez-vous : 500 — erreur interne du serveur

Cinq questions rapides sur ce qu’est une 500 et son effet sur le SEO. Choisissez une réponse pour chaque question, puis vérifiez.

Journal des modifications