WordPress-Wartungsmodus: aktivieren, deaktivieren, offline

Den Wartungsmodus schaltet WordPress mit einer einzigen Datei: .maintenance im Hauptverzeichnis der Installation. Liegt sie dort, beantwortet WordPress jede Anfrage mit dem Statuscode 503 und der Meldung „Diese Website ist aufgrund planmäßiger Wartungsarbeiten vorübergehend nicht verfügbar". Löschen beendet den Modus. Mehr steckt nicht dahinter, und genau deshalb geht beim Aktivieren und Deaktivieren so viel schief.

Der eingebaute Wartungsmodus endet nach zehn Minuten von selbst. Er ist für Updates gebaut, nicht für einen Umbau über den Nachmittag. Wer ihn für längere Arbeiten nutzt, steht nach zehn Minuten mit halbfertiger Seite im Netz.

Wie WordPress den Wartungsmodus schaltet#

Startet ein Update, schreibt WordPress die Datei .maintenance mit einer einzigen Zeile: <?php $upgrading = 1791073200; ?>, also dem Zeitpunkt des Starts. Ist das Update fertig, löscht WordPress die Datei wieder (WP_Upgrader::maintenance_mode()).

Bei jeder Anfrage prüft der Kern in wp_is_maintenance_mode(), ob die Datei existiert, und liest sie ein. Ist der Zeitstempel älter als zehn Minuten, gilt die Wartung als vorbei, und die Seite läuft normal. Ist er jünger, beendet wp_maintenance() die Anfrage. Es sendet den Kopf Retry-After: 600 und eine Fehlerseite mit Status 503.

Drei Folgen, die man kennen sollte:

• Auch der Admin-Bereich ist gesperrt. wp_maintenance() läuft in wp-settings.php ganz am Anfang, bevor ein Plugin oder ein angemeldeter Benutzer geladen ist (wp-settings.php im Quellcode). Du kommst auch als Administrator nicht hinein.
• Der Statuscode stimmt. 503 heißt laut RFC 9110 „vorübergehend nicht verfügbar", und Retry-After sagt, wann es sich lohnt, wiederzukommen. Für Suchmaschinen ist das die richtige Antwort.
• Eine eigene Seite ist vorgesehen. Liegt eine Datei wp-content/maintenance.php vor, lädt WordPress statt der Standardmeldung diese Datei. Der Kern führt sie als Drop-in „Custom maintenance message" (_get_dropins()). Den Statuscode setzt WordPress dann allerdings nicht mehr, das muss die Datei selbst tun.

Nachgemessen: zehn Minuten, dann läuft die Seite wieder#

Ob das in der aktuellen Version so stimmt, habe ich am 08.10.2026 an einer frischen Testinstallation auf meinem Rechner nachgemessen (WordPress 7.1.3, PHP 8.4.23, nichts verändert). Erst den Modus mit WP-CLI einschalten, dann die Startseite abrufen (Ausgabe um Datum und Verbindungszeilen gekürzt):

$ wp maintenance-mode activate
Enabling Maintenance mode...
Success: Activated Maintenance mode.
$ cat .maintenance
<?php $upgrading = 1791462187; ?>
$ curl -sI http://127.0.0.1:8099/
HTTP/1.1 503 Service Unavailable
X-Powered-By: PHP/8.4.23
Retry-After: 600
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private

Danach habe ich Startseite und /wp-admin/ alle 15 Sekunden abgerufen, 13 Minuten lang, ohne die Datei anzufassen:

Nach zehn Minuten antwortet die Startseite wieder mit 200, /wp-admin/ leitet mit 302 zur Anmeldung weiter. Die Datei .maintenance lag zu diesem Zeitpunkt noch unverändert im Verzeichnis, und wp maintenance-mode status meldete trotzdem „Maintenance mode is not active.“ Wer nach einem abgebrochenen Update nur auf die Datei schaut, sieht also einen anderen Zustand als die Besucher.

Wenn die Seite im Wartungsmodus hängt#

Die offizielle Antwort der WordPress-Dokumentation: Die Datei .maintenance wurde nach dem Update nicht entfernt, also per FTP löschen (Common WordPress Errors). Der Weg dauert zwei Minuten.

1. Status prüfen. Im Terminal curl -I https://deine-domain.at/ aufrufen. Steht in der ersten Zeile 503 und darunter Retry-After: 600, kommt die Meldung von WordPress selbst.
2. Datei löschen. Per SFTP oder im Dateimanager des Hosters ins Hauptverzeichnis wechseln (dort, wo wp-config.php liegt) und .maintenance löschen. Die Datei beginnt mit einem Punkt und ist in vielen Programmen versteckt. Die Anzeige versteckter Dateien muss eingeschaltet sein. Mit Shell-Zugang geht es ohne Suchen: wp maintenance-mode deactivate (WP-CLI-Dokumentation). wp maintenance-mode status zeigt vorher, ob der Modus aktiv ist.
3. Cache leeren. Ein Seiten-Cache oder ein CDN kann die Wartungsseite weiter ausliefern, obwohl WordPress längst wieder läuft. Cache im Plugin oder beim Hoster leeren und erneut mit curl -I prüfen.
4. Das Update zu Ende bringen. Die Datei bleibt meist liegen, weil ein Update abgebrochen ist. Unter Dashboard → Aktualisierungen nachsehen, was noch offen ist, und es einzeln nachholen. Wie man Updates so einspielt, dass das nicht passiert, steht in WordPress-Updates richtig machen.

Steht die Meldung länger als zehn Minuten, obwohl kein Update läuft, lohnt ein zweiter Blick. Laut Kerncode endet der eingebaute Modus nach dieser Zeit von selbst. Die Meldung kommt dann sehr wahrscheinlich aus einem Cache, aus einem Wartungsmodus-Plugin oder aus einer .maintenance, die jemand von Hand mit einem anderen Inhalt angelegt hat.

Den Wartungsmodus selbst einschalten#

Für kurze Arbeiten reicht der eingebaute Modus: wp maintenance-mode activate legt die Datei an, deactivate entfernt sie. WP-CLI nutzt dafür dieselbe Funktion wie der Updater (Quellcode des Befehls). Die Zehn-Minuten-Grenze gilt also auch hier.

Für längere Arbeiten gibt es drei Wege:

• .maintenance mit dauerhaftem Zeitstempel. Schreibst du in die Datei <?php $upgrading = time(); ?>, ist der Zeitstempel bei jeder Anfrage die aktuelle Sekunde, und die zehn Minuten laufen nie ab. Der Modus bleibt, bis du die Datei löschst. Das ist eine Folge des Codes oben, keine dokumentierte Funktion: zuverlässig, aber leicht zu vergessen.
• Eigene Wartungsseite als Drop-in. In wp-content/maintenance.php gehört dann mindestens http_response_code( 503 ); und header( 'Retry-After: 3600' ); vor jede Ausgabe. Ohne diese zwei Zeilen liefert die schöne Seite den Status 200, und das ist für Google eine normale Seite mit wenig Inhalt.
• Plugin. Wartungsmodus-Plugins haben einen Vorteil: Angemeldete Administratoren sehen die Seite normal und können weiterarbeiten. Prüf nach dem Aktivieren mit curl -I, ob das Plugin wirklich 503 sendet. Manche liefern „Coming soon" mit 200 aus.

Die Seite für längere Zeit offline nehmen#

Google hat dafür eine eigene Anleitung (Website vorübergehend pausieren). Die Kernaussage: Für ein bis zwei Tage ist eine Fehlerseite mit 503 richtig. Für länger soll eine indexierbare Startseite mit Status 200 erreichbar bleiben, die erklärt, was los ist. Schon ein Ausfall von wenigen Wochen kann der Indexierung schaden.

Der Grund steht in Googles Doku zu Serverfehlern (HTTP-Statuscodes und Netzwerkfehler): Bei 5xx senkt Google die Crawl-Rate, ignoriert den Inhalt der Antwort und behält bereits indexierte Adressen zunächst. Liefern sie dauerhaft Fehler, fliegen sie irgendwann raus. Eine feste Frist nennt Google nicht.

Der Passwortschutz in der letzten Zeile passt für eine Baustelle, die Google noch nie gesehen hat. Für eine Seite mit Rankings ist er falsch, denn er sperrt Google genauso aus wie die Besucher.

Was nicht hilft#

„Coming soon" mit Status 200 über alle Seiten. Für Google ersetzt der Platzhalter dann den Inhalt jeder Adresse, und so wird er auch bewertet.

noindex oder ein Komplettverbot in der robots.txt. Google warnt ausdrücklich: Ein Disallow für alles, ein noindex oder die Codes 403, 404 und 410 können die Adressen aus der Suche entfernen. Nach dem Ende der Wartung kommen sie nicht auf Knopfdruck zurück. Wie lange das dauern kann, steht in Wie lange dauert die Indexierung bei Google.

Die Datei stehen lassen „bis zum nächsten Mal". Eine vergessene .maintenance mit time() sperrt die Seite unbemerkt, bis sich jemand beschwert. Nach getaner Arbeit mit curl -I prüfen, ob wieder 200 kommt.

Ein Sicherheitsnetz für zwei Minuten#

Der Wartungsmodus von WordPress ist ein Sicherheitsnetz für die zwei Minuten eines Updates, kein Werkzeug für Umbauten. Hängt er, ist fast immer ein abgebrochenes Update schuld, und die Ursache sitzt dann nicht in der Datei, sondern in Plugins, PHP-Version oder fehlendem Platz. Ob die PHP-Version passt, zeigt Welche PHP-Version braucht WordPress?. Wo Updates in die gesamte Absicherung passen, steht in WordPress-Sicherheit prüfen. Wer das nicht selbst machen will, findet die Updates als Teil der WordPress-Wartung.

Häufige Fragen#

Stand 08.10.2026. Kerncode (wp-includes/load.php, wp-settings.php, class-wp-upgrader.php) im Zweig trunk von wordpress-develop, WP-CLI- und Google-Dokumentation am 04.10.2026 gelesen; Verhalten am 08.10.2026 an einer lokalen Testinstallation mit WordPress 7.1.3 nachgemessen. Die deutsche Meldung stammt aus der offiziellen Übersetzung auf translate.wordpress.org.