In diesem Artikel zeige ich dir Schritt für Schritt wie du WordPress debug.log aktivierst, die Datei findest und vor allem richtig liest.
Die meisten WordPress-Probleme haben eine Ursache. Die steht meistens schon irgendwo aufgeschrieben – in einer Textdatei auf deinem Server die die wenigsten kennen.
Sie heißt debug.log. Und sie ist der Grund warum ich bei Kundenwebsites selten länger als zwei Minuten brauche um zu wissen wo ein Fehler herkommt – während andere noch blind Plugins deaktivieren.
In diesem Artikel zeige ich dir wie du sie aktivierst, findest und vor allem liest. Denn aktivieren kann man schnell googeln – verstehen was da drin steht, das erklärt kaum jemand auf Deutsch.
Was ist WP_DEBUG überhaupt?
WordPress hat einen eingebauten Debug-Modus der standardmäßig deaktiviert ist. Gut so – auf einer Produktivseite willst du keine PHP-Fehlermeldungen öffentlich anzeigen. Aber wenn du ein Problem debuggst, ist er dein schärfstes Werkzeug.
Der Debug-Modus wird über drei Konstanten in der wp-config.php gesteuert. Die meisten Anleitungen erklären nur die erste – und wundern sich dann warum die Log-Datei leer bleibt.
WP_DEBUG – schaltet den Debug-Modus ein. Ohne das funktionieren die anderen beiden nicht.
WP_DEBUG_LOG – schreibt alle Fehler still in eine Log-Datei statt sie anzuzeigen. Das ist der Teil der wirklich zählt.
WP_DEBUG_DISPLAY – steuert ob Fehler im Frontend sichtbar sind. Auf einer Live-Site immer false. Immer.
Schritt 1: wp-config.php öffnen
Die wp-config.php liegt im Stammverzeichnis deiner WordPress-Installation – direkt in /public_html/ oder /www/, je nach Hoster. Du erreichst sie per SFTP (FileZilla o.ä.) oder über den Dateimanager deines Hosting-Dashboards.
Bevor du irgendetwas anfasst: mach eine Kopie der Datei. Einen Tippfehler in der wp-config.php und die gesamte Website ist down. Kein Witz, passiert regelmäßig. Dupliziere die Datei einfach und bennene sie um in wp-config.php.bak. Mit der wp-config.php machen wir jetzt weiter.
Schritt 2: Debug-Logging aktivieren
Suche in der Datei nach dieser Zeile:
/* That's all, stop editing! Happy blogging. */Füge die drei Zeilen direkt oberhalb davon ein:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Datei speichern, hochladen, fertig. WordPress schreibt ab jetzt alle Fehler still ins Log ohne sie im Frontend anzuzeigen.
Falls in deiner wp-config.php bereits eine Zeile mit define( 'WP_DEBUG', false ) steht – einfach false durch true ersetzen und die anderen beiden Zeilen darunter ergänzen.
Schritt 3: Die debug.log finden und öffnen
Die Log-Datei liegt unter:
/wp-content/debug.logPer SFTP oder Dateimanager aufrufen, herunterladen, mit einem Texteditor öffnen. Notepad++, VS Code oder sogar der Windows-Editor reichen – es ist eine einfache Textdatei.
Einen Haken: Die Datei existiert erst nachdem ein Fehler aufgetreten ist. Wenn du sie nicht findest, ruf die Seite auf die den Fehler zeigt – dann wird sie automatisch erstellt.
Schritt 4: Die Log-Datei lesen – was bedeutet was?
Das ist der Teil den die meisten Artikel weglassen. Und der eigentlich wichtigste.
Hier ein typischer Eintrag:
[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 123Was du daraus liest:
PHP Fatal error – schwerwiegender Fehler der die Ausführung sofort stoppt. Der Grund für deinen weißen Bildschirm oder 500er.
Call to undefined function some_plugin_function() – das Plugin ruft eine Funktion auf die nicht existiert. Meistens weil ein anderes Plugin oder der Core diese Funktion nach einem Update nicht mehr bereitstellt. Klassischer Konflikt.
/wp-content/plugins/mein-plugin/mein-plugin.php on line 123 – der Übeltäter. Dateiname und Zeile direkt genannt. Kein Rätselraten mehr.
Die vier Fehlertypen die du kennen musst
PHP Fatal error
Die Website ist down, Ausführung gestoppt. Sofort handeln.
PHP Warning
Die Seite läuft noch, aber irgendwas stimmt nicht. Oft der Vorbote eines Fatal Errors nach dem nächsten Update. Nicht ignorieren.
PHP Notice
Rein informativ, kein akutes Problem. Meistens schlampig geschriebener Plugin-Code. Solange keine Warnings oder Errors dabei sind, ignorierbar.
PHP Deprecated
Eine Funktion wird verwendet die in zukünftigen PHP-Versionen entfernt wird. Heute kein Problem, in sechs Monaten vielleicht schon. Plugin-Entwickler kontaktieren oder Alternative suchen.
Ein weiteres Beispiel aus der Praxis: headers already sent
Einer der häufigsten Fehler den 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)Was das bedeutet: Irgendwo vor dem eigentlichen WordPress-Output wird Text ausgegeben – meistens ein unsichtbares Leerzeichen oder Zeilenumbruch am Anfang oder Ende einer PHP-Datei. Hier beispielhaft in der wp-config.php in Zeile 5.
Lösung: Die genannte Datei in Notepad++ öffnen, Encoding auf UTF-8 without BOM setzen, prüfen ob vor <?php oder nach ?> versteckte Zeichen stehen. In 90% der Fälle ist es genau das.
Schritt 5: Nach dem Debugging aufräumen
Das vergessen die meisten. Und das ist ein echtes Sicherheitsproblem.
Eine aktive debug.log auf einer Produktivseite ist öffentlich erreichbar unter deinewebsite.de/wp-content/debug.log – und enthält Dateipfade, Funktionsnamen und Code-Details deiner Installation. Ein Angreifer freut sich.
Nach dem Debugging 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.
Profi-Tipp: Wer die Log-Datei grundsätzlich nicht im Web-Root haben will, kann den Pfad auf ein Verzeichnis außerhalb legen:
define( 'WP_DEBUG_LOG', '/home/deinuser/debug.log' );Dann ist sie gar nicht erst öffentlich erreichbar.
Wann reicht die debug.log nicht?
Für Plugin-Konflikte und PHP-Fehler reicht sie vollständig. Wenn du aber langsame Datenbankabfragen debuggen, JavaScript-Fehler analysieren oder REST-API-Calls tracken willst – dann brauchst du zusätzlich Query Monitor. Kostenlos, aktiv gepflegt, über eine Million Installationen. Zeigt dir im Backend direkt welche Queries langsam sind, welche Hooks feuern und was im Hintergrund läuft.
Für den Alltag: debug.log reicht.
Abschluss
Einmal eingerichtet weißt du beim nächsten Fehler in zwei Minuten wo das Problem liegt. Kein blinder Aktionismus, kein stundenlanger Ausschluss-Marathon.
Ich richte das bei jedem neuen Kundenprojekt als erstes ein – nicht weil ich Fehler erwarte, sondern weil ich sie schnell finden will wenn sie kommen. Und sie kommen immer irgendwann.
Und wenn du sagst „Patrick, ich will mich mit sowas einfach nicht beschäftigen“ – auch gut. Dafür bin ich da.
Häufige Fragen zur WordPress debug.log
Wo finde ich die wp-config.php?
Im Stammverzeichnis deiner WordPress-Installation – direkt in /public_html/ oder /www/. Erreichbar per SFTP oder über den Dateimanager deines Hosters.
Die debug.log existiert nicht – was tun?
Die Datei wird erst erstellt wenn ein Fehler auftritt. Ruf die Seite auf die den Fehler zeigt, dann wird sie angelegt. Wenn sie danach immer noch nicht da ist, prüfe ob WordPress Schreibrechte auf /wp-content/ hat.
Kann ich WP_DEBUG dauerhaft aktiviert lassen?
Nein. Die Log-Datei wächst kontinuierlich, enthält sensible Pfadinformationen und ist standardmäßig öffentlich erreichbar. Nur aktivieren wenn du aktiv debuggst, danach sofort wieder deaktivieren und Datei löschen.
Was bedeutet PHP Fatal error vs. PHP Warning?
Fatal Error stoppt die Ausführung sofort – Website down. Warning ist weniger kritisch, die Seite läuft noch, aber ignorieren solltest du sie trotzdem nicht.
Muss ich nach dem Debugging die debug.log löschen?
Ja. Die Datei enthält Dateipfade und Code-Details deiner Installation. Löschen oder Inhalt leeren – dann ist sie weg bis zum nächsten Fehler.