WordPress weißer Bildschirm (WSOD) beheben

Sie rufen Ihre Seite auf und sehen, nichts. Eine leere weiße Fläche, kein Text, keine Fehlermeldung, nicht mal ein Hinweis, worauf Sie klicken könnten. Das ist der „White Screen of Death” (WSOD), und er ist tückischer als ein klarer Fehler, weil WordPress Ihnen genau das verschweigt, was Sie brauchen: die Ursache. Die gute Nachricht: Der Fehler ist fast immer dieselbe Handvoll Dinge, und Sie bekommen die Meldung mit zwei Zeilen Code sichtbar. Dann ist es nur noch Detektivarbeit.

Soforthilfe

Bevor Sie irgendwas ändern:

1. Prüfen Sie, wo der weiße Bildschirm auftritt. Nur die Startseite (ihre-seite.de) oder auch das Backend (/wp-admin)? Diese Unterscheidung entscheidet später über Ihren Weg, also notieren Sie sie sich jetzt.
2. Holen Sie sich FTP/SFTP oder den Dateimanager Ihres Hosters. Wenn das Backend selbst weiß ist, ist das Ihr einziger Zugang zu den Dateien. Ohne ihn kommen Sie nicht weiter.
3. Sichern Sie den aktuellen Stand (Dateien + Datenbank), bevor Sie etwas umbenennen oder editieren. Ein kaputter Stand mit Backup ist besser als ein kaputter Stand ohne.

Frontend weiß oder Backend auch? Der erste Gabelpunkt

Der weiße Bildschirm hat zwei Geschmacksrichtungen, und die Ursache liegt jeweils woanders:

• Nur das Frontend ist weiß, /wp-admin lädt noch. Glück gehabt, meist steckt ein Theme oder ein Plugin dahinter, das nur im Frontend feuert. Sie können Plugins und Theme bequem über das Backend deaktivieren.
• Frontend UND Backend sind weiß. Jetzt geht alles nur noch über FTP, weil Sie kein Dashboard mehr haben. Die Ursache ist eher ein Plugin, das überall lädt, ein PHP-Fatal-Error oder ein gerissenes Speicherlimit.

Merken Sie sich diesen Befund. Er halbiert in jedem Schritt die Verdächtigen.

Debug: die versteckte Meldung sichtbar machen

Der weiße Bildschirm entsteht meist durch einen PHP-Fatal-Error, dessen Ausgabe WordPress unterdrückt. Sie machen sie sichtbar. Öffnen Sie per FTP die wp-config.php im Stammverzeichnis und suchen Sie die Zeile /* That's all, stop editing! */. Direkt darüber fügen Sie ein:

// WSOD-Debug: Fehler ins Log statt auf die Seite schreiben
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );     // Datei: wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // nichts öffentlich anzeigen

// Beim reinen Suchen dürfen Sie DISPLAY kurz auf true setzen,
// dann sehen Sie den Fehler direkt im Browser. Danach wieder false.

Laden Sie die weiße Seite jetzt neu, schreibt WordPress die genaue Zeile in wp-content/debug.log: Datei, Zeilennummer, Fehlertyp. Das ist der Abkürzer schlechthin: Statt blind Plugins zu deaktivieren, lesen Sie direkt, welche Datei sich beschwert. Eine Meldung wie PHP Fatal error: ... in wp-content/plugins/xyz/xyz.php on line 214 sagt Ihnen auf einen Schlag, wer schuld ist.

Wichtig: Setzen Sie WP_DEBUG und WP_DEBUG_DISPLAY nach der Reparatur wieder auf false. Sonst stehen technische Fehler offen auf Ihrer Live-Seite.

PHP-Speicherlimit gerissen

Steht im debug.log etwas wie Allowed memory size of 134217728 bytes exhausted, ist Ihr Skript schlicht aus dem RAM gelaufen, ein klassischer WSOD-Auslöser bei vielen Plugins oder schweren Seiten. Heben Sie das Limit in der wp-config.php an, wieder über der „stop editing”-Zeile:

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

Lädt die Seite danach, war’s das Speicherlimit. Bleibt sie weiß und das Log meldet weiter „exhausted”, greift Ihr Wert nicht, dann deckelt der Server selbst. Dann muss Ihr Hoster das serverseitige PHP-memory_limit anheben; gegen diese Grenze kommt die wp-config.php nicht an.

Plugin-Konflikt per Ordner-Umbenennung finden

Plugins sind die häufigste WSOD-Ursache. Wenn Sie nicht ins Backend kommen, deaktivieren Sie sie per FTP auf einen Schlag:

1. Benennen Sie wp-content/plugins in wp-content/plugins-aus um.
2. Seite neu laden. Ist sie wieder da, lag’s an einem Plugin.
3. Benennen Sie den Ordner zurück und aktivieren Sie die Plugins im Backend einzeln wieder, nach jedem die Seite prüfen. Das Plugin, bei dem der weiße Bildschirm zurückkommt, ist der Schuldige.

Diese Methode ist sicher: Das Umbenennen löscht nichts, es entkoppelt WordPress nur von den Plugins. Ihre Einstellungen bleiben in der Datenbank.

Theme per Ordner-Umbenennung testen

Bleibt die Seite auch ohne Plugins weiß, ist das Theme dran. Benennen Sie unter wp-content/themes den Ordner Ihres aktiven Themes um (z. B. ihr-theme → ihr-theme-aus). WordPress findet sein gewohntes Theme nicht mehr und fällt automatisch auf ein Standard-Theme wie „Twenty Twenty-Four” zurück, vorausgesetzt, eins davon liegt noch im Ordner. Lädt die Seite jetzt, haben Sie den Übeltäter: das Theme oder eine Änderung darin.

PHP-Fatal-Error in der functions.php

Der häufigste „selbstgemachte” weiße Bildschirm: Sie (oder ein Tutorial) haben ein Snippet in die functions.php des Themes kopiert, eine fehlende Klammer, ein doppelt definierter Funktionsname, und WordPress bricht komplett ab. Das debug.log zeigt Ihnen die Zeile. Öffnen Sie wp-content/themes/ihr-theme/functions.php per FTP und nehmen Sie das zuletzt eingefügte Snippet wieder raus. Lädt die Seite, war’s das. Lektion fürs nächste Mal: PHP gehört nicht in die functions.php per Copy-Paste, sondern in ein kleines eigenes Plugin oder ein Child-Theme, dann reißt ein Fehler nicht die ganze Seite mit.

Der Wiederherstellungsmodus-Link in Ihrer Mail

Seit WordPress 5.2 gibt es einen Rettungsanker, den viele übersehen: Bei einem Fatal-Error schickt WordPress automatisch eine Mail an die Admin-Adresse unter Einstellungen → Allgemein. Betreff sinngemäß „Ihre Website hat ein technisches Problem”. Darin steckt ein Link in den Wiederherstellungsmodus, eine abgesicherte Backend-Sitzung, in der das fehlerhafte Plugin oder Theme schon pausiert ist und Ihnen WordPress sogar nennt, welches es war. Schauen Sie also zuerst ins Postfach (und in den Spam). Kommt die Mail nicht an, ist meist der Mailversand Ihres Hosters das Problem, dann bleibt der FTP-Weg von oben.

So vermeiden Sie das künftig

• Staging statt Live-Experiment. Updates und Snippets zuerst auf einer Test-Kopie ausprobieren, nie direkt auf der Seite, die Kunden sehen.
• Weniger Plugins. Jedes zusätzliche ist ein potenzieller WSOD-Auslöser. Was Sie nur einmal brauchen, fliegt wieder raus.
• PHP-Code ins Child-Theme oder Mini-Plugin, nie roh in die functions.php der Eltern-Vorlage.
• Automatische Backups plus Uptime-Monitoring, damit Sie vom Ausfall erfahren, bevor der Kunde anruft.

Oder: Schluss mit WordPress-Bränden

Seien Sie ehrlich zu sich selbst: Der weiße Bildschirm existiert nur, weil eine WordPress-Seite bei jedem Aufruf live PHP ausführt, eine Datenbank befragt und ein Dutzend Plugins zusammenspielen lässt. Ein einziger Fatal-Error in dieser Kette, und alles ist weiß. Eine mit Astro gebaute Seite hat diese Kette nicht: kein PHP, keine Plugins, keine Live-Datenbank, sondern fertiges HTML, das einfach ausgeliefert wird. Ein weißer Bildschirm durch ein Plugin-Update um 23 Uhr ist dort technisch unmöglich, weil es nichts gibt, das zur Laufzeit abstürzen könnte. webAION migriert Ihre Seite zum Festpreis von WordPress nach Astro und übernimmt Ihre Inhalte → WordPress zu Astro migrieren. Und falls Sie gerade einen anderen Fehler jagen: alle WordPress-Fehler im Überblick.

Weiterlesen: Wenn die Seite danach dauerhaft langsam oder anfällig bleibt, hilft der Ratgeber WordPress langsam und ein Blick auf Webseite ohne WordPress, was geht.