502 Bad Gateway: Bedeutung und Behebung

TL;DR — Ein 502 Bad Gateway bedeutet, dass ein Server Ihre Seite bei einem anderen Server angefordert und eine fehlerhafte Antwort erhalten hat. Meist ist der vorgeschaltete Server ein CDN oder Proxy und der nachgelagerte Ihr eigentlicher Website-Server (der Origin). Der Fehler liegt in Hosting oder Infrastruktur — nicht in der Google Search Console — und ein kurzlebiger 502 birgt in der Praxis meist ein begrenztes SEO-Risiko, obwohl Google keine genaue “sichere” Dauer veröffentlicht. Je länger er anhält, desto problematischer wird er.

Was ein 502 Bad Gateway ist

Wenn Sie eine Seite laden, geht die Anfrage oft nicht direkt an Ihre Website. Sie läuft über einen Vermittler — ein CDN (wie Cloudflare), einen Load Balancer oder einen Reverse Proxy (wie Nginx). Dieser Vermittler leitet die Anfrage an Ihren eigentlichen Server weiter, wartet auf eine Antwort und gibt sie an den Besucher zurück.

Ein 502 Bad Gateway ist die Meldung des Vermittlers, wenn er die Seite bei Ihrem Server angefordert und eine ungültige Antwort — oder überhaupt keine Antwort — erhalten hat. Vereinfacht: Der vorgeschaltete Server konnte vom nachgelagerten Server keine brauchbare Antwort bekommen. 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

Das ist die wichtige Nuance. Ein 502 bedeutet nicht automatisch, dass Ihre Website ausgefallen ist. Ihr Server kann vollkommen gesund sein und auf eine direkte Anfrage korrekt antworten — wenn der vorgeschaltete Proxy ihn aber nicht erreicht (Timeout, fehlerhafte Konfiguration oder ein eigener Ausfall des CDN), sehen Besucher trotzdem einen 502.

Worin er sich von verwandten Fehlern unterscheidet

Einige 5xx-Fehler sehen ähnlich aus:

• 500 — der eigene Code Ihrer Website ist beim Erstellen der Seite auf einen Fehler gestoßen.
• 502 — ein Proxy vor Ihrer Website hat eine fehlerhafte Antwort von ihr erhalten.
• 503 — Ihre Website ist absichtlich nicht verfügbar (geplante Wartung, Überlastung).
• 504 — ein Proxy hat auf Ihren Server gewartet, aber ohne Antwort ein Timeout erreicht.

Sie hängen zusammen, weisen aber auf unterschiedliche Stellen hin, an denen Sie suchen sollten.

Schadet ein 502 Ihrer SEO?

Meist nicht besonders — solange er nicht anhält. Googles Crawler (Googlebot) behandelt einen 502 wie andere 5xx-Fehler: Das Crawling wird proportional dazu verlangsamt, wie viele Ihrer URLs Fehler liefern, und anschließend wieder hochgefahren, sobald Ihre Website wieder mit 2xx antwortet. Google veröffentlicht keine genaue “sichere” Dauer, aber ein kurzer 502 — von Minuten bis zu ein paar Stunden — birgt in der Praxis deutlich weniger Risiko als einer, der immer wieder auftritt. 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

Das eigentliche Risiko entsteht, wenn ein 502 wiederkehrt oder über längere Zeit bestehen bleibt. Googles eigene Formulierung lautet, dass URLs entfernt werden, die “persistent” einen Serverfehler zurückgeben — eine konkrete Zahl von Tagen nennt Google dafür nicht. (John Mueller von Google erwähnte informell “mehrere Tage” als grobe Größenordnung, ab der Seiten aus dem Index fallen können, und dass sie nach der Erholung der Website meist wiederkommen — behandeln Sie das aber als die grobe Einschätzung einer Person zu einem bestimmten Vorfall, nicht als offizielle Regel.)

Was Sie dagegen tun können

• Versuchen Sie nicht, ihn in der Search Console zu “beheben”. Die Search Console meldet einen 502 erst im Nachhinein. Die Behebung erfolgt an Ihrem CDN, Proxy oder Server.
• Prüfen Sie, ob nur Sie oder alle betroffen sind. Wenn das gesamte Internet funktioniert, aber Ihre Website nicht, liegt es an Ihrer Konfiguration. Wenn ein großes CDN einen Ausfall hat, muss es nicht an Ihnen liegen — dann können Sie auf Ihrer Seite möglicherweise nur warten.
• Prüfen Sie die Statusseite Ihres Hosters oder CDN und Ihre Serverlogs. Dort liegt die eigentliche Antwort.

Möchten Sie die Diagnose nach Schichten (CDN, Proxy und Origin), genau wissen, was Googles Dokumentation sagt, und erfahren, was John Mueller während des Cloudflare-Ausfalls im November 2025 sagte? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — Ein 502 ist ein Fehler auf der Proxy-/Gateway-Schicht: RFC 9110 §15.6.3 definiert ihn als den Fall, dass ein Gateway oder Proxy von einem vorgelagerten Server eine ungültige Antwort erhält. Er unterscheidet sich von 500 (Fehler der Origin-Anwendung) und 503 (Origin absichtlich nicht verfügbar). Googles Dokumentation fasst 500, 502 und 503 unter einer gemeinsamen 5xx-Behandlung zusammen — die Crawl-Rate sinkt proportional zur Zahl fehlerhafter URLs, Inhalte aus 5xx-Antworten werden ignoriert und anhaltende Fehler führen dazu, dass Seiten aus dem Index fallen. Nach der Rückkehr von 2xx steigt das Crawling schrittweise wieder, ohne dass Google einen festen Zeitplan veröffentlicht. Die Dauer ist wichtig, aber es gibt keinen offiziellen Schwellenwert: Kurze Spitzen bergen deutlich weniger praktisches Risiko, während wiederkehrende Fehler das eigentliche Risiko darstellen — Muellers Äußerungen vom November 2025 sprechen informell von mehreren Tagen, nicht von einem dokumentierten SLA. Diagnostizieren Sie nach Schichten — CDN, Reverse Proxy oder Origin — und gleichen Sie Belege über mehrere Hops hinweg ab, statt sich allein auf eine gebrandete Fehlerseite zu verlassen.

Was ein 502 tatsächlich signalisiert

RFC 9110 §15.6.3 definiert 502 ausdrücklich als den Fall, dass ein Gateway oder Proxy von einem vorgelagerten Server, den es zur Erfüllung der Anfrage kontaktiert hat, eine ungültige Antwort erhält. Diese Grenze ist wichtig: Sie zeigt, an welcher Stelle das Gateway den Fehler beobachtet hat, aber nicht unbedingt, welcher Hop ihn verursacht hat. Der Status 502 ist ein Beleg für einen Fehler an einer Grenze, kein Beweis dafür, dass die Origin-Anwendung defekt ist. Genau diese Unterscheidung verwischen die meisten Beiträge mit “13 Lösungswegen” von Wettbewerbern; deshalb ist die folgende Diagnose geschichtet statt flach. 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

Vergleichen Sie die leicht zu verwechselnden 5xx-Codes:

• 500 Internal Server Error — die Origin-Anwendung selbst ist fehlgeschlagen (Codefehler, unbehandelte Ausnahme, Ressourcenmangel). Der Origin hat geantwortet, und die Antwort lautete: “Ich bin kaputt.”
• 502 Bad Gateway — der Proxy hat vom vorgelagerten Server eine fehlerhafte oder ungültige Antwort erhalten (RFC 9110 §15.6.3).
• 503 Service Unavailable — der Origin ist absichtlich nicht verfügbar; dies ist der beabsichtigte, von Google vorgesehene Code für “kommen Sie später wieder”, den Sie bei geplanter Wartung idealerweise mit einem Retry-After-Header verwenden.
• 504 Gateway Timeout — der Proxy hat auf den vorgelagerten Server gewartet und vor Ablauf seines Timeouts keine Antwort erhalten (RFC 9110 §15.6.5). (502 = fehlerhafte Antwort; 504 = nicht rechtzeitig eingetroffene Antwort.) 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 \nRetry-After

Die praktische Konsequenz: 503 ist der Code, den Sie absichtlich auswählen; 502 ist der Code, der Ihnen passiert, wenn die Infrastruktur ausfällt.

Wie Googlebot einen 502 behandelt

Hier lohnt es sich, auf Googles tatsächliche Dokumentation zu schauen, statt auf das vage “das kann Rankings schaden”, das Sie anderswo lesen. Googles Dokument zu HTTP- und Netzwerkfehlern führt 502 (bad gateway) als 5xx-Code auf und behandelt alle 5xx-Codes gleich:\n502 (bad gateway)

• Die Crawl-Rate sinkt proportional. Google verringert die Crawl-Rate der Website; die Verringerung ist proportional dazu, wie viele einzelne URLs einen Serverfehler zurückgeben. Einzelne 502-Fehler fallen wenig ins Gewicht; ein websiteweit auftretender 502 ist dagegen ein klares Signal zum Drosseln.
• 5xx-Inhalte werden ignoriert. Alles, was Google von einer URL erhält, die 5xx zurückgibt, wird ignoriert — Google indexiert die 502-Fehlerseite nicht als Ihren Inhalt.
• Der Index bleibt vorübergehend erhalten. Bereits indexierte URLs bleiben zunächst im Index, aber Googles Indexierungspipeline entfernt URLs, die anhaltend einen Serverfehler zurückgeben.
• Die Erholung erfolgt automatisch und schrittweise. Sobald der Server wieder mit 2xx antwortet, erhöht Google die Crawl-Rate allmählich. Für die normale Erholung sind keine erneute Übermittlung, kein Antrag auf erneute Prüfung und kein “Validierung gestartet”-Aktionismus nötig — die Schaltfläche fordert Google nur zu einer früheren erneuten Prüfung auf.

Die wichtigste Erkenntnis: 502 wird genauso behandelt wie 500 und 503. Er ist nicht “weniger ernst”, nur weil er an der Proxy-/CDN-Schicht statt in der Origin-Anwendung entsteht. Eine dokumentierte Sonderbehandlung zugunsten von 502 gibt es nicht. 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

Die Dauer ist entscheidend

Ob ein 502 Ihnen tatsächlich schadet, hängt davon ab, wie lange er anhält — Google veröffentlicht aber weder eine feste sichere Dauer noch einen festen Schwellenwert für das Herausfallen aus dem Index. Behandeln Sie das Folgende daher als praktische Einordnung, nicht als SLA:

• Eine kurze Spitze (Minuten bis einige Stunden) → Googles Reduzierung der Crawl-Rate skaliert mit der Zahl fehlerhafter URLs; eine kurze, kleinräumige Spitze hat daher geringe praktische Auswirkungen und ist normalerweise kein Grund, in der Search Console aktiv zu werden. Googles Dokumentation nimmt kurze Fehler formal nicht aus — es geht um den Grad, nicht um eine harte Grenze.
• Ein Fehler, der wiederkehrt oder bestehen bleibt → Hier greift Googles Formulierung “anhaltend einen Serverfehler zurückgeben”, und Seiten können beginnen, aus dem Index zu fallen. Google definiert “anhaltend” nicht als konkrete Zahl von Tagen. Muellers öffentliche Äußerung (unten) ordnete es informell bei mehreren Tagen ein, mit relativ schneller Erholung, sobald die Website gesund ist — das ist aber die Einschätzung eines Praktikers zu einem konkreten Vorfall, keine dokumentierte Regel, auf die Sie sich bei jeder Website oder jedem CDN verlassen können.

Das passt grob zum Cloudflare-Ausfall im November 2025, bei dem eine Welle von Websites ohne eigenes Verschulden 5xx-Fehler ausgab. Muellers öffentliche Antwort auf Bluesky lautete, dass sich das 5xx-Crawling verlangsamt, aber “wieder hochfährt” — im Tab Zitate finden Sie den genauen Wortlaut und die Hinweise zur Quellenlage, einschließlich einer separaten Aussage zu “mehreren Tagen”, die über eine Zusammenfassung Dritter überliefert und nicht anhand des Original-Threads verifiziert wurde. Ein kurzer, vom Anbieter bestätigter Ausfall ist nahezu der günstigste Fall: Er ist sichtbar, löst sich typischerweise von selbst, und sobald der Anbieter die Erholung bestätigt und Ihre eigenen 2xx-Antworten wieder vorliegen, besteht die vernünftige Reaktion meist darin, Infrastrukturänderungen zunächst nicht reaktiv vorzunehmen.

Einen 502 nach Schichten diagnostizieren

Da ein 502 ein Kommunikationsfehler zwischen Servern ist, finden Sie ihn am schnellsten, wenn Sie den Stack abwärts prüfen — CDN, dann Reverse Proxy, dann Origin — statt eine flache Checkliste abzuarbeiten. (Der Tab Entscheidungsbäume führt Sie dabei Schritt für Schritt.)

Eine Warnung vorab: Eine gebrandete Fehlerseite, der Name eines Anbieters in einem Header oder das “Aussehen” eines Ausfalls sind jeweils nur ein Beweissignal und kein Beweis dafür, welcher Hop fehlgeschlagen ist. Gleichen Sie Response-Header, Request-/Trace-IDs und zeitgestempelte Logs auf beiden Seiten des Hops ab, bevor Sie folgern: “Es ist das CDN” oder “Es ist mein Origin.”

CDN-/Edge-Schicht

• Upstream-Timeout: Der Edge-Knoten konnte nicht rechtzeitig eine Antwort vom Origin erhalten.
• Der Edge kann den Origin überhaupt nicht erreichen — DNS-Auflösungsfehler, fehlgeschlagener SSL/TLS-Handshake oder eine Origin-Firewall/Sicherheitsregel blockiert die IP-Bereiche des CDN.
• Die dokumentierten Ursachen unterscheiden sich je nach Anbieter: Cloudflares eigene Fehlerbehebungsdokumentation beschreibt Origin-Konnektivität und Timeouts speziell für sein Edge-Netzwerk, während AWS CloudFront eigene TLS-, DNS-, Port- und Origin-Function-Ursachen dokumentiert — prüfen Sie die Dokumentation Ihres konkreten CDN, statt anzunehmen, dass die Ursachenliste eines Anbieters für einen anderen gilt.
• Ein eigener Ausfall des CDN-Anbieters (Cloudflare, Fastly, AWS usw.) — ein Massen-502 über unabhängige Websites hinweg, der nichts mit dem Zustand Ihres Servers zu tun hat; bestätigen Sie ihn auf der Statusseite des Anbieters und nicht nur anhand der Marke auf der Fehlerseite.

Reverse-Proxy-/Load-Balancer-Schicht (Nginx, Apache mod_proxy, HAProxy)

• Timeout des Backends oder verweigerte Verbindung.
• Eine falsch konfigurierte proxy_pass-/Upstream-Definition, die auf das falsche Ziel zeigt.
• Erschöpfter Backend-Pool — jeder Upstream-Worker ist beschäftigt.
• Eine inkompatible SSL-/TLS-Konfiguration zwischen Proxy und Backend.\nmod_proxy proxy_pass

Origin-Server-Schicht

• Absturz oder Neustart der Anwendung/PHP-FPM oder ein OOM-Kill (Speicherlimit überschritten).
• Erschöpfte Datenbankverbindungen.
• Ein Deployment/Neustart, der eine kurze Nichtverfügbarkeit verursacht.
• Eine WAF oder ein Sicherheits-Plugin blockiert legitime Proxy- oder Crawler-IP-Adressen wie Angreifer — das ist der tückische Fall, weil normale Browser funktionieren, während der Proxy (oder Googlebot) 502s erhält.

Dieses letzte Muster verdient besondere Aufmerksamkeit: Wenn nur Googlebot oder nur Anfragen über das CDN 502s erhalten, während normale Browser funktionieren, handelt es sich wahrscheinlich um eine botspezifische Blockierung oder eine variierende Antwort und nicht um einen echten Ausfall. Testen Sie direkt am Origin und über das CDN und prüfen Sie mit dem Live-Test der URL-Prüfung in der Search Console, was Googlebot tatsächlich sieht, statt aus einem möglicherweise bereits veralteten Bericht zu Serverfehlern (5xx) auf eine anhaltende Auswirkung zu schließen.

502s beheben und verhindern

Die Behebung hängt von der Schicht ab, und wer sie vornehmen sollte, von der jeweiligen Rolle:

• Besucher — nichts zu beheben. Laden Sie einmal neu, probieren Sie bei einem vermuteten lokalen Problem ein anderes Netzwerk und warten Sie ansonsten; Änderungen im Browser können einen Server-zu-Server-Fehler nicht reparieren.
• Websitebetreiber ohne Infrastrukturzugriff — Umfang bestätigen und zuerst Statusseiten/Logs prüfen (siehe Checkliste unten), dann den Hoster, den CDN-Support oder das Entwicklerteam einschalten, statt eine Behebung zu erraten.
• Hoster-/CDN-/Anwendungsverantwortliche — Proxy-/Upstream-Konfiguration korrigieren, Timeouts und Backend-Kapazität erhöhen, wenn der Origin tatsächlich der Engpass ist, und Deployments staffeln, damit Neustarts nicht den gesamten Pool kurz unterbrechen. Behandeln Sie WAF-Allowlisting, Firewall-Änderungen und Änderungen an Proxy-/Upstream-Konfigurationen als zustimmungspflichtige Änderungen — führen Sie diese erst aus, wenn Logs und Anbieterbelege tatsächlich auf einen Firewall- oder Zugriffskontrollfehler hinweisen, nicht als erste Vermutung; ein CDN oder einen Crawler auf die Allowlist zu setzen ist keine allgemeine 502-Behebung.

Für die Vorbeugung sind die unspektakulären Maßnahmen am wirksamsten: Uptime-Monitoring mit Alarmen, Monitoring der Fehlerlogs von Server und Proxy, Beobachtung von Host status und dem Trend bei Serverfehlern (5xx) in den Crawl Stats der Search Console sowie der Abgleich von Spitzen mit den Statusseiten Ihrer CDN- und DNS-Anbieter. So können Sie in Sekunden zwischen “mein Problem” und “deren Ausfall” unterscheiden.

Verwandte Codes, die in diesem Cluster direkt danebenliegen: der Origin-500, der absichtlich verwendete 503 und der Timeout-504.

KI-Zusammenfassung

Eine komprimierte Zusammenfassung der Advanced-Version:

• 502 = Fehler auf Proxy-/Gateway-Schicht. RFC 9110 §15.6.3 definiert ihn als eine ungültige Antwort, die ein Gateway oder Proxy von einem vorgelagerten Server erhält — das belegt einen Fehler an einer Grenze, aber nicht, welcher Hop (CDN, Proxy oder Origin) ihn verursacht hat. Der Origin kann gesund sein, während Besucher trotzdem einen 502 sehen.
• Unterschiedliche Ursachen, dieselbe dokumentierte Familie. 500 (Fehler der Origin-Anwendung), 502 (Proxy erhält eine ungültige Antwort, RFC §15.6.3), 503 (Origin absichtlich nicht verfügbar), 504 (Proxy erhält keine rechtzeitige Antwort, RFC §15.6.5). Googles Dokumentation fasst 500, 502 und 503 unter einer gemeinsamen 5xx-Behandlung zusammen; darüber hinaus dokumentiert sie keine besondere statuscodespezifische Behandlung.
• Googles Reaktion: Die Crawl-Rate sinkt proportional zur Zahl fehlerhafter URLs, 5xx-Inhalte werden ignoriert, indexierte URLs kurzfristig erhalten, aber bei anhaltenden Fehlern entfernt, und das Crawling steigt nach Rückkehr von 2xx schrittweise wieder. Google veröffentlicht weder eine genaue sichere Dauer noch einen garantierten Zeitplan für die Erholung.
• Die Dauer ist wichtig, aber es gibt keinen offiziellen Schwellenwert. Kurze Spitzen bergen deutlich weniger praktisches Risiko; wiederkehrende Fehler sind das eigentliche Risiko. Muellers informelle Bemerkung vom November 2025 ordnete das Herausfallen aus dem Index bei “mehreren Tagen” ein und sprach von relativ schneller Erholung — behandeln Sie das als Einschätzung eines Praktikers zu einem Vorfall, nicht als dokumentierte SLA.
• Diagnostizieren Sie durch Abgleich der Belege über die Schichten hinweg, statt der Marke allein zu vertrauen: CDN (Timeout, DNS-/SSL-Fehler, Anbieterausfall — Cloudflare und AWS CloudFront dokumentieren jeweils unterschiedliche plattformspezifische Ursachen) → Reverse Proxy (falsches proxy_pass, erschöpfter Pool, verweigerte Verbindung) → Origin (Absturz von Anwendung/PHP-FPM, OOM, erschöpfte Datenbank, WAF blockiert Proxy-/Crawler-IP-Adressen). Gleichen Sie Header, Trace-IDs und zeitgestempelte Logs auf beiden Seiten eines Hops ab, bevor Sie die ausgefallene Schicht bestimmen.
• Die Behebung ist nicht für alle gleich. Die Search Console meldet 502 erst im Nachhinein und kann ihn nicht beheben. Besucher können ihn ebenfalls nicht beheben; Websitebetreiber ohne Infrastrukturzugriff sollten eskalieren, statt Konfigurationen zu ändern. Potenziell störende Eingriffe — WAF-Allowlisting sowie Firewall- oder Proxy-Änderungen — sollten auf Logs oder Anbieterbelegen beruhen und nicht auf einer ersten Vermutung. Wenn nur Googlebot oder nur Anfragen über das CDN 502 erhalten, vermuten Sie eine botspezifische Blockierung und keinen globalen Ausfall.\nproxy_pass

Offizielle Dokumentation

Primärquellen dazu, wie Suchmaschinen mit 5xx-Fehlern einschließlich 502 umgehen.

Google

• Wie HTTP-Statuscodes die Crawler von Google beeinflussen — die maßgebliche Dokumentation; führt 502 (bad gateway) zusammen mit 500 und 503 auf und beschreibt die gemeinsame Behandlung von Crawl-Rate und Indexierung.
• So gehen Sie mit einer geplanten Ausfallzeit der Website um — warum 503 (nicht 502, 404 oder 200) der richtige Code für beabsichtigte Ausfallzeiten ist, mit einem Retry-After-Header. Nützlich für die Unterscheidung zwischen 502 und 503.
• robots.txt-Spezifikation — Umgang mit Serverfehlern — wie Google einen 5xx-Fehler in der robots.txt-Datei selbst behandelt.\n502 (bad gateway) Retry-After

Spezifikation

• RFC 9110 §15.6.3 — 502 (Bad Gateway) — die Definition auf Spezifikationsebene: Ein Gateway oder Proxy erhält von einem vorgelagerten Server, den es zur Erfüllung der Anfrage kontaktiert hat, eine ungültige Antwort. Sie bezeichnet die Grenze, an der ein Fehler beobachtet wurde, nicht den verursachenden Hop.

Bing / Microsoft

• Bing Webmaster Tools — Help Center — Bing zeigt serverseitige Crawl-Probleme (5xx-Klasse), einschließlich Verbindungsfehlern, in seinen Berichten zu Crawl-Fehlern.

Zitate aus der Quelle

Aufzeichnungen von Google und John Mueller. Jeder Link führt direkt zur zitierten Passage.

Google — Umgang mit 5xx (einschließlich 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.” (Übersetzung) „5xx- und 429-Serverfehler veranlassen Googles Crawler, das Crawling vorübergehend zu verlangsamen. Für die Google-Suche bleiben bereits indexierte URLs zunächst im Index erhalten, werden aber schließlich entfernt.“ — Google Search Central, How HTTP status codes affect Google’s crawlers. Zum Zitat springen
• “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.” (Übersetzung) „Google senkt die Crawl-Rate der Website. Die Senkung der Crawl-Rate ist proportional zur Zahl der einzelnen URLs, die einen Serverfehler zurückgeben. Für die Google-Suche entfernt Googles Indexierungspipeline URLs, die dauerhaft einen Serverfehler zurückgeben, aus dem Index.“ — dasselbe Dokument, die Tabellenzeile für 500, 502 und 503. Zum Zitat springen
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (Übersetzung) „Sobald der Server wieder mit einem 2xx-Statuscode antwortet, erhöht Google die Crawl-Rate der Website schrittweise.“ — dasselbe Dokument. Zum Zitat springen

John Mueller, Google (Bluesky, 18. November 2025 — Antwort in einem Thread zur 5xx-Spitze beim Cloudflare-Ausfall)

• “Yeah. 5xx = Google crawling slows down, but it’ll ramp back up.” (Übersetzung) „Ja. 5xx = Google crawlt langsamer, aber die Rate wird wieder hochgefahren.“ Beitrag ansehen
• “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.” (Übersetzung) „Wenn es mehrere Tage bei 5xx bleibt, kann es sein, dass Dinge allmählich herausfallen, aber selbst dann kommen sie ziemlich schnell wieder zurück.“ Über Matt G. Southerns Artikel im Search Engine Journal zum selben Austausch überliefert; vor einer endgültigen Verwendung gegen den Original-Thread prüfen. Berichterstattung lesen

Checkliste für 502 Bad Gateway

Wenn ein 502 im Browser, im Monitoring oder im Bericht zu Serverfehlern (5xx) der Search Console auftaucht, arbeiten Sie diese Liste ab. Rollenmarkierungen: [Alle] gilt unabhängig vom Infrastrukturzugriff; [Host/CDN/App-Verantwortliche] setzt Infrastrukturzugriff voraus.

• [Alle] Bestätigen Sie, dass der Fehler echt und aktuell ist — rufen Sie die URL jetzt erneut ab; ein Bericht zu Serverfehlern (5xx) kann hinter einem bereits behobenen Aussetzer zurückliegen.
• [Alle] Prüfen Sie den Umfang — eine URL, ein Abschnitt oder die gesamte Website? (Die Auswirkungen auf das Crawling skalieren mit der Zahl fehlerhafter URLs.)
• [Alle] Prüfen Sie die Statusseite Ihres CDN-/DNS-Anbieters auf einen anbieterweiten Ausfall, bevor Sie Ihre eigene Konfiguration ändern.
• [Host/CDN/App-Verantwortliche] Testen Sie direkt am Origin und über das CDN — wenn der Origin direkt 2xx antwortet, das CDN aber 502 zurückgibt, liegt das Problem am Edge oder dazwischen.
• [Host/CDN/App-Verantwortliche] Prüfen Sie, ob nur Bots oder Anfragen von CDN-IP-Adressen einen 502 erhalten, während Browser funktionieren — das deutet auf eine mögliche WAF-/Firewall-Blockierung hin, nicht auf einen Ausfall. Bestätigen Sie dies zuerst in den Firewall-/WAF-Logs; eine Allowlist ist keine allgemeine Lösung und darf erst auf Grundlage dieser Belege eingerichtet werden.
• [Host/CDN/App-Verantwortliche] Lesen Sie die Fehlerlogs des Proxys (Nginx/Apache/HAProxy) auf Upstream-Timeouts oder verweigerte Verbindungen.
• [Host/CDN/App-Verantwortliche] Lesen Sie die Origin-Logs auf Abstürze der Anwendung, OOM-Kills oder erschöpfte Datenbankverbindungen rund um die Zeitstempel.
• [Alle] Prüfen Sie mit dem Live-Test der GSC-URL-Prüfung, was Googlebot sieht.
• [Host/CDN/App-Verantwortliche] Wenden Sie die schichtspezifische Behebung erst an, wenn Logs/Anbieterbelege darauf hinweisen — WAF-, Firewall-, Timeout- und Proxy-Konfigurationsänderungen sind Infrastrukturänderungen und keine Vermutungen für die erste Reaktion.
• [Alle] Lassen Sie nach der Behebung die Erholung stattfinden — 2xx-Antworten lassen das Crawling schrittweise wieder ansteigen; Google veröffentlicht keinen genauen Zeitplan. Verwenden Sie “Fehlerbehebung validieren” nur für eine schnellere erneute Prüfung, nicht als “Behebung”.
• [Host/CDN/App-Verantwortliche] Stellen Sie künftig sicher, dass Sie für geplante Ausfallzeiten 503 (nicht 502) verwenden.

Ist mein 502 ein CDN-, Proxy- oder Origin-Problem?

Ein 502 ist ein Fehler zwischen Servern. Diagnostizieren Sie ihn daher, indem Sie den Stack abwärts gehen, statt zu raten. Beginnen Sie am Edge und gehen Sie nach innen.

Q1. Meldet Ihr CDN- oder DNS-Anbieter gerade einen Ausfall?

• Ja → Es handelt sich höchstwahrscheinlich um einen anbieterweiten Ausfall (der Cloudflare-Vorfall vom November 2025 ist das klassische Beispiel). Auf Ihrer Seite gibt es meist nichts zu beheben. Bestätigen Sie, dass Ihr Origin gesund ist, und warten Sie auf die Erholung — Googles Crawl-Rate steigt nach der Rückkehr von 2xx schrittweise wieder, auch wenn kein genauer Zeitplan veröffentlicht wird. Halten Sie hier an.
• Nein → Fahren Sie fort.

Q2. Antwortet der Origin bei einer direkten Anfrage (unter Umgehung von CDN/Proxy) mit 2xx?

• Nein — auch der Origin schlägt fehl → Das Problem liegt auf der Origin-Schicht. Prüfen Sie in den Logs Abstürze der Anwendung/PHP-FPM, OOM-Kills, erschöpfte Datenbankverbindungen oder ein fehlerhaftes Deployment. Je nachdem, wie der Proxy es sieht, erscheint dies häufig auch als 500 oder 504. Halten Sie hier an.
• Ja — der Origin ist direkt gesund, aber CDN/Proxy gibt 502 zurück → Fahren Sie fort. Der Origin ist in Ordnung; eine vorgeschaltete Komponente kann keine gültige Antwort erhalten.\n2xx

Q3. Funktionieren normale Browser, während nur Googlebot-/CDN-IP-Adressen 502 erhalten?

• Ja → Vermuten Sie eine WAF- oder Firewall-Blockierung, die Proxy- oder Crawler-IP-Bereiche als Angreifer behandelt. Bestätigen Sie dies zuerst in den Firewall-/WAF-Logs und setzen Sie erst dann legitime CDN- und verifizierte Crawler-IP-Bereiche auf die Allowlist — nicht ohne diese Bestätigung. Halten Sie hier an.
• Nein — alle erhalten über den Proxy 502 → Fahren Sie fort.

Q4. Was zeigen die Reverse-Proxy-Logs für Upstream?

• Timeout / Verbindung verweigert → Der Proxy kann das Backend erreichen, erhält aber keine rechtzeitige gültige Antwort → Problem mit Backend-Kapazität oder Timeout (Pool erschöpft, Timeouts zu knapp). Erhöhen Sie Kapazität/Timeouts oder beheben Sie das langsame Backend.
• Falscher Host / DNS-/SSL-Handshake-Fehler zu Upstream → Fehlkonfiguration des Proxys → Korrigieren Sie die proxy_pass-/Upstream-Definition oder die TLS-Konfiguration zwischen Proxy und Backend.\nproxy_pass

Unabhängig von der Schicht ist die SEO-Bereinigung gleich und weitgehend automatisch. Sobald die URLs 2xx zurückgeben, setzt Google das Crawling selbstständig fort — eine erneute Übermittlung ist nicht nötig.\n2xx

502-Mythen und Fehler, die Sie vermeiden sollten

• Mythos: “502 ist ein Google-/SEO-Problem, das ich in der Search Console behebe.” Nein. Ein 502 ist ein Hosting-/Infrastrukturfehler; die Search Console meldet ihn erst im Nachhinein. Die Behebung liegt bei CDN, Proxy oder Origin. “Fehlerbehebung validieren” bittet Google nur um eine erneute Prüfung — es repariert nichts.
• Mythos: “A 502 always means my server is down.” (Übersetzung) „Ein 502 bedeutet immer, dass mein Server ausgefallen ist.“ Nein. Der Origin kann auf eine direkte Anfrage 2xx zurückgeben, während Besucher über das CDN einen 502 sehen — wegen eines Timeouts, einer falschen Upstream-Konfiguration oder eines eigenen CDN-Ausfalls. Testen Sie direkt am Origin, bevor Sie von einem Absturz Ihres Servers ausgehen.
• Mythos: “502 ist für SEO weniger ernst als 500.” Nein. Googles Dokumentation gibt 500, 502 und 503 dieselbe Reduzierung der Crawl-Rate und bei anhaltenden Fehlern dieselbe mögliche Entfernung aus dem Index. Für 502 gibt es keine dokumentierte mildere Behandlung.
• Mythos: “Ein einmaliger 502 entfernt meine Seite aus dem Index.” Nein. Das Crawling wird langsamer und steigt dann wieder an. Für das Herausfallen aus dem Index muss der Fehler anhaltend sein — Google verwendet dieses Wort, ohne eine konkrete Zahl von Tagen zu nennen. Muellers informelle Bemerkung vom November 2025 ordnete es bei mehreren Tagen ein und ergänzte, dass entfernte Seiten “ziemlich schnell wiederkommen” — behandeln Sie das als Einschätzung eines Praktikers zu einem Vorfall, nicht als offiziellen Schwellenwert.
• Mythos: “502 und 503 bedeuten dasselbe.” Nein. 503 ist der beabsichtigte Code “Service Unavailable”, den Sie für geplante Wartung (mit Retry-After) verwenden sollten; 502 ist ein unbeabsichtigter Proxy-Fehler. Wer sie im Monitoring gleichsetzt, versteckt echte Vorfälle hinter erwarteten Wartungsfenstern.
• Mythos: “Das Leeren des Browser-Caches behebt einen websiteweiten 502.” Dieser Rat betrifft einen Besucher, der seine eigene Ansicht untersucht. Wenn CDN, Proxy oder Origin tatsächlich ausfallen, ändert keine browserseitige Aktion etwas für andere.
• Anti-Pattern: reflexartig “Fehlerbehebung validieren” anklicken und die Search Console aktualisieren. Bei einer vorübergehenden Spitze (oder einem CDN-Ausfall) ist es oft am schnellsten und richtigsten, nur die Erholung zu bestätigen. Google erledigt das schrittweise Wiederhochfahren automatisch.\n2xx Retry-After

Incident-Playbook: Die Website gibt 502 zurück

1. Umfang bestätigen. Prüfen Sie eine betroffene URL mit dem Website Down Checker und testen Sie anschließend mehrere URLs mit dem Bulk HTTP Status Code Checker. Wenn nur Ihr Browser fehlschlägt, beheben Sie zunächst das lokale Netzwerk- oder DNS-Problem, bevor Sie einen websiteweiten Vorfall eskalieren. Wenn viele öffentliche URLs 502 zurückgeben, fahren Sie fort.
2. Fehlerhafte Antwort aufzeichnen. Speichern Sie Zeitpunkt, URL, Status, Response-Header und eine etwaige CDN-Request-ID. Ist der Fehler intermittierend, wiederholen Sie die Anfrage, statt einen einzelnen erfolgreichen Versuch als Erholung zu werten.
3. Gateway identifizieren — Marke als Signal, nicht als Beweis behandeln. Lesen Sie Header und die gebrandete Fehlerseite auf Hinweise zu CDN, Reverse Proxy oder Load Balancer, bestätigen Sie diese aber anhand der Statusseite des Anbieters und Ihrer Logs, bevor Sie schlussfolgern, welcher Hop fehlgeschlagen ist; gebrandete Seiten und Header sind anbieterspezifisch und beweisen die Ursache nicht allgemein. Meldet der Anbieter einen Ausfall, folgen Sie seinem Incident-Pfad; andernfalls gehen Sie weiter zum Origin.
4. Edge und Origin vergleichen. Rufen Sie den öffentlichen Hostnamen normal ab und senden Sie denselben Hostnamen anschließend mit curl --resolve direkt an die bekannte Origin-IP. Wenn der Origin erfolgreich antwortet, während der Edge 502 liefert, prüfen Sie die Verbindung vom CDN zum Origin, TLS und die Proxy-Konfiguration. Wenn beide fehlschlagen, gehen Sie zu den Anwendungs- und Origin-Logs.
5. Logs nach Zeitstempeln korrelieren. Eine verweigerte Verbindung oder ein TLS-Fehler weist auf die Grenze zwischen Gateway und Origin hin; eine fehlerhafte oder abrupt geschlossene Upstream-Antwort weist auf den Origin-Dienst hin. Beheben Sie die fehlerhafte Schicht, nicht die Search Console.
6. Erholung verifizieren. Wiederholen Sie die Prüfungen sowohl öffentlich als auch direkt am Origin für repräsentative URLs. Wenn 2xx-Antworten stabil sind, beobachten Sie Logs und Search Console, während Googlebot das Crawling automatisch wieder aufnimmt. Kehren 502s zurück, gehen Sie mit den neuen Zeitstempeln zu Schritt 4 zurück, statt blind die Zahl der Wiederholungen zu erhöhen.\ncurl --resolve

Prompt: Eine Gruppe von 502-Fehlern nach Schicht klassifizieren

Fügen Sie eine CSV mit URL, Zeitstempel, Status, Response-Headern, Ergebnis am öffentlichen Edge, Ergebnis am direkten Origin und jedem passenden Logauszug ein. Entfernen Sie vorher Geheimnisse, Cookies, Authorization-Header und private Origin-Adressen.

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]

Erwarten Sie eine Triage-Warteschlange, keinen definitiven Bericht zur Grundursache. Prüfen Sie jede vorgeschlagene Kontrolle anhand aktueller Header und Logs.

Den öffentlichen 502 reproduzieren

Führen Sie dies in einer macOS-/Linux-Shell aus. Der Befehl gibt Response-Header aus, ohne den Body herunterzuladen, und folgt keinen Weiterleitungen, sodass Sie die erste Antwort sehen.

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

PowerShell-Äquivalent:

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

Wenn die Anwendung HEAD anders behandelt, verwenden Sie einen normalen GET und verwerfen Sie den Body:\nHEAD GET

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

Die CDN-Route mit dem bekannten Origin vergleichen

Ersetzen Sie 203.0.113.10 durch eine Origin-IP, die Sie kontrollieren. —resolve behält den öffentlichen Hostnamen für den HTTP-Host-Header und den TLS-Namen bei, während die Verbindung zu dieser IP hergestellt wird.\n203.0.113.10 --resolve

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

Legen Sie einen geschützten Origin nicht offen und schwächen Sie seine Firewall nicht nur für diesen Test. Führen Sie ihn aus einem bereits autorisierten Netzwerk aus. Ein öffentlicher 502 bei gleichzeitigem Erfolg am direkten Origin grenzt den Fehler auf den CDN-/Proxy-Pfad ein; ein Fehler auf beiden Pfaden weist auf den Origin oder die Anwendung hin.

Werkzeuge zum Eingrenzen eines 502

• Website Down Checker — bestätigt, ob die URL von einer externen Cloudflare-Ansicht aus erreichbar ist, und erfasst Timing, Weiterleitungen und begrenzte DNS-Belege. Er beantwortet “passiert das nur mir?”, bevor Sie Infrastruktur ändern.
• Bulk HTTP Status Code Checker — testet eine repräsentative URL-Menge, zeigt vollständige Weiterleitungspfade und Latenz und exportiert Ergebnisse. Verwenden Sie ihn, um einen Fehler auf einer einzelnen Route von einem umfassenderen 502-Vorfall zu trennen.
• Ihr CDN- oder Load-Balancer-Dashboard — gleichen Sie Request-IDs und Zeitstempel der fehlerhaften Antwort mit Edge-Logs und dem Status des Anbieters ab.
• Anwendungs- und Serverlogs des Origins — bestätigen Sie, ob der Upstream die Anfrage akzeptiert und ob er die Antwort zurückgegeben, zurückgesetzt oder fehlerhaft formatiert hat. Dadurch wird aus einer Hypothese über die Schicht eine Grundursache.

Kein Tool kann allein anhand von 502 die fehlerhafte Schicht bestimmen. Vergleichen Sie Belege vom öffentlichen Edge mit einer autorisierten direkten Origin-Anfrage und zeitgestempelten Logs.\n502

Testen Sie Ihr Wissen: 502 Bad Gateway

Fünf kurze Fragen dazu, was ein 502 ist und wie er SEO beeinflusst. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend Ihre Auswahl.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte

• Umfassender Leitfaden zu HTTP-Statuscodes für SEO — wo 502 und der Rest der 5xx-Familie einzuordnen sind und was die einzelnen Codes für Suchmaschinen signalisieren.
• Der Einsteigerleitfaden für technisches SEO — wie Servergesundheit und Crawling mit dem größeren Zusammenhang verbunden sind.
• robots.txt und SEO: Alles, was Sie wissen müssen — relevant, weil ein 5xx-Fehler in Ihrer robots.txt-Datei speziell behandelt wird.

Aus der Branche

• Wie HTTP-Statuscodes Googles Crawler beeinflussen (Google Search Central) — die Primärquelle: 502 (bad gateway) wird mit 500/503 gruppiert, einschließlich der genauen Aussagen zu Crawl-Rate und Indexierung.
• Umgang mit geplanter Website-Ausfallzeit (Google Search Central) — die Unterscheidung zwischen 503 und 502 und warum 503 der Code für absichtliche Ausfallzeiten ist.
• Cloudflare-Ausfall löst 5xx-Spikes aus: Was das für SEO bedeutet (Matt G. Southern, Search Engine Journal) — der Ausfall vom November 2025 als Praxisbeispiel mit Muellers Kommentaren.
• 502 Bad Gateway: MDN-Referenz (MDN Web Docs) — die neutrale Definition auf Spezifikationsebene.
• RFC 9110 §15.6.3 — 502 (Bad Gateway) (IETF) — die zugrunde liegende HTTP-Semantikspezifikation.
• So beheben Sie einen 502-Bad-Gateway-Fehler (Kinsta) — ein ausführlicher Troubleshooting-Ablauf aus Sicht des Hosters für Browser- und Websitebetreiber-Behebungen.
• 502 Bad Gateway: Bedeutung und Behebung für Webentwickler (Webflow) — ein auf Entwickler ausgerichteter Überblick über Ursachen und Behebungen.\n502 (bad gateway)

Änderungsprotokoll