Une 502 Bad Gateway indique qu’un serveur intermédiaire n’a pas reçu une réponse valide du serveur auquel il s’adresse. Dans une architecture courante, le navigateur contacte un proxy, qui transmet la requête à l’application. La panne peut donc se situer après le premier serveur.
Un diagnostic par horodatage
Exemple pédagogique : la page renvoie une 502 à 10 h 14. Relevez URL, heure et éventuel identifiant de requête. Cherchez ensuite la même requête dans les journaux du proxy et de l’application.
Navigateur → proxy → application
502 ← réponse amont absente ou invalide
Si l’application n’a aucune trace, vérifiez son accès depuis le proxy. Si elle a reçu la requête, examinez son erreur ou son arrêt. Ne redémarrez pas tous les services avant d’avoir conservé les éléments de diagnostic.
Ce qu’il faut mesurer
Une erreur isolée et une rubrique indisponible pendant des heures ne se traitent pas de la même manière. Regardez la fréquence, les URL touchées, les délais et les changements récents. Un pic de mémoire, un déploiement ou une mauvaise adresse de serveur amont sont des pistes, pas des conclusions automatiques.
Les erreurs 5xx peuvent ralentir le crawl et, lorsqu’elles persistent, affecter l’indexation. Une panne n’implique toutefois pas une désindexation instantanée. Documentation Google.
Après le correctif
Contrôlez plusieurs URL, dont une page dynamique et une ressource statique. Vérifiez que les nouvelles requêtes réussissent et que les logs ne continuent pas à accumuler des erreurs. Faites ensuite un crawl de contrôle et consultez les signaux de Search Console.
Une 403 relève d’un accès refusé ; elle ne doit pas être diagnostiquée comme une 502.