Lösungen für: „Auf dieser Website ist ein kritischer Fehler aufgetreten“ (und weiße Seite) in WordPress

Wenn Ihre WordPress-Website statt Ihrer Inhalte nur noch den Satz „Auf dieser Website ist ein kritischer Fehler aufgetreten.“ zeigt oder eine leere weiße Seite, ist das ein Schreck, aber selten eine Katastrophe. Ihre Inhalte sind in aller Regel noch da. Es läuft nur gerade ein Stück Programmcode nicht, und WordPress bricht deshalb ab.

Die kurze Antwort: Rufen Sie einmal die Adresse /wp-login.php Ihrer Website auf. Erst das löst in vielen Fällen die E-Mail aus, mit der Sie in den Wiederherstellungsmodus kommen und das schuldige Plugin oder Theme abschalten. Kommt keine E-Mail, steht die Ursache im Fehlerprotokoll Ihres Hosters, und Sie schalten das Plugin oder Theme per Dateimanager, FTP oder Datenbank ab.

Alles in diesem Beitrag habe ich auf einer Testinstallation (WordPress 7.1.4 auf Deutsch, PHP 8.4) absichtlich kaputt gemacht und wieder repariert: jeden Fehler, jeden Befehl, jede Änderung an der wp-config.php. Wo das Ergebnis anders aussieht, als Foren und Anleitungen behaupten, steht das dabei.

Was bedeutet „kritischer Fehler“ bei WordPress?

Ein PHP-Programm ist mit einem sogenannten fatalen Fehler abgebrochen, meist in einem Plugin oder im Theme. Seit Version 5.2 fängt WordPress das ab und zeigt diese Meldung, statt technische Details auszugeben. Der Server antwortet dabei mit dem Statuscode 500.

Es bedeutet nicht, dass Beiträge oder Seiten gelöscht wurden. Es bedeutet auch nicht, dass „WordPress gerade Probleme hat“: WordPress läuft auf Ihrem eigenen Webspace, die Ursache liegt also fast immer auf Ihrer Website.

Der Wortlaut hängt davon ab, wo Sie die Meldung sehen und welche Version und Sprachfassung läuft. Gemeint ist immer dasselbe:

• Auf der Website: „Auf dieser Website ist ein kritischer Fehler aufgetreten.“
• Beim Anmelden und im Dashboard: „Es gab einen kritischen Fehler auf dieser Website. Prüfe bitte den Posteingang der administrativen E-Mail-Adresse der Website auf Anweisungen.“ (in der Sie-Fassung: „Prüfen Sie bitte …“)
• In älteren Versionen: „Es gab einen kritischen Fehler auf deiner Website.“ oder „… auf Ihrer Website.“, dazu „Bitte überprüfe den Posteingang deiner Website-Administrator-E-Mail-Adresse für weitere Anweisungen.“
• In Version 5.2: „Die Website hat technische Schwierigkeiten.“
• Auf Englisch: „There has been a critical error on this website.“

Bevor Sie etwas ändern: Ein falscher Handgriff kann mehr Schaden anrichten als der Fehler selbst. Ein Tippfehler in der wp-config.php legt die ganze Website lahm, ein falscher Befehl in der Datenbank oder auf der Kommandozeile lässt sich oft nicht zurücknehmen. Mit diesen Regeln bleibt jeder Schritt umkehrbar:

• Zuerst eine vollständige Sicherung von Dateien und Datenbank, abgelegt außerhalb Ihres Webspace. Viele Hoster bieten dafür eine eigene Funktion an. Fragen Sie im Zweifel nach, wie Sie die Sicherung wieder einspielen.
• Vor jeder Bearbeitung eine Kopie der Datei auf Ihren eigenen Rechner laden. Eine Kopie auf dem Server darf nicht wp-config.php.bak heißen, denn so kann sie jeder samt Datenbank-Passwort im Browser abrufen. Nennen Sie sie wp-config-kopie.php, und löschen Sie sie am Ende.
• Immer nur eine Änderung, dann testen. Hat sie nicht geholfen, machen Sie sie rückgängig, bevor Sie die nächste versuchen.
• Eine Testkopie (Staging) nutzen, wenn Ihr Hoster eine anbietet: Dort darf alles schiefgehen.
• Aufhören ist eine gute Option: wenn Sie nicht mehr wissen, was Sie geändert haben, wenn ein Schritt anders aussieht als hier beschrieben oder wenn die Website täglich Geld verdient. Dann schreiben Sie mir, das Angebot steht am Ende dieses Beitrags.

Schritt 1: Die Recovery-E-Mail von WordPress auslösen

Viele warten vergeblich auf die versprochene E-Mail, weil WordPress sie nicht bei jedem Fehler verschickt. Die E-Mail geht nur hinaus, wenn der Fehler beim Anmelden oder im Dashboard auftritt, nicht wenn ein Besucher die Website aufruft. In meinem Test ergaben beliebig viele Aufrufe der Website null E-Mails, ein einziger Aufruf der Anmeldeseite eine.

So kommen Sie zum Wiederherstellungsmodus:

1. Rufen Sie https://ihre-domain.at/wp-login.php auf. Sehen Sie die längere Meldung mit dem Posteingang, hat WordPress die E-Mail gerade verschickt oder in den letzten 24 Stunden schon einmal.
2. Sehen Sie in das Postfach der Administrator-Adresse, auch in den Spam-Ordner. Der Betreff lautet „[Name Ihrer Website] Deine Website hat ein technisches Problem“ (oder „Ihre Website …“). Die E-Mail nennt das Plugin oder Theme, die genaue Fehlermeldung und einen Link, der einen Tag lang gilt.
3. Klicken Sie auf den Link und melden Sie sich an, wie gewohnt mit Benutzername und Passwort. Der Link funktioniert nur einmal.
4. Öffnen Sie Plugins → Installierte Plugins. Das Plugin ist rot markiert, mit dem Hinweis „Dieses Plugin konnte nicht ordnungsgemäß geladen werden und ist im Wiederherstellungsmodus pausiert.“ Klicken Sie auf Deaktivieren. War es das Theme, aktivieren Sie unter Design → Themes ein anderes.
5. Verlassen Sie den Modus über „Wiederherstellungsmodus verlassen“ oben rechts.

Zwei Dinge sollten Sie dabei wissen. Solange Sie das Plugin oder Theme nicht wirklich abschalten, sehen Ihre Besucher weiter die Fehlermeldung. Die Pause gilt nur für Ihren Browser. Und wer den Modus ohne Reparatur verlässt, hat weiterhin eine kaputte Website, bekommt aber beim nächsten Aufruf der Anmeldeseite sofort eine neue E-Mail.

Prüfen Sie danach, ob es für das Plugin oder Theme eine neuere Version gibt, und installieren Sie diese. Gibt es keine, lassen Sie es abgeschaltet und suchen Ersatz.

Erscheint unter /wp-login.php das normale Anmeldeformular, ist der Fehler auf bestimmte Seiten beschränkt, etwa auf eine einzelne Seite mit einem Shortcode oder Block. Dann gibt es keine E-Mail, aber auch keinen Grund dafür: Melden Sie sich an und schalten Sie die Plugins im Dashboard einzeln ab.

Warum habe ich nach einem kritischen Fehler in WordPress keine E-Mail bekommen?

Die Foren sind voll von dieser Frage. Das sind die Gründe, in der Reihenfolge, in der ich sie prüfen würde:

• Der Fehler trat bisher nur auf der Website auf. Dann wurde noch keine E-Mail ausgelöst. Rufen Sie die Anmeldeseite auf (Schritt 1).
• Die E-Mail ging schon einmal hinaus. WordPress verschickt höchstens eine pro Tag, und es merkt sich den Zeitpunkt auch dann, wenn der Versand fehlgeschlagen ist. Einen neuen Versuch erzwingen Sie, indem Sie in der Tabelle wp_options die Zeile recovery_mode_email_last_sent löschen und die Anmeldeseite wieder aufrufen.
• Sie geht an eine alte Adresse. Empfänger ist die „Administrative E-Mail-Adresse“ aus Einstellungen → Allgemein. Das ist oft noch die des Webdesigners. Ohne Dashboard-Zugang tragen Sie die richtige in die wp-config.php ein, oberhalb der Zeile „Das war’s, Schluss mit dem Bearbeiten!“:

define( 'RECOVERY_MODE_EMAIL', 'ihre-adresse@ihre-domain.at' );

• Ihr Server verschickt keine E-Mails, oder sie landen im Spam. Dann kommt auch sonst nichts an, was die Website verschickt, etwa das Zurücksetzen des Passworts.
• Die Ursache ist kein normales Plugin oder Theme. WordPress verschickt die E-Mail nur, wenn es den Fehler einem Plugin oder Theme zuordnen kann. Bei einer fehlenden WordPress-Datei, einem sogenannten Must-Use-Plugin oder einem Speicherfehler in einer WordPress-Datei kommt keine. Die Anmeldeseite fordert Sie trotzdem auf, in den Posteingang zu sehen. Warten Sie in diesem Fall nicht, sondern gehen Sie zum nächsten Abschnitt.

Schritt 2: Die Ursache für einen kritischen Fehler von WordPress im Fehlerprotokoll finden

Ohne E-Mail führt der Weg über das Protokoll. Am besten über das Fehlerprotokoll Ihres Hosters, denn dafür müssen Sie nichts ändern. Es heißt meist error_log und liegt im Kundenbereich oder in einem Ordner logs. In Plesk, wie bei meinem eigenen Hosting, finden Sie es unter Websites & Domains → Ihre Domain → Protokolle oder im Dateimanager unter logs. Wo es bei Ihnen liegt, weiß der Support Ihres Hosters.

Suchen Sie die jüngste Zeile mit „PHP Fatal error“. Sie sieht zum Beispiel so aus:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /wp-content/plugins/altes-plugin/altes-plugin.php:3

Entscheidend ist der Pfad am Ende:

• /wp-content/plugins/altes-plugin/: Das Plugin in diesem Ordner ist die Ursache.
• /wp-content/themes/mein-theme/: Das Theme ist die Ursache.
• /wp-includes/ oder /wp-admin/: WordPress selbst ist nicht unbedingt schuld. Sehen Sie in die Zeilen darunter (ab „Stack trace“), ob dort ein Plugin oder Theme genannt wird, und beachten Sie den Abschnitt zum Speicher weiter unten.

Kommen Sie an das Protokoll nicht heran, lässt sich WordPress selbst eines schreiben. Ändern Sie in der wp-config.php die vorhandene Zeile define( 'WP_DEBUG', false ); auf true, und ergänzen Sie darunter die anderen beiden, oberhalb von „Das war’s, Schluss mit dem Bearbeiten!“ (je nach Installation „That's all, stop editing!“):

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

Rufen Sie danach die Website auf und öffnen Sie die Datei wp-content/debug.log. Drei Dinge habe ich dabei getestet, die in vielen Anleitungen fehlen:

• Die dritte Zeile ist nicht optional. Mit nur den ersten beiden Zeilen sehen Ihre Besucher den rohen Fehler samt Serverpfaden auf der Seite.
• Die Datei debug.log kann jeder im Browser abrufen, unter https://ihre-domain.at/wp-content/debug.log. Nehmen Sie deshalb die Zeilen wieder heraus und löschen Sie die Datei, sobald Sie die Ursache kennen.
• Die Reihenfolge zählt. Unterhalb der Zeile „Schluss mit dem Bearbeiten“ wirken die Einträge nicht mehr. Eine zweite WP_DEBUG-Zeile unter der vorhandenen auch nicht, es gilt die erste. Und WP_DEBUG_LOG allein, ohne WP_DEBUG, schreibt gar nichts.

Warten Sie nach jeder Änderung an einer Datei ein paar Sekunden, bevor Sie urteilen. PHP hält den alten Code kurz im Zwischenspeicher, bei mir zwei Sekunden, bei Ihrem Hoster vielleicht länger.

Schritt 3: Ein defektes WordPress-Plugin ohne Dashboard abschalten

Sie brauchen dafür einen Dateimanager im Kundenbereich Ihres Hosters oder FTP-Zugang, phpMyAdmin oder SSH. Einer dieser drei Wege genügt.

Mit Dateimanager oder FTP: Öffnen Sie den Ordner wp-content/plugins und benennen Sie den Ordner des Plugins um, zum Beispiel altes-plugin in altes-plugin.off. Die Website läuft sofort wieder.

Kennen Sie das Plugin noch nicht, benennen Sie den ganzen Ordner plugins um, etwa in plugins.off. Danach kommt es darauf an, was Sie tun:

• Sie benennen den Ordner gleich wieder zurück: Alle Plugins sind sofort wieder aktiv, auch das schuldige, und der Fehler ist wieder da. WordPress hat sich nichts gemerkt.
• Sie melden sich zuerst an und öffnen die Seite Plugins: Dort meldet WordPress für jedes Plugin „Das Plugin … wurde aufgrund eines Fehlers deaktiviert: Diese Plugindatei existiert nicht.“ Benennen Sie den Ordner nun zurück, sind alle Plugins deaktiviert, und die Website läuft. Das ist der Weg, den ich empfehle. Aktivieren Sie die Plugins dann einzeln und prüfen Sie nach jedem die Website. Das letzte vor dem Fehler ist die Ursache.

Mit phpMyAdmin: Öffnen Sie die Tabelle wp_options (die Vorsilbe wp_ kann bei Ihnen anders lauten, sie steht in der wp-config.php), suchen Sie die Zeile active_plugins, kopieren Sie den alten Wert und ändern Sie ihn in:

a:0:{}

Damit sind alle Plugins deaktiviert.

Mit SSH und WP-CLI: Ohne Zusatz bricht auch WP-CLI am selben Fehler ab. Mit --skip-plugins funktioniert es:

wp plugin deactivate altes-plugin --skip-plugins

Hilft das Abschalten aller Plugins nicht, kann der Fehler auch in Code liegen, den keiner dieser Wege erreicht: in einem Must-Use-Plugin (Ordner wp-content/mu-plugins) oder in einer Datei wie wp-content/object-cache.php, die ein Cache-Plugin dort hinterlassen hat. Das Umbenennen des Ordners plugins und --skip-plugins ändern dann nichts. Das Fehlerprotokoll nennt die Datei. Benennen Sie genau diese um.

Schritt 4: Ein defektes WordPress-Theme ohne Dashboard abschalten

Liegt der Fehler in der functions.php oder einer anderen Theme-Datei, gilt das Gleiche. Nur stimmt der oft gelesene Satz „Theme-Ordner umbenennen, dann schaltet WordPress auf das Standard-Theme“ so nicht.

In meinem Test geschah nach dem Umbenennen Folgendes: Die Website zeigte eine völlig leere weiße Seite, und auch der Besuch des Dashboards änderte nichts. Erst als ich Design → Themes öffnete, kam „Das aktuelle Theme ist fehlerhaft. Das Standard-Theme wurde aktiviert.“, und die Website war wieder da. Das setzt voraus, dass noch ein Standard-Theme (Twenty Twenty-Irgendwas) installiert ist. Ohne eines meldet WordPress nur, das Theme-Verzeichnis existiere nicht, und die Seite bleibt weiß. Löschen Sie deshalb nie das letzte Standard-Theme.

Mit phpMyAdmin: Tragen Sie in der Tabelle wp_options in den Zeilen template und stylesheet den Ordnernamen eines installierten Themes ein, zum Beispiel twentytwentyfive.

Mit SSH und WP-CLI:

wp theme activate twentytwentyfive --skip-themes --skip-plugins

Haben Sie kurz zuvor selbst Code in die functions.php eingefügt, ist die Lösung einfacher: Spielen Sie Ihre Kopie der Datei zurück.

Die üblichen Ursachen für einen kritischen Fehler in WordPress

Das Protokoll sagt Ihnen, in welcher Datei es gekracht hat. Warum, hat meist einen dieser Gründe.

Ein Plugin oder Theme wurde aktualisiert oder neu installiert

Fragen Sie sich zuerst, was sich zuletzt geändert hat, auch durch automatische Updates. WordPress schützt Sie beim Aktivieren nur teilweise: Stürzt ein Plugin schon beim Laden ab, verweigert WordPress die Aktivierung („Das Plugin konnte nicht aktiviert werden, da es einen fatalen Fehler ausgelöst hat.“), und die Website bleibt heil. Stürzt es erst später im Ablauf ab, wird es aktiviert und reißt die Website mit.

Die PHP-Version passt nicht

Das geht in beide Richtungen, und beide habe ich nachgestellt:

• PHP wurde angehoben, und ein altes Plugin oder Theme kommt nicht mit. Typisch sind Meldungen wie Call to undefined function create_function(), weil es diese Funktion seit PHP 8.0 nicht mehr gibt. Mein Test-Plugin lief unter PHP 7.4 tadellos und brachte unter PHP 8.4 die ganze Website zum Absturz. Stellen Sie die PHP-Version im Kundenbereich Ihres Hosters vorübergehend zurück, aktualisieren oder ersetzen Sie das Plugin oder Theme und gehen Sie dann wieder hoch. Eine alte PHP-Version ist keine Dauerlösung, weil sie keine Sicherheitsupdates mehr bekommt.
• Ein neues Plugin verlangt ein neueres PHP als Ihr Server hat. Dann steht auf der Seite oft nur noch nackter Text statt der WordPress-Meldung: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.1.0". Hier hilft nur, die PHP-Version anzuheben.

Der Speicher reicht nicht

Im Protokoll steht Allowed memory size of 134217728 bytes exhausted (tried to allocate …). Die Zahl sind die Bytes des aktuellen Limits, hier 128 MB. Tragen Sie in der wp-config.php oberhalb von „Schluss mit dem Bearbeiten“ ein:

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

Im Test verschwand der Fehler damit. Er blieb, wenn die Zeile unterhalb von „Schluss mit dem Bearbeiten“ stand, und er blieb, wenn der Server das Limit fest vorgab. Dann erhöhen Sie es im Kundenbereich Ihres Hosters oder fragen dort nach.

Zwei Einschränkungen: Mehr Speicher behandelt das Symptom, oft steckt ein Plugin mit einem Speicherproblem dahinter. Und die genannte Datei ist hier oft unschuldig. Sie ist nur die, bei der der Speicher gerade zu Ende war. In meinem Test verbrauchte ein Plugin den Speicher, das Protokoll nannte aber wp-includes/l10n.php, und eine E-Mail kam deshalb auch nicht.

Das ist mir auch selbst schon passiert: Beim Umzug einer Divi-Website hatte die Kommandozeile nur 128 MB, und jeder WP-CLI-Befehl gab nur noch „kritischer Fehler“ aus. Mit php -d display_errors=1 vor dem Befehl war die wahre Meldung zu sehen.

Ein Update wurde abgebrochen: Wie kann ich WordPress reparieren?

Fehlen WordPress-Dateien, sehen Sie oft gar keine Meldung, sondern überall eine leere Antwort, auch auf der Anmeldeseite, denn dann kann WordPress nicht einmal seine eigene Fehlerseite anzeigen. Ob etwas fehlt, zeigt per SSH dieser Befehl. Er listet fehlende und veränderte Dateien auf und meldet bei einer intakten Installation „Success“:

wp core verify-checksums --skip-plugins --skip-themes

Die Reparatur ist unspektakulär: dieselbe WordPress-Version noch einmal darüberkopieren. Laden Sie sie von de.wordpress.org herunter (ältere Versionen im Archiv) und überschreiben Sie per FTP alles außer dem Ordner wp-content und der Datei wp-config.php. Per SSH geht das so, mit Ihrer Versionsnummer:

wp core download --locale=de_DE --version=7.1.4 --skip-content --force

Beiträge, Medien, Plugins und Themes bleiben dabei unberührt.

Bei einem halb aktualisierten Plugin steht im Protokoll etwas wie Failed opening required … /includes/…. Das Plugin ist unvollständig. Benennen Sie seinen Ordner um und installieren Sie es neu. Fehlt seine Hauptdatei ganz, gibt es keinen Fehler: Das Plugin ist einfach still abgeschaltet, und erst die Seite Plugins sagt es Ihnen.

Auch ein WordPress-Update selbst kann der Auslöser sein: Das Sicherheitsupdate 6.9.2 vom März 2026 störte Themes, die ihre Vorlagen auf ungewöhnliche Weise laden, und Version 6.9.3 behob das noch am selben Tag. Sehen Sie also nach, ob es schon eine neuere Version gibt.

Warum wird meine WordPress-Website nur weiß angezeigt?

Die berüchtigte weiße Seite ist meistens derselbe Absturz, nur ohne Meldung. Welche Sorte Sie haben, verrät der Statuscode. Sie sehen ihn in den Entwicklertools des Browsers (F12, Reiter „Netzwerk“, Seite neu laden) oder mit diesem Befehl im Terminal:

curl -I https://ihre-domain.at/

Status 500 und leere Antwort: PHP ist abgestürzt, bevor WordPress etwas anzeigen konnte. Chrome zeigt dann statt einer weißen Seite eine eigene Fehlerseite mit „HTTP ERROR 500“. Im Test führten diese Ursachen dazu, und alle stehen im Fehlerprotokoll des Hosters:

• ein Tippfehler in der wp-config.php, meist von der letzten Änderung. Spielen Sie Ihre Kopie zurück. Das WordPress-eigene Protokoll hilft hier nicht, weil WordPress so weit gar nicht kommt.
• fehlende WordPress-Dateien (siehe oben)
• eine Zeile define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); in der wp-config.php oder eine leere Datei wp-content/php-error.php. Beide schalten die WordPress-Meldung ab, der Fehler dahinter bleibt.

Steht im Protokoll kein PHP-Fehler, liegt ein Status 500 meist am Webserver selbst, etwa an der .htaccess.

Status 200 und leere Antwort: Nichts ist abgestürzt, es wurde nur nichts ausgegeben. Deshalb steht auch nichts im Protokoll. Hier hilft ein Blick auf die Anmeldeseite:

• Die Anmeldeseite funktioniert: Es liegt am Theme, zum Beispiel an einem umbenannten, fehlenden oder leeren Theme-Ordner (Schritt 4).
• Auch die Anmeldeseite ist leer: Vermutlich beendet ein Plugin die Ausgabe vorzeitig. Schalten Sie die Plugins ab (Schritt 3).

Der obere Teil der Seite erscheint, darunter die Fehlermeldung: Ein klassisches Theme ist mitten in der Ausgabe abgestürzt. Der Weg ist derselbe wie beim kritischen Fehler.

Und ein Mythos: Eine Leerzeile am Dateiende macht keine weiße Seite. Das steht in vielen älteren Anleitungen. Ich habe Leerzeilen hinter dem schließenden ?> der functions.php und vor dem öffnenden <?php der wp-config.php eingefügt: Die Website lief weiter. Nur die Anmeldung meldete „Cookies sind wegen einer unerwarteten Ausgabe gesperrt“, und das ist ein anderes Problem.

Wenn nichts davon hilft

• Spielen Sie eine Sicherung ein. Wenn Sie wissen, seit wann der Fehler auftritt, ist eine Sicherung von davor oft der schnellste Weg. Was seither geändert wurde, geht dabei verloren.
• Fragen Sie Ihren Hoster. Er sieht das Protokoll und kann die PHP-Einstellungen prüfen. Die E-Mail von WordPress rät übrigens ebenfalls dazu.
• Fragen Sie mich. Schreiben Sie mir, was Sie sehen. Das Angebot steht gleich unter diesem Beitrag.

Dieser Beitrag behandelt Abstürze, keine Hacks. Sehen Sie im Protokoll Dateien oder Plugins, die Sie nie installiert haben, wenden Sie sich an Ihren Hoster (oder an mich), statt weiter zu probieren.

Damit es beim nächsten Mal schneller geht

• Halten Sie die Administrator-Adresse aktuell (Einstellungen → Allgemein), und zwar so, dass Sie dieses Postfach wirklich lesen.
• Sichern Sie vor Updates und testen Sie größere Änderungen auf einer Kopie. Was sonst noch zur Pflege gehört, steht in WordPress-Website richtig pflegen.
• Lassen Sie die Website auch auf ihren Inhalt überwachen. Eine weiße Seite mit Status 200 gilt für einen einfachen Verfügbarkeits-Check als „online“. Meine eigene Überwachung sucht deshalb auf der Startseite nach einem bestimmten Text.

Zeigt das Dashboard dagegen zwar Inhalte, aber ohne Gestaltung, ist das ein anderes Problem: Dafür gibt es Lösungen für: WordPress Dashboard wird nicht richtig angezeigt.