WordPress weißer Bildschirm (WSOD) beheben

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

Soforthilfe

Bevor du irgendwas änderst:

1. Prüf, wo der weiße Bildschirm auftritt. Nur die Startseite (deine-seite.de) oder auch das Backend (/wp-admin)? Diese Unterscheidung entscheidet später über deinen Weg — also notier sie dir jetzt.
2. Hol dir FTP/SFTP oder den Dateimanager deines Hosters. Wenn das Backend selbst weiß ist, ist das dein einziger Zugang zu den Dateien. Ohne ihn kommst du nicht weiter.
3. Sichere den aktuellen Stand (Dateien + Datenbank), bevor du etwas umbenennst oder editierst. 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. Du kannst Plugins und Theme bequem über das Backend deaktivieren.
• Frontend UND Backend sind weiß. Jetzt geht alles nur noch über FTP, weil du kein Dashboard mehr hast. Die Ursache ist eher ein Plugin, das überall lädt, ein PHP-Fatal-Error oder ein gerissenes Speicherlimit.

Merk dir 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. Du machst sie sichtbar. Öffne per FTP die wp-config.php im Stammverzeichnis und such die Zeile /* That's all, stop editing! */. Direkt darüber fügst du 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 darfst du DISPLAY kurz auf true setzen,
// dann siehst du den Fehler direkt im Browser. Danach wieder false.

Lädst du 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, liest du direkt, welche Datei sich beschwert. Eine Meldung wie PHP Fatal error: ... in wp-content/plugins/xyz/xyz.php on line 214 sagt dir auf einen Schlag, wer schuld ist.

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

PHP-Speicherlimit gerissen

Steht im debug.log etwas wie Allowed memory size of 134217728 bytes exhausted, ist dein Skript schlicht aus dem RAM gelaufen — ein klassischer WSOD-Auslöser bei vielen Plugins oder schweren Seiten. Heb 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 dein Wert nicht — dann deckelt der Server selbst. Dann muss dein 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 du nicht ins Backend kommst, deaktivierst du sie per FTP auf einen Schlag:

1. Benenne wp-content/plugins in wp-content/plugins-aus um.
2. Seite neu laden. Ist sie wieder da, lag’s an einem Plugin.
3. Benenne den Ordner zurück und aktiviere 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. Deine Einstellungen bleiben in der Datenbank.

Theme per Ordner-Umbenennung testen

Bleibt die Seite auch ohne Plugins weiß, ist das Theme dran. Benenne unter wp-content/themes den Ordner deines aktiven Themes um (z. B. dein-theme → dein-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, hast du den Übeltäter: das Theme oder eine Änderung darin.

PHP-Fatal-Error in der functions.php

Der häufigste „selbstgemachte” weiße Bildschirm: Du (oder ein Tutorial) hast 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 dir die Zeile. Öffne wp-content/themes/dein-theme/functions.php per FTP und nimm 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 deiner 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äß „Deine 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 dir WordPress sogar nennt, welches es war. Schau also zuerst ins Postfach (und in den Spam). Kommt die Mail nicht an, ist meist der Mailversand deines Hosters das Problem — dann bleibt der FTP-Weg von oben.

So vermeidest du 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 du nur einmal brauchst, 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 du vom Ausfall erfährst, bevor der Kunde anruft.

Oder: Schluss mit WordPress-Bränden

Sei ehrlich zu dir: 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 deine Seite zum Festpreis von WordPress nach Astro und übernimmt deine Inhalte → WordPress zu Astro migrieren. Und falls du gerade einen anderen Fehler jagst: alle WordPress-Fehler im Überblick.