WordPress nach Update kaputt? Ursachen, Soforthilfe & Wiederherstellung

Besonders tückisch sind Fehler, die nur einzelne Funktionen betreffen. Die Website lädt scheinbar ganz normal, aber beispielsweise:

• Kontaktformulare senden keine Nachrichten mehr.
• Der WooCommerce-Checkout funktioniert nicht.
• Bestellungen können nicht abgeschlossen werden.
• Ein Slider oder Menü reagiert nicht.
• Ein Login oder Mitgliederbereich ist defekt.
• Caching funktioniert nicht mehr.
• Cronjobs werden nicht ausgeführt.
• Auf Smartphones entsteht plötzlich ein JavaScript-Fehler.

Eine funktionierende Startseite ist noch kein Beweis dafür, dass die Website nach dem Update vollständig funktioniert.

WordPress besteht nicht nur aus WordPress selbst.

Eine typische Unternehmenswebsite kombiniert den WordPress-Core mit einem Theme, einem Page Builder, mehreren Plugins, individuellen Code-Anpassungen, einer bestimmten PHP-Version und verschiedenen externen Diensten.

All diese Komponenten greifen ineinander.

Das lässt sich gut mit einem Betriebssystem vergleichen. Nur weil ein neues Betriebssystem sauber funktioniert, bedeutet das nicht automatisch, dass jede zehn Jahre alte Software damit kompatibel ist.

Bei WordPress ist es ähnlich.

Eine neue Core-Version kann interne Funktionen verändern. PHP kann bestimmte bisher tolerierte Programmierweisen nicht mehr akzeptieren. Plugins können voneinander abhängen. Themes können Funktionen nutzen, die inzwischen als veraltet gelten.

Das Update ist dann häufig nicht unmittelbar die Ursache, sondern der Auslöser, der eine bereits vorhandene Inkompatibilität sichtbar macht.

Genau deshalb ist die Aussage „WordPress 7.1 hat meine Website zerstört“ technisch oft zu einfach.

Ein aktueller Fall aus dem August 2026 zeigt sehr gut, wie komplex solche Abhängigkeiten sein können.

Die Meldung selbst verrät zunächst relativ wenig.

WordPress versucht damit vor allem zu verhindern, dass technische Fehlerdetails öffentlich an Besucher ausgegeben werden.

Im Hintergrund ist normalerweise ein schwerwiegender PHP-Fehler aufgetreten.

Seit WordPress 5.2 existiert dafür der sogenannte Recovery Mode. Erkennt WordPress einen geeigneten Fatal Error während eines normalen Seitenaufrufs, kann eine Nachricht an die hinterlegte Administrator-E-Mail-Adresse gesendet werden.

Diese E-Mail enthält häufig bereits Informationen darüber, welches Plugin oder Theme den Fehler ausgelöst hat.

Über den enthaltenen Recovery-Link kann sich ein Administrator in einer speziellen Sitzung anmelden. Die problematische Erweiterung wird für diese Sitzung pausiert, sodass das Backend unter Umständen wieder erreichbar ist. Mehr zum Recovery Mode bei WordPress.org.

Kommt keine Nachricht an, bedeutet das nicht automatisch, dass WordPress keine Informationen über den Fehler besitzt. Die Mail kann beispielsweise aufgrund der Server-Mail-Konfiguration nicht zugestellt worden sein.

Dann lohnt sich der Blick in die Server- und PHP-Logs.

Der wichtigste Hinweis steckt häufig bereits in der Fehlermeldung.

Ein typischer Fatal Error enthält einen Dateipfad. Darin kann beispielsweise stehen:

Taucht dort eindeutig der Ordner eines bestimmten Plugins auf, ist dieses Plugin zumindest am Fehler beteiligt.

Das bedeutet allerdings nicht zwingend, dass das Plugin allein „schuld“ ist.

Ein Plugin kann eine Funktion eines anderen Plugins aufrufen. Ein Hook kann von mehreren Erweiterungen verwendet werden. Eine neue PHP-Version kann Code ablehnen, der zuvor funktioniert hat.

Der Dateipfad ist der Ausgangspunkt der Analyse – nicht automatisch das abschließende Urteil.

Wenn der Fehler unmittelbar nach einem einzigen Plugin-Update aufgetreten ist, ist die Sache vergleichsweise einfach.

Wurden dagegen gleichzeitig WordPress, zehn Plugins, Elementor, WooCommerce und ein Theme aktualisiert, wird die Ursachenanalyse erheblich schwieriger.

Genau deshalb sind große „Alles aktualisieren“-Aktionen auf geschäftskritischen Websites keine besonders gute Update-Strategie.

Hier wird häufig empfohlen, einfach alle Plugins zu deaktivieren.

Als Notfallmaßnahme kann das sinnvoll sein. Für eine saubere Diagnose ist es jedoch besser, zuerst vorhandene Informationen auszuwerten.

• Prüfen Sie die Recovery-Mail.
• Prüfen Sie PHP Error Logs.
• Prüfen Sie debug.log, sofern Logging bereits aktiviert ist.
• Prüfen Sie, welche Komponente zuletzt aktualisiert wurde.
• Prüfen Sie die Versionshistorie im Hosting oder Wartungssystem.

Erst wenn daraus kein klarer Kandidat hervorgeht, kann ein kontrollierter Konflikttest durchgeführt werden.

WordPress beschreibt für den Fall eines nicht erreichbaren Backends auch die Möglichkeit, den kompletten Ordner /wp-content/plugins/ temporär umzubenennen. Dadurch werden die normalen Plugins deaktiviert und können anschließend schrittweise wieder aktiviert werden.

Ein Fatal Error sieht für jemanden ohne Entwicklungserfahrung zunächst ziemlich kryptisch aus.

Für die Fehlersuche sind solche Meldungen allerdings extrem wertvoll.

WordPress besitzt mit WP_DEBUG und WP_DEBUG_LOG eigene Debugging-Funktionen. Wird das Logging korrekt aktiviert, können Fehler typischerweise in einer Datei wie dieser protokolliert werden:

Die offizielle WordPress-Dokumentation weist ausdrücklich darauf hin, Debug-Funktionen nicht unkontrolliert auf öffentlichen Produktionsseiten laufen zu lassen. Fehler können technische Informationen enthalten und Logs sollten nicht öffentlich zugänglich sein. WordPress Debugging-Dokumentation ansehen.

Für eine professionelle Fehlersuche interessieren insbesondere:

Schon diese Informationen reichen häufig aus, um aus „WordPress ist komplett kaputt“ ein sehr konkretes Problem zu machen.

Ein Rollback kann eine sinnvolle Notfallmaßnahme sein – aber es sollte nicht die erste reflexartige Reaktion sein.

Angenommen, eine neue Plugin-Version verursacht einen reproduzierbaren Fatal Error und die vorherige Version hat korrekt funktioniert. Dann kann ein kontrolliertes Zurücksetzen auf die vorherige Version sinnvoll sein, bis der Hersteller einen Fix veröffentlicht.

Ein Rollback ist jedoch keine universelle Reparaturmethode.

Besonders beim WordPress-Core sollte sorgfältig geprüft werden, warum eine ältere Version wiederhergestellt werden soll.

Neue WordPress-Versionen enthalten nicht nur Funktionen, sondern auch Fehlerbehebungen und möglicherweise sicherheitsrelevante Änderungen. Dauerhaft auf einer alten Version zu bleiben, nur weil eine Erweiterung nicht kompatibel ist, verschiebt das Problem lediglich.

Die bessere langfristige Lösung ist meistens: Die inkompatible Komponente identifizieren, eine kompatible Version installieren, gegebenenfalls den Hersteller kontaktieren und anschließend wieder einen aktuellen, unterstützten Softwarestand herstellen.

Ein vollständiges Backup kann im Notfall Gold wert sein.

WordPress empfiehlt ausdrücklich, vor Core- und Plugin-Updates ein aktuelles Backup anzulegen. WordPress Update-Dokumentation ansehen.

Trotzdem ist „Backup einspielen“ nicht automatisch die beste erste Lösung.

Bei einer einfachen Unternehmenswebsite, auf der sich seit dem Backup nichts verändert hat, kann eine Wiederherstellung relativ unkompliziert sein.

Bei einem WooCommerce-Shop sieht das anders aus.

Stellen Sie dort ein Backup von gestern wieder her, können neue Bestellungen, Kundenkonten, Lageränderungen oder andere Daten verloren gehen.

Dasselbe gilt für Websites mit Formularspeicherung, Mitgliederbereichen, Buchungssystemen oder regelmäßig aktualisierten Inhalten.

Vor jeder Wiederherstellung sollte deshalb geprüft werden, welche Daten seit dem Backup hinzugekommen sind.

Das ist einer der häufigsten Fehler nach einem Update-Problem.

Die Website lädt wieder. Die Startseite sieht normal aus. Problem gelöst? Nicht unbedingt.

Bei einer professionellen Funktionsprüfung sollten die wirklich geschäftsrelevanten Abläufe getestet werden.

Ein Update gilt deshalb erst dann als erfolgreich repariert, wenn die relevanten Geschäftsprozesse wieder funktionieren.

Wenn eine Website nach einem Update bereits fehlerhaft ist, sollte nicht sofort der nächste Stapel Updates gestartet werden.

Das verändert die Ausgangssituation.

Vielleicht verursacht Plugin A den Fehler.

Dann aktualisieren Sie zusätzlich Plugin B, C, D und das Theme.

Plugin B verändert die Datenbank. Plugin C verändert JavaScript-Dateien. Das Theme aktualisiert Templates.

Und plötzlich wissen Sie nicht mehr, welche Änderung welchen Effekt hatte.

Genau deshalb ist ein dokumentierter Update-Prozess bei professionell betreuten WordPress-Websites so wertvoll.

Automatische Updates sind nicht grundsätzlich schlecht.

Gerade Sicherheitsupdates sollten nicht monatelang liegen bleiben.

WordPress unterstützt automatische Updates für Plugins und Themes und weist gleichzeitig darauf hin, dass regelmäßige Backups vorhanden sein sollten, um bei Problemen auf einen früheren Zustand zurückkehren zu können. Dokumentation zu automatischen Updates.

Bei einer kleinen privaten Website ist ein vollautomatischer Update-Prozess häufig vertretbar.

Bei einer Website, über die täglich Leads, Buchungen oder Bestellungen entstehen, sollte die Strategie differenzierter sein.

Denn das eigentliche Problem ist nicht, dass Updates installiert werden.

Das Problem ist ein Update ohne:

• aktuelles Backup
• Monitoring
• Funktionskontrolle
• Rollback-Möglichkeit
• Kenntnis der vorherigen Versionsstände
• und jemanden, der bei einem Fehler reagieren kann

Ein Update um 03:00 Uhr hilft wenig, wenn am nächsten Vormittag niemand bemerkt, dass seit sieben Stunden kein Checkout mehr funktioniert.

Eine Staging-Website ist eine separate Kopie der Live-Website.

Dort können Updates durchgeführt werden, ohne dass Besucher unmittelbar betroffen sind.

Das ist besonders sinnvoll bei größeren WordPress-Systemen mit WooCommerce, individuellen Plugins, komplexem Elementor-Aufbau, Mitgliedersystemen oder externen Schnittstellen.

Auf Staging kann zunächst geprüft werden:

Erst danach wird das Update auf der Live-Seite durchgeführt.

Natürlich kann auch ein erfolgreicher Staging-Test nicht jedes Problem ausschließen. Serverkonfiguration, Datenbestand oder Cache-Zustand können sich zwischen Staging und Produktion unterscheiden.

Das Risiko lässt sich dadurch aber erheblich reduzieren.

Nicht jeder Update-Fehler ist ein Fatal Error.

Während eines WordPress-Updates wird normalerweise vorübergehend eine .maintenance-Datei angelegt.

Wird der Update-Prozess abgebrochen, kann diese Datei bestehen bleiben.

Die Website zeigt dann möglicherweise dauerhaft eine Meldung wie:

„Wegen geplanter Wartungsarbeiten kurzzeitig nicht verfügbar.“

In diesem Fall kann die .maintenance-Datei im WordPress-Hauptverzeichnis geprüft und gegebenenfalls entfernt werden.

Die offizielle WordPress-Dokumentation führt diesen Fall ebenfalls als typisches Problem nach fehlgeschlagenen Updates auf. WordPress Update-Dokumentation.

Auch das kann passieren.

Ein Timeout, fehlender Speicherplatz, falsche Dateirechte oder ein unterbrochener Prozess können dazu führen, dass nicht alle WordPress-Dateien korrekt ersetzt wurden.

In solchen Fällen kann eine kontrollierte manuelle Aktualisierung notwendig werden.

WordPress dokumentiert dafür einen manuellen Update-Prozess, bei dem Core-Dateien aus einer sauberen WordPress-Version ersetzt werden. Dabei müssen wp-content und insbesondere eigene Inhalte sorgfältig behandelt werden.

Wer dabei versehentlich die falschen Ordner überschreibt oder löscht, kann den Schaden allerdings vergrößern.

Bei Unternehmenswebsites sollte deshalb zunächst geklärt werden, ob tatsächlich ein beschädigter Core vorliegt oder ob lediglich ein Plugin einen Fatal Error erzeugt.

Eine Website, die direkt nach einem Update ausfällt, wurde nicht automatisch gehackt.

Ein PHP Fatal Error aufgrund einer inkompatiblen Funktion ist zunächst ein technisches Problem.

Trotzdem sollte man beide Themen nicht vollständig voneinander trennen.

Veraltete Plugins und Themes gehören zu den Gründen, warum WordPress-Installationen überhaupt Sicherheitsrisiken entwickeln. Updates einfach dauerhaft zu deaktivieren, nur weil irgendwann einmal ein Update einen Fehler verursacht hat, ist deshalb keine sinnvolle Strategie.

Wenn Sie statt eines Update-Problems Hinweise auf Malware, fremde Weiterleitungen oder unbekannte Administratoren feststellen, lesen Sie auch unseren Leitfaden „WordPress gehackt – was tun?“ .

Bei einer kleinen Website ohne geschäftskritische Funktionen kann ein technisch versierter Betreiber viele Probleme selbst beheben.

Professionelle Unterstützung ist dagegen sinnvoll, wenn:

• das WordPress-Backend vollständig nicht erreichbar ist
• die Ursache nicht eindeutig identifiziert werden kann
• ein WooCommerce-Shop betroffen ist
• aktuelle Bestellungen oder Kundendaten erhalten werden müssen
• mehrere Plugins gleichzeitig aktualisiert wurden
• nach einem Rollback weiterhin Fehler auftreten
• PHP-, Datenbank- oder Serverlogs nicht eindeutig sind
• mehrere Reparaturversuche bereits fehlgeschlagen sind

Besonders problematisch wird es, wenn mehrere Reparaturversuche hintereinander durchgeführt wurden.

• WordPress downgraded.
• Backup eingespielt.
• Plugins gelöscht.
• PHP-Version geändert.
• Theme gewechselt.
• Datenbank repariert.
• Caches gelöscht.

Spätestens dann wird die ursprüngliche Ursache immer schwerer rekonstruierbar.

Eine professionelle Analyse versucht deshalb zuerst festzustellen, was sich unmittelbar vor dem Ausfall verändert hat, und arbeitet von dort aus weiter.

Das Ziel kann nicht sein, jedes Update-Problem zu hundert Prozent auszuschließen.

WordPress ist ein erweiterbares System mit Tausenden Plugins, Themes, PHP-Versionen und Serverkonfigurationen. Selbst ausführliche Tests aller Hersteller können nicht jede denkbare Kombination abdecken.

Der WordPress-7.1-/WP-Rocket-Fall ist dafür ein gutes Beispiel.

WP Rocket beschreibt in seinem eigenen Post-Mortem, dass das Problem bereits während der Entwicklungsphase von WordPress 7.1 gemeldet worden war, sich in den damaligen Tests jedoch nicht reproduzieren ließ. Erst die Kombination mit weiteren Komponenten machte den Fehler unter realen Bedingungen deutlich sichtbar.

Dazu gehören verlässliche Backups, Monitoring, dokumentierte Versionsstände, kontrollierte Updates, eine Möglichkeit zum Rollback sowie Funktionsprüfungen nach größeren Änderungen.

Dann wird aus:

„Unsere Website ist seit gestern kaputt und niemand weiß warum.“

im Idealfall:

„Das letzte Plugin-Update erzeugt einen Fatal Error. Die vorherige Version wurde wiederhergestellt und wir warten auf den Hersteller-Fix.“

Das ist ein erheblicher Unterschied.

Updates selbst dauern häufig nur wenige Minuten.

Die eigentliche Arbeit einer professionellen WordPress-Wartung passiert davor und danach.

Genau deshalb ist eine betreute Website nicht dasselbe wie eine Website, bei der lediglich automatische Updates aktiviert wurden.

Automatisierung kann einen Wartungsprozess unterstützen. Sie ersetzt ihn nicht.

Mehr zu laufenden Updates, Backups, Monitoring und technischer Betreuung finden Sie auf unserer Seite zur WordPress-Wartung und Website-Betreuung .