Den White Screen of Death in WordPress beheben

Der berüchtigte White Screen of Death in WordPress ist nichts anderes als ein PHP Fatal Error bei deaktivierter Fehleranzeige: Der Code ist abgestürzt, bevor auch nur eine Zeile HTML ausgegeben wurde, und WordPress unterdrückt die Fehlermeldung, damit keine Dateipfade und Serverdetails an Besucher durchsickern.

Sie aktualisieren ein Plugin, laden die Seite neu und sehen im Frontend nur noch eine leere Seite – häufig auch im wp-admin. Keine Fehlermeldung, kein Stack Trace, nichts zum Anklicken. Die Versuchung ist groß, wahllos Komponenten zu deaktivieren, dabei existiert die Meldung längst; sie wird Ihnen nur nicht angezeigt. Jeder der folgenden Schritte funktioniert über SFTP oder einen Dateimanager des Hosters, und für Hoster, die zwar phpMyAdmin, aber keinen Dateizugriff anbieten, gibt es einen Weg über die Datenbank.

Was ist der WordPress White Screen of Death?

Eine weiße Seite bedeutet, dass PHP auf einen Fatal Error gestoßen ist, bevor die Seite gerendert werden konnte. WordPress unterdrückt den Fehlertext auf Produktivsystemen bewusst, weil er Pfade, Versionsnummern und andere Interna preisgeben kann. Die Dateien und die Datenbank der Website sind intakt; lediglich eine Komponente hat den Request zum Absturz gebracht.

Bevor Sie irgendetwas anfassen: Prüfen Sie das Postfach der Administrator-E-Mail-Adresse. Seit Version 5.2 schickt WordPress bei einem Fatal Error eine E-Mail an den Administrator, benennt darin das fehlerhafte Plugin oder Theme und enthält einen Link in den Recovery Mode – einen Zustand, in dem die defekte Komponente pausiert wird, sodass Sie das Dashboard erreichen und sie deaktivieren können. Dieser Link enthält einen geheimen Schlüssel; die Recovery-Mode-URL von Hand einzutippen verschafft Ihnen keinen Zugang. Falls die E-Mail nie ankommt (Spamfilter schlucken sie, und sie wird nur versendet, wenn der Fehler an einem geschützten Endpunkt wie wp-login.php oder im Admin-Bereich auftritt – nicht bei einer Frontend-Seite oder einem Cronjob), lesen Sie weiter.

Logging aktivieren, nicht die Anzeige

Öffnen Sie wp-config.php per SFTP oder über den Dateimanager Ihres Hosters und fügen Sie diese Zeilen oberhalb von /* That's all, stop editing! */ ein:

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

Laden Sie die defekte Seite neu und öffnen Sie anschließend das Log, üblicherweise unter wp-content/debug.log. Laut der WordPress-Dokumentation zum Debugging hat WP_DEBUG_LOG keine Wirkung, solange WP_DEBUG nicht auf true steht, und WP_DEBUG_DISPLAY ist standardmäßig true – deshalb setzt das Snippet die Konstante explizit auf false. Geben Sie Fehler auf einer Live-Website niemals direkt auf der Seite aus: Jeder Besucher würde Serverpfade und Code-Details zu sehen bekommen. Entfernen Sie alle vier Zeilen wieder, sobald die Website läuft.

Den Fehler lesen: Der Pfad benennt den Verursacher

Das Log liefert Ihnen eine Datei und eine Zeilennummer, und das Verzeichnis in diesem Pfad verrät, welche Komponente versagt hat. Ein realistischer Eintrag sieht so aus:

PHP Fatal error: Uncaught Error: Call to undefined function acme_slider_init() in /home/example/public_html/wp-content/plugins/acme-slider/includes/display.php:87

Der Pfad liegt unterhalb von wp-content/plugins/acme-slider/ – Ursache ist also das Plugin Acme Slider, und das Umbenennen dieses einen Ordners repariert die Website sofort. Als Faustregel gilt:

Nennt das Log stattdessen einen Speicherfehler, lesen Sie den nächsten Abschnitt. Nur wenn das Log leer bleibt, greifen Sie auf das schrittweise Eingrenzen zurück.

Wie behebt man einen Speicherüberlauf in WordPress?

Ein Fehler, der mit Allowed memory size of X bytes exhausted beginnt, bedeutet, dass PHP mitten im Request an seine Speichergrenze gestoßen ist. Erhöhen Sie das Limit von WordPress in der wp-config.php:

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

WordPress setzt WP_MEMORY_LIMIT standardmäßig auf 40M bei Einzelinstallationen und 64M bei Multisite und erhöht das PHP-Limit ausschließlich, senkt es also nie. Die Konstante wirkt nur bis zu der Obergrenze, die Ihr Hoster auf Serverebene durchsetzt; ändert sich mit 256M nichts, liegt die Grenze am Hosting-Tarif und nicht an der Einstellung – dann muss der Hoster sie anheben.

Wie deaktiviert man ein defektes Plugin ohne wp-admin?

Nennt das Log ein Plugin, benennen Sie ausschließlich dessen Ordner innerhalb von wp-content/plugins/ um. Ist das Log leer, grenzen Sie schrittweise ein: Benennen Sie wp-content/plugins in plugins.hold um, rufen Sie /wp-admin/plugins.php auf, damit WordPress die fehlenden Plugins als deaktiviert markiert, benennen Sie den Ordner zurück und schalten Sie die Plugins anschließend einzeln wieder ein – nach jedem Schritt die Website neu laden, bis sie erneut abstürzt. Der Preis dieses Wegs ist, dass Sie jedes Plugin von Hand wieder aktivieren müssen; dafür bleiben aber alle gespeicherten Einstellungen erhalten.

Kein Dateizugriff, aber phpMyAdmin verfügbar? Öffnen Sie die Tabelle wp_options (Ihr Präfix lautet möglicherweise nicht wp_), suchen Sie den Datensatz, bei dem option_name gleich active_plugins ist, und kopieren oder exportieren Sie den aktuellen option_value an einen sicheren Ort. Ersetzen Sie den Wert anschließend durch das serialisierte leere Array a:0:{}, was alle Plugins auf einen Schlag deaktiviert. Den gesicherten Wert können Sie später wiederherstellen, wenn Sie die ursprüngliche Liste benötigen.

Wie deaktiviert man ein defektes Theme?

Verweist das Log auf wp-content/themes/, benennen Sie ausschließlich den Ordner des aktiven Themes um, zum Beispiel mytheme in mytheme.hold. WordPress fällt auf ein mitgeliefertes Standard-Theme zurück, sofern eines installiert ist; falls nicht, installieren Sie zuerst eines über den Dateimanager. Der übliche Übeltäter ist die functions.php, und das Log hat Ihnen die genaue Zeile bereits genannt – oft eine kürzlich vorgenommene Änderung mit einem Syntaxfehler. Korrigieren Sie diese Zeile und benennen Sie den Ordner zurück.

Immer noch leer? Caches, Berechtigungen und PHP-Version

Bevor Sie irgendeinem Ergebnis trauen, leeren Sie sämtliche Caches: den Page Cache des Caching-Plugins, jeden Server-Cache und den Ihres Browsers. Eine gecachte leere Seite lässt eine reparierte Website defekt aussehen, und eine gecachte funktionierende Seite kann einen aktiven Fehler verbergen. Prüfen Sie anschließend die Dateiberechtigungen – auf Shared Hosting üblicherweise 755 für Verzeichnisse und 644 für Dateien – und kontrollieren Sie Ihre PHP-Version: WordPress empfiehlt als Basis 8.3 oder neuer. Eine Website unter 7.4 lädt zwar weiterhin, doch dieser Zweig erhält seit Jahren keine Sicherheitsupdates mehr.

Drei Fälle liegen außerhalb des Rahmens dieses Artikels: die Wiederherstellung aus einem Backup (über das Backup-Tool Ihres Hosters – beachten Sie, dass Sie alles seit dem Snapshot verlieren), beschädigte Core-Dateien (ein frisch heruntergeladenes WordPress über alles außer wp-content und wp-config.php kopieren) und Malware (folgen Sie dem Wiederherstellungsprozess Ihres Hosters für gehackte Websites).

Fazit

Eine leere WordPress-Seite ist eine unterdrückte Fehlermeldung, kein Rätsel – und der schnellste Weg zur Lösung besteht immer darin, diese Meldung zu lesen, statt drumherum zu raten. Fügen Sie jetzt die vier Debug-Zeilen in die wp-config.php ein, laden Sie die Seite einmal neu und lassen Sie sich vom Pfad in wp-content/debug.log genau sagen, welchen Ordner Sie umbenennen müssen.

FAQs

Was ist der Unterschied zwischen dem White Screen of Death und der Meldung „Es gab einen kritischen Fehler auf deiner Website“?

Seit WordPress 5.2 fängt ein eingebauter Fatal-Error-Handler die meisten PHP Fatal Errors ab und gibt statt einer leeren Seite die Meldung über den kritischen Fehler aus. Ein vollständig weißer Bildschirm bedeutet, dass PHP abgestürzt ist, bevor dieser Handler greifen konnte – typischerweise durch Speicherüberlauf oder einen Fehler sehr früh im Ladevorgang, etwa innerhalb der wp-config.php. Beide gehen auf PHP Fatal Errors zurück, und die Debugging-Schritte sind identisch.

Warum ist wp-content/debug.log leer, obwohl WP_DEBUG aktiviert ist?

Die üblichen Ursachen sind ein Fehler, der auftritt, bevor die Debug-Konstanten greifen – etwa ein Syntaxfehler in der wp-config.php selbst – oder ein wp-content-Verzeichnis, in das der Webserver nicht schreiben kann, sodass WordPress die Datei gar nicht erst anlegt. Vergewissern Sie sich, dass die Konstanten oberhalb des Stop-Editing-Kommentars stehen, und fordern Sie dann bei Ihrem Hoster das PHP-Fehlerlog auf Serverebene an, das Fatal Errors unabhängig von den WordPress-Einstellungen protokolliert.

Warum erscheint die weiße Seite auf manchen Seiten, auf anderen aber nicht?

Der Fatal Error steckt in Code, der nur bei diesen Requests ausgeführt wird. Ein Absturz in einer Theme-Template-Datei legt das Frontend lahm, während wp-admin weiterhin funktioniert, weil der Admin-Bereich keine Frontend-Templates rendert. Ein Absturz in reinem Admin-Plugin-Code bewirkt das Gegenteil. Aktivieren Sie das Debug-Logging, rufen Sie eine der defekten Seiten auf, und der Dateipfad im protokollierten Fehler identifiziert die fehlerhafte Komponente.

Ist es unbedenklich, WP_DEBUG und WP_DEBUG_LOG nach der Reparatur aktiviert zu lassen?

Nein. Das Log landet standardmäßig unter wp-content/debug.log – einem vorhersehbaren, über das Web erreichbaren Pfad, den viele Hoster nicht blockieren. Jeder, der diese URL aufruft, kann also Dateipfade, Fehlerdetails und Plugin-Interna einsehen, und die Datei wächst ohne Rotation immer weiter. Entfernen Sie die Debug-Zeilen aus der wp-config.php, sobald die Website wieder läuft, oder setzen Sie WP_DEBUG_LOG auf einen eigenen Dateipfad außerhalb des öffentlichen Web-Roots.