Die Diagnose eines 500 Internal Server Error beginnt in den Logs
Ein 500 internal server error bedeutet, dass der Server einer Website auf eine unerwartete Bedingung gestoßen ist und eine Anfrage nicht abschließen konnte. Es handelt sich um einen HTTP status code, also eine Zahl, die ein Server zurückgibt, um zu beschreiben, was geschah, als ein Browser eine Seite anforderte. Die umfassendere 5xx-Gruppe deckt serverseitige Ausfälle ab, während 500 als Sammelcode verwendet wird, wenn der Server das Problem nicht genauer einordnen kann. In einem am 14. Oktober 2026 von Sucuri veröffentlichten Leitfaden wird betont, dass die hilfreiche Erklärung normalerweise im Error Log und nicht auf der öffentlichen Fehlerseite zu finden ist.
Dadurch unterscheidet sich 500 von verwandten Fehlern. Ein 502 zeigt an, dass ein Server von einem anderen vorgelagerten Server eine fehlerhafte Antwort erhalten hat. Ein 503 bedeutet, dass der Dienst nicht verfügbar oder überlastet ist, während ein 504 darauf hinweist, dass bei einer vorgelagerten Anfrage ein Timeout aufgetreten ist. Ein echter 500 ist normalerweise kein Problem des Browsers, Netzwerks oder Domain Name System (DNS). DNS ordnet einen Domainnamen dem Server zu, auf dem er gehostet wird. Bei einem 500 hat die Anfrage den Server erreicht, doch etwas ist fehlgeschlagen, während der Server seine Antwort vorbereitete.
Besucher können verschiedene Varianten des Fehlers sehen, darunter eine kurze Meldung über einen internal server error, eine vollständig leere weiße Seite oder den Hinweis von WordPress, dass auf der Website ein kritischer Fehler aufgetreten ist. WordPress kann einen schwerwiegenden PHP-Fehler abfangen und die ursprüngliche Serverantwort durch eine eigene Meldung ersetzen. PHP ist die Programmiersprache, mit der ein großer Teil von WordPress und viele andere Websites betrieben werden. Auch eine leere Seite kann ohne sichtbaren Inhalt eine 500-Antwort übermitteln; der tatsächliche Status lässt sich im Network-Tab der Entwicklertools eines Browsers oder über eine Anfrage in der Kommandozeile prüfen.
Zu den häufigen Ursachen gehören fehlerhafte Plugins, Erweiterungen oder Themes, insbesondere wenn ein Update Code einführt, den die installierte PHP-Version nicht ausführen kann. Zwei Plugins könnten dieselbe Funktion definieren, oder ein Theme könnte Code aufrufen, der nicht mehr vorhanden ist. Eine weitere häufige Ursache ist eine beschädigte .htaccess-Datei, eine Apache-Konfigurationsdatei, die Weiterleitungen, das Umschreiben von Adressen und Einstellungen auf Verzeichnisebene steuert. Ein Tippfehler, eine nicht unterstützte Anweisung oder eine von einem anderen Server kopierte Regel kann sich auf jede Seite unterhalb dieses Verzeichnisses auswirken.
Weitere Ursachen sind erschöpfter PHP-Arbeitsspeicher, eine nach einem Upgrade nicht mehr passende PHP-Version, falsche Dateieigentümer und Berechtigungen, Fehler bei der Datenbankverbindung oder ein nicht behandelter Ausfall in einem zeitgesteuerten Script, einer individuellen Integration oder einem externen Dienst. Sowohl zu restriktive als auch übermäßig offene Berechtigungen können auf gehärteten Hosting-Systemen Probleme verursachen. Schädliches PHP oder veränderte .htaccess-Regeln können dasselbe Ergebnis hervorrufen. Daher sollte ein unerklärlicher 500 nicht automatisch als gewöhnlicher Konfigurationsfehler behandelt werden.
Die Fehlersuche sollte mit einem einmaligen Neuladen beginnen, um eine kurzzeitige Auslastungsspitze auszuschließen. Anschließend sollte die Website von einem anderen Gerät, Netzwerk oder externen Statusdienst aus geprüft werden. Wenn nur ein Besucher den Fehler sieht, kann eine zwischengespeicherte Antwort bei einem content delivery network (CDN), Proxy oder Page Cache verantwortlich sein. Ein CDN ist ein Netzwerk, das Kopien von Website-Inhalten an mehreren Standorten speichert und ausliefert. Wenn alle den Fehler erhalten, muss die Untersuchung auf dem Server stattfinden.
Erstellen Sie eine vollständige Sicherung der Dateien und der Datenbank, bevor Sie Änderungen vornehmen. Öffnen Sie anschließend das Error Log im Hosting-Kontrollpanel oder das in der Dokumentation angegebene Log von Apache, Nginx oder PHP-FPM. Darin werden häufig die fehlerhafte Datei und die entsprechende Zeile angegeben. Falls nicht, aktivieren Sie das Debug-Logging der Anwendung, damit Fehler in eine nicht öffentliche Datei geschrieben werden. Zeigen Sie auf einer aktiven Website niemals detaillierte Fehler öffentlich an, da sie interne Dateipfade und andere Informationen offenlegen können.
Benennen Sie als Nächstes .htaccess vorübergehend um und laden Sie die Website neu. Wenn der Fehler dadurch behoben wird, können WordPress-Nutzer die Datei neu erzeugen, indem sie die Permalink-Einstellungen erneut speichern. Bei anderen Plattformen sollten die Anweisungen schrittweise wiederhergestellt werden, bis die fehlerhafte Anweisung gefunden ist. Deaktivieren Sie Plugins und testen Sie sie einzeln. Wechseln Sie danach vorübergehend zu einem Standard-Theme. Wenn das Dashboard nicht verfügbar ist, können diese Änderungen vorgenommen werden, indem Plugin- oder Theme-Verzeichnisse über Secure File Transfer Protocol (SFTP) umbenannt werden, eine verschlüsselte Methode zur Verwaltung von Dateien auf einem Server.
Erhöhen Sie das PHP-Speicherlimit nur, wenn im Log gemeldet wird, dass der zulässige Speicher erschöpft ist, und betrachten Sie die Änderung als Diagnoseschritt statt als dauerhafte Lösung für ein ineffizientes Plugin. Wenn der Fehler nach einem PHP-Upgrade auftrat, kann die vorübergehende Wiederherstellung der vorherigen Version ein Kompatibilitätsproblem bestätigen. Nicht mehr unterstütztes PHP sollte jedoch nicht dauerhaft verwendet werden. Bei den meisten Shared-Hosting-Angeboten wird für Dateien die Berechtigung 644 und für Verzeichnisse 755 erwartet, wobei der Eigentümer dem Hosting-Konto zugeordnet ist. Eine auf 777 gesetzte Datei ist sowohl funktional als auch sicherheitstechnisch problematisch. Leeren Sie abschließend den Page Cache, Object Cache, CDN-Cache und Reverse-Proxy-Cache. Teilen Sie dem Hosting-Anbieter außerdem den genauen Zeitstempel und den Log-Eintrag mit, wenn der Ausfall einen Datenbankserver, ein Ressourcenlimit oder ein Servermodul betrifft, das außerhalb der Kontrolle des Kunden liegt.
WordPress bietet zwei zusätzliche Wiederherstellungswege. Beschädigte Core-Dateien können ersetzt werden, indem eine frische WordPress-Kopie hochgeladen wird, während wp-content und wp-config.php erhalten bleiben. Nach einem unterbrochenen Update kann eine .maintenance-Datei im Root-Verzeichnis der Website zurückbleiben; durch das Entfernen dieser Datei wird die Website wieder freigegeben. Das Testen von Änderungen auf einer staging copy, also einem privaten Duplikat der aktiven Website, verhindert, dass detaillierte Fehler offengelegt oder riskante Änderungen in der Produktionsumgebung vorgenommen werden.
Eine mögliche Kompromittierung erfordert eine andere Reaktion. Zu den Warnzeichen gehören ein 500, der ohne Update oder Deployment auftritt, unerklärliche neue Änderungszeitpunkte, unbekannte Dateien, unerwartete .htaccess-Dateien oder Log-Einträge, die Code nennen, den der Eigentümer nicht installiert hat. Bedingte Ausfälle, die nur bestimmte Besucher, Browsertypen oder Personen betreffen, die über eine Suche auf die Website gelangen, können auf getarnte Malware hindeuten. Caching kann jedoch ein ähnliches Verhalten verursachen. Kein einzelnes Anzeichen beweist eine Infektion.
Die Untersuchung sollte einen serverseitigen Scan oder einen file integrity check anhand bekanntermaßen intakter Core-Dateien, die Prüfung der .htaccess-Dateien in jedem Verzeichnis, eine Kontrolle kürzlich erstellter Administratorkonten und die Untersuchung der Zugriffs-Logs rund um den ersten Ausfall umfassen. Wenn schädlicher Code bestätigt wird, müssen die betroffenen Dateien bereinigt, die Zugangsdaten für Hosting, SFTP, Datenbank und CMS-Administratoren geändert und der ursprüngliche Einstiegspunkt geschlossen werden. Wird eine saubere Sicherung wiederhergestellt, ohne die Schwachstelle zu beheben, kann die Website weiterhin für eine erneute Infektion offenbleiben.
Ein kurzzeitiger 500 verursacht wahrscheinlich keine dauerhaften Beeinträchtigungen in Suchmaschinen, da Crawler Anfragen nach vorübergehenden Serverausfällen üblicherweise wiederholen. Fehler, die mehrere Tage andauern, können das Crawling reduzieren und dazu führen, dass betroffene Seiten aus dem Suchindex entfernt werden. Zwischengespeicherte Fehler können auch nach der Behebung der ursprünglichen Störung weiterhin sichtbar bleiben. Uptime-Monitoring für 5xx-Antworten, zugängliche Logs und Berichte zu Serverfehlern in Google Search Console können Ausfallzeiten verkürzen. Updates für Plugins, Themes und PHP sollten einzeln auf einer staging copy getestet werden, mit wiederherstellbaren automatisierten Sicherungen und ohne unnötige Plugins oder für alle beschreibbare Verzeichnisse.