502 — mauvaise passerelle

TL;DR — Une 502 Bad Gateway signifie qu’un serveur demandait votre page à un autre serveur et a reçu une mauvaise réponse. Le serveur « frontal » est généralement un CDN ou un proxy, et le serveur « arrière » est votre véritable site (l’origine). L’erreur se situe dans votre hébergement ou votre infrastructure — pas dans Google Search Console — et une 502 de courte durée présente en pratique un risque SEO limité, même si Google ne publie pas de durée exacte considérée comme « sûre ». Plus elle s’éternise, plus le problème devient sérieux.

Qu’est-ce qu’une 502 Bad Gateway ?

Lorsque vous chargez une page, la requête ne va souvent pas directement à votre site. Elle passe par un intermédiaire — un CDN (comme Cloudflare), un répartiteur de charge ou un proxy inverse (comme Nginx). Cet intermédiaire transmet la requête à votre véritable serveur, attend une réponse et la renvoie au visiteur.

Une 502 Bad Gateway est ce que l’intermédiaire affiche lorsqu’il a demandé la page à votre serveur et a reçu quelque chose d’invalide — ou rien du tout. En termes simples : le serveur frontal n’a pas pu obtenir une bonne réponse du serveur arrière. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

C’est la nuance importante. Une 502 ne signifie pas automatiquement que votre site est hors service. Votre serveur peut être parfaitement sain et répondre correctement à une requête directe — mais si le proxy placé devant lui ne parvient pas à l’atteindre (délai d’attente, mauvais réglage ou journée difficile pour le CDN), les visiteurs voient tout de même une 502.

En quoi diffère-t-elle de ses cousines ?

Vous verrez quelques erreurs 5xx qui se ressemblent :

• 500 — le code de votre propre site a rencontré une erreur en construisant la page.
• 502 — un proxy placé devant votre site a reçu une mauvaise réponse de celui-ci.
• 503 — votre site est délibérément indisponible (maintenance planifiée, surcharge).
• 504 — un proxy a attendu votre serveur, mais le délai a expiré sans aucune réponse.

Elles sont liées, mais elles indiquent des endroits différents où chercher.

Une 502 nuit-elle à votre SEO ?

Généralement pas beaucoup — tant qu’elle ne dure pas. Le robot d’exploration de Google (Googlebot) traite une 502 comme les autres erreurs 5xx : il ralentit l’exploration en fonction du nombre de vos URL en erreur, puis reprend progressivement lorsque votre site recommence à répondre avec des 2xx. Google ne publie pas de durée exacte considérée comme « sûre », mais une brève 502 — de quelques minutes à quelques heures — présente beaucoup moins de risque pratique qu’une erreur récurrente.

Le risque réel apparaît lorsqu’une 502 se répète ou reste active pendant une longue période. Google indique que les URL qui “persistently” (traduction) : « renvoient une erreur de manière persistante » sont retirées ; il ne définit pas cela comme un nombre précis de jours. John Mueller a mentionné de manière informelle “multiple days” (traduction) : « plusieurs jours », comme ordre de grandeur du moment où des pages commencent à disparaître, et qu’elles ont tendance à revenir lorsque le site se rétablit — mais considérez cela comme la lecture personnelle d’une personne sur un incident précis, et non comme une règle officielle.

Que faire ?

• N’essayez pas de la « réparer » dans Search Console. Search Console ne fait que signaler une 502 après coup. La correction se fait sur votre CDN, votre proxy ou votre serveur.
• Vérifiez si le problème ne touche que vous ou tout le monde. Si Internet fonctionne partout ailleurs mais que votre site est en panne, c’est votre configuration. Si un grand CDN subit une panne, ce n’est peut-être pas votre faute — et il n’y a rien à corriger de votre côté si ce n’est attendre.
• Consultez la page d’état de votre hébergeur ou de votre CDN et vos journaux serveur. C’est là que se trouve la vraie réponse.

Vous voulez le diagnostic couche par couche (CDN, proxy et origine), le contenu exact de la documentation de Google et les propos de John Mueller pendant la panne Cloudflare de novembre 2025 ? Passez à l’onglet Advanced.

TL;DR — Une 502 est une panne de la couche proxy/passerelle : la RFC 9110 §15.6.3 la définit comme le fait, pour une passerelle ou un proxy, de recevoir une réponse invalide d’un serveur entrant. Elle se distingue d’une 500 (erreur de l’application d’origine) et d’une 503 (origine délibérément indisponible). La documentation de Google regroupe 500, 502 et 503 dans un traitement 5xx commun — le rythme d’exploration baisse proportionnellement au nombre d’URL en erreur, le contenu 5xx est ignoré et les erreurs persistantes font sortir les pages de l’index. Le retour à la normale est progressif une fois les 2xx rétablies, sans calendrier fixe publié par Google. La durée compte, mais il n’existe aucun seuil officiel : les pics brefs présentent beaucoup moins de risque pratique, tandis que les erreurs récurrentes mettent réellement les pages en danger — les remarques de Mueller en novembre 2025 évoquent informellement plusieurs jours, et non un SLA documenté. Diagnostiquez par couche — CDN, proxy inverse ou origine — et corrélez les preuves entre les sauts plutôt que de vous fier à une page d’erreur marquée.

Ce qu’indique réellement une 502

La RFC 9110 §15.6.3 définit précisément la 502 : une passerelle ou un proxy reçoit une réponse invalide d’un serveur entrant auquel il a accédé en essayant de satisfaire la requête. Cette limite de la spécification est importante : elle identifie l’endroit où la passerelle a observé l’échec, pas nécessairement le saut qui l’a causé. Le statut 502 est la preuve d’une panne à une frontière, et non la preuve que l’application d’origine est défectueuse. C’est la distinction que la plupart des articles concurrents « 13 façons de la corriger » brouillent, et pourquoi le diagnostic ci-dessous est par couches plutôt que plat. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

Comparez les codes 5xx que l’on confond facilement :

• 500 Internal Server Error — l’application d’origine a elle-même rencontré une erreur (bug, exception non gérée, épuisement des ressources). L’origine a répondu, et la réponse disait : « j’ai cassé ».
• 502 Bad Gateway — le proxy a reçu une réponse malformée ou invalide de l’amont (RFC 9110 §15.6.3).
• 503 Service Unavailable — l’origine est délibérément indisponible ; c’est le code intentionnel, reconnu par Google comme « revenez plus tard », à utiliser pour une maintenance planifiée, idéalement avec un en-tête Retry-After.
• 504 Gateway Timeout — le proxy a attendu l’amont et n’a obtenu aucune réponse avant l’expiration du délai (RFC 9110 §15.6.5). (502 = mauvaise réponse ; 504 = aucune réponse à temps.)

La conséquence pratique : la 503 est le code que vous choisissez volontairement ; la 502 est le code qui vous arrive lorsque l’infrastructure tombe en panne.

Comment Googlebot traite une 502

Voici la partie qu’il faut ancrer dans la documentation réelle de Google plutôt que dans le vague « cela peut nuire au classement » que vous lirez ailleurs. Le document Google sur les erreurs HTTP et réseau liste 502 (bad gateway) comme un code 5xx et applique le même traitement à tous les 5xx :

• Le rythme d’exploration baisse proportionnellement. Google réduit le rythme d’exploration du site, et cette baisse est proportionnelle au nombre d’URL individuelles qui renvoient une erreur serveur. Quelques 502 sont limitées ; une 502 à l’échelle du site signifie clairement « ralentissez ».
• Le contenu 5xx est ignoré. Tout ce que Google reçoit d’une URL qui renvoie une 5xx est ignoré — il n’indexera pas une page d’erreur 502 comme votre contenu.
• La conservation dans l’index est temporaire. Les URL déjà indexées restent d’abord dans l’index, mais le pipeline d’indexation de Google retire les URL qui renvoient une erreur serveur de manière persistante.
• Le rétablissement est automatique et progressif. Une fois que le serveur recommence à répondre avec des 2xx, Google augmente progressivement le rythme d’exploration. Aucun renvoi, aucune demande de réexamen ni héroïsme « Valider la correction » n’est nécessaire pour un rétablissement ordinaire — ce bouton indique seulement à Google de vérifier plus tôt.

Le point essentiel : 502 est traitée comme 500 et 503. Elle n’est pas « moins grave » parce qu’elle prend naissance dans la couche proxy/CDN plutôt que dans l’application d’origine. Il n’existe aucune indulgence documentée pour la 502. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

La durée est toute l’histoire

Le fait qu’une 502 vous nuise réellement dépend de sa durée — mais Google ne publie ni durée sûre fixe ni seuil fixe de retrait ; considérez donc ce qui suit comme une couleur pratique, et non comme un SLA :

• Un bref pic (de quelques minutes à quelques heures) → la réduction du rythme d’exploration de Google dépend du nombre d’URL en erreur ; un pic court et limité a donc un impact pratique restreint et ne mérite généralement pas de chercher une solution dans Search Console. Rien dans la documentation de Google n’exempte officiellement les erreurs brèves — c’est une question de degré, pas une limite ferme.
• Une erreur qui se répète ou reste active → c’est la situation à laquelle s’applique la formule de Google « renvoient une erreur serveur de manière persistante », et les pages peuvent commencer à sortir de l’index. Google ne définit pas « persistante » comme un nombre précis de jours. Le commentaire public de Mueller ci-dessus situait cela informellement autour de “multiple days” (traduction) : « plusieurs jours », avec un rétablissement assez rapide une fois le site sain — mais c’est la lecture d’un praticien sur un incident précis, et non une règle documentée sur laquelle compter pour chaque site ou CDN.

Cela correspond vaguement à la panne Cloudflare de novembre 2025, quand une vague de sites a renvoyé des erreurs 5xx sans que ce soit leur faute. La réponse publique de Mueller sur Bluesky disait que l’exploration des 5xx ralentit, mais “ramps back up” (traduction) : « reprend progressivement » — consultez l’onglet Quotes pour la formulation exacte et les réserves sur les sources, notamment le commentaire distinct sur « plusieurs jours », relayé par un compte rendu tiers plutôt que vérifié sur le fil original. Une panne courte confirmée par le fournisseur est presque le meilleur cas : elle est visible, se résout généralement seule et, une fois le rétablissement confirmé par le fournisseur et vos propres réponses 2xx rétablies, la réaction raisonnable consiste généralement à attendre plutôt qu’à modifier l’infrastructure de manière réactive.

Diagnostiquer une 502 par couche

Comme une 502 est une panne de communication entre serveurs, le moyen le plus rapide de la trouver est de descendre la pile — CDN, puis proxy inverse, puis origine — plutôt que de suivre une liste plate de contrôles. (L’onglet Decision Trees propose cette marche à suivre.)

Une précaution avant de commencer : une page d’erreur marquée, le nom d’un fournisseur dans un en-tête ou l’apparence d’une panne constituent un signal, et non la preuve du saut qui a échoué. Corrélez-les avec les en-têtes de réponse, les identifiants de requête/trace et les journaux horodatés des deux côtés du saut avant de conclure « c’est le CDN » ou « c’est mon origine ».

Couche CDN / périphérie

• Délai d’attente amont : le nœud périphérique n’a pas pu obtenir une réponse de l’origine à temps.
• La périphérie ne peut pas atteindre l’origine — échec de résolution DNS, échec de négociation SSL/TLS ou pare-feu/sécurité de l’origine qui bloque les plages IP du CDN.
• Les causes documentées varient selon le fournisseur : les documents de dépannage de Cloudflare décrivent des scénarios de connectivité avec l’origine et de délai propres à son réseau périphérique, tandis qu’AWS CloudFront documente son propre ensemble de causes liées à TLS, DNS, aux ports et aux fonctions d’origine — consultez la documentation de votre CDN au lieu de supposer que la liste d’un fournisseur s’applique à un autre.
• Panne du fournisseur CDN lui-même (Cloudflare, Fastly, AWS, etc.) — un événement de masse renvoyant des 502 sur des sites sans rapport, qui n’a rien à voir avec la santé de votre serveur ; confirmez-le sur la page d’état du fournisseur, et pas seulement grâce à la marque de la page d’erreur.

Couche proxy inverse / répartiteur de charge (Nginx, Apache mod_proxy, HAProxy)

• Délai d’attente du backend ou connexion refusée.
• Bloc proxy_pass / amont mal configuré et pointant au mauvais endroit.
• Épuisement du pool backend — chaque worker amont est occupé.
• Incompatibilité SSL/TLS entre le proxy et le backend.

Couche serveur d’origine

• Crash ou redémarrage de l’application/PHP-FPM, ou arrêt OOM (limite mémoire dépassée).
• Épuisement des connexions à la base de données.
• Déploiement/redémarrage provoquant une indisponibilité brève.
• Un WAF ou un plugin de sécurité qui bloque des IP légitimes du proxy ou du robot d’exploration comme s’il s’agissait d’attaquants — c’est le cas trompeur, car les navigateurs normaux fonctionnent tandis que le proxy (ou Googlebot) reçoit des 502.

Ce dernier cas mérite d’être souligné : si seuls Googlebot ou les requêtes passant par le CDN reçoivent des 502 tandis que les navigateurs normaux fonctionnent, vous êtes face à un blocage propre aux robots ou à une réponse variable, et non à une véritable panne. Testez l’origine directement puis par le CDN, et vérifiez ce que Googlebot voit avec le test en direct de l’inspection d’URL de Search Console au lieu de supposer que le rapport « Erreur serveur (5xx) », peut-être déjà obsolète, reflète encore l’impact actuel.

Corriger et prévenir les 502

Les corrections dépendent de la couche, et la personne qui doit les faire varie selon le rôle :

• Visiteur — rien à corriger. Rechargez une fois, essayez un autre réseau si vous soupçonnez un problème local et attendez sinon ; les changements dans le navigateur ne peuvent pas réparer une panne de serveur à serveur.
• Propriétaire du site sans accès à l’infrastructure — confirmez l’étendue du problème et consultez d’abord les pages d’état et les journaux (voir la checklist ci-dessous), puis contactez votre hébergeur, le support CDN ou l’équipe de développement au lieu de deviner une correction.
• Propriétaire de l’hébergeur, du CDN ou de l’application — corrigez la configuration proxy/amont, augmentez les délais et la capacité backend lorsque l’origine est le goulot d’étranglement réel, et échelonnez les déploiements pour que les redémarrages ne fassent pas clignoter tout le pool. Traitez la mise sur liste autorisée du WAF, les changements de pare-feu et les modifications de configuration proxy/amont comme des changements nécessitant une validation — appliquez-les seulement lorsque les journaux et les preuves du fournisseur montrent effectivement un échec de pare-feu ou de contrôle d’accès, et non comme une première hypothèse ; autoriser un CDN ou un robot n’est pas une correction générique d’une 502.

Pour prévenir le problème, les mesures peu glamour sont les plus efficaces : surveillance de disponibilité avec alertes, surveillance des journaux d’erreur du serveur et du proxy, suivi de l’état de l’hôte et de la tendance « Erreur serveur (5xx) » dans les statistiques d’exploration de Search Console, et corrélation des pics avec les pages d’état de vos fournisseurs CDN et DNS afin de distinguer en quelques secondes « mon problème » de « leur panne ».

Les codes associés à garder en tête se trouvent juste à côté dans ce cluster : l’origine 500, la 503 intentionnelle et la 504 de délai d’attente.

Résumé par IA

Une synthèse de la version Advanced :

• 502 = panne de la couche proxy/passerelle. La RFC 9110 §15.6.3 la définit comme le fait, pour une passerelle ou un proxy, de recevoir une réponse invalide d’un serveur entrant — c’est la preuve d’une panne à une frontière, et non la preuve du saut (CDN, proxy ou origine) qui l’a causée. L’origine peut être saine alors que les visiteurs voient une 502.
• Causes distinctes, même famille documentée. 500 (erreur de l’application d’origine), 502 (le proxy reçoit une mauvaise réponse, RFC §15.6.3), 503 (origine délibérément indisponible), 504 (le proxy n’obtient pas de réponse à temps, RFC §15.6.5). La documentation de Google regroupe 500, 502 et 503 dans un même traitement 5xx — elle ne documente pas de parité spécifique entre les statuts au-delà de cette règle de famille.
• Réaction de Googlebot : le rythme d’exploration baisse proportionnellement au nombre d’URL en erreur, le contenu 5xx est ignoré, les URL indexées sont conservées à court terme mais retirées si les erreurs persistent, et l’exploration reprend progressivement une fois les 2xx rétablies — Google ne publie ni durée sûre exacte ni calendrier garanti de rétablissement.
• La durée compte, sans seuil officiel. Les pics brefs présentent beaucoup moins de risque pratique ; les erreurs récurrentes constituent le vrai risque. Le commentaire informel de Mueller en novembre 2025 situait les retraits autour de « plusieurs jours », avec un rétablissement assez rapide — considérez-le comme la lecture d’un praticien sur un incident, et non comme un SLA documenté.
• Diagnostiquez en corrélant les preuves entre les couches, et non en vous fiant seulement à la marque : CDN (délai d’attente, échec DNS/SSL, panne du fournisseur — Cloudflare et AWS CloudFront documentent chacun des causes propres à leur plateforme) → proxy inverse (mauvais proxy_pass, épuisement du pool, connexion refusée) → origine (crash de l’application/PHP-FPM, OOM, épuisement DB, WAF bloquant les IP du proxy ou du robot). Faites correspondre en-têtes, identifiants de trace et journaux horodatés des deux côtés d’un saut avant de conclure quelle couche a échoué.
• La correction n’est pas universelle. GSC ne fait que signaler la 502 après coup et ne peut pas la réparer. Les visiteurs ne peuvent pas non plus la corriger ; les propriétaires sans accès à l’infrastructure doivent escalader plutôt que modifier la configuration, et les changements destructeurs — liste autorisée WAF, pare-feu ou proxy — doivent suivre les preuves des journaux ou du fournisseur, et non constituer une première hypothèse. Si seuls Googlebot ou les requêtes via le CDN reçoivent une 502, soupçonnez un blocage propre aux robots, pas une panne mondiale.

Documentation officielle

Documentation issue de sources primaires sur la façon dont les moteurs de recherche traitent les erreurs 5xx, notamment 502.

Google

• Effet des codes d’état HTTP sur les robots de Google — le document de référence ; il liste 502 (bad gateway) avec 500 et 503 et décrit le traitement commun de l’exploration et de l’indexation.
• Gérer une interruption planifiée du site — pourquoi 503 (et non 502, 404 ou 200) est le bon code pour une interruption intentionnelle, avec un en-tête Retry-After. Utile pour distinguer 502 et 503.
• Spécification de robots.txt — gestion des erreurs serveur — traitement par Google d’une 5xx sur le fichier robots.txt lui-même.

Spécification

• RFC 9110 §15.6.3 — 502 (Bad Gateway) — définition au niveau de la spécification : une passerelle ou un proxy reçoit une réponse invalide d’un serveur entrant auquel il a accédé en essayant de satisfaire la requête. Elle identifie la frontière où l’échec a été observé, et non le saut qui l’a causé.

Bing / Microsoft

• Centre d’aide Bing Webmaster Tools — Bing fait remonter les problèmes d’exploration côté serveur (classe 5xx), notamment les échecs de connectivité, dans ses rapports d’erreurs d’exploration.

Citations des sources

Déclarations attribuées, provenant de Google ou de John Mueller. Chaque lien pointe directement vers le passage cité.

Google — traitement des 5xx (dont 502)

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped.” (traduction) : « Les erreurs serveur 5xx et 429 amènent temporairement les robots de Google à ralentir l’exploration. Pour Google Search, les URL déjà indexées sont conservées dans l’index, mais finissent par en être retirées. » — Google Search Central, How HTTP status codes affect Google’s crawlers. Aller à la citation
• “Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error. For Google Search, Google’s indexing pipeline removes from the index URLs that persistently return a server error.” (traduction) : « Google réduit le rythme d’exploration du site. Cette réduction est proportionnelle au nombre d’URL individuelles qui renvoient une erreur serveur. Pour Google Search, le pipeline d’indexation de Google retire de l’index les URL qui renvoient une erreur serveur de manière persistante. » — même document, ligne du tableau couvrant 500, 502 et 503. Aller à la citation
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (traduction) : « Dès que le serveur recommence à répondre avec un code d’état 2xx, Google augmente progressivement le rythme d’exploration du site. » — même document. Aller à la citation

John Mueller, Google (Bluesky, 18 novembre 2025 — réponse à un fil sur le pic de 5xx de la panne Cloudflare)

• “Yeah. 5xx = Google crawling slows down, but it’ll ramp back up.” (traduction) : « Oui. 5xx = l’exploration de Google ralentit, mais elle reprendra progressivement. » Voir la publication
• “If it stays at 5xx for multiple days, then things may start to drop out, but even then, those will pop back in fairly quickly.” (traduction) : « Si le 5xx persiste pendant plusieurs jours, certaines choses peuvent commencer à disparaître, mais même dans ce cas elles réapparaîtront assez vite. » Relaté par le compte rendu de Matt G. Southern dans Search Engine Journal sur le même échange ; confirmez la déclaration dans le fil original avant de la considérer comme définitive. Lire le compte rendu

Checklist de réponse à une 502 Bad Gateway

Lorsqu’une 502 apparaît — dans un navigateur, dans la surveillance ou dans le rapport « Erreur serveur (5xx) » de Search Console — suivez cette liste. Les rôles sont indiqués ainsi : [Tous] fonctionne avec ou sans accès à l’infrastructure ; [Propriétaire hôte/CDN/app] le nécessite.

• [Tous] Confirmez qu’elle est réelle et actuelle — reproduisez l’URL maintenant ; un rapport « Erreur serveur (5xx) » peut être en retard sur un pic déjà résolu.
• [Tous] Vérifiez l’étendue — une URL, une section ou tout le site ? (L’impact sur l’exploration dépend du nombre d’URL en erreur.)
• [Tous] Consultez la page d’état de votre fournisseur CDN/DNS pour vérifier une panne générale avant de toucher à votre propre configuration.
• [Propriétaire hôte/CDN/app] Testez l’origine directement puis via le CDN — si l’origine répond en 2xx directement mais que le CDN renvoie 502, le problème se trouve à la périphérie ou entre les deux.
• [Propriétaire hôte/CDN/app] Vérifiez si seuls les robots ou les IP du CDN reçoivent une 502 tandis que les navigateurs fonctionnent — cela indique un possible blocage WAF/pare-feu, et non une panne. Confirmez-le dans les journaux du pare-feu/WAF avant d’autoriser quoi que ce soit ; une liste autorisée n’est pas une correction générique et doit suivre les preuves.
• [Propriétaire hôte/CDN/app] Lisez les journaux d’erreur du proxy (Nginx/Apache/HAProxy) à la recherche de délais d’attente amont ou de connexions refusées.
• [Propriétaire hôte/CDN/app] Lisez les journaux de l’origine pour repérer les crashs de l’application, les arrêts OOM ou l’épuisement des connexions DB aux heures concernées.
• [Tous] Vérifiez ce que voit Googlebot avec le test en direct de l’inspection d’URL de GSC.
• [Propriétaire hôte/CDN/app] Appliquez le correctif propre à la couche seulement lorsque les journaux ou les preuves du fournisseur l’indiquent — les changements de WAF, pare-feu, délai et configuration proxy sont des changements d’infrastructure, pas des hypothèses de première réponse.
• [Tous] Une fois la correction effectuée, laissez le rétablissement se faire — les réponses 2xx font progressivement reprendre l’exploration ; Google ne publie pas de calendrier exact. Utilisez « Valider la correction » uniquement pour demander une nouvelle vérification plus rapide, pas comme une « correction ».
• [Propriétaire hôte/CDN/app] Confirmez qu’à l’avenir vous utilisez 503 (et non 502) pour toute indisponibilité planifiée.

Ma 502 vient-elle du CDN, du proxy ou de l’origine ?

Une 502 est une panne entre les serveurs : diagnostiquez-la en descendant la pile au lieu de deviner. Commencez à la périphérie et progressez vers l’intérieur.

Q1. Votre fournisseur CDN ou DNS signale-t-il une panne en ce moment ?

• Oui → il s’agit probablement d’une panne générale du fournisseur (l’événement Cloudflare de novembre 2025 en est le cas d’école). Il n’y a généralement rien à corriger de votre côté. Confirmez que votre origine est saine, puis attendez le rétablissement — le rythme d’exploration de Google reprend progressivement lorsque les réponses 2xx reviennent, sans calendrier exact publié. Arrêtez-vous ici.
• Non → continuez.

Q2. L’origine répond-elle en 2xx à une requête directe (en contournant le CDN/proxy) ?

• Non — l’origine échoue aussi → le problème se situe à la couche origine. Consultez les journaux pour les crashs de l’application/PHP-FPM, les arrêts OOM, l’épuisement des connexions DB ou un mauvais déploiement. Selon la façon dont le proxy l’observe, cela peut aussi apparaître comme une 500 ou une 504. Arrêtez-vous ici.
• Oui — l’origine est saine directement, mais le CDN/proxy renvoie 502 → continuez. L’origine va bien ; quelque chose placé devant elle n’obtient pas une réponse propre.

Q3. Les navigateurs normaux fonctionnent-ils alors que seuls Googlebot ou les IP du CDN reçoivent des 502 ?

• Oui → soupçonnez un blocage WAF ou pare-feu qui traite les plages IP du proxy ou du robot comme des attaquants. Confirmez-le d’abord dans les journaux du pare-feu/WAF, puis autorisez les plages IP légitimes du CDN et des robots vérifiés — n’autorisez rien sans cette confirmation. Arrêtez-vous ici.
• Non — tout le monde reçoit une 502 via le proxy → continuez.

Q4. Que montrent les journaux du proxy inverse pour l’amont ?

• Délai d’attente / connexion refusée → le proxy atteint le backend, mais n’obtient pas une réponse valide à temps → problème de capacité backend ou de délai (pool épuisé, délais trop serrés). Augmentez la capacité ou les délais, ou corrigez le backend lent.
• Mauvais hôte / DNS / échec de négociation SSL vers l’amont → mauvaise configuration du proxy → corrigez le bloc proxy_pass / amont ou la configuration TLS proxy↔backend.

Quelle que soit la couche, le nettoyage SEO est le même et largement automatique. Une fois les URL de retour en 2xx, Google reprend automatiquement l’exploration — aucune nouvelle soumission n’est nécessaire.

Mythes et erreurs à éviter avec une 502

• Mythe : « 502 est un problème Google/SEO que je corrige dans Search Console. » Non. Une 502 est une panne d’hébergement ou d’infrastructure ; Search Console ne fait que la signaler après coup. La correction se trouve sur le CDN, le proxy ou l’origine. « Valider la correction » demande seulement à Google de revérifier — cela ne répare rien.
• Mythe : “A 502 always means my server is down.” (traduction) : « Une 502 signifie toujours que mon serveur est hors service. » Non. L’origine peut renvoyer 2xx à une requête directe alors que les visiteurs voient une 502 via le CDN — délai d’attente, mauvaise configuration amont ou panne du CDN lui-même. Testez l’origine directement avant de conclure que le serveur a crashé.
• Mythe : « Une 502 est moins grave qu’une 500 pour le SEO. » Non. La documentation de Google applique à 500, 502 et 503 la même réduction du rythme d’exploration et le même retrait éventuel de l’index pour les erreurs persistantes. Il n’existe aucune indulgence documentée pour 502.
• Mythe : « Une 502 ponctuelle va désindexer ma page. » Non. L’exploration ralentit puis reprend. Le retrait de l’index exige que l’erreur persiste — la documentation de Google emploie ce mot sans définir un nombre exact de jours. Le commentaire informel de Mueller en novembre 2025 évoquait “multiple days” (traduction) : « plusieurs jours », en ajoutant que les pages retirées “pop back in fairly quickly” (traduction) : « réapparaissent assez vite » — considérez cela comme la lecture d’un praticien sur un incident, et non comme un seuil officiel.
• Mythe : « 502 et 503 veulent dire la même chose. » Non. La 503 est le code intentionnel de « service indisponible » à utiliser pour une maintenance planifiée (avec un Retry-After) ; la 502 est une panne proxy involontaire. Les confondre dans la surveillance masque les vrais incidents derrière des fenêtres de maintenance prévues.
• Mythe : « Vider le cache de mon navigateur corrige une 502 généralisée. » Ce conseil concerne un visiteur qui dépanne sa propre vue. Si le CDN, le proxy ou l’origine échoue réellement, aucune action dans un navigateur ne change quoi que ce soit pour les autres.
• Anti-pattern : cliquer réflexivement sur « Valider la correction » et actualiser GSC. Pendant un pic transitoire (ou une panne CDN), l’action la plus rapide et correcte consiste souvent à ne rien faire, sinon confirmer le rétablissement. Google gère automatiquement la reprise du rythme.

Playbook d’incident : le site renvoie 502

1. Confirmez l’étendue. Vérifiez une URL touchée avec le Website Down Checker, puis testez plusieurs URL avec le Bulk HTTP Status Code Checker. Si seul votre navigateur échoue, corrigez le problème local de réseau ou de DNS avant d’escalader un incident à l’échelle du site. Si de nombreuses URL publiques renvoient 502, continuez.
2. Enregistrez la réponse en échec. Conservez l’heure, l’URL, le statut, les en-têtes de réponse et tout identifiant de requête CDN. Si l’erreur est intermittente, répétez la requête au lieu de prendre une nouvelle tentative réussie pour un rétablissement.
3. Identifiez la passerelle — la marque n’est qu’un signal, pas une preuve. Lisez les en-têtes et la page d’erreur marquée pour repérer l’empreinte d’un CDN, d’un proxy inverse ou d’un répartiteur de charge, mais confirmez-la avec la page d’état du fournisseur et vos journaux avant de conclure quel saut a échoué ; les pages et en-têtes marqués dépendent du fournisseur et ne prouvent pas universellement la cause. Si le fournisseur signale une panne, suivez son incident ; sinon, poursuivez vers l’origine.
4. Comparez la périphérie et l’origine. Demandez normalement le nom d’hôte public, puis envoyez le même nom d’hôte directement à l’IP d’origine connue avec curl --resolve. Si l’origine réussit tandis que la périphérie renvoie 502, examinez la connectivité CDN-origine, TLS et la configuration du proxy. Si les deux échouent, passez aux journaux de l’application et de l’origine.
5. Corrélez les journaux par horodatage. Une connexion refusée ou un échec TLS pointe vers la frontière passerelle/origine ; une réponse amont malformée ou fermée brutalement pointe vers le service d’origine. Corrigez la couche défaillante, pas Search Console.
6. Vérifiez le rétablissement. Relancez les tests public et direct vers l’origine sur des URL représentatives. Si les réponses 2xx sont stables, surveillez les journaux et Search Console pendant que Googlebot reprend automatiquement l’exploration. Si les 502 reviennent, revenez à l’étape 4 avec les nouveaux horodatages au lieu d’augmenter aveuglément les nouvelles tentatives.

Prompt : classer un lot d’échecs 502 par couche

Collez un CSV contenant l’URL, l’horodatage, le statut, les en-têtes de réponse, le résultat côté public, le résultat direct vers l’origine et tout extrait de journal correspondant. Supprimez d’abord les secrets, cookies, en-têtes d’autorisation et adresses d’origine privées.

You are triaging HTTP 502 Bad Gateway failures. A 502 means a gateway or proxy
received an invalid response from an upstream server. Classify each row as one of:
CDN/edge, reverse proxy or load balancer, origin application/server, local-only,
provider-wide outage, or insufficient evidence.

For every row:
1. Cite the exact supplied evidence that supports the classification.
2. State the next check that would distinguish the leading cause from the runner-up.
3. Do not infer a cause from the 502 code alone.
4. Flag cases where the public edge fails but a same-host direct-origin test succeeds.
5. Group failures that share a timestamp, header fingerprint, or upstream log error.

Return a table with URL, likely layer, confidence (high/medium/low), evidence, next
check, and incident group. End with the three highest-value checks for the batch.

DATA:
[PASTE SANITIZED CSV HERE]

Attendez-vous à une file de triage, et non à un rapport définitif de cause racine. Validez chaque contrôle suggéré avec des en-têtes et des journaux en direct.

Reproduire la 502 publique

Exécutez ceci dans un shell macOS/Linux. Le script affiche les en-têtes de réponse sans télécharger le corps et ne suit aucune redirection, afin que vous voyiez la première réponse.

curl -sS -D - -o /dev/null https://www.example.com/affected-path

Équivalent PowerShell :

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -Method Head -SkipHttpErrorCheck

Si l’application traite HEAD différemment, utilisez un GET normal et ignorez le corps :

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -SkipHttpErrorCheck | Select-Object StatusCode, Headers

Comparer la route CDN à l’origine connue

Remplacez 203.0.113.10 par une IP d’origine que vous contrôlez. --resolve conserve le nom d’hôte public pour l’en-tête Host HTTP et le nom TLS tout en se connectant à cette IP.

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/affected-path

N’exposez pas une origine protégée et n’affaiblissez pas son pare-feu uniquement pour exécuter ce test. Lancez-le depuis un réseau déjà autorisé. Une 502 publique avec succès direct vers l’origine réduit la panne au chemin CDN/proxy ; un échec sur les deux chemins vous oriente vers l’origine ou l’application.

Outils pour circonscrire une 502

• Website Down Checker — confirme si l’URL est accessible depuis un point de présence Cloudflare externe et capture la durée, les redirections et des éléments DNS bornés. Il répond à « est-ce que cela n’arrive qu’à moi ? » avant que vous ne modifiiez l’infrastructure.
• Bulk HTTP Status Code Checker — teste un ensemble représentatif d’URL, affiche les chemins complets de redirection et la latence, et exporte les résultats. Utilisez-le pour distinguer une panne d’une seule route d’un incident 502 plus large.
• Tableau de bord de votre CDN ou répartiteur de charge — faites correspondre les identifiants de requête et les horodatages de la réponse en échec avec les journaux de périphérie et l’état du fournisseur.
• Journaux de l’application et du serveur d’origine — confirmez si l’amont a accepté la requête et s’il a renvoyé, réinitialisé ou malformé la réponse. C’est ce qui transforme une hypothèse de couche en cause racine.

Aucun outil ne peut identifier la couche défaillante à partir de 502 seul. Comparez les preuves de la périphérie publique avec une requête directe vers l’origine, déjà autorisée, et des journaux horodatés.

Testez-vous : 502 — mauvaise passerelle

Cinq questions rapides sur la nature d’une 502 et son effet sur le SEO. Choisissez une réponse pour chaque question, puis vérifiez.

Ressources qui valent votre temps

Mes articles associés

• Guide complet des codes de statut HTTP pour le SEO — place de 502 et du reste de la famille 5xx, et signification de chaque code pour les moteurs de recherche.
• Guide du SEO technique pour débutants — lien entre la santé du serveur et l’exploration dans une vue d’ensemble.
• Robots.txt et SEO : tout ce qu’il faut savoir — pertinent parce qu’une 5xx sur votre fichier robots.txt est traitée spécialement.

Dans le reste du secteur

• Effet des codes de statut HTTP sur les robots de Google (Google Search Central) — la source primaire : 502 (bad gateway) regroupée avec 500/503, avec la formulation exacte sur l’exploration et l’indexation.
• Gérer une interruption planifiée du site (Google Search Central) — distinction 503/502 et raison pour laquelle 503 est le code des interruptions intentionnelles.
• La panne Cloudflare déclenche des pics de 5xx : ce que cela signifie pour le SEO (Matt G. Southern, Search Engine Journal) — la panne de novembre 2025 comme étude de cas, avec les commentaires de Mueller.
• 502 Bad Gateway: référence MDN (MDN Web Docs) — définition neutre du statut au niveau de la spécification.
• RFC 9110 §15.6.3 — 502 (Bad Gateway) (IETF) — la spécification des sémantiques HTTP sous-jacentes.
• Corriger une erreur 502 Bad Gateway (Kinsta) — guide de dépannage détaillé vu depuis l’hébergeur, pour les corrections côté navigateur et propriétaire du site.
• 502 Bad Gateway : signification et correction pour les développeurs web (Webflow) — vue d’ensemble des causes et corrections destinée aux développeurs.

Journal des modifications