WordPress: kritischer Fehler & weißer Bildschirm beheben

Es ist ein besonderer Moment: Sie rufen Ihre eigene Website auf und sehen nichts. Kein Menü, kein Logo, keine Fehlermeldung — nur Weiß. Oder einen einzigen grauen Satz: „Auf der Website ist ein kritischer Fehler aufgetreten.”

Der erste Reflex ist meistens der falsche. Er lautet: irgendetwas ändern. Plugins löschen, ein Backup einspielen, beim Hoster anrufen und die PHP-Version zurückstellen lassen. Manches davon hilft, vieles macht die Lage schlechter — vor allem, weil es die Spuren vernichtet, an denen sich die Ursache ablesen lässt.

Dieser Ratgeber geht die Schritte in der Reihenfolge durch, in der ein Techniker sie gehen würde.

Erst verstehen: Was die Meldung bedeutet

WordPress fängt seit Version 5.2 schwere PHP-Fehler ab, statt die Seite einfach leer auszuliefern. Dabei passieren zwei Dinge gleichzeitig:

1. Besucher sehen die Meldung „Auf der Website ist ein kritischer Fehler aufgetreten.”
2. An die im System hinterlegte Administratoradresse geht eine E-Mail, die den Fehler benennt — mit Datei, Zeile und in der Regel dem verantwortlichen Plugin oder Theme. Diese Mail enthält außerdem einen Link in den Wiederherstellungsmodus, über den Sie sich anmelden und die betroffene Erweiterung deaktivieren können, obwohl die Seite selbst nicht läuft.

Genau diese Mail ist der Grund, warum der erste Schritt nicht am Server stattfindet, sondern im Postfach.

Der häufigste Haken: Die Administratoradresse ist eine alte Adresse. Die des Praktikanten, der vor drei Jahren die Seite aufgesetzt hat, oder eine Adresse bei einem Hoster, den es nicht mehr gibt. Dann liegt die Antwort in einem Postfach, das niemand liest. Prüfen Sie deshalb in ruhigen Zeiten unter Einstellungen → Allgemein, welche E-Mail-Adresse dort steht.

Sehen Sie dagegen einen komplett leeren Bildschirm ohne jede Meldung, ist die Fehlerausgabe serverseitig unterdrückt und WordPress konnte den Fehler nicht mehr abfangen. Dann führt der Weg über das Protokoll.

Schritt 1: Was ist zuletzt passiert?

Bevor Sie irgendetwas anfassen, beantworten Sie diese Frage. In neun von zehn Fällen steht die Ursache schon darin:

• Wurde ein Update eingespielt — WordPress selbst, ein Theme oder ein Plugin? Auch automatische Updates zählen, die niemand bewusst angestoßen hat.
• Wurde ein neues Plugin installiert?
• Kam vom Hoster eine Mitteilung über eine PHP-Umstellung? Das ist der klassische Auslöser für Seiten, die wochenlang unverändert liefen und plötzlich nicht mehr.
• Wurde etwas im Code geändert — ein Schnipsel in der functions.php, ein Tracking-Code, eine Anpassung im Theme?

Notieren Sie die Antwort. Sie ist die halbe Diagnose.

Schritt 2: Sichern, bevor Sie eingreifen

Bevor Sie das erste Plugin anfassen, brauchen Sie eine Sicherung von Dateien und Datenbank. Nicht das Backup von letzter Woche — eine Sicherung des aktuellen, kaputten Zustands. Sie kostet fünf Minuten und ist die Versicherung dagegen, dass aus einem Anzeigefehler ein Datenverlust wird.

Die meisten Hoster bieten das im Kundenbereich mit zwei Klicks an. Wo das fehlt: Dateien per FTP herunterladen, Datenbank über phpMyAdmin exportieren.

Schritt 3: Das Fehlerprotokoll lesen

Hier steht die Antwort, und zwar meist im Klartext. Es gibt zwei Wege:

Über den Hoster. Fast jeder Webhoster bietet im Kundenbereich ein Fehlerprotokoll („Error Log”). Suchen Sie den letzten Eintrag mit dem Vermerk Fatal error. Dahinter steht die Datei — und aus deren Pfad ergibt sich fast immer sofort das Plugin oder Theme.

Über WordPress selbst. In der Datei wp-config.php lässt sich die Protokollierung einschalten:

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

Die Zeilen gehören oberhalb von /* That's all, stop editing! */. Danach schreibt WordPress Fehler in die Datei wp-content/debug.log. Wichtig: WP_DEBUG_DISPLAY auf false lassen, damit Besucher die Fehler nicht zu sehen bekommen — und die Protokollierung wieder abschalten, sobald das Problem gelöst ist. Ein dauerhaft offenes Debug-Log auf einer Produktivseite ist ein Sicherheitsrisiko.

Eine typische Zeile sieht so aus:

PHP Fatal error: Uncaught Error: Call to undefined function ...
in /www/wp-content/plugins/beispiel-plugin/includes/klasse.php:214

Damit ist der Fall im Grunde geklärt.

Schritt 4: Plugins gesammelt deaktivieren

Wenn Sie nicht mehr ins Backend kommen und das Protokoll nichts hergibt, hilft der Holzhammer — der aber nichts zerstört:

Benennen Sie per FTP oder im Dateimanager des Hosters den Ordner wp-content/plugins in plugins-alt um. Damit sind sämtliche Plugins deaktiviert. Ihre Einstellungen und Inhalte bleiben erhalten, weil die in der Datenbank liegen.

• Die Seite lädt wieder? Dann liegt es an einem Plugin. Benennen Sie den Ordner zurück, gehen Sie ins Backend und aktivieren Sie die Plugins einzeln — nach jedem Schritt die Seite neu laden. Der Übeltäter ist der, nach dem es wieder bricht.
• Die Seite bleibt weiß? Dann liegt es am Theme oder an WordPress selbst. Benennen Sie testweise den Ordner Ihres aktiven Themes um; WordPress fällt dann auf ein Standard-Theme zurück.

Schritt 5: Die üblichen Verdächtigen

Bleibt es unklar, prüfen Sie diese vier Punkte:

PHP-Version. Läuft die Seite auf einer Version, die der Hoster gerade umgestellt hat? Eine Rückstellung ist als Notbehelf möglich, aber keine Lösung: Alte PHP-Versionen bekommen keine Sicherheitsupdates mehr. Der richtige Weg ist, die nicht mehr lauffähige Erweiterung zu ersetzen.

Speichergrenze. Besonders bei Page-Buildern wie Elementor, Divi oder WPBakery reicht der Standardwert oft nicht. In der wp-config.php lässt sich das anheben:

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

Setzt der Server ein niedrigeres Limit, greift diese Zeile nicht — dann muss der Hoster ran.

Beschädigte Kerndateien. Ein abgebrochenes Update kann die WordPress-Dateien unvollständig hinterlassen. Abhilfe: die passende WordPress-Version herunterladen und die Ordner wp-admin und wp-includes per FTP überschreiben. wp-content und wp-config.php bleiben unangetastet.

Ein Schnipsel in der functions.php. Codeschnipsel aus dem Netz landen oft direkt im Theme. Nach einem Theme-Update sind sie entweder weg oder kollidieren mit neuem Code. Solche Anpassungen gehören in ein Child-Theme oder ein Code-Snippet-Plugin.

Was Sie nicht tun sollten

• Kein Backup einspielen, solange die Ursache unklar ist. Sie überschreiben damit Spuren und möglicherweise neuere Inhalte.
• Keine Plugins löschen. Deaktivieren reicht und ist umkehrbar — Löschen nimmt in vielen Fällen die Einstellungen mit.
• Nicht wahllos Codeschnipsel einfügen, die in Foren empfohlen werden. Ohne bekannte Ursache verschieben sie das Problem nur.
• Die Seite nicht kaputt online lassen, wenn es länger dauert. Eine schlichte Wartungsseite ist für Besucher und für Google besser als eine Fehlermeldung.

Wenn es ein Angriff ist, gelten andere Regeln

Ein Defekt und ein Hack sehen im ersten Moment ähnlich aus, brauchen aber entgegengesetzte Schritte. Für einen Angriff sprechen: Weiterleitungen auf fremde Seiten, unbekannte Benutzerkonten, fremde Dateien im Webspace, Werbung, die Sie nie eingebaut haben, oder eine Warnung in der Google Search Console.

In dem Fall gilt zuerst: nichts überschreiben, Passwörter von einem sauberen Gerät aus ändern und die Seite vorübergehend schließen. Die vollständige Reihenfolge steht unter Erste Hilfe, wenn die Website gehackt wurde und auf der Seite Website gehackt.

Wenn Sie nicht weiterkommen

Die Schritte oben lösen einen großen Teil der Fälle. Was übrig bleibt, sind meist Kombinationen: ein altes Theme, eine neue PHP-Version und ein Plugin, das seit Jahren kein Update mehr bekommen hat — dann greift eine Maßnahme in die nächste.

Für genau diese Fälle gibt es den WordPress-Notfall: 99 € für die Diagnose, inklusive Sicherung, Auslesen der Protokolle und Eingrenzung der Ursache. Danach bekommen Sie ein verbindliches Festpreis-Angebot für die Reparatur — kein offener Stundenzettel. Beauftragen Sie sie, werden die 99 € voll angerechnet. Läuft Ihre Seite auf einem anderen System als WordPress, ist Website-Fehler beheben die passende Seite.

Und weil fast jeder dieser Notfälle dieselbe Vorgeschichte hat — Updates, die zu lange liegen blieben, oder Sicherungen, die es nicht gab: Wer das nicht selbst im Blick behalten will, findet den laufenden Weg unter Website-Pflege.