„Es gab einen kritischen Fehler auf dieser Website“ – so finden und beheben Sie die Ursache

Kurz gesagt: „Es gab einen kritischen Fehler auf dieser Website“ ist die Fehlerseite, die WordPress bei einem PHP Fatal Error anzeigt. Fast immer steckt ein Plugin, das Theme oder eine neue PHP-Version beim Hoster dahinter, seltener zu wenig Arbeitsspeicher. Die genaue Ursache steht in der Recovery-Mode-E-Mail an die Admin-Adresse oder in der Datei wp-content/debug.log. Kommen Sie nicht ins Backend, deaktivieren Sie Plugins per FTP, indem Sie ihre Ordner umbenennen.

Die Meldung sieht harmlos aus: ein Satz auf weißem Hintergrund, dazu ein Link zur WordPress-Hilfe. Für Besucher ist die Website damit aber weg, oft auch das Backend unter /wp-admin. Die gute Nachricht: In den allermeisten Fällen sind keine Daten verloren. Seiten, Beiträge und Bestellungen liegen unverändert in der Datenbank. Kaputt ist nur der PHP-Code, der sie ausgibt.

Was die Meldung bedeutet

WordPress ist in PHP geschrieben. Stößt PHP auf einen Fehler, bei dem es nicht weitermachen kann – einen sogenannten Fatal Error –, bricht es die Seite ab. Früher sahen Besucher dann eine leere weiße Seite oder eine technische Meldung mit Dateipfaden. Seit WordPress 5.2 fängt WordPress solche Fehler ab und zeigt stattdessen den neutralen Hinweis auf einen kritischen Fehler.

Der Satz sagt also nur: „PHP ist abgestürzt.“ In welcher Datei und in welcher Zeile, steht woanders. Genau das finden Sie als Erstes heraus. Raten kostet mehr Zeit als Nachsehen.

Die häufigsten Ursachen

1. Plugin oder Theme nach einem Update

Das ist in meiner Praxis der häufigste Fall. Ein Plugin wurde automatisch oder per Klick aktualisiert und verträgt sich nicht mit einem anderen Plugin, dem Theme oder der WordPress-Version. Typisch sind Page Builder mit Zusatzpaketen, die nicht im Gleichschritt aktualisiert wurden – etwa eine Pro-Erweiterung, die eine neuere Version des Basis-Plugins erwartet.

2. Neue PHP-Version beim Hoster

Hoster stellen alte PHP-Versionen um, weil diese keine Sicherheitsupdates mehr bekommen. PHP 7.4 ist seit dem 28.11.2022 ohne Support, PHP 8.0 seit dem 26.11.2023, PHP 8.1 seit dem 31.12.2025. Älterer Plugin- oder Theme-Code läuft unter neuem PHP oft nicht mehr. Klassiker sind create_function() und each(), die in PHP 8.0 entfernt wurden. Wenn die Website gestern noch lief und Sie nichts geändert haben, ist das ein starkes Indiz für diese Ursache.

3. Zu wenig Arbeitsspeicher

Braucht ein Skript mehr Speicher als erlaubt, endet es mit „Allowed memory size of … bytes exhausted“. Auch das zeigt WordPress als kritischen Fehler an. Häufig passiert das beim Hochladen großer Bilder, bei Importen oder in Shops mit vielen Produkten.

4. Eigene Änderungen

Ein Code-Schnipsel in der functions.php, ein fehlendes Semikolon, eine halb hochgeladene Datei nach einem abgebrochenen FTP-Transfer. Auch das endet als kritischer Fehler – meist direkt nach dem Speichern.

Schritt 1: Die Recovery-Mode-E-Mail prüfen

Seit WordPress 5.2 schickt WordPress bei einem Fatal Error eine E-Mail an die Administrator-Adresse. Sie enthält in der Regel:

• das Plugin oder Theme, in dem der Fehler aufgetreten ist,
• die Fehlermeldung mit Datei und Zeilennummer,
• einen Login-Link für den Wiederherstellungsmodus (Recovery Mode).

Über diesen Link melden Sie sich in einer abgesicherten Sitzung an. Das fehlerhafte Plugin ist darin pausiert. Sie können es deaktivieren, aktualisieren oder löschen. Für normale Besucher bleibt die Website so lange kaputt, bis Sie das Problem tatsächlich behoben haben.

Schauen Sie auch in den Spam-Ordner. Die Mail geht an die Adresse unter „Einstellungen → Allgemein“. Das ist oft noch die Adresse einer früheren Agentur oder ein Postfach, das niemand liest. Außerdem ist der Link nur begrenzt gültig.

Schritt 2: WP_DEBUG und debug.log einschalten

Kam keine Mail, schalten Sie das Fehlerprotokoll von WordPress ein. Öffnen Sie per FTP oder im Dateimanager des Hosters die Datei wp-config.php im Hauptverzeichnis. Suchen Sie die Zeile mit WP_DEBUG und ersetzen Sie sie durch:

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

Die Zeilen müssen oberhalb von require_once ABSPATH . 'wp-settings.php'; stehen. Rufen Sie danach die kaputte Seite einmal auf. WordPress schreibt die Fehler jetzt in wp-content/debug.log. Entscheidend ist die Zeile mit PHP Fatal error, zum Beispiel:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /www/htdocs/.../wp-content/plugins/altes-slider-plugin/inc/widget.php:42

Der Pfad verrät den Verursacher. Hier ist es das Plugin im Ordner altes-slider-plugin. Steht dort wp-content/themes/…, liegt es am Theme. Steht dort ein Pfad in wp-includes, war der Auslöser oft trotzdem ein Plugin – dann lohnt der Blick auf die Zeilen darunter (den sogenannten Stack Trace).

WP_DEBUG_DISPLAY auf false sorgt dafür, dass Besucher die Meldungen nicht sehen. Das ist wichtig, denn Fehlermeldungen verraten Pfade und Details über Ihren Server. Stellen Sie WP_DEBUG nach der Reparatur wieder auf false und löschen Sie die debug.log. Sie liegt im öffentlich erreichbaren Ordner wp-content und lässt sich sonst von außen abrufen.

Schritt 3: Plugins per FTP deaktivieren

Kommen Sie nicht ins Backend, deaktivieren Sie Plugins direkt im Dateisystem. WordPress lädt ein Plugin nur, wenn sein Ordner existiert. Benennen Sie den Ordner um, ist das Plugin aus.

1. Verbinden Sie sich per FTP, zum Beispiel mit FileZilla, oder öffnen Sie den Dateimanager im Kundenmenü Ihres Hosters.
2. Wechseln Sie in wp-content/plugins/.
3. Kennen Sie das Plugin aus der Mail oder der debug.log, benennen Sie nur diesen Ordner um, etwa elementor-pro in elementor-pro_off.
4. Kennen Sie es nicht, benennen Sie den ganzen Ordner plugins in plugins_off um. Dann sind alle Plugins aus.
5. Laden Sie die Website neu. Läuft sie wieder, war es ein Plugin.

Haben Sie den ganzen Ordner umbenannt, benennen Sie ihn danach wieder in plugins zurück. WordPress führt die Plugins dann als deaktiviert. Aktivieren Sie sie im Backend einzeln und laden Sie nach jedem Plugin die Website neu. Beim fehlerhaften Plugin taucht der Fehler wieder auf – das deaktivieren Sie per FTP erneut.

Beim Theme funktioniert es genauso: Ordner in wp-content/themes/ umbenennen. WordPress weicht dann auf ein installiertes Standard-Theme wie „Twenty Twenty-Four“ aus. Die Website sieht anders aus, aber Sie kommen wieder ins Backend. Ist kein Standard-Theme installiert, laden Sie eines per FTP hoch.

Schritt 4: Die eigentliche Ursache beheben

Ein deaktiviertes Plugin ist ein Notbehelf, keine Lösung. Oft hängen Formulare, Shop-Funktionen oder das Layout daran. Je nach Ursache geht es so weiter:

• Fehlerhaftes Plugin-Update: nach einem Korrektur-Update des Herstellers suchen oder die vorherige Version einspielen.
• Neue PHP-Version: Plugin oder Theme aktualisieren. Gibt es kein Update mehr, das Plugin ersetzen oder den Code anpassen lassen. Die PHP-Version beim Hoster zurückzustellen, verschiebt das Problem nur.
• Speicher: das Limit prüfen, aber auch klären, warum so viel Speicher gebraucht wird.
• Eigener Code: die geänderte Datei aus dem Backup zurückspielen oder den Fehler in der genannten Zeile korrigieren.

Fehler, die Sie vermeiden sollten

• WordPress komplett neu installieren. Das hilft selten, weil die Ursache fast immer in Plugins oder Theme liegt.
• Ein Backup blind zurückspielen. Bei einem Shop gehen so alle Bestellungen seit dem Backup verloren. Und hat der Hoster PHP umgestellt, ist der Fehler mit dem alten Stand sofort wieder da.
• Ordner löschen statt umbenennen. Umbenennen lässt sich mit einem Klick rückgängig machen, Löschen nicht.
• WP_DEBUG_DISPLAY auf true lassen. Dann sieht jeder Besucher Ihre Serverpfade.
• Am Live-System ausprobieren. Wenn es irgend geht, testen Sie Updates zuerst auf einer Kopie der Website.

Wann Sie Hilfe holen sollten

Schwieriger wird es, wenn die debug.log einen Fehler im Theme oder in einem selbst entwickelten Plugin zeigt. Dann muss Code angepasst werden, und das sollte jemand tun, der PHP liest. Gleiches gilt, wenn der Fehler bleibt, obwohl alle Plugins aus sind, wenn ein Shop betroffen ist und jede Stunde Umsatz kostet, oder wenn Sie im Dateisystem Dateien entdecken, die Sie nicht kennen. Dann kann auch ein Hack dahinterstecken.

Professionelle Hilfe

Wenn Sie nicht weiterkommen, schaue ich mir die Website an. Ich suche die Ursache im Fehlerprotokoll, behebe sie im Code statt sie nur zu umgehen und prüfe danach, ob Formulare, Shop und Backend wieder funktionieren. Die WordPress-Reparatur beginnt bei 290 € netto. Liegt der Fehler in eigenem PHP-Code oder kam er nach einer PHP-Umstellung, passt die PHP-Fehlerbehebung: Analyse für 150 € netto, Reparatur ab 290 € netto.