500 Internal Server Error beheben

Ein 500 Internal Server Error gehört zu den häufigsten serverseitigen Website-Fehlern. Die Meldung bedeutet, dass der Webserver eine Anfrage erhalten hat, sie aber aufgrund eines internen Fehlers nicht erfolgreich verarbeiten konnte.

Der Statuscode 500 nennt dabei noch nicht die eigentliche Ursache. Häufig stecken PHP-Fehler, eine fehlerhafte .htaccess, inkompatible Plugins oder Themes, falsche PHP-Einstellungen oder Probleme mit Dateien und Berechtigungen dahinter.

In dieser Anleitung zeigen wir dir, wie du einen 500 Internal Server Error im CURIAWEB-Webhosting systematisch diagnostizierst und die tatsächliche Ursache findest.

Wichtig: Ein 500-Fehler ist eine Sammelmeldung. Ändere deshalb nicht wahllos PHP-Version, Dateiberechtigungen, Plugins und .htaccess gleichzeitig. Der schnellste Weg zur Lösung führt normalerweise über den genauen Zeitpunkt des Fehlers und das Error Log.

Was bedeutet 500 Internal Server Error? #

Vereinfacht läuft eine Anfrage folgendermaßen ab:

Browser sendet Anfrage
        ↓
Webserver erhält Anfrage
        ↓
serverseitige Verarbeitung schlägt fehl
        ↓
500 Internal Server Error

Der Browser weiß dabei normalerweise nicht, welcher interne Fehler auf dem Server aufgetreten ist. Deshalb wird lediglich der allgemeine HTTP-Statuscode 500 angezeigt.

Wie kann ein 500-Fehler aussehen? #

Je nach Webserver, Anwendung und Browser kann die sichtbare Meldung unterschiedlich formuliert sein.

Beispiele sind:

500 Internal Server Error

Internal Server Error

HTTP ERROR 500

The server encountered an internal error
and was unable to complete your request.

Entscheidend ist nicht die genaue Formulierung, sondern dass die Anfrage mit dem HTTP-Statuscode 500 fehlschlägt.

500, 403, 404 und 503 unterscheiden #

Status	Vereinfacht bedeutet er
403 Forbidden	Zugriff wird verweigert
404 Not Found	Ressource wurde nicht gefunden
500 Internal Server Error	interne serverseitige Verarbeitung ist fehlgeschlagen
503 Service Unavailable	Dienst kann die Anfrage vorübergehend nicht verarbeiten

Wenn tatsächlich ein 403 angezeigt wird, verwende stattdessen unsere Anleitung 403 Forbidden beheben.

Zuerst das Fehlerbild eingrenzen #

Bevor du etwas änderst, prüfe, wann und wo der Fehler auftritt.

Stelle beispielsweise fest:

• Ist die komplette Website betroffen?
• Nur eine einzelne Seite?
• Nur der WordPress-Adminbereich?
• Nur eine bestimmte Aktion?
• Nur ein PHP-Skript?
• Nur ein Import oder Export?
• Trat der Fehler unmittelbar nach einer Änderung auf?
• Ist der Fehler dauerhaft oder nur sporadisch?

Diese Informationen helfen dabei, die Fehlersuche deutlich einzugrenzen.

1. Datum, Uhrzeit und betroffene URL notieren #

Notiere möglichst genau, wann der Fehler auftritt.

Beispiel:

28.08.2026
15:42 Uhr
https://example.ch/wp-admin/
500 Internal Server Error

Wenn der Fehler nur bei einer bestimmten Aktion entsteht, notiere auch diese.

Beispielsweise:

WordPress funktioniert
→ Plugin aktualisieren
→ 500 Internal Server Error

Der genaue Zeitpunkt ist wichtig, damit du anschließend den passenden Eintrag im Fehlerprotokoll finden kannst.

2. cPanel Error Log prüfen #

Öffne im CURIAWEB-cPanel:

Messwerte → Fehler

Suche nach Einträgen, die zeitlich mit dem 500-Fehler zusammenfallen.

Das Error Log ist bei einem 500 Internal Server Error einer der wichtigsten Diagnosepunkte.

Wie du die Meldungen richtig liest, erklären wir ausführlich unter cPanel Error Log lesen und Website-Fehler finden.

Praxis-Tipp: Wenn der Fehler reproduzierbar ist, notiere die aktuelle Uhrzeit, rufe die fehlerhafte Seite einmal auf und kontrolliere anschließend direkt das Error Log. Dadurch lässt sich der relevante Eintrag häufig leichter zuordnen.

Die genaue Fehlermeldung ist wichtiger als „Error 500“ #

Der sichtbare 500-Fehler ist lediglich das Symptom.

Ein Error-Log-Eintrag kann dagegen beispielsweise Hinweise enthalten wie:

PHP Fatal error

Allowed memory size exhausted

Call to undefined function

Class not found

Permission denied

.htaccess configuration error

Diese Informationen führen wesentlich näher an die tatsächliche Ursache.

3. Letzte Änderungen prüfen #

Wenn eine Website vorher funktioniert hat, ist die wichtigste Frage häufig:

Was wurde unmittelbar vor dem ersten 500-Fehler geändert?

Prüfe beispielsweise:

• Plugin installiert oder aktualisiert
• Theme aktualisiert
• WordPress aktualisiert
• PHP-Version geändert
• .htaccess bearbeitet
• PHP-Einstellungen geändert
• Dateien hochgeladen oder ersetzt
• Website migriert
• individuellen PHP-Code geändert
• neuen Cronjob eingerichtet

Ein enger zeitlicher Zusammenhang ist ein wichtiger Diagnosehinweis.

4. .htaccess überprüfen #

Eine fehlerhafte Apache-Anweisung in einer .htaccess-Datei kann einen 500 Internal Server Error verursachen.

Das ist besonders wahrscheinlich, wenn der Fehler unmittelbar nach einer manuellen Änderung dieser Datei begonnen hat.

Die .htaccess befindet sich häufig im Document Root der Website.

Wenn sie im Dateimanager nicht sichtbar ist, lies zuerst Versteckte Dateien wie .htaccess in cPanel anzeigen.

.htaccess nicht einfach löschen #

Die Datei kann wichtige Regeln enthalten, beispielsweise für:

• WordPress-Permalinks
• Weiterleitungen
• Zugriffsschutz
• individuelle Serveranweisungen

Erstelle deshalb zuerst eine Sicherungskopie.

Wie du Änderungen kontrolliert vornimmst, erklären wir unter .htaccess erklärt und sicher bearbeiten.

Zuletzt eingefügte .htaccess-Regel zurücknehmen #

Wenn der Ablauf eindeutig ist:

Website funktioniert
        ↓
.htaccess geändert
        ↓
500 Internal Server Error

solltest du zuerst genau diese Änderung rückgängig machen.

Entferne nicht wahllos sämtliche vorhandenen Regeln.

.htaccess testweise umbenennen #

Wenn du einen starken Verdacht auf die .htaccess hast, aber nicht erkennen kannst, welche Regel fehlerhaft ist, kannst du nach vorheriger Sicherung die Datei vorübergehend umbenennen.

Beispielsweise:

.htaccess
→
.htaccess-test

Rufe anschließend die Website erneut auf.

Verschwindet der 500-Fehler, liegt sehr wahrscheinlich eine Ursache innerhalb der bisherigen .htaccess-Konfiguration vor.

Wichtig: Das Umbenennen ist ein Diagnoseschritt und keine fertige Lösung. Funktionen wie WordPress-Permalinks oder Weiterleitungen können dadurch vorübergehend nicht mehr korrekt arbeiten.

5. PHP-Version kontrollieren #

Ein 500-Fehler kann auftreten, wenn eine Website mit der verwendeten PHP-Version nicht kompatibel ist.

Das ist insbesondere relevant, wenn der Fehler unmittelbar nach einem PHP-Wechsel aufgetreten ist.

Bei CURIAWEB verwaltest du die PHP-Version einer Domain grundsätzlich über:

Software → MultiPHP-Manager

Die vollständige Anleitung findest du unter PHP-Version in cPanel ändern.

PHP-Version nicht wahllos wechseln #

Teste nicht nacheinander beliebige PHP-Versionen in der Hoffnung, dass eine davon funktioniert.

Prüfe zuerst:

• welche PHP-Version aktuell verwendet wird
• welche Version vorher funktioniert hat
• welche Version die Anwendung unterstützt
• ob Plugins und Themes damit kompatibel sind

Wenn der Fehler direkt nach einem PHP-Wechsel begonnen hat, kann ein kontrollierter Wechsel auf die zuvor funktionierende und weiterhin geeignete Version ein sinnvoller Test sein.

6. PHP Fatal Errors prüfen #

Ein PHP Fatal Error kann dazu führen, dass eine Anfrage nicht erfolgreich abgeschlossen wird.

Typische Meldungen können beispielsweise so beginnen:

PHP Fatal error:

Der weitere Text der Meldung ist für die Diagnose entscheidend.

Er kann beispielsweise auf:

• eine bestimmte PHP-Datei
• ein WordPress-Plugin
• ein Theme
• eine fehlende Funktion
• eine fehlende Klasse
• einen Speicherfehler

hinweisen.

Pfad in der Fehlermeldung lesen #

Enthält die Meldung einen Dateipfad, kann dieser einen wichtigen Hinweis auf die verursachende Komponente geben.

Beispiel:

/wp-content/plugins/beispiel-plugin/...

weist darauf hin, dass Code innerhalb dieses Plugin-Verzeichnisses am Fehler beteiligt ist.

Das beweist noch nicht automatisch, dass das gesamte Plugin fehlerhaft ist, grenzt die Untersuchung aber erheblich ein.

7. Fehlende PHP-Erweiterungen prüfen #

Nach einem PHP-Wechsel oder einer Migration kann eine Anwendung eine PHP-Erweiterung erwarten, die in der verwendeten PHP-Umgebung nicht verfügbar ist.

Typische Hinweise sind beispielsweise:

Call to undefined function ...

Class ... not found

requires ext-...

Wie du solche Fälle untersuchst, erklären wir unter PHP-Erweiterungen in cPanel aktivieren und verwalten.

PHP-Erweiterungen und PHP-Version gemeinsam betrachten #

PHP-Erweiterungen sind versionsbezogen.

Wenn ein Fehler unmittelbar nach einem Wechsel der PHP-Version beginnt, solltest du deshalb nicht nur die Versionsnummer betrachten, sondern auch prüfen, ob die Anwendung alle benötigten Funktionen in dieser PHP-Umgebung vorfindet.

8. PHP Memory Limit prüfen #

Wenn das Error Log beispielsweise folgende Meldung enthält:

Allowed memory size of ... bytes exhausted

hat ein PHP-Prozess sein konfiguriertes memory_limit erreicht.

Das ist ein konkreter Hinweis und sollte nicht mit dem CloudLinux Physical Memory verwechselt werden.

Wie du PHP-Limits prüfst und sinnvoll einstellst, erklären wir unter PHP Memory Limit, Upload-Größe und Ausführungszeit einstellen.

Memory Limit nicht beliebig erhöhen #

Wenn eine Anwendung ungewöhnlich viel Speicher benötigt, kann ein höheres Limit das Symptom unter Umständen verschieben, ohne die eigentliche Ursache zu beseitigen.

Prüfe deshalb zusätzlich:

• welcher Prozess den Speicher benötigt
• ob der Bedarf für die betreffende Aufgabe plausibel ist
• ob ein Plugin oder Skript fehlerhaft arbeitet

9. Weitere PHP-Einstellungen kontrollieren #

Wenn der Fehler nach Änderungen an der PHP-Konfiguration begonnen hat, kontrolliere die zuletzt veränderten Werte.

Bei CURIAWEB verwendest du dafür grundsätzlich den:

Software → MultiPHP INI-Editor

Unsere Anleitung findest du unter PHP-Einstellungen in cPanel ändern.

Ändere PHP-Werte nicht auf Verdacht. Verwende die Fehlermeldung und die Anforderungen der Anwendung als Grundlage.

10. Dateiberechtigungen überprüfen #

Auch ungeeignete Datei- oder Verzeichnisberechtigungen können serverseitige Probleme verursachen.

Öffne:

Dateien → Dateimanager

Prüfe insbesondere Dateien und Verzeichnisse, die unmittelbar vor dem Fehler geändert, hochgeladen oder entpackt wurden.

Bei typischen Websites werden häufig folgende Werte verwendet:

Dateien:       644
Verzeichnisse: 755

Die genaue Vorgehensweise findest du unter Dateiberechtigungen 644 und 755 in cPanel richtig einstellen.

Achtung: Setze Berechtigungen nicht pauschal auf 777. Das ist keine saubere Lösung für einen 500-Fehler und kann Sicherheitsprobleme verursachen.

11. Dateien nach Migration oder Upload kontrollieren #

Wenn der Fehler nach einer Migration oder einem manuellen Upload begonnen hat, kontrolliere:

• ob alle Dateien übertragen wurden
• ob die Dateien im richtigen Document Root liegen
• ob Archive vollständig entpackt wurden
• ob Konfigurationsdateien vorhanden sind
• ob Berechtigungen plausibel sind
• ob die PHP-Version zur Anwendung passt

Ein unvollständig übertragenes Plugin, Theme oder Framework kann ebenfalls serverseitige Fehler verursachen.

12. Document Root kontrollieren #

Wenn du möglicherweise Dateien im falschen Verzeichnis untersuchst, prüfe unter:

Domains → Domains

den Document Root der betroffenen Domain.

Unsere Anleitung dazu findest du unter Domain in cPanel hinzufügen und verwalten.

13. WordPress-Plugins untersuchen #

Bei WordPress gehören Plugins zu den häufigsten Anwendungskomponenten, die an einem 500-Fehler beteiligt sein können.

Besonders verdächtig ist ein Plugin, wenn der Fehler unmittelbar nach:

• Installation
• Aktivierung
• Update
• Konfigurationsänderung

dieses Plugins begonnen hat.

Prüfe zuerst das Error Log. Enthält die Fehlermeldung einen Pfad innerhalb von:

/wp-content/plugins/

kannst du die Untersuchung auf die betreffende Erweiterung konzentrieren.

WordPress-Plugin deaktivieren, wenn wp-admin nicht erreichbar ist #

Wenn ein fehlerhaftes Plugin den WordPress-Adminbereich unzugänglich macht, kann es notwendig sein, die Erweiterung außerhalb des WordPress-Backends zu deaktivieren.

Die passende Anleitung findest du unter WordPress-Plugin deaktivieren oder löschen.

Nicht alle Plugins gleichzeitig deaktivieren, wenn die Ursache bekannt ist #

Wenn das Error Log eindeutig auf eine bestimmte Erweiterung zeigt, solltest du zunächst genau diese Komponente untersuchen.

Eine vollständige Deaktivierung aller Plugins ist eher ein Diagnoseschritt, wenn die Ursache nicht eingegrenzt werden kann.

14. WordPress-Theme untersuchen #

Auch ein Theme kann PHP-Code enthalten, der einen Fatal Error verursacht.

Wenn das Error Log einen Pfad wie:

/wp-content/themes/mein-theme/

zeigt, sollte die betreffende Theme-Komponente untersucht werden.

Das gilt besonders, wenn der Fehler unmittelbar nach einem Theme-Update oder einer Codeänderung begonnen hat.

Plugin- und Theme-Konflikte systematisch prüfen #

Wenn die Ursache nicht eindeutig ist, verwende die Anleitung WordPress Plugin- und Theme-Konflikte erkennen und beheben.

Gehe dabei kontrolliert vor und dokumentiere jede Änderung.

15. WordPress-Debugging verwenden #

Wenn das normale Error Log nicht genügend Informationen liefert, kann bei WordPress eine gezielte Debug-Ausgabe beziehungsweise Protokollierung hilfreich sein.

WordPress kann Fehler beispielsweise in:

wp-content/debug.log

protokollieren, wenn das Debugging entsprechend konfiguriert wurde.

Wie du dies sicher einrichtest, erklären wir unter WordPress-Debugging und Fehlerprotokolle verwenden.

Wichtig: Aktiviere eine ausführliche Fehlerausgabe auf einer produktiven Website nicht dauerhaft für Besucher. Fehlermeldungen können technische Details und interne Pfade offenlegen.

16. Kritischen WordPress-Fehler berücksichtigen #

WordPress kann bei bestimmten PHP-Fatal-Errors statt eines klassischen 500-Fehlers auch eine eigene Meldung über einen kritischen Fehler anzeigen.

Beide Fehlerbilder können dieselbe technische Ursache haben.

Wenn WordPress die Meldung:

Es gab einen kritischen Fehler auf deiner Website.

anzeigt, verwende zusätzlich WordPress kritischer Fehler oder weiße Seite beheben.

17. Fehler nur auf einer einzelnen Seite #

Wenn die Startseite funktioniert, aber eine einzelne URL einen 500-Fehler erzeugt, solltest du die Diagnose auf diese Anfrage konzentrieren.

Mögliche Ursachen sind beispielsweise:

• bestimmtes Plugin
• individueller PHP-Code
• fehlerhafte Daten
• bestimmte Datenbankabfrage
• Rewrite-Regel
• speicherintensive Funktion

Ändere nicht die gesamte Hosting-Konfiguration, wenn der Fehler nur bei einer einzelnen Funktion auftritt.

18. Fehler nur im WordPress-Adminbereich #

Wenn die öffentliche Website funktioniert, aber /wp-admin/ einen 500-Fehler erzeugt, ist ein generelles DNS- oder Domainproblem unwahrscheinlich.

Prüfe besonders:

• Error Log
• Plugins
• Theme beziehungsweise individuellen Code
• PHP-Version
• PHP Memory Limit
• kürzlich vorgenommene Updates

19. Fehler nur beim Speichern oder Aktualisieren #

Wenn WordPress normal lädt, aber beispielsweise das Speichern eines Beitrags mit 500 fehlschlägt, ist die serverseitige Verarbeitung genau dieser Aktion zu untersuchen.

Reproduziere den Fehler einmal und kontrolliere unmittelbar danach das Error Log.

Ein solches Fehlerbild kann beispielsweise mit einem Plugin, PHP-Code oder einer ressourcenintensiven Verarbeitung zusammenhängen.

20. Fehler bei Uploads #

Wenn der 500-Fehler nur beim Hochladen größerer Dateien auftritt, prüfe zusätzlich die PHP-Limits.

Relevant können beispielsweise sein:

upload_max_filesize
post_max_size
memory_limit
max_execution_time

Beachte, dass diese Werte unterschiedliche Aufgaben haben und nicht beliebig erhöht werden sollten.

21. Fehler bei Importen #

Wenn nur ein großer Import mit 500 abbricht, während die restliche Website funktioniert, solltest du die Importverarbeitung untersuchen.

Prüfe insbesondere:

• Error Log
• PHP Memory Limit
• Ausführungszeit
• PHP-Kompatibilität
• Größe des Imports
• Fehler der verwendeten Import-Anwendung

Wenn möglich, kann eine Anwendung kleinere Verarbeitungspakete unterstützen. Welche Einstellung sinnvoll ist, hängt vom verwendeten Importwerkzeug ab.

22. Fehler bei Cronjobs #

Ein PHP-Skript kann bei einem Cronjob fehlschlagen, obwohl die Website im Browser grundsätzlich funktioniert.

Wenn der Fehler im Zusammenhang mit einem geplanten Prozess auftritt, kontrolliere:

• Cronjob-Befehl
• PHP-Pfad beziehungsweise PHP-Version
• Dateipfad
• Berechtigungen
• Fehlerausgabe

Die ausführliche Diagnose findest du unter Cronjob funktioniert nicht: Ursachen und Lösungen.

23. CloudLinux-Ressourcen prüfen #

Wenn der 500-Fehler nur sporadisch oder unter Last auftritt, solltest du zusätzlich die CloudLinux-Ressourcennutzung zum gleichen Zeitpunkt kontrollieren.

Öffne:

Messwerte → Ressourcennutzung

Prüfe, ob zum Zeitpunkt des Fehlers ein Ressourcenlimit erreicht wurde.

Wie du die Werte interpretierst, erklären wir unter CloudLinux Ressourcennutzung in cPanel verstehen.

500 und Resource Limit Is Reached sind nicht dasselbe #

Ein CloudLinux-Limit und ein HTTP-500-Fehler sind unterschiedliche Dinge.

Ein Ressourcenengpass kann jedoch die Verarbeitung einer Anwendung beeinflussen. Deshalb ist bei sporadischen Fehlern ein zeitlicher Vergleich sinnvoll.

Wenn ausdrücklich 508 Resource Limit Is Reached angezeigt wird, verwende unsere Anleitung Resource Limit Is Reached: CloudLinux-Limits erkennen und beheben.

24. Speicherplatz kontrollieren #

Ein vollständig belegter Hosting-Account kann verschiedene Anwendungen und Schreibvorgänge beeinträchtigen.

Wenn der Fehler beispielsweise bei Updates, Cache-Erstellung, Uploads oder anderen schreibenden Vorgängen auftritt, kontrolliere zusätzlich den verfügbaren Speicherplatz.

Die Vorgehensweise findest du unter Speicherplatz und Bandbreite in cPanel überprüfen.

25. Datenbankfehler berücksichtigen #

Eine Anwendung kann einen 500-Fehler erzeugen, wenn serverseitiger Code bei einer Datenbankoperation fehlschlägt.

Das bedeutet jedoch nicht, dass du sofort Tabellen in phpMyAdmin reparieren oder verändern solltest.

Prüfe zuerst die konkrete Fehlermeldung.

Wenn ein Datenbankproblem genannt wird, notiere:

• genauen Fehlertext
• betroffene Tabelle, falls angegeben
• betroffene Anwendung
• Zeitpunkt

Datenbank nicht auf Verdacht bearbeiten #

Lösche oder ändere keine Tabellen, nur weil ein 500-Fehler auftritt.

Ein Fehler in Anwendungscode kann genauso gut die Datenbankabfrage verursachen.

Grundlagen zur Datenbankverwaltung findest du unter phpMyAdmin in cPanel verwenden.

26. Fehler nach Website-Migration #

Wenn eine Website unmittelbar nach einer Migration einen 500-Fehler erzeugt, solltest du besonders folgende Punkte prüfen:

• PHP-Version
• benötigte PHP-Erweiterungen
• PHP-Einstellungen
• .htaccess
• Dateiberechtigungen
• vollständige Dateiübertragung
• Datenbankverbindung
• anwendungsspezifische Pfade und Konfigurationen

Versuche nicht, alle Punkte gleichzeitig zu verändern. Das Error Log sollte auch hier die Diagnose führen.

27. Fehler nach PHP-Wechsel #

Wenn der zeitliche Ablauf lautet:

Website funktioniert
        ↓
PHP-Version geändert
        ↓
500 Internal Server Error

prüfe zuerst:

• Kompatibilität der Anwendung
• Plugins und Themes
• benötigte PHP-Erweiterungen
• Error Log

Ein Wechsel zurück auf die zuvor funktionierende und weiterhin unterstützte Version kann als kontrollierter Test sinnvoll sein.

28. Fehler nach Plugin-Update #

Wenn ein 500-Fehler unmittelbar nach einem Plugin-Update beginnt, prüfe zuerst das Error Log auf einen entsprechenden Plugin-Pfad.

Falls die Erweiterung tatsächlich beteiligt ist, können je nach Situation folgende Schritte sinnvoll sein:

• Plugin deaktivieren
• Kompatibilität prüfen
• Update korrigieren beziehungsweise erneut sauber installieren
• Herstellerhinweise prüfen

Führe kein Downgrade auf eine unsichere oder bekannte fehlerhafte Version durch, ohne die Auswirkungen zu prüfen.

29. Fehler nach Theme-Update #

Dasselbe gilt für Themes.

Wenn das Error Log auf:

/wp-content/themes/...

verweist und der Fehler direkt nach einem Theme-Update begonnen hat, konzentriere die Diagnose auf diese Komponente.

30. Fehler nach Bearbeitung von functions.php #

Individueller PHP-Code in einer Theme-Datei kann bereits durch einen Syntax- oder Programmierfehler die Ausführung unterbrechen.

Wenn der Fehler unmittelbar nach einer Änderung an:

functions.php

auftritt, stelle zunächst die zuvor funktionierende Version dieser Änderung wieder her.

Bearbeite produktiven PHP-Code nicht ohne Sicherung.

31. Fehler nach Code Snippet #

Dasselbe Prinzip gilt für individuell eingefügten PHP-Code über ein Snippet-Plugin.

Wenn:

Snippet aktiviert
        ↓
500 Internal Server Error

ist dieses Snippet ein naheliegender Ausgangspunkt der Diagnose.

Prüfe das Error Log und deaktiviere gezielt den betreffenden Code, sofern dies sicher möglich ist.

32. Fehler nach Entpacken eines Archivs #

Wenn eine Website nach dem Hochladen und Entpacken eines ZIP-Archivs einen 500-Fehler erzeugt, prüfe:

• ob das Archiv vollständig entpackt wurde
• ob Dateien im richtigen Verzeichnis liegen
• Dateiberechtigungen
• .htaccess
• PHP-Kompatibilität
• Konfigurationsdateien

Wie du Archive korrekt verarbeitest, erklären wir unter ZIP-Dateien in cPanel komprimieren und entpacken.

33. 500 nur zeitweise #

Ein sporadischer 500-Fehler ist schwieriger zu diagnostizieren als ein dauerhaft reproduzierbarer Fehler.

Notiere deshalb jeden bekannten Zeitpunkt und vergleiche:

Zeitpunkt des 500-Fehlers
        ↓
Error Log
        ↓
CloudLinux-Ressourcen
        ↓
Cronjobs / Hintergrundaufgaben
        ↓
Traffic / besondere Aktivität

Wiederkehrende Zeitmuster können besonders hilfreich sein.

34. 500 immer zur selben Uhrzeit #

Wenn der Fehler regelmäßig ungefähr zur gleichen Uhrzeit auftritt, prüfe geplante Prozesse.

Dazu können beispielsweise gehören:

• Cronjobs
• Importe
• Exporte
• Synchronisationen
• Backup-Plugins
• WordPress-Hintergrundaufgaben

Der wiederkehrende Zeitpunkt ist dabei ein starker Diagnosehinweis.

35. 500 nur bei hoher Last #

Wenn der Fehler ausschließlich während hoher Auslastung auftritt, prüfe zusätzlich CloudLinux und die Art der Anfragen.

Ein hoher Traffic allein beweist noch nicht, dass das Hosting-Paket die Ursache ist.

Auch langsame PHP-Prozesse, ineffiziente Datenbankabfragen oder fehlendes Caching können dazu führen, dass sich Anfragen unter Last stärker aufstauen.

36. Caching kontrollieren #

Bei WordPress kann geeignetes Caching die dynamische Verarbeitung reduzieren.

CURIAWEB stellt dafür AccelerateWP in der Hosting-Umgebung bereit.

Die Verwendung erklären wir unter AccelerateWP in cPanel erklärt.

Caching ist jedoch keine Reparatur für einen PHP Fatal Error oder eine fehlerhafte .htaccess.

37. Nicht mehrere Cache-Systeme als Fehlerbehebung installieren #

Ein 500-Fehler sollte nicht dadurch behandelt werden, dass zusätzliche Performance-Plugins installiert werden.

Dadurch kann die technische Situation sogar komplizierter werden.

Finde zuerst die Ursache des Fehlers.

38. Browser-Cache ist selten die Ursache eines echten 500 #

Ein HTTP-500 wird serverseitig erzeugt.

Ein privates Browserfenster kann bei Tests trotzdem hilfreich sein, ändert aber nicht die zugrunde liegende Serverursache.

Wenn der Webserver weiterhin mit 500 antwortet, muss die serverseitige Verarbeitung untersucht werden.

39. DNS ist normalerweise nicht die Ursache eines 500 #

Wenn du von einem Webserver bereits einen HTTP-500 erhältst, wurde grundsätzlich ein Server erreicht.

Ein klassischer DNS-Ausfall äußert sich anders.

Nach DNS-Änderungen kann eine Domain allerdings versehentlich auf einen anderen Server zeigen. Prüfe deshalb bei einer kürzlichen Migration, ob du tatsächlich die erwartete Hosting-Umgebung erreichst.

40. SSL-Fehler und HTTP 500 unterscheiden #

Ein Zertifikatsfehler ist ebenfalls eine andere Fehlerklasse.

Wenn der Browser einen echten HTTP-Statuscode 500 erhält, wurde die Verbindung bereits weit genug aufgebaut, damit der Webserver eine HTTP-Antwort senden konnte.

Ersetze deshalb nicht auf Verdacht SSL-Zertifikate.

41. 500-Fehler nicht durch display_errors dauerhaft offenlegen #

Es kann verlockend sein, PHP-Fehler direkt auf der öffentlichen Website anzeigen zu lassen.

Auf einer produktiven Website ist das keine gute dauerhafte Lösung, weil Fehlermeldungen interne Informationen wie Dateipfade oder technische Details offenlegen können.

Verwende für die Diagnose bevorzugt Fehlerprotokolle.

42. Fehler nach Änderung erneut reproduzieren #

Nach jeder gezielten Korrektur solltest du exakt dieselbe URL oder Aktion erneut testen.

Ein sinnvoller Ablauf lautet:

Fehler reproduzieren
        ↓
Log prüfen
        ↓
eine Ursache ändern
        ↓
gleiche Aktion erneut testen
        ↓
Ergebnis vergleichen

Dadurch kannst du feststellen, ob deine Änderung tatsächlich relevant war.

43. Nicht fünf Dinge gleichzeitig ändern #

Wenn du gleichzeitig:

PHP wechselst
.htaccess löschst
Plugins deaktivierst
Berechtigungen änderst
Cache leerst

und die Website danach wieder funktioniert, weißt du nicht, was die Ursache war.

Das erschwert spätere Fehler erheblich.

Grundregel: Bei einem 500 Internal Server Error sollte das Error Log die Diagnose führen. Eine konkrete Fehlermeldung ist wertvoller als zehn Änderungen auf Verdacht.

500 Internal Server Error systematisch diagnostizieren #

1. Notiere betroffene URL, Datum und Uhrzeit.
2. Prüfe, ob die ganze Website oder nur eine bestimmte Aktion betroffen ist.
3. Öffne Messwerte → Fehler.
4. Suche den zeitlich passenden Error-Log-Eintrag.
5. Prüfe die zuletzt vorgenommenen Änderungen.
6. Untersuche bei entsprechendem Hinweis die .htaccess.
7. Kontrolliere PHP-Version und Anwendungskompatibilität.
8. Prüfe gemeldete PHP Fatal Errors.
9. Kontrolliere gegebenenfalls benötigte PHP-Erweiterungen.
10. Prüfe bei Speicherfehlern das PHP Memory Limit.
11. Kontrolliere relevante Datei- und Verzeichnisberechtigungen.
12. Prüfe bei WordPress den im Log genannten Plugin- oder Theme-Pfad.
13. Kontrolliere bei sporadischen Fehlern die CloudLinux-Ressourcen.
14. Berücksichtige Cronjobs und Hintergrundaufgaben.
15. Ändere nur eine mögliche Ursache gleichzeitig.
16. Teste anschließend exakt dieselbe Aktion erneut.

Schnelldiagnose nach Fehlermeldung #

Hinweis	Erster Prüfpunkt
PHP Fatal error	genannten PHP-Pfad beziehungsweise Komponente prüfen
Allowed memory size exhausted	PHP Memory Limit und verursachenden Prozess prüfen
Call to undefined function	PHP-Kompatibilität beziehungsweise Erweiterung prüfen
Class not found	Anwendung, Autoloading oder benötigte Erweiterung prüfen
Fehler direkt nach .htaccess-Änderung	zuletzt geänderte Regel prüfen
Fehler direkt nach PHP-Wechsel	PHP-Kompatibilität und Erweiterungen prüfen
Fehler direkt nach Plugin-Update	Error Log und betreffendes Plugin prüfen
Fehler nur unter Last	CloudLinux-Ressourcen und Anwendung prüfen
Fehler regelmäßig zur gleichen Uhrzeit	Cronjobs und Hintergrundaufgaben prüfen

Was du bei einem 500-Fehler nicht tun solltest #

Vermeide insbesondere:

• Dateiberechtigungen pauschal auf 777 setzen
• .htaccess ohne Sicherung löschen
• PHP-Versionen wahllos wechseln
• PHP Memory Limit extrem erhöhen
• alle Plugins ohne Diagnose löschen
• Datenbanktabellen auf Verdacht verändern
• mehrere Cache-Plugins installieren
• DNS oder SSL ohne entsprechenden Hinweis ändern
• mehrere technische Änderungen gleichzeitig durchführen

Wann solltest du den CURIAWEB-Support kontaktieren? #

Wenn der 500 Internal Server Error weiterhin besteht oder die Ursache aus dem Error Log nicht eindeutig hervorgeht, dokumentiere das Problem möglichst genau.

Hilfreich sind insbesondere:

• betroffene Domain
• vollständige betroffene URL
• Datum und genaue Uhrzeit
• sichtbare Fehlermeldung
• relevanter Error-Log-Eintrag
• ob die gesamte Website oder nur eine bestimmte Aktion betroffen ist
• kürzlich vorgenommene Änderungen
• aktuell verwendete PHP-Version
• ob der Fehler dauerhaft oder sporadisch auftritt
• bei sporadischen Fehlern gegebenenfalls auffällige CloudLinux-Werte

Wenn der Fehler reproduzierbar ist, beschreibe zusätzlich die genauen Schritte, mit denen er ausgelöst werden kann.

Zusammenfassung #

Ein 500 Internal Server Error bedeutet, dass eine serverseitige Anfrage nicht erfolgreich verarbeitet werden konnte. Der Statuscode selbst nennt noch nicht die eigentliche Ursache.

Der wichtigste erste Diagnosepunkt ist deshalb das cPanel Error Log unter Messwerte → Fehler. Vergleiche den dortigen Eintrag mit dem genauen Zeitpunkt des Fehlers.

Häufige Ursachen sind PHP Fatal Errors, fehlerhafte .htaccess-Regeln, inkompatible Plugins oder Themes, ungeeignete PHP-Versionen, fehlende PHP-Erweiterungen, erreichte PHP-Limits oder Probleme nach einer Migration beziehungsweise Dateiänderung.

Bei sporadischen Fehlern solltest du zusätzlich die CloudLinux-Ressourcennutzung, Cronjobs und Hintergrundaufgaben zum gleichen Zeitpunkt untersuchen.

Ändere nicht mehrere Komponenten gleichzeitig. Reproduziere den Fehler, prüfe das Log, formuliere eine konkrete Ursache und teste anschließend genau eine gezielte Änderung.

Die wichtigste Regel lautet: „500 Internal Server Error“ ist nicht die Diagnose – die eigentliche Diagnose beginnt mit der Fehlermeldung im Log.