Debug-Modus aktivieren — Schluss mit Rätselraten.
Irgendetwas stimmt nicht: eine weiße Seite, ein Formular, das nichts tut, ein Block, der nicht speichert. Ohne Fehlermeldung bleibt nur Raten. Der Debug-Modus macht sichtbar, was WordPress im Hintergrund meldet — und verwandelt eine halbe Stunde Probieren in zwei Minuten Lesen.
Drei Zeilen in der wp-config.php reichen: WP_DEBUG schaltet die Protokollierung ein, WP_DEBUG_LOG schreibt alles in eine Datei, WP_DEBUG_DISPLAY false hält die Meldungen von Besuchern fern. Danach steht in wp-content/debug.log, was wirklich passiert. Auf einer Live-Website gilt: protokollieren ja, anzeigen nie — und nach der Fehlersuche wieder abschalten.
Wozu das gut ist.
WordPress verschluckt Fehler standardmäßig. Das ist im Alltag sinnvoll, denn Besucher sollen keine technischen Meldungen sehen. Bei der Fehlersuche ist es hinderlich: Du siehst nur das Symptom, nicht die Ursache. Mit eingeschaltetem Debug-Modus bekommst du zu jedem Problem den Dateipfad, die Zeilennummer und die Art der Meldung — und damit meist sofort den Schuldigen. Bei praktisch jedem Fehlerbild lohnt der Blick ins Protokoll: bei der weißen Seite, beim kritischen Fehler, bei JSON-Fehlern im Editor und nach jedem PHP-Update.
Einschalten in drei Zeilen.
Die Datei wp-config.php liegt im Hauptverzeichnis deiner Installation. Öffne sie per FTP oder Dateimanager und suche die Zeile mit dem Kommentar, dass ab hier nichts mehr bearbeitet werden soll. Direkt davor kommt der Block. Falls WP_DEBUG dort schon mit false steht, wird diese Zeile ersetzt, nicht ergänzt — sonst gilt die erste.
define( 'WP_DEBUG', true ); // Protokollierung an
define( 'WP_DEBUG_LOG', true ); // schreibt nach wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // nichts im Browser ausgeben
@ini_set( 'display_errors', 0 ); // auch serverseitig stumm
/* That's all, stop editing! Happy publishing. */Auf einer lokalen Testinstallation kannst du WP_DEBUG_DISPLAY auf true setzen — dann siehst du Meldungen direkt im Browser.
Willst du das Protokoll an einem anderen Ort ablegen, etwa außerhalb des öffentlich erreichbaren Bereichs, gibst du bei WP_DEBUG_LOG statt true einen Pfad an. Das ist die sicherste Variante, weil die Datei dann gar nicht über den Browser abrufbar ist.
Das Protokoll lesen.
Die Datei findest du unter wp-content/debug.log. Sie entsteht erst, wenn die erste Meldung anfällt — bleibt sie leer, ist das ein gutes Zeichen. Eine Zeile sieht typischerweise so aus:
[29-Sep-2026 09:14:02 UTC] PHP Warning: Undefined array key "email" in
/www/htdocs/w01xxxxx/example.de/wp-content/plugins/altes-formular/form.php on line 88Zeitstempel, Art der Meldung, Beschreibung, Datei, Zeile. Der Pfad nennt dir den Verursacher.
Lies von unten nach oben — die neuesten Einträge stehen am Ende. Wiederholt sich dieselbe Meldung hundertfach, ist das normal: Sie fällt bei jedem Seitenaufruf an. Entscheidend ist nicht die Menge, sondern welche verschiedenen Meldungen auftreten.
Meldungen einordnen.
| Art | Bedeutung | Handeln? |
|---|---|---|
| Notice | Hinweis auf unsaubere, aber harmlose Stelle | Meist nein |
| Deprecated | Veraltete Funktion, verschwindet künftig | Update einplanen |
| Warning | Etwas stimmt nicht, läuft aber weiter | Ja, wenn sichtbar etwas fehlt |
| Fatal error | Abbruch — hier endet die Seite | Sofort |
| Database error | Abfrage fehlgeschlagen | Sofort, Tabelle prüfen |
Der häufigste Anfängerfehler: sich an Notices festbeißen. In jeder gewachsenen Installation finden sich davon dutzende, ohne dass irgendetwas kaputt ist. Konzentriere dich auf Fatal errors und auf Warnungen, die zeitlich zu deinem Problem passen.
Protokoll schützen.
Die Standarddatei liegt in einem Ordner, der über den Browser erreichbar ist. Wer die Adresse errät, liest Dateipfade, Plugin-Namen und manchmal mehr. Deshalb: Zugriff sperren, solange das Protokoll läuft.
<Files "debug.log">
Require all denied
</Files>Bei nginx übernimmt das eine entsprechende location-Regel in der Serverkonfiguration, die der Hoster einträgt.
Query Monitor als Ergänzung.
Das Protokoll zeigt Fehler. Wenn du wissen willst, warum etwas langsam ist, hilft zusätzlich das kostenlose Plugin Query Monitor. Es blendet in der Admin-Leiste für jeden Aufruf ein, wie lange er gedauert hat, wie viele Datenbankabfragen anfielen, welches Plugin sie verursacht hat und welche fremden Server angefragt wurden. Für Tempoprobleme ist das die schnellste Diagnose (Backend langsam). Nach der Analyse wieder deaktivieren — es ist ein Werkzeug, kein Dauergast.
Protokolle beim Hoster.
Unabhängig von WordPress führt der Server eigene Protokolle: das Fehlerprotokoll von PHP und das Zugriffsprotokoll. Bei den meisten Hostern findest du sie im Kundenbereich unter „Logfiles" oder „Statistiken". Sie helfen besonders dann, wenn WordPress gar nicht erst startet — bei einem Fehler 500 etwa steht die Ursache oft nur dort. Auch bei Sperrungen durch den Hoster ist das Zugriffsprotokoll die beste Quelle.
Wieder abschalten.
Nach der Fehlersuche gehören beide Dinge erledigt: WP_DEBUG auf false setzen und die Datei debug.log löschen. Sie wächst sonst unbemerkt weiter und kann bei einer Website mit vielen Warnungen in wenigen Wochen mehrere hundert Megabyte erreichen — in Einzelfällen bis das Webspace-Kontingent voll ist. Dauerhaft eingeschaltet gehört der Debug-Modus nur in eine Testumgebung.
Wenn du nicht weiterkommst.
Wenn im Protokoll Meldungen stehen, mit denen du nichts anfangen kannst, schick sie mir — meist erkenne ich daran schon, was los ist. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist: WordPress-Hilfe, bei einem Totalausfall der Notfall-Support. Damit es gar nicht erst so weit kommt: WordPress-Wartung.
Ursache finden, Website wieder zum Laufen bringen, kurzer Bericht — meist am selben Tag.
Für Anpassungen, Fehlerbehebung und Beratung nach Aufwand, abgerechnet in 15-Minuten-Schritten.
Updates, Backups, Sicherheitscheck, Monitoring — Kleinigkeiten inklusive.
Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.
Wer hilft.
Ich bin Manuel Killert, WordPress-Entwickler aus Quakenbrück. Seit 2020 baue und betreue ich WordPress-Websites — für Handwerksbetriebe, Industrie, Gastronomie, Start-ups und Vereine —, entwickle eigene Plugins und unterrichte WordPress als Dozent an der KW Design Akademie. Das heißt: Ich kenne die typischen Fehler nicht nur aus Foren, sondern aus eigenen Projekten, und ich kann sie so erklären, dass du sie beim nächsten Mal selbst erkennst. Du erreichst mich direkt, ohne Ticketsystem.
Echte Projekte — live ansehen.
WordPress-Websites, die ich gebaut habe oder laufend betreue.
Markenfest
Stärkerer Online-Shop — Webdesign, Content und individuelle Shop-Funktionen.
Website ansehen ↗
KT Bodenteam
Professioneller Auftritt für einen Bodenleger — Vorher-Nachher-Slider und regionale SEO.
Website ansehen ↗
Potassco Solutions
Klare Website für ein KI-Unternehmen, die komplexe Technologie verständlich macht.
Website ansehen ↗FAQ — Debug-Modus & Fehlerprotokoll.
Wie aktiviere ich den Debug-Modus in WordPress?
Mit drei Zeilen in der wp-config.php: WP_DEBUG auf true, WP_DEBUG_LOG auf true und WP_DEBUG_DISPLAY auf false. Damit werden Fehler protokolliert, aber Besuchern nicht angezeigt.
Wo finde ich die Datei debug.log?
Unter wp-content/debug.log. Sie entsteht erst, wenn die erste Meldung anfällt. Über eine Pfadangabe bei WP_DEBUG_LOG lässt sie sich auch außerhalb des öffentlich erreichbaren Bereichs ablegen.
Ist der Debug-Modus auf einer Live-Website gefährlich?
Nur wenn Meldungen angezeigt werden, denn sie verraten Dateipfade und Versionen. Mit WP_DEBUG_DISPLAY auf false und gesperrtem Zugriff auf debug.log ist die Protokollierung unproblematisch.
Muss ich mich um jede Notice kümmern?
Nein. In jeder gewachsenen Installation gibt es dutzende harmlose Notices. Wichtig sind Fatal errors und Warnungen, die zeitlich zu deinem Problem passen.
Sollte ich den Debug-Modus dauerhaft anlassen?
Nein. Nach der Fehlersuche abschalten und debug.log löschen, sonst wächst die Datei unbemerkt und kann den Webspace füllen. Dauerhaft gehört sie nur in eine Testumgebung.
Was ist der Unterschied zu Query Monitor?
Das Protokoll zeigt Fehler, Query Monitor zeigt, wo Zeit verloren geht: Ladezeit, Datenbankabfragen je Plugin und Anfragen an fremde Server. Für Tempoprobleme ist es die bessere Wahl.
Das bin ich – rechts im BildErzähl mir, was nicht funktioniert.
Domain und eine kurze Beschreibung reichen — du bekommst eine ehrliche Einschätzung, was los ist und was die Behebung kostet.
Antwort meist innerhalb von 24 Stunden · hallo@manuelkillert.de