Dein Shop zeigt plötzlich einen kritischen Fehler an, ein Formular verschickt nichts mehr oder das Backend lädt nur noch halb? Dann schaust du zuerst ins PHP-Fehlerprotokoll. WordPress schreibt PHP-Fehler in die Datei debug.log im Ordner /wp-content/, sobald du in der wp-config.php zwei Konstanten setzt: WP_DEBUG und WP_DEBUG_LOG. Daneben führt dein Server meist ein eigenes PHP-Error-Log. Hier zeigen wir dir, wie du beide Protokolle einschaltest, wo du sie findest und wie du die Einträge liest. Außerdem erfährst du, wie du das Log so ablegst, dass es keine Sicherheitslücke wird.
TL;DR
- Setze in der
wp-config.phpWP_DEBUGundWP_DEBUG_LOGauftrueundWP_DEBUG_DISPLAYauffalse. Alle drei Zeilen gehören vor die Zeile/* That's all, stop editing! */. - Die Datei
debug.logentsteht standardmäßig unter/wp-content/, aber erst, wenn tatsächlich ein Fehler auftritt. - Speichere das Log besser außerhalb des öffentlichen Webverzeichnisses. Eine offen erreichbare
debug.logverrät Pfade, Plugins und im Zweifel Datenbankdetails. - Die neuesten Einträge stehen unten. Fehlertyp, Meldung, Datei und Zeilennummer zeigen dir fast immer das verantwortliche Plugin oder Theme.
- Schalte das Logging nach der Fehlersuche wieder ab und lösche die Datei. Auf Live-Systemen steht
WP_DEBUGdauerhaft auffalse.
Inhaltsverzeichnis
- Zwei Protokolle, ein Ziel: debug.log und Server-Log
- Debug-Log in der wp-config.php aktivieren
- Wo liegt das PHP-Fehlerprotokoll?
- Das Log sicher ablegen
- Einträge verstehen: So liest du das Log
- Wenn das Log leer bleibt
- Fatal Error und Wiederherstellungsmodus
- Die PHP-Version als Fehlerquelle
- Aus der Praxis: Drei typische Fälle
- Logging nach der Fehlersuche sauber abschalten
- Wenn du lieber einen Profi draufschauen lässt
- Häufige Fragen zum PHP-Fehlerprotokoll
- Quellen
Zwei Protokolle, ein Ziel: debug.log und Server-Log
Wer vom „PHP Error Log in WordPress“ spricht, meint meist eine von zwei Dateien. Beide sammeln PHP-Fehler, werden aber an unterschiedlichen Stellen gesteuert.
| Merkmal | WordPress-Debug-Log | Server-PHP-Error-Log |
|---|---|---|
| Dateiname | meist debug.log |
z. B. error_log, php_errors.log oder je nach Hoster anders |
| Gesteuert über | wp-config.php |
php.ini, .user.ini oder Hoster-Oberfläche |
| Standardort | /wp-content/ |
je nach Server, oft im Log-Verzeichnis des Hosting-Pakets |
| Aktivieren kann | jeder mit FTP- oder Dateizugriff | der Server-Admin oder du über das Kundenmenü |
| Erfasst | Fehler, Warnungen und Hinweise aus WordPress, Plugins und Themes | alle PHP-Fehler der Domain, auch außerhalb von WordPress |
| Ideal für | gezielte Fehlersuche bei Plugins und Themes | Fehler, die schon vor dem Laden von WordPress auftreten |
Für die tägliche Fehlersuche ist das WordPress-Log praktischer, weil du es ohne Serverrechte einschalten kannst. Das Server-Log brauchst du, wenn WordPress gar nicht erst startet. Das passiert etwa bei einem Syntaxfehler in der wp-config.php selbst oder wenn PHP wegen Speichermangels abbricht, bevor WordPress eingreifen kann.
Die zuständigen PHP-Direktiven heißen log_errors (Protokollierung an oder aus) und error_log (Pfad zur Datei). Was sie bedeuten und welche Standardwerte sie haben, steht in der Laufzeit-Konfiguration im PHP-Handbuch. Bei Shared Hosting kannst du die php.ini selten direkt ändern. Viele Hoster bieten dafür aber einen Schalter im Kundenmenü an oder erlauben eine eigene .user.ini.
Debug-Log in der wp-config.php aktivieren
Bevor du etwas änderst: Erstelle ein Backup oder arbeite auf einer Staging-Kopie. Das empfiehlt auch die offizielle WordPress-Dokumentation zum Debugging, und zwar aus gutem Grund. Ein vergessenes Semikolon in der wp-config.php legt die komplette Seite lahm.
So gehst du vor:
- Verbinde dich mit deinem Webspace. Nutze SFTP oder den Dateimanager deines Hosters und öffne das Hauptverzeichnis deiner WordPress-Installation.
- Sichere die wp-config.php. Lade die Datei herunter, bevor du sie bearbeitest. So machst du jede Änderung in Sekunden rückgängig.
- Suche nach bestehenden Einträgen. Oft steht dort schon
define( 'WP_DEBUG', false );. Eine doppelte Definition erzeugt selbst eine Warnung. Ersetze deshalb die vorhandene Zeile, statt eine zweite einzufügen. - Füge die Konstanten ein, und zwar oberhalb der Zeile
/* That's all, stop editing! Happy publishing. */:
// Fehler sammeln
define( 'WP_DEBUG', true );
// Fehler in /wp-content/debug.log schreiben
define( 'WP_DEBUG_LOG', true );
// Fehler NICHT im Browser anzeigen
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
- Speichere die Datei und löse den Fehler erneut aus. Ruf die betroffene Seite auf, schick das Formular ab oder starte den Checkout. Erst dann entstehen Einträge.
- Öffne
/wp-content/debug.log. Lade die Datei herunter oder öffne sie im Dateimanager. Die neuesten Einträge stehen ganz unten.
Entscheidend ist das Zusammenspiel der drei Schalter. WP_DEBUG allein schreibt keine Datei. Es weist WordPress nur an, alle Fehler und Warnungen zu melden. Erst WP_DEBUG_LOG speichert sie dauerhaft. Das zählt vor allem bei AJAX-Anfragen, REST-API-Aufrufen und Cron-Jobs, denn deren Fehler siehst du im Browser nie. WP_DEBUG_DISPLAY auf false sorgt dafür, dass deine Besucher keine Fehlermeldungen mit Serverpfaden zu sehen bekommen. Alle drei Konstanten beschreibt die Referenz zur wp-config.php.
Wie du den Debug-Modus für verschiedene Umgebungen sauber einstellst, etwa lokal mit Anzeige und live nur mit Log, erklären wir ausführlich in unserem Beitrag zum Debug Mode in WordPress mit der richtigen Konfiguration.
Wo liegt das PHP-Fehlerprotokoll?
„Wo ist meine Log-Datei?“ ist die Frage, die wir bei der Fehlersuche am häufigsten hören. Die Antwort hängt davon ab, welches Log du suchst.
- WordPress-Debug-Log: standardmäßig
/wp-content/debug.log. Gibst du beiWP_DEBUG_LOGeinen Pfad statttruean, liegt die Datei genau dort. - Server-Log im Hosting-Paket: Viele deutsche Hoster zeigen PHP-Fehler im Kundenbereich unter Punkten wie „Logs“, „Protokolle“ oder „Fehlerprotokoll“ an. Manche legen eine Datei namens
error_logdirekt in das Verzeichnis, in dem das fehlerhafte Skript lief. - Eigener Server oder VPS: Den Pfad verrät dir die Direktive
error_login der aktivenphp.ini. Bei PHP-FPM kann zusätzlich jeder Pool ein eigenes Log schreiben.
Findest du gar nichts, frag den Support deines Hosters: „Wo werden die PHP-Fehler für meine Domain protokolliert, und kann ich das Logging einschalten?“ Das erspart dir oft eine Stunde Suche.
Das Log sicher ablegen
Diesen Punkt erwähnen viele Anleitungen nur am Rand. Der Ordner /wp-content/ ist öffentlich erreichbar. Liegt dort eine debug.log, kann sie jeder unter deinedomain.de/wp-content/debug.log aufrufen, der die Adresse kennt. Und automatisierte Scanner kennen sie alle.
Was steht in so einer Datei? Vollständige Serverpfade, Namen und Versionen deiner Plugins, manchmal Datenbanktabellen oder Teile von Anfragen. Die WordPress-Härtungsanleitung zu display_errors erklärt, warum genau solche Informationen Angreifern helfen. Für das Log gilt dasselbe wie für Fehlermeldungen im Browser.
Du hast zwei gute Optionen:
Option 1: Log außerhalb des Webroots speichern. Das ist die sauberste Lösung. WP_DEBUG_LOG akzeptiert statt true auch einen Dateipfad:
define( 'WP_DEBUG_LOG', '/home/kunde/logs/wp-debug.log' );
Der Ordner muss existieren und für PHP beschreibbar sein. Den richtigen absoluten Pfad findest du im Kundenmenü deines Hosters oder in WordPress unter Website-Zustand.
Option 2: Zugriff per .htaccess sperren. Läuft deine Seite auf Apache, kannst du die Datei in der .htaccess im Hauptverzeichnis blockieren:
<Files "debug.log">
Require all denied
</Files>
Auf älteren Apache-Versionen lautet die Anweisung Deny from all. Auf Nginx-Servern greift die .htaccess nicht, dort muss die Sperre in die Serverkonfiguration. Prüfe danach in einem privaten Browserfenster, ob die Datei wirklich nicht mehr ausgeliefert wird.
Ein offen liegendes Log finden wir bei einem WordPress-Sicherheitsaudit übrigens regelmäßig, oft noch Monate nach der eigentlichen Fehlersuche.
Einträge verstehen: So liest du das Log
Ein typischer Eintrag sieht so aus:
[19-Oct-2026 08:14:02 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mein-theme/single.php:27
Lies ihn von links nach rechts:
- Zeitstempel in eckigen Klammern, meist in UTC. Gleiche ihn mit dem Zeitpunkt ab, zu dem das Problem auftrat.
- Fehlertyp, hier
Fatal error. Er zeigt dir, wie dringend der Eintrag ist. - Meldung, hier eine Funktion, die nicht existiert. In diesem Beispiel ruft das Theme eine Funktion aus einem Plugin auf, das deaktiviert wurde.
- Datei und Zeile. Der Pfad verrät dir den Verursacher: Steht dort
/plugins/plugin-name/, ist es dieses Plugin. Steht dort/themes/, liegt es am Theme.
Die wichtigsten Fehlertypen im Überblick:
| Fehlertyp | Bedeutung | Handlungsbedarf |
|---|---|---|
| Fatal error | PHP bricht das Skript ab, die Seite oder eine Funktion fällt aus | sofort beheben |
| Parse error | Syntaxfehler im Code, z. B. eine fehlende Klammer | sofort beheben, tritt meist nach einer Code-Änderung auf |
| Warning | Problem, das Skript läuft weiter, das Ergebnis ist aber womöglich falsch | zeitnah prüfen |
| Notice | Hinweis auf unsauberen Code, z. B. eine undefinierte Variable | einplanen |
| Deprecated | Funktion fällt in einer künftigen PHP- oder WordPress-Version weg | vor dem nächsten PHP-Update beheben |
PHP meldet standardmäßig alle diagnostischen Fehler. Laut PHP-Handbuch zu diagnostischen Fehlern war das vor PHP 8.0 noch anders. Deshalb wirken Logs nach einem Versionssprung oft plötzlich voll. Nicht jede Zeile ist ein Notfall. Kümmere dich zuerst um Fatal und Parse Errors, danach um Warnungen, die zu deinem konkreten Problem passen.
Praxistipp: Lösche die Datei vor einem neuen Test oder notiere dir die Uhrzeit. So trennst du alte Einträge sauber von neuen. Taucht derselbe Eintrag hundertfach auf, stammt er meist von einem Cron-Job oder von einem Plugin, das bei jedem Seitenaufruf denselben Fehler erzeugt.
Wenn das Log leer bleibt
Du hast alles eingetragen, aber es erscheint keine debug.log? Das sind die häufigsten Ursachen:
- Es gab noch keinen Fehler. Die Datei entsteht erst mit dem ersten Eintrag. Löse das Problem gezielt aus.
- Die Konstanten stehen an der falschen Stelle. Alles unterhalb von
require_once ABSPATH . 'wp-settings.php';greift zu spät. - Doppelte Definition. Steht
WP_DEBUGweiter oben schon auffalse, gilt die erste Definition. - Fehlende Schreibrechte. Darf PHP nicht in
/wp-content/schreiben, entsteht keine Datei. Prüfe die Rechte oder nutze einen beschreibbaren Pfad. - Ein Plugin überschreibt die Einstellungen. Manche Sicherheits- oder Performance-Plugins setzen
error_reportingoderlog_errorsselbst. Teste auf einer Staging-Kopie mit deaktivierten Plugins. - Der Fehler passiert vor WordPress. Dann landet er nur im Server-Log. Sieh im Kundenmenü deines Hosters nach.
- Der Cache liefert eine alte Seite aus. Leere Seiten-Cache und Server-Cache, sonst läuft der fehlerhafte Code gar nicht erst.
Fatal Error und Wiederherstellungsmodus
Seit WordPress 5.2 gibt es den Fatal Error Handler. Statt einer weißen Seite zeigt WordPress den Hinweis, dass die Website technische Schwierigkeiten hat, und schickt eine E-Mail an die Administrator-Adresse. Über den Link darin kommst du im Wiederherstellungsmodus ins Backend und kannst das fehlerhafte Plugin deaktivieren. Die Referenz zur wp-config.php beschreibt das im Abschnitt zum Fatal Error Handler.
Die E-Mail nennt meist das betroffene Plugin, die genaue Ursache steht aber im Log. Nutze deshalb beides: die Recovery-Mail für den schnellen Zugang, die debug.log für die Diagnose. Bleibt die Seite trotzdem komplett weiß, weil etwa die Mail nicht ankommt, hilft dir unsere Schritt-für-Schritt-Anleitung zum WordPress White Screen.
Musst du einen Fehler ausnahmsweise direkt im Browser sehen, kannst du WP_DEBUG_DISPLAY kurz auf true setzen. Mach das nur auf einer Staging-Seite oder für wenige Minuten und stell den Wert danach sofort zurück.
Die PHP-Version als Fehlerquelle
Viele Einträge im Log haben dieselbe Ursache: Ein Plugin oder Theme passt nicht zur PHP-Version deines Servers. Typisch ist der Wechsel auf eine neue Hauptversion. Alte Funktionen fallen weg, und aus „Deprecated“ wird plötzlich „Fatal error“.
Die aktive PHP-Version findest du am zuverlässigsten im Backend unter Werkzeuge > Website-Zustand > Info > Server. Dort steht die Version, mit der WordPress tatsächlich läuft. Die Ausgabe von php -v auf der Kommandozeile kann davon abweichen, weil Webserver und Konsole unterschiedliche PHP-Installationen nutzen können.
Für Versionswechsel gilt eine einfache Regel: erst testen, dann live schalten. Kopiere die Seite auf eine Staging-Umgebung, stell dort die neue PHP-Version ein, aktiviere das Debug-Log und prüf alle wichtigen Funktionen. Bei einem WooCommerce-Shop heißt das: Produkt in den Warenkorb legen, Checkout mit jeder Zahlungsart durchspielen, Bestellbestätigung und Kundenkonto prüfen. Wie du so eine Testumgebung aufsetzt, zeigen wir dir in vier Wegen zur sicheren Stagingumgebung. Eine vollständige Liste für den Umstieg findest du in unserer Checkliste für das PHP-Upgrade in WordPress.
Gerade bei Shops gehört vor jeden Eingriff eine frische Sicherung samt Datenbank, damit keine Bestellungen und Kundendaten verloren gehen. Welche Werkzeuge sich dafür eignen, zeigt dieser Vergleich von Backup-Plugins für WooCommerce.
Aus der Praxis: Drei typische Fälle
Fall 1: Der Checkout hängt. Kunden klicken auf „Zahlungspflichtig bestellen“, und der Ladekreis dreht sich endlos. Im Browser siehst du nichts, weil der Checkout per AJAX läuft. Im Log dagegen steht ein Fatal Error aus einem Zahlungs- oder Versand-Plugin. Genau deshalb ist WP_DEBUG_LOG unverzichtbar.
Fall 2: Nach dem Hoster-Update ist das Log voller Deprecated-Meldungen. Die Seite läuft, aber die Datei wächst jeden Tag um mehrere Megabyte. Das ist kein Notfall, aber ein Warnsignal: Die betroffenen Plugins brauchen Updates oder Ersatz, bevor die nächste PHP-Version sie ausbremst. Ein großes Log kostet außerdem Speicherplatz und Schreibzugriffe.
Fall 3: Geplante Beiträge erscheinen nicht. WP-Cron bricht im Hintergrund ab, und kein Besucher sieht eine Fehlermeldung. Nur das Log zeigt, dass ein Plugin beim Cron-Lauf an einem Speicherlimit scheitert.
In allen drei Fällen gehst du gleich vor: Log aktivieren, Fehler auslösen, Eintrag lesen, Verursacher eingrenzen, auf Staging beheben, Log wieder abschalten.
Logging nach der Fehlersuche sauber abschalten
Ist das Problem gelöst, setzt du die Werte zurück:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
Lösche anschließend die debug.log, falls sie im Webverzeichnis lag. Ein dauerhaft aktives Debug-Log auf einer Live-Seite ist ein Sicherheitsrisiko. Es kann außerdem auf mehrere Gigabyte anwachsen und die Performance belasten. Willst du Fehler dauerhaft überwachen, gehört das Log in ein geschütztes Verzeichnis außerhalb des Webroots. Dazu gehört ein fester Wartungsablauf, in dem jemand die Einträge regelmäßig auswertet.
Wenn du lieber einen Profi draufschauen lässt
Ein Log zu lesen ist das eine. Den Fehler zu beheben, ohne an anderer Stelle Shop, Formulare oder Schnittstellen zu beschädigen, ist das andere. Dafür gibt es unsere WordPress Problemlösung: Wir werten dein Fehlerprotokoll aus, finden die Ursache und beheben sie, bei Bedarf zuerst auf einer Staging-Umgebung. Mit über 14 Jahren Erfahrung in WordPress und WooCommerce kennen wir die typischen Konflikte zwischen Plugins, Themes und PHP-Versionen. Damit Fehler gar nicht erst unbemerkt wachsen, übernehmen wir mit der WordPress Wartung auch die laufende Betreuung: Updates, Sicherheit, Performance und ein wachsames Auge auf deine Logs. Wir arbeiten für Unternehmen, Online-Händler und Agenturen in ganz Deutschland.
Häufige Fragen zum PHP-Fehlerprotokoll
Wie lasse ich PHP-Fehler in WordPress anzeigen?
Setze in der wp-config.php WP_DEBUG und WP_DEBUG_DISPLAY auf true. Dann erscheinen die Meldungen direkt im Browser. Mach das nur auf einer Staging- oder Entwicklungsumgebung, denn auf einer Live-Seite verraten die Meldungen jedem Besucher Serverpfade und Plugin-Details. Auf Live-Seiten ist die debug.log der sichere Weg.
Wie finde ich die PHP-Version meiner WordPress-Seite heraus?
Öffne im Backend Werkzeuge > Website-Zustand, wechsle in den Tab Info und klapp den Abschnitt Server auf. Dort steht die PHP-Version, mit der WordPress tatsächlich läuft. Diese Angabe ist verlässlicher als die Kommandozeile, weil Webserver und Konsole unterschiedliche PHP-Versionen nutzen können.
Wie behebe ich einen Fatal Error in WordPress?
Öffne die Recovery-Mail an deine Administrator-Adresse und melde dich über den Link im Wiederherstellungsmodus an. Deaktiviere dort das genannte Plugin oder Theme und prüfe in der debug.log, welche Datei und Zeile den Fehler auslöst. Kommt keine Mail an, benenne den Plugin-Ordner per SFTP unter /wp-content/plugins/ um. Dann deaktiviert WordPress das Plugin automatisch.
Darf die debug.log dauerhaft auf dem Server bleiben?
Im öffentlichen Ordner /wp-content/ nicht. Dort ist die Datei über den Browser erreichbar und liefert Angreifern wertvolle Informationen. Lösche sie nach der Fehlersuche oder leg sie über einen Pfad in WP_DEBUG_LOG dauerhaft außerhalb des Webroots ab.
Warum ist meine debug.log so groß?
Meist schreibt ein Plugin bei jedem Seitenaufruf dieselbe Warnung oder Deprecation-Meldung, oft nach einem PHP-Update. Prüfe, welcher Eintrag sich wiederholt, aktualisiere oder ersetze das betroffene Plugin und leere danach die Datei. Lass das Logging auf Live-Seiten nicht dauerhaft unbeobachtet laufen.
Quellen
- Debugging in WordPress (WordPress Developer Resources)
- wp-config.php (WordPress Developer Resources)
- Display Errors (WordPress Hardening)
- PHP: Runtime Configuration (PHP-Handbuch)
- PHP: Diagnostic errors (PHP-Handbuch)
