WordPress: kritischer Fehler auf dieser Website, was jetzt hilft

Vier Symptome, vier erste Schritte

Was du zuerst tust, hängt davon ab, was auf dem Bildschirm steht. Die vier Fälle und der jeweils schnellste Weg zur Ursache:

Was die Meldung bedeutet

Der Satz ist die Standardausgabe von WordPress für einen abgebrochenen PHP-Vorgang, seit Version 5.2 auch bekannt als Fatal Error Protection. Irgendwo im Code wurde eine Funktion aufgerufen, die es nicht gibt, eine Datei eingebunden, die fehlt, oder eine Grenze überschritten, etwa der verfügbare Speicher. WordPress bricht ab und zeigt statt einer weißen Seite diesen Hinweis.

Das ist eine gute Nachricht, denn es bedeutet zwei Dinge: der Server läuft, und WordPress hat den Fehler bemerkt. Wer stattdessen eine komplett weiße Seite sieht, hat dieselbe Fehlerklasse ohne Schutzmeldung, meist weil die Ausgabe von Fehlern abgeschaltet ist. Und wer HTTP 500 oder 503 bekommt, hat ein Problem, das vor WordPress liegt, also beim Webserver oder bei PHP selbst.

Der schnellste Weg: die Recovery-Mail

WordPress schickt beim kritischen Fehler automatisch eine E-Mail an die Administratoradresse aus den Einstellungen, mit dem Betreff, dass die Website ein technisches Problem hat. Diese Mail ist das wertvollste Werkzeug in der ganzen Situation, denn sie enthält zwei Dinge:

• Die Ursache im Klartext: Name des Plugins oder Themes, die betroffene Datei und die Zeilennummer, dazu die Fehlermeldung von PHP.
• Einen Link in den Wiederherstellungsmodus. Darüber kommst du ins Dashboard, auch wenn die Seite selbst nicht mehr lädt. Das fehlerhafte Plugin ist dort automatisch pausiert und lässt sich deaktivieren.

Suche im Postfach nach „WordPress“ und sieh dabei in den Spam-Ordner. Findest du die Mail nicht, liegt das oft daran, dass die Adresse in den Einstellungen veraltet ist oder der Mailversand der Website nicht funktioniert. Dann geht es über den zweiten Weg weiter.

Ohne Mail: den Fehler sichtbar machen

Ohne die Meldung im Klartext ist jede Reparatur ein Ratespiel. Du brauchst dafür Dateizugriff über SFTP oder den Dateimanager des Hosters. Öffne wp-config.php und ergänze oberhalb der Zeile mit /* That's all, stop editing! */:

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

Ruf die Seite danach einmal auf. WordPress schreibt den Fehler jetzt in wp-content/debug.log. Die letzte Zeile darin nennt Datei und Zeilennummer, und damit weißt du, welche Erweiterung den Ausfall verursacht.

Wichtig: WP_DEBUG_DISPLAY steht bewusst auf false. Sonst erscheinen Pfade und Dateinamen für jeden Besucher sichtbar auf der Seite, und das ist eine Information, die niemand außerhalb braucht. Nach der Reparatur setzt du alle drei Zeilen zurück auf false oder löschst sie.

Wer SSH hat, sieht dasselbe schneller:

tail -n 40 wp-content/debug.log

Die vier häufigsten Ursachen

In der Praxis führen vier Dinge zu dieser Fehlermeldung, und sie lassen sich in dieser Reihenfolge abarbeiten.

1. Ein Plugin nach dem Update

Der Regelfall: die Seite lief, ein Update kam, jetzt steht sie. Du brauchst kein Dashboard, um das zu prüfen, und kein Terminal. Öffne den Dateimanager im Kundenmenü deines Hosters, geh in den Ordner wp-content und benenn den Ordner plugins um, etwa in plugins-aus. Rechtsklick, umbenennen, fertig. Mit SSH-Zugang ist es ein Befehl:

mv wp-content/plugins wp-content/plugins-aus

WordPress findet dann keine Erweiterungen und deaktiviert alle auf einmal. Lädt die Seite danach, war es ein Plugin. Benenn den Ordner zurück und schalte die Plugins einzeln wieder ein, bis der Fehler wiederkommt. Die Einstellungen bleiben dabei erhalten, sie liegen in der Datenbank und nicht im Ordner.

2. Die PHP-Version passt nicht mehr

Der zweite Klassiker, und er tritt oft ohne eigenes Zutun auf: der Hoster hebt die PHP-Version an, ein älteres Plugin nutzt eine Funktion, die es in der neuen Version nicht mehr gibt. Typische Meldung im Protokoll ist ein Uncaught Error mit einem Funktionsnamen. Im Hosting-Panel lässt sich die vorherige PHP-Version meist für ein paar Tage zurückstellen. Das ist eine Notlösung, keine Reparatur: eine PHP-Version ohne Sicherheitsupdates ist ein eigenes Risiko, und die eigentliche Antwort ist ein Ersatz für das Plugin.

3. Der Speicher reicht nicht

Erkennbar an Allowed memory size of … bytes exhausted. In wp-config.php:

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

Greift das nicht, ist die Grenze serverseitig gesetzt und der Hoster muss ran. Ein Speicherbedarf, der plötzlich steigt, ist allerdings selten harmlos: dahinter steckt oft eine Endlosschleife in einem Plugin oder ein Import, der zu groß geworden ist.

4. Das Theme oder eine eigene Anpassung

Nennt das Protokoll die functions.php des Themes, ist die Ursache dort. Häufig war ein Code-Schnipsel im Spiel, der irgendwann per Copy-und-Paste eingefügt wurde und nach einem Update nicht mehr passt. Zum Prüfen genügt ein Wechsel auf ein Standardtheme:

wp theme list --status=inactive
wp theme activate <name-des-standardthemes>

Ohne WP-CLI geht es auch über den Ordner: benenn im Dateimanager den Ordner des aktiven Themes unter wp-content/themes um. WordPress fällt dann automatisch auf ein installiertes Standardtheme zurück, vorausgesetzt es liegt noch eines daneben. Genau deshalb gehört ein Standardtheme auf jeder Installation belassen, auch wenn es nie benutzt wird.

Wenn du nicht mehr ins Dashboard kommst

Der Login unter /wp-admin ist ebenfalls eine PHP-Seite, er fällt bei einem kritischen Fehler also oft mit aus. Drei Wege hinein, in dieser Reihenfolge:

1. Wiederherstellungsmodus: der Link aus der Recovery-Mail. Er funktioniert auch dann, wenn der normale Login eine Fehlerseite zeigt.
2. Alles deaktivieren: Plugin-Ordner umbenennen, wie oben. Danach ist der Login fast immer wieder erreichbar.
3. Neues Administratorkonto: Wenn die Anmeldung selbst das Problem ist, mit SSH wp user create notfall deine@mail.de --role=administrator, sonst über phpMyAdmin.

Kommst du nicht hinein und findest keine Erklärung im Protokoll, prüf, ob es überhaupt ein technischer Fehler ist. Ein gesperrter Login gehört auch zum Bild einer kompromittierten Installation.

Sonderfall: der Wartungsmodus hängt

Zeigt die Seite dauerhaft „Kurz nicht verfügbar wegen geplanter Wartungsarbeiten“, ist gar kein Fehler passiert: ein Update wurde abgebrochen. WordPress legt zu Beginn jedes Updates die Datei .maintenance im Stammverzeichnis an und löscht sie danach wieder. Bricht der Vorgang ab, bleibt sie liegen.

rm .maintenance

Danach ist die Seite sofort wieder da. Prüf anschließend im Dashboard, ob das Update vollständig durchgelaufen ist, und spiel es bei Bedarf erneut ein.

Wann es kein Update-Fehler ist

Drei Anzeichen sprechen dafür, dass der Ausfall eine andere Ursache hat als ein Plugin:

• Der Fehler kommt zurück, obwohl du das Plugin deaktiviert hast. Dann schreibt etwas die Dateien neu, und das ist ein Muster von eingeschleustem Code.
• Das Protokoll nennt eine Datei, die es nicht geben dürfte, etwa in wp-content/uploads oder in mu-plugins.
• Niemand hat etwas geändert. Kein Update, kein neues Plugin, keine Anpassung, und die Seite fällt trotzdem aus. Dann ist die Frage nicht, was kaputt ist, sondern wer daran war.

In diesen Fällen bringt das Zurückspielen eines Backups nur eine Pause. Der Weg führt über eine vollständige Bereinigung, sonst steht die Seite am nächsten Tag wieder.

Damit es nicht wieder passiert

Ein kritischer Fehler ist fast immer die Folge eines Updates ohne Rückweg. Vier Dinge verhindern die Wiederholung:

• Backup vor jedem Update, nicht nach Zeitplan. Der Zeitpunkt, an dem ein Backup zählt, ist der Moment davor.
• Updates nicht auf der Live-Seite, sondern gestuft über eine Kopie. Ab etwa zehn Installationen ist das die einzige Variante, die in den Arbeitstag passt.
• Administratoradresse pflegen. Die Recovery-Mail ist nur so gut wie das Postfach, in das sie geht. Prüf sie einmal im Jahr, und prüf gleich mit, ob die Website überhaupt Mails versenden kann.
• Verfügbarkeit überwachen. Ein Ausfall, den der Betreiber vom Kunden erfährt, hat meistens Stunden gedauert. Ein Monitoring meldet ihn in Minuten, das ist Teil jedes Wartungspakets.

Wenn die Seite gerade steht und du an einer der Stellen oben nicht weiterkommst: die WordPress-Soforthilfe nennt die vier Symptome mit dem jeweils ersten Schritt, die Grenzen der Selbsthilfe und was eine Beauftragung kostet. Für Berliner Unternehmen geht das auch persönlich, über die Betreuung in Berlin.

Quellen

• WordPress Developer Docs: Debugging in WordPress
• WordPress Developer Docs: Editing wp-config.php
• Make WordPress Core: Fatal Error Recovery Mode in 5.2