Die Seite funktionierte noch vor einer Sekunde, Sie waren gerade dabei, einen Artikel fertigzustellen oder WooCommerce zu konfigurieren, und plötzlich: nichts. Ein weißer Bildschirm statt des Admin-Panels. Oder die Startseite ist verschwunden, obwohl das Dashboard noch geöffnet ist. Kommt Ihnen das bekannt vor? Willkommen im Club, Sie sind dem White Screen of Death begegnet, auch bekannt als WSOD, auch bekannt als der „weiße Bildschirm des Todes" WordPress.

Panik ist hier der erste Feind. Ein WSOD bedeutet fast nie, dass die Seite endgültig verloren ist. Meistens ist die Ursache banal: ein Plugin-Konflikt nach einem Update, fehlerhaft eingefügter Code in functions.php oder schlichtweg zu wenig Arbeitsspeicher für den PHP-Prozess. In diesem Leitfaden finden Sie vier bewährte Wege, die Seite wiederzubeleben, und einen fünften, der im WordPress-Kern integriert ist und den selbst erfahrene Nutzer oft vergessen.

💡 Kurzüberblick:

• Deaktivieren Sie das problematische Plugin per FTP (Ordner umbenennen) oder pauschal durch Umbenennen des plugins-Verzeichnisses
• Deaktivieren Sie das konfliktverursachende Theme nach derselben Methode: themes-Ordner → Verzeichnis des aktiven Themes umbenennen
• Erhöhen Sie das PHP-Speicherlimit mit der Zeile WP_MEMORY_LIMIT in wp-config.php auf 128M oder 256M
• Aktivieren Sie WP_DEBUG und WP_DEBUG_LOG zur Diagnose und erfahren Sie die genaue Fehlerursache aus der Datei debug.log
• Nutzen Sie den Wiederherstellungsmodus (WordPress 5.2+), einen integrierten Mechanismus, der Ihnen einen Link sendet, über den Sie auch bei einem schwerwiegenden Fehler auf das Admin-Panel zugreifen können
• Stellen Sie die Seite aus einem Backup wieder her, falls die anderen Methoden nicht funktioniert haben

1. Das problematische Plugin deaktivieren

Plugins sind die häufigste Ursache für einen WSOD. Sie haben gerade Ihr bevorzugtes Caching-Plugin aktualisiert, der Bildschirm wurde dunkel. Sie haben einen neuen Slider installiert, die Seite öffnet sich nicht mehr. Der Mechanismus ist einfach: Der PHP-Code des Plugins verursacht einen schwerwiegenden Fehler, und WordPress bricht das Laden der gesamten Seite ab.

Das Problem: Sie können sich nicht im Admin-Panel anmelden und auf „Deaktivieren" klicken, das Admin-Panel zeigt ebenfalls nur den weißen Bildschirm. Die Lösung: Deaktivieren Sie das Plugin direkt über das Dateisystem.

So deaktivieren Sie ein einzelnes Plugin per FTP:

• Verbinden Sie sich per FTP (FileZilla, WinSCP) oder über den Dateimanager Ihres Hostings (cPanel → Dateimanager) mit dem Server.
• Navigieren Sie zum Wurzelverzeichnis von WordPress.
• Öffnen Sie wp-content/plugins.
• Suchen Sie den Ordner des problematischen Plugins, der Name entspricht dem Titel (zum Beispiel akismet, woocommerce oder elementor).
• Benennen Sie den Ordner um: Fügen Sie einen Unterstrich oder ein Suffix hinzu, etwa _akismet oder akismet_disabled. WordPress interpretiert die Umbenennung als Abwesenheit des Plugins und deaktiviert es.

Öffnen Sie die Seite unmittelbar nach der Umbenennung in Ihrem Browser. Funktioniert sie, ist der Verursacher gefunden. Jetzt können Sie den ursprünglichen Ordnernamen wiederherstellen und das Plugin nach der Anmeldung im Admin-Panel entweder auf eine kompatible Version aktualisieren oder entfernen und eine Alternative suchen.

Pauschale Deaktivierung aller Plugins auf einmal. Wenn unklar ist, welches Plugin genau den Fehler verursacht hat, deaktivieren Sie alle auf einen Schlag. Benennen Sie den Ordner wp-content/plugins selbst in plugins_old um und erstellen Sie daneben ein neues, leeres plugins-Verzeichnis. Alle Plugins sind deaktiviert. Anschließend holen Sie sie einzeln zurück: Verschieben Sie den Plugin-Ordner von plugins_old zurück nach plugins, melden Sie sich im Admin-Panel an, aktivieren Sie es und prüfen Sie die Seite. Wiederholen Sie dies, bis Sie den Verursacher gefunden haben.

Alternative für diejenigen, die WP-CLI haben. Ein Befehl im Terminal ersetzt den umständlichen FTP-Tanz:

1
wp plugin deactivate --all

Und dann einzeln aktivieren: wp plugin activate <slug>. Schnell, sauber, ohne Dateimanager.

2. Das konfliktverursachende Theme deaktivieren

Der zweithäufigste Verursacher ist das Theme. Die Szenarien sind dieselben: Sie haben das Theme auf eine neue Hauptversion aktualisiert, ein Theme mit einer fehlerhaften functions.php installiert, oder ein Plugin kollidierte nach einem WordPress-Update mit dem aktuellen Theme.

Der Lösungsmechanismus ist nahezu identisch mit dem für Plugins:

• Melden Sie sich per FTP bei wp-content/themes an.
• Suchen Sie den Ordner des aktiven Themes (dasjenige, das derzeit auf der Seite installiert ist).
• Benennen Sie ihn um, indem Sie beispielsweise _disabled an das Ende des Namens anhängen.

WordPress findet das aktive Theme nicht und wechselt automatisch zum Standard-Theme Twenty Twenty-Five (oder Twenty Twenty-Four, abhängig von der WP-Version). Die Seite lädt mit dem Standard-Design, aber alle Ihre Inhalte bleiben erhalten. Wichtig: Löschen Sie das Standard-Theme nicht, sonst gibt es nichts, worauf gewechselt werden kann, und Sie erhalten eine weitere Runde WSOD.

Schlecht programmierte Themes und WordPress-Updates. Nach einem größeren WordPress-Release können alte Themes, die veraltete Funktionen oder Hooks verwenden, kaputtgehen. Qualitäts-Themes von verifizierten Entwicklern werden innerhalb weniger Tage nach dem Core-Release aktualisiert. Wenn Ihr Theme seit sechs Monaten oder länger nicht aktualisiert wurde, ist das ein Warnsignal: Wechseln Sie zu einem, das aktiv gepflegt wird.

Bearbeitung von functions.php und anderen Theme-Dateien. Ein Tippfehler in functions.php, eine überflüssige Klammer, ein falscher Hook-Aufruf, und die Seite ist offline. Wenn Sie Theme-Dateien unmittelbar vor dem Auftreten des WSOD bearbeitet haben, ersetzen Sie die geänderte Datei durch die Originalversion aus einem Backup oder der Theme-Distribution. Ohne Backup laden Sie das Theme erneut von der Quelle herunter und laden die saubere Datei hoch.

3. Überschreitung des PHP-Speicherlimits

Die Seite ist gewachsen, die Plugins haben sich vermehrt, der Traffic hat zugenommen, und plötzlich WSOD. Ein klassisches Symptom dafür, dass dem PHP-Prozess der Arbeitsspeicher ausgegangen ist. Besonders relevant bei günstigem Hosting, wo ein Server Hunderte von Seiten bedient und das Limit pro Kunde auf ein Minimum gekürzt ist.

WordPress empfiehlt offiziell mindestens 64 MB Arbeitsspeicher, aber diese Empfehlung stammt aus der PHP-5.6-Ära und der Zeit von fünf Plugins pro Seite. Im Jahr 2026 liegt ein realistisches Minimum für eine funktionierende Seite bei 128 MB, und für Installationen mit Elementor, WooCommerce und mehreren Dutzend Plugins bei 256 MB.

So erhöhen Sie das Speicherlimit:

Öffnen Sie die Datei wp-config.php (befindet sich im Wurzelverzeichnis der WordPress-Installation) und fügen Sie eine Zeile vor dem Kommentar /* That's all, stop editing! */ ein:

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

Wenn der Anbieter den PHP-Speicher auf Serverebene strikt begrenzt, funktioniert diese Anweisung nicht, dann gibt es nur einen Ausweg: Tarif oder Hosting wechseln. Managed-WordPress-Hosting (SiteGround, WP Engine, Kinsta) konfiguriert Limits von Haus aus angemessen, und das Speicherproblem tritt dort praktisch nie auf.

4. Diagnose durch WP_DEBUG

Manchmal sind weder Plugins noch das Theme noch der Speicher schuld, die Ursache des WSOD entzieht sich. Dann müssen Sie WordPress dazu bringen, Ihnen zu sagen, was genau schiefgelaufen ist.

WordPress verfügt seit Jahrzehnten über einen integrierten Debugger WP_DEBUG. Standardmäßig ist er deaktiviert (weißer Bildschirm statt Fehlermeldungen, die Idee ist, Besuchern keine Interna der Seite preiszugeben). Für den Administrator ist dieser Modus jedoch unbezahlbar.

Fügen Sie in wp-config.php hinzu:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Was passiert:

• WP_DEBUG aktiviert den Debug-Modus;
• WP_DEBUG_LOG schreibt Fehler in die Datei wp-content/debug.log, bequem zu lesen, ohne sie Besuchern zu zeigen;
• WP_DEBUG_DISPLAY mit dem Wert false blendet Fehler auf dem Bildschirm aus (Sie sehen einen weißen Bildschirm, aber die Logs werden geschrieben).

Öffnen Sie nach der Aktivierung die Seite, reproduzieren Sie das Problem und sehen Sie in wp-content/debug.log nach. Dort finden Sie eine Zeile mit Datei, Zeilennummer und Fehlertyp, zum Beispiel Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. Das ist die genaue Adresse des Problems.

Wichtig: Lassen Sie WP_DEBUG nach der Diagnose nicht in der Produktivumgebung aktiviert, die Logs wachsen schnell und können den Festplattenspeicher füllen.

5. Wiederherstellungsmodus, der integrierte Retter von WordPress 5.2+

Seit Version 5.2 kann WordPress selbst schwerwiegende Fehler erkennen und einen Ausweg anbieten. Der Wiederherstellungsmodus (Recovery Mode) ist eine Funktion, die viele Administratoren immer noch nicht nutzen, einfach weil sie sie nicht kennen.

So funktioniert es. Wenn PHP-Code in einem Plugin oder Theme einen schwerwiegenden Fehler verursacht, fängt WordPress ihn ab, stoppt die problematische Erweiterung und sendet eine E-Mail an die E-Mail-Adresse des Administrators. Die E-Mail enthält einen Link, der den Zugang zum Admin-Panel unter Umgehung des problematischen Codes öffnet. Sie melden sich an, sehen das abgestürzte Plugin mit dem Vermerk „verursachte Fehler", deaktivieren es, und die Seite lebt wieder. Kein FTP, keine Ordnerumbenennung.

Einschränkungen des Wiederherstellungsmodus:

• Der Link ist zeitlich begrenzt gültig (etwa einen Tag) und an eine IP-Adresse gebunden;
• Erfordert konfigurierten E-Mail-Versand von der Seite (SMTP-Plugin oder Hosting-Mail);
• Hilft nicht bei Fehlern auf Serverebene (Speichermangel, defekte .htaccess).

Und dennoch, wenn die E-Mail angekommen ist, sparen Sie sich ein Dutzend Minuten Nerven und FTP-Aktionen.

Sehen Sie sich eine kurze Anleitung zur Behebung von WSOD an, alle beschriebenen Methoden mit Live-Demonstration:

⁉️🤔 Häufig gestellte Fragen

Warum erscheint der weiße Bildschirm nur im Admin-Panel, die Seite selbst öffnet sich aber normal?

Der Fehler ist in Code lokalisiert, der nur im Bedienfeld ausgeführt wird: eine Plugin-Metabox, eine Theme-Einstellungsseite, ein benutzerdefiniertes Admin-Widget. Deaktivieren Sie kürzlich installierte Plugins nacheinander, der Verursacher ist schnell gefunden. Wenn das nicht hilft, aktivieren Sie WP_DEBUG_LOG und prüfen Sie das Log nach dem Versuch, sich im Admin-Panel anzumelden.

Weißer Bildschirm nur bei einem einzigen Beitrag oder einer Eintragsseite, was ist das?

Höchstwahrscheinlich liegt das Problem im Inhalt des spezifischen Eintrags: ein Shortcode eines nicht existierenden Plugins, fehlerhaftes HTML im Text, Konflikt mit benutzerdefinierten Feldern. Öffnen Sie den Eintrag über die Schnellbearbeitung im Admin-Panel und ändern Sie den Status vorübergehend auf „Entwurf". Lädt die Seite? Dann graben Sie im Inhalt weiter.

Kann man WSOD in Zukunft ganz vermeiden?

Vollständig ausschließen, nein, aber das Risiko zu minimieren ist realistisch. Drei Regeln: (1) Testen Sie Plugin- und Theme-Updates immer auf einer Staging-Kopie der Seite, bevor Sie sie in der Produktivumgebung einspielen; (2) Führen Sie tägliche Backups von Dateien und Datenbank durch; (3) Installieren Sie keine Plugins und Themes aus fragwürdigen Quellen, insbesondere keine gecrackten Versionen.

Der Wiederherstellungsmodus hat keine E-Mail gesendet, was tun?

Der E-Mail-Versand von einer WordPress-Seite ohne konfiguriertes SMTP-Plugin funktioniert instabil. Richten Sie SMTP (Post SMTP, FluentSMTP oder WP Mail SMTP) vorsorglich ein. Wenn die E-Mail bereits nicht angekommen ist, greifen Sie auf die FTP-Methode aus Abschnitt 1 zurück, sie funktioniert immer.

Wie lange ist der Link des Wiederherstellungsmodus gültig?

Der Link ist 24 Stunden gültig (genauer gesagt, bis das Nonce-Token abläuft). Danach müssen Sie den Fehler erneut reproduzieren, WordPress sendet die E-Mail dann erneut.

Was tun, wenn nichts geholfen hat?

Wenn die vier oben genannten Methoden und der Wiederherstellungsmodus die Seite nicht zurückgebracht haben, liegt das Problem tiefer. Möglicherweise ist die .htaccess-Datei beschädigt (benennen Sie sie um und melden Sie sich im Admin-Panel an, WordPress erstellt eine neue über „Einstellungen → Permalinks → Speichern"). Oder eine Inkompatibilität der PHP-Version: Modernes WordPress benötigt PHP 7.4+, aber der Hoster hat möglicherweise noch PHP 5.6.

Ein weiteres Diagnosewerkzeug ist das Plugin Health Check & Troubleshooting vom WordPress.org-Team. Es kann eine abgesicherte Sitzung starten: deaktiviert alle Plugins und wechselt zum Standard-Theme, aber nur für Ihren Browser (Besucher sehen die normale Seite). Damit können Sie Plugins einzeln sicher aktivieren und den Verursacher finden, ohne die Produktivumgebung zu beeinträchtigen.

Keine Zeit für Nachforschungen, aber die Seite muss jetzt sofort wieder online? Stellen Sie das Backup wieder her. Wenn kein Backup vorhanden ist, eine Lehre für die Zukunft: Tägliche automatische Backups kosten ein paar Dollar im Monat und machen sich am ersten Tag einer Katastrophe bezahlt. Praktisch jedes Hosting bietet diese Funktion im Bedienfeld an.

Und das Wichtigste: Fürchten Sie den WSOD nicht. Er ist unangenehm, aber lösbar. Jetzt haben Sie einen Schritt-für-Schritt-Handlungsalgorithmus, nicht Panik und einen leeren Bildschirm.