Tech-Blog seit 2010
Daniel Weihmann
Alle Aufrufe auf eine Index-Seite umleiten: Wartungsmodus richtig umsetzen

Alle Aufrufe auf eine Index-Seite umleiten: Wartungsmodus richtig umsetzen

Von Daniel Weihmann · · Aktualisiert: 03.06.2026 · 7 Kommentare

Manchmal muss die ganze Webseite in den Wartungsmodus: ein Relaunch steht an, das Shop-System bekommt ein Major-Update, eine fehlerhafte Konfiguration soll keine echten Nutzer mehr treffen. Die saubere Lösung dafür: alle Aufrufe vorübergehend auf eine einzige Index- oder Wartungsseite umleiten, die freundlich erklärt was los ist. Hier findest du die passende Konfiguration für Apache, nginx und PHP, plus die SEO-Hinweise, die viele beim ersten Mal übersehen.

Der Artikel ist 2011 entstanden, damals als Antwort auf einen sehr konkreten Kunden-Wunsch. Das Vorgehen ist heute unverändert, aber drei Dinge sind dazugekommen: die Empfehlung Status 503 statt 302 für Wartungsfenster, ein Hinweis zum richtigen Retry-After-Header und die Frage, was du beim Wartungsmodus mit der robots.txt machst.

Wann eine komplette Index-Umleitung wirklich sinnvoll ist

Die Methode ist ein Werkzeug für drei klare Szenarien:

Was die Methode nicht sein sollte: eine wochenlange Dauerlösung, weil die alten Inhalte angeblich "veraltet" sind. In dem Fall lieber die Artikel einzeln überarbeiten oder gezielt 301en. Mehr dazu auch im Hub Domain umziehen ohne SEO-Verluste.

Der richtige Statuscode: 503 statt 302

Wer für Wartungsfenster mit Status 302 weiterleitet, signalisiert Google und Bing nur "diese Seite ist gerade an einer anderen Stelle zu finden". Das ist falsch. Korrekt ist Status 503 Service Unavailable - das sagt der Suchmaschine: "Inhalt ist vorübergehend nicht verfügbar, bitte später nochmal versuchen". Ergänzt um den Header Retry-After (mit erwartetem Wieder-Verfügbar-Datum oder in Sekunden) bleibt deine Seite im Index erhalten, die Crawler kommen später nochmal vorbei.

Konkret: bei einem Wartungsfenster von einer Stunde reicht Retry-After: 3600. Bei einem Wochenende-Relaunch Retry-After: Mon, 09 Jun 2026 08:00:00 GMT. Beide Schreibweisen sind zulässig.

Apache: htaccess-Regel mit Status 503

Die saubere Variante mit 503-Statuscode und Retry-After-Header in der .htaccess deines Webroots:

RewriteEngine On
# eigene IP ausnehmen, damit du selbst weiter testen kannst
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.42$
# Wartungsseite selbst nicht erneut umleiten
RewriteCond %{REQUEST_URI} !^/wartung\.html$
# Statische Assets ausnehmen, damit die Wartungsseite Bilder und CSS laden kann
RewriteCond %{REQUEST_URI} !\.(css|js|jpg|jpeg|png|svg|webp|woff2?)$ [NC]
RewriteRule ^.* /wartung.html [R=503,L]

# Statuscode 503 für die Wartungsseite + Retry-After
<Files "wartung.html">
  Header set Retry-After "3600"
</Files>

Drei Zeilen erklärt: die RewriteCond-Zeilen schließen drei Szenarien aus - deine eigene IP, die Wartungsseite selbst und statische Dateien wie CSS und Bilder. Wenn keine der drei zutrifft, leitet die Rule auf wartung.html um, mit explizitem Statuscode 503. Der Files-Block fügt der Wartungsseite den Retry-After-Header bei.

Für die eigene IP: DynDNS-Tipps und das DNS-Lookup-Tool helfen, wenn sich deine Heim-IP regelmäßig ändert. Bei statischen Office-Anschlüssen reicht die IP einmal eintragen.

nginx: server-Block mit Maintenance-Modus

Die nginx-Variante mit Datei-Schalter - sobald die Datei /etc/nginx/maintenance.flag existiert, ist Wartungsmodus aktiv:

server {
  listen 80;
  listen 443 ssl;
  server_name www.beispiel.de;
  root /var/www/beispiel;

  if (-f /etc/nginx/maintenance.flag) {
    return 503;
  }

  error_page 503 @maintenance;
  location @maintenance {
    rewrite ^.*$ /wartung.html break;
    add_header Retry-After 3600 always;
  }

  # statische Assets weiter ausliefern
  location ~* \.(css|js|jpg|jpeg|png|svg|webp|woff2?)$ {
    try_files $uri =404;
  }
}

Vorteil dieser Variante: Wartungsmodus an/aus geht per touch /etc/nginx/maintenance.flag bzw. rm /etc/nginx/maintenance.flag ohne nginx-Reload. Praktisch wenn mehrere Personen den Modus schalten dürfen.

PHP-Variante als Notfall ohne Server-Zugriff

Wenn du keine htaccess- oder nginx-Konfiguration anfassen kannst, hilft eine kleine PHP-Datei, die du an die index.php hängst:

<?php
\$maintenance = true;
\$allowed_ips = ['203.0.113.42', '198.51.100.7'];

if (\$maintenance && !in_array(\$_SERVER['REMOTE_ADDR'] ?? '', \$allowed_ips, true)) {
    \$is_asset = preg_match('/\.(css|js|jpg|jpeg|png|svg|webp|woff2?)\$/i', \$_SERVER['REQUEST_URI'] ?? '');
    if (!\$is_asset) {
        http_response_code(503);
        header('Retry-After: 3600');
        readfile(__DIR__ . '/wartung.html');
        exit;
    }
}
?>

Diese Datei am Anfang deiner index.php includen oder als eigene Front-Controller-Datei nutzen. Funktioniert mit jedem CMS, das einen zentralen Einstiegspunkt hat.

Cookie-Ausnahme statt IP-Ausnahme

Bei mobilen Mitarbeitenden mit wechselnden IPs (Café-WLAN, Hotel, Bahn) hilft eine Cookie-basierte Ausnahme. Du legst manuell ein Cookie auf jedem Test-Gerät an und prüfst es im Server-Code:

RewriteCond %{HTTP_COOKIE} !maintenance_bypass=geheimer_wert
RewriteCond %{REQUEST_URI} !^/wartung\.html$
RewriteRule ^.* /wartung.html [R=503,L]

Das Cookie setzt du einmal per document.cookie in der Browser-Konsole oder per kleinem PHP-Endpunkt mit Passwort-Abfrage. Tester ohne Cookie sehen die Wartungsseite, Tester mit Cookie sehen die normale Webseite.

Was mit der robots.txt passieren sollte

Wichtiger Punkt, der oft vergessen wird: in der Wartungszeit darf die robots.txt nicht plötzlich alles aussperren. Manche Setups generieren während des Wartungsmodus eine restriktive robots.txt mit User-agent: * Disallow: /. Das ist falsch - du willst, dass Crawler nach Ende der Wartung wieder regulär arbeiten.

Wenn die robots.txt selbst Status 503 zurückgibt, ignorieren Crawler den Disallow temporär - sie warten ab. Das ist das gewünschte Verhalten. Die robots.txt sollte also entweder unverändert bleiben oder ebenfalls per htaccess-Regel auf den 503er kommen.

Die Wartungsseite selbst

Ein paar Mindestanforderungen an die Wartungsseite, damit sie nicht selbst zum Problem wird:

Nach dem Wartungsfenster

  1. Wartungsmodus abschalten: htaccess-Block auskommentieren, nginx-Flag-Datei löschen, PHP-Schalter auf false.
  2. Statuscodes verifizieren: mit dem Redirect-Checker oder curl -I prüfen, dass die Webseite jetzt wieder mit Status 200 antwortet.
  3. Crawler-Aktivität beobachten: in den ersten 24 Stunden in der Search Console beobachten, ob Google die Seiten wieder regulär crawlt. Bei plötzlichen Indexierungs-Drops im Crawl-Statistiken-Bericht nachschauen.
  4. Test-IP entfernen: die Bypass-IP oder das Cookie für die nächste Wartungs-Session sauber dokumentieren, aber nicht produktiv aktiv lassen.

FAQ

Warum nicht einfach 302 statt 503?

Eine 302 sagt "Inhalt ist temporär unter einer anderen URL". Suchmaschinen interpretieren das als Hinweis auf eine andere Seite, behalten den ursprünglichen Inhalt im Index. Status 503 sagt klar "kurzfristig nicht verfügbar, kommt wieder" - das ist die richtige Botschaft für Wartungsfenster.

Wie lange kann ich den 503-Modus laufen lassen?

Google verträgt einen 503er für mehrere Tage problemlos, in der Praxis ohne Ranking-Verlust. Bei längeren Ausfällen (über eine Woche) wird Google vorsichtig - die Seite kann aus dem Index fallen. Faustregel: 503 für geplante Wartung bis maximal 24-48 Stunden, danach lieber temporäre Inhalte ausspielen.

Muss ich für jedes CMS einen anderen Code nutzen?

Nein. Die htaccess- oder nginx-Lösung greift vor dem CMS und ist unabhängig von WordPress, Joomla, Typo3 oder selbstgebautem PHP. Die PHP-Variante funktioniert mit jedem CMS, das einen zentralen Einstiegspunkt hat.

Was tun, wenn ich nicht weiß, was meine IP ist?

Auf ipinfo.io, whatismyip.com oder direkt mit curl ifconfig.me aus der Kommandozeile. Bedenke: viele Internetanbieter ändern die IP alle 24 Stunden. Wer dauerhaft testen will, nutzt entweder DynDNS oder eine Cookie-basierte Ausnahme.

Kann ich mehrere Test-IPs zulassen?

Ja. Bei htaccess mehrere RewriteCond-Zeilen oder ein Regex-OR (!^(203\.0\.113\.42|198\.51\.100\.7)$). Bei nginx mehrere if-Blöcke. Bei PHP einfach als Array führen.

Was passiert mit laufenden Sessions oder Warenkörben?

Bei Status 503 sieht der Nutzer die Wartungsseite, der ursprüngliche Warenkorb bleibt aber in der Session bzw. Datenbank erhalten - solange das Backend nicht zerstört wurde. Nach Ende der Wartung ist beim ersten Aufruf wieder alles da. Das ist ein zentraler Vorteil gegenüber Shop-Komplett-Reset.

Quellen

Verwandte Artikel

Kommentararchiv 7

Sieben Leser haben zwischen 2011 und 2014 kommentiert. Schwerpunkte: Diskussion um den richtigen Statuscode (302 vs. 503), Frage nach Mehr-Domain-Setups und Verbindung zwischen htaccess-Regel und gleichzeitig laufenden Tests aus dem Büro - die IP-Ausnahme galt schon damals als die saubere Lösung.