Wartungsmodus und SEO: 503 richtig einsetzen

Wenn eine Website für geplante Wartungsarbeiten offline geht, entscheidet ein einzelner HTTP-Statuscode darüber, ob Google die Unterbrechung als vorübergehend einstuft oder als Signal wertet, dass die Seiten verschwunden sind. Die technisch richtige Antwort ist ein 503-Statuscode mit einem gesetzten Retry-After-Header, ausgeliefert auf jeder URL, die während der Wartung nicht erreichbar ist. Alles andere – eine Weiterleitung auf eine separate Wartungsseite mit 302, oder schlimmer, eine Wartungsseite, die mit 200 OK ausgeliefert wird – lässt Suchmaschinen glauben, der eigentliche Inhalt sei durch die Wartungsseite ersetzt worden.

Wie lange ein 503 unproblematisch bleibt, wie der Retry-After-Header korrekt gesetzt wird, warum 302 und 200 während der Wartung riskant sind und worauf bei CDNs und CMS-Wartungsmodi zu achten ist, zeigt dieser Artikel anhand der technischen Mechanik dahinter – nicht anhand geschätzter Ausfallzeiten oder unbelegter Erfahrungswerte.

Warum der Statuscode über Vertrauen entscheidet

Für einen Crawler ist ein HTTP-Statuscode keine Formalität, sondern die einzige verlässliche Information darüber, was mit einer URL gerade passiert. 200 OK heißt: Hier ist Inhalt, bewerte und indexiere ihn. 404 und 410 heißen: Diese Adresse ist weg, entferne sie aus dem Index. 503 heißt etwas völlig anderes: Der Server kann die Anfrage momentan nicht bearbeiten, aber die Ressource existiert weiterhin und sollte später erneut abgerufen werden.

Diese dritte Kategorie ist genau das, was eine geplante Wartung ist: ein temporärer Zustand, kein inhaltliches Ereignis. Wenn ein Server während einer Wartung konsequent 503 zurückgibt, muss Google nicht neu bewerten, ob eine Seite noch relevant ist – die Seite wird schlicht als momentan nicht abrufbar behandelt und ihre bisherigen Rankingsignale bleiben erhalten, bis der nächste erfolgreiche Crawl wieder Inhalt liefert. Liefert der Server stattdessen 200 für eine Wartungsseite, sieht Googlebot dagegen echten, neuen Inhalt – und beginnt, genau diesen zu bewerten, nicht die eigentliche Seite dahinter.

Der Unterschied wirkt banal, ist aber der ganze Mechanismus: 503 sagt „warte", 200 sagt „das ist jetzt der Inhalt". Ein Statuscode kommuniziert Absicht an ein System, das keine andere Möglichkeit hat, diese Absicht zu erkennen.

Retry-After korrekt setzen

Der Retry-After-Header ist der Teil, den die meisten Wartungsmodi weglassen, obwohl er der eigentliche Zweck der Übung ist. Er teilt einem abrufenden Client – Browser wie Crawler – mit, wann ein erneuter Versuch sinnvoll ist. Zulässig sind zwei Formate, die weiter unten aufgeführt sind.

Googlebot behandelt diesen Wert als Hinweis, nicht als exakte Zusage – ein erneuter Crawl-Versuch genau zur Sekunde ist nicht garantiert, weil Crawling-Budget und Warteschlangen dazwischenliegen. Trotzdem verändert der Header das Verhalten messbar: Ohne Retry-After fällt Google auf eigene Backoff-Heuristiken zurück, die auf wiederholten 503-Antworten basieren und typischerweise vorsichtiger, also seltener, erneut anfragen. Mit einem realistischen Retry-After signalisiert die Seite dagegen aktiv, dass die Downtime geplant und begrenzt ist, was die Wahrscheinlichkeit erhöht, dass der nächste Crawl-Versuch zeitlich näher an der tatsächlichen Wiederverfügbarkeit liegt.

Wichtig ist „realistisch": Ein Retry-After von 30 Tagen für eine zweistündige Wartung ist kein Sicherheitspuffer, sondern eine falsche Information, die Google unnötig lange von der Seite fernhält. Der Wert sollte die tatsächlich erwartete Dauer abbilden, im Zweifel mit moderater Reserve, nicht mit einer willkürlich großen Zahl.

• Eine ganze Zahl in Sekunden: Retry-After: 3600 bedeutet „in einer Stunde erneut versuchen".
• Ein Datum im HTTP-Date-Format: Retry-After: Wed, 24 Sep 2026 14:00:00 GMT gibt einen konkreten Zeitpunkt an.

Wie lange ist ein 503 sicher?

Es gibt keine feste Stundenzahl, ab der ein 503 „gefährlich" wird – die Frage ist falsch gestellt. Der Mechanismus ist kumulativ: Jeder einzelne 503 ändert nichts an sich, aber wiederholte 503-Antworten über mehrere Crawl-Versuche hinweg verändern, wie dringend Google die Seite noch für abrufbar hält. Google selbst beschreibt in seiner Dokumentation zu Website-Ausfällen sinngemäß, dass kurze Unterbrechungen von wenigen Stunden bis zu einem Tag in der Regel folgenlos bleiben, während sich über mehrere Tage fortsetzende 503-Antworten dazu führen können, dass die Crawling-Frequenz für die betroffenen Adressen automatisch sinkt und die URLs im ungünstigsten Fall vorübergehend aus dem Index genommen werden, bis wieder regulärer Inhalt abrufbar ist.

Die praktische Konsequenz ist keine Deadline, sondern eine Priorität: Ein Wartungsfenster, das endet, bevor der nächste planmäßige Crawl-Versuch überhaupt stattfindet, ist inhärent sicherer als eines, das sich über mehrere Crawl-Zyklen zieht. Eine zehnminütige Migration am frühen Morgen trägt in der Praxis kaum Risiko, weil kaum ein Crawl-Versuch in dieses Fenster fällt. Eine mehrtägige Serverumstellung, die durchgehend 503 liefert, verschiebt sich dagegen von „temporär" zu „wiederholt bestätigt nicht erreichbar" – und genau dieser wiederholte Befund ist es, der die Behandlung ändert, nicht ein einzelner Schwellenwert.

Für längere, mehrtägige Vorhaben lohnt sich deshalb ein anderer Ansatz: die Wartung auf einzelne Bereiche oder Uhrzeiten mit wenig Crawling-Aktivität begrenzen, statt die gesamte Domain durchgehend zu sperren.

Warum eine 302-Weiterleitung auf die Wartungsseite riskant ist

Ein naheliegender, aber problematischer Ansatz ist es, jede Anfrage per 302 auf eine zentrale Wartungsseite umzuleiten, die selbst mit 200 OK antwortet. Das Problem liegt nicht in der Weiterleitung an sich, sondern in der Kombination: 302 signalisiert „temporär", aber das Ziel der Weiterleitung liefert regulären, indexierbaren 200-Inhalt. Für einen Crawler heißt das: Tausende unterschiedlicher URLs leiten alle auf denselben, identischen Inhalt um.

Bleibt dieser Zustand über mehrere Crawl-Zyklen bestehen, entsteht faktisch ein massives Duplicate-Content-Signal – nicht weil der Inhalt kopiert wurde, sondern weil das gesamte URL-Set vorübergehend denselben, meist sehr dünnen Text ausliefert. Google kann in dieser Zeit nicht verifizieren, ob die ursprünglichen Seiten noch relevant sind, weil es ihren tatsächlichen Inhalt schlicht nicht sieht. Je länger dieser Zustand anhält, desto größer die Wahrscheinlichkeit, dass die betroffenen Adressen für die Dauer der Wartung an Relevanz für ihre eigentlichen Suchanfragen verlieren, weil das System keine aktuellen Belege für diese Relevanz mehr abrufen kann.

Noch ungünstiger ist eine Wartungsseite, die ganz ohne Weiterleitung direkt unter der Original-URL mit 200 OK ausgeliefert wird. Hier fehlt sogar das schwache Signal „temporär", das ein 302 zumindest andeutet. Für Google sieht es aus, als hätte sich der Inhalt dieser URL grundlegend geändert – von einer thematischen Seite zu einem kurzen Hinweistext wie „Wir sind bald zurück". Bis zum nächsten erfolgreichen Crawl mit echtem Inhalt kann genau dieser dünne Hinweistext das sein, was Nutzer in den Suchergebnissen als Snippet sehen, was Klickrate und Nutzersignale für die Seite in dieser Zeit belastet.

CDN-Fallstricke im Wartungsmodus

Viele Wartungsmodi laufen nicht auf dem Ursprungsserver, sondern auf der Ebene eines CDN wie Cloudflare, Fastly oder eines Reverse-Proxys wie Varnish. Das verändert die technische Aufgabe: Es reicht nicht, dass der Origin-Server korrekt 503 sendet, wenn die Edge-Konfiguration diesen Code auf dem Weg zum Client überschreibt. Einige Standard-Wartungsseiten von CDN-Anbietern liefern per Default 200 für ihre eigene Hinweisseite aus, unabhängig davon, was der Origin-Server gemeldet hätte. Wer sich auf „der Server sagt doch 503" verlässt, ohne das am Edge zu prüfen, hat oft de facto einen 200-Wartungsmodus im Sinn des vorherigen Abschnitts.

Ein zweites, subtileres Problem ist Caching selbst: Wurden Seiten kurz vor Beginn der Wartung noch mit langer Cache-Gültigkeit ausgeliefert, kann ein Crawler je nach Cache-Status mal die alte, gecachte 200-Antwort erhalten und mal die neue 503-Antwort – abhängig davon, ob und wann der Cache invalidiert wurde. Dieses Flattern zwischen zwei unterschiedlichen Antworten für dieselbe URL ist für die Bewertung ungünstiger als ein durchgehender, konsistenter 503, weil es keinen klaren Zustand mehr gibt, den das System als „aktuell" ansehen kann. Vor einer geplanten Wartung sollte der Cache am Edge entweder gezielt geleert oder für die betroffenen Pfade auf ein sehr kurzes Zeitfenster gesetzt werden, und der Retry-After-Header muss explizit als durchzureichender Header konfiguriert werden, da manche Edge-Regeln nur den Statuscode weiterleiten, aber zusätzliche Header stillschweigend fallen lassen.

Ein Punkt, der hier ausdrücklich nicht gemeint ist: Googlebot speziell anders zu behandeln als menschliche Besucher, etwa indem nur Anfragen mit dem User-Agent „Googlebot" den 503 erhalten, während echte Besucher weiterhin die Seite sehen. Das wäre Cloaking – unterschiedlicher Inhalt für Crawler und Menschen – und ein eigenständiges Problem, unabhängig vom Wartungsmodus. Ein legitimer 503 gilt für alle gleich, weil er einen tatsächlichen Systemzustand beschreibt, keine Vorzugsbehandlung für Suchmaschinen.

CMS- und Plugin-Wartungsmodi

Die meisten Redakteure aktivieren einen Wartungsmodus nicht über eine eigene Server-Konfiguration, sondern über ein Plugin oder eine CMS-Funktion – etwa ein Wartungsmodus-Plugin in WordPress oder eine „Coming soon"-Funktion des Shopsystems. Viele dieser Werkzeuge zeigen zwar visuell eine Hinweisseite, liefern dabei aber standardmäßig einen 200-Statuscode aus, weil aus Sicht der Anwendung ja „erfolgreich" eine Seite gerendert wurde. Ob das eigene Plugin tatsächlich 503 sendet, lässt sich nicht durch Anschauen im Browser feststellen, sondern nur durch einen Blick auf den rohen HTTP-Header, etwa mit curl -I gegen die öffentliche URL.

Eine zweite Falle betrifft eingeloggte Redakteure: Viele Wartungsmodi blenden den Hinweis für angemeldete Administratoren automatisch aus, damit intern weitergearbeitet werden kann, während die Seite für alle anderen im Wartungsmodus ist. Das führt regelmäßig dazu, dass ein Verantwortlicher im eigenen, eingeloggten Browser eine ganz normale Seite sieht und den Fehler im Wartungsmodus – etwa den falschen Statuscode – schlicht nicht bemerkt, weil er ihn in seiner eigenen Sitzung nie zu sehen bekommt. Die Prüfung gehört deshalb in einen Inkognito-Tab, ein anonymes Terminal oder ein separates Tool, nicht in den ohnehin schon authentifizierten Arbeitsbrowser.

Ein letzter, oft gut gemeinter Fehler: robots.txt oder Meta-Robots-Tags mit noindex während der Wartung zu ergänzen, in der Annahme, das schütze zusätzlich vor Indexierungsproblemen. Ein korrekt gesetzter 503 kommuniziert bereits „temporär nicht verfügbar" – ein zusätzliches noindex fügt dem nichts hinzu, birgt aber ein eigenes Risiko: Wird es nach Ende der Wartung vergessen zu entfernen, deindexiert es die Seite dauerhaft, weit über das eigentliche Wartungsfenster hinaus. robots.txt selbst sollte während der gesamten Wartung weiterhin ganz normal mit 200 abrufbar bleiben, damit Crawler überhaupt wissen, welche Regeln gelten.

Checkliste für einen technisch korrekten Wartungsmodus

• 503 auf jeder betroffenen URL ausliefern, nicht nur auf der Startseite – Unterseiten, die weiterhin 200 liefern, während der Rest der Domain down ist, erzeugen ein inkonsistentes Bild.
• Retry-After realistisch setzen, in Sekunden oder als HTTP-Date, und bei Verzögerungen aktualisieren statt den alten Wert stehen zu lassen.
• robots.txt während der Wartung weiterhin normal mit 200 ausliefern.
• Kein noindex und keine Meta-Robots-Änderung an den betroffenen Seiten vornehmen – der 503 übernimmt diese Funktion bereits.
• Den tatsächlich ausgelieferten Status am Edge prüfen, per curl -I von außerhalb des eigenen Netzwerks, nicht nur im eigenen, möglicherweise eingeloggten Browser.
• CDN-Caches für die betroffenen Pfade vor Beginn der Wartung leeren oder auf ein sehr kurzes Zeitfenster setzen, damit keine veralteten 200-Antworten weiter ausgeliefert werden.
• Den 503 identisch für Bots und menschliche Besucher ausliefern – niemals unterschiedlich nach User-Agent.
• Das Wartungsfenster so kurz wie operativ möglich halten und wenn möglich in Zeiten mit geringer Crawling-Aktivität legen.
• Nach Abschluss der Wartung sofort prüfen, ob wieder durchgehend 200 mit dem echten Inhalt ausgeliefert wird, statt sich auf die eigene Wahrnehmung zu verlassen.
• In der Google Search Console die Crawling-Statistiken der folgenden Tage beobachten; ein kurzer Anstieg an Serverfehlern während der Wartung ist normal, ein anhaltender Anstieg danach ist ein Hinweis auf ein verbleibendes Konfigurationsproblem.

Wann ein 503 nicht die richtige Antwort ist

Ein 503 ist ein Signal für „vorübergehend, kommt zurück" – und genau deshalb passt er nicht auf jede Störung. Wird eine Seite dauerhaft entfernt, etwa weil ein Produkt endgültig eingestellt wird, ist 410 die richtige Antwort, nicht 503: 410 sagt explizit „endgültig weg", während ein dauerhaft stehen gelassener 503 Google jahrelang glauben lässt, die Seite kehre jeden Moment zurück, was die endgültige Entfernung aus dem Index unnötig verzögert.

Fällt nur ein einzelner Bereich aus – etwa der Checkout-Prozess eines Shops, während Produktseiten und Blog normal erreichbar bleiben – sollte der 503 ebenfalls nur auf die betroffenen Pfade begrenzt werden, statt die gesamte Domain in den Wartungsmodus zu versetzen. Ein domainweiter 503 für ein isoliertes Problem nimmt unnötig auch den unbetroffenen, weiterhin funktionierenden Seiten die Crawling- und Rankingkontinuität.

Und schließlich: Ein 503 ist kein Werkzeug für A/B-Tests, Feature-Flags oder eine vorübergehend fehlerhafte Drittanbieter-Integration. Diese Fälle sind Bugs oder Konfigurationsentscheidungen, keine geplante Wartung – und sollten als solche behoben werden, statt sie hinter einem Statuscode zu verstecken, der eigentlich für eine ganz andere Situation gedacht ist.