Was ist Fehler 503 (Service Unavailable)?

Der Code 503 gehört zur Klasse 5xx der HTTP-Statuscodes, den Serverfehlern. Heute definiert ihn RFC 9110, „HTTP Semantics“, veröffentlicht im Juni 2022, in Abschnitt 15.6.4. Dasselbe Dokument beschreibt in Abschnitt 10.2.3 den Header Retry-After: Zusammen mit 503 gibt er an, wie lange der Dienst voraussichtlich nicht verfügbar ist, als HTTP-Datum oder als Zahl von Sekunden.

Der offizielle Name lautet „Service Unavailable“. Jeder Server zeigt den Fehler mit eigenem Text an, etwa „503 Service Temporarily Unavailable“ oder „No server is available to handle this request“. Es ist dieselbe Antwort, entscheidend ist der Zahlencode.

Ein 503 entsteht, wenn der Server läuft, aber nicht antworten kann. RFC und MDN nennen zwei Ursachen: Wartung oder Überlastung. In der Praxis heißt das:

• Wartung oder ein Software-Update: CMS oder Server liefern für die Dauer an jede Anfrage einen 503.
• Überlastung: Laut MDN lehnen manche Anwendungen Anfragen mit 503 ab, sobald Speicher, CPU oder Verbindungen an ihre Grenze kommen, damit der Server nicht ganz ausfällt.

Der RFC ergänzt in einer Anmerkung: Dass es 503 gibt, verpflichtet einen überlasteten Server nicht, ihn zu senden, manche lehnen die Verbindung einfach ab.

Für Google hat ein 503 drei dokumentierte Folgen:

• Das Crawling wird langsamer. Laut Googles Doku zu Statuscodes bremsen 5xx-Fehler und 429 die Crawler vorübergehend. Die Anleitung zum Senken der Crawl-Rate ergänzt, dass das für den ganzen Hostnamen gilt, auch für URLs, die weiter Inhalt liefern, und dass die Rate von selbst wieder steigt, wenn die Fehler zurückgehen.
• Indexierte URLs bleiben eine Zeit lang, aber nicht dauerhaft. Google schreibt, bereits indexierte URLs blieben im Index erhalten, „but eventually dropped“, also bis sie irgendwann herausfallen. Eine feste Frist nennt Google nicht.
• Der Inhalt der Antwort wird ignoriert. Solange der 503 anliegt, kann Google Titel, Beschreibungen, Metadaten und strukturierte Daten der Seite nicht aktualisieren.

Zwei Fälle musst du trennen, weil Google sie unterschiedlich behandelt.

Ein 503 auf einer normalen Seite folgt den Regeln oben: weniger Crawling für den ganzen Host und, wenn er anhält, Verlust von URLs ohne veröffentlichte Frist.

Ein 503 auf der robots.txt hat eigene Regeln. Laut Googles Doku zur robots.txt gilt: Gibt es die Datei, kann Google sie aber nicht abrufen, crawlt es die Website in den ersten 12 Stunden nicht und versucht weiter, sie zu holen. In den 30 Tagen danach nutzt es die letzte funktionierende Fassung. Bei einem 503 spricht Google von „fairly frequent“ neuen Versuchen. Die Fristen von 12 Stunden und 30 Tagen gelten nur für die robots.txt, nicht für andere Seiten.

Ein Shop aktualisiert zwei Stunden lang sein CMS. In dieser Zeit liefern alle Seiten eine Hinweisseite mit diesen Headern:

HTTP/1.1 503 Service Unavailable Retry-After: 7200

7200 sind Sekunden, also zwei Stunden. Die robots.txt antwortet weiter mit 200. Nach dem Update liefern die Seiten wieder 200, und Google erhöht die Crawl-Rate wieder.

Ein anderer Fall: Eine Kampagne bringt einen Besucheransturm, der Server erreicht seine Verbindungsgrenze und beantwortet einige Minuten lang einen Teil der Anfragen mit 503. Google crawlt diesen Host langsamer, bis der Server wieder antwortet.

Um den Code einer URL zu prüfen, reicht eine Anfrage im Terminal, wie Googles eigene Anleitung zeigt: curl -I -X GET "https://www.example.com/". Die erste Zeile der Antwort nennt den Code, darunter steht, falls vorhanden, der Header Retry-After.

In der Google Search Console fasst der Bericht zur Seitenindexierung diese URLs unter „Server error (5xx)“ (Serverfehler) zusammen. Google weist darauf hin, dass sie vorübergehend sein können: Ein Live-Test in der URL-Prüfung kann gelingen, obwohl Googles Crawl vorher scheiterte.

Für eine geplante Abschaltung ist 503 der Code, den der Standard vorsieht: Er sagt, dass das Problem vorübergehend ist, und erlaubt die Angabe, wann es weitergeht. Er ist besser als eine Hinweisseite mit 200, die für einen Crawler eine normale Seite mit diesem Text ist, und besser als ein 404, der meldet, dass es die Seite nicht gibt. Mit Retry-After gibt der Server zusätzlich eine konkrete Schätzung.

Die Nachteile sind die jedes 5xx: Das Crawling sinkt für den ganzen Host, Google aktualisiert weder Titel noch strukturierte Daten, und hält der Fehler an, können URLs aus dem Index fallen. Ein 503 ist für Stunden oder ein, zwei Tage gedacht, nicht als Dauerzustand.

Quelle: RFC 9110 (Juni 2022), Abschnitte 15.6.1, 15.6.3 und 15.6.4; MDN, „503 Service Unavailable“ (429); Googles Doku zu Statuscodes (abgerufen am 11.11.2026).

Beim Crawling behandelt Google 500, 502 und 503 gleich und zählt auch 429 zu den Serverfehlern. Der Unterschied liegt im Standard und darin, was der Empfänger der Antwort versteht, nicht in einer anderen Behandlung im Index.

Zum 503 kursieren Fristen, die Googles Quellen nicht stützen. Google veröffentlicht nicht, wie viele Tage es einen 503 hinnimmt, bevor es eine URL entfernt. Google schreibt zwei verschiedene Dinge. Das eine ist eine Empfehlung zur Dauer: Wer das Crawling absichtlich bremst, soll 5xx oder 429 „a couple of hours, or 1-2 days“ liefern und eine ganze Website nur „a few days at most“ abschalten. Das andere ist ein Risiko ohne Datum: Indexierte URLs bleiben erhalten, „but eventually dropped“, und sieht Googlebot diese Codes mehrere Tage auf derselben URL, kann sie aus dem Index fallen. Die ein, zwei Tage sind also keine Frist bis zur Entfernung. Zahlen wie „eine Woche“ oder „zwei Wochen“ stehen ebenfalls nicht in Googles Doku.

In Googles Blogbeitrag von 2011 zu geplanten Ausfällen empfahl Google 503 statt 404 oder 200, weil er den Ausfall als vorübergehend kennzeichnet; die heutige Statuscode-Doku beschreibt 500, 502 und 503 dagegen mit derselben Wirkung auf Crawling und Index. 503 ist also nach dem Standard der richtige Code für Wartung, schützt den Index aber nicht besser als ein 500.

Ähnlich ist es bei Retry-After. Google nennt den Header seit dem 6. Oktober 2026 in der Anleitung zum Senken der Crawl-Rate, mit dem Hinweis, dass die Unterstützung nicht neu ist. Ob die Crawler ihn auswerten und so lange warten, sagt keine Quelle.

• Entscheide, ob die Abschaltung in Stunden oder ein, zwei Tagen erledigt ist. Dauert sie länger, nimm statt eines 503 eine indexierbare Startseite mit 200.
• Stell den Server oder den Wartungsmodus so ein, dass die Seiten 503 liefern, nicht 200 oder 404.
• Ergänze Retry-After mit einem Datum oder den geschätzten Sekunden.
• Nimm die robots.txt vom 503 aus: Sie muss weiter mit 200 antworten.
• Liefere eine statische, schlanke Hinweisseite aus.
• Prüf mit curl, ob die Antwort 503 lautet und den Header trägt.
• Stell danach wieder auf 200 um und sieh dir in der Search Console den Indexierungsbericht und die Crawling-Statistiken an.

• Nutze 503 oder 429, um Googlebot kurzfristig zu bremsen; von 403 und 404 rät Google dafür ab.
• Halte den Hinweis kurz und statisch, damit er einen ausgelasteten Server nicht zusätzlich belastet.

• Die robots.txt mit 503 ausliefern: Google crawlt dann die ganze Website nicht.
• Den Wartungsmodus Tage oder Wochen eingeschaltet lassen.
• Den Wartungshinweis mit Code 200 ausliefern: Für Google ist das eine normale Seite mit diesem Text.
• Davon ausgehen, dass ein 503 URLs unbegrenzt im Index hält.

Dieser Eintrag wurde im November 2026 mit KI-Unterstützung geschrieben. Die Fakten stammen aus RFC 9110, aus Googles Doku zu Statuscodes, Crawl-Rate, robots.txt und zum Abschalten einer Website, aus Googles Blogbeitrag von 2011 und von MDN. Er wurde vor der Veröffentlichung geprüft und enthält keine Kundendaten.