--- title: "WordPress-Update fehlgeschlagen: weiße Seite, kritischer Fehler und Timeouts beheben" date: 2026-09-30T21:02:28+02:00 modified: 2026-10-23T22:17:04+02:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-update-fehler-beheben-weisse-seite-kritischer-fehler keywords: - WordPress - Updates - Fehlerbehebung - WP-CLI - Debugging reading_time: 9 --- # 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. **Kurzfassung:** Bestimmen Sie zuerst das Fehlerbild: Wartungsmeldung, kritischer Fehler, weiße Seite oder Zeitüberschreitung. Hängt die Wartungsmeldung, löschen Sie die Datei `.maintenance` im WordPress-Verzeichnis. Bei kritischem Fehler oder weißer Seite aktivieren Sie das Debug-Log, finden das verursachende Plugin oder Theme über den Dateipfad und deaktivieren es per WP-CLI oder durch Umbenennen des Ordners. Beschädigte Core-Dateien erkennen Sie mit `wp core verify-checksums` und ersetzen sie mit `wp core download --skip-content --force`. ## 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“. > **Prüfen:** 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: ```bash $ 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: ```bash $ 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. > **Prüfen:** `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!“: Datei: `wp-config.php` ```php 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: ```plaintext 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](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben), wie Sie die Einträge lesen. > **Prüfen:** 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: ```bash $ 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: ```bash $ 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](https://s-edv.com/anleitungen/wordpress-php-version-aktualisieren-kompatibilitaet-pruefen). > **Prüfen:** 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: ```bash $ 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: Datei: `php.ini` ```php 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: ```bash $ 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: Datei: `wp-config.php` ```bash 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. > **Prüfen:** `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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=9) übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und wöchentliche Backups auf externen Speicher. > **Prüfen:** 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. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=9). ## Weiterführende Anleitungen und Quellen - [WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler selbst beheben](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) - [PHP-Version für WordPress aktualisieren: Kompatibilität prüfen und sicher umstellen](https://s-edv.com/anleitungen/wordpress-php-version-aktualisieren-kompatibilitaet-pruefen) - [WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten) - [WordPress Advanced Administration: Common WordPress errors](https://developer.wordpress.org/advanced-administration/wordpress/common-errors/) - [WordPress Advanced Administration: Editing wp-config.php](https://developer.wordpress.org/advanced-administration/wordpress/wp-config/) - [WP-CLI: wp core verify-checksums](https://developer.wordpress.org/cli/commands/core/verify-checksums/)