Kritischer Fehler auf deiner Website: WordPress beheben

„Es gab einen kritischen Fehler auf deiner Website“ bedeutet: PHP ist beim Aufbau der Seite mit einem fatalen Fehler abgebrochen, und WordPress zeigt statt einer weißen Seite diese Meldung. Der Fehler sitzt fast immer in einem Plugin oder Theme, oft direkt nach einem Update oder einem Wechsel der PHP-Version. Behoben wird er in dieser Reihenfolge: Wiederherstellungs-Mail suchen, sonst das Fehlerprotokoll lesen, den Verursacher abschalten, dann die eigentliche Ursache beheben.

Die Meldung ist keine Diagnose, sondern der Hinweis, wo die Diagnose liegt. WordPress kennt den Verursacher in den meisten Fällen genau und schreibt ihn in eine Mail. Wer sofort Plugins löscht oder die Seite neu installiert, wirft diese Information weg.

Der Wortlaut hängt von der Version ab. Bis WordPress 6.6 hieß es in der deutschen Übersetzung „Es gab einen kritischen Fehler auf deiner Website. Bitte überprüfe den Posteingang deiner Website-Administrator-E-Mail-Adresse für weitere Anweisungen.“, seit 6.7 „auf dieser Website“ mit einem Verweis auf die Support-Foren (Übersetzungen auf translate.wordpress.org). Steht nur „Auf dieser Website ist ein kritischer Fehler aufgetreten.“ ohne Hinweis aufs Postfach, hat WordPress keine Mail verschickt; warum, steht im nächsten Abschnitt.

Was hinter der Meldung steckt#

PHP unterscheidet zwischen Warnungen, nach denen das Skript weiterläuft, und fatalen Fehlern, nach denen es „halted“ ist, also anhält (PHP-Handbuch, Fehlerkonstanten). Typische fatale Fehler sind ein Aufruf einer Funktion, die es nicht mehr gibt, ein Syntaxfehler in einer Datei und zu wenig Arbeitsspeicher. WordPress fängt die Fehlerarten E_ERROR, E_PARSE, E_USER_ERROR, E_COMPILE_ERROR und E_RECOVERABLE_ERROR ab, Warnungen und Hinweise auf veralteten Code nicht (class-wp-fatal-error-handler.php).

Seit WordPress 5.2 gibt es dazu den Wiederherstellungsmodus (Fatal Error Recovery Mode in 5.2). WordPress erkennt, welches Plugin oder Theme den Fehler ausgelöst hat, und schickt eine Mail mit einem geheimen Link. Wer ihm folgt, kommt ins Backend, und das fehlerhafte Plugin ist pausiert, nur für diese eine Sitzung. Für Besucher bleibt die Seite kaputt, bis jemand den Fehler behebt.

Drei Bedingungen aus dem Code entscheiden, ob die Mail überhaupt kommt (class-wp-recovery-mode.php, load.php):

• Der Fehler muss aus einem Plugin oder Theme stammen. Liegt er im Kern, in der wp-config.php oder in einem Netzwerk-Plugin einer Multisite, gibt es keine Mail.
• Er muss an einer geschützten Adresse auftreten: im Backend, bei wp-login.php oder bei einigen Ajax-Aktionen wie Plugin-Updates. Ein Fehler, der nur auf der Startseite auftritt, löst keine Mail aus.
• Höchstens eine Mail pro Tag. Der Standardwert ist DAY_IN_SECONDS, und genauso lange gilt der Link darin.

Der zweite Punkt erklärt, warum so viele Betroffene nie eine Mail sehen. Ruf /wp-admin/ deiner Seite auf. Tritt der Fehler dort ebenfalls auf, wird die Mail dabei ausgelöst.

Schritt 1: die Wiederherstellungs-Mail finden#

Der Betreff lautet „[Name deiner Website] Deine Website hat ein technisches Problem“. Sie geht an die Adresse unter „Einstellungen → Allgemein → Administrator-E-Mail-Adresse“ oder, falls gesetzt, an die Konstante RECOVERY_MODE_EMAIL in der wp-config.php. Unter „Fehlerdetails“ steht der Fehler mit Datei und Zeile, darüber, welches Plugin oder Theme ihn verursacht hat.

Such auch im Spam-Ordner. WordPress verschickt Mails standardmäßig über die PHP-Funktion mail() des Webservers, und die WordPress-Dokumentation nennt fehlende SPF- und DKIM-Einträge als häufigen Grund, warum solche Mails im Spam landen oder verworfen werden (FAQ Troubleshooting). Kommen auch Mails zum Zurücksetzen des Passworts nicht an, liegt das Problem dort und nicht beim Wiederherstellungsmodus.

Mit dem Link im Backend: Unter „Plugins“ steht das pausierte Plugin mit der Fehlermeldung. Deaktivieren, dann über die Schaltfläche „Wiederherstellungsmodus verlassen“ in der Werkzeugleiste aussteigen und die Seite in einem privaten Fenster aufrufen.

Damit die Mail beim nächsten Mal ankommt, gehört in die wp-config.php eine Adresse, die jemand liest:

define( 'RECOVERY_MODE_EMAIL', 'technik@beispiel.at' );

Schritt 2: das Fehlerprotokoll lesen#

Ohne Mail führt debug.log zum Verursacher. In der wp-config.php vor der Zeile /* That's all, stop editing! */ eintragen (Debugging in WordPress):

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

WP_DEBUG_DISPLAY auf false hält die Fehler aus der Seite heraus, die Besucher sehen. Dann die kaputte Seite einmal aufrufen und per SFTP wp-content/debug.log öffnen. Gesucht ist die letzte Zeile mit PHP Fatal error. Der Pfad dahinter nennt den Verursacher: Steht dort /wp-content/plugins/<name>/, ist es dieses Plugin, bei /wp-content/themes/<name>/ das Theme. Die Zeilen mit Deprecated oder Warning davor sind meist nicht die Ursache.

Steht im Protokoll „Allowed memory size of … bytes exhausted“, reicht der Arbeitsspeicher nicht. Der Fall hat einen eigenen Abschnitt weiter unten.

Bleibt debug.log leer, schreibt WordPress die Datei vielleicht nicht, weil der Ordner nicht beschreibbar ist, oder der Fehler passiert, bevor die wp-config.php gelesen wird. Dann hilft das PHP-Fehlerprotokoll des Hosters, das viele Hoster im Kundenbereich anzeigen.

Schritt 3: den Verursacher abschalten#

Drei Wege, je nachdem, welchen Zugang du hast. Alle drei lassen die Einstellungen des Plugins in der Datenbank stehen.

Per SFTP oder Dateimanager. Im Ordner wp-content/plugins/ den Ordner des Plugins umbenennen, etwa kontaktformular in kontaktformular.aus. WordPress findet das Plugin nicht mehr und deaktiviert es. Weißt du nicht, welches Plugin es ist, den ganzen Ordner plugins in plugins.hold umbenennen, im Backend anmelden, zurückbenennen und die Plugins einzeln wieder aktivieren, bis der Fehler zurückkommt (FAQ Troubleshooting).

Per WP-CLI. Mit --skip-plugins und --skip-themes lädt WP-CLI die kaputte Erweiterung gar nicht erst und läuft deshalb auch, wenn die Seite steht (WP-CLI, globale Parameter):

wp plugin list --status=active --skip-plugins --skip-themes
wp plugin deactivate kontaktformular --skip-plugins --skip-themes

wp plugin deactivate --all schaltet alle ab, mit --exclude= lassen sich einzelne ausnehmen (wp plugin deactivate). Plugins im Ordner mu-plugins lädt WP-CLI trotz --skip-plugins; liegt der Fehler dort, hilft nur Umbenennen.

Das Theme. Nennt das Protokoll den Theme-Ordner, im Ordner wp-content/themes/ den Ordner des aktiven Themes umbenennen, dann fällt WordPress auf ein mitgeliefertes Standard-Theme zurück, sofern eines installiert ist (Common WordPress Errors). Mit WP-CLI: wp theme list --skip-themes zeigt die installierten, wp theme activate <name> --skip-plugins --skip-themes schaltet um.

Die typischen Ursachen und was dann zu tun ist#

Plugin- oder Theme-Update. Die neue Version verträgt sich nicht mit deiner PHP-Version, mit einem anderen Plugin oder mit dem Theme. Eine bestimmte ältere Version holst du mit wp plugin install <name> --version=<x.y.z> --force zurück; wie das geht und was WordPress seit 6.3 und 6.6 selbst zurücknimmt, steht in WordPress-Updates richtig machen.

PHP-Version gewechselt. Hat der Hoster umgestellt oder hast du es selbst getan, zuerst die alte Version im Kundenbereich zurückstellen. Das empfiehlt WordPress selbst, bevor eine Sicherung zurückgespielt wird (Update PHP). Danach Plugins aktualisieren und neu umstellen; der Weg steht in WordPress PHP-Version.

Zu wenig Arbeitsspeicher. WordPress versucht von sich aus, PHP mindestens 40 MB zuzuweisen, bei Multisite 64 MB (wp-config.php). Mehr setzt diese Zeile vor wp-settings.php:

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

Sie wirkt nur, wenn der Hoster die Änderung zulässt. Dieselbe Dokumentation warnt, dass ein höheres Limit die eigentliche Ursache verdecken kann, bis sie mit dem nächsten Plugin wiederkommt.

Abgebrochenes Update. Bricht ein Update mittendrin ab, liegen alte und neue Dateien nebeneinander, und das passt nicht zusammen. Zeigt die Seite stattdessen „vorübergehend nicht verfügbar“, ist es der Wartungsmodus, nicht dieser Fehler; was dann zu tun ist, steht in WordPress-Wartungsmodus. Beim Kern ist der dokumentierte Weg, das Update von Hand zu wiederholen (Common WordPress Errors), bei einem Plugin die Neuinstallation über wp plugin install <name> --force.

Eigener Code. Eine Zeile in der functions.php oder einem Code-Schnipsel-Plugin mit einem Tippfehler. Das Protokoll nennt Datei und Zeile.

Wenn nichts davon passt: Sicherung einspielen. Dateien und Datenbank vom letzten Stand vor dem Fehler, beides zusammen. Vorher den kaputten Stand sichern, sonst ist das Protokoll mit dem Fehler weg.

Danach: Ursache beheben, Protokoll entfernen#

Ein abgeschaltetes Plugin ist kein behobener Fehler. Entweder kommt ein Update des Herstellers, das den Fehler behebt, dann wieder einschalten. Oder es bleibt bei der älteren Version mit abgeschaltetem automatischem Update, bis die Korrektur da ist. Oder das Plugin fliegt raus; ob ein Plugin noch gepflegt wird, prüfst du wie in WordPress-Plugins prüfen beschrieben.

Dann das Protokoll wieder abschalten. Die Dokumentation rät ausdrücklich davon ab, WP_DEBUG auf einer Live-Seite laufen zu lassen (Debugging in WordPress):

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

Danach debug.log löschen. Die Datei liegt unter wp-content/ und ist damit oft für jeden abrufbar, der die Adresse kennt. Sie verrät Serverpfade, Plugin-Namen und Versionen. Die WordPress-Dokumentation nennt ein öffentlich erreichbares Protokoll ein Sicherheitsrisiko und empfiehlt, es außerhalb des öffentlichen Verzeichnisses abzulegen (wp-config.php). Seit WordPress 5.1 nimmt WP_DEBUG_LOG dafür einen Pfad statt true (load.php):

define( 'WP_DEBUG_LOG', '/home/benutzer/logs/wp-debug.log' );

Geht das beim Hoster nicht, sperrt unter Apache 2.4 dieser Eintrag in der .htaccess den Abruf (Apache, Upgrading to 2.4):

<Files "debug.log">
    Require all denied
</Files>

Ob deine Seite noch eine debug.log ausliefert, siehst du, wenn du https://deine-domain.at/wp-content/debug.log im Browser aufrufst. Kommt Text statt 403 oder 404, ist sie offen.

Kritischer Fehler oder gehackt#

Ein fataler Fehler ist ein Programmierfehler. Ein Angriff sieht anders aus: Weiterleitungen auf fremde Seiten, Dateien mit Zufallsnamen im Hauptverzeichnis oder in wp-content/uploads/, unbekannte Administrator-Konten, fremde Einträge in Google. Nennt das Protokoll eine Datei, die du nie installiert hast, ist das kein Fall für diese Anleitung. Dann gilt Website gehackt: was tun, und die Seite wird zuerst gesichert und vom Netz genommen, nicht repariert.

Was nicht hilft#

Alle Plugins löschen. Umbenennen oder deaktivieren reicht und behält die Einstellungen. Beim Löschen im Backend läuft dagegen die Deinstallationsroutine des Plugins, und die soll laut Plugin-Handbuch seine Einstellungen und Tabellen aus der Datenbank entfernen (Uninstall Methods).

WordPress neu installieren. Liegt der Fehler in einem Plugin, ändert eine Neuinstallation des Kerns nichts daran, und ein frisch aufgesetztes WordPress samt neu eingespielter Plugins kostet die Information, welches es war.

WP_DEBUG_DISPLAY auf true auf der Live-Seite. Dann sehen alle Besucher Pfade und Fehlermeldungen. Das Protokoll in die Datei reicht.

WP_DISABLE_FATAL_ERROR_HANDLER setzen. Die Konstante schaltet die Meldung und die Wiederherstellungs-Mail ab (error-protection.php). Der Fehler bleibt, nur sieht man wieder eine weiße Seite.

Das Memory-Limit hochsetzen, ohne ins Protokoll zu schauen. Hilft nur, wenn dort „Allowed memory size“ steht.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Die WordPress-Soforthilfe übernimmt genau diesen Fall: Fehlerdiagnose und Reparatur für 149 € einmalig, mit kostenloser Ersteinschätzung, Sicherung von Dateien und Datenbank vor dem Eingriff, Auswertung des Fehlerprotokolls und Prüfung nach der Reparatur. Rückmeldung in der Regel am selben Werktag, ohne Garantie und ohne Bereitschaft rund um die Uhr. Ist die Seite gehackt, ist das die Hack-Bereinigung ab 290 €, Preis nach der Ersteinschätzung. Damit es nicht wieder passiert: Die WordPress-Wartung für 49 € im Monat spielt Updates vorher getestet ein und sichert täglich außerhalb des Servers, monatlich kündbar. Was Wartung sonst kostet, steht in WordPress-Wartung: Kosten.

Häufige Fragen#

Stand 12.10.2026. WordPress-Dokumentation, WP-CLI-Handbuch, PHP-Handbuch, Quellcode von WordPress (trunk) und die deutschen Übersetzungen auf translate.wordpress.org an diesem Tag gelesen.