„Es gab einen kritischen Fehler“ in WordPress: Ursachen, Lösungen und Prävention

Last updated: April 24, 2026

Quick Answer: Die Meldung „Es gab einen kritischen Fehler auf dieser Website“ erscheint in WordPress, wenn ein schwerwiegender PHP-Fehler den normalen Betrieb der Seite verhindert. In den meisten Fällen liegt der Fehler an einem inkompatiblen Plugin, einem fehlerhaften Theme oder einer veralteten PHP-Version. Die Lösung ist in der Regel in wenigen Schritten möglich, auch ohne Programmierkenntnisse.

Key Takeaways

🔴 „Es gab einen kritischen Fehler“ ist WordPress‘ Benutzeroberfläche für den sogenannten „White Screen of Death“ (WSoD).
Der Fehler wird fast immer durch ein Plugin, ein Theme oder eine PHP-Inkompatibilität ausgelöst.
WordPress sendet bei diesem Fehler automatisch eine E-Mail an die Admin-Adresse mit weiteren Details.
Der Debug-Modus (WP_DEBUG) ist das wichtigste Werkzeug zur genauen Fehlerdiagnose.
Plugins lassen sich über FTP oder den Dateimanager im Hosting-Panel deaktivieren, ohne Zugang zum Admin-Bereich.
Ein regelmäßiges Backup schützt vor dauerhaftem Datenverlust bei kritischen Fehlern.
Wer keine Zeit oder technische Kenntnisse hat, kann einen WordPress-Reparaturservice beauftragen.

Was bedeutet „Es gab einen kritischen Fehler“ genau?

„Es gab einen kritischen Fehler auf dieser Website“ ist die standardisierte Fehlermeldung, die WordPress seit Version 5.2 anzeigt, wenn PHP abstürzt und die Seite nicht mehr geladen werden kann. Vor Version 5.2 erschien stattdessen ein leerer weißer Bildschirm, der sogenannte White Screen of Death.

WordPress fängt den PHP-Fatal-Error ab und zeigt stattdessen diese benutzerfreundlichere Meldung an. Gleichzeitig wird eine automatische E-Mail an die hinterlegte Admin-E-Mail-Adresse gesendet. Diese E-Mail enthält oft den genauen Fehlertyp und die betroffene Datei.

Was die Meldung nicht bedeutet: Die Website ist nicht dauerhaft beschädigt. In den allermeisten Fällen lässt sich der Fehler vollständig beheben, ohne Daten zu verlieren.

Welche Ursachen hat „Es gab einen kritischen Fehler“ am häufigsten?

Die häufigsten Auslöser lassen sich in drei Kategorien einteilen:

Kategorie	Typische Ursache	Häufigkeit (geschätzt)
Plugins	Inkompatibles oder fehlerhaftes Plugin	Sehr häufig
Themes	Fehler im aktiven Theme nach Update	Häufig
PHP-Version	Inkompatible PHP-Version auf dem Server	Mittel
Speicherlimit	PHP-Speicherlimit überschritten	Mittel
Core-Dateien	Beschädigte WordPress-Kerndateien	Selten

Die häufigste Einzelursache ist ein Plugin-Update, das Konflikte mit anderen Plugins oder dem aktiven Theme erzeugt. Besonders riskant sind Updates direkt nach einem WordPress-Core-Update, wenn Plugin-Entwickler noch nicht reagiert haben.

Merksatz: Wenn der Fehler direkt nach einem Update auftritt, liegt die Ursache fast immer bei dem zuletzt aktualisierten Element.

Wie findet man die genaue Fehlerquelle?

Der erste Schritt ist immer die Aktivierung des Debug-Modus, um den genauen PHP-Fehler zu sehen.

Schritt 1: Debug-Modus aktivieren

Die Datei wp-config.php im Hauptverzeichnis der WordPress-Installation enthält folgende Zeile:

define( 'WP_DEBUG', false );

Diese Zeile muss auf true geändert werden:

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

Mit WP_DEBUG_LOG wird der Fehler in die Datei /wp-content/debug.log geschrieben, ohne ihn öffentlich anzuzeigen.

Schritt 2: Die Debug-Log-Datei lesen

Die Datei debug.log zeigt den genauen Fehlertyp, die betroffene PHP-Datei und die Zeilennummer. Ein typischer Eintrag sieht so aus:

PHP Fatal error: Uncaught Error: Call to undefined function xyz_plugin_function() in /wp-content/plugins/xyz-plugin/xyz-plugin.php:42

Dieser Eintrag zeigt klar: Das Plugin xyz-plugin ist verantwortlich.

Schritt 3: Admin-E-Mail prüfen

WordPress sendet bei einem kritischen Fehler automatisch eine E-Mail. Diese E-Mail enthält einen Link zum WordPress-Recovery-Modus, der den Zugang zum Admin-Bereich ermöglicht, auch wenn die Seite selbst nicht lädt.

Wie behebt man „Es gab einen kritischen Fehler“ durch Plugin-Deaktivierung?

Wenn ein Plugin als Ursache identifiziert wurde oder vermutet wird, ist die Deaktivierung der schnellste Weg zur Lösung.

Option A: Über den Recovery-Modus (empfohlen)

Der Link in der Admin-E-Mail führt in den WordPress-Recovery-Modus. Dort kann das problematische Plugin direkt im Admin-Bereich deaktiviert werden.

Option B: Über FTP oder den Dateimanager

Wenn kein Zugang zum Admin-Bereich möglich ist:

Per FTP oder Hosting-Dateimanager in das Verzeichnis /wp-content/plugins/ navigieren.
Den Ordner des verdächtigen Plugins umbenennen (z.B. von xyz-plugin zu xyz-plugin-deaktiviert).
WordPress erkennt das Plugin nicht mehr und deaktiviert es automatisch.
Die Website neu laden und prüfen, ob der Fehler behoben ist.

Alle Plugins auf einmal deaktivieren: Den gesamten Ordner /wp-content/plugins/ umbenennen (z.B. in plugins-backup). Wenn die Seite dann lädt, liegt die Ursache bei einem Plugin. Plugins dann einzeln wieder aktivieren, bis der Fehler erneut auftritt.

Was tun, wenn ein Theme „Es gab einen kritischen Fehler“ verursacht?

Themes können ebenfalls PHP-Fatal-Errors auslösen, besonders nach Updates oder wenn ein Theme-Code auf eine Funktion zugreift, die nicht mehr existiert.

So wechselt man das Theme ohne Admin-Zugang:

Per FTP in /wp-content/themes/ navigieren.
Den Ordner des aktiven Themes umbenennen.
WordPress fällt automatisch auf ein Standard-Theme zurück (z.B. Twenty Twenty-Four).
Wenn die Seite dann lädt, ist das Theme die Ursache.

Wähle diesen Weg, wenn: Der Fehler nach einem Theme-Update aufgetreten ist oder wenn die Debug-Log-Datei eine Datei aus dem Theme-Ordner als Ursache nennt.

Für professionelle Hilfe bei komplexen Theme-Fehlern bietet ein WordPress-Reparaturservice schnelle Unterstützung.

Wie behebt man das PHP-Speicherlimit als Ursache?

Ein zu niedriges PHP-Speicherlimit ist eine häufig übersehene Ursache für kritische Fehler. WordPress benötigt mindestens 64 MB, empfohlen werden 256 MB oder mehr für Seiten mit vielen Plugins.

Das Speicherlimit lässt sich auf drei Wegen erhöhen:

Methode 1: In der wp-config.php

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

Methode 2: In der .htaccess

php_value memory_limit 256M

Methode 3: Über das Hosting-Panel
Die meisten Hosting-Anbieter erlauben die Anpassung des PHP-Speicherlimits direkt im Kundenbereich unter den PHP-Einstellungen.

Wie verhindert man „Es gab einen kritischen Fehler“ in Zukunft?

Prävention ist einfacher als Reparatur. Diese Maßnahmen reduzieren das Risiko erheblich:

Regelmäßige Backups: Mindestens wöchentliche automatische Backups der Datenbank und aller Dateien. Plugins wie UpdraftPlus oder Jetpack Backup erledigen das automatisch.
Updates in einer Staging-Umgebung testen: Vor dem Update auf der Live-Seite in einer Testumgebung prüfen.
PHP-Version aktuell halten: PHP 8.2 oder höher wird für WordPress in 2026 empfohlen. Veraltete PHP-Versionen sind eine häufige Fehlerquelle.
Plugins reduzieren: Jedes zusätzliche Plugin erhöht das Konfliktpotenzial. Nur wirklich benötigte Plugins installieren.
Seriöse Plugin-Quellen: Nur Plugins aus dem offiziellen WordPress-Repository oder von vertrauenswürdigen Entwicklern verwenden.

Wer seine WordPress-Installation langfristig stabil halten möchte, findet bei WP.Repair professionelle Unterstützung für Wartung und Reparatur.

Wann sollte man einen Profi für „Es gab einen kritischen Fehler“ beauftragen?

Nicht jeder Fehler lässt sich ohne technische Kenntnisse beheben. Ein Profi ist sinnvoll, wenn:

Der Debug-Log keine klare Fehlerquelle zeigt.
Die Fehlerquelle ein Core-Datei-Problem ist.
Die Seite nach Plugin- und Theme-Deaktivierung immer noch nicht lädt.
Kundendaten oder E-Commerce-Funktionen betroffen sind und Ausfallzeit teuer ist.
Kein FTP-Zugang oder Hosting-Panel-Zugang vorhanden ist.

Ein WordPress-Reparaturservice kann in solchen Fällen die Seite schnell wiederherstellen und die Grundursache dauerhaft beheben.

FAQ: Häufige Fragen zu „Es gab einen kritischen Fehler“

Kann ich die Seite selbst reparieren, ohne Programmierkenntnisse?
Ja, in vielen Fällen. Die Plugin-Deaktivierung über FTP oder den Dateimanager erfordert keine Programmierkenntnisse. Der WordPress-Recovery-Modus ist ebenfalls für Einsteiger geeignet.

Verliere ich Daten, wenn ich Plugins deaktiviere?
Nein. Das Deaktivieren eines Plugins löscht keine Daten. Die Daten bleiben in der Datenbank erhalten. Erst das vollständige Löschen eines Plugins kann Daten entfernen, und auch das nur bei bestimmten Plugins.

Warum bekomme ich keine E-Mail von WordPress über den Fehler?
Die E-Mail wird an die Admin-E-Mail-Adresse gesendet, die in den WordPress-Einstellungen hinterlegt ist. Prüfen Sie den Spam-Ordner. Wenn WordPress selbst nicht mehr lädt, kann die E-Mail-Funktion ebenfalls betroffen sein.

Kann ein Hacker-Angriff „Es gab einen kritischen Fehler“ auslösen?
Ja, das ist möglich. Schadcode in Plugins, Themes oder Core-Dateien kann PHP-Fehler verursachen. Wenn keine offensichtliche Ursache (Update, Änderung) vorliegt, sollte die Seite auf Malware geprüft werden.

Wie lange dauert die Reparatur normalerweise?
Bei einem klar identifizierten Plugin- oder Theme-Problem dauert die Reparatur oft unter 15 Minuten. Komplexere Probleme mit beschädigten Kerndateien oder Datenbankfehlern können mehrere Stunden in Anspruch nehmen.

Was ist der Unterschied zwischen „Es gab einen kritischen Fehler“ und dem 500 Internal Server Error?
Beide Fehler können ähnliche Ursachen haben. Der 500-Fehler kommt vom Webserver und erscheint auch bei Nicht-WordPress-Problemen (z.B. Serverkonfiguration). Die WordPress-Meldung ist spezifisch für PHP-Fatal-Errors innerhalb von WordPress.

Muss ich die PHP-Version selbst ändern?
Das geht in der Regel über das Hosting-Panel ohne technische Kenntnisse. Die meisten Anbieter bieten eine einfache Auswahl der PHP-Version im Kundenbereich an.

Kann der Fehler nach einem WordPress-Core-Update auftreten?
Ja. Wenn Plugins oder Themes nicht mit der neuen WordPress-Version kompatibel sind, kann ein kritischer Fehler auftreten. Deshalb sollten Core-Updates immer zuerst in einer Staging-Umgebung getestet werden.

Fazit: „Es gab einen kritischen Fehler“ ist lösbar

Die Meldung „Es gab einen kritischen Fehler auf dieser Website“ klingt bedrohlicher als sie ist. In den meisten Fällen ist die Ursache klar identifizierbar und die Lösung in wenigen Schritten umsetzbar.

Sofortmaßnahmen auf einen Blick:

Admin-E-Mail auf den Recovery-Link prüfen.
Debug-Modus aktivieren und die Datei debug.log lesen.
Das zuletzt aktualisierte Plugin oder Theme deaktivieren.
PHP-Speicherlimit prüfen und ggf. erhöhen.
Bei komplexen Fehlern einen WordPress-Reparaturservice beauftragen.

Langfristig: Regelmäßige Backups, das Testen von Updates in einer Staging-Umgebung und eine aktuelle PHP-Version sind die drei wichtigsten Maßnahmen, um kritische Fehler in Zukunft zu verhindern. Wer seine WordPress-Seite professionell betreuen lassen möchte, findet bei WP.Repair einen zuverlässigen Ansprechpartner für Reparatur und laufende Wartung.

Quellen

WordPress.org Dokumentation: „Debugging in WordPress“ – wordpress.org/documentation/article/debugging-in-wordpress/ (2023)
WordPress.org Release Notes: Version 5.2 „Jaco“ – wordpress.org/news/2019/05/jaco/ (2019)
PHP.net: „Memory Limit Configuration“ – php.net/manual/en/ini.core.php (2024)

Tags: Es gab einen kritischen Fehler, WordPress Fehler beheben, WordPress kritischer Fehler, White Screen of Death, WordPress Plugin Konflikt, WP Debug Modus, PHP Fatal Error WordPress, WordPress Reparatur, WordPress Theme Fehler, WordPress Speicherlimit, WordPress Recovery Modus, WordPress Fehlerbehebung, jaegermediagroup.de

Verschlagwortet es gab einen kritischen fehler, php fatal error wordpress, white screen of death, wordpress fehler beheben, wordpress fehlerbehebung, wordpress kritischer fehler, wordpress plugin konflikt, wordpress recovery modus, wordpress reparatur, wordpress speicherlimit, wordpress theme fehler, wp debug modus