WordPress Debug-Log: Wo debug.log liegt und wie du es verschiebst

WordPress schreibt sein Debug-Log standardmäßig nach wp-content/debug.log – auf der Festplatte also unter einem absoluten Pfad wie /pfad/zu/deiner/website/wp-content/debug.log. Die Datei existiert erst, wenn tatsächlich etwas protokolliert wird, und sie wird überhaupt nur beschrieben, wenn WP_DEBUG auf true steht und WP_DEBUG_LOG in der wp-config.php aktiviert ist. Dieser Standardort ist außerdem ein echtes Sicherheitsproblem, denn bei den meisten Hostern kann ihn jeder im Browser abrufen.

Die drei Konstanten und was jede davon tut

Alle drei gehören in die wp-config.php, oberhalb der Zeile /* That's all, stop editing! Happy blogging. */. Alles, was du unterhalb dieser Zeile einträgst, läuft erst, wenn WordPress bereits gestartet ist, und wird ignoriert.

Konstante	Standard	Was sie tut
WP_DEBUG	false	Hauptschalter. Hebt PHPs Fehlerberichterstattung an, sodass Hinweise, Warnungen und Veraltungsmeldungen erscheinen. Ohne sie funktioniert nichts anderes auf dieser Liste.
WP_DEBUG_LOG	false	Schreibt Fehler in eine Datei. true bedeutet wp-content/debug.log. Eine Zeichenkette wird als Dateipfad interpretiert, in den geschrieben wird.
WP_DEBUG_DISPLAY	true	Gibt Fehler im HTML der Seite aus, sichtbar für jeden Besucher.

Die Abhängigkeit ist der Teil, den die Leute falsch machen. WP_DEBUG_LOG wird innerhalb des WP_DEBUG-Zweigs im Startcode von WordPress ausgewertet. Steht WP_DEBUG auf false, bewirkt WP_DEBUG_LOG auf true schlicht gar nichts – keine Datei, kein Fehler, keine Warnung. Hast du WP_DEBUG_LOG gesetzt und es erschien kein Log, prüfe zuerst WP_DEBUG.

Eine funktionierende Konfiguration für eine Live-Website:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Ist WP_DEBUG weiter oben in der Datei bereits definiert – üblicherweise ist es das, mit dem Wert false –, bearbeite diese vorhandene Zeile, statt ein zweites define() hinzuzufügen. Dieselbe Konstante zweimal zu definieren wirft eine PHP-Warnung, die auf einer Website mit aktivierter Anzeige direkt oben auf der Seite landet.

Warum WP_DEBUG_DISPLAY im Produktivbetrieb false sein muss

Ist die Anzeige an, werden PHP-Fehler in die HTML-Antwort geschrieben. Eine einzige Veraltungsmeldung aus einem Theme druckt den absoluten Dateisystempfad deines Servers vor jedem Besucher aus. Ein Datenbankfehler verrät Tabellennamen und Fragmente von Abfragen. Schlimmer noch: Ausgabe, die vor dem Senden der Header erscheint, zerlegt Weiterleitungen, zerstört REST- und AJAX-Antworten, die sauberes JSON erwarten, und kann die weiße Seite erzeugen, die man anschließend einem Plugin in die Schuhe schiebt.

Eine Feinheit, die man kennen sollte: WP_DEBUG_DISPLAY auf null zu setzen ist nicht dasselbe wie false. null weist WordPress an, PHPs display_errors-Einstellung in Ruhe zu lassen und zu übernehmen, was der Server vorgibt. false schaltet sie aktiv ab. Auf einer Produktivseite nimmst du false und ergänzt die obige ini_set-Zeile als doppelte Absicherung, denn ein Plugin kann display_errors später im Request wieder einschalten.

Der Standardort ist öffentlich abrufbar

wp-content/debug.log liegt innerhalb des Web-Roots. Nichts in einer WordPress-Standardinstallation blockiert direkte Anfragen darauf. Bei einem typischen Apache- oder nginx-Setup liefert https://deineseite.de/wp-content/debug.log die Datei als Klartext aus. Debug-Logs enthalten absolute Serverpfade, Interna von Plugins und Themes, Datenbankfehler mit echtem Abfragetext und manchmal Werte, die an fehlschlagende Funktionen übergeben wurden. Das ist kostenlose Aufklärung für jeden, der die URL errät – und es ist eine der ersten URLs, die automatische Scanner ausprobieren.

Es gibt zwei Wege damit umzugehen. Der bessere ist, das Log zu verschieben.

Das Log über einen Pfad verschieben

Seit WordPress 5.1 akzeptiert WP_DEBUG_LOG statt eines Booleans auch einen Dateipfad als Zeichenkette. Lege ihn außerhalb des Document Roots an:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Drei Regeln für diesen Pfad. Nimm einen absoluten Pfad – ein relativer wird gegen PHPs Arbeitsverzeichnis aufgelöst, das je nach Request und Server variiert, du verlierst also aus den Augen, wo die Datei gelandet ist. Das Verzeichnis muss bereits existieren; PHP legt es nicht an, und wenn es die Datei nicht öffnen kann, scheitert es stillschweigend. Und das Verzeichnis muss für den PHP-Benutzer beschreibbar sein, was auf Shared Hosting nicht dasselbe Konto ist, mit dem du dich per SFTP einloggst.

Sperrt dein Hosting dich in den Web-Root ein und es gibt oberhalb davon nichts Beschreibbares, bleibst du beim Standardpfad und sperrst den Zugriff stattdessen auf Serverebene. Apache:

<Files "debug.log">
  Require all denied
</Files>

Das gehört in eine .htaccess innerhalb von wp-content, nicht in die im Stammverzeichnis – WordPress schreibt die .htaccess im Stammverzeichnis beim Speichern der Permalinks neu und kann deine Ergänzung dabei löschen. Unter nginx bewirkt eine .htaccess gar nichts; dort brauchst du einen Location-Block in der Serverkonfiguration, was bei Managed Hosting meist heißt: den Support fragen.

Sei ehrlich, was dir das Sperren bringt: Die Datei liegt weiterhin in einem Verzeichnis, das der Webserver ausliefert. Ein Path-Traversal-Fehler in irgendeinem Plugin kann sie immer noch lesen. Sie aus dem Web-Root zu verschieben ist die stärkere Lösung.

Die Datei lesen und live mitverfolgen

Per SSH beobachtest du sie live, während du den Fehler reproduzierst:

tail -f wp-content/debug.log

Reproduziere den Fehler in einem anderen Tab, und die neuen Zeilen erscheinen, während sie geschrieben werden. Um nur das Jüngste zu sehen oder auf ein Plugin zu filtern:

tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50

PHP hängt hinten an die Datei an, also lies von unten nach oben. Jeder Eintrag ist mit einem Zeitstempel in UTC versehen, der nicht zu deiner WordPress-Zeitzone passt – lass dich davon nicht zu dem Schluss verleiten, du würdest alte Einträge ansehen.

Mit WP-CLI schaltest du die Konstanten um, ohne die Datei von Hand zu bearbeiten:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Der Schalter --raw ist entscheidend – ohne ihn wird der Wert als Zeichenkette "true" geschrieben statt als Boolean. Für die Pfad-Variante lässt du --raw weg, damit er als Zeichenkette in Anführungszeichen geschrieben wird.

Kein SSH? Lade die Datei per SFTP herunter oder öffne sie im Dateimanager deines Hosters. Meide Plugins, die das Log im wp-admin anzeigen, sofern du ihnen nicht vollständig vertraust; du gibst einem Plugin damit Lesezugriff auf eine Datei voller Server-Interna.

Wenn du den exakten wp-config-Block für dein Setup willst, inklusive eines sicheren Pfads außerhalb des Roots und der passenden Serverregel, baut der WordPress Debug-Log-Generator ihn für dich.

Schalte es wieder aus, wenn du fertig bist

Nichts im WordPress-Core rotiert oder kürzt debug.log. Auf einer Website, die bei jedem Seitenaufruf einen Hinweis wirft, wächst sie unbegrenzt und kann die Festplatte füllen – was die Website härter lahmlegt als der Fehler, den du gesucht hast. Logging einschalten, Problem reproduzieren, Log lesen, WP_DEBUG wieder auf false setzen.

So leerst du die Datei, ohne sie zu löschen:

: > wp-content/debug.log

Wenn das Log leer bleibt

Arbeite das der Reihe nach ab. WP_DEBUG steht auf false – die mit Abstand häufigste Ursache, und sie legt alles andere stillschweigend still. Die Konstante steht unterhalb der “stop editing”-Zeile in der wp-config.php. Dateirechte – PHP kann nicht nach wp-content schreiben oder nicht in das eigene Verzeichnis, das du angegeben hast. Ein fataler Fehler, bevor die wp-config fertig geladen ist, etwa ein Syntaxfehler in der Konfigurationsdatei selbst, passiert zu früh, als dass das Logging von WordPress ihn noch mitbekäme; solche Fehler landen im PHP-Fehlerlog des Servers. Dein Hoster überschreibt es – manche Managed-Plattformen fixieren PHPs error_log-Einstellung oder leiten das Logging in ihr eigenes Dashboard um; dann sind deine Konstanten korrekt gesetzt und die Ausgabe liegt schlicht woanders. Sieh in den Log-Viewer des Hosters, bevor du annimmst, deine Konfiguration sei kaputt.