„Es gab einen kritischen Fehler auf deiner Website“: So beheben Sie ihn

Diese Meldung sieht schlimmer aus, als sie ist. Sie bedeutet: PHP ist beim Laden der Seite auf einen Fehler gestoßen, fast immer in einem Plugin oder Theme, fast immer direkt nach einem Update. Ihre Inhalte sind nicht weg. In den meisten Fällen ist die Seite in zehn Minuten wieder da. Wenn nicht, übernehme ich zum Festpreis von 149 €.

Auf dieser Seite: die Bedeutung der Meldung, vier Schritte zur Behebung (Wiederherstellungs-Mail, Plugins per FTP abschalten, Fehlerprotokoll mit WP_DEBUG lesen, PHP-Version und Speicher), echte Einträge aus dem debug.log mit Erklärung, was zu tun ist, wenn der Fehler immer wiederkommt, und wann Sie besser aufhören.

Was die Meldung bedeutet

Seit WordPress 5.2 fängt WordPress schwere PHP-Fehler ab und zeigt statt einer weißen Seite diesen Satz. Die eigentliche Fehlermeldung steht nicht auf der Seite, sondern in einer Mail an die Administrator-Adresse und im Fehlerprotokoll des Servers. Die häufigsten Ursachen, in dieser Reihenfolge:

1. Ein Plugin-Update, das mit einem anderen Plugin oder der PHP-Version nicht zusammenpasst.
2. Ein Theme-Update oder eine Änderung an der Datei functions.php.
3. Ein PHP-Versionswechsel beim Hoster, meist auf PHP 8, mit dem ein altes Plugin nicht umgehen kann.
4. Zu wenig Arbeitsspeicher für PHP (Memory Limit).
5. Ein Hack, der Dateien verändert hat. Seltener, aber dann sollte die Seite bereinigt werden.

Die Varianten der Meldung

Je nach WordPress-Version und je nachdem, ob die Mail schon verschickt wurde, lautet der Text etwas anders. Gemeint ist immer dasselbe:

• „Es gab einen kritischen Fehler auf deiner Website.“
• „Es gab einen kritischen Fehler auf dieser Website.“
• „Es gab einen kritischen Fehler auf deiner Website. Bitte überprüfe den Posteingang deiner Website-Administrator-E-Mail-Adresse, um Anweisungen zu erhalten.“ Dieser Zusatz heißt: WordPress hat die Wiederherstellungs-Mail gerade verschickt. Weiter mit Schritt 1.
• Ein Hinweis, dass die Website in den Wiederherstellungsmodus versetzt wurde: Den sehen Sie, wenn Sie bereits über den Link aus der Mail eingeloggt sind.
• Auf englischen Installationen: „There has been a critical error on this website.“

Steht stattdessen nur eine leere weiße Seite oder „HTTP ERROR 500“ im Browser, ist die Ursache meist dieselbe, nur ohne den freundlichen Hinweis. Die Wege unten gelten genauso; weitere Fehlerbilder erkläre ich unter WordPress-Fehler beheben.

Schritt 1: Die Wiederherstellungs-Mail nutzen

Prüfen Sie das Postfach der Administrator-Adresse, auch den Spam-Ordner. WordPress hat eine Mail mit dem Betreff „Deine Website hat ein technisches Problem“ geschickt. Darin steht, welches Plugin oder Theme den Fehler verursacht, und ein Link in den Wiederherstellungsmodus. Über diesen Link kommen Sie ins Backend, obwohl die Seite vorne nicht lädt. Deaktivieren Sie dort das genannte Plugin. Fertig.

Der Link ist 24 Stunden gültig. Wenn die Mail nicht da ist, weiter mit Schritt 2.

Was der Wiederherstellungsmodus macht

Im Wiederherstellungsmodus pausiert WordPress das fehlerhafte Plugin oder Theme, aber nur für Ihre Sitzung. Besucher sehen weiterhin die Fehlermeldung, bis Sie das Plugin deaktiviert, aktualisiert oder ersetzt haben. Unter „Plugins“ steht beim betroffenen Plugin ein Hinweis mit Dateipfad und Zeilennummer. Diese Angabe ist Gold wert: Schreiben Sie sie ab, bevor Sie etwas ändern. Danach verlassen Sie den Wiederherstellungsmodus über den Eintrag oben in der Werkzeugleiste und prüfen die Seite in einem privaten Browserfenster.

Der Link ist abgelaufen

WordPress verschickt die Mail höchstens einmal am Tag. Ist der Link abgelaufen, kommt also nicht sofort eine neue Mail, auch wenn der Fehler weiter besteht. Warten Sie nicht darauf, sondern gehen Sie den FTP-Weg aus Schritt 2. Der funktioniert immer, unabhängig von Mails.

Die Mail kommt nicht an

Drei Gründe sehe ich immer wieder:

1. Die Administrator-Adresse ist veraltet, etwa die Adresse des früheren Webdesigners oder ein abgeschaltetes Postfach.
2. Der Server verschickt Mails ohne Absender-Berechtigung (kein SMTP, fehlendes SPF), und der Empfänger sortiert sie aus.
3. Der Fehler tritt so früh auf, dass WordPress die Mail gar nicht mehr verschicken kann.

Nach der Reparatur lohnt sich das Aufräumen: Unter „Einstellungen → Allgemein“ die Administrator-Adresse auf ein Postfach setzen, das Sie lesen, und den Mailversand über ein SMTP-Plugin mit echtem Postfach laufen lassen. Wer die Wiederherstellungs-Mails an eine andere Adresse schicken will, kann in der wp-config.php die Konstante RECOVERY_MODE_EMAIL setzen.

Schritt 2: Das Plugin per FTP oder Hoster-Dateimanager abschalten

1. Loggen Sie sich per FTP oder im Dateimanager Ihres Hosters ein.
2. Öffnen Sie den Ordner wp-content/plugins/.
3. Wenn Sie wissen, welches Plugin Sie zuletzt aktualisiert haben: Benennen Sie dessen Ordner um, etwa in pluginname_aus. WordPress deaktiviert das Plugin dann automatisch.
4. Wenn Sie es nicht wissen: Benennen Sie den ganzen Ordner plugins in plugins_aus um. Lädt die Seite jetzt, war es ein Plugin. Benennen Sie den Ordner zurück und schalten Sie die Plugins im Backend einzeln wieder ein, bis der Fehler wieder auftritt.
5. Lädt die Seite auch ohne Plugins nicht, ist es das Theme: Benennen Sie in wp-content/themes/ den Ordner Ihres aktiven Themes um. WordPress fällt dann auf ein Standard-Theme zurück.

Die Zugangsdaten für FTP oder SFTP finden Sie im Kundenmenü Ihres Hosters, meist unter „FTP-Zugänge“ oder „Dateimanager“. Löschen Sie dabei nichts, umbenennen reicht. So können Sie jeden Schritt rückgängig machen.

Ohne FTP: Plugins über die Datenbank oder WP-CLI abschalten

Wenn Sie nur an die Datenbank kommen, etwa über phpMyAdmin im Hosting-Menü: In der Tabelle wp_options (das Präfix kann anders heißen) steht in der Zeile active_plugins die Liste aller aktiven Plugins. Kopieren Sie den Wert zuerst in eine Textdatei, dann ersetzen Sie ihn durch a:0:{}. Damit sind alle Plugins aus, ohne dass Einstellungen verloren gehen.

Mit SSH-Zugang geht es schneller:

wp plugin deactivate pluginname
wp plugin deactivate --all

Das Theme wechseln, ohne ins Backend zu kommen

Der Rückfall auf ein Standard-Theme klappt nur, wenn eines installiert ist, etwa Twenty Twenty-Five. Prüfen Sie im Ordner wp-content/themes/, ob es da ist, sonst laden Sie es vorher von wordpress.org hoch. Über die Datenbank setzen Sie in wp_options die beiden Zeilen template und stylesheet auf den Ordnernamen des Standard-Themes, zum Beispiel twentytwentyfive. Per SSH: wp theme activate twentytwentyfive. Ihre Inhalte bleiben dabei unberührt, nur Menüs und Widgets müssen nach dem Zurückwechseln eventuell neu zugeordnet werden.

Schritt 3: Die Ursache im Fehlerprotokoll finden (WP_DEBUG)

Wenn weder die Mail noch das Umbenennen eindeutig zeigen, was los ist, schalten Sie das Fehlerprotokoll von WordPress ein. Öffnen Sie die Datei wp-config.php im Hauptordner der Installation. Dort steht meist schon eine Zeile define( 'WP_DEBUG', false );. Ersetzen Sie genau diese Zeile durch:

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

Wichtig: die Zeile ersetzen, nicht zusätzlich einfügen. Doppelt definierte Konstanten erzeugen neue Warnungen. WP_DEBUG_DISPLAY auf false sorgt dafür, dass Besucher keine Fehlermeldungen mit Dateipfaden sehen.

Rufen Sie die Seite danach einmal auf. WordPress schreibt jetzt alle Fehler in die Datei wp-content/debug.log. Laden Sie die Datei herunter und lesen Sie sie von unten nach oben: Der letzte Eintrag mit „Fatal error“ ist fast immer der Schuldige.

So ist ein Eintrag aufgebaut:

[01-Oct-2026 08:14:03 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /html/wordpress/wp-content/plugins/alter-slider/includes/slider.php:88

• Zeitstempel: in UTC, also im Sommer zwei Stunden hinter der deutschen Zeit. Passt er zum Zeitpunkt des Updates?
• Art des Fehlers: Nur „Fatal error“ und „Parse error“ legen die Seite lahm. „Warning“, „Notice“ und „Deprecated“ sind Hinweise und für den kritischen Fehler meist nicht verantwortlich.
• Dateipfad: Der Ordnername nach plugins/ oder themes/ verrät, welches Plugin oder Theme schuld ist. Hier wäre es alter-slider.

Wenn Sie fertig sind, setzen Sie WP_DEBUG wieder auf false und löschen die debug.log. Die Datei liegt im öffentlich erreichbaren Ordner wp-content und verrät Angreifern Pfade und Plugin-Namen. Wer das Protokoll länger braucht, gibt WP_DEBUG_LOG statt true einen Pfad außerhalb des Web-Verzeichnisses. Zusätzlich führt fast jeder Hoster ein eigenes PHP-Fehlerprotokoll, meist im Kundenmenü unter „Logs“ oder in einem Ordner logs neben dem Web-Verzeichnis.

Typische Einträge im debug.log und was sie bedeuten

„Allowed memory size of … bytes exhausted“

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /html/wordpress/wp-content/plugins/elementor/core/files/manager.php on line 154

PHP hat das Speicherlimit erreicht, hier 128 MB (134.217.728 Byte). Die genannte Datei ist nicht unbedingt der Verursacher, sondern nur die Stelle, an der der Speicher ausging. Lösung: Speicherlimit erhöhen (Schritt 4). Tritt der Fehler auch bei 512 MB auf, steckt eine Endlosschleife in einem Plugin dahinter, und mehr Speicher hilft nicht.

„Call to undefined function“

PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /html/wordpress/wp-content/plugins/alter-slider/includes/slider.php:88

Ein Plugin ruft eine Funktion auf, die es nicht gibt. Zwei typische Gründe: Die Funktion wurde aus PHP entfernt, create_function() etwa mit PHP 8.0. Oder ein Zusatz-Plugin braucht ein Haupt-Plugin, das gerade deaktiviert ist, zum Beispiel eine WooCommerce-Erweiterung mit Call to undefined function wc_get_product(). Im ersten Fall braucht das Plugin ein Update oder einen Ersatz, im zweiten das Haupt-Plugin wieder aktivieren.

„Uncaught Error“ oder „Uncaught TypeError“ nach einem PHP-Update

PHP Fatal error:  Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /html/wordpress/wp-content/themes/mein-theme/functions.php:212

PHP 8 ist strenger als PHP 7. Was früher eine Warnung war, bricht heute ab. Das passiert typischerweise, wenn der Hoster die PHP-Version umstellt und ein Theme oder Plugin seit Jahren kein Update bekommen hat. Welche PHP-Versionen noch Sicherheitsupdates erhalten und wie lange, zeige ich tagesaktuell unter Aktuelle PHP-Version.

„Parse error: syntax error“

PHP Parse error:  syntax error, unexpected '}' in /html/wordpress/wp-content/themes/mein-theme/functions.php on line 45

Ein Tippfehler im Code, fast immer nach einer Änderung an der functions.php oder nach dem Einfügen eines Code-Schnipsels. Öffnen Sie die Datei per FTP, gehen Sie zur genannten Zeile und machen Sie die letzte Änderung rückgängig. Wenn Sie nicht wissen, was geändert wurde: Datei aus dem Backup zurückspielen.

„Cannot redeclare“

PHP Fatal error:  Cannot redeclare meine_funktion() (previously declared in …/plugins/plugin-a/a.php:12) in …/plugins/plugin-b/b.php on line 30

Zwei Plugins oder ein Plugin und das Theme bringen eine gleichnamige Funktion mit. Häufig nach dem Installieren einer zweiten Version desselben Plugins oder eines Code-Schnipsels, der schon im Theme steckt. Eines der beiden abschalten.

Schritt 4: PHP-Version und Speicher prüfen

Wenn der Fehler nach einer Umstellung beim Hoster aufgetreten ist, stellen Sie die PHP-Version im Hosting-Menü vorübergehend eine Stufe zurück, etwa von 8.3 auf 8.1. Lädt die Seite, ist ein Plugin nicht bereit für die neue Version. Es braucht ein Update oder einen Ersatz. Das Zurückstellen ist nur eine Brücke: Alte PHP-Versionen bekommen keine Sicherheitsupdates mehr, und manche Hoster bieten sie gar nicht mehr an.

Memory Limit erhöhen

Bei „Allowed memory size exhausted“ im Fehlerprotokoll: Ergänzen Sie in der wp-config.php vor der Zeile „That’s all, stop editing“ die Zeile

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

Für das Backend, etwa beim Bearbeiten großer Seiten mit einem Seitenbaukasten, gibt es einen eigenen Wert:

define('WP_MAX_MEMORY_LIMIT', '512M');

WordPress kann sich nur so viel Speicher nehmen, wie der Hoster erlaubt. Steht im Hosting-Menü ein PHP-Speicherlimit von 128 MB, bewirkt die Zeile in der wp-config.php nichts. Dann das Limit dort hochsetzen, bei manchen Hostern über eine Datei .user.ini mit memory_limit = 256M im Hauptordner. Ob der neue Wert greift, sehen Sie im Backend unter „Werkzeuge → Website-Zustand → Bericht → Server“.

Nach jeder Reparatur: Cache leeren. Ein Cache-Plugin, der Server-Cache des Hosters oder ein CDN wie Cloudflare liefern sonst noch eine Weile die alte Fehlerseite aus.

Wenn der Fehler immer wieder kommt

Sie haben das Plugin abgeschaltet, die Seite läuft, und ein paar Tage später ist die Meldung zurück. Das hat fast immer einen dieser Gründe:

• Automatische Updates: Das Plugin ist für automatische Updates eingeschaltet, oder ein anderes Plugin aktualisiert sich selbst und bricht erneut. Automatische Updates für das betroffene Plugin abschalten, bis die Ursache geklärt ist.
• Speicher knapp auf Kante: Die Seite läuft meistens, aber bei vielen Besuchern, beim Backup oder beim nächtlichen Cron-Lauf reicht der Speicher nicht. Im debug.log stehen dann Speicherfehler zu immer ähnlichen Uhrzeiten.
• Geplante Aufgaben (Cron): Ein Plugin führt nachts eine Aufgabe aus, die abbricht, etwa einen Import oder einen Newsletter-Versand. Der Zeitstempel im Protokoll verrät es.
• Das Plugin wurde wieder aktiviert: Jemand im Team, eine Agentur oder ein Wartungs-Tool hat es zurückgeholt. Lieber ersetzen und löschen statt nur deaktivieren.
• Veränderte Dateien: Wenn im Protokoll Dateien auftauchen, die Sie nicht kennen, oder der Fehler ohne jedes Update wiederkommt, kann ein Hack dahinterstecken. Dann hilft kein Abschalten, die Seite muss bereinigt werden. Mehr dazu unter WordPress gehackt.

Bei wiederkehrenden Fehlern lasse ich das Fehlerprotokoll eine Woche mitlaufen, mit dem Pfad außerhalb des Web-Verzeichnisses. Danach ist die Ursache in aller Regel eindeutig.

Sonderfälle

Die Wiederherstellungs-Mail kommt nicht. Häufigster Grund: Der Server kann keine Mails versenden, oder die Administrator-Adresse ist eine alte Adresse des Webdesigners. Dann bleibt der FTP-Weg aus Schritt 2. Nach der Behebung sollte die Admin-Adresse in den Einstellungen auf eine Adresse zeigen, die Sie lesen, und der Mailversand über SMTP laufen.

Der Fehler erscheint nur im Backend, die Seite vorne läuft. Dann steckt der Fehler in einem Plugin, das nur im Backend lädt, etwa einem Seiteneditor, einem SEO-Plugin oder einem Backup-Plugin. Sie können die Plugins per FTP einzeln umbenennen und dabei das Backend im Blick behalten.

Der Fehler erscheint nur beim Login. Typisch für Sicherheits-Plugins mit Login-Schutz oder für Plugins, die den Login-Bildschirm gestalten. Per FTP deaktivieren, einloggen, dann prüfen, ob es ein Update gibt.

Nach der PHP-Umstellung des Hosters. Hoster stellen alte PHP-Versionen ab und schalten auf PHP 8.2 oder 8.3 um, manchmal ohne Ankündigung. Plugins, die seit 2020 kein Update bekommen haben, brechen dann sofort. Zurück auf die alte Version geht oft nicht mehr. Die Lösung ist, das Plugin zu ersetzen; ich kenne für die meisten alten Plugins den gepflegten Nachfolger.

Nach dem WordPress-Core-Update. Selten die Ursache, aber es kommt vor, wenn ein Theme veraltete Funktionen nutzt. Das Standard-Theme aktivieren, dann läuft die Seite ohne Design. Danach das Theme aktualisieren oder ersetzen. Welche WordPress-Version gerade aktuell ist und wie verbreitet die älteren noch sind, steht unter Aktuelle WordPress-Version.

Plugins deaktiviert, Fehler bleibt. Dann liegt es am Theme, an einer Datei in wp-content/mu-plugins, an einer beschädigten Kerndatei oder am Speicherlimit. In dieser Reihenfolge prüfen. Bei beschädigten Kerndateien hilft es, WordPress in derselben Version neu über die Installation zu kopieren, ohne den Ordner wp-content.

Elementor, Divi und andere Seitenbaukästen. Diese Plugins sind groß und brauchen viel Speicher. Der kritische Fehler tritt hier gern beim Speichern einer Seite auf. Speicherlimit auf 256 MB oder mehr, dann prüfen, ob eine Erweiterung des Baukastens veraltet ist.

WooCommerce. Ein kritischer Fehler im Shop heißt: keine Bestellungen. Hier gilt zuerst: Wartungsmodus einschalten, damit Kunden keine halben Bestellungen anlegen, dann reparieren. Meist ist eine Zahlungs- oder Versanderweiterung schuld, die mit der neuen WooCommerce-Version nicht mehr zusammenpasst.

Nichts hilft, aber es gibt ein Backup. Ein Backup vom Tag vor dem Fehler ist oft der schnellste Weg zurück. Achten Sie darauf, dass dabei keine neuen Bestellungen oder Formulareingänge verloren gehen. Wie das sauber geht, beschreibe ich unter Website wiederherstellen.

Wann Sie aufhören und Hilfe holen sollten

Die Schritte oben lösen die meisten Fälle. Es gibt aber Situationen, in denen Ausprobieren mehr kaputt macht als repariert. Ich würde aufhören, wenn:

• Sie nach einer Stunde noch nicht wissen, welches Plugin oder Theme schuld ist.
• Das Fehlerprotokoll auf Dateien zeigt, die Sie nicht kennen, oder die Seite Besucher auf fremde Seiten umleitet.
• Es sich um einen Shop handelt und jede Stunde Ausfall Bestellungen kostet.
• Die Lösung bedeuten würde, Code im Theme oder in einem Plugin zu ändern.
• Es kein aktuelles Backup gibt und Sie nicht sicher sind, was ein Rückschritt löscht.
• Sie keinen FTP- oder Datenbankzugang haben und der Hoster nicht weiterhilft.

Dann ist der schnellste Weg, mir die Adresse zu schicken. Wie die Soforthilfe abläuft und was sie kostet, steht unter WordPress-Soforthilfe.

Wenn nichts hilft: Ich übernehme, Festpreis 149 €

Sie schicken mir die Adresse und die Zugangsdaten, ich lese das Fehlerprotokoll und behebe die Ursache. Diagnose kostenlos, Behebung 149 € netto bis zwei Stunden Arbeit. Wenn es mehr braucht, weil etwa ein Plugin ersetzt und die Seite angepasst werden muss, sage ich Ihnen vorher den Festpreis. Antwort werktags innerhalb von 24 Stunden.

Bei einem Wartungsvertrag ist die Behebung inklusive. Und mit Plus oder Betreuung wäre der Fehler gar nicht erst live gegangen, weil ich Updates vorher auf einer Kopie teste.

Vorbeugen: Damit es nicht wieder passiert

• Updates nicht auf der Live-Seite testen, sondern auf einer Staging-Kopie.
• Vor jedem Update ein Backup, das man in fünf Minuten einspielen kann.
• Plugins, die seit über einem Jahr kein Update bekommen haben, ersetzen.
• PHP-Umstellungen des Hosters ernst nehmen und vorher prüfen.
• Die Administrator-Adresse aktuell halten und Mails über SMTP verschicken, damit die Wiederherstellungs-Mail ankommt.
• Den FTP-Zugang griffbereit haben, bevor etwas passiert, nicht erst danach.

Genau das ist WordPress-Wartung ab 49 € im Monat.

Häufige Fragen

Notfall melden

Sofortige Eingangsbestätigung, werktags innerhalb von 24 Stunden Diagnose und Angebot.

---