Hafen

WordPress weißer Bildschirm: So behebst du den White Screen of Death

Statt deiner Seite siehst du nur noch weiße Leere, kein Fehlertext, kein Backend? Der WordPress White Screen of Death ist beängstigend, aber in den allermeisten Fällen in wenigen Minuten systematisch lösbar.

Du rufst deine Seite auf und siehst: nichts. Kein Fehlertext, keine Meldung, nur eine leere weiße Fläche. Auch das Backend unter /wp-admin bleibt oft genauso weiß. Willkommen beim WordPress White Screen of Death, im deutschsprachigen Raum meist schlicht „weißer Bildschirm WordPress" genannt. Die gute Nachricht vorweg: Der WSoD ist selten ein Zeichen für einen zerstörten Datenbestand oder einen gehackten Server. Meistens steckt ein einzelner PHP-Fehler dahinter, der WordPress zum Abbruch zwingt, bevor auch nur eine Fehlermeldung ausgegeben werden kann. In diesem Beitrag gehen wir systematisch durch, wie du die Ursache findest und deine Seite wieder online bringst.

Was der White Screen of Death überhaupt ist

Technisch ist der weiße Bildschirm kein eigener Fehlertyp, sondern das sichtbare Symptom eines Fatal Error in PHP: Ein Plugin oder Theme ruft eine nicht existierende Funktion auf, überschreitet das Speicherlimit oder bricht auf andere Weise ab. Die Fehlerausgabe ist auf produktiven WordPress-Seiten standardmäßig deaktiviert, damit Besucher keine internen Serverpfade sehen. Das Problem: Ohne diese Ausgabe bricht die Seite sauber ab, zeigt dir aber auch keinen Hinweis, was schiefging. Genau deshalb wirkt der WSoD zunächst undurchsichtig, obwohl die Ursache fast immer klar benennbar ist, sobald du die Fehlerausgabe aktivierst.

Schritt 1: Ruhe bewahren und Backup-Stand prüfen

Bevor du irgendetwas änderst, ein kurzer, aber wichtiger Zwischenschritt: Prüfe, ob und wann zuletzt ein Backup deiner Seite erstellt wurde. Die meisten Hoster bieten automatische tägliche Sicherungen, viele Backup-Plugins ebenso. Ein aktuelles Backup ist dein Sicherheitsnetz und erlaubt dir, im Zweifel einfach auf den letzten funktionierenden Stand zurückzuspringen, statt stundenlang zu suchen. Existiert keines, stoße jetzt manuell eines an, sofern Hoster oder Plugin das noch zulassen, bevor du an Dateien oder der Datenbank herumschraubst.

Tipp: Notiere dir vor der ersten Änderung, was du zuletzt an der Seite gemacht hast, ein Update, ein neues Plugin, eine Theme-Anpassung. Meist liegt genau dort die Ursache.

Schritt 2: WP_DEBUG aktivieren und die debug.log lesen

Der wichtigste Handgriff überhaupt: Öffne per FTP oder Datei-Manager deines Hosters die Datei wp-config.php im WordPress-Hauptverzeichnis und suche die Zeile define('WP_DEBUG', false);. Ersetze sie durch folgenden Block, direkt oberhalb der Zeile /* That's all, stop editing! */:

  • define('WP_DEBUG', true); aktiviert den Debug-Modus grundsätzlich
  • define('WP_DEBUG_LOG', true); schreibt alle Fehler in eine Log-Datei statt sie nur anzuzeigen
  • define('WP_DEBUG_DISPLAY', false); verhindert, dass Fehler live auf der Seite für jeden Besucher sichtbar werden

Speichere die Datei, lade die Seite einmal neu und öffne anschließend die neu erzeugte Datei wp-content/debug.log. Dort steht in aller Regel exakt, welche Datei, welche Funktion und welche Zeile den Fatal Error ausgelöst hat, meist mit einem Hinweis wie „Fatal error: Uncaught Error: Call to undefined function" oder „Allowed memory size exhausted". Diese eine Zeile ist der Schlüssel zur Lösung. Setze WP_DEBUG nach erfolgreicher Fehlerbehebung wieder auf false, ein dauerhaft aktiviertes Debug-Log ist ein unnötiges Sicherheits- und Performance-Risiko.

Schritt 3: Ins Error-Log deines Hosters schauen

Kommst du per FTP oder Datei-Manager gar nicht mehr an wp-config.php heran, oder bleibt die debug.log leer, hilft der zweite Blick: das serverseitige Error-Log deines Hosters. Fast jedes Hosting-Panel, ob Plesk, cPanel oder ein individuelles Kundenmenü, bietet einen Bereich „Fehlerprotokoll" an, der PHP-Fehler unabhängig von WordPress protokolliert. Diese Quelle ist besonders wertvoll, wenn der Fehler so früh auftritt, dass WordPress die eigene Konfiguration noch nicht verarbeiten konnte. Findest du dort nichts, frag den Support deines Hosters gezielt nach den letzten PHP-Fehlereinträgen zu deiner Domain.

Schritt 4: Plugin-Konflikt isolieren

Der weit überwiegende Teil aller White-Screen-Fälle lässt sich auf ein einzelnes Plugin zurückführen, häufig direkt nach einem Update. So gehst du vor:

  • 1. Alle Plugins deaktivieren: Verbinde dich per FTP, benenne den Ordner wp-content/plugins um, etwa in plugins-off. WordPress erkennt die Plugins dadurch nicht mehr und deaktiviert sie faktisch alle auf einmal.
  • 2. Seite testen: Lädt deine Seite jetzt wieder, war ein Plugin die Ursache. Benenne den Ordner zurück in plugins, sie bleiben dabei zunächst deaktiviert.
  • 3. Einzeln reaktivieren: Aktiviere im Backend unter „Plugins" eines nach dem anderen und lade nach jedem Schritt neu. Sobald der weiße Bildschirm zurückkehrt, hast du den Übeltäter gefunden.
  • 4. Alternative per Datenbank: Kommst du auch per FTP nicht weiter, erzielst du denselben Effekt über phpMyAdmin, indem du in der Tabelle wp_options den Eintrag active_plugins auf a:0:{} setzt.

Hast du das verantwortliche Plugin identifiziert, aktualisiere es auf die neueste Version oder prüfe im Support-Forum, ob andere Nutzer denselben Fehler melden. Bleibt das Problem bestehen, ist eine schlankere Alternative meist die nachhaltigere Lösung als ein dauerhaft deaktiviertes Plugin.

Schritt 5: Theme auf ein Standard-Theme wechseln

Bringt die Plugin-Isolation keine Lösung, ist das aktive Theme dran. Auch hier hilft der Umweg über FTP oder phpMyAdmin, falls das Backend nicht erreichbar ist: Benenne den Ordner deines aktiven Themes in wp-content/themes um. WordPress fällt dann automatisch auf ein installiertes Standard-Theme wie Twenty Twenty-Four zurück. Lädt die Seite jetzt, lag der Fehler im Theme, etwa in der functions.php oder einem veralteten Child-Theme. Prüfe dann, ob ein Theme-Update vorliegt, oder wende dich an den Entwickler.

Schritt 6: PHP-Speicherlimit (Memory Limit) erhöhen

Steht in der debug.log oder im Error-Log ein Hinweis wie „Allowed memory size of X bytes exhausted", ist die Ursache klar: WordPress hat mehr Arbeitsspeicher angefordert, als ihm zugestanden wird, oft ausgelöst durch mehrere speicherhungrige Plugins gleichzeitig. Trage in der wp-config.php oberhalb der Zeile /* That's all, stop editing! */ folgende Zeile ein:

  • define('WP_MEMORY_LIMIT', '256M'); erhöht das WordPress-Speicherlimit auf 256 Megabyte

Reicht das nicht, liegt das serverseitige PHP-Limit oft niedriger als das WordPress-Limit und muss zusätzlich über die php.ini deines Hosters angehoben werden. Ein erhöhtes Memory Limit behebt allerdings nur das Symptom, nicht die Ursache: Ein Plugin, das regelmäßig an die Speichergrenze stößt, ist in aller Regel schlicht zu ressourcenhungrig programmiert.

Schritt 7: PHP-Version prüfen

Nicht selten tritt der weiße Bildschirm direkt nach einem PHP-Versionswechsel durch den Hoster auf, weil ein älteres Plugin oder Theme mit der neuen Version nicht kompatibel ist. Prüfe im Hosting-Kundenmenü, welche PHP-Version aktiv ist, und vergleiche sie mit den Mindestanforderungen deiner Plugins. Im Zweifel hilft ein testweises Zurückschalten auf die vorherige Version, um zu bestätigen, ob das tatsächlich die Ursache war.

Schritt 8: Recovery Mode und Wiederherstellungs-E-Mail nutzen

Seit WordPress 5.2 bringt der Kern eine eingebaute Rettungsleine mit: Erkennt WordPress einen Fatal Error, verschickt es automatisch eine E-Mail an die hinterlegte Administrator-Adresse mit einem Link zum Recovery Mode. Über diesen Link gelangst du ins Backend, selbst wenn die Seite für Besucher weiß bleibt, und siehst dort direkt, welches Plugin oder Theme den Fehler verursacht hat, inklusive einer Option, es testweise zu deaktivieren. Prüfe zuerst dein Postfach samt Spam-Ordner, oft ist die Lösung dort nur zwei Klicks entfernt.

Schritt 9: .htaccess zurücksetzen

Deutlich seltener, aber möglich: Eine fehlerhafte .htaccess-Datei kann ebenfalls einen weißen Bildschirm oder einen Serverfehler 500 auslösen, etwa nach einer manuellen Bearbeitung oder einem fehlgeschlagenen Plugin-Update. Benenne die Datei per FTP testweise um, etwa in htaccess-backup, und lade die Seite neu. Funktioniert sie jetzt, erzeugt WordPress unter „Einstellungen → Permalinks" automatisch eine neue, saubere Datei, sobald du dort einmal speicherst. Achte danach darauf, dass keine internen Links plötzlich ins Leere laufen. Wie du entstehende 404-Fehler findest und weiterleitest, und wie du Weiterleitungsregeln grundsätzlich einrichtest, liest du im Beitrag 301-Weiterleitungen in WordPress einrichten.

Wann du besser den Hoster einschaltest

Die meisten White-Screen-Fälle lassen sich mit den obigen Schritten selbst lösen. Es gibt aber klare Grenzen: wenn du keinerlei FTP- oder Datei-Manager-Zugriff hast, wenn das Error-Log auf einen Serverfehler statt auf PHP-Code hindeutet, wenn Speicherlimits serverseitig gesperrt sind, oder wenn du dir bei Eingriffen in die Datenbank unsicher bist. Ein guter Hoster kann dann meist innerhalb weniger Minuten ins Server-Log schauen und dir die genaue Ursache nennen, oft schneller, als selbst jede Möglichkeit durchzuprobieren.

Die eigentliche Ursache: warum der WSoD überhaupt entsteht

Bei aller Anleitung lohnt sich der Blick auf die Wurzel. In unserer Erfahrung als Plugin-Anbieter ist der häufigste Auslöser fast immer derselbe: schlecht programmierte, überladene oder veraltete Plugins und Themes, die nach einem PHP-Update inkompatibel werden oder einen Fatal Error werfen, weil interne Funktionen nicht sauber abgesichert sind. Je mehr Plugins laufen, je mehr davon Alles-Könner mit riesigem Funktionsumfang sind, und je länger eines nicht mehr aktualisiert wurde, desto höher die Wahrscheinlichkeit für den nächsten weißen Bildschirm.

Ein ehrlicher Hinweis in eigener Sache, auch wenn wir als Plugin-Anbieter nicht ganz neutral sind: Schlanke, sauber gepflegte Plugins minimieren dieses Risiko spürbar. Ein Plugin, das genau eine Aufgabe sauber löst, ist in der Regel schneller unterwegs als ein Speedboot, während ein aufgeblähtes Alles-Könner-Plugin eher wie ein Frachter jede Funktion mitschleppt, egal ob du sie brauchst. Genau nach diesem Prinzip bauen wir Linkjet, MemberJet und Adjet: kostenlose, schlanke GPLv2-Plugins, aktiv gepflegt und bewusst auf einen klaren Funktionskern beschränkt. Auch unser Theme Hafen denkt dieses Prinzip konsequent weiter und ist als kostenlose Beta zum Download verfügbar. Mehr Tipps, wie du deine Seite insgesamt schlank und stabil hältst, findest du im Beitrag WordPress langsam? So machst du deine Seite in 10 Schritten wieder schnell.

Fazit

Der WordPress White Screen of Death sieht im ersten Moment nach Totalausfall aus, ist aber fast immer ein einzelner, klar identifizierbarer Fatal Error. Aktiviere WP_DEBUG, lies debug.log oder Error-Log, isoliere Plugins und Theme systematisch, prüfe Memory Limit und PHP-Version, und nutze im Zweifel Recovery Mode und Wiederherstellungs-E-Mail. Mit diesen neun Schritten bringst du deine Seite meist selbst wieder online, und mit schlanken, gut gepflegten Plugins sorgst du dafür, dass der nächste weiße Bildschirm erst gar nicht entsteht.

Ein schlankes Fundament statt der nächsten Fehlermeldung

Linkjet, MemberJet und Adjet sind kostenlose, aktiv gepflegte GPLv2-Plugins ohne Ballast. Mit Hafen haben wir das passende Theme dazu gebaut, schnell wie ein Speedboot statt schwerfällig wie ein Frachter. Jetzt als kostenlose Beta verfügbar.

Hafen entdecken

Häufige Fragen

Was bedeutet White Screen of Death bei WordPress genau?

Der WordPress White Screen of Death bezeichnet eine leere, weiße Seite ohne jede Fehlermeldung, die entsteht, wenn ein PHP-Fatal-Error den Programmablauf abbricht, bevor eine sichtbare Ausgabe erzeugt werden konnte. Die Fehlerausgabe ist auf produktiven Seiten standardmäßig deaktiviert, damit Besucher keine internen Serverpfade sehen, weshalb der Bildschirm einfach leer bleibt statt eine Meldung zu zeigen. Meist steckt ein fehlerhaftes Plugin oder Theme dahinter, häufig nach einem Update. Aktivierst du WP_DEBUG, wird die eigentliche Ursache in der Regel sofort sichtbar.

Verliere ich beim weißen Bildschirm meine Daten oder Inhalte?

Nein, beim White Screen of Death verlierst du in aller Regel keine Daten oder Inhalte. Der WSoD betrifft nur die Darstellung der Seite, während deine Datenbank mit allen Beiträgen, Seiten und Einstellungen unberührt bleibt, denn die Ursache liegt fast immer in einem einzelnen PHP-Fatal-Error und nicht in einer zerstörten Datenbank. Trotzdem solltest du vor größeren Eingriffen wie dem Umbenennen von Plugin- oder Theme-Ordnern prüfen, ob ein aktuelles Backup existiert, oder eines erstellen. So hast du im Zweifel ein Sicherheitsnetz, falls beim Beheben doch etwas schiefgeht.

Wie komme ich ins Backend, wenn auch wp-admin weiß bleibt?

Wenn auch wp-admin weiß bleibt, kommst du trotzdem über FTP, den Datei-Manager deines Hosters oder phpMyAdmin an deine Seite heran. Darüber lassen sich Plugin- und Theme-Ordner umbenennen oder in der Datenbank der Eintrag active_plugins zurücksetzen, ganz ohne Login ins Backend. Seit WordPress 5.2 verschickt der Kern bei einem Fatal Error zudem automatisch eine Wiederherstellungs-E-Mail an die Administrator-Adresse mit einem Link zum Recovery Mode. Prüfe also zuerst dein Postfach samt Spam-Ordner, oft ist die Lösung darüber nur zwei Klicks entfernt.

Wie kann ich einen weißen Bildschirm künftig vermeiden?

Um einen weißen Bildschirm künftig zu vermeiden, halte WordPress, PHP, Theme und Plugins konsequent aktuell und teste Updates nach Möglichkeit zuerst auf einer Staging-Seite. Setze bevorzugt auf schlanke, aktiv gepflegte Plugins statt auf überladene Alles-Könner, denn je mehr Plugins laufen und je länger eines nicht aktualisiert wurde, desto höher die Wahrscheinlichkeit für einen Fatal Error. Schlanke Lösungen wie Linkjet, MemberJet oder Adjet senken dieses Risiko spürbar, weil weniger unnötiger Code überhaupt läuft. So bleibt deine Seite insgesamt stabiler, auch nach einem PHP-Versionswechsel deines Hosters.

Reicht es, WP_DEBUG dauerhaft aktiviert zu lassen?

Nein, WP_DEBUG dauerhaft aktiviert zu lassen reicht nicht und ist auch nicht empfehlenswert. WP_DEBUG_DISPLAY sollte auf produktiven Seiten immer deaktiviert bleiben, damit Besucher keine internen Fehlermeldungen und Serverpfade zu sehen bekommen. Auch WP_DEBUG_LOG solltest du nach abgeschlossener Fehlersuche wieder auf false setzen, da die debug.log sonst unnötig weiterwächst und ein Sicherheits- sowie Performance-Risiko bleibt. Aktiviere den Debug-Modus also gezielt zur Fehlersuche und schalte ihn danach wieder ab.

Zurück zum Blog Ein Beitrag von hafenstudios