Wenn deine WordPress-Seite plötzlich einen White Screen of Death zeigt, der Admin-Bereich nicht mehr lädt oder ein Plugin nach einem Update spinnt, ist Raten der falsche Weg. In dieser Anleitung lernst du, wie du den WordPress Debug-Modus aktivieren, die zentrale Logdatei debug.log finden und PHP-Fehler so auswerten kannst, dass du die Ursache selbst diagnostizierst und behebst. Die Anleitung richtet sich an Einsteiger und Admins, die Fehler nicht blind per Plugin-Deaktivierung suchen, sondern gezielt nachlesen wollen, was WordPress, ein Theme oder ein Plugin wirklich meldet. Du brauchst dafür kein zusätzliches Plugin, nur Zugriff auf zwei Dateien deiner Installation.

Kurzfassung: In wp-config.php setzt du WP_DEBUG und WP_DEBUG_LOG auf true und WP_DEBUG_DISPLAY auf false. Fehler landen dann in /wp-content/debug.log. Dort suchst du nach Fatal error, Warning und Notice, behebst die Ursache und schaltest den Debug-Modus auf der Live-Seite danach wieder aus.

Was ist der WordPress Debug-Modus und warum brauchst du ihn?

WordPress ist in PHP geschrieben. Standardmäßig unterdrückt das System die meisten PHP-Meldungen, damit Besucher keine technischen Details sehen. Genau deshalb bekommst du bei einem Problem oft nur eine leere weisse Seite (den berüchtigten 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 ist die Kombination "loggen statt anzeigen" ideal: Du siehst alles im Log, aber deine 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 deiner WordPress-Installation per SFTP/FTP, SSH oder den Dateimanager deines Hosters.
Die Datei wp-config.php im Hauptverzeichnis (Document Root) deiner 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 du Änderungen vornimmst.
Optional SSH-Zugang, um das Log direkt auf dem Server live mitzulesen.

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

Verbinde dich per SFTP oder öffne den Dateimanager und wechsle ins Hauptverzeichnis deiner WordPress-Installation (dort, wo wp-config.php, wp-content und wp-admin liegen).
Lade dir die wp-config.php herunter und lege eine Kopie als wp-config.php.bak an. So kannst du jederzeit zurück.
Öffne die Datei in deinem Editor. Suche die Zeile mit dem Kommentar /* That's all, stop editing! Happy publishing. */. Alle Debug-Zeilen müssen oberhalb dieser Zeile stehen.

Schritt 2: WP_DEBUG, WP_DEBUG_LOG und WP_DEBUG_DISPLAY setzen

Falls bereits eine Zeile define('WP_DEBUG', false); existiert, ersetzt du sie komplett. Füge 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 würden Fehler öffentlich sichtbar werden. Speichere die Datei und lade sie zurück auf den Server.

Log an einen eigenen Pfad schreiben (optional)

Statt true kannst du 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.

Schritt 3: Fehler reproduzieren und debug.log finden

Rufe 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.
Öffne 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üfe in dem Fall die Dateirechte (typisch sind 755 für Ordner und 644 für Dateien).

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

Wenn du SSH-Zugang hast, musst du die Datei nicht ständig neu herunterladen. Verfolge sie stattdessen in Echtzeit, während du den Fehler auslöst:

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

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

Jetzt lädst du im Browser die fehlerhafte Seite neu – und siehst die neue Meldung sofort im Terminal erscheinen. Mit Strg + C beendest du die Verfolgung wieder.

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

Diese Zeile verrät dir vier entscheidende Dinge: 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 weißt du sofort, welches Plugin schuld ist.

Statt dich durch eine große Datei zu scrollen, filterst du gezielt nach den drei 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 nutzt du die PowerShell, wenn du das Log lokal heruntergeladen hast:

# 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

Arbeite Fatal errors immer zuerst ab, denn sie verursachen den eigentlichen Ausfall. Warnungen und Notices sind danach dran. Sehr oft zeigt schon die erste Fatal-error-Zeile direkt auf das verantwortliche Plugin oder Theme.

Schritt 6: Die Ursache beheben

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

Beachte, dass viele White Screens und mysteriöse 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 dir das Debug-Log, fehlerhaften oder eingeschleusten Code schnell der richtigen Datei zuzuordnen.

Schritt 7: Verifikation und erster Test

Rufe die zuvor fehlerhafte Seite, das WP-Admin-Dashboard und eine beliebige Unterseite auf. Sie sollten wieder normal laden.
Leere das Log oder lege es zur Seite, damit du nur frische Meldungen siehst:

# 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.

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

Lass WP_DEBUG auf einer produktiven Seite niemals dauerhaft mit aktiver Anzeige laufen. Es kann interne Pfade preisgeben, und die Logdatei kann schnell auf über 100 MB anwachsen. Setze nach getaner Arbeit zurück:

define( 'WP_DEBUG', false );

Lösche anschließend die alte debug.log, damit keine veralteten Fehlermeldungen herumliegen. Auf einer reinen Test- oder Staging-Umgebung darfst du das Debugging dagegen ruhig anlassen.

Updates und Wartung

Behalte 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üfe 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 simple Wartungsmassnahme 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

Erstelle vor jeder Änderung an wp-config.php oder vor dem Deaktivieren von Plugins ein vollständiges Backup von Datenbank und Dateien. Notiere dir den Stand, der zuletzt fehlerfrei lief. So kannst du im Zweifel innerhalb von Minuten zurücksetzen, statt dich tiefer in ein kaputtes System zu graben.

Troubleshooting

Es entsteht keine debug.log: Der Ordner wp-content ist nicht beschreibbar. Prüfe 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änze @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üfe deine Änderungen auf fehlende Semikolons oder Klammern und nutze deine .bak-Kopie.
Doppelte oder uralte Einträge: Leere das Log mit : > wp-content/debug.log, bevor du den Fehler erneut auslöst.
Speicherfehler (Allowed memory size exhausted): Erhöhe 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 du WP_DEBUG und WP_DEBUG_LOG in wp-config.php aktiviert hast, schreibt WordPress alle Meldungen in die Datei /wp-content/debug.log. Du erreichst sie per SFTP, über den Dateimanager deines 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. Schalte 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?

Aktiviere den Debug-Modus mit Logging und ruf die betroffene Seite auf. Suche in debug.log nach Fatal error. Die Zeile nennt dir Datei und Plugin/Theme, das den Absturz verursacht. Deaktiviere dieses Plugin (z. B. durch Umbenennen des Ordners) oder wechsle auf ein Standard-Theme, bis die Seite wieder lädt.

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. Behebe die häufigsten Warnungen, leere das Log regelmäßig und deaktiviere den Debug-Modus, sobald du fertig bist.

Brauche ich ein Plugin für das Debugging?

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

Fazit

Mit drei Zeilen in der wp-config.php verwandelst du ein stummes WordPress in ein gesprächiges System, das dir genau sagt, wo es klemmt. Wer den WordPress Debug-Modus aktivieren und die debug.log nach Fatal error, Warning und Notice durchsuchen kann, löst die meisten White Screens und Plugin-Konflikte in wenigen Minuten selbst – ganz ohne fremde Hilfe. Wichtig bleibt nur die Disziplin, den Debug-Modus auf produktiven Seiten danach wieder auszuschalten und die Logdatei nicht ungebremst wachsen zu lassen.

Weiterlesen und Quellen

Passend zur Fehlersuche bei kompromittierten Erweiterungen findest du 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. Mehr Anleitungen rund um Server und WordPress sammeln wir in der Kategorie WordPress.

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