„Es gab einen kritischen Fehler auf deiner Website": Ursachen und Lösung Schritt für Schritt

Die Meldung „Es gab einen kritischen Fehler auf deiner Website” (in älteren Übersetzungen „Auf dieser Website ist ein kritischer Fehler aufgetreten”) ist WordPress’ höfliche Art zu sagen: Irgendein PHP-Code ist abgestürzt, und ich zeige lieber diesen Satz als eine leere Seite. Was abgestürzt ist, verrät sie nicht. Das steht woanders, und dort fangen wir an.

Schritt 1: Die E-Mail suchen

Seit WordPress 5.2 gibt es den Wiederherstellungsmodus. Beim ersten Auftreten des Fehlers schickt WordPress eine E-Mail an die Admin-Adresse (Einstellungen → Allgemein → Administrator-E-Mail-Adresse) mit Betreff „Auf deiner Website gibt es ein technisches Problem”. Darin stehen zwei wertvolle Dinge: der Name des Plugins oder Themes, das den Fehler ausgelöst hat, und ein Link, der Sie in einen Sondermodus einloggt, in dem genau dieses Plugin abgeschaltet ist.

Das ist in gut der Hälfte der Fälle schon die Lösung: Link klicken, Plugin deaktivieren, Seite prüfen, fertig. Die Mail kommt allerdings nur, wenn der Mailversand der Seite funktioniert — und der ist bei vielen Installationen kaputt, ohne dass es jemand gemerkt hat (dazu unser Beitrag WordPress-Mails landen im Spam).

Schritt 2: Die echte Fehlermeldung anzeigen

Kommt keine Mail, holen Sie sich die Meldung selbst. Dafür brauchen Sie Zugriff auf die Dateien der Seite: per FTP, per Dateimanager des Hosters oder per SSH. Öffnen Sie wp-config.php und ergänzen Sie oberhalb der Zeile /* That's all, stop editing! */:

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

Danach die Seite einmal aufrufen und unter wp-content/debug.log nachsehen. Dort steht jetzt ein Eintrag wie:

PHP Fatal error: Uncaught Error: Call to undefined function ...
in /wp-content/plugins/slider-pro/includes/loader.php:112

Die Zeile nennt Ordner und Datei. Steht dort plugins/<name>/, ist es das Plugin; steht dort themes/<name>/, ist es das Theme. Alternativ zeigt der Hoster das Fehlerprotokoll oft im Kundenmenü an („Logs”, „error.log”). Vergessen Sie nicht, die drei Zeilen hinterher wieder zu entfernen — das Protokoll wächst sonst und ist öffentlich lesbar, wenn der Ordner nicht geschützt ist.

Schritt 3: Den Verursacher abschalten, ohne Backend

Ins Backend kommen Sie bei einem kritischen Fehler meist nicht. Das ist kein Problem, denn WordPress lädt nur, was im Ordner wp-content/plugins/ liegt. Benennen Sie per FTP den Ordner des betroffenen Plugins um, etwa von slider-pro in slider-pro-aus. WordPress erkennt das Plugin nicht mehr, deaktiviert es intern, und die Seite lädt wieder. Kennen Sie den Verursacher nicht, benennen Sie den ganzen plugins-Ordner um: Läuft die Seite dann, war es eines der Plugins, und Sie können sie nach dem Zurückbenennen einzeln im Backend wieder einschalten, bis der Fehler zurückkommt.

Beim Theme geht es genauso: Ordner umbenennen, WordPress fällt auf ein Standard-Theme zurück (sofern eines installiert ist — sonst vorher twentytwentyfive hochladen).

Die fünf häufigsten Ursachen

1. Plugin oder Theme nach Update unverträglich. Meist mit einem anderen Plugin oder mit der WordPress-Version. Lösung: Verursacher abschalten, Update des Herstellers abwarten oder Alternative suchen.
2. PHP-Version gewechselt. Der Hoster hat von 7.4 oder 8.0 auf 8.2/8.3 umgestellt, und ein altes Plugin nutzt Funktionen, die es nicht mehr gibt. Kurzfristig hilft, im Hoster-Menü die alte Version zurückzustellen; das ist aber nur ein Aufschub, denn alte PHP-Versionen bekommen keine Sicherheitsupdates mehr. Dauerhaft: PHP-8-Migration.
3. Speicherlimit erreicht. Die Fehlermeldung enthält dann „Allowed memory size … exhausted”. In wp-config.php hilft define( 'WP_MEMORY_LIMIT', '256M' ); — wenn der Hoster es zulässt.
4. Abgebrochenes Update. Speicherplatz voll oder Verbindung weg; Dateien sind halb ersetzt. Lösung: WordPress-Kern manuell neu hochladen (alles außer wp-content und wp-config.php).
5. Manuell eingefügter Code. Ein Schnipsel in functions.php mit einem Tippfehler reicht. Die Zeilennummer im Protokoll führt direkt hin.

Wann Sie aufhören sollten

Zwei Situationen, in denen Sie besser nichts mehr anfassen: Erstens, wenn im Protokoll Dateien auftauchen, die Sie nicht kennen, oder das Plugin, das den Fehler wirft, nie von Ihnen installiert wurde — dann kann ein Hack dahinter stecken, und jede Reparatur verwischt Spuren. Zweitens, wenn Sie kein aktuelles Backup haben und die Fehlersuche Sie in die Datenbank führt. In beiden Fällen ist der Schaden durch einen falschen Handgriff größer als die Wartezeit auf Hilfe.

Für alles andere gilt: Das oben Beschriebene ist genau das, was wir in der WordPress-Soforthilfe tun — nur mit Werkzeugen, die es schneller machen, und mit Backup vor jedem Schritt. Eine Stunde für 99 €, Start am selben Werktag, und in den meisten Fällen ist die Seite in dieser Stunde wieder online.