WordPress debug.log aktivieren und lesen

Die meisten WordPress-Probleme haben eine Ursache und die steht meistens schon irgendwo aufgeschrieben, in einer Textdatei auf deinem Server, die kaum jemand kennt. Sie heißt debug.log. Wegen dieser Datei brauche ich bei Kundenseiten selten länger als zwei Minuten, um zu wissen, wo ein Fehler herkommt, während andere noch auf Verdacht Plugins abschalten.

Wie man sie einschaltet, lässt sich schnell googeln. Wie man versteht, was drinsteht, erklärt auf Deutsch kaum jemand. Beides kommt hier.

Was WP_DEBUG ist

WordPress hat einen eingebauten Debug-Modus, der standardmäßig aus ist. Das ist richtig so, auf einer Live-Seite willst du keine PHP-Fehlermeldungen öffentlich zeigen. Wenn du aber einem Problem nachgehst, ist er dein schärfstes Werkzeug.

Gesteuert wird er über drei Konstanten in der wp-config.php. Die meisten Anleitungen erklären nur die erste und wundern sich dann, warum die Protokolldatei leer bleibt.

WP_DEBUG schaltet den Debug-Modus ein. Ohne diese Konstante tun die anderen beiden nichts.

WP_DEBUG_LOG schreibt alle Fehler still in eine Datei, statt sie anzuzeigen. Das ist der Teil, der zählt.

WP_DEBUG_DISPLAY steuert, ob Fehler auf der Seite sichtbar sind. Auf einer Live-Seite steht das immer auf false.

Schritt 1: wp-config.php öffnen

Die wp-config.php liegt im Stammverzeichnis deiner Installation, je nach Hoster unter /public_html/ oder /www/. Du kommst per SFTP dran (FileZilla oder ein anderer Client) oder über den Dateimanager deines Hosters.

Bevor du etwas änderst, mach eine Kopie der Datei. Ein Tippfehler in der wp-config.php und die ganze Seite ist weg. Das passiert regelmäßig. Dupliziere die Datei und nenne die Kopie wp-config.php.bak, dann arbeitest du im Original weiter.

Schritt 2: Debug-Logging einschalten

Such in der Datei nach dieser Zeile:

/* That's all, stop editing! Happy blogging. */

Füg direkt oberhalb davon diese drei Zeilen ein:

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

Speichern, hochladen, fertig. Ab jetzt schreibt WordPress alle Fehler ins Protokoll, ohne sie auf der Seite zu zeigen.

Steht in deiner wp-config.php schon eine Zeile mit define( 'WP_DEBUG', false ), ersetz dort false durch true und ergänze die beiden anderen Zeilen darunter.

Schritt 3: Die debug.log finden

Die Datei liegt unter:

/wp-content/debug.log

Per SFTP oder Dateimanager herunterladen und mit einem Texteditor öffnen. Notepad++, VS Code oder der Windows-Editor reichen, es ist eine einfache Textdatei.

Ein Haken: Die Datei entsteht erst, wenn ein Fehler aufgetreten ist. Findest du sie nicht, ruf einmal die Seite auf, die den Fehler zeigt. Dann wird sie angelegt.

Schritt 4: Das Protokoll lesen

Diesen Teil lassen die meisten Artikel weg, dabei ist er der wichtigste. Ein typischer Eintrag sieht so aus:

[29-Mar-2026 10:15:42 UTC] PHP Fatal error: Uncaught Error: Call to undefined function some_plugin_function() in /wp-content/plugins/mein-plugin/mein-plugin.php on line 123

Der Eintrag hat drei Teile und jeder sagt dir etwas.

PHP Fatal error ist die Schwere. Ein Fatal Error stoppt die Ausführung sofort, das ist der Grund für den weißen Bildschirm oder den 500er.

Call to undefined function some_plugin_function() ist die Meldung. Hier ruft ein Plugin eine Funktion auf, die es nicht gibt, meistens weil ein anderes Plugin oder der Kern sie nach einem Update nicht mehr bereitstellt. Das ist ein klassischer Konflikt.

/wp-content/plugins/mein-plugin/mein-plugin.php on line 123 ist der Ort. Dateiname und Zeile stehen da, damit kennst du das verantwortliche Plugin.

Die vier Fehlerstufen

Ein Fatal Error heißt: Seite down, Ausführung gestoppt, sofort handeln.

Eine Warning heißt: Die Seite läuft noch, aber etwas stimmt nicht. Oft ist das der Vorbote eines Fatal Errors nach dem nächsten Update, also nicht ignorieren.

Eine Notice ist rein informativ, meistens schlampig geschriebener Plugin-Code. Solange keine Warnings oder Errors dabei sind, kannst du sie ignorieren.

Deprecated heißt: Eine Funktion wird benutzt, die aus künftigen PHP-Versionen verschwindet. Heute kein Problem, in sechs Monaten vielleicht schon. Entwickler anschreiben oder nach einer Alternative schauen.

Ein zweites Beispiel: headers already sent

Einer der häufigsten Einträge, die ich sehe:

[29-Mar-2026 10:20:11 UTC] PHP Warning: Cannot modify header information - headers already sent by (output started at /wp-config.php:5)

Hier wird vor der eigentlichen Ausgabe von WordPress schon Text gesendet, meistens ein unsichtbares Leerzeichen oder ein Zeilenumbruch am Anfang oder Ende einer PHP-Datei. Im Beispiel steht der Verursacher in der wp-config.php in Zeile 5.

Die Lösung: Die genannte Datei in Notepad++ öffnen, die Kodierung auf UTF-8 without BOM stellen und prüfen, ob vor <?php oder nach ?> versteckte Zeichen stehen. In neun von zehn Fällen ist es genau das.

Schritt 5: Nach dem Debuggen aufräumen

Das vergessen die meisten und es ist ein echtes Sicherheitsproblem. Eine aktive debug.log auf einer Live-Seite ist öffentlich erreichbar unter deinewebsite.de/wp-content/debug.log und sie enthält Dateipfade, Funktionsnamen und Details deiner Installation. Ein Angreifer freut sich darüber.

Nach dem Debuggen also in der wp-config.php:

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

Und die debug.log löschen.

Wer die Datei grundsätzlich nicht im Web-Verzeichnis haben will, legt den Pfad außerhalb:

define( 'WP_DEBUG_LOG', '/home/deinuser/debug.log' );

Dann ist sie von außen nie erreichbar.

Wann die debug.log nicht reicht

Für Plugin-Konflikte und PHP-Fehler reicht sie vollständig. Willst du langsame Datenbankabfragen finden, JavaScript-Fehler analysieren oder REST-API-Aufrufe nachverfolgen, brauchst du zusätzlich Query Monitor. Das Plugin ist kostenlos, wird gepflegt und hat über eine Million Installationen. Es zeigt dir im Backend, welche Abfragen langsam sind, welche Hooks feuern und was im Hintergrund läuft. Für den Alltag reicht die debug.log.

Was bleibt

Einmal eingerichtet, weißt du beim nächsten Fehler in zwei Minuten, wo das Problem sitzt, ohne stundenlanges Ausschlussverfahren. Ich richte das bei jedem neuen Kundenprojekt als Erstes ein, weil Fehler irgendwann kommen und ich sie dann schnell finden will.

Und wenn du sagst „Patrick, ich will mich mit so etwas einfach nicht beschäftigen“, ist das auch in Ordnung. Dafür bin ich da.

Häufige Fragen zur debug.log

Wo finde ich die wp-config.php?

Im Stammverzeichnis deiner WordPress-Installation, je nach Hoster unter /public_html/ oder /www/. Erreichbar per SFTP oder über den Dateimanager deines Hosters.

Die debug.log existiert nicht. Was tun?

Die Datei wird erst angelegt, wenn ein Fehler auftritt. Ruf die Seite auf, die den Fehler zeigt. Ist sie danach immer noch nicht da, prüfe, ob WordPress Schreibrechte auf /wp-content/ hat.

Kann ich WP_DEBUG dauerhaft eingeschaltet lassen?

Nein. Die Datei wächst unbegrenzt, enthält Pfadinformationen und ist standardmäßig öffentlich erreichbar. Nur einschalten, wenn du aktiv nach einem Fehler suchst, danach ausschalten und die Datei löschen.

Was ist der Unterschied zwischen Fatal error und Warning?

Ein Fatal Error stoppt die Ausführung sofort, die Seite ist down. Eine Warning ist weniger kritisch, die Seite läuft weiter. Ignorieren solltest du sie trotzdem nicht.

Muss ich die debug.log nach dem Debuggen löschen?

Ja. Sie enthält Dateipfade und Details deiner Installation. Löschen oder leeren, dann ist sie weg bis zum nächsten Fehler.