Wie man Fehlerprotokolle für WordPress erstellt und darauf zugreift (3 Methoden)

WordPress-Fehlerprotokolle sind Diagnoseaufzeichnungen, die PHP-Fehler, schwerwiegende Ausnahmen, Datenbankfehler, Plugin-Konflikte und Theme-Inkompatibilitäten erfassen, sobald diese auf Ihrem Server auftreten. Der Zugriff auf diese Protokolle und deren Interpretation ist der schnellste Weg, die Ursache einer defekten Seite, eines weißen Bildschirms des Todes oder einer stillen Leistungsregression zu identifizieren – ohne zu raten oder Plugins einzeln zu deaktivieren.

Dieser Leitfaden behandelt drei praxiserprobte Methoden zum Aktivieren, Auffinden und Lesen von WordPress-Fehlerprotokollen: den nativen WP_DEBUG-Stack, serverseitige Protokolle über Ihr Hosting-Kontrollpanel und plugin-basierte Protokoll-Viewer. Jede Methode eignet sich für eine andere Zugriffsebene und einen anderen Anwendungsfall, und alle drei werden mit genauen Dateipfaden, Konfigurationssyntax und Sicherheitsüberlegungen erläutert.

Warum WordPress-Fehlerprotokolle wichtig sind

WordPress läuft auf PHP, das verschiedene Klassen von Laufzeitmeldungen erzeugt: schwerwiegende Fehler (Ausführung stoppt), Warnungen (Ausführung wird fortgesetzt, aber etwas stimmt nicht), Hinweise (informativ, weisen oft auf veralteten Code hin) und veraltete Meldungen (Funktionen, die zur Entfernung vorgesehen sind). Standardmäßig werden diese in den meisten Produktionskonfigurationen nicht in ein dauerhaftes Protokoll geschrieben – sie werden entweder unterdrückt oder an den Browser ausgegeben, was ein Sicherheitsrisiko darstellt.

Ohne ein Protokoll erzeugt ein Plugin-Update, das einen schwerwiegenden Fehler einführt, nur einen leeren Bildschirm. Eine falsch konfigurierte SMTP-Bibliothek verwirft E-Mails stillschweigend. Eine Überschreitung des Speicherlimits beendet einen Seitenaufruf ohne sichtbare Spur. Fehlerprotokolle wandeln diese unsichtbaren Fehler in zeitgestempelte, dateireferenzierte, zeilennummerierte Einträge um, auf die Sie sofort reagieren können.

Methode 1: WordPress-Debug-Modus über wp-config.php aktivieren

WordPress wird mit einem integrierten Debugging-Subsystem geliefert, das durch eine Reihe von PHP-Konstanten gesteuert wird, die in wp-config.php definiert sind. Dies ist die präziseste Methode, da sie WordPress-spezifische Fehler erfasst, einschließlich solcher, die von der Plugin-API, dem Theme-Loader und der Datenbankabstraktionsschicht (wpdb) ausgelöst werden.

Schritt 1: wp-config.php finden und öffnen

Verbinden Sie sich mit Ihrem Server über SFTP (aus Sicherheitsgründen gegenüber einfachem FTP bevorzugt) mit einem Client wie FileZilla oder Cyberduck, oder öffnen Sie den Dateimanager Ihres Hosting-Anbieters. Navigieren Sie zum WordPress-Stammverzeichnis, typischerweise /public_html/ oder /var/www/html/. Die Datei wp-config.php befindet sich im Stammverzeichnis dieses Ordners.

Wenn Sie SSH-Zugang haben, können Sie sie direkt bearbeiten:

nano /var/www/html/wp-config.php

Schritt 2: Die Debug-Konstanten konfigurieren

Suchen Sie die vorhandene Zeile:

define( 'WP_DEBUG', false );

Ersetzen Sie den gesamten Block durch die folgende Konfiguration, die die Protokollierung aktiviert, ohne Fehler für Website-Besucher sichtbar zu machen:

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

Was jede Konstante bewirkt:

• WP_DEBUG — aktiviert die WordPress-Debugging-Engine und ermöglicht PHP-Fehlerberichterstattung auf der E_ALL-Ebene.
• WP_DEBUG_LOG — schreibt alle erfassten Fehler in eine Protokolldatei anstatt (oder zusätzlich) auf dem Bildschirm.
• WP_DEBUG_DISPLAY — wenn auf false gesetzt, unterdrückt die Bildschirmausgabe. Dies ist auf Produktionsseiten entscheidend; ohne diese Einstellung geben PHP-Hinweise interne Dateipfade und Variablennamen an Besucher weiter.
• display_errors — die zugrunde liegende PHP-Direktive; das Setzen auf 0 über ini_set bietet eine zweite Unterdrückungsebene, falls ein Plugin oder Theme WP_DEBUG_DISPLAY überschreibt.

Schritt 3: Die Debug-Protokolldatei finden

Wenn WP_DEBUG_LOG auf true gesetzt ist, schreibt WordPress Fehler in:

/wp-content/debug.log

Diese Datei wird automatisch beim ersten protokollierten Fehler erstellt. Sie können sie über SFTP oder SSH einsehen:

tail -f /var/www/html/wp-content/debug.log

Das Flag tail -f streamt neue Einträge in Echtzeit, was beim interaktiven Reproduzieren eines bestimmten Fehlers unschätzbar wertvoll ist.

Schritt 4: Einen benutzerdefinierten Protokollpfad verwenden (aus Sicherheitsgründen empfohlen)

Der standardmäßige debug.log-Pfad ist öffentlich zugänglich, wenn Ihr Webserver ihn nicht explizit blockiert. Ein falsch konfigurierter Server stellt https://yourdomain.com/wp-content/debug.log jedem Besucher zur Verfügung und legt dabei interne Pfade, Datenbanktabellen-Präfixe und Klassennamen offen.

Option A — Protokolldatei außerhalb des Web-Stammverzeichnisses verschieben:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );

Erstellen Sie das Zielverzeichnis und setzen Sie die Berechtigungen:

mkdir -p /var/log/wordpress
chown www-data:www-data /var/log/wordpress
chmod 750 /var/log/wordpress

Option B — Den Standardpfad über .htaccess blockieren (Apache):

<Files "debug.log">
    Order allow,deny
    Deny from all
</Files>

Option C — Nginx-Äquivalent in Ihrem Server-Block:

location ~* /wp-content/debug.log {
    deny all;
    return 404;
}

Schritt 5: Debug-Modus nach der Fehlerbehebung deaktivieren

Lassen Sie WP_DEBUG niemals länger als nötig auf true auf einer Live-Website gesetzt. Sobald das Problem behoben ist:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Das Aktivlassen des Debug-Modus auf einer Produktionsseite beeinträchtigt die Leistung (PHP verarbeitet jeden E_ALL-Hinweis) und kann sensible Stack-Traces offenlegen, wenn WP_DEBUG_DISPLAY versehentlich auf true gesetzt wird.

Methode 2: Serverseitige Fehlerprotokolle über Ihr Hosting-Kontrollpanel aufrufen

WordPress-Fehler, die auftreten, bevor der WordPress-Bootstrap abgeschlossen ist – wie eine beschädigte wp-config.php, eine PHP-Versionsinkompatibilität oder eine fehlgeschlagene Datenbankverbindung – werden niemals in debug.log erscheinen, da WordPress selbst nie geladen wird. Dafür benötigen Sie das PHP-Fehlerprotokoll des Servers oder das Apache/Nginx-Fehlerprotokoll.

cPanel-basiertes Hosting

Wenn Ihre Hosting-Umgebung VPS mit cPanel verwendet, ist das Fehlerprotokoll über die Kontrollpanel-Oberfläche zugänglich:

1. Melden Sie sich bei cPanel an.
2. Navigieren Sie zu Metriken > Fehler.
3. Das Panel zeigt die letzten 300 Zeilen des Apache-Fehlerprotokolls für Ihr Konto an.

Für die vollständige Protokolldatei verwenden Sie den Dateimanager von cPanel oder verbinden Sie sich über SFTP und navigieren Sie zu:

/home/yourusername/logs/yourdomain.com-ssl_log
/home/yourusername/logs/yourdomain.com-error_log

Die genauen Dateinamen variieren je nach Serverkonfiguration, aber das Muster ist bei den meisten cPanel-Installationen konsistent.

Plesk-basiertes Hosting

Navigieren Sie in Plesk zu Websites & Domains > wählen Sie Ihre Domain > Protokolle. Sie können nach Protokolltyp (Zugriff, Fehler, PHP) filtern und die vollständige Protokolldatei herunterladen.

Direkter Serverzugriff (VPS oder Dedicated)

In einer VPS Hosting– oder Dedicated Server-Umgebung, in der Sie Root-Zugriff haben, hängen die Protokollspeicherorte von Ihrem Stack ab:

So überwachen Sie das PHP-FPM-Protokoll in Echtzeit:

tail -f /var/log/php8.2-fpm.log

So suchen Sie nach WordPress-spezifischen schwerwiegenden Fehlern im Apache-Protokoll:

grep -i "fatal|wordpress|wp-" /var/log/apache2/error.log | tail -50

PHP-Fehlerprotokollierung auf Serverebene konfigurieren

Wenn PHP-Fehler nicht in ein Protokoll geschrieben werden, überprüfen Sie Ihre php.ini-Konfiguration:

php --ini | grep "Loaded Configuration"

Öffnen Sie die identifizierte php.ini-Datei und überprüfen oder setzen Sie:

log_errors = On
error_log = /var/log/php_errors.log
display_errors = Off
error_reporting = E_ALL

Starten Sie PHP-FPM nach Änderungen neu:

systemctl restart php8.2-fpm

Alternativ können Sie PHP-Einstellungen pro Website mit einer .htaccess-Datei überschreiben (nur Apache):

php_flag log_errors on
php_value error_log /var/log/wordpress/php_errors.log
php_flag display_errors off

Methode 3: Ein WordPress-Fehlerprotokollierungs-Plugin verwenden

Für Umgebungen, in denen der direkte Serverzugriff eingeschränkt ist – wie bei Shared Web Hosting – oder für Teams, in denen nicht-technische Administratoren Fehler ohne SSH-Zugang überprüfen müssen, bietet ein WordPress-Plugin eine praktikable Alternative.

Empfohlene Plugins

• WP Log Viewer — liest die vorhandene debug.log-Datei und zeigt sie im WordPress-Admin mit Filterung und Suche an.
• Error Log Monitor — fügt ein Dashboard-Widget hinzu, das aktuelle Fehler anzeigt, und kann E-Mail-Benachrichtigungen senden, wenn neue Fehler protokolliert werden.
• Query Monitor — geht über die Fehlerprotokollierung hinaus und erstellt Profile von Datenbankabfragen, HTTP-API-Aufrufen, Hooks und bedingten Tags. Unverzichtbar für die Leistungsanalyse.
• Health Check & Troubleshooting — das offizielle Plugin von WordPress.org; aktiviert einen Fehlerbehebungsmodus, der ein Standard-Theme aktiviert und alle Plugins nur für Ihre Sitzung deaktiviert, ohne andere Besucher zu beeinträchtigen.

Error Log Monitor installieren und konfigurieren

1. Gehen Sie im WordPress-Admin zu Plugins > Neu hinzufügen.
2. Suchen Sie nach Error Log Monitor und klicken Sie auf Jetzt installieren, dann auf Aktivieren.
3. Navigieren Sie zu Einstellungen > Error Log Monitor.
4. Legen Sie den Protokolldateipfad fest. Wenn Sie debug.log außerhalb des Web-Stammverzeichnisses verschoben haben, geben Sie hier den absoluten Serverpfad ein.
5. Konfigurieren Sie die E-Mail-Benachrichtigungshäufigkeit, wenn Sie Benachrichtigungen für neue Fehlertypen wünschen.

Das Plugin liest dieselbe debug.log-Datei, in die WP_DEBUG_LOG schreibt. Es erstellt keinen separaten Protokollierungsmechanismus – es ist ein Viewer. Das bedeutet, dass WP_DEBUG und WP_DEBUG_LOG weiterhin in wp-config.php aktiviert sein müssen, damit das Plugin etwas anzeigt.

Kritische Einschränkung: Plugins werden geladen, nachdem WordPress gestartet wurde. Jeder Fehler, der das Laden von WordPress verhindert (Datenbankverbindungsfehler, beschädigte Core-Datei, inkompatible PHP-Version), ist in keinem plugin-basierten Protokoll-Viewer sichtbar. Für diese Szenarien ist Methode 2 die einzige Option.

Vergleich: Drei WordPress-Fehlerprotokollierungsmethoden

WordPress-Fehlerprotokolleinträge lesen und interpretieren

Ein roher debug.log-Eintrag sieht folgendermaßen aus:

[04-Jul-2025 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mytheme/functions.php:47
Stack trace:
#0 /var/www/html/wp-content/themes/mytheme/functions.php(47): get_field()
#1 {main}
thrown in /var/www/html/wp-content/themes/mytheme/functions.php on line 47

So lesen Sie diesen Eintrag:

• Der Zeitstempel ist in UTC – konvertieren Sie ihn bei Bedarf in die lokale Zeitzone Ihres Servers.
• PHP Fatal error bedeutet, dass die Ausführung gestoppt wurde. Die Seite, die dies ausgelöst hat, hat einen 500-Fehler oder einen leeren Bildschirm zurückgegeben.
• Call to undefined function get_field() bedeutet, dass das Advanced Custom Fields-Plugin entweder deaktiviert ist oder nach dem functions.php des Themes geladen wird, das versucht hat, es aufzurufen.
• Der Stack-Trace zeigt die genaue Datei und Zeilennummer. Beginnen Sie mit der Fehlersuche in Zeile 47 von functions.php.

Häufige Fehlermuster und ihre Ursachen:

• PHP Warning: require(): Failed opening required — ein Dateipfad ist falsch oder eine Datei fehlt. Wird oft durch ein Plugin verursacht, das auf eine gelöschte Datei verweist.
• PHP Deprecated: Function _register_controls is deprecated — ein Plugin oder Theme verwendet eine veraltete API. Nicht schwerwiegend, weist aber auf ein Plugin hin, das für die aktuelle WordPress/Elementor-Version nicht aktualisiert wurde.
• WordPress database error ... for query — eine wpdb-Abfrage ist fehlgeschlagen. Prüfen Sie auf Tabellenpräfix-Unstimmigkeiten oder beschädigte Tabellen.
• Maximum execution time of 30 seconds exceeded — ein Skript lief zu lange. Häufig bei großen Importen, nicht optimierten Abfragen oder externen API-Aufrufen, die eine Zeitüberschreitung haben.
• Allowed memory size of X bytes exhausted — PHP hat das Speicherlimit erreicht. Erhöhen Sie memory_limit in php.ini oder identifizieren Sie das speicherleckende Plugin.

Best Practices für die Verwaltung von WordPress-Fehlerprotokollen

Protokolle rotieren, um Festplattenerschöpfung zu verhindern. Eine stark frequentierte WordPress-Website unter Angriff oder mit einem wiederkehrenden Fehler kann täglich Hunderte von Megabytes an Protokolldaten erzeugen. Konfigurieren Sie auf Linux-Servern logrotate:

nano /etc/logrotate.d/wordpress-debug

/var/log/wordpress/debug.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
}

Committen Sie debug.log niemals in die Versionskontrolle. Fügen Sie es zu .gitignore hinzu:

wp-content/debug.log

Überprüfen Sie Ihre wp-config.php nach jeder Servermigration. Hosting-Migrationen setzen WP_DEBUG häufig auf false zurück oder führen eine neue wp-config.php-Vorlage ein, die Ihre Konstanten überschreibt.

Verwenden Sie SAVEQUERIES für das Debugging auf Datenbankebene. Fügen Sie diese Konstante zusammen mit WP_DEBUG hinzu, um jede SQL-Abfrage zu protokollieren, die WordPress ausführt:

define( 'SAVEQUERIES', true );

Überprüfen Sie dann $wpdb->queries in einer benutzerdefinierten Vorlage oder über Query Monitor. Deaktivieren Sie es sofort nach der Verwendung – es speichert jede Abfrage im Speicher und erhöht den RAM-Verbrauch erheblich.

Korrelieren Sie Protokoll-Zeitstempel mit Deployment-Ereignissen. Wenn ein neuer Fehlertyp auftritt, prüfen Sie, ob er mit einem Plugin-Update, einem WordPress-Core-Update oder einer PHP-Versionsänderung auf dem Server zusammenfällt. Die meisten Hosting-Kontrollpanels protokollieren PHP-Versionsänderungen in einem separaten Audit-Trail.

Entscheidungsmatrix: Welche Methode verwenden

Technische Checkliste der wichtigsten Erkenntnisse

• Setzen Sie WP_DEBUG_DISPLAY auf false, bevor Sie WP_DEBUG_LOG auf einer Website mit Live-Traffic aktivieren.
• Verschieben Sie debug.log außerhalb des Web-Stammverzeichnisses oder blockieren Sie es über Server-Regeln – der Standardpfad ist öffentlich zugänglich.
• Verwenden Sie tail -f auf der Protokolldatei beim interaktiven Reproduzieren von Fehlern; dies eliminiert die Notwendigkeit, die Datei manuell zu aktualisieren.
• Serverseitige PHP- und Apache/Nginx-Protokolle sind die einzige Wahrheitsquelle für Fehler, die auftreten, bevor WordPress geladen wird.
• Plugin-basierte Protokoll-Viewer erfordern, dass WP_DEBUG_LOG aktiv ist – sie sind Leser, keine Schreiber.
• Implementieren Sie Log-Rotation auf jedem Server, auf dem WP_DEBUG_LOG länger als ein paar Stunden aktiviert ist.
• Lassen Sie SAVEQUERIES niemals in der Produktion aktiviert; es ist eine Speicher- und Leistungsbelastung.
• Setzen Sie nach der Behebung eines Problems alle Debug-Konstanten zurück auf false und überprüfen Sie mit einer Browser-Anfrage, dass keine PHP-Hinweise im Seitenquelltext erscheinen.

—

Häufig gestellte Fragen

Wo befindet sich die WordPress-Debug-Protokolldatei standardmäßig?

WordPress schreibt das Debug-Protokoll in /wp-content/debug.log relativ zu Ihrem WordPress-Stammverzeichnis. Dieser Pfad wird erst nach dem ersten protokollierten Fehler erstellt und nur wenn sowohl WP_DEBUG als auch WP_DEBUG_LOG in wp-config.php auf true gesetzt sind. Sie können den Pfad überschreiben, indem Sie einen absoluten Dateipfad-String als Wert von WP_DEBUG_LOG anstelle von true angeben.

Ist es sicher, WP_DEBUG auf einer Live-Produktionsseite zu aktivieren?

Es ist nur sicher, wenn WP_DEBUG_DISPLAY explizit auf false gesetzt ist und display_errors auf 0 gesetzt ist. Ohne diese beiden Einstellungen werden PHP-Fehler – einschließlich interner Dateipfade und Datenbanktabellennamen – direkt im HTML-Quelltext jeder Seite gerendert. Kombinieren Sie WP_DEBUG true immer mit WP_DEBUG_DISPLAY false auf jeder Website mit öffentlichem Traffic.

Warum ist meine debug.log-Datei leer, obwohl WP_DEBUG aktiviert ist?

Die häufigsten Ursachen sind: Der Webserver-Prozess hat keine Schreibberechtigung für das /wp-content/-Verzeichnis; WP_DEBUG_LOG ist auf false gesetzt oder fehlt in wp-config.php; oder der Fehler tritt auf Serverebene auf, bevor WordPress geladen wird, was bedeutet, dass er im Apache- oder PHP-FPM-Protokoll statt in debug.log erscheint. Überprüfen Sie die Verzeichnisberechtigungen mit ls -la wp-content/ und stellen Sie sicher, dass die Konstanten in der richtigen Reihenfolge in wp-config.php definiert sind.

Was ist der Unterschied zwischen WP_DEBUG_LOG und dem PHP-Fehlerprotokoll des Servers?

WP_DEBUG_LOG ist eine WordPress-Konstante, die Fehler, die vom benutzerdefinierten Fehler-Handler von WordPress erfasst werden, an debug.log weiterleitet. Das PHP-Fehlerprotokoll des Servers (konfiguriert über error_log in php.ini) erfasst alle PHP-Fehler auf Interpreter-Ebene, einschließlich solcher, die auftreten, bevor WordPress initialisiert wird. Auf einem ordnungsgemäß konfigurierten Server sind beide Protokolle gleichzeitig aktiv und ergänzen sich gegenseitig.

Kann ich die Fehlerprotokollierung auf Shared Hosting ohne SSH-Zugang aktivieren?

Ja. Sie können wp-config.php über den Dateimanager Ihres Hosting-Anbieters in cPanel oder Plesk bearbeiten, WP_DEBUG und WP_DEBUG_LOG aktivieren und dann debug.log über dieselbe Dateimanager-Oberfläche lesen. Für serverseitige Protokolle auf Shared Web Hosting verwenden Sie den Abschnitt Fehler unter Metriken in cPanel. Wenn Sie mehr Kontrolle über PHP-Konfiguration und Protokollpfade benötigen, gibt Ihnen ein Upgrade auf einen VPS Hosting-Plan direkten Zugriff auf php.ini und vollständigen SSH-Zugang zu allen Protokolldateien.