Der WordPress White Screen of Death, erklärt

Der White Screen of Death ist ein fataler PHP-Fehler, den du nicht sehen kannst. WordPress ist mitten im Rendern auf einen nicht behebbaren Fehler gestoßen, PHP hat gestoppt, und weil die Fehleranzeige auf Produktionsservern abgeschaltet ist, kam die Seite leer zurück, statt den Grund auszugeben. Die Lösung ist fast nie Rätselraten: Aktiviere den Debug-Modus, öffne wp-content/debug.log und lies die letzte Fatal-Zeile. Sie nennt die exakte Datei — fast immer ein Plugin oder Theme — und diese eine Zeile ist die ganze Reparatur.

Warum die Seite leer bleibt

PHP hat eine Einstellung namens display_errors. Auf einer Entwicklungsmaschine ist sie meist aktiv, sodass ein fataler Fehler einen Stacktrace auf den Bildschirm ausgibt. Auf einem echten Host ist sie standardmäßig aus, denn Dateipfade und Fehler an Besucher preiszugeben ist ein Sicherheitsproblem. Wenn also etwas einen fatalen Fehler auslöst — der Aufruf einer Funktion, die es nicht mehr gibt, eine Klasse, die nicht geladen ist, ein Syntaxfehler in einem Plugin-Update — stirbt PHP und schickt nichts zurück. Dein Browser rendert ein leeres Dokument. Das ist der “White Screen”.

Seit WordPress 5.2 gibt es einen Handler für fatale Fehler (WP_Fatal_Error_Handler), der versucht, diese abzufangen. Wenn er funktioniert, bekommst du keine leere Seite, sondern “Es gab einen kritischen Fehler auf deiner Website”, plus eine E-Mail an die Admin-Adresse, die oft den eigentlichen Fehler und einen Link zum Wiederherstellungsmodus enthält. Ein wirklich leerer Bildschirm bedeutet meist, dass der Fehler ausgelöst wurde, bevor dieser Handler laufen konnte: ein Parse-/Syntaxfehler (der zur Kompilierzeit auftritt), ein defektes Must-use-Plugin oder ein Fatal in der functions.php des aktiven Themes. So oder so — die Ursache steht irgendwo geschrieben. Du musst das Schreiben nur einschalten.

So behebst du es, der Reihe nach

1. Schalte den Debug-Modus ein. Bearbeite wp-config.php über SFTP und füge das oberhalb der Zeile /* 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 );

WP_DEBUG_DISPLAY auf false hält die Fehler von der öffentlichen Seite fern, während WP_DEBUG_LOG sie in wp-content/debug.log schreibt. Lade die defekte Seite einmal neu, um einen frischen Eintrag zu erzeugen.

2. Lies den letzten Fatal. Öffne wp-content/debug.log und schau ganz unten:

tail -n 30 wp-content/debug.log

Du suchst nach einer Zeile wie dieser:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

Der Pfad nennt den Schuldigen: plugins/some-addon. Das ist deine Antwort. Wenn der Trace lang oder die Meldung kryptisch ist (Allowed memory size exhausted, Cannot redeclare, ein Klassenname, den du nicht kennst), füge sie in unseren Error-Log-Decoder ein — er entfernt das Rauschen, sagt dir, auf welches Plugin oder Theme der Pfad zeigt, und erklärt, was der konkrete Fehlertyp bedeutet.

3. Deaktiviere die genannte Komponente. Du kommst nicht an /wp-admin, also mach es über SFTP. Benenne den Ordner des betreffenden Plugins um, z. B. some-addon → some-addon.off. WordPress kann einen Ordner nicht laden, den es nicht findet, deaktiviert also das Plugin, und die Seite kommt zurück. Wenn das Log auf dein Theme zeigt, wechsle zu einem Standard-Theme, indem du den Ordner des aktiven Themes umbenennst — WordPress fällt auf ein mitgeliefertes twentytwentysomething zurück.

4. Wenn das Log nicht schreibt, ist wp-content nicht beschreibbar, oder der Fehler liegt auf Serverebene. Prüfe stattdessen das PHP-Fehlerprotokoll des Hosts:

find . -name "error_log" -newermt "-1 hour"

Gleiche Information, andere Datei. cPanel/Apache-Stacks legen oft ein error_log im Site-Root oder im fehlerhaften Verzeichnis ab.

Was du nicht tun solltest

Erhöhe nicht einfach das Speicherlimit. Der meistwiederholte Ratschlag im Netz ist, WP_MEMORY_LIMIT auf 256M oder 512M hochzusetzen. Das behebt den WSOD nur, wenn das Log tatsächlich Allowed memory size of N bytes exhausted meldet. Wenn der Fehler Call to undefined function lautet, bringt mehr Speicher nichts — du hast eine Einstellung willkürlich geändert und der Bildschirm ist immer noch weiß. Lies zuerst das Log, und erhöhe den Speicher nur, wenn Speicher das benannte Problem ist.

Leere nicht deinen Cache und nenn das eine Diagnose. Der White Screen entsteht, weil PHP auf dem Server stirbt, bevor überhaupt HTML existiert. Ein veraltetes gecachtes Asset kann kein leeres Dokument verursachen. (Ein defektes Caching-Plugin schon — aber das Log nennt es, und genau darum geht es.)

Bearbeite oder installiere den WordPress-Core nicht neu. Der Fatal liegt fast nie in wp-includes oder wp-admin; er liegt in dem Plugin oder Theme, auf das das Log zeigt. Den Core neu zu installieren ist langsam, riskant und behandelt ein Symptom, das du gar nicht bestätigt hast.

Deaktiviere nicht alle Plugins und schalte sie blind einzeln wieder ein. Bisektion funktioniert, aber sie ist der langsame Weg. Das Log nennt dir den exakten Ordner in einem Schritt. Greife zur “alles ausschalten”-Methode nur, wenn es überhaupt keinen lesbaren Fehler gibt.

Lass display_errors in der Produktion nicht an. Sobald die Seite wieder läuft, entferne die Debug-Definitionen (oder setze WP_DEBUG zurück auf false). An Besucher ausgegebene Fehler legen deine Pfade offen.

Immer noch fest?

Wenn das Log ein Plugin nennt, das Deaktivieren aber den Bildschirm nicht befreit, liegt unter dem ersten ein zweiter Fatal — schalte das Log wieder ein und lies die neue letzte Zeile; Fatals stapeln sich. Wenn die Meldung selbst die Wand ist, wirf sie in den Error-Log-Decoder und lass ihn den Fehlertyp und Dateipfad für dich übersetzen. Der White Screen bleibt nur so lange ein Rätsel, wie das Log aus ist.