„Briefly unavailable for scheduled maintenance" beheben

Du hast ein Update gestartet und plötzlich zeigt die ganze Seite nur noch: „Briefly unavailable for scheduled maintenance. Check back in a minute.” Auch nach Minuten ändert sich nichts. Was passiert ist: Ein Update wurde unterbrochen und WordPress hat die Wartungssperre nicht wieder entfernt. Die Lösung dauert keine Minute, das saubere Aufräumen danach etwas länger.

Läuft deine Installation auf Deutsch, siehst du statt des englischen Textes die offizielle Übersetzung: „Diese Website ist aufgrund planmäßiger Wartungsarbeiten vorübergehend nicht verfügbar. Bitte versuche es in wenigen Minuten erneut.” Es ist dieselbe Meldung und dasselbe Problem. Alles, was hier steht, gilt für beide Fassungen.

Die Meldung auf Deutsch und Englisch

Der deutsche Wortlaut stammt aus der offiziellen WordPress-Übersetzung auf translate.wordpress.org. Hat dein Theme oder ein Plugin die Meldung verändert, sieht sie bei dir anders aus. Dann steckt meist eine eigene Wartungsseite dahinter (dazu weiter unten mehr).

Was dahintersteckt: die .maintenance-Datei

Beim Update legt WordPress im Hauptverzeichnis eine Datei namens .maintenance an. Ihr Inhalt ist winzig: eine PHP-Zeile, die in der Variable $upgrading den aktuellen Unix-Zeitstempel speichert. Bei jedem Seitenaufruf prüft WordPress früh im Ladevorgang, ob diese Datei existiert. Ist das der Fall, bricht es ab und gibt statt deiner Seite die Wartungsmeldung aus. Nach dem Update löscht WordPress die Datei wieder.

Bricht der Vorgang dazwischen ab, bleibt die Datei liegen. Es ist also kein echter Defekt, sondern eine vergessene Sperre. Die Entwicklerdoku von WordPress beschreibt die zuständige Funktion wp_maintenance() ausdrücklich als internen Core-Baustein, du musst daran nichts programmieren.

Hebt sich die Sperre nach zehn Minuten von selbst auf?

Fast. Im Quellcode von wp_is_maintenance_mode() steht eine Zehn-Minuten-Regel: Ist der Zeitstempel in $upgrading zehn Minuten oder älter, behandelt WordPress den Wartungsmodus als beendet. Eine hängende Datei sollte die Seite also nicht dauerhaft blockieren, sondern nur etwa zehn Minuten lang.

Bleibt die Meldung bei dir trotzdem länger, kommen mehrere Gründe infrage. Ein Seiten-Cache oder ein CDN kann die Wartungsseite weiter ausliefern. Oder ein Update läuft tatsächlich noch und erneuert die Datei. Löschen solltest du sie in jedem Fall, schon damit der nächste Update-Versuch nicht auf Altlasten trifft.

Warum der Wartungsmodus hängen bleibt

Ein Update muss nacheinander Dateien herunterladen, entpacken, kopieren und die Sperre wieder aufheben. An jeder Stelle kann es reißen:

• Timeout: Der Server beendet das PHP-Skript, bevor das Update fertig ist. Auf günstigem Shared Hosting passiert das bei großen Paketen.
• Abgebrochener Browser: Du schließt den Tab oder verlierst die Verbindung, während das Update noch läuft.
• Massen-Update: Du aktualisierst zehn Plugins und ein Theme auf einmal. Je mehr gleichzeitig läuft, desto eher stößt der Server an Grenzen.
• Speicherlimit: Ein Plugin braucht beim Entpacken oder Initialisieren mehr Arbeitsspeicher, als PHP erlaubt. Das Skript bricht mit einem Fatal Error ab.
• Voller Speicherplatz oder fehlende Rechte: WordPress kann Dateien nicht schreiben oder verschieben.

Die Ursache zu kennen hilft, denn sie bestimmt, ob es beim nächsten Versuch klappt. Wer ein Speicherlimit trifft, wiederholt das Update nicht blind.

Die .maintenance-Datei finden und löschen

Die Datei liegt im Hauptverzeichnis der Installation, direkt neben wp-config.php und dem Ordner wp-content. Weil der Name mit einem Punkt beginnt, blenden viele Programme sie aus.

Per FTP oder SFTP

1. Verbinde dich mit deinen Zugangsdaten des Hosters.
2. Schalte in deinem Programm die Anzeige versteckter Dateien ein. Die Option steckt je nach Programm im Server-, Ansichts- oder Einstellungsmenü.
3. Wechsle ins WordPress-Hauptverzeichnis, oft public_html, htdocs oder ein Unterordner für die Domain.
4. Lösche .maintenance.

Über den Dateimanager des Hosters

Die meisten Hoster haben in ihrem Kundenbereich einen Dateimanager. Auch dort musst du versteckte Dateien häufig erst einschalten. Wo die Option liegt, unterscheidet sich je Anbieter, meist steckt sie in den Einstellungen des Dateimanagers.

Per SSH

Hast du SSH-Zugang, geht es am schnellsten. Wechsle ins Hauptverzeichnis und lass dir die Dateien samt versteckten anzeigen:

ls -la

Taucht .maintenance in der Liste auf, löschst du sie:

rm .maintenance

Danach lädst du die Seite neu. Sie sollte sofort wieder erreichbar sein. Hilft das nicht, leere den Cache deines Caching-Plugins und, falls vorhanden, den des CDN.

Danach: halbfertiges Update erkennen

Dass die Seite wieder läuft, heißt noch nicht, dass das Update vollständig war. Zuerst schaust du, was überhaupt betroffen war. Im Backend unter Dashboard → Aktualisierungen siehst du, welche Updates noch ausstehen. Das sind die Kandidaten.

Plugins und Themes

Typische Zeichen für ein unvollständiges Plugin- oder Theme-Update:

• Das Backend meldet einen kritischen Fehler oder die Seite bleibt weiß.
• Ein Plugin ist laut Plugin-Liste aktiv, einzelne Funktionen fehlen aber.
• Im Ordner wp-content/plugins/ fehlt der Plugin-Ordner oder er ist auffällig leer.

Seit WordPress 6.3 gibt es einen Rollback für fehlgeschlagene manuelle Plugin- und Theme-Updates. Dabei verschiebt WordPress die alte Version zunächst nach wp-content/upgrade-temp-backup/ und stellt sie wieder her, wenn das Update scheitert. Bei Erfolg wird die Sicherung gelöscht. Laut der Ankündigung auf make.wordpress.org gilt das ausdrücklich für manuelle Updates von Plugins und Themes, nicht für Core-Updates. Ob Massen-Updates ebenfalls abgedeckt sind, nennt die Ankündigung nicht. Verlass dich also nicht darauf.

Siehst du einen halbfertigen Plugin-Ordner, lässt du das Plugin im Backend deaktivieren, falls du noch hineinkommst. Kommst du nicht hinein, benennst du den Ordner per FTP um, etwa in plugin-name-defekt. Danach installierst du die aktuelle Version des Plugins frisch.

Core-Update neu einspielen

Das WordPress-Update selbst kannst du ebenfalls neu einspielen. Im Backend geht das unter Dashboard → Aktualisierungen mit der Schaltfläche zum erneuten Installieren. Mit WP-CLI per SSH:

wp core version
wp core update --force --version=DEINE_VERSION

Für DEINE_VERSION setzt du die Nummer ein, die wp core version ausgibt. Laut WP-CLI-Doku erzwingt --force das Update auch dann, wenn die installierte Version höher ist als die angeforderte.

Ob alle Core-Dateien unverändert sind, prüfst du mit:

wp core verify-checksums

Der Befehl vergleicht die Dateien mit den offiziellen Prüfsummen und meldet Abweichungen oder fehlende Dateien. Eine Abweichung kann von einem abgebrochenen Update kommen, aber auch von absichtlichen Änderungen. Lies die gemeldeten Dateinamen, bevor du etwas überschreibst.

Danach schließt du das ursprüngliche Update im Backend sauber ab, am besten Plugin für Plugin, und prüfst anschließend Startseite, Login, Formulare und den Shop-Checkout, falls vorhanden.

Wenn die Seite danach immer noch hängt

Ist die .maintenance-Datei weg und die Seite lädt trotzdem nicht, war der Wartungsmodus nicht das eigentliche Problem. Das unterbrochene Update hat eine tiefere Baustelle hinterlassen. Dann zeigt die Seite meist einen anderen Fehler: einen Critical Error, einen Weißen Bildschirm oder einen 500er. Diese ordnest du über den Überblick zu WordPress-Fehlern ein. Hier hilft ein aktuelles Backup, um sauber auf den Stand vor dem Update zurückzukehren.

Stehst du unter Zeitdruck und kommst nicht weiter, hilft unser WordPress-Notfall-Service.

Eine eigene Wartungsseite bewusst nutzen

Die graue Standardmeldung kannst du ersetzen. WordPress sucht im Ordner wp-content nach einer Datei maintenance.php und gibt sie statt der Standardmeldung aus, wenn der Wartungsmodus aktiv ist. Das gilt für Updates genauso wie für Wartungsarbeiten, die du selbst planst.

Wichtig dabei: Laut Quellcode bindet WordPress deine Datei ein und beendet danach die Ausführung. Den HTTP-Status setzt WordPress in diesem Fall nicht für dich. Das übernimmst du in der Datei selbst:

<?php
http_response_code( 503 );
header( 'Retry-After: 600' );
header( 'Content-Type: text/html; charset=utf-8' );
?>
<!doctype html>
<html lang="de">
<head>
  <meta charset="utf-8">
  <title>Wartungsarbeiten</title>
</head>
<body>
  <h1>Wir sind gleich zurück</h1>
  <p>Wir aktualisieren die Seite. Bitte versuche es in einigen Minuten erneut.</p>
</body>
</html>

Ohne den 503-Status würde Google deine Wartungsseite als normale Seite mit Status 200 sehen und im ungünstigen Fall indexieren. Wer das Thema ausführlicher braucht, findet unten den Generator.

HTTP 503 und Retry-After: was für SEO zählt

Die Standardmeldung von WordPress kommt laut Quellcode mit dem Status 503 und dem Header Retry-After: 600, zusätzlich werden Cache-Header gesetzt, damit der Browser die Meldung nicht festhält. 503 bedeutet „Service nicht verfügbar” und sagt Suchmaschinen: Das ist vorübergehend, komm später wieder. Die 600 sind Sekunden, also zehn Minuten.

Für Suchmaschinen ist eine kurze Störung mit 503 deshalb unproblematisch. Kritisch wird es, wenn der Wartungsmodus tagelang hängt oder eine eigene Seite fälschlich mit 200 antwortet. Prüf nach dem Löschen der Datei im Browser oder mit curl -I https://deine-domain.de/, dass die Startseite wieder mit 200 antwortet.

Damit es nicht wieder passiert

• Einzeln updaten. Ein Plugin nach dem anderen, und jeweils kurz die Seite prüfen. Dann weißt du bei einem Fehler sofort, wer ihn verursacht.
• Den Tab offen lassen, bis WordPress den Abschluss meldet.
• Backup vor dem Update. Eines, das du schon einmal zurückgespielt hast. Ein Backup, dessen Wiederherstellung nie getestet wurde, ist eine Hoffnung.
• Staging nutzen. Größere Updates testest du zuerst auf einer Kopie → WordPress sicher updaten mit Staging.
• Ressourcen im Blick behalten. Das PHP-Speicherlimit und die maximale Ausführungszeit deines Tarifs entscheiden, wie große Updates durchlaufen.

Die Datei ist weg, aber die Seite hängt weiter? Dann steckt mehr dahinter. Schreib uns kurz, wir bringen die Seite und das Update sauber zu Ende. Wenn Updates bei dir regelmäßig zur Zitterpartie werden, nimmt dir unsere WordPress-Wartung das ab, mit Backup und Staging-Test vor jedem Update.

Und damit Besucher beim nächsten Update nicht die graue Standardmeldung sehen: eine eigene Wartungsseite mit korrektem 503-Status, in fünf Minuten erzeugt.

Auch als eigenständige Seite mit allen Anleitungen: Wartungsseiten-Generator.