Zeigt Ihre WordPress-Seite einen White Screen of Death, lädt der Admin-Bereich nicht mehr oder fällt ein Plugin nach einem Update aus, führt Raten selten zum Ziel. Diese Anleitung zeigt, wie Sie den WordPress Debug-Modus aktivieren, die Logdatei debug.log finden und PHP-Fehler so auswerten, dass Sie die Ursache gezielt beheben. Sie brauchen dafür kein zusätzliches Plugin, nur Zugriff auf die Dateien Ihrer Installation.

Was ist der WordPress Debug-Modus und wozu brauchen Sie ihn?

WordPress ist in PHP geschrieben. Standardmäßig unterdrückt das System die meisten PHP-Meldungen, damit Besucher keine technischen Details sehen. Deshalb erscheint bei einem Problem oft nur eine leere weiße Seite (White Screen) statt einer aussagekräftigen Fehlermeldung. Der Debug-Modus dreht diesen Schalter um: WordPress sammelt dann alle PHP-Fehler, Warnungen und Hinweise und schreibt sie nach Wunsch in eine Protokolldatei.

Die wichtigsten Konstanten dafür sind WP_DEBUG (schaltet das Debugging grundsätzlich ein), WP_DEBUG_LOG (schreibt alle Meldungen in eine Datei) und WP_DEBUG_DISPLAY (steuert, ob Fehler zusätzlich auf der Seite ausgegeben werden). Für die Fehlersuche auf einer erreichbaren Seite eignet sich die Kombination „loggen statt anzeigen“: Sie sehen alles im Log, Ihre Besucher sehen nichts.

Welche Fehlertypen gibt es?

Fatal error – ein kritischer Fehler, der die Ausführung sofort abbricht. Das ist fast immer die Ursache für White Screens.
Warning – ein Problem, das die Seite (noch) nicht abstürzen lässt, aber auf einen Fehler hindeutet, etwa eine fehlende Datei oder veraltete Funktion.
Notice – ein Hinweis auf unsauberen Code, meist unkritisch, aber nützlich für Entwickler.
Deprecated – eine Funktion oder Schreibweise, die in kommenden PHP- oder WordPress-Versionen entfernt wird.

Voraussetzungen

Zugriff auf die Dateien Ihrer WordPress-Installation per SFTP/FTP, SSH oder den Dateimanager Ihres Hosters.
Die Datei wp-config.php im Hauptverzeichnis (Document Root) Ihrer Installation.
Ein Texteditor, der Dateien ohne BOM und mit korrekten Zeilenenden speichert (z. B. VS Code, Notepad++ oder der Editor des Hosters).
Ein aktuelles Backup von Datenbank und Dateien, bevor Sie Änderungen vornehmen.
Optional SSH-Zugang, um das Log direkt auf dem Server live mitzulesen.

Schritt 1: wp-config.php öffnen und sichern

Verbinden Sie sich per SFTP oder öffnen Sie den Dateimanager und wechseln Sie ins Hauptverzeichnis Ihrer WordPress-Installation (dort, wo wp-config.php, wp-content und wp-admin liegen).
Laden Sie die wp-config.php herunter und legen Sie eine Kopie als wp-config.php.bak an. So können Sie jederzeit zurück.
Öffnen Sie die Datei im Editor. Suchen Sie die Zeile mit dem Kommentar /* That's all, stop editing! Happy publishing. */. Alle Debug-Zeilen müssen oberhalb dieser Zeile stehen.

Verifizieren: Neben wp-config.php liegt wp-config.php.bak mit identischer Dateigröße, und die Zeile „That's all, stop editing!“ ist im Editor gefunden.

Schritt 2: WP_DEBUG, WP_DEBUG_LOG und WP_DEBUG_DISPLAY setzen

Falls bereits eine Zeile define('WP_DEBUG', false); existiert, ersetzen Sie sie komplett. Fügen Sie oberhalb von „stop editing“ folgenden Block ein:

// Debugging grundsaetzlich aktivieren
define( 'WP_DEBUG', true );

// Alle Meldungen in /wp-content/debug.log schreiben
define( 'WP_DEBUG_LOG', true );

// Fehler NICHT auf der Seite anzeigen (wichtig fuer Live-Sites)
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Optional: auch Skripte/Styles unkomprimiert laden
define( 'SCRIPT_DEBUG', true );

Wichtig: WP_DEBUG_DISPLAY muss auf false stehen und WP_DEBUG_LOG auf true, sonst werden Fehler öffentlich sichtbar. Speichern Sie die Datei und laden Sie sie zurück auf den Server.

Log an einen eigenen Pfad schreiben (optional)

Statt true können Sie WP_DEBUG_LOG auch einen Pfad geben. So liegt das Log nicht im öffentlich erreichbaren wp-content-Ordner:

define( 'WP_DEBUG_LOG', '/var/www/logs/wp-debug.log' );

Der Pfad muss absolut sein, und der Webserver-Benutzer (z. B. www-data) braucht Schreibrechte auf das Verzeichnis.

Verifizieren: Die Website lädt nach dem Hochladen weiterhin, und auf der Seite erscheinen keine PHP-Meldungen.

Schritt 3: Fehler reproduzieren und debug.log finden

Rufen Sie die Seite oder Aktion auf, die den Fehler auslöst (z. B. die Startseite, ein bestimmter Beitrag oder die Plugin-Einstellungen). Erst durch das Aufrufen schreibt PHP die Meldung ins Log.
Öffnen Sie den Ordner wp-content. Dort sollte jetzt die Datei debug.log liegen. Der vollständige Pfad lautet:

/wp-content/debug.log

Wenn die Datei nicht erscheint, hat entweder kein Fehler stattgefunden, oder der Ordner wp-content ist nicht beschreibbar. Prüfen Sie dann die Dateirechte (typisch sind 755 für Ordner und 644 für Dateien).

Verifizieren: wp-content/debug.log existiert und enthält Zeilen mit dem Zeitstempel Ihres Aufrufs.

Schritt 4: Das Log per SSH live mitlesen (empfohlen)

Mit SSH-Zugang müssen Sie die Datei nicht ständig neu herunterladen. Verfolgen Sie sie in Echtzeit, während Sie den Fehler auslösen:

# Ins WordPress-Verzeichnis wechseln
cd /var/www/html

# Log live verfolgen
tail -f wp-content/debug.log

Laden Sie im Browser die fehlerhafte Seite neu. Mit Strg + C beenden Sie die Verfolgung.

Verifizieren: Beim Neuladen erscheint im Terminal sofort eine neue Logzeile.

Schritt 5: Die Logzeilen richtig lesen und nach Fehlern suchen

Eine typische Fatal-error-Zeile sieht so aus:

[31-May-2026 09:14:52 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function my_plugin_init() in /var/www/html/wp-content/plugins/mein-plugin/mein-plugin.php:42

Die Zeile nennt vier Angaben: den Zeitpunkt, den Fehlertyp (Fatal error), die genaue Ursache (eine undefinierte Funktion) sowie die Datei und Zeilennummer – hier Zeile 42 in mein-plugin.php. Damit ist das verursachende Plugin bekannt.

Filtern Sie große Dateien gezielt nach den wichtigsten Schlüsselwörtern:

# Nur kritische Abstuerze anzeigen
grep "Fatal error" wp-content/debug.log

# Warnungen und Hinweise getrennt durchsehen
grep -E "PHP Warning|PHP Notice|Deprecated" wp-content/debug.log

# Die letzten 50 Zeilen ansehen
tail -n 50 wp-content/debug.log

Unter Windows ohne SSH nutzen Sie PowerShell für das lokal heruntergeladene Log:

# Nur Fatal errors aus dem Log filtern
Select-String -Path .\debug.log -Pattern "Fatal error"

# Letzte 50 Zeilen anzeigen
Get-Content .\debug.log -Tail 50

Arbeiten Sie Fatal errors zuerst ab, denn sie verursachen den Ausfall. Warnungen und Notices folgen danach. Oft zeigt schon die erste Fatal-error-Zeile auf das verantwortliche Plugin oder Theme.

Verifizieren: Sie haben für den ersten Fatal error Datei, Zeilennummer und das zugehörige Plugin oder Theme notiert.

Schritt 6: Die Ursache beheben

Steht in der Fehlerzeile ein Pfad unter /wp-content/plugins/..., deaktivieren Sie das genannte Plugin. Ohne Admin-Zugang benennen Sie den Plugin-Ordner per SFTP um (z. B. von mein-plugin in mein-plugin_off). WordPress deaktiviert es dann automatisch.
Zeigt der Pfad auf /wp-content/themes/..., wechseln Sie vorübergehend auf ein Standard-Theme wie Twenty Twenty-Four.
Bei einer Deprecated-Meldung prüfen Sie, ob ein Plugin- oder Theme-Update bereitsteht, das die veraltete Funktion ersetzt.
Laden Sie die Seite erneut und prüfen Sie im Log, ob die Fatal-error-Zeile verschwindet. Tritt ein neuer Fehler auf, wiederholen Sie den Vorgang.

Viele White Screens und unerklärliche Abstürze auf veraltete oder kompromittierte Erweiterungen zurückgehen. Gerade nach Sicherheitsvorfällen wie der Auth-Bypass-Lücke in Burst Statistics oder den aktiven Angriffen über den Funnel Builder hilft das Debug-Log, fehlerhaften oder eingeschleusten Code der richtigen Datei zuzuordnen.

Verifizieren: Nach dem Neuladen erscheint keine neue Fatal-error-Zeile für die betroffene Datei.

Schritt 7: Verifikation und erster Test

Rufen Sie die zuvor fehlerhafte Seite, das WP-Admin-Dashboard und eine beliebige Unterseite auf. Sie sollten wieder normal laden.
Leeren Sie das Log oder benennen Sie es um, damit nur frische Meldungen erscheinen:

# Log leeren, ohne die Datei zu loeschen
: > wp-content/debug.log

# Seite neu laden, dann pruefen ob neue Eintraege kamen
tail -n 20 wp-content/debug.log

Bleibt das Log nach dem Neuladen leer (oder enthält nur harmlose Notices), ist der Fehler behoben.

Verifizieren: tail -n 20 wp-content/debug.log zeigt nach dem Neuladen keinen Fatal error, und die Seite liefert im Browser wieder Inhalt.

Schritt 8: Debug-Modus auf der Live-Seite wieder deaktivieren

Lassen Sie WP_DEBUG auf einer produktiven Seite nicht dauerhaft aktiv. Es kann interne Pfade preisgeben, und die Logdatei kann schnell auf über 100 MB anwachsen. Setzen Sie den Wert nach der Fehlersuche zurück:

define( 'WP_DEBUG', false );

Löschen Sie anschließend die alte debug.log. Auf einer Test- oder Staging-Umgebung kann das Debugging aktiv bleiben.

Verifizieren: grep WP_DEBUG wp-config.php zeigt false, und https://ihre-domain.de/wp-content/debug.log liefert 404.

Updates und Wartung

Prüfen Sie das Debug-Log nach jedem größeren Update von WordPress-Core, Themes und Plugins kurz im Blick. Neue Deprecated-Meldungen sind ein Frühwarnsignal, dass eine Erweiterung mit der nächsten PHP- oder WordPress-Version Probleme bekommen könnte. Prüfen Sie regelmäßig die Größe von debug.log. Auf stark frequentierten Seiten kann die Datei in wenigen Stunden mehrere hundert Megabyte erreichen und den Webspace füllen. Eine einfache Wartungsmaßnahme ist, das Log per Cronjob regelmäßig zu rotieren oder zu leeren:

# Log monatlich leeren (Beispiel-Cron)
0 3 1 * * : > /var/www/html/wp-content/debug.log

Backup-Hinweis

Erstellen Sie vor jeder Änderung an wp-config.php oder vor dem Deaktivieren von Plugins ein vollständiges Backup von Datenbank und Dateien und notieren Sie den letzten fehlerfreien Stand. So setzen Sie im Zweifel in wenigen Minuten zurück.

Troubleshooting

Es entsteht keine debug.log: Der Ordner wp-content ist nicht beschreibbar. Prüfen Sie die Verzeichnisrechte und ob ein anderes Plugin WP_DEBUG_LOG überschreibt.
Fehler werden trotzdem auf der Seite angezeigt: Eine andere Stelle (Theme, mu-plugin oder php.ini) setzt display_errors auf On. Ergänzen Sie @ini_set('display_errors', 0); wie oben gezeigt.
Die Seite bleibt weiterhin weiß, das Log aber leer: Der Absturz passiert sehr früh, oft in wp-config.php selbst (Syntaxfehler). Prüfen Sie Ihre Änderungen auf fehlende Semikolons oder Klammern und nutzen Sie die .bak-Kopie.
Doppelte oder uralte Einträge: Leeren Sie das Log mit : > wp-content/debug.log, bevor Sie den Fehler erneut auslöst.
Speicherfehler (Allowed memory size exhausted): Erhöhen Sie testweise das PHP-Memory-Limit über define('WP_MEMORY_LIMIT', '256M'); in wp-config.php.

Häufige Fragen

Wo finde ich das WordPress error log?

Sobald WP_DEBUG und WP_DEBUG_LOG in wp-config.php aktiv sind, schreibt WordPress alle Meldungen in die Datei /wp-content/debug.log. Sie erreichen sie per SFTP, über den Dateimanager Ihres Hosters oder per SSH mit tail -f wp-content/debug.log.

Ist es gefährlich, den Debug-Modus auf einer Live-Seite zu aktivieren?

Nur wenn die Anzeige aktiv ist. Mit WP_DEBUG_DISPLAY auf false und WP_DEBUG_LOG auf true werden Fehler ausschließlich ins Log geschrieben und nicht öffentlich gezeigt. Schalten Sie WP_DEBUG nach der Fehlersuche trotzdem wieder aus, da die Logdatei wachsen und interne Pfade enthalten kann.

Wie behebe ich den White Screen of Death in WordPress?

Aktivieren Sie den Debug-Modus mit Logging, rufen Sie die Seite auf und suchen Sie in debug.log nach Fatal error. Deaktivieren Sie das genannte Plugin (z. B. durch Umbenennen des Ordners) oder wechseln Sie auf ein Standard-Theme (Schritt 6).

Warum wird meine debug.log so groß?

Jede Warnung und jeder Hinweis wird bei jedem Seitenaufruf protokolliert. Auf einer stark besuchten Seite kann die Datei dadurch schnell über 100 MB erreichen. Beheben Sie die häufigsten Warnungen, leeren Sie das Log regelmäßig und deaktivieren Sie den Debug-Modus nach der Fehlersuche.

Brauche ich ein Plugin für das Debugging?

Nein. Die drei Konstanten in wp-config.php reichen aus. Plugins wie Query Monitor sind eine Ergänzung für Entwickler, ersetzen aber nicht das Verständnis der debug.log.

Fazit

Drei Konstanten in der wp-config.php genügen, damit WordPress Fehler mit Datei und Zeilennummer protokolliert. Wer die debug.log nach Fatal error, Warning und Notice durchsucht, findet die Ursache der meisten White Screens und Plugin-Konflikte selbst. Schalten Sie den Debug-Modus auf produktiven Seiten danach wieder aus und begrenzen Sie die Größe der Logdatei.

Weiterlesen und Quellen

Passend zur Fehlersuche bei kompromittierten Erweiterungen finden Sie auf s-edv.com weitere WordPress-Themen, etwa die Analyse zur Auth-Bypass-Schwachstelle in Burst Statistics und den Bericht über die Skimming-Angriffe über den WordPress Funnel Builder. Weitere Anleitungen finden Sie in der Kategorie WordPress, etwa WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen.

Quellen: WordPress Developer Resources – Debugging in WordPress, WordPress.org Documentation – Debugging in WordPress.