cPanel Error Log lesen und Website-Fehler finden

Wenn eine Website einen Fehler zeigt, ist die sichtbare Meldung im Browser häufig nur ein Symptom. Das eigentliche Problem kann beispielsweise durch PHP, eine Anwendung, falsche Dateipfade, Berechtigungen oder eine fehlerhafte Serverkonfiguration verursacht werden.

Im CURIAWEB-cPanel findest du unter Messwerte → Fehler aktuelle Einträge aus dem Fehlerprotokoll des Webservers. Diese Meldungen können entscheidende Hinweise darauf geben, wann, wo und warum ein Fehler aufgetreten ist.

In dieser Anleitung zeigen wir dir, wie du das cPanel Error Log aufrufst, typische Fehlermeldungen liest und daraus die nächsten sinnvollen Schritte für die Fehlersuche ableitest.

Wichtig: Eine Fehlermeldung sollte nicht nur nach einzelnen Begriffen durchsucht werden. Zeitstempel, Dateipfad, Zeilennummer und Fehlertext gehören zusammen. Erst der vollständige Kontext zeigt häufig, welche Datei oder Anwendung tatsächlich betroffen ist.

Was ist das cPanel Error Log? #

Webserver und Anwendungen protokollieren bestimmte Fehler, die bei der Verarbeitung einer Website auftreten.

Im cPanel-Bereich Fehler kannst du aktuelle Einträge aus dem Webserver-Fehlerprotokoll einsehen.

Solche Einträge können beispielsweise Hinweise enthalten auf:

• PHP-Fehler
• nicht gefundene Dateien
• falsche Dateipfade
• Berechtigungsprobleme
• fehlerhafte Konfigurationen
• Probleme mit PHP-Skripten
• bestimmte Apache-/Webserver-Meldungen

Das Error Log ist deshalb eines der wichtigsten Werkzeuge bei der Diagnose einer Website, die plötzlich nicht mehr korrekt funktioniert.

Was das Error Log nicht ist #

Das cPanel Error Log ist keine vollständige Historie sämtlicher Vorgänge innerhalb deines Hosting-Accounts.

Es zeigt auch nicht automatisch:

• jeden Fehler jeder Anwendung
• sämtliche WordPress-Fehler
• alle Datenbankfehler
• alle Cronjob-Ausgaben
• sämtliche Zugriffe auf deine Website

Je nach Fehlerart können andere Logs oder Diagnosewerkzeuge relevant sein.

Kurz erklärt: Das Error Log ist ein wichtiger Ausgangspunkt – aber nicht jedes technische Problem muss dort protokolliert werden.

1. cPanel Error Log öffnen #

Melde dich bei deinem CURIAWEB-cPanel an.

Öffne anschließend:

Messwerte → Fehler

cPanel zeigt dir dort aktuelle Einträge aus dem Fehlerprotokoll.

2. Fehler zuerst reproduzieren #

Wenn ein bestimmter Fehler reproduzierbar ist, solltest du die betroffene Seite unmittelbar vor der Kontrolle des Logs erneut aufrufen.

Beispiel:

13:42 Uhr
→ fehlerhafte Seite aufrufen

13:43 Uhr
→ cPanel → Messwerte → Fehler öffnen

Dadurch kannst du aktuelle Logeinträge zeitlich wesentlich leichter dem gerade ausgelösten Fehler zuordnen.

Praxis-Tipp: Notiere dir die genaue Uhrzeit, zu der du den Fehler ausgelöst hast. Gerade auf Websites mit vielen Zugriffen können innerhalb kurzer Zeit zahlreiche unterschiedliche Meldungen entstehen.

3. Nicht automatisch den neuesten Eintrag für die Ursache halten #

Der zeitlich neueste Logeintrag muss nicht zwangsläufig zu deinem Problem gehören.

Eine Website kann beispielsweise gleichzeitig von:

• Besuchern
• Suchmaschinen
• Bots
• Monitoring-Systemen
• anderen Anwendungen

aufgerufen werden.

Prüfe deshalb zusätzlich zum Zeitstempel immer den betroffenen Pfad beziehungsweise die angegebene Datei.

Wie ist eine Fehlermeldung aufgebaut? #

Der genaue Aufbau hängt von der Art des Fehlers ab. Ein Logeintrag kann jedoch Informationen wie diese enthalten:

Zeitstempel
Fehlerart
Fehlertext
Dateipfad
Zeilennummer
weitere technische Informationen

Ein schematisches PHP-Beispiel könnte so aussehen:

PHP Fatal error:
Uncaught Error: ...
in /home/CPANELUSER/public_html/example.php
on line 125

Für die Fehlersuche sind dabei mehrere Bestandteile relevant.

Zeitstempel #

Der Zeitstempel hilft dir festzustellen, ob die Meldung tatsächlich zu dem Zeitpunkt entstanden ist, an dem du das Problem beobachtet hast.

Eine Meldung von gestern ist normalerweise kein Beweis für einen Fehler, den du gerade erst ausgelöst hast.

Fehlerart #

Die Fehlerart gibt einen ersten Hinweis auf die Schwere und Kategorie des Problems.

Beispiele:

PHP Fatal error
PHP Warning
PHP Notice
Permission denied
File not found

Diese Meldungen bedeuten nicht dasselbe und sollten deshalb unterschiedlich behandelt werden.

Fehlertext #

Der eigentliche Fehlertext beschreibt, was bei der Verarbeitung schiefgelaufen ist.

Beispiele können sein:

Call to undefined function ...
Class ... not found
Failed opening required ...
Permission denied
Allowed memory size ... exhausted

Der Fehlertext ist häufig der wichtigste Teil für die technische Einordnung.

Dateipfad #

Der angegebene Dateipfad zeigt häufig, welche Datei am Fehler beteiligt war.

Beispielsweise:

/home/CPANELUSER/public_html/wp-content/plugins/example/plugin.php

Aus einem solchen Pfad lässt sich bereits erkennen, dass sich die betroffene Datei innerhalb eines WordPress-Plugins befindet.

Wichtig: Ein Dateipfad zeigt, wo der Fehler ausgelöst beziehungsweise erkannt wurde. Das bedeutet nicht in jedem Fall, dass genau diese Datei allein die eigentliche Ursache ist.

Zeilennummer #

PHP-Fehlermeldungen können zusätzlich eine Zeilennummer enthalten:

on line 125

Damit lässt sich die betreffende Stelle innerhalb der Datei lokalisieren.

Die Zeilennummer ist vor allem für Entwickler oder bei eigenem Code hilfreich. Bei einem fremden Plugin oder Theme solltest du nicht einfach die betreffende Codezeile löschen oder verändern.

PHP Fatal Error verstehen #

Ein:

PHP Fatal error

bedeutet, dass PHP die betreffende Ausführung wegen eines schwerwiegenden Fehlers nicht fortsetzen konnte.

Das kann beispielsweise dazu führen, dass:

• eine Seite nicht geladen wird
• nur eine leere Seite erscheint
• WordPress einen kritischen Fehler meldet
• ein HTTP-500-Fehler entsteht

Entscheidend ist der Text, der nach PHP Fatal error folgt.

„Uncaught Error“ verstehen #

Eine Meldung wie:

Uncaught Error: ...

weist darauf hin, dass während der PHP-Ausführung ein Fehler aufgetreten ist, der von der Anwendung nicht abgefangen wurde.

Beispielsweise kann eine benötigte Funktion oder Klasse fehlen.

Die Meldung sollte immer zusammen mit dem nachfolgenden Dateipfad und der Zeilennummer betrachtet werden.

„Call to undefined function“ #

Eine Meldung wie:

Call to undefined function example()

bedeutet, dass PHP eine aufgerufene Funktion nicht kennt beziehungsweise zum Zeitpunkt des Aufrufs nicht verfügbar ist.

Mögliche Ursachen können sein:

• fehlende PHP-Erweiterung
• nicht geladene Anwendungsdatei
• inkompatibler Code
• fehlerhaftes Plugin oder Theme
• Versionskonflikt

Wenn die Funktion zu einer PHP-Erweiterung gehört, kann der Artikel PHP-Erweiterungen in cPanel aktivieren und verwalten weiterhelfen.

„Class not found“ #

Eine Meldung wie:

Class "Example" not found

bedeutet, dass eine Anwendung eine PHP-Klasse verwenden möchte, die zu diesem Zeitpunkt nicht verfügbar ist.

Das kann beispielsweise durch:

• fehlende Dateien
• unvollständige Updates
• fehlerhafte Abhängigkeiten
• inkompatible Plugins
• fehlerhaften individuellen Code

verursacht werden.

Bei einer WordPress-Website kann der Dateipfad häufig bereits zeigen, welches Plugin oder Theme beteiligt ist.

„Failed opening required“ #

Eine Meldung wie:

Failed opening required '/pfad/datei.php'

weist darauf hin, dass PHP eine benötigte Datei nicht erfolgreich laden konnte.

Prüfe insbesondere:

• existiert die Datei?
• stimmt der Pfad?
• wurde die Datei verschoben oder gelöscht?
• war ein Update unvollständig?
• stimmen die Berechtigungen?

Mit dem cPanel-Dateimanager kannst du den angegebenen Pfad kontrollieren.

„No such file or directory“ #

Eine Meldung wie:

No such file or directory

bedeutet grundsätzlich, dass eine erwartete Datei oder ein Verzeichnis unter dem angegebenen Pfad nicht gefunden wurde.

Das kann beispielsweise nach einer Migration, einem manuellen Verschieben von Dateien oder einem fehlerhaften Update auftreten.

„Permission denied“ #

Eine Meldung wie:

Permission denied

weist darauf hin, dass ein benötigter Zugriff aufgrund der vorhandenen Berechtigungen nicht möglich war.

Prüfe in diesem Fall zunächst:

• welche Datei oder welches Verzeichnis betroffen ist
• welcher Zugriff versucht wurde
• ob die vorhandenen Dateiberechtigungen plausibel sind

Grundlagen findest du unter Dateiberechtigungen 644 und 755 in cPanel richtig einstellen.

Achtung: Setze Dateiberechtigungen nicht pauschal auf 777, nur um eine Fehlermeldung verschwinden zu lassen. Das löst die Ursache nicht sauber und kann die Sicherheit der Website verschlechtern.

„Allowed memory size exhausted“ #

Eine häufige PHP-Fehlermeldung lautet sinngemäß:

Allowed memory size of ... bytes exhausted

PHP hat in diesem Fall das für den Prozess verfügbare Speicherlimit erreicht.

Die Meldung enthält häufig zusätzlich:

• das verfügbare Speicherlimit
• die zusätzlich angeforderte Speichermenge
• die betroffene Datei
• eine Zeilennummer

Wie du PHP-Speicher und weitere Limits einordnest, erklären wir unter PHP Memory Limit, Upload-Größe und Ausführungszeit einstellen.

Memory Limit nicht einfach unbegrenzt erhöhen #

Wenn eine Anwendung ungewöhnlich viel Speicher benötigt, kann ein höheres Limit zwar erforderlich sein – es kann aber auch lediglich ein Symptom verdecken.

Beispiele für einen ungewöhnlich hohen Speicherverbrauch können sein:

• fehlerhaftes Plugin
• extrem große Datenmenge
• Endlosschleife
• problematischer Import
• ungeeignete Anwendungskonfiguration

Prüfe deshalb auch den Kontext des Fehlers.

„Maximum execution time exceeded“ #

Eine Meldung wie:

Maximum execution time of ... seconds exceeded

bedeutet, dass ein PHP-Prozess länger gelaufen ist als für diese PHP-Umgebung erlaubt.

Das kann beispielsweise bei:

• großen Importen
• aufwendigen Exporten
• langsamen externen Verbindungen
• umfangreichen Datenbankoperationen
• problematischem Anwendungscode

auftreten.

Auch hier sollte das Limit nicht blind erhöht werden. Prüfe zuerst, welcher Prozess betroffen ist.

PHP Warning verstehen #

Eine:

PHP Warning

ist grundsätzlich nicht dasselbe wie ein Fatal Error.

PHP kann die Verarbeitung bei vielen Warnungen fortsetzen.

Trotzdem können Warnungen auf Fehler oder veraltete beziehungsweise problematische Programmierung hinweisen.

Wenn dieselbe Warning sehr häufig auftritt, kann sie außerdem Logdateien unnötig vergrößern.

PHP Notice und Deprecated-Meldungen #

Meldungen wie:

PHP Notice

oder:

PHP Deprecated

sind ebenfalls von einem Fatal Error zu unterscheiden.

Eine Deprecated-Meldung weist typischerweise darauf hin, dass Code eine Funktion oder Vorgehensweise verwendet, die als veraltet gilt und künftig möglicherweise nicht mehr unterstützt wird.

Solche Meldungen treten beispielsweise nach einem Wechsel auf eine neuere PHP-Version häufiger bei älteren Anwendungen, Plugins oder Themes auf.

Viele Deprecated-Meldungen nach PHP-Wechsel #

Wenn unmittelbar nach einem PHP-Wechsel zahlreiche Deprecated-Meldungen erscheinen, solltest du prüfen, ob die betreffende Anwendung vollständig mit der neuen PHP-Version kompatibel ist.

Die PHP-Version deiner Domain verwaltest du bei CURIAWEB grundsätzlich über den MultiPHP-Manager.

Stelle nicht wahllos mehrere PHP-Versionen nacheinander ein. Prüfe zuerst die Systemanforderungen der verwendeten Software.

Fehlermeldung zeigt auf ein WordPress-Plugin #

Ein WordPress-Pfad kann beispielsweise so aussehen:

/home/CPANELUSER/public_html/wp-content/plugins/example-plugin/file.php

Der Bereich:

/wp-content/plugins/example-plugin/

zeigt, dass die Datei zu einem Plugin gehört.

Wenn ein Fatal Error dort ausgelöst wird, gehört dieses Plugin zu den ersten Komponenten, die du untersuchen solltest.

Das bedeutet jedoch nicht automatisch, dass das Plugin allein schuld ist. Auch ein Konflikt mit einem anderen Plugin, Theme, PHP oder WordPress selbst kann beteiligt sein.

Fehlermeldung zeigt auf ein WordPress-Theme #

Ein Pfad wie:

/wp-content/themes/example-theme/...

weist darauf hin, dass sich die betroffene Datei innerhalb eines Themes befindet.

Prüfe dann insbesondere:

• wurde das Theme gerade aktualisiert?
• wurde PHP geändert?
• wurde WordPress aktualisiert?
• trat der Fehler unmittelbar nach einer Theme-Anpassung auf?
• handelt es sich um individuellen Code?

Fehlermeldung zeigt auf wp-content, aber Ursache kann woanders liegen #

Bei WordPress greifen Core, Plugins und Themes ständig ineinander.

Ein Fehler kann deshalb beispielsweise in Plugin A sichtbar werden, obwohl eine von Plugin B verursachte Änderung den problematischen Zustand ausgelöst hat.

Betrachte den Dateipfad deshalb als wichtigen Hinweis – nicht als automatischen Schuldbeweis.

Stack Trace verstehen #

Bei bestimmten PHP-Fehlern wird zusätzlich ein sogenannter Stack Trace protokolliert.

Dieser zeigt vereinfacht, welche Funktionen beziehungsweise Dateien aufgerufen wurden, bevor der Fehler entstanden ist.

Schematisch:

#0 Datei A → Funktion X
#1 Datei B → Funktion Y
#2 Datei C → Funktion Z
#3 Hauptaufruf

Ein Stack Trace kann sehr wertvoll sein, weil er den Weg bis zum eigentlichen Fehler zeigt.

Bei einem Stack Trace nicht nur die letzte Zeile lesen #

Ein Stack Trace enthält mehrere beteiligte Aufrufe.

Die erste sichtbare Datei oder die letzte Zeile ist deshalb nicht automatisch die Ursache.

Bei WordPress kann beispielsweise ein Plugin eine WordPress-Core-Funktion aufrufen, in der der Fehler schließlich sichtbar wird.

Für die Diagnose ist die gesamte Aufrufkette relevant.

„thrown in … on line …“ #

Bei PHP-Fatal-Errors kann am Ende einer Meldung beispielsweise stehen:

thrown in /home/CPANELUSER/public_html/example.php on line 125

Diese Angabe zeigt, an welcher Stelle die Ausnahme beziehungsweise der Fehler letztlich ausgelöst wurde.

Dokumentiere diese Zeile zusammen mit dem vorhergehenden Fehlertext.

Fehlende Datei nach Plugin- oder Theme-Update #

Wenn unmittelbar nach einem Update Meldungen über fehlende Dateien auftreten, kann das Update unvollständig oder eine Installation beschädigt sein.

Lösche in diesem Fall nicht wahllos einzelne Dateien.

Prüfe zunächst:

• welche Komponente betroffen ist
• ob das Update vollständig abgeschlossen wurde
• ob eine aktuelle Sicherung vorhanden ist
• ob die Komponente sauber neu installiert beziehungsweise wiederhergestellt werden kann

HTTP 500 und Error Log #

Ein Browser zeigt bei einem serverseitigen Problem möglicherweise nur:

500 Internal Server Error

Diese Meldung allein sagt noch nicht, wodurch der Fehler verursacht wurde.

Das Error Log kann dazu beispielsweise einen konkreten PHP Fatal Error, eine fehlerhafte Konfiguration oder einen Berechtigungsfehler enthalten.

Die vollständige Diagnose behandeln wir unter 500 Internal Server Error beheben.

HTTP 403 und Error Log #

Bei einem:

403 Forbidden

kann das Error Log ebenfalls Hinweise liefern – beispielsweise im Zusammenhang mit Berechtigungen oder Zugriffsbeschränkungen.

Ein 403 kann jedoch auch durch andere Sicherheitsebenen entstehen.

Die systematische Fehlersuche behandeln wir unter 403 Forbidden beheben.

HTTP 503 und Error Log #

Ein:

503 Service Unavailable

kann unterschiedliche Ursachen haben.

Neben Anwendungsproblemen können dabei auch Ressourcen oder vorübergehend nicht verfügbare Dienste relevant sein.

Weitere Schritte findest du unter 503 Service Unavailable beheben.

.htaccess-Fehler erkennen #

Eine fehlerhafte .htaccess-Konfiguration kann dazu führen, dass eine Website nicht mehr korrekt verarbeitet wird.

Je nach Fehler kann das Protokoll Hinweise auf eine ungültige Direktive oder eine nicht erlaubte Konfiguration enthalten.

Wenn das Problem unmittelbar nach einer Änderung an .htaccess begonnen hat, solltest du diese Änderung zuerst prüfen.

Weitere Informationen findest du unter .htaccess erklärt und sicher bearbeiten.

„Invalid command“ nach .htaccess-Änderung #

Eine Meldung kann beispielsweise darauf hinweisen, dass eine Direktive nicht erkannt oder in diesem Kontext nicht erlaubt ist.

Wenn du kurz zuvor Code aus einer fremden Anleitung in .htaccess eingefügt hast, stelle den vorherigen Zustand wieder her und prüfe die verwendete Direktive.

Achtung: Füge keine zufälligen Apache- oder PHP-Anweisungen in .htaccess ein. Nicht jede Direktive ist in jeder Hosting- und PHP-Konfiguration zulässig.

PHP-Werte nicht blind über .htaccess setzen #

Bei modernen PHP-Konfigurationen können alte Anleitungen mit Direktiven wie:

php_value ...
php_flag ...

ungeeignet sein und unter bestimmten PHP-Handlern sogar einen HTTP-500-Fehler auslösen.

PHP-Einstellungen verwaltest du bei CURIAWEB über die dafür vorgesehenen cPanel-Werkzeuge.

Die Vorgehensweise erklären wir unter PHP-Einstellungen in cPanel ändern.

File not found und 404 unterscheiden #

Nicht jede Meldung über eine nicht gefundene Datei bedeutet, dass deine gesamte Website defekt ist.

Websites erhalten regelmäßig Anfragen nach nicht vorhandenen Ressourcen.

Das können beispielsweise sein:

• alte URLs
• gelöschte Bilder
• fehlerhafte Links
• Bot-Anfragen
• automatisierte Scans

Ein einzelner Eintrag zu einer nicht vorhandenen Datei ist deshalb nicht automatisch kritisch.

Bot-Anfragen richtig einordnen #

Öffentlich erreichbare Websites werden regelmäßig automatisiert aufgerufen.

Dabei können Bots URLs anfordern, die auf deiner Website niemals existiert haben.

Beispiele können ungewöhnliche Pfade zu Administrationsoberflächen, Skripten oder bekannten Schwachstellen anderer Systeme sein.

Solche Einträge sind nicht automatisch ein Hinweis darauf, dass die betreffende Datei auf deinem Hosting vorhanden war.

Wichtig: Ein Logeintrag kann lediglich zeigen, dass jemand eine bestimmte URL angefordert hat. Daraus folgt nicht automatisch, dass die angeforderte Datei existiert oder deine Website kompromittiert wurde.

Wiederkehrende Fehler sind wichtiger als zufällige Einzelmeldungen #

Bei der Priorisierung solltest du darauf achten, ob eine Meldung:

• bei jedem Seitenaufruf erscheint
• nur einmal aufgetreten ist
• immer dieselbe Datei betrifft
• mit einem sichtbaren Website-Problem zusammenfällt
• erst seit einer bestimmten Änderung auftritt

Eine reproduzierbare Fehlermeldung, die exakt beim Aufruf der defekten Seite entsteht, ist meist wesentlich relevanter als ein zufälliger älterer Logeintrag.

Ursache und Folgefehler unterscheiden #

Ein einzelnes Problem kann mehrere weitere Fehlermeldungen auslösen.

Beispielsweise:

benötigte Datei fehlt
        ↓
Klasse kann nicht geladen werden
        ↓
Funktion kann nicht ausgeführt werden
        ↓
Seite bricht mit Fatal Error ab

Wenn du nur die letzte Meldung behandelst, kann die ursprüngliche Ursache bestehen bleiben.

Prüfe deshalb bei mehreren zeitgleichen Meldungen, welche zuerst entstanden ist und wie die Meldungen zusammenhängen.

Was wurde unmittelbar vor dem Fehler geändert? #

Eine der wertvollsten Fragen bei der Diagnose lautet:

Was hat sich unmittelbar vor dem ersten Auftreten des Fehlers geändert?

Beispiele:

• WordPress aktualisiert
• Plugin aktualisiert
• Theme aktualisiert
• PHP-Version geändert
• PHP-Einstellung geändert
• .htaccess bearbeitet
• Dateien verschoben
• Website migriert
• neues Plugin installiert

Der zeitliche Zusammenhang ist kein endgültiger Beweis, aber ein sehr wertvoller Ausgangspunkt.

Immer nur eine Änderung zurücknehmen #

Wenn der Fehler nach einer konkreten Änderung begonnen hat, solltest du möglichst zuerst genau diese Änderung überprüfen beziehungsweise kontrolliert zurücknehmen.

Ändere nicht gleichzeitig:

PHP-Version
.htaccess
Dateiberechtigungen
Plugins
Theme
PHP-Limits

Sonst lässt sich später kaum noch feststellen, welche Maßnahme relevant war.

Fehler nach PHP-Wechsel #

Wenn eine Website unmittelbar nach einem PHP-Wechsel nicht mehr funktioniert, prüfe das Error Log auf Meldungen wie:

• Fatal Errors
• fehlende Funktionen
• fehlende Klassen
• Deprecated-Meldungen
• Probleme mit Erweiterungen

Wenn die Anwendung mit der neuen PHP-Version nicht kompatibel ist, kann ein kontrollierter Wechsel auf die zuvor funktionierende Version ein sinnvoller Diagnoseschritt sein.

Fehler nach Änderung der PHP-Einstellungen #

Wenn das Problem unmittelbar nach einer Änderung im MultiPHP INI Editor entstanden ist, solltest du die zuletzt geänderte Direktive prüfen.

Die PHP-Konfiguration behandeln wir ausführlich unter PHP-Einstellungen in cPanel ändern.

Fehler nach Änderung von Dateiberechtigungen #

Wenn Dateien oder Verzeichnisse unmittelbar vor dem Fehler andere Berechtigungen erhalten haben, solltest du auch diesen Zusammenhang berücksichtigen.

Setze die Rechte nicht wahllos auf immer höhere Werte, sondern stelle eine für den jeweiligen Dateityp geeignete Konfiguration her.

Fehler nach Migration #

Nach einem Website-Umzug können Fehlermeldungen beispielsweise auf folgende Probleme hinweisen:

• alte absolute Dateipfade
• fehlende Dateien
• inkompatible PHP-Version
• fehlende PHP-Erweiterungen
• unvollständige Übertragung
• abweichende Konfiguration

Gerade absolute Pfade können sich zwischen zwei Hosting-Systemen unterscheiden.

Fehler nach Wiederherstellung eines Backups #

Wenn nach einer Wiederherstellung Fehler auftreten, solltest du prüfen, ob Dateien und Datenbank zum selben Stand gehören.

Eine Anwendung kann Probleme verursachen, wenn beispielsweise neuere Dateien mit einer deutlich älteren Datenbank kombiniert werden.

cPanel Error Log und WordPress Debug Log unterscheiden #

WordPress besitzt zusätzlich eigene Debugging-Möglichkeiten.

Bei aktiviertem WordPress-Debugging kann beispielsweise eine Datei wie:

wp-content/debug.log

verwendet werden.

Das WordPress Debug Log und das cPanel Error Log sind nicht dasselbe.

Sie können sich ergänzen, weil sie Fehler auf unterschiedlichen Ebenen beziehungsweise mit unterschiedlichem Kontext protokollieren können.

Die WordPress-Diagnose behandeln wir unter WordPress-Debugging und Fehlerprotokolle verwenden.

WordPress Debugging nicht dauerhaft unnötig aktiv lassen #

Debugging-Funktionen sollten auf einer produktiven Website gezielt zur Diagnose verwendet werden.

Insbesondere Fehlermeldungen sollten nicht unnötig öffentlich im Frontend ausgegeben werden.

Logs können technische Informationen enthalten und sollten nicht öffentlich zugänglich gemacht werden.

cPanel Error Log und Cronjob-Ausgabe unterscheiden #

Ein PHP-Skript, das über einen Cronjob beziehungsweise die Kommandozeile ausgeführt wird, muss seine Fehler nicht zwangsläufig im gleichen Webserver-Log hinterlassen.

Bei Cronjob-Problemen solltest du deshalb zusätzlich die eigentliche Cron-Ausgabe und anwendungsspezifische Logs prüfen.

Die Vorgehensweise erklären wir unter Cronjob funktioniert nicht: Ursachen und Lösungen.

Error Log und Access Log unterscheiden #

Ein Error Log protokolliert Fehler beziehungsweise relevante Fehlersituationen.

Ein Access Log protokolliert dagegen Zugriffe auf den Webserver.

Vereinfacht:

Access Log
→ Wer beziehungsweise was hat welche Ressource aufgerufen?

Error Log
→ Welcher Fehler ist bei der Verarbeitung aufgetreten?

Beide Logtypen können sich bei einer detaillierten Diagnose ergänzen.

Rohdaten von Zugriffen in cPanel #

Im Bereich Messwerte stellt cPanel zusätzlich Funktionen für Zugriffs- und Statistikdaten bereit.

Wenn du beispielsweise untersuchen möchtest, ob eine bestimmte URL aufgerufen wurde, sind Zugriffsdaten unter Umständen hilfreicher als das Error Log allein.

Error Log und CloudLinux-Ressourcen unterscheiden #

Ein langsamer oder fehlgeschlagener Seitenaufruf muss nicht zwingend einen klassischen PHP-Fehler erzeugen.

Wenn Hosting-Ressourcen ausgeschöpft werden, solltest du zusätzlich die CloudLinux-Ressourcennutzung prüfen.

Wie das funktioniert, erklären wir unter CloudLinux Ressourcennutzung in cPanel verstehen.

Wann Ressourcen und Error Log gemeinsam interessant sind #

Angenommen, eine Website fällt sporadisch aus und das Error Log enthält keine eindeutige wiederkehrende PHP-Ursache.

Dann kann ein Vergleich sinnvoll sein:

Zeitpunkt des Website-Problems
        ↓
Error Log prüfen
        ↓
CloudLinux-Ressourcen zum selben Zeitraum prüfen

Damit lässt sich beispielsweise erkennen, ob der Fehler mit einer Lastspitze zusammenfällt.

Alte Fehler nicht mit aktuellen Problemen verwechseln #

Ein Error Log kann Meldungen enthalten, deren Ursache längst behoben wurde.

Wenn beispielsweise gestern ein Plugin einen Fatal Error erzeugt hat und heute wieder korrekt funktioniert, bleibt die alte Meldung zunächst ein historischer Hinweis.

Entscheidend ist deshalb immer der zeitliche Zusammenhang mit dem aktuellen Problem.

Fehler gezielt erneut auslösen #

Bei einem reproduzierbaren Problem ist folgende Vorgehensweise besonders effektiv:

1. cPanel Error Log kurz kontrollieren.
2. Aktuelle Uhrzeit notieren.
3. Betroffene Seite oder Funktion genau einmal aufrufen.
4. Error Log erneut öffnen beziehungsweise aktualisieren.
5. Nach neuen Einträgen zum entsprechenden Zeitpunkt suchen.
6. Dateipfad und Fehlertext prüfen.

Damit reduzierst du die Wahrscheinlichkeit, einen völlig anderen Logeintrag zu analysieren.

Fehler tritt nur bei einer bestimmten URL auf #

Wenn nur eine einzelne Seite betroffen ist, prüfe:

• welcher Code speziell auf dieser Seite ausgeführt wird
• welches Plugin beziehungsweise Theme daran beteiligt ist
• ob die Seite besondere Funktionen verwendet
• ob unmittelbar beim Aufruf ein neuer Logeintrag entsteht

Eine funktionierende Startseite beweist nicht, dass sämtliche PHP-Funktionen der Website fehlerfrei sind.

Fehler tritt nur im WordPress-Adminbereich auf #

Wenn das Frontend funktioniert, aber beispielsweise eine bestimmte Verwaltungsseite einen Fatal Error erzeugt, solltest du genau diesen Adminbereich aufrufen und anschließend die neuen Logeinträge prüfen.

Plugins können beispielsweise Code nur innerhalb des Administrationsbereichs ausführen.

Fehler tritt nur bei Formularen auf #

Ein Formular kann beim normalen Anzeigen der Seite funktionieren und erst beim Absenden einen Fehler erzeugen.

Reproduziere deshalb genau die Aktion, bei der das Problem auftritt.

Bei der Fehlersuche zählt nicht nur die URL, sondern der konkrete Ablauf.

Fehler tritt nur sporadisch auf #

Sporadische Fehler sind schwieriger zu diagnostizieren.

Dokumentiere möglichst:

• Datum und Uhrzeit
• betroffene URL
• ausgeführte Aktion
• sichtbare Browsermeldung
• gleichzeitige Logeinträge
• mögliche Ressourcenwerte

Je genauer der Zeitpunkt bekannt ist, desto leichter lassen sich verschiedene Diagnosequellen miteinander vergleichen.

Fehlermeldung nicht öffentlich weitergeben #

Error Logs können interne Dateipfade, Benutzernamen, technische Konfigurationen oder andere Informationen über die Hosting-Umgebung enthalten.

Veröffentliche vollständige Logs deshalb nicht unüberlegt in öffentlichen Foren oder sozialen Netzwerken.

Sicherheitshinweis: Prüfe Logauszüge vor dem Weitergeben auf Passwörter, Tokens, API-Schlüssel, personenbezogene Daten und andere vertrauliche Informationen.

Nicht komplette riesige Logs senden #

Für eine Supportanfrage ist ein relevanter Ausschnitt rund um den konkreten Fehler häufig hilfreicher als tausende unzusammenhängende Logzeilen.

Wichtig sind:

• Zeitpunkt
• vollständige Fehlermeldung
• betroffene Datei
• gegebenenfalls Stack Trace
• Beschreibung der Aktion, die den Fehler auslöst

Fehlermeldung vollständig kopieren #

Schneide bei einer technischen Meldung nicht nur einen einzelnen Begriff heraus.

Statt beispielsweise nur:

Fatal error

weiterzugeben, sollte die relevante Meldung mit Fehlertext, Dateipfad und Zeilennummer dokumentiert werden.

Gerade diese Details unterscheiden zwei völlig verschiedene Ursachen voneinander.

Typische Meldungen und erste Prüfschritte #

Meldung	Erster Prüfschritt
PHP Fatal error	vollständigen Fehlertext, Datei und Zeile prüfen
Uncaught Error	Fehlertext und Stack Trace auswerten
Call to undefined function	PHP-Erweiterung, Anwendung und PHP-Version prüfen
Class ... not found	betroffene Anwendung und fehlende Abhängigkeit prüfen
Failed opening required	Dateipfad und vorhandene Dateien prüfen
No such file or directory	Pfad, Dateiname und Migration prüfen
Permission denied	Datei- und Verzeichnisberechtigungen prüfen
Allowed memory size ... exhausted	Speicherbedarf und PHP Memory Limit prüfen
Maximum execution time ... exceeded	betroffenen Prozess und Laufzeit prüfen
PHP Deprecated	Software-Kompatibilität mit PHP-Version prüfen
Invalid command	Konfiguration beziehungsweise .htaccess prüfen

Systematische Fehlersuche mit dem cPanel Error Log #

1. Notiere das sichtbare Problem und die betroffene URL.
2. Notiere die aktuelle Uhrzeit.
3. Öffne Messwerte → Fehler.
4. Rufe die problematische Seite beziehungsweise Funktion erneut auf.
5. Prüfe unmittelbar danach neue Logeinträge.
6. Vergleiche den Zeitstempel mit deinem Test.
7. Prüfe Fehlerart und vollständigen Fehlertext.
8. Prüfe Dateipfad und gegebenenfalls Zeilennummer.
9. Ordne die Datei einer Anwendung, einem Plugin oder Theme zu.
10. Prüfe, was unmittelbar vor dem ersten Auftreten des Fehlers geändert wurde.
11. Nimm nicht mehrere Konfigurationsänderungen gleichzeitig vor.
12. Teste nach einer gezielten Änderung erneut denselben Ablauf.

Wenn im Error Log nichts erscheint #

Wenn beim reproduzierbaren Fehler kein neuer Eintrag im cPanel Error Log erscheint, bedeutet das nicht automatisch, dass kein technisches Problem existiert.

Je nach Situation solltest du andere Diagnosequellen prüfen.

Dazu können gehören:

• anwendungseigene Logs
• WordPress Debug Log
• Cronjob-Ausgabe
• Zugriffslogs
• CloudLinux-Ressourcen
• Browser-Entwicklerwerkzeuge bei Frontend-Problemen

Die richtige Diagnosequelle hängt davon ab, auf welcher Ebene der Fehler entsteht.

Wann solltest du den CURIAWEB-Support kontaktieren? #

Wenn du einen reproduzierbaren Website-Fehler hast, das Error Log eine technische Meldung enthält und du die Ursache nicht eindeutig beheben kannst, dokumentiere den Fall möglichst präzise.

Für eine Analyse sind insbesondere folgende Angaben hilfreich:

• betroffene Domain
• betroffene URL beziehungsweise Funktion
• Datum und genaue Uhrzeit des Fehlers
• sichtbare Fehlermeldung im Browser
• vollständiger relevanter Error-Log-Eintrag
• betroffene Datei und Zeilennummer, falls vorhanden
• was unmittelbar vor dem Problem geändert wurde
• ob der Fehler reproduzierbar ist
• verwendete PHP-Version, falls relevant

Übermittle keine Passwörter, Tokens, API-Schlüssel oder andere vertrauliche Zugangsdaten.

Zusammenfassung #

Das cPanel Error Log unter Messwerte → Fehler ist eines der wichtigsten Diagnosewerkzeuge bei serverseitigen Website-Problemen. Es kann dir zeigen, wann ein Fehler aufgetreten ist, welche Datei beteiligt war und welche technische Meldung erzeugt wurde.

Analysiere einen Eintrag immer im Zusammenhang mit Zeitstempel, Fehlertext, Dateipfad und gegebenenfalls Zeilennummer. Ein einzelnes Wort wie Fatal error reicht für eine zuverlässige Diagnose nicht aus.

Typische Meldungen wie Permission denied, Allowed memory size exhausted, Failed opening required oder Call to undefined function weisen auf unterschiedliche Fehlerklassen hin und erfordern entsprechend unterschiedliche Maßnahmen.

Bei WordPress kann der Dateipfad häufig zeigen, ob ein Plugin oder Theme am Fehler beteiligt ist. Das ist jedoch ein Hinweis und nicht automatisch der Beweis, dass diese Komponente allein die Ursache darstellt.

Reproduziere einen Fehler möglichst kontrolliert und kontrolliere unmittelbar danach das Error Log. Dadurch kannst du aktuelle Meldungen wesentlich zuverlässiger dem konkreten Problem zuordnen.

Wenn dort keine passende Meldung erscheint, solltest du die Diagnosequelle wechseln. WordPress Debug Logs, Cronjob-Ausgaben, Zugriffslogs und CloudLinux-Ressourcen liefern Informationen über andere technische Ebenen.

Die wichtigste Regel lautet: Nicht die erste rote Fehlermeldung auf Verdacht reparieren. Reproduziere den Fehler, ordne den passenden Logeintrag zeitlich zu und arbeite anschließend anhand der konkreten Meldung.