WordPress Debug Modus aktivieren – Fehler sichtbar machen

Weiße Seiten, kritische Fehler, merkwürdiges Verhalten — und WordPress schweigt. Das ist Absicht: Auf Live-Websites werden Fehlermeldungen unterdrückt, damit Besucher (und Angreifer) keine Interna sehen. Der Debug-Modus hebt dieses Schweigen gezielt auf. Er ist das erste Werkzeug bei praktisch jeder Fehlersuche.

Die richtige Konfiguration

Öffne die wp-config.php und füge oberhalb von /* That's all, stop editing! */ ein:

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

Die Kombination ist bewusst gewählt:

• WP_DEBUG schaltet die Fehlererfassung ein.
• WP_DEBUG_LOG schreibt alles nach /wp-content/debug.log.
• WP_DEBUG_DISPLAY false hält die Meldungen von der Website fern — Besucher sehen weiterhin nichts. Fehler auf einer öffentlichen Seite anzeigen zu lassen ist keine Option: Pfade, Versionen und Plugin-Namen sind ein Geschenk an Angreifer.

Das Log richtig lesen

Öffne /wp-content/debug.log per FTP. Ein typischer Eintrag:

[21-Aug-2026 10:14:03 UTC] PHP Fatal error: Uncaught Error: Call to undefined function foo() in /wp-content/plugins/beispiel/inc/loader.php:87

Lies ihn in dieser Reihenfolge:

1. Schweregrad: Fatal error stoppt die Seite — das ist dein Hauptverdächtiger. Warning und Notice sind Schönheitsfehler; Deprecated kündigt künftige Probleme an. Bei einem Ausfall interessiert dich zuerst nur die letzte Fatal-Zeile.
2. Pfad: /plugins/beispiel/ — der Verursacher ist das Plugin „beispiel“. Wie es weitergeht, steht im Artikel PHP Fatal Error beheben.
3. Zeitstempel: Passt er zu deinem Problem? Ein Log sammelt auch Altlasten — entscheidend sind die Einträge aus dem Moment des Fehlers. Tipp: Log-Datei leeren, Fehler reproduzieren, frisch lesen.

Die weiteren Debug-Konstanten

• SCRIPT_DEBUG (true): WordPress lädt unkomprimierte CSS/JS-Dateien — hilfreich bei Darstellungs- und Editor-Problemen, um echte Fehlerzeilen zu sehen.
• SAVEQUERIES (true): protokolliert alle Datenbank-Abfragen samt Dauer — die Grundlage für Performance-Analysen, aber selbst spürbar bremsend: nur kurzzeitig einschalten.
• WP_DISABLE_FATAL_ERROR_HANDLER (true): schaltet WordPress‘ eigene „Website hat ein technisches Problem“-Abfederung ab, damit du den rohen Fehler siehst statt der freundlichen Hülle.

Query Monitor: Debug mit Komfort

Für alles jenseits des Logs ist das kostenlose Plugin Query Monitor der Standard: Es zeigt pro Seitenaufruf PHP-Fehler, langsame Datenbank-Abfragen, HTTP-Requests, Hooks und Template-Entscheidungen — aufgeschlüsselt nach verursachendem Plugin. Perfekt, um Performance-Fressern und sporadischen Fehlern auf die Spur zu kommen; nach der Analyse wieder deaktivieren.

Nach der Fehlersuche: aufräumen

1. Alle Debug-Konstanten auf false bzw. entfernen.
2. debug.log löschen — sie kann sensible Pfade enthalten und wächst sonst unbegrenzt.
3. Sicherstellen, dass die Datei nicht öffentlich abrufbar war/ist — ein Grund mehr, warum WP_DEBUG auf Live-Seiten nur für die Dauer der Diagnose läuft.

Bei Ammera Care gehört der Blick in die Fehlerprotokolle zur laufenden Betreuung: Häufen sich Warnungen oder tauchen neue Fatal Errors auf, sehen wir es im Monitoring — und beheben die Ursache, bevor aus einem Log-Eintrag ein Ausfall wird. Zum Core-Modul.