WordPress „Kritischer Fehler“: Website wiederherstellen

Meldet WordPress einen „kritischen Fehler“, ist fast immer ein Plugin, das Theme, die PHP-Version oder zu wenig Arbeitsspeicher die Ursache, deine Inhalte sind in der Regel noch da. Du findest den Auslöser über die Admin-E-Mail, das Fehlerprotokoll oder das gezielte Abschalten von Plugins.

Was bedeutet der „kritische Fehler“ in WordPress?

Die Meldung bedeutet, dass beim Laden der Seite ein schwerer PHP-Fehler aufgetreten ist, nach dem WordPress nicht weiterarbeiten kann. Statt einer leeren weißen Seite zeigt WordPress seit Version 5.2 einen Hinweis und verweist auf die E-Mail an die Administrator-Adresse.

Früher endete ein solcher Fehler im „White Screen of Death“, einer komplett leeren Seite. Das Kernteam beschreibt die neue Fehlerschutz-Funktion im Beitrag „Fatal Error Recovery Mode in 5.2“ vom 16.04.2019 so: Besucher sehen einen Hinweis auf technische Schwierigkeiten, die Administratorin oder der Administrator bekommt eine E-Mail mit einem geheimen Link.

Welche Ursachen stecken typischerweise dahinter?

Typische Auslöser sind ein fehlerhaftes oder inkompatibles Plugin, ein Theme-Update, eine zu alte oder zu neue PHP-Version und ein zu knappes Speicherlimit. Seltener sind es beschädigte Dateien nach einem abgebrochenen Update oder ein falsch eingefügtes Code-Snippet in der functions.php.

Was kurz vorher passiert ist, verrät meist die Ursache:

Ein Blick auf die PHP-Version lohnt sich besonders. WordPress empfiehlt auf wordpress.org derzeit PHP 8.3 oder neuer. Laut php.net erhält PHP 8.2 nur noch bis zum 31.12.2026 Sicherheitsupdates, PHP 8.3 bis Ende 2027 und PHP 8.4 bis Ende 2028 (Stand: Oktober 2026). Stellt dein Hoster eine auslaufende Version um, zeigen sich veraltete Plugins oft genau in diesem Moment.

Wie kommst du über den Wiederherstellungsmodus wieder ins Backend?

Öffne die E-Mail, die WordPress an die Administrator-Adresse geschickt hat, und klicke auf den Link zum Wiederherstellungsmodus. Nach dem Login zeigt dir WordPress, welches Plugin oder Theme den Fehler verursacht hat, und du kannst es direkt deaktivieren.

So gehst du vor:

1. Postfach prüfen: Suche nach einer E-Mail von deiner WordPress-Installation, auch im Spam-Ordner. Sie geht an die Adresse, die unter Einstellungen → Allgemein als Administrator-E-Mail hinterlegt ist.
2. Link öffnen und anmelden: Der Link setzt ein Cookie in deinem Browser und pausiert die fehlerhafte Erweiterung nur für dich.
3. Verursacher deaktivieren: Ein Hinweis im Dashboard nennt das betroffene Plugin oder Theme. Deaktiviere das Plugin oder aktiviere ein anderes Theme.
4. Testen: Rufe die Website in einem privaten Browserfenster auf, damit du sie wie ein Besucher siehst.
5. Modus beenden: Über die Schaltfläche in der Admin-Leiste verlässt du den Wiederherstellungsmodus wieder.

Laut WordPress-Quellcode ist der Link standardmäßig einen Tag gültig, und WordPress verschickt die E-Mail ebenfalls höchstens einmal pro Tag. Ist sie weg, bleiben FTP oder die Kommandozeile.

Was tun, wenn keine E-Mail ankommt?

Kommt keine E-Mail an, aktivierst du das Debug-Protokoll in der wp-config.php und liest die Fehlermeldung in wp-content/debug.log. Dort steht meist der genaue Dateipfad, etwa im Ordner eines bestimmten Plugins. Alternativ deaktivierst du Plugins per FTP.

Für eine fehlende E-Mail gibt es mehrere Gründe: Mails aus WordPress landen im Spam, der Server verschickt sie nicht, oder die Admin-Adresse ist veraltet. Außerdem verschickt WordPress die E-Mail nur, wenn der Fehler aus einem Plugin- oder Theme-Ordner stammt. Das WordPress-Handbuch „Debugging in WordPress“ empfiehlt für die Fehlersuche diese Einträge in der wp-config.php, eingefügt oberhalb der Zeile /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Fehler landen so in debug.log, aber nicht auf der Website. Rufe danach die fehlerhafte Seite auf und öffne die Datei per FTP. Eine Zeile mit „PHP Fatal error“ und einem Pfad wie /wp-content/plugins/name-des-plugins/ verrät den Verursacher.

Das Handbuch rät ausdrücklich davon ab, die Debug-Werkzeuge dauerhaft auf Live-Seiten zu nutzen. Setze WP_DEBUG nach der Reparatur wieder auf false und lösche die Datei debug.log, denn sie kann Pfade und technische Details enthalten, die Fremde nicht sehen sollten.

Wie stellst du die Website per FTP oder WP-CLI wieder her?

Per FTP deaktivierst du alle Plugins, indem du den Ordner wp-content/plugins umbenennst, zum Beispiel in plugins_old. Läuft die Seite danach, benennst du ihn zurück und schaltest die Plugins einzeln wieder ein, bis der Fehler erneut auftritt.

So beschreibt es das offizielle Handbuch unter „Common WordPress errors“. Beim Theme gilt dasselbe: Benennst du den Ordner des aktiven Themes in wp-content/themes um, fällt WordPress auf ein installiertes Standard-Theme zurück. Achte deshalb darauf, dass immer ein aktuelles Standard-Theme wie Twenty Twenty-Five installiert bleibt.

Hast du SSH-Zugang, geht es mit der WP-CLI schneller. Laut Dokumentation lädt der globale Parameter --skip-plugins keine Plugins, --skip-themes kein Theme, sodass Befehle auch bei einer defekten Seite laufen:

wp plugin list --skip-plugins --skip-themes
wp plugin deactivate name-des-plugins --skip-plugins --skip-themes
wp plugin deactivate --all --skip-plugins --skip-themes

Liegt es am Speicher, steht im Protokoll „Allowed memory size exhausted“. WordPress versucht laut Handbuch standardmäßig, das PHP-Limit auf 40 MB bei Einzelseiten und 64 MB bei Multisite anzuheben. Mit define( 'WP_MEMORY_LIMIT', '256M' ); in der wp-config.php setzt du einen höheren Wert. Ob der Server ihn zulässt, hängt von deinem Tarif ab.

Wann ist das Zurückspielen eines Backups die richtige Wahl?

Ein Backup ist die richtige Wahl, wenn du die Ursache trotz Protokoll und Deaktivieren nicht findest, wenn Dateien beschädigt oder verändert wurden oder wenn ein Verdacht auf Schadcode besteht. Vorher lohnt sich der Blick auf das, was seit dem Backup verloren ginge.

Eine vollständige Wiederherstellung setzt Dateien und Datenbank auf den Stand des Backups zurück. Bestellungen, Kommentare, Formulareingaben und Beiträge, die danach entstanden sind, wären weg, sofern du die Datenbank mit zurückspielst. Oft reicht es, nur die Dateien eines Plugins oder Themes aus dem Backup zu holen.

Siehst du unbekannte Dateien oder Administratoren, behandle die Sache als Sicherheitsvorfall, denn ein Backup allein schließt die Lücke nicht. Hinweise bieten IT-Sicherheit für kleine Unternehmen: Die wichtigsten Schutzmaßnahmen und IT-Sicherheit für KMU: 7 Schwachstellen beheben.

💬 Meine Einschätzung

Oft lautet der erste Reflex: sofort das letzte Backup zurückspielen. Das offizielle WordPress-Handbuch nennt für den kritischen Fehler aber eine andere Reihenfolge: Admin-E-Mail prüfen, Debug-Modus aktivieren, debug.log lesen. Das hat einen guten Grund. Die Fehlerschutz-Funktion von WordPress ordnet einen Fehler gezielt einer einzelnen Erweiterung zu, die Ursache ist also meist eng eingrenzbar. Ich würde ein vollständiges Backup deshalb als letzten Schritt sehen, nicht als ersten, vor allem bei Shops mit laufenden Bestellungen.

Wie gehst du strukturiert vor und beugst dem nächsten Fehler vor?

Am sichersten gehst du nach einer festen Reihenfolge vor, vom schonendsten zum aufwendigsten Schritt. Dafür nutze ich den 5-Stufen-Rettungsplan. Vorbeugend helfen dir eine Testumgebung für Updates, aktuelle PHP-Versionen und regelmäßige Backups, die außerhalb des eigenen Servers liegen.

Der 5-Stufen-Rettungsplan im Überblick:

1. Sichern: Lade vor jedem Eingriff die wp-config.php herunter und prüfe, wann dein letztes Backup erstellt wurde.
2. Eingrenzen: Überlege, was zuletzt geändert wurde: Update, neues Plugin, PHP-Umstellung, eigener Code.
3. Lesen: Wiederherstellungsmodus über die E-Mail nutzen oder das Debug-Protokoll aktivieren und den Pfad aus der Fehlerzeile ablesen.
4. Abschalten: Verursacher im Backend, per FTP oder per WP-CLI deaktivieren, danach Website im privaten Fenster prüfen.
5. Zurückspielen: Nur wenn die Stufen 1 bis 4 nicht helfen oder Schadcode im Spiel ist, einzelne Dateien oder das vollständige Backup wiederherstellen.

Damit der Fehler gar nicht erst auf der Live-Seite landet, spielst du größere Updates zuerst in einer Staging-Umgebung ein, sofern dein Hoster eine anbietet. Halte außerdem die Administrator-E-Mail aktuell. Wie eine Sicherung aufgebaut sein sollte, erklärt Backup-Strategie für Selbstständige: Die 3-2-1-Regel umsetzen, den Begriff selbst das Glossar unter 3-2-1-Backup: Bedeutung einfach erklärt.

SSH-Zugang, wählbare PHP-Versionen und Staging im Tarif erleichtern jede Reparatur, mehr dazu unter Hosting: Bedeutung einfach erklärt. Den Gesamtüberblick über Aufbau, Technik und Betrieb einer eigenen Seite bietet Website erstellen für Selbstständige: Wege, Kosten und Ablauf.

Häufige Fragen zum kritischen Fehler in WordPress

Diese Fragen tauchen bei der Fehlersuche besonders oft auf.

Sind meine Inhalte nach einem kritischen Fehler verloren?

In der Regel nicht. Der Fehler entsteht beim Ausführen von PHP-Code, Beiträge, Seiten und Bestellungen liegen weiter in der Datenbank und die Medien im Ordner wp-content/uploads. Sobald der fehlerhafte Code deaktiviert ist, erscheinen die Inhalte wieder wie vorher.

Kann ich die Wiederherstellungs-E-Mail erneut anfordern?

Nicht beliebig. WordPress verschickt die E-Mail standardmäßig höchstens einmal pro Tag. Ist sie verloren gegangen oder der Link abgelaufen, nutzt du das Debug-Protokoll, deaktivierst Plugins per FTP oder per WP-CLI.

Warum erscheint der Fehler nur im Backend oder nur auf einer Seite?

Viele Plugins laden ihren Code nur in bestimmten Bereichen, etwa im Editor oder im Warenkorb. Der Fehler tritt dann nur dort auf, das Debug-Protokoll zeigt trotzdem den Pfad zur fehlerhaften Datei.

Sollte ich nach der Reparatur die PHP-Version wieder senken?

Nur kurzfristig als Notlösung. Laut php.net erhält PHP 8.2 nur noch bis Ende 2026 Sicherheitsupdates. Besser ist es, das betroffene Plugin zu aktualisieren oder zu ersetzen und die PHP-Version auf einem unterstützten Stand zu halten.

Quellen

Die Angaben stammen aus der offiziellen WordPress- und PHP-Dokumentation, Stand der Recherche: Oktober 2026.

• Fatal Error Recovery Mode in 5.2 · make.wordpress.org · Funktionsweise des Wiederherstellungsmodus (16.04.2019).
• WP_Recovery_Mode (Code Reference) · developer.wordpress.org · Rate-Limit der E-Mail und Gültigkeit des Links (abgerufen Oktober 2026).
• Debugging in WordPress · developer.wordpress.org · Debug-Konstanten und debug.log (abgerufen Oktober 2026).
• Common WordPress errors · developer.wordpress.org · Plugins und Theme per FTP deaktivieren (abgerufen Oktober 2026).
• Editing wp-config.php · developer.wordpress.org · Standardwerte für WP_MEMORY_LIMIT (abgerufen Oktober 2026).
• wp plugin deactivate · developer.wordpress.org · WP-CLI-Optionen und globale Parameter (abgerufen Oktober 2026).
• Requirements · wordpress.org · Empfohlene PHP- und Datenbankversionen (abgerufen Oktober 2026).
• Supported Versions · php.net · Supportzeiträume der PHP-Versionen (30.10.2026).