Es gab einen kritischen Fehler auf dieser Website: Was das heißt und wie du es behebst

Diese Meldung heißt: PHP ist beim Aufbau deiner Seite auf einen fatalen Fehler gelaufen, und WordPress hat ihn abgefangen, bevor daraus eine weiße Seite wurde. Der Fehler ist real, konkret und aufgezeichnet – WordPress weigert sich nur, ihn im Browser auszugeben, weil ein Stack Trace auf einer öffentlichen Seite Dateipfade und Code an jeden Besucher verrät.

Die Lösung ist deshalb nie Raten. Sie lautet: den echten Fehler lesen und dann danach handeln.

Was tatsächlich passiert

Seit WordPress 5.2 steckt im Core ein Handler für fatale Fehler. Stirbt PHP mitten im Request, springt dieser Handler ein, ersetzt die Absturzausgabe durch den höflichen Allgemeinplatz und versucht – sofern er ermitteln kann, welches Plugin oder Theme schuld ist – dem Administrator eine E-Mail mit einem Link in den Wiederherstellungsmodus zu schicken.

Deshalb siehst du das statt des alten White Screen of Death. Das ist ein Fortschritt, bedeutet aber auch, dass die Diagnose-Informationen standardmäßig versteckt sind. Es gibt zwei Varianten der Meldung:

Was du siehst	Wo	Was es dir sagt
”Es gab einen kritischen Fehler auf dieser Website.”	Frontend, ausgeloggt	Fataler Fehler aufgetreten, keine weiteren Details sichtbar
Dieselbe Zeile plus “Erfahre mehr über die Fehlerbehebung in WordPress”	Frontend oder wp-admin	Gleicher Fehler, WordPress verweist auf die Handbuchseite
”…Bitte prüfe den Posteingang der Administrator-E-Mail-Adresse für weitere Anweisungen.”	Frontend	Der Handler ging davon aus, eine Wiederherstellungs-E-Mail verschickt zu haben

Die dritte Variante ist die nützliche. Sie bedeutet, dass WordPress den Absturz einem konkreten Plugin oder Theme zuordnen konnte und dir einen Weg hinein anbieten wollte.

Schritt 1: die E-Mail zum Wiederherstellungsmodus prüfen

WordPress schickt den Wiederherstellungslink an die Administrator-E-Mail-Adresse der Website – die aus Einstellungen, Allgemein –, und das ist oft nicht die Adresse, mit der du dich einloggst. Sieh in diesem Postfach nach, und sieh auch in den Spam-Ordner.

Die E-Mail enthält einen langen Link, der auf etwas wie ?action=enter_recovery_mode endet. Öffnest du ihn, landest du im Wiederherstellungsmodus im wp-admin, wo das schuldige Plugin oder Theme pausiert und in einem roten Hinweis oben markiert ist. Von dort aus kannst du es ganz normal deaktivieren.

Zwei ehrliche Einschränkungen. Erstens wird die E-Mail von demselben PHP-Prozess erzeugt, der gerade abgestürzt ist, auf einem Server, der womöglich gar keinen funktionierenden Mailversand hat – Nichtzustellung ist häufig, und dass keine E-Mail kommt, sagt nichts über den Fehler aus. Zweitens läuft der Wiederherstellungslink ab (standardmäßig nach etwa einem Tag), eine ältere E-Mail im Postfach funktioniert also womöglich schlicht nicht mehr; löse durch Neuladen der Website einen frischen Absturz aus und warte auf eine neue Nachricht.

Wenn die E-Mail an eine Adresse gehen soll, die du wirklich liest, lege sie in der wp-config.php fest:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Schritt 2: den echten Fehler lesen

Das ist der Schritt, der aus einer kaputten Website eine Fünf-Minuten-Reparatur macht. Trage diese Zeilen in die wp-config.php ein, oberhalb der Zeile, ab der du nicht mehr editieren sollst:

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

Dass WP_DEBUG_DISPLAY auf false steht, ist wichtig – so bleibt der Fehler aus dem Browser draußen, wird aber weiterhin auf die Festplatte geschrieben. Du legst also während der Fehlersuche keine Pfade vor Besuchern offen.

Lade die kaputte Seite einmal neu und öffne dann wp-content/debug.log. Der letzte Eintrag sieht ungefähr so aus:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Der Dateipfad ist die Antwort. Zeigt er nach wp-content/plugins/, ist dieses Plugin die Ursache. Zeigt er nach wp-content/themes/, ist es das Theme – sehr oft etwas, das kurz zuvor in die functions.php kopiert wurde.

Taucht keine debug.log auf, ist das Verzeichnis vielleicht nicht beschreibbar, oder ein Sicherheits-Plugin hat das Logging umgeleitet. Weiche auf das PHP-Fehlerlog deines Hosters aus – die meisten Panels haben einen Bereich “Fehlerprotokoll” oder “Logs”, und derselbe fatale Fehler steht dort mit Zeitstempel.

Füge den Eintrag in den WordPress Error-Log-Decoder ein, um die PHP-Formulierung in ihre praktische Bedeutung zu übersetzen und zu sehen, welche Datei du zuerst anschauen solltest.

Lösche diese Debug-Zeilen wieder, wenn du fertig bist. Bleibt WP_DEBUG im Produktivbetrieb an, läuft die Festplatte voll, und falls WP_DEBUG_DISPLAY je zurückgestellt wird, stehen Serverpfade öffentlich auf der Seite.

Schritt 3: zurück ins wp-admin kommen

Wenn auch das wp-admin tot ist und keine Wiederherstellungs-E-Mail ankam, deaktivierst du sämtliche Plugins auf Dateisystemebene. Verbinde dich per SFTP (oder über den Dateimanager deines Hosters) und benenne einen einzigen Ordner um:

mv wp-content/plugins wp-content/plugins-off

WordPress findet die Plugins nicht mehr, deaktiviert sie deshalb alle, und der Admin-Zugang kommt fast immer zurück. Danach:

1. Benenne den Ordner zurück in plugins. Alles bleibt deaktiviert – WordPress hat die Plugins als inaktiv vermerkt.
2. Aktiviere die Plugins einzeln und lade nach jedem das Frontend.
3. Dasjenige, mit dem der Fehler zurückkehrt, ist dein Verursacher.

Ist die Website auch mit allen Plugins aus noch kaputt, ist das Theme verdächtig. Benenne den Ordner des aktiven Themes in wp-content/themes/ um; WordPress fällt dann auf ein Standard-Theme zurück, sofern eines installiert ist.

Die drei Ursachen, die du kennen solltest

Ein Plugin- oder Theme-Update, das fatal endet. Mit Abstand am häufigsten. Das Log nennt die Datei direkt. Setze dieses eine Plugin auf die vorherige Version zurück, oder lass es deaktiviert und schicke dem Entwickler die Log-Zeile.

Eine unpassende PHP-Version. Hoster aktualisieren PHP nach Plan, manchmal ohne große Vorwarnung. Code, der für ältere PHP-Versionen geschrieben wurde, lässt sich auf einer neueren unter Umständen gar nicht mehr parsen. Das Erkennungszeichen: Auf deiner Seite hat sich nichts geändert, und trotzdem war plötzlich alles kaputt. PHP im Hosting-Panel um eine Nebenversion zurückzudrehen ist eine legitime Diagnose – behandle es aber als Zeitgewinn, nicht als Lösung. Alte PHP-Versionen bekommen keine Sicherheitsupdates mehr.

Erschöpfter Arbeitsspeicher. Im Log steht “Allowed memory size of X bytes exhausted”. Das Limit in der wp-config.php anzuheben ist vertretbar:

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

Sei ehrlich, was das bewirkt: Es hebt die Obergrenze an, es behebt aber nicht, was beim Rendern einer einzigen Seite 256 MB verbraucht. Wenn das Limit immer weiter steigen muss, ist irgendetwas – meist ein Import, ein Page Builder oder eine schlecht geschriebene Abfrage – das eigentliche Problem.

Ratschläge, die du getrost ignorieren kannst

“Erhöh einfach das Memory-Limit.” Nur relevant, wenn im Log tatsächlich erschöpfter Speicher steht. Sonst ändert es nichts und verdeckt nur, dass du den Fehler nie gelesen hast.

“Installier den WordPress-Core neu.” Core-Dateien sind selten die Ursache, und sie zu ersetzen kostet Zeit, die du mit dem Lesen einer einzigen Log-Zeile besser nutzt.

“Schalt den Fatal-Error-Handler ab.” Es gibt eine Konstante dafür, und das Ergebnis ist, dass der rohe Fehler ungefiltert auf deiner öffentlichen Website steht statt abgefangen zu werden. Damit legst du Dateipfade vor Besuchern offen. Nutze stattdessen WP_DEBUG_LOG mit ausgeschaltetem WP_DEBUG_DISPLAY – gleiche Information, keine Offenlegung.

“Leer den Cache.” Ein fataler Fehler passiert in PHP, bevor ein Cache-Plugin überhaupt etwas ausliefern kann. Wird eine gecachte Kopie der Fehlerseite ausgeliefert, hilft Leeren nachdem du die Ursache behoben hast – niemals stattdessen.

Immer noch festgefahren?

Zeigt das Log auf eine Core-Datei statt auf etwas in wp-content, ist die wahrscheinlichere Erklärung ein früher geladenes Plugin, das den Zustand kaputt gemacht hat, auf den der Core sich verlässt – und nicht ein beschädigter Core. Schalte mit der Ordner-Umbenennung alles ab, prüfe, ob die Website sauber lädt, und hole die Plugins dann einzeln zurück. Das letzte, das du vor der Rückkehr des Fehlers aktivierst, ist dasjenige, das du melden solltest, mitsamt der Log-Zeile.