WordPress zeigt eine weiße Seite: Ursachen und Lösung

Eine weiße Seite ist keine Fehlermeldung, sondern das Fehlen einer. Der Browser hat eine Antwort bekommen, in der nichts steht. Früher war das der normale Zustand nach einem PHP-Fehler, der „White Screen of Death“. Seit WordPress 5.2 fängt WordPress fatale Fehler ab (wp-includes/error-protection.php, Klasse WP_Fatal_Error_Handler) und zeigt stattdessen „Es gab einen kritischen Fehler auf deiner Website“, bei Bedarf mit einer Wiederherstellungs-Mail an den Administrator. Wer heute eine wirklich weiße Seite sieht, hat deshalb eine der wenigen Ursachen, bei denen dieser Schutz nicht greifen kann. Die Reihenfolge ist: erst messen, was der Server antwortet, dann lesen, was PHP geschrieben hat, dann abschalten.

Die Meldung „kritischer Fehler“ ist ein anderer Fall. Für sie gibt es den Beitrag Kritischer Fehler in WordPress beheben mit Wiederherstellungs-Mail und debug.log. Vieles davon gilt auch hier, aber die weiße Seite hat ihre eigenen Ursachen, und bei ihr gibt es keine Mail.

Erst den HTTP-Status prüfen#

Bevor du irgendetwas änderst, eine Zeile im Terminal, oder der Reiter „Netzwerk“ in den Entwicklerwerkzeugen des Browsers:

curl -sI https://deine-domain.at/ | head -1

Die Antwort sortiert den Fehler ein:

• 500 und leer: PHP ist abgebrochen, und niemand hat eine Fehlerseite ausgegeben. Der Fehler steht in einem Protokoll. Manche Browser zeigen bei einer leeren 500-Antwort eine eigene Fehlerseite, andere nur Weiß.
• 200 und leer (content-length: 0 oder ein paar Bytes): PHP ist durchgelaufen, hat aber nichts erzeugt. Cache, leere Vorlagendatei, oder ein Plugin, das die Ausgabe abbricht.
• 503: Wartungsmodus. Meist liegt eine Datei .maintenance von einem abgebrochenen Update im Hauptverzeichnis; wie man die loswird, steht in WordPress-Wartungsmodus.
• 502 oder 504: Der Webserver hat PHP nicht erreicht oder nicht rechtzeitig. Das ist eine Sache des Hosters, die Seite selbst ist meist nicht schuld.

Dazu drei Kontrollfragen. Ist /wp-admin/ auch weiß? Lädt eine statische Datei wie /wp-includes/js/jquery/jquery.min.js mit 200? Dann steht der Webserver, und nur PHP oder WordPress hängt. Und: Sehen andere die weiße Seite auch, oder nur du? Ein privates Fenster oder das Handy im Mobilfunknetz beantwortet das.

Warum der Fehlerschutz nicht greift#

WordPress registriert seinen Fehlerschutz in wp-settings.php, kurz nach dem Laden der Grundfunktionen und vor der Datenbankverbindung, den Drop-ins, den Plugins und dem Theme. Alles, was danach kaputtgeht, wird abgefangen. Übrig bleiben vier Fälle:

1. Der Fehler sitzt in der wp-config.php. Die wp-config.php wird gelesen, bevor wp-settings.php überhaupt dran ist. Ein Syntaxfehler dort, ein fehlendes Anführungszeichen, ein fehlendes Semikolon, typografische Anführungszeichen aus einem Text- oder Webeditor statt ' und ", bricht PHP ab, bevor der Schutz existiert. Das passiert fast immer nach einer Handänderung: Konstante eingefügt, Zeile aus einer Anleitung kopiert, Datei im falschen Programm gespeichert. Mit SSH prüft php -l wp-config.php die Syntax, ohne die Datei auszuführen.

2. Der Fehlerschutz ist abgeschaltet. Die Konstante WP_DISABLE_FATAL_ERROR_HANDLER in der wp-config.php schaltet ihn ab, ebenso der Filter wp_fatal_error_handler_enabled. Und wer ein Drop-in wp-content/php-error.php hat, ersetzt damit die Standard-Fehlerseite; ist diese Datei leer oder selbst fehlerhaft, bleibt die Seite weiß. Beides kommt vor, weil ein Plugin oder ein Hoster es einmal so eingerichtet hat.

3. PHP wurde hart beendet. Der Fehlerschutz ist eine Abschlussfunktion von PHP. Beendet der Webserver oder das Betriebssystem den PHP-Prozess, weil ein Zeitlimit des Hosters greift oder dem Server der Speicher ausgeht, läuft keine Abschlussfunktion mehr. Dann gibt es 500, 502 oder 504 ohne Inhalt, und im Protokoll des Hosters steht, wer den Prozess beendet hat.

4. Die Antwort ist leer, aber korrekt. Status 200, kein Inhalt. Ein Seitencache (Plugin, Hoster, CDN) hat eine leere Antwort gespeichert und liefert sie jetzt allen aus. Eine Vorlagendatei des Themes ist leer, weil ein SFTP-Upload abgebrochen ist. Oder ein Plugin für Wartungsseiten oder Weiterleitungen beendet die Ausgabe mit exit, bevor es etwas geschrieben hat.

Das Memory-Limit gehört nur bedingt hierher: Allowed memory size of … bytes exhausted ist ein normaler fataler Fehler, den der Schutz abfängt und als kritischen Fehler zeigt. Erhöhen hilft trotzdem oft, und wie die Konstanten WP_MEMORY_LIMIT und WP_MAX_MEMORY_LIMIT zusammenspielen, steht in WordPress und die PHP-Version.

Das Fehlerprotokoll lesen#

In der wp-config.php, oberhalb der Zeile /* That's all, stop editing! Happy publishing. */:

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

Seite neu laden, dann wp-content/debug.log öffnen. Die letzte Zeile mit PHP Fatal error oder PHP Parse error nennt Datei und Zeile, und damit das Plugin oder Theme. Mit WP-CLI geht dasselbe ohne Editor: wp config set WP_DEBUG true --raw und wp config set WP_DEBUG_LOG true --raw. Laut WordPress-Dokumentation ist der Debug-Modus nichts für Live-Seiten; also einschalten, lesen, ausschalten, und die debug.log danach löschen, weil sie Pfade und Versionen verrät.

Sitzt der Fehler in der wp-config.php selbst (Fall 1), kommt WordPress nie bis zu dieser Einstellung. Dann hilft nur das Fehlerprotokoll des Hosters, das im Kundenmenü meist „Error-Log“ oder „PHP-Fehlerprotokoll“ heißt. Dort steht etwa PHP Parse error: syntax error, unexpected … in /…/wp-config.php on line 23. Dass PHP solche Fehler standardmäßig nicht auf die Seite schreibt, ist gewollt: Die mitgelieferte php.ini-production setzt display_errors auf Off, und die PHP-Dokumentation nennt das Anzeigen von Fehlern eine Entwicklungsfunktion, die auf Produktionssystemen nichts verloren hat.

Den Verursacher abschalten#

Das Protokoll nennt einen Pfad. Was darin steht, bestimmt den Griff:

• wp-config.php: Zeile ansehen, mit der wp-config-sample.php aus dem WordPress-Paket vergleichen, Anführungszeichen und Semikolon prüfen. Eine Sicherungskopie davon gehört vor jede Handänderung.
• wp-content/plugins/name/…: Den Ordner per SFTP umbenennen, etwa in name-aus. WordPress nimmt ein Plugin, dessen Hauptdatei fehlt, beim nächsten Aufruf aus der Liste der aktiven Plugins. Alle auf einmal: den ganzen Ordner plugins in plugins_old umbenennen, so beschreibt es die WordPress-Dokumentation, danach zurück und einzeln wieder aktivieren. Mit WP-CLI: wp plugin deactivate --all --skip-plugins --skip-themes; die beiden Schalter verhindern, dass das kaputte Plugin beim Ausführen des Befehls selbst geladen wird.
• wp-content/themes/name/…: Ein Standard-Theme wie Twenty Twenty-Five aktivieren, per wp theme activate twentytwentyfive oder indem du den Ordner des aktiven Themes umbenennst; fehlt das aktive Theme, fällt WordPress auf das Standard-Theme zurück, sofern es installiert ist.
• wp-content/advanced-cache.php oder object-cache.php: Drop-ins von Cache-Plugins. Umbenennen, WP_CACHE in der wp-config.php auf false, neu laden. Bleibt die Seite danach mit Status 200 leer, den Cache des Plugins, des Hosters und des CDN leeren.
• Kein Protokolleintrag, Status 200, leer: Leere Dateien suchen. Mit SSH: find wp-content/themes/dein-theme -name '*.php' -size 0. Ohne SSH: Dateigrößen im SFTP-Programm mit einer frischen Kopie des Themes vergleichen.

Nach jedem Schritt neu laden, und zwar ohne Cache: privates Fenster oder curl.

Was die weiße Seite für Google bedeutet#

Bei Status 500 drosselt Google das Crawling und wartet; erst wer dauerhaft Serverfehler liefert, wird aus dem Index entfernt. Eine leere Seite mit Status 200 ist schlimmer: Google wertet sie als „Soft 404“, als Seite, die es nicht mehr gibt, und die Search Console meldet genau das. Wer die Ursache nicht am selben Tag findet, sollte dem Server eine ehrliche Antwort geben: einen Wartungsmodus mit Status 503 und Retry-After, wie in WordPress-Wartungsmodus beschrieben, statt einer leeren 200.

Nur das Backend weiß, oder nur die Website#

Ist nur /wp-admin/ weiß, liegt es fast immer an einem Plugin, das nur im Backend Code lädt, oder am Speicher: Das Backend lädt mehr als die Website. Ist nur die Website weiß und das Backend in Ordnung, ist das Theme der erste Verdächtige, denn das Backend benutzt keine Theme-Vorlagen, oder ein Seitencache, denn der greift im Backend nicht. Beides lässt sich mit dem Standard-Theme und einem geleerten Cache in zwei Minuten trennen.

Was nicht hilft#

WordPress neu hochladen. Nur, wenn das Protokoll eine Datei in wp-includes/ oder wp-admin/ nennt. Sonst bleibt der Fehler, wo er ist.

Warten. Ein Cache läuft irgendwann ab, der Fehler dahinter nicht.

display_errors auf der Live-Seite einschalten. Dann steht der Fehler samt Pfad für jeden Besucher auf der Seite. Das Protokoll sagt dasselbe, nur dir.

Die PHP-Version zurückdrehen, ohne das Protokoll gelesen zu haben. Wenn ein Plugin mit der neuen PHP-Version nicht läuft, ist das Plugin fällig, nicht die Version. Was das für die Sicherheit heißt, steht in WordPress und die PHP-Version.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. „Weiße Seite oder Fehler 500“ steht ganz oben auf der Liste der Fälle für die WordPress-Soforthilfe: Fehlerdiagnose und Reparatur für 149 €, ohne Stundenzähler. Danach hält die WordPress-Wartung für 49 € im Monat Updates, Backups und die Überwachung am Laufen, damit eine weiße Seite auffällt, bevor ein Kunde anruft.

Häufige Fragen#

Stand 13.10.2026. WordPress-Quelltext (wp-settings.php, error-protection.php, class-wp-fatal-error-handler.php), WordPress-Dokumentation, PHP-Handbuch und die Ankündigung zu WordPress 5.2 an diesem Tag gelesen.