504 Gateway Timeout: Bedeutung und Diagnose

TL;DR — Ein 504 Gateway Timeout bedeutet, dass etwas vor Ihrer Website — ein CDN, Load Balancer oder Proxy — auf eine Antwort Ihres Servers gewartet und aufgegeben hat, weil sie zu lange dauerte. Es ist ein Timeout, keine fehlerhafte Antwort. Ein einzelner 504 ist unproblematisch; problematisch wird es, wenn er immer wieder auftritt, weil Suchmaschinen Ihre Website dann seltener crawlen und Seiten schließlich aus dem Index entfernen können.

Was ein 504 tatsächlich bedeutet

Wenn Sie eine Seite laden, erreicht die Anfrage Ihren Webserver oft nicht direkt. Sie läuft normalerweise zuerst über ein Gateway — ein CDN, einen Load Balancer oder einen Reverse Proxy. Dieses Gateway leitet die Anfrage an den dahinterliegenden Server (den Upstream oder Origin) weiter, wartet auf eine Antwort und gibt sie an Sie zurück.

Ein 504 Gateway Timeout ist die Antwort des Gateways, wenn es auf die Upstream-Antwort gewartet und innerhalb der vorgesehenen Zeit keine erhalten hat. Der Origin kann eine Datenbankabfrage langsam ausführen, auf eine API eines Drittanbieters warten oder schlicht überlastet sein — aus Sicht des Gateways ist aber die Zeit abgelaufen. Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

Das entscheidende Wort ist Timeout. Es war nicht unbedingt etwas “kaputt”. Die Antwort ist einfach nicht schnell genug eingetroffen.

Wie er sich von seinen 5xx-Geschwistern unterscheidet

Diese Fehler werden ständig verwechselt:

• 502 Bad Gateway — das Gateway hat eine Antwort vom Origin erhalten, aber sie war ungültig oder fehlerhaft.
• 503 Service Unavailable — der Server hat ausdrücklich gesagt: “Ich bin gerade nicht verfügbar” (oft absichtlich, etwa während eines Wartungsfensters).
• 504 Gateway Timeout — das Gateway hat vom Upstream keine rechtzeitige Antwort erhalten. Das ist eine engere Aussage als “es kam überhaupt nichts zurück” — der Upstream kann noch daran arbeiten, hat aber innerhalb des Wartefensters nicht geantwortet.

Ein 504 ist daher fast immer ein Performance-Symptom: Etwas im Upstream ist zu langsam.

Schadet ein 504 meiner SEO?

Nicht direkt, und es ist keine Strafe. Google bewertet Ihren Inhalt nicht — Google kann die Seite schlicht nicht abrufen. Es gibt aber einen echten indirekten Preis:

• Wenn Googlebot weiterhin auf langsame Antworten und Timeouts stößt, zieht er sich zurück und crawlt Ihre Website seltener, damit die Überlastung nicht noch schlimmer wird.
• Ein einzelner 504 während einer Verkehrsspitze wird erneut versucht und weitgehend ignoriert.
• 504s, die über Tage hinweg immer wieder auftreten, führen eher dazu, dass Seiten aus dem Index entfernt werden — weil Google sie nicht zuverlässig abrufen kann. Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

Was Sie dagegen tun können

• Laden Sie die Seite ein- oder zweimal neu — ein einzelner 504 kann nur ein kurzer Aussetzer sein.
• Prüfen Sie Server- und Fehlerlogs, um zu sehen, was langsam war (Datenbankabfrage, externe API oder überlasteter Anwendungsprozess).
• Erhöhen Sie nicht einfach den Timeout-Wert und erklären Sie die Sache damit für erledigt — das versteckt die langsame Antwort, statt sie zu beheben (mehr dazu auf der Registerkarte Fortgeschritten).
• Halten Sie Ihren Server schnell: Caching, schnellere Abfragen und ausreichende Kapazität sind die eigentliche Vorbeugung.

Möchten Sie die vollständige technische Version — wo ein 504 in der Anfragekette entsteht, wie Googles Crawl-Drosselung funktioniert und warum TTFB die entscheidende Kennzahl ist? Wechseln Sie zur Registerkarte Fortgeschritten.

TL;DR — Ein 504 ist das Signal eines Gateways/Proxys, dass der Upstream-Server innerhalb des Timeout-Fensters nicht geantwortet hat — ein Timeout, der sich von 502 (schlechte Antwort) und 503 (ausdrückliche Nichtverfügbarkeit) unterscheidet. Es ist ein Zugriffsproblem, keine Strafe. Timeouts stehen in derselben Gruppe wie 429/500/503: Googlebot zieht sich bei ihnen zurück, und anhaltende 504s bergen Deindexierungsrisiko. Die dauerhafte Behebung ist eine bessere Serverantwortzeit (TTFB), nicht ein längerer Timeout-Wert — ein höherer Timeout maskiert meist den langsamen Upstream und kann die Lage unter Last verschlimmern.

Wo ein 504 in der Anfragekette entsteht

Ein moderner Anfragepfad sieht ungefähr so aus: Browser → CDN/Edge → Load Balancer → Reverse Proxy (z. B. Nginx) → Anwendungsserver (PHP-FPM, Node usw.) → Datenbank / APIs von Drittanbietern. Ein 504 wird von der Komponente erzeugt, die beim Ablauf ihres Timeouts gerade auf die dahinterliegende Komponente gewartet hat. Das ist die erste Diagnosefrage: Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

• CDN/Edge wartet auf den Origin → Die Behebung ist bessere Origin-Performance oder eine vorsichtige Erhöhung des Upstream-Timeouts des CDN (siehe unten).
• Load Balancer wartet auf den Anwendungsserver → Prüfen Sie die Gesundheit des Anwendungsservers und die automatische Skalierung.
• Reverse Proxy wartet auf den Anwendungsprozess → Prüfen Sie Nginx’ proxy_read_timeout / fastcgi_read_timeout und die langsame Abfrage oder den Prozess, der tatsächlich dahinterliegt.

Die richtige Schicht zu bestimmen ist wichtig, denn “den Timeout am Edge beheben” und “die langsame Datenbankabfrage am Origin beheben” sind völlig unterschiedliche Aufgaben.

Was 504s verursacht

Der Statuscode selbst beweist keine Ursache — er sagt nur, dass ein Gateway beim Warten auf einen Upstream ein Timeout erreicht hat. Das sind die üblichen Verdächtigen, die Sie prüfen sollten, nicht bereits durch den 504 bewiesene Tatsachen; bestätigen Sie eine Vermutung mit Logs und Traces, bevor Sie handeln:

• Langsame Datenbankabfragen oder Upstream-API-Aufrufe. Eine einzelne nicht indexierte Abfrage oder eine langsame Abhängigkeit eines Drittanbieters kann die Antwortzeit über den Timeout drücken.
• Überlastung des Servers/der Anwendung und Ressourcenerschöpfung. Bei genügend gleichzeitiger Last reihen sich Anfragen ein, Worker-Prozesse füllen sich und Antworten treffen nicht mehr rechtzeitig ein.
• Falsch konfigurierte Timeout-Werte über Nginx, Apache, Load Balancer oder CDN — oft zwischen Schichten nicht abgestimmt, sodass eine Schicht vor einer anderen aufgibt.
• Verkehrsspitzen, Bot-Fluten oder DDoS, welche die Kapazität vorübergehend überfordern.

504s treten oft intermittierend und lastabhängig auf

Das macht sie so tückisch. Anders als bei einem harten Ausfall erscheint ein 504 häufig nur unter Last — ein Uptime-Monitor, der in einem ruhigen Zeitfenster anfragt, kann 100 % grün anzeigen, während Googlebot bei seinen stärkeren Crawl-Schüben unbemerkt Timeouts sammelt. In der URL-Prüfung der Google Search Console kann dies als “Hostload exceeded” erscheinen und nicht als sauberer, dauerhafter Fehler. Wenn Ihr Monitoring alles in Ordnung meldet, die Crawling-Statistiken aber nicht, sind lastabhängige 504s ein naheliegender Verdacht.

Wie Googlebot (und Bingbot) mit Timeouts umgehen

Google behandelt einen 504 nicht als Bewertung der Inhaltsqualität — er ist ein Verfügbarkeits-Signal, und die Reaktion ist eine automatische Drosselung. Googles Crawling-Dokumentation ist eindeutig: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (Übersetzung) „Googlebot reduziert seine Crawling-Aktivität, wenn er feststellt, dass Ihre Server Probleme haben, Crawling-Anfragen zu beantworten.“ Der Leitfaden zum Crawl-Budget großer Websites sagt dasselbe in Budget-Begriffen: “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (Übersetzung) „Wird die Website langsamer oder antwortet sie mit Serverfehlern, sinkt das Limit und Google crawlt weniger.“ Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

Die aktuellste Darstellung, die dies direkt mit langsamen oder ablaufenden Antworten verbindet, stammt aus Googles Inside Googlebot-Erklärung vom März 2026. Dort wird Gary Illyes zitiert: “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (Übersetzung) „Wenn Ihr Server nur mit Mühe Daten ausliefert, ziehen sich unsere Crawler automatisch zurück, um Ihre Infrastruktur nicht zu überlasten; dadurch nimmt die Crawling-Häufigkeit ab.“ (So berichtet es Search Engine Land — wenn Sie es anderswo zitieren, sollten Sie es anhand der Originalaufnahme oder des Transkripts bestätigen.) Ein 504 macht dieses Problem sichtbar.

Eine wichtige Nuance: Google sieht nicht immer einen wörtlichen “504”, wie ihn Ihr Browser anzeigt. Wenn der Timeout eintritt, bevor Googlebot überhaupt eine Statuszeile erhält, wird er in den Crawling-Statistiken als Timeout/Netzwerkfehler statt als sauberer 5XX protokolliert. Wenn aber ein zwischengeschalteter Proxy oder ein CDN den eigenen 504 erzeugt, erhält Googlebot einen standardmäßigen 5xx-Serverfehler. Die Wirkung ist in beiden Fällen gleich: gedrosselte Crawl-Rate und bei anhaltendem Auftreten Entfernung aus dem Index.

Bing führt Timeouts als eigene Crawl-Fehlerkategorie getrennt von Serverfehlern. Bingbot hört auf, Seiten abzurufen, wenn Antworten zu langsam sind; die ständige Empfehlung lautet, die Serverantwortzeit zu prüfen, Serversoftware aktuell zu halten, langsame Ressourcen zu optimieren und Serverlogs auf systematische Muster statt einzelne Aussetzer zu untersuchen. Bing hat nicht dieselbe Detailtiefe zu Drosselung und Erholung wie Google veröffentlicht. Behandeln Sie beide daher hinsichtlich der Absicht als grob vergleichbar, nicht als nachweislich identisch.

Die Rückkopplungsschleife: drosseln, dann erholen

Der beruhigende Teil: Diese Schleife ist automatisch und selbstkorrigierend. Google drosselt, wenn es Fehler und Timeouts sieht, und fährt das Crawling schrittweise wieder hoch, sobald die Antworten wieder gesund sind. Sobald die zugrunde liegende Ursache behoben ist, müssen Sie keine manuelle Schaltfläche zum “Entdrosseln” drücken — John Mueller sagte dazu: “Once things settle down on the server, the crawl rate will return to normal automatically.” (Übersetzung) „Sobald sich die Lage auf dem Server beruhigt hat, kehrt die Crawling-Rate automatisch zum Normalzustand zurück.“ Er wies auch auf die Asymmetrie hin: Das Herunterdrosseln geschieht schnell, um ein akutes Problem zu entschärfen; das Hochfahren erfolgt vorsichtig.

Die Dauer macht aus einem Aussetzer ein Indexierungsproblem

Kurze, gelegentliche 504s — einige während einer Spitze, schnell behoben — werden erneut versucht und weitgehend toleriert. Das Deindexierungsrisiko entsteht durch ein anhaltendes Muster von Timeouts über ein längeres Zeitfenster. Googles dokumentierte “später wiederkommen”-Mechanik, bei der Sie bei Überlastung absichtlich 503 oder 429 zurückgeben, nennt einen Horizont von ungefähr zwei Tagen, bevor URLs zu fallen beginnen; diese konkrete Zahl ist aber ausdrücklich für 503/429 dokumentiert, nicht für 504. Die allgemeine 5xx-Richtlinie von Google sagt, dass die Crawl-Rate proportional zur Zahl fehlerhafter URLs sinkt und sich nach gesunden Antworten schrittweise erholt, ohne einen festen Zeitraum speziell für 504 zu nennen. Die Übertragung der Zwei-Tage-Zahl auf 504 ist eine vernünftige Schlussfolgerung, keine dokumentierte Tatsache — verstehen Sie es so: Kurze 504s sind verkraftbar, und ein über Tage anhaltendes Muster ist der Bereich, in dem Sie sich Sorgen machen sollten, nicht ein garantiertes Auslösedatum.

Warum das bei großen und E-Commerce-Websites wichtiger ist

Bei einer kleinen Website, deren Seiten noch am selben Tag ihrer Veröffentlichung gecrawlt werden, bemerken Sie das fast nie. Bei großen oder schnell veränderlichen Websites — großen E-Commerce-Katalogen, Nachrichten- und Marktplatzseiten — ist das Crawl-Budget jedoch bereits der Engpass. Eine Welle von 504s während der Spitzenlast kann das Crawling von Seiten blockieren, die tatsächlich erneut gecrawlt werden müssten. Timeouts und Crawl-Budget sind im großen Maßstab dasselbe Thema.

Serverantwortzeit und TTFB sind ein wirksamer Hebel zur Vorbeugung — bei Ursachen am Origin

Hier liegt ein Punkt, den die meisten 504-Artikel übersehen: Erst beim Auftreten von Fehlern zu reagieren und dann Logs zu durchsuchen, ist reaktiv. Die Serverantwortzeit kontinuierlich zu überwachen, damit Sie die Verschlechterung sehen, bevor sie in einen Timeout kippt, ist proaktiv. Ein Server, der heute langsam, aber noch nicht im Timeout ist, erzeugt morgen unter etwas mehr Last oder einer etwas langsameren Abhängigkeit 504s. Wenn Sie TTFB (Time to First Byte) als fortlaufendes Frühwarnsignal beobachten — nicht nur als Kennzahl nach dem Vorfall — erkennen Sie diese Verschlechterung rechtzeitig.

Die Einschränkung: TTFB-Monitoring erfasst Langsamkeit am Origin. Es erkennt nicht, dass ein CDN bei einem gesunden Origin einen Timeout erreicht, ein Load Balancer zu früh aufgibt oder ein Netzwerkpfad zwischen Hops gestört ist — dafür muss zuerst der auslösende Hop bestimmt werden (der Abschnitt “Wo ein 504 entsteht” oben oder der Entscheidungsbaum unten). TTFB ist eine echte, dauerhafte Lösung für den häufigen Fall eines wirklich langsamen Upstreams, aber keine universelle. Sobald Sie den Origin als Engpass bestätigt haben, optimieren Sie mit Seiten-, Objekt- und CDN-Caching, schnelleren Datenbankabfragen und passenden Indizes, automatischer Skalierung und sinnvoller Upstream-Konfiguration des CDN.

Warum “einfach den Timeout erhöhen” der falsche Reflex ist

Das Erhöhen von proxy_read_timeout oder des Upstream-Timeouts des CDN kann verhindern, dass der 504 angezeigt wird — aber die Upstream-Antwort wird dadurch nicht schneller. Unter Last bedeutet ein längeres Timeout-Fenster außerdem, dass sich Anfragen aufstauen und Worker-Prozesse sowie Verbindungen länger binden. Das kann eine Überlastungsspirale verschlimmern statt verbessern. Eine Erhöhung des Timeouts kann für einen wirklich lang laufenden, gut verstandenen Vorgang gelegentlich richtig sein, als Reflex maskiert sie aber das eigentliche Problem.

Wenn die Ausfallzeit geplant ist oder Sie Last absichtlich abwerfen, ist es nicht richtig, Seiten 504 liefern zu lassen. Geben Sie stattdessen 503 (mit einem Retry-After-Header) zurück, damit Sie Suchmaschinen ein sauberes, beabsichtigtes “kommen Sie später wieder” statt eines chaotischen Timeouts senden.

Einen 504 in der Praxis diagnostizieren

Bestimmen Sie den antwortenden Hop, bevor Sie eine Ursache vermuten — das entscheidet darüber, ob Sie das tatsächliche Problem oder nur ein Symptom beheben:

• Reproduzieren und den antwortenden Hop bestimmen. Laden Sie die Seite im Browser, rufen Sie diese mit curl ab und beobachten Sie time_starttransfer für TTFB, und lassen Sie einen Crawler wie Ahrefs Site Audit oder Screaming Frog prüfen, ob der Fehler die gesamte Website oder nur einzelne URLs betrifft. Testen Sie, wenn möglich, direkt am Origin (unter Umgehung von CDN/Proxy), um festzustellen, ob der Origin selbst fertig wird.
• Logs lesen. Server- und Proxy-Logs zeigen, welche Schicht den Timeout erreicht hat und idealerweise worauf sie wartete — langsame Abfrage, festhängender Upstream oder erschöpfter Worker-Pool. Korrelieren Sie Zeitstempel und Request-ID über Schichten hinweg, statt etwas anzunehmen.
• Search Console prüfen. Die Crawling-Statistiken zeigen Spitzen bei Antwortcodes und der durchschnittlichen Antwortzeit; der Bericht zur Seitenindexierung und die URL-Prüfung zeigen, ob Google auf Timeouts (einschließlich “Hostload exceeded”) stößt.

Werkzeuge abzugleichen ist wichtig: Ein 504 im Browser, ein 5xx in Ahrefs Site Audit und ein Timeout in der GSC können dasselbe zugrunde liegende Problem eines langsamen Origins aus verschiedenen Blickwinkeln beschreiben. Gehen Sie nicht davon aus, dass drei Tools drei Probleme bedeuten.

Verwandte Codes

Ein 504 gehört zu einer kleinen Familie. Ein 500 ist ein allgemeiner Serverfehler ohne spezifischeren Code; ein 502 ist eine schlechte oder fehlerhafte Upstream-Antwort; ein 503 ist eine ausdrücklich, oft absichtlich gemeldete “Nichtverfügbarkeit”. Zu wissen, welchen Code Sie tatsächlich zurückgeben — und bei geplanter Wartung absichtlich den richtigen zu verwenden — ist die halbe Lösung.

KI-Zusammenfassung

Eine komprimierte Zusammenfassung der Advanced-Version:

• Ein 504 = ein Timeout, keine fehlerhafte Antwort. Ein Gateway/Proxy (CDN, Load Balancer oder Reverse Proxy) hat auf den Upstream-Server gewartet und keine rechtzeitige Antwort erhalten — nicht unbedingt “nie eine Antwort”. Er unterscheidet sich von 502 (schlechte Antwort) und 503 (ausdrückliche Nichtverfügbarkeit). Der Statuscode allein beweist weder den betroffenen Hop noch die Ursache; bestimmen Sie den auslösenden Hop, bevor Sie etwas beheben.
• Es ist keine Strafe. Es ist ein Zugriffsproblem — Google kann die Seite nicht abrufen; ein Verlust bei Ranking/Indexierung ist eine Folge der Nichtverfügbarkeit und keine Bestrafung.
• Timeouts lösen eine Crawl-Drosselung aus. Google: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding.” (Übersetzung) „Googlebot fährt das Crawling zurück, wenn er erkennt, dass Ihre Server Schwierigkeiten mit Antworten haben.“ Gary Illyes wird (über Search Engine Lands Berichterstattung vom März 2026) mit den Worten zitiert, dass sich Crawler “automatically back off … which will drop your crawl frequency.” (Übersetzung) „automatisch zurückziehen … wodurch die Crawling-Häufigkeit sinkt“.
• Die Dauer ist wichtig, aber die Zahl “2 Tage” ist für 504 nicht Googles dokumentierte Zahl. Dieser Horizont ist für absichtlich zurückgegebene 503/429 bei Überlastung dokumentiert. Googles breitere 5xx-Richtlinie sagt, dass die Crawl-Rate proportional sinkt und sich schrittweise erholt, ohne einen festen Zeitraum speziell für 504 zu nennen — einzelne 504s werden erneut versucht und toleriert; ein anhaltendes Muster über längere Zeit ist der Bereich mit Deindexierungsrisiko.
• Die Schleife korrigiert sich selbst. Sobald sich die Antworten erholen, kehrt die Crawl-Rate automatisch zurück — ein manuelles Entdrosseln ist nicht nötig.
• Oft intermittierend und lastabhängig — für Uptime-Monitore in ruhigen Zeitfenstern unsichtbar; in der URL-Prüfung kann “Hostload exceeded” erscheinen.
• Serverantwortzeit (TTFB) ist bei Ursachen am Origin ein wirksamer Hebel zur Vorbeugung, wenn sie als Frühwarnsignal überwacht wird — aber keine universelle Lösung: Ein 504 kann auch an CDN-, Load-Balancer- oder Proxy-Schicht entstehen. Bestimmen Sie daher zuerst, welcher Hop das Timeout erreicht. Ein höherer Timeout-Wert ist in keinem Fall automatisch eine Lösung — er maskiert den langsamen Upstream und kann die Überlastung verschlimmern.
• Bei geplanter Ausfallzeit geben Sie 503 mit Retry-After zurück, nicht 504.

Offizielle Dokumentation

Primärquellen zu Timeouts, Serverfehlern und der Reaktion von Crawlern.

Definition

• MDN — 504 Gateway Timeout — die maßgebliche Definition des Statuscodes und seine Abgrenzung zu 502.

Google

• Crawling-Fehler beheben — wie Googlebot bei Serverproblemen zurückfährt und wann bei Überlastung 503/429 zurückgegeben werden sollten.
• Crawl-Budget optimieren — wie langsame Antworten und Serverfehler das Crawl-Limit senken.
• Crawl-Stats-Bericht — die Kategorien “Server error (5XX)” und “Page timeout” und wie Googlebot zur Vermeidung von Überlastung drosselt.

Bing / Microsoft

• Bing Webmaster Tools — Crawl-Fehlerwarnungen — wie Bing Serverfehler und Timeouts als getrennte Crawl-Fehlerkategorien kennzeichnet.

Zitate aus der Quelle

Aufzeichnungen. Jeder Link springt direkt zur zitierten Passage auf der Quellseite.

MDN — die Definition

• “The HTTP 504 Gateway Timeout server error response status code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server in order to complete the request. This is similar to a 502 Bad Gateway, except that in a 504 status, the proxy or gateway did not receive any HTTP response from the origin within a certain time.” (Übersetzung) „Der HTTP-Serverfehler-Statuscode 504 Gateway Timeout bedeutet, dass der Server, während er als Gateway oder Proxy agierte, vom Upstream-Server nicht rechtzeitig eine Antwort erhielt, um die Anfrage abzuschließen. Dies ähnelt einem 502 Bad Gateway, außer dass der Proxy oder das Gateway bei einem 504 innerhalb einer bestimmten Zeit überhaupt keine HTTP-Antwort vom Origin erhielt.“ Zum Zitat springen

Google — Crawling und Timeouts

• “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (Übersetzung) „Googlebot wird das Crawling zurückfahren, wenn er erkennt, dass Ihre Server Schwierigkeiten haben, auf Crawling-Anfragen zu antworten.“ — Google Search Central, Crawling-Fehler beheben. Zum Zitat springen
• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (Übersetzung) „Wenn die Website langsamer wird oder mit Serverfehlern antwortet, sinkt das Limit und Google crawlt weniger.“ — Google Search Central, Crawl-Budget optimieren. Zum Zitat springen

Gary Illyes, Google

• “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (Übersetzung) „Wenn Ihr Server Schwierigkeiten hat, Bytes auszuliefern, ziehen sich unsere Crawler automatisch zurück, um eine Überlastung Ihrer Infrastruktur zu vermeiden; dadurch sinkt Ihre Crawl-Häufigkeit.“ Zum Zitat springen

John Mueller, Google (auf Reddit, berichtet vom Search Engine Journal, August 2025)

• “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts.” (Übersetzung) „Ich würde nur dann erwarten, dass die Crawl-Rate so schnell reagiert, wenn sie 429 / 500 / 503 / Timeouts zurückgeben.“ Zum Zitat springen Das Search Engine Journal gibt Muellers Reddit-Antwort und den Kontext darum wieder.

Checkliste für Serverantwortzeit und TTFB

Das Ziel ist, Antworten schnell genug zu halten, damit nie ein 504 ausgelöst wird — und die Verschlechterung vorher zu erkennen. Arbeiten Sie die Liste von oben nach unten ab:

• TTFB-Grundwert mit curl -w "%{time_starttransfer}" (oder einem synthetischen Monitor) erfassen und dokumentieren, was pro Template als “normal” gilt.
• TTFB kontinuierlich überwachen, nicht nur nach einem Vorfall — auf steigende Werte alarmieren, nicht nur auf harte Fehler.
• Mit realistischer (und Spitzen-)Parallelität Lasttests durchführen — 504s sind meist lastabhängig, daher zeigt eine Prüfung in einem ruhigen Fenster sie nicht.
• Die langsamste Upstream-Arbeit profilieren — nicht indexierte Datenbankabfragen, N+1-Abfragen und blockierende API-Aufrufe von Drittanbietern sind die üblichen Ursachen.
• Konsequent cachen — Seiten-, Objekt- und CDN-Edge-Cache — damit die meisten Anfragen den langsamen Pfad nie berühren.
• Prüfen, dass Timeout-Werte über alle Schichten konsistent sind (CDN, Load Balancer, Nginx proxy_read_timeout / fastcgi_read_timeout, Anwendung), damit eine Schicht nicht vor einer anderen aufgibt.
• Ausreichende Kapazitätsreserve und automatische Skalierung für Verkehrs- und Crawl-Spitzen bestätigen.
• GSC-Crawling-Statistiken auf Timeout- und 5XX-Spitzen sowie steigende durchschnittliche Antwortzeit prüfen.
• Server- und Proxy-Logs prüfen, um festzustellen, welche Schicht bei welcher Arbeit den Timeout erreicht.
• Sicherstellen, dass das Uptime-Monitoring Spitzenlast und nicht nur Anfragen außerhalb der Geschäftszeiten abdeckt.
• Für geplante Ausfallzeiten 503 + Retry-After verwenden, statt Seiten 504 liefern zu lassen.

504-Mythen und Fehler, die Sie vermeiden sollten

Die Fallen, die am häufigsten auftreten — mehrere davon sind weit verbreitete Mythen, die korrigiert werden sollten:

• “Ein 504 ist eine Google-Strafe.” Nein. Es ist ein Zugriffs-/Crawlbarkeitsproblem, keine algorithmische Maßnahme. Google bewertet Ihren Inhalt nicht — Google kann die Seite nicht abrufen. Jeder Rankingverlust ist eine nachgelagerte Folge der Nichtverfügbarkeit, keine Bestrafung.
• “Jeder 504 führt sofort zur Deindexierung meiner Seite.” Nein. Kurze, gelegentliche 504s werden erneut versucht und toleriert. Das Risiko entsteht bei anhaltenden, häufigen 504s über längere Zeit.
• “504 und 503 sind im Grunde dasselbe — ich kann sie austauschbar verwenden.” Nein. Ein 503 kann ein absichtliches, kontrolliertes Signal sein (Google unterstützt 503 ausdrücklich für geplante Ausfallzeiten); ein 504 ist ein Timeout, fast immer ungeplant und ein Symptom eines langsamen Upstreams. Geben Sie bei geplanter Ausfallzeit 503 mit Retry-After zurück — lassen Sie Seiten nicht 504 liefern.
• “Googlebot ist zu aggressiv.” Meist ist es umgekehrt. Ein Server, der unter Googles Crawl-Rate zuverlässig 504s liefert, wird bei ähnlicher Last auch für echte Nutzer schlechter. Der Timeout macht ein echtes Kapazitäts-/Performanceproblem sichtbar (“Hostload exceeded”-Szenarien gibt es, sie sind aber die Ausnahme und nicht die Regel).
• “Die Behebung besteht einfach darin, den Timeout-Wert zu erhöhen.” Das Erhöhen von proxy_read_timeout maskiert den langsamen Upstream, statt ihn zu beheben — und ein längerer Timeout bindet unter Last Worker-Prozesse länger, wodurch sich die Überlastung verschlimmern kann. Beheben Sie die langsame Antwort, statt die Geduld dafür zu verlängern.
• “Das Uptime-Monitoring ist grün, also haben wir kein 504-Problem.” 504s sind häufig lastabhängig. Ein Monitor in einem ruhigen Fenster kann die Timeouts verpassen, die Googlebot während stärkerer Crawl-Schübe sammelt. Vertrauen Sie den Crawling-Statistiken und Logs mehr als Anfragen außerhalb der Spitzenzeiten.

Welche Schicht erreicht den Timeout?

Prompt: Eine Gruppe von 504-Vorfällen klassifizieren

Fügen Sie bereinigte Zeilen mit URL, Zeitstempel, Response-Headern, TTFB oder Gesamtzeit, Ergebnis am öffentlichen Edge, Ergebnis am direkten Origin, Anwendungstrace, Datenbankzeit und Ressourcensignalen ein. Fügen Sie keine Zugangsdaten, Cookies, privaten Adressen oder Nutzerdaten ein.

You are triaging HTTP 504 Gateway Timeout incidents. Classify each row into one of:
slow application or query, upstream dependency timeout, resource exhaustion,
gateway/origin timeout mismatch, CDN or network path, intermittent with insufficient
evidence, or not actually a 504.

For each row:
- quote the supplied evidence behind the classification;
- identify the missing observation that would most change the conclusion;
- separate response latency from the gateway's configured timeout;
- do not recommend increasing a timeout unless the evidence shows healthy work that
  legitimately needs longer;
- group rows sharing timestamps, routes, upstreams, or resource spikes.

Return a table with URL, likely cause, confidence, evidence, next diagnostic, and
incident group. Then list the first three engineering checks for the highest-impact
group. Do not invent thresholds or monitoring data.

DATA:
[PASTE SANITIZED INCIDENT DATA HERE]

Behandeln Sie das Ergebnis als Warteschlange für Hypothesen. Bestätigen Sie es in Gateway-, Anwendungs-, Datenbank- und Infrastruktur-Telemetrie.

Status und Zeit bis zum ersten Byte messen

Führen Sie dies in einer macOS-/Linux-Shell aus. Der Befehl meldet den endgültigen Antwortcode und TTFB für eine einzelne Anfrage, ohne den Body auszugeben.

curl -sS -o /dev/null \
  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.example.com/slow-path

Wiederholen Sie den Befehl einige Male, um zu sehen, ob der Timeout konstant oder lastabhängig ist:

for i in {1..5}; do
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
    https://www.example.com/slow-path
done

PowerShell-Äquivalent:

1..5 | ForEach-Object {
  $watch = [System.Diagnostics.Stopwatch]::StartNew()
  try {
    $response = Invoke-WebRequest -Uri 'https://www.example.com/slow-path' -SkipHttpErrorCheck
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = $response.StatusCode; TotalMs = $watch.ElapsedMilliseconds }
  } catch {
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = 'request-failed'; TotalMs = $watch.ElapsedMilliseconds }
  }
}

Die PowerShell-Version misst die gesamte Anfragezeit, nicht TTFB. Verwenden Sie den Shell-Befehl oder Ihre Anwendungstelemetrie, wenn Sie die Aufteilung bis zum ersten Byte benötigen.

Werkzeuge zum Reproduzieren und Eingrenzen von 504s

• Website Down Checker — testet die Erreichbarkeit von einem externen Standort und erfasst Antwortzeit, Weiterleitung und begrenzte DNS-Belege. Verwenden Sie ihn, um festzustellen, ob der Vorfall öffentlich reproduzierbar ist.
• Bulk HTTP Status Code Checker — prüft eine repräsentative Routenauswahl, vergleicht die Latenz und exportiert die fehlerhafte Teilmenge. So lässt sich ein einzelner langsamer Endpunkt von einem websiteweiten Upstream-Problem trennen.
• CDN-/Load-Balancer-Logs — finden Sie das Gateway, das den 504 ausgegeben hat, und korrelieren Sie dessen Request-ID und Timeout mit dem Upstream-Versuch.
• Anwendungstracing und Logs langsamer Datenbankabfragen — zeigen, wo die Anfrage nach dem Erreichen des Origins ihre Zeit verbracht hat.
• Infrastruktur-Monitoring — vergleichen Sie das Vorfallsfenster mit CPU, Speicher, Worker-Pool, Verbindungen und ausgelasteten Abhängigkeiten, statt aus dem Statuscode zu raten.

TTFB nach Route und Perzentil

Kennzahl: Zeit bis zum ersten Byte für repräsentative Routen, aufgeschlüsselt nach aussagekräftigen Perzentilen statt nur nach einem Durchschnitt.

Aussage: Eine steigende Latenz im oberen Ende ist ein Frühwarnsignal dafür, dass sich Anfragen einem Gateway-Timeout nähern, noch bevor sie 504 zurückgeben.

Erhebung: Verwenden Sie Real-User-/Server-Monitoring oder Gateway-Logs; nutzen Sie das curl-Skript auf der Registerkarte Skripte für Stichproben, nicht als Ersatz für Produktions-Telemetrie.

Benchmark / realistische Spanne: Ermitteln Sie eine Basislinie pro Route und Infrastrukturpfad. Ein sinnvoller Alarm ist eine anhaltende Abweichung von dieser Basislinie oder eine Bewegung in Richtung Ihres tatsächlich konfigurierten Gateway-Timeouts, nicht eine universelle SEO-Zahl.

Rhythmus: Kontinuierlich überwachen; Routentrends wöchentlich und während jedes 504-Vorfalls prüfen.

504-Antwortrate

Kennzahl: Anfragen mit 504 geteilt durch alle Anfragen, aufgeschlüsselt nach Route, Gateway, Origin und — sofern verfügbar — Crawler-/User-Agent-Klasse.

Aussage: Ob Timeouts isoliert sind, sich auf einen Pfad konzentrieren oder so umfassend sind, dass sie Crawling und Nutzer betreffen.

Erhebung: CDN-, Load-Balancer- oder Server-Access-Logs nach Statuscode und Anfrageattributen aggregieren.

Benchmark / realistische Spanne: Das gesunde Ziel sind keine unerklärten 504s. Verwenden Sie für die Alarmsensitivität Ihre eigene normale, vorfallfreie Basislinie, da sich Traffic-Mix und Wiederholungsverhalten je nach Stack unterscheiden.

Rhythmus: Kontinuierlich alarmieren; während der Erholung täglich und im regulären wöchentlichen Zuverlässigkeitsbericht prüfen.

Upstream-Abschluss im Vergleich zum Gateway-Timeout

Kennzahl: Verteilung der Abschlusszeiten des Upstreams im Vergleich zum konfigurierten Timeout jeder Schicht.

Aussage: Ob langsame Arbeit tatsächlich die Grenze erreicht oder ein kürzerer Gateway-Timeout ansonsten gesunde Upstream-Antworten abschneidet.

Erhebung: Gateway-Zeitfelder mithilfe einer Request- oder Trace-ID mit Anwendungstraces verbinden.

Benchmark / realistische Spanne: Halten Sie normale Abschlüsse mit Abstand innerhalb des konfigurierten Limits und lassen Sie Raum für erwartete Schwankungen. Bestimmen Sie diesen Raum aus beobachteten Produktionsverteilungen; erfinden Sie keinen allgemeinen Prozentsatz.

Rhythmus: Nach Konfigurations- oder Abhängigkeitsänderungen und immer dann prüfen, wenn die Latenz im oberen Ende oder die 504-Rate steigt.

Testen Sie Ihr Wissen: 504 Gateway Timeout

Fünf kurze Fragen dazu, was ein 504 bedeutet und wie er sich auf das Crawling auswirkt. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend Ihre Auswahl.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte

• Der Einsteigerleitfaden für technisches SEO — wo Servergesundheit und Crawlability in das größere Bild gehören.
• Die neuen Webcrawler: KI-Bots rücken an Suchmaschinen-Bots heran — wer tatsächlich auf Ihren Server zugreift und warum die Last wichtig ist.

Meine Vorträge

• So funktioniert die Suche (SlideShare) — meine Erklärung von Crawling, Rendering, Indexierung und Ranking, einschließlich des Einflusses von Serverantworten auf die Crawl-Rate. (Mein ständiger Hinweis gilt: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „So verstehe ich die Systeme … diese Darstellung wird nicht zu 100 % vollständig oder korrekt sein.“)

Aus der Branche

• MDN — 504 Gateway Timeout — die maßgebliche Definition und die Unterscheidung zu 502.
• Google — Crawling-Fehler beheben — wie Googlebot bei Serverproblemen zurückfährt.
• Google — Crawl-Budget für große Websites verwalten — wie langsame Antworten das Crawl-Limit senken.
• Google erklärt, wie Crawling 2026 funktioniert (Search Engine Land) — das Illyes-Zitat, das Probleme beim Server mit geringerer Crawl-Häufigkeit verbindet.
• Googlebot-Crawling eingebrochen? Mueller verweist auf Serverfehler (Search Engine Journal) — Mueller ordnet Timeouts zusammen mit 429/500/503 als Fehler ein, welche die Crawl-Rate schnell senken.
• So beheben Sie den 504-Gateway-Timeout-Fehler (Kinsta) — ein solider technischer Ablauf aus Host-Sicht für Anfragekette und Logdiagnose.

Videos

• Google Search Central (YouTube) — die Reihe So funktioniert die Google-Suche und die Crawling-Erklärungen von Martin Splitt, die zeigen, wie Serverantworten und Crawl-Rate zusammenwirken. Kanal

Änderungsprotokoll