White Screen of Death: Häufigste Ursachen und Fixes

80 % aller WSOD-Fälle durch Plugins, 90 % nach Updates. Sieben Schritte – von Recovery Mode über WP_DEBUG bis Core-Reparatur – mit denen du den weißen Bildschirm in unter 30 Minuten behebst.

Deine WordPress-Seite zeigt nichts mehr an. Statt deiner Website siehst du eine weiße Seite oder die Meldung "Es ist ein kritischer Fehler auf deiner Website aufgetreten." Kein Menü, kein Footer, kein Dashboard. Dein Geschäft steht still, und jede Minute zählt.

Der White Screen of Death (WSOD) ist einer der häufigsten WordPress-Ausfälle. Die gute Nachricht: In den meisten Fällen lässt er sich in unter 30 Minuten beheben, wenn du systematisch vorgehst. Dieser Artikel zeigt dir die sieben Schritte, mit denen wir als WordPress-Reparatur-Dienstleister den WSOD bei Kunden-Websites diagnostizieren und fixen.

Warum zeigt WordPress einen weißen Bildschirm?

Der WSOD entsteht, wenn PHP während der Seitenausgabe auf einen fatalen Fehler stößt und die Ausführung abbricht. Vor WordPress 5.2 war das Ergebnis eine komplett weiße Seite ohne jede Fehlermeldung. Seit Version 5.2 gibt es den Recovery Mode, der dir zumindest eine Meldung und eine E-Mail mit Hinweisen schickt.

Die Ursachen lassen sich in vier Kategorien einteilen. Die Verteilung sieht in der Praxis so aus:

Rund 50 % der kritischen Fehler entstehen durch Plugin-Konflikte nach Updates. Ein Plugin wird aktualisiert, ist aber nicht mit deiner PHP-Version oder einem anderen Plugin kompatibel – und die gesamte Seite geht down. Besonders brisant in 2026: PHP 8.4 hat mehrere veraltete Funktionen entfernt, die ältere Plugins noch nutzen. Das Thema behandeln wir ausführlich in unserem Artikel zu WordPress-Sicherheit 2026.

Schritt 1: Recovery Mode und E-Mail prüfen

Seit WordPress 5.2 erkennt WordPress fatale PHP-Fehler automatisch und schickt eine E-Mail an die Admin-Adresse. Diese E-Mail enthält einen Recovery-Link, mit dem du dich ins Dashboard einloggen kannst, auch wenn das Frontend nicht funktioniert.

Prüfe den Posteingang der E-Mail-Adresse, die in WordPress unter Einstellungen > Allgemein > E-Mail-Adresse hinterlegt ist. Schau auch im Spam-Ordner nach. Die E-Mail enthält den Namen des Plugins oder Themes, das den Fehler ausgelöst hat, und einen temporären Login-Link.

Wenn du die E-Mail findest: Klicke den Recovery-Link, logge dich ein und deaktiviere das betroffene Plugin oder Theme. Fertig. In ca. 30 % der Fälle ist der WSOD damit behoben, ohne dass du FTP oder SSH brauchst.

Wenn keine E-Mail da ist oder der Link abgelaufen ist, geh weiter zu Schritt 2.

Schritt 2: WP_DEBUG aktivieren

Ohne Fehlermeldung tappst du im Dunkeln. WP_DEBUG sorgt dafür, dass WordPress dir sagt, was genau schiefläuft. Öffne die wp-config.php im Root-Verzeichnis deiner WordPress-Installation per FTP oder Dateimanager und suche die Zeile mit WP_DEBUG:

// In wp-config.php – vor "That's all, stop editing!"
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG_LOG schreibt alle Fehler in die Datei /wp-content/debug.log. WP_DEBUG_DISPLAY auf false verhindert, dass Fehlermeldungen auf der Live-Seite angezeigt werden – wichtig für Produktiv-Websites.

Lade die Seite neu und öffne dann /wp-content/debug.log per FTP. Dort findest du die exakte Fehlermeldung mit Dateiname und Zeilennummer. Typische Einträge sehen so aus:

PHP Fatal error: Uncaught Error: Call to undefined function
create_function() in /wp-content/plugins/old-plugin/init.php:42

Diese Meldung sagt dir: Das Plugin old-plugin nutzt create_function(), die in PHP 8.4 entfernt wurde. Jetzt weißt du, welches Plugin den Fehler verursacht und kannst gezielt handeln.

Schritt 3: Alle Plugins deaktivieren

Wenn du keinen Zugang zum Dashboard hast, deaktivierst du alle Plugins auf Dateisystem-Ebene. Dazu benennst du den Plugin-Ordner um:

Per FTP: Navigiere zu /wp-content/ und benenne den Ordner plugins in plugins_deaktiviert um. WordPress kann die Plugins nicht mehr finden und deaktiviert sie automatisch.

Per WP-CLI (wenn du SSH-Zugang hast):

# Alle Plugins auf einmal deaktivieren
wp plugin deactivate --all

# Oder nur ein bestimmtes Plugin
wp plugin deactivate woocommerce

Wenn die Seite nach dem Umbenennen wieder funktioniert, liegt das Problem bei einem Plugin. Benenne den Ordner zurück in plugins und aktiviere die Plugins einzeln im Dashboard, bis der Fehler wieder auftritt. So identifizierst du den Übeltäter.

Dieser Plugin-für-Plugin-Test dauert bei 20 Plugins ca. 10 Minuten. In unserem Artikel über die Risiken von ignorierten Updates erklären wir, warum regelmäßige Updates dieses Szenario von vornherein verhindern.

Schritt 4: Auf Standard-Theme wechseln

Wenn alle Plugins deaktiviert sind und der WSOD bleibt, ist das Theme die wahrscheinlichste Ursache. Der gleiche Trick funktioniert: Benenne den aktiven Theme-Ordner um.

Per FTP: Navigiere zu /wp-content/themes/ und benenne deinen aktiven Theme-Ordner um (z.B. flavflavor zu flavorflavor_backup). WordPress fällt automatisch auf ein Standard-Theme wie Twenty Twenty-Five zurück.

Per WP-CLI:

# Zum Standard-Theme wechseln
wp theme activate twentytwentyfive

Wenn die Seite mit dem Standard-Theme funktioniert, hat dein Theme ein Problem. Prüfe, ob ein Theme-Update verfügbar ist. Bei Custom Themes: Schau in die functions.php und das debug.log – dort steht die fehlerhafte Zeile.

Schritt 5: PHP-Speicherlimit erhöhen

WordPress setzt standardmäßig ein Speicherlimit von 128 MB. Für eine Seite mit WooCommerce, Page Builder und mehreren aktiven Plugins reicht das oft nicht. Wenn das Speicherlimit überschritten wird, bricht PHP ab – weißer Bildschirm.

Erhöhe das Limit in der wp-config.php:

// Speicherlimit für WordPress erhöhen
define( 'WP_MEMORY_LIMIT', '256M' );

// Für das Admin-Dashboard separat (optional)
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Alternativ kannst du das PHP-Limit auch in der .htaccess setzen:

# In .htaccess
php_value memory_limit 256M

Oder in der php.ini (wenn du Zugriff hast):

memory_limit = 256M

Auf Shared Hosting gibt es oft eine Obergrenze, die dein Hoster festlegt. Wenn 256 MB nicht reichen oder dein Hoster das nicht erlaubt, ist das ein Zeichen, dass du über besseres Hosting nachdenken solltest. VPS-Hosting gibt dir die volle Kontrolle über PHP-Einstellungen.

Schritt 6: Core-Dateien reparieren

In seltenen Fällen sind die WordPress-Core-Dateien selbst beschädigt – durch ein fehlgeschlagenes Auto-Update, einen Server-Absturz oder einen Hack. Wenn die Schritte 1 bis 5 nichts gebracht haben, ersetzt du die Core-Dateien manuell.

Per WP-CLI (schnellste Methode):

# Core-Dateien verifizieren
wp core verify-checksums

# Beschädigte Dateien neu herunterladen
wp core download --skip-content --force

Per FTP:

1. Lade die neueste WordPress-Version von wordpress.org herunter
2. Entpacke das Archiv lokal
3. Lade die Ordner /wp-admin/ und /wp-includes/ per FTP hoch und überschreibe die bestehenden Dateien
4. Lade die Dateien im Root-Verzeichnis hoch (wp-login.php, wp-cron.php etc.) – aber nicht wp-config.php und nicht den /wp-content/-Ordner

Der /wp-content/-Ordner enthält deine Themes, Plugins und Uploads. Den fasst du nicht an. Die wp-config.php enthält deine Datenbank-Zugangsdaten. Die bleibt, wie sie ist.

Schritt 7: PCRE-Limits und Edge Cases

In ca. 2 % der Fälle liegt der Fehler tiefer. Wenn deine Seite sehr große Seiten hat (langer Content, komplexe Shortcodes), kann das PCRE-Backtrack-Limit von PHP überschritten werden. Das lässt sich in der .htaccess oder php.ini beheben:

# In .htaccess
php_value pcre.backtrack_limit 1000000
php_value pcre.recursion_limit 500000

Weitere Edge Cases, die wir in der Praxis sehen:

Problem	Symptom	Lösung
Syntax-Fehler in functions.php	WSOD nur im Frontend	Fehler per FTP in der Datei korrigieren
Volle Festplatte	WSOD + DB-Fehler im Log	Alte Backups und Logs löschen
PHP-Version inkompatibel	WSOD nach PHP-Upgrade	PHP-Version im Hosting-Panel zurücksetzen
Beschädigte .htaccess	500-Fehler statt WSOD	.htaccess umbenennen, Permalinks neu speichern
Objekt-Cache korrupt	Sporadischer WSOD	object-cache.php in /wp-content/ löschen

WSOD verhindern: Prävention statt Feuerwehr

Der beste WSOD ist der, der gar nicht erst passiert. Vier Maßnahmen reduzieren das Risiko auf nahezu null:

1. Automatische Backups einrichten. Bevor du irgendetwas aktualisierst, brauchst du ein Backup. Tägliche automatische Backups sind Pflicht. Unser Backup-Guide zeigt dir, wie du das in 15 Minuten einrichtest.

2. Staging-Umgebung nutzen. Updates nicht auf der Live-Seite testen. Die meisten Managed-Hoster bieten One-Click-Staging an. Dort testest du Plugin- und Theme-Updates, bevor sie live gehen.

3. PHP-Version kontrollieren. PHP 8.4 ist seit Ende 2024 verfügbar. Viele Plugins hatten ein Jahr Zeit, sich anzupassen – aber nicht alle haben es getan. Prüfe vor dem PHP-Upgrade die Kompatibilität deiner Plugins. Das Tool "PHP Compatibility Checker" hilft dabei.

4. Plugin-Hygiene betreiben. 91 % aller WordPress-Schwachstellen kommen aus Plugins. Deaktiviere und lösche Plugins, die du nicht brauchst. Jedes aktive Plugin ist ein potenzieller Ausfallpunkt und eine potenzielle Sicherheitslücke.