WordPress White Screen of Death

Was dieser Fehler bedeutet und wie du ihn erkennst

• Das WordPress-Frontend, das Administrations-Dashboard oder beide zeigen eine vollständig leere weiße Seite ohne Fehlermeldung.
• Der Fehler kann die gesamte Website oder nur einen bestimmten Dashboard-Bildschirm, ein Template, einen Shortcode, Block oder eine URL betreffen.
• Die leere Seite kann unmittelbar nach der Installation oder Aktualisierung eines Plugins oder Themes erscheinen.
• Das Problem kann beginnen, nachdem der Hosting-Anbieter die PHP-Version der Website geändert hat.
• Betroffene Anfragen bleiben leer, bis das Plugin, Theme, Speicherproblem, Kompatibilitätsproblem oder die beschädigte Datei behoben ist, das beziehungsweise die den PHP-Fehler verursacht.

Hauptursachen nach Wahrscheinlichkeit

1. PHP-Fatalfehler in einem Plugin — die wahrscheinlichste Ursache, wenn das Problem nach der Installation oder Aktualisierung eines Plugins beginnt oder nur pluginbezogene Seiten ausfallen.
2. Fehler im aktiven Theme — ein Problem im Theme oder in dessen functions.php kann viele Seiten oder die gesamte Website betreffen.
3. Erschöpfter PHP-Speicher — eine Anfrage kann das konfigurierte memory_limit überschreiten; im Log erscheint häufig Allowed memory size exhausted.
4. Inkompatible PHP-Version — ein Plugin oder Theme kann Code enthalten, der mit der aktuell vom Hoster verwendeten PHP-Version nicht funktioniert.
5. Beschädigte WordPress-Core-Dateien — ein unterbrochenes oder unvollständiges Update kann Core-Dateien beschädigen. Das ist jedoch weniger wahrscheinlich, wenn der Fehler eindeutig nach einer Änderung an einem Plugin oder Theme auftritt.

So behebst du den Fehler

1. Website schützen und die fehlgeschlagene Anfrage ermitteln

Wenn Ihre Hosting-Tools Backups bereitstellen, erstellen Sie vor dem Bearbeiten von Dateien ein Backup. Notieren Sie, ob die leere Seite das Frontend, das Dashboard oder nur eine bestimmte URL betrifft. Sie benötigen Zugriff auf SFTP oder den Dateimanager des Hosting-Panels sowie die Berechtigung, wp-config.php zu bearbeiten.

2. Debugging-Logging aktivieren, ohne Fehler für Besucher sichtbar zu machen

Öffnen Sie wp-config.php und fügen Sie die folgenden Einstellungen hinzu oder aktualisieren Sie sie, sodass jede Konstante nur einmal vorkommt:

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

Lassen Sie WP_DEBUG_DISPLAY auf einer Live-Website auf false gesetzt. Laden Sie die URL, die den White Screen zeigt, exakt neu und prüfen Sie anschließend wp-content/debug.log. Suchen Sie nach dem Fatalfehler, dem Dateipfad und der Zeilennummer. Wenn das WordPress-Log nicht erstellt wird oder das Ereignis nicht enthält, bitten Sie den Hoster, das PHP-Fehlerprotokoll des Accounts zu prüfen.

3. Das im Log identifizierte Plugin deaktivieren

Wenn der Fehler ein Plugin nennt, öffnen Sie per SFTP oder über den Dateimanager des Hostings den Ordner wp-content/plugins/. Benennen Sie den betreffenden Plugin-Ordner um, indem Sie beispielsweise das Suffix -disabled hinzufügen. Durch das Umbenennen wird verhindert, dass WordPress das Plugin lädt, während dessen Dateien und Einstellungen erhalten bleiben.

Laden Sie die fehlerhafte URL neu. Wenn sie funktioniert, ist das Plugin die unmittelbare Ursache. Prüfen Sie, ob ein kompatibles Update verfügbar ist, oder wenden Sie sich an den Plugin-Entwickler, wenn kein geeignetes Update existiert, das zu den WordPress- und PHP-Versionen der Website passt. Lassen Sie ein inkompatibles oder veraltetes Plugin nicht aktiv, nur weil das Umbenennen seines Ordners die Website wiederhergestellt hat.

4. Das aktive Theme testen

Wenn das Log auf das aktive Theme verweist oder das Deaktivieren des identifizierten Plugins nicht hilft, benennen Sie den Ordner dieses Themes in wp-content/themes/ um. WordPress sollte auf ein verfügbares Standard-Theme zurückgreifen.

Wenn die Website wieder funktioniert, prüfen Sie die im Log angegebene Datei und Zeile, insbesondere functions.php. Wenn kein nutzbares Ersatz-Theme installiert ist, stellen Sie den ursprünglichen Ordnernamen nach dem Test wieder her und wenden Sie sich an den Theme-Anbieter oder Hoster, bevor Sie weitere Änderungen vornehmen.

5. Einen Fehler wegen erschöpften Speichers beheben

Wenn das Log Allowed memory size exhausted meldet, hat die fehlgeschlagene Anfrage das konfigurierte PHP-Speicherlimit überschritten. Befolgen Sie die Hosting- oder WordPress-Administrationsanleitung der Website, um das Limit sicher zu erhöhen, und untersuchen Sie, ob ein Plugin, Theme oder eine bestimmte Anfrage übermäßig viel Speicher verbraucht.

Laden Sie nach einer autorisierten Konfigurationsänderung dieselbe URL neu und bestätigen Sie, dass der identische Fatalfehler nicht mehr protokolliert wird. Eine Erhöhung des Limits kann lediglich eine ineffiziente oder inkompatible Komponente verdecken. Untersuchen Sie die Ursache daher weiter, wenn der Fehler erneut auftritt.

6. Kompatibilität der PHP-Version prüfen

Wenn der White Screen nach einer Änderung der PHP-Version begonnen hat, vergleichen Sie den Zeitpunkt mit dem im Log genannten Plugin oder Theme. Das vorübergehende Deaktivieren dieser Erweiterung kann helfen, den Zusammenhang zu bestätigen.

Fragen Sie den Hoster, ob vorübergehend ein Rollback auf eine frühere PHP-Version möglich ist, während das Plugin oder Theme aktualisiert, ersetzt oder korrigiert wird. Betrachten Sie ein Rollback als Diagnose- oder Übergangsmaßnahme, nicht als dauerhafte Kompatibilitätslösung.

7. Core-Dateien nur wiederherstellen, wenn die Hinweise dafür sprechen

Wenn kein Plugin, Theme, keine PHP- oder Speicheränderung den Fehler erklärt und das Log keine Erweiterung identifiziert, kommen beschädigte WordPress-Core-Dateien als Ursache infrage. Laden Sie passende WordPress-Core-Dateien aus einem frischen offiziellen WordPress-Download per SFTP erneut hoch.

Überschreiben Sie nicht wp-content oder wp-config.php. Wenn Sie Core-Dateien nicht zuverlässig von Website-Inhalten und Konfiguration unterscheiden können, brechen Sie ab und bitten Sie den Hoster oder einen WordPress-Fachmann um Hilfe.

8. Wiederherstellung überprüfen und aufräumen

Laden Sie die exakt betroffene Frontend-URL oder den zuvor leeren Administrationsbildschirm neu. Testen Sie verwandte Seiten, die dasselbe Plugin, Theme, denselben Shortcode oder Block verwenden. Prüfen Sie wp-content/debug.log und bestätigen Sie, dass derselbe Fatalfehler nicht erneut auftritt.

Sobald die Ursache bestätigt ist, deaktivieren Sie vorübergehende Debugging-Änderungen oder stellen Sie sicher, dass jedes weiterhin vorhandene Log vor öffentlichem Zugriff geschützt ist.

Vorbeugung und Überprüfung der Lösung

• Sichern Sie die Website, bevor Sie WordPress, Plugins, Themes oder die PHP-Version des Hostings aktualisieren.
• Aktualisieren Sie Plugins und Themes einzeln, damit die mit einem Fehler verbundene Änderung identifizierbar bleibt.
• Testen Sie größere Änderungen an WordPress, PHP, Themes und Plugins zunächst auf einer Staging-Kopie, bevor Sie sie in der Produktion anwenden.
• Lassen Sie WP_DEBUG_DISPLAY auf Live-Websites deaktiviert und beschränken Sie den Zugriff auf jedes Debug-Log.
• Überwachen Sie den verfügbaren PHP-Speicher und untersuchen Sie Komponenten, die sich wiederholt dem konfigurierten Limit nähern.
• Laden Sie nach jeder Behebung die exakt fehlerhafte URL neu und prüfen Sie das Log auf ein erneutes Auftreten desselben Fatalfehlers.

Häufig gestellte Fragen