WordPress-Update fehlgeschlagen: weiße Seite, kritischer Fehler und Timeouts beheben

Ein WordPress-Update läuft meist in Sekunden durch. Bricht es ab, sehen Besucher eine weiße Seite, den Hinweis auf einen kritischen Fehler oder dauerhaft die Wartungsmeldung. Diese Anleitung ordnet die häufigsten Fehlerbilder nach einem Update, erklärt die Ursache und führt Sie in fester Reihenfolge zur funktionierenden Website zurück, ohne Daten zu verlieren. Alle gezeigten Meldungen stammen aus einer Testinstanz mit WordPress 7.1.2.

Voraussetzungen

• WordPress: Die Schritte gelten für aktuelle Versionen, getestet mit WordPress 7.1.2 und PHP 8.4.
• Dateizugriff: FTP/SFTP oder der Dateimanager Ihres Hosters. Bei einer defekten Seite ist das Backend oft nicht erreichbar, deshalb ist Dateizugriff Pflicht.
• Optional SSH mit WP-CLI: beschleunigt Diagnose und Reparatur deutlich. Die Befehle führen Sie im WordPress-Verzeichnis aus.
• Rolle: Administrator im WordPress-Backend für die Kontrolle nach der Reparatur.
• Backup: ein Backup von Dateien und Datenbank aus der Zeit vor dem Update. Fertigen Sie zusätzlich vor jeder Reparatur eine Sicherung des aktuellen Zustands an, damit Sie Ihre Eingriffe zurücknehmen können.
• Zugang zum Postfach der Admin-E-Mail-Adresse: WordPress schickt bei kritischen Fehlern dorthin einen Link in den Wiederherstellungsmodus.

Schritt 1: Fehlerbild bestimmen

Rufen Sie die Startseite und /wp-admin/ in einem privaten Browserfenster auf, damit kein Browser-Cache das Bild verfälscht. Ordnen Sie das, was Sie sehen, einer Zeile der Tabelle zu. Die weiteren Schritte bauen darauf auf.

Anzeige	HTTP-Status	Wahrscheinliche Ursache	Weiter mit
„Briefly unavailable for scheduled maintenance. Check back in a minute.“ (im Labor auch bei deutscher Installation auf Englisch)	503	Datei .maintenance wurde nicht entfernt	Schritt 2
„Auf dieser Website ist ein kritischer Fehler aufgetreten.“	500	PHP-Fehler in Plugin, Theme oder Core	Schritt 3 und 4
Leere weiße Seite	meist 500	PHP-Fehler bei abgeschalteter Fehlerbehandlung oder vor deren Start	Schritt 3 und 4
„Momentan wird eine andere Aktualisierung durchgeführt.“	200 im Backend	Update-Sperre aus abgebrochenem Lauf	Schritt 5
Update lädt endlos oder „Der Download ist fehlgeschlagen.“	unterschiedlich	Zeitlimit, Speicherlimit, Dateirechte oder Verbindung	Schritt 5

Den HTTP-Status sehen Sie per Kommandozeile mit curl -I https://ihre-domain.de/ oder in den Entwicklertools des Browsers im Reiter „Netzwerk“.

Verifizieren: Sie können Ihr Fehlerbild genau einer Tabellenzeile zuordnen und kennen den HTTP-Status.

Schritt 2: Hängenden Wartungsmodus beenden

WordPress legt während eines Updates die Datei .maintenance im Hauptverzeichnis an, also dort, wo auch wp-config.php liegt. Solange sie existiert, liefert WordPress die Wartungsseite mit Status 503 aus. Bricht das Update ab, bleibt die Datei liegen. Laut Quellcode von WordPress 7.1 ignoriert WordPress die Datei zwar, wenn der darin gespeicherte Zeitstempel älter als zehn Minuten ist. Darauf sollten Sie sich nicht verlassen: Bis dahin ist die Seite offline, und das abgebrochene Update ist trotzdem unvollständig.

Löschen Sie die Datei per FTP. Achten Sie darauf, dass Ihr FTP-Programm versteckte Dateien anzeigt, denn Dateien mit Punkt am Anfang werden oft ausgeblendet. Mit WP-CLI geht es in einem Schritt:

wp maintenance-mode status
wp maintenance-mode deactivate

Im Labor meldete wp maintenance-mode deactivate bei einer von Hand angelegten Datei mit fehlerhaftem Inhalt „Maintenance mode already deactivated“, obwohl die Seite weiterhin 503 lieferte. In diesem Fall entfernen Sie die Datei direkt:

rm .maintenance

Wichtig: Die Wartungsmeldung ist nur das Symptom. Prüfen Sie danach unter „Dashboard > Updates“, ob Core, Plugins und Themes wirklich die neue Version haben, und wiederholen Sie das abgebrochene Update einzeln.

Verifizieren: curl -I auf die Startseite liefert nicht mehr 503, und „Dashboard > Updates“ zeigt keine halb fertigen Aktualisierungen.

Schritt 3: Ursache im Fehlerprotokoll finden

Seit WordPress 5.2 fängt eine eingebaute Fehlerbehandlung fatale PHP-Fehler ab und zeigt statt einer weißen Seite den Hinweis auf einen kritischen Fehler. Gleichzeitig verschickt WordPress eine E-Mail an die Admin-Adresse mit dem Namen des betroffenen Plugins oder Themes und einem Link in den Wiederherstellungsmodus. Prüfen Sie dieses Postfach zuerst, auch den Spam-Ordner.

Fehlt die E-Mail, aktivieren Sie das Debug-Log in der wp-config.php oberhalb der Zeile „That's all, stop editing!“:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Rufen Sie die fehlerhafte Seite erneut auf und lesen Sie das Ende von wp-content/debug.log. Entscheidend ist die Zeile mit PHP Fatal error und der Dateipfad dahinter. Liegt die Datei unter wp-content/plugins/NAME/, ist das Plugin NAME die Ursache, bei wp-content/themes/NAME/ das Theme. Im Labor erzeugte ein absichtlich zu hoher Speicherbedarf diesen Eintrag:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 943718432 bytes) in /var/www/html/wp-content/mu-plugins/mem.php on line 2

Schreibt WordPress kein debug.log, weil der Fehler vor dem Laden von WordPress auftritt, finden Sie ihn im PHP-Fehlerprotokoll des Hosters. Wo das liegt, zeigt die Verwaltungsoberfläche oder der Support. Ausführlich erklärt die Anleitung WordPress Debug-Modus aktivieren und Error-Logs analysieren, wie Sie die Einträge lesen.

Verifizieren: Sie haben eine konkrete Fehlerzeile mit Dateipfad und können sie einem Plugin, Theme oder einer Core-Datei zuordnen.

Schritt 4: Plugin oder Theme gezielt abschalten

Mit Link aus der Wiederherstellungs-E-Mail melden Sie sich an und deaktivieren das genannte Plugin im Backend unter „Plugins“. Ohne diesen Link nutzen Sie WP-CLI. Der Schalter --skip-plugins verhindert, dass das defekte Plugin beim Aufruf von WP-CLI selbst geladen wird:

wp plugin list --status=active --skip-plugins --skip-themes
wp plugin deactivate PLUGINNAME --skip-plugins --skip-themes

Im Labor meldete der zweite Befehl „Plugin 'altlast' deactivated. Success: Deactivated 1 of 1 plugins.“, obwohl das Frontend zu diesem Zeitpunkt nur den kritischen Fehler zeigte. Ist die Ursache ein Theme, aktivieren Sie ein mitgeliefertes Standard-Theme:

wp theme activate twentytwentyfive --skip-plugins --skip-themes

Ohne SSH benennen Sie per FTP den Ordner des Plugins um, etwa wp-content/plugins/NAME in NAME.aus. WordPress findet die Plugin-Datei dann nicht mehr und lädt sie nicht. Lässt sich die Ursache nicht eingrenzen, benennen Sie den gesamten Ordner wp-content/plugins um, dann startet WordPress ohne Plugins. Benennen Sie danach alles zurück und prüfen Sie unter „Plugins“, welche Erweiterungen aktiv sind. Aktivieren Sie sie einzeln und laden Sie nach jedem Plugin die Website neu, bis der Fehler wieder auftritt.

Anschließend haben Sie drei Wege: auf ein Korrektur-Update des Herstellers warten, die vorherige Plugin-Version einspielen oder das Plugin ersetzen. Die Rückkehr auf eine ältere Version geht mit wp plugin install NAME --version=X.Y --force, ist aber nur eine Übergangslösung, weil ältere Versionen bekannte Sicherheitslücken enthalten können. Liegt der Fehler an der PHP-Version, hilft die Anleitung PHP-Version für WordPress aktualisieren und Kompatibilität prüfen.

Verifizieren: Die Startseite lädt mit Status 200, /wp-admin/ ist erreichbar, und debug.log erhält beim erneuten Aufruf keinen neuen Fatal-Eintrag.

Schritt 5: Update-Sperre, Zeitüberschreitung und beschädigte Dateien

Update-Sperre: Beim Core-Update setzt WordPress in der Datenbank die Option core_updater.lock. Laut Quellcode läuft die Sperre nach 15 Minuten ab. Bricht ein Update ab, erscheint bis dahin „Momentan wird eine andere Aktualisierung durchgeführt.“ Warten Sie die 15 Minuten ab. Wenn sicher kein Update mehr läuft, können Sie die Sperre auch entfernen:

wp option get core_updater.lock
wp option delete core_updater.lock

Zeitüberschreitung und Speicher: Laut WordPress-Dokumentation entsteht der Fehler „Connection Timed Out“, wenn die Website mehr verlangt, als der Server leisten kann, besonders bei knappem Speicherlimit. Das Handbuch empfiehlt, Plugins zu deaktivieren, auf ein Standard-Theme zu wechseln, das Speicherlimit über WP_MEMORY_LIMIT in der wp-config.php zu erhöhen und die maximale Ausführungszeit in der php.ini anzuheben. Die beiden PHP-Werte legt meist der Hoster fest:

define( 'WP_MEMORY_LIMIT', '256M' );

Die Konstante kann das PHP-Limit des Hosters nicht übersteigen. Liegt dieses niedriger, müssen Sie es beim Hoster anheben lassen.

Beschädigte Core-Dateien: Ist das Core-Update mitten im Kopieren abgebrochen, passen Dateien verschiedener Versionen nicht zusammen. WP-CLI vergleicht alle Core-Dateien mit den offiziellen Prüfsummen:

wp core verify-checksums

Findet der Befehl Abweichungen, endet er mit „Error: WordPress installation doesn't verify against checksums.“ Laden Sie dann die Core-Dateien derselben Version neu. --skip-content lässt wp-content mit Ihren Plugins, Themes und Uploads unberührt, und wp-config.php wird nicht überschrieben:

wp core version
wp core download --version=7.1.2 --locale=de_DE --skip-content --force

Setzen Sie für --version die Ausgabe von wp core version ein. Ohne SSH folgen Sie dem manuellen Weg aus der offiziellen Dokumentation: Paket herunterladen und die Ordner wp-admin und wp-includes per FTP ersetzen, ohne wp-content anzufassen.

Verifizieren: wp core verify-checksums meldet „Success: WordPress installation verifies against checksums.“, und das Update lässt sich unter „Dashboard > Updates“ ohne Sperrhinweis starten.

Schritt 6: Aufräumen und Wiederholung vermeiden

Setzen Sie WP_DEBUG nach der Reparatur wieder auf false und löschen Sie wp-content/debug.log. Die Datei enthält Serverpfade und liegt im öffentlich erreichbaren Verzeichnis. Entfernen Sie umbenannte Plugin-Ordner, sobald das Ersatz-Plugin läuft.

Die meisten Update-Fehler lassen sich vermeiden, wenn Updates nicht gesammelt nach Monaten eingespielt werden, sondern regelmäßig und einzeln, mit Backup davor und einem kurzen Funktionstest danach. Das ist eine wiederkehrende Aufgabe. Wer sie nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und wöchentliche Backups auf externen Speicher.

Verifizieren: In der wp-config.php steht WP_DEBUG auf false, wp-content/debug.log existiert nicht mehr, und „Werkzeuge > Website-Zustand“ meldet keine kritischen Probleme.

Typische Fehler

• Weiße Seite trotz Fehlerbehandlung: Ist in der wp-config.php die Konstante WP_DISABLE_FATAL_ERROR_HANDLER auf true gesetzt, zeigt WordPress keinen Hinweis mehr. Im Labor lieferte die Seite dann Status 500 mit leerem Inhalt. Entfernen Sie die Konstante auf Produktivseiten.
• Datei .maintenance nicht sichtbar: Das FTP-Programm blendet Dateien mit Punkt am Anfang aus. Aktivieren Sie die Anzeige versteckter Dateien.
• WP-CLI stürzt selbst ab: Ohne --skip-plugins lädt WP-CLI das defekte Plugin und endet mit demselben Fatal Error.
• Verzeichnis-Fehler beim Update: Meldungen wie „Das Verzeichnis konnte nicht erstellt werden.“ oder „Die Aktualisierung konnte nicht installiert werden, da einige Dateien nicht kopiert werden konnten. Dies liegt meist an inkonsistenten Dateiberechtigungen.“ deuten auf falsche Eigentümer oder Rechte. Der Webserver-Benutzer braucht Schreibrechte auf wp-content und beim Core-Update auf das ganze Verzeichnis.
• Zusätzliche Dateien bei der Prüfsummenprüfung: wp core verify-checksums meldet auch Dateien, die nicht zu WordPress gehören, etwa „Warning: File should not exist: wp-includes/version.php.bak“. Solche Dateien in Core-Ordnern sollten Sie prüfen und entfernen, denn Angreifer legen dort gern Schadcode ab.

Häufige Fragen

Soll ich sofort das Backup zurückspielen?

Nicht als ersten Schritt. Ein Restore setzt auch Bestellungen, Formulareingänge und Kommentare seit dem Backup zurück. Wenn Sie die Ursache in wenigen Minuten eingrenzen können, ist die gezielte Reparatur schonender. Das Backup ist die Rückfallebene, wenn die Diagnose nicht weiterführt.

Warum kommt keine E-Mail zum Wiederherstellungsmodus?

WordPress versendet sie über seine Mailfunktion, standardmäßig über den Mailversand des Servers. Ist der Mailversand nicht eingerichtet oder landet die Nachricht im Spam, kommt sie nicht an. Der Weg über das Debug-Log funktioniert unabhängig davon.

Ist mein Inhalt verloren, wenn die Seite weiß bleibt?

Nein. Beiträge, Seiten und Einstellungen liegen in der Datenbank, Medien unter wp-content/uploads. Ein fehlgeschlagenes Update betrifft in aller Regel Programmdateien.

Kann ich automatische Updates danach einfach abschalten?

Das verlagert das Problem: Ohne Updates bleiben Sicherheitslücken offen. Sinnvoller ist ein fester Rhythmus mit Backup und Test.

Testumfang

Wir haben mit WordPress 7.1.2 im Labor die hängende Wartungsdatei mit Status 503 und einen kritischen Fehler durch Speicherüberlauf nachgestellt. Die Reparatur per WP-CLI funktionierte, etwa das Deaktivieren aller Plugins mit --skip-plugins. Auffällig war, dass bei abgeschalteter Fehlerbehandlung nur eine weiße Seite erscheint.

Nicht geprüft haben wir die E-Mail des Wiederherstellungsmodus und die Reparatur per FTP-Programm, testen Sie diese Wege daher zuerst auf einer Kopie.

Fazit

Ein fehlgeschlagenes Update ist fast immer reparabel, wenn Sie strukturiert vorgehen: Fehlerbild bestimmen, Log lesen, Verursacher gezielt abschalten, Core-Dateien prüfen und erst dann über ein Restore nachdenken. Wenn Sie Updates und Backups dauerhaft in fachkundige Hände geben möchten, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler selbst beheben
• PHP-Version für WordPress aktualisieren: Kompatibilität prüfen und sicher umstellen
• WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen
• WordPress Advanced Administration: Common WordPress errors
• WordPress Advanced Administration: Editing wp-config.php
• WP-CLI: wp core verify-checksums