WordPress zeigt einen kritischen Fehler – Ursachen und Lösungen

Wenn WordPress plötzlich nur noch die Meldung "Es gab einen kritischen Fehler auf dieser Website" anzeigt, ist das für die meisten Betreiber:innen erst einmal ein Schreckmoment — die Website ist offline, das Backend oft nicht mehr erreichbar, und die Meldung selbst sagt nichts darüber, was eigentlich kaputt ist. Die gute Nachricht: In den meisten Fällen lässt sich die Ursache systematisch eingrenzen, ohne dass Daten verloren gehen.

Dieser Artikel zeigt, wie Sie vorgehen, welche Ursachen am häufigsten sind und wann es sinnvoller ist, die Fehlersuche in professionelle Hände zu geben.

Was die Meldung eigentlich bedeutet

Seit WordPress 5.2 gibt es einen eingebauten Schutzmechanismus gegen fatale PHP-Fehler ("Fatal Error Protection"). Statt einer weißen Seite ohne jede Information zeigt WordPress seitdem die generische Meldung eines kritischen Fehlers — sowohl Besucher:innen als auch (falls E-Mail-Versand funktioniert) dem Admin per Mail. Die Meldung selbst ist bewusst unspezifisch, damit keine sensiblen Systeminformationen öffentlich sichtbar werden. Das bedeutet aber auch: Um die eigentliche Ursache zu finden, muss man gezielt nachschauen.

Häufige Ursachen

In der Praxis lässt sich ein kritischer Fehler fast immer auf eine dieser Ursachen zurückführen:

• Ein Plugin-Update, das nicht mit der aktuellen WordPress- oder PHP-Version kompatibel ist
• Ein Theme-Update oder eine fehlerhafte Anpassung in der functions.php
• Eine PHP-Versionsänderung beim Hoster, auf die ein Plugin oder Theme nicht vorbereitet ist
• Erschöpfter Arbeitsspeicher (PHP Memory Limit) bei speicherintensiven Plugins
• Eine unvollständige Aktualisierung (z. B. durch einen abgebrochenen Datei-Upload)
• Ein Konflikt zwischen zwei Plugins, die dieselbe Funktion oder Bibliothek unterschiedlich einbinden

Bevor Sie etwas ändern: Backup prüfen

Wichtig: Bevor Sie Dateien löschen, Plugins deaktivieren oder etwas in der Datenbank verändern, prüfen Sie, ob ein aktuelles Backup existiert — idealerweise sowohl der Dateien als auch der Datenbank. Ohne Backup wird jede weitere Änderung riskanter, weil sich Fehler nicht mehr rückgängig machen lassen. Wenn kein Backup vorhanden ist, lohnt es sich, zuerst ein manuelles Backup über den Hosting-Zugang (z. B. per phpMyAdmin und Datei-Export) zu erstellen, bevor Sie weitermachen.

WordPress-Debug-Modus aktivieren

Der Debug-Modus zeigt die eigentliche Fehlermeldung an, statt der generischen Meldung. Dazu öffnen Sie die Datei wp-config.php im Stammverzeichnis Ihrer Installation (per FTP oder Datei-Manager im Hosting-Panel) und passen die folgenden Zeilen an:

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

Mit dieser Kombination wird der Fehler nicht öffentlich auf der Seite angezeigt (wichtig für Besucher:innen), aber in der Datei wp-content/debug.log protokolliert. Dort finden Sie in der Regel eine konkrete Zeile mit Dateiname und Zeilennummer, die auf das verursachende Plugin oder Theme hinweist.

Nach der Fehlersuche sollten WP_DEBUG und WP_DEBUG_LOG wieder auf false gesetzt werden — der Debug-Modus ist nicht für den dauerhaften Betrieb gedacht.

Plugins und Theme systematisch prüfen

Lässt sich die Ursache im Log nicht eindeutig erkennen, hilft ein systematischer Ausschlussprozess:

1. Alle Plugins deaktivieren — entweder über das Backend (falls erreichbar) oder per FTP, indem der plugins-Ordner in plugins_deaktiviert umbenannt wird. WordPress deaktiviert alle Plugins automatisch, wenn der Ordner fehlt.
2. Ist die Website danach wieder erreichbar, liegt die Ursache bei einem Plugin. Ordner zurückbenennen und Plugins einzeln wieder aktivieren, bis der Fehler erneut auftritt.
3. Bleibt der Fehler auch ohne Plugins bestehen, liegt die Ursache wahrscheinlich beim Theme. Testweise auf ein WordPress-Standardtheme (z. B. Twenty Twenty-Four) wechseln — auch das lässt sich per FTP im themes-Ordner nachvollziehen, indem der Theme-Ordner umbenannt wird.

Hosting und PHP-Version prüfen

Nicht jede Ursache liegt an Plugins oder Themes. Ein häufiger, oft übersehener Fall: Der Hoster hat automatisch die PHP-Version aktualisiert, und ein älteres Plugin oder Theme ist damit nicht kompatibel. Im Hosting-Panel lässt sich die aktuelle PHP-Version meist einsehen und in vielen Fällen auch gezielt auf eine ältere, kompatible Version zurücksetzen — als kurzfristige Übergangslösung, nicht als Dauerzustand.

Auch ein zu niedriges PHP Memory Limit kann kritische Fehler auslösen, besonders bei Seiten mit vielen Plugins oder einem umfangreichen Theme. Das Limit lässt sich häufig im Hosting-Panel oder über die wp-config.php anpassen:

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

Wann professionelle Hilfe sinnvoll ist

Die oben beschriebenen Schritte lösen die meisten kritischen Fehler. Es gibt aber Situationen, in denen sich externe Unterstützung lohnt — etwa wenn:

• kein Backup existiert und die Datenbank ebenfalls betroffen sein könnte,
• der Fehler nach dem Deaktivieren aller Plugins und dem Theme-Wechsel weiterhin besteht,
• die Website für Kund:innen oder Patient:innen zentral ist und jede Ausfallzeit Geschäft kostet,
• oder schlicht die Zeit fehlt, sich durch Logs und FTP-Zugänge zu arbeiten.

In diesen Fällen ist es meist schneller und sicherer, jemanden mit Erfahrung in WordPress-Wartung die Fehlersuche und Behebung übernehmen zu lassen, statt auf eigene Faust weiter zu testen und das Risiko einzugehen, den Fehler zu verschlimmern.

Alsterform übernimmt genau solche Fälle: WordPress-Fehlerbehebung, technische SEO-Grundlagen und laufende technische Betreuung, damit solche Ausfälle seltener werden und schneller behoben sind, wenn sie doch passieren.