Was ist Fehler 500 (Internal Server Error)?

Der Code 500 gehört zur 5xx-Familie, die für Fehler innerhalb des Servers reserviert ist, nicht für Probleme in der Anfrage selbst. Nach RFC 9110, der aktuell gültigen Spezifikation, antwortet der Server mit 500, wenn er auf "einen unerwarteten Zustand stößt, der ihn daran hindert, die Anfrage zu erfüllen". In der Praxis ist das der Sammelbegriff für Serverfehler: Er greift, wenn etwas schiefgeht und kein konkreterer Code die Ursache benennt.

Genau diese Unbestimmtheit macht den Unterschied. Ein Fehler 404 zeigt an, dass die angeforderte Ressource nicht existiert. Ein Fehler 400 zeigt eine fehlerhaft aufgebaute Anfrage an. Der 500 sagt davon nichts: Er bestätigt nur, dass der Server die Anfrage erhalten, mit der Verarbeitung begonnen hat und dabei etwas abgebrochen ist, sei es im Anwendungscode, in der Datenbankverbindung oder bei erschöpften Ressourcen.

Bei WordPress und ähnlichen Systemen taucht der 500 meist nach der Aktivierung eines inkompatiblen Plugins oder Themes auf, oder nach einem PHP-Update, das alten Code ohne Unterstützung zurücklässt. Bei Seiten mit mehr Traffic kann auch schlicht der Arbeitsspeicher oder die Zahl verfügbarer Verbindungen in einem Lastspitzenwert ausgehen.

Alle vier Codes sind Serverfehler, markieren aber unterschiedliche Stellen im Ablauf. Sie zu verwechseln erschwert die Diagnose, weil die Lösung in keinem der vier Fälle dieselbe ist.

Praktisch bedeutsam: 502 und 504 setzen fast immer einen Proxy oder Load Balancer voraus, während 500 und 503 auch bei einem einzelnen Server auftreten können. Gegenüber dem Fehler 404 haben alle vier eines gemeinsam: Die Anfrage kam korrekt an, der Fehler liegt auf Serverseite, nicht beim Client.

Kommt eine korrekt aufgebaute Anfrage beim Server an, beginnt er mit der Verarbeitung: Datenbankabfrage, Anwendungslogik, Aufbau der Antwort. Der 500 entsteht, wenn in diesem Ablauf etwas bricht, nachdem die Anfrage bereits die Prüfungen bestanden hat, die sonst einen Fehler 400 auslösen würden, und bevor der Server die Antwort fertigstellt.

HTTP/1.1 500 Internal Server Error
Content-Type: text/html; charset=UTF-8
Date: Sat, 08 Aug 2026 10:21:09 GMT

Die häufigsten Ursachen wiederholen sich meist. Ein Plugin oder Theme mit fehlerhaftem Code, oft nach einem WordPress-Update, das mit der installierten PHP-Version nicht harmoniert. Ein Fehler bei der Datenbankverbindung, sei es durch falsche Zugangsdaten, einen ausgefallenen Dienst oder eine überschrittene Grenze gleichzeitiger Verbindungen. Eine fehlerhafte Konfiguration in der .htaccess-Datei, besonders nach manueller Bearbeitung oder einem Umzug auf einen neuen Server. Erschöpfte Serverressourcen, Arbeitsspeicher oder Prozesse, bei Trafficspitzen, die das Hosting-Paket nicht abfängt. Seltener: ein abgelaufenes SSL-Zertifikat oder ein PHP-Versionskonflikt zwischen Code und Umgebung, etwa nach einem Update des Hosters.

Anders als der Fehler 404, der bestätigt, dass der Server fertig gesucht und nichts gefunden hat, bricht der 500 den Prozess mittendrin ab, oft ohne erkennbares Muster für den Besucher. Deshalb ist die Prüfung der Server-Logs fast immer der erste Schritt: Dort steht, welcher Prozess oder welche Codezeile den Fehler verursacht hat, eine Information, die die HTTP-Antwort selbst nicht liefert. Ein Blick allein auf die Fehlerseite im Browser reicht dafür nicht aus.

Ein einzelner 500-Fehler, der nur Sekunden oder Minuten dauert, wirkt sich kaum auf das Ranking aus. Google behandelt vereinzelte Ausfälle als normales Rauschen jedes Servers. Problematisch wird es, wenn sich der Fehler wiederholt oder anhält: Google Search Central bestätigt, dass 5xx-Fehler zusammen mit 429 dazu führen, dass die Crawler ihre Crawling-Geschwindigkeit vorübergehend drosseln, und bleibt der Server lange genug bei 500, verschwinden die betroffenen URLs nach und nach aus dem Index.

Die Search Console fasst diese Fehler im Crawling-Statistikbericht unter der Kategorie "Serverfehler (5XX)" zusammen, getrennt von den 4xx-Fehlern. Ein anhaltender Anstieg dort ist das verlässlichste Signal dafür, dass das Problem nicht punktuell ist, selbst wenn die Seite bei einer manuellen Prüfung normal wirkt.

Die gute Nachricht: Die Erholung geht ebenso schnell. Sobald der Server wieder normal antwortet, stellt Google das vorherige Crawling-Tempo schrittweise wieder her. Anders als beim Fehler 404, der Inhalte entfernt, ohne dass sich der Fehler wiederholen muss, schadet der 500 erst, wenn er zur Regel statt zur Ausnahme wird.

• Server-Logs direkt nach einem 500 prüfen, um Prozess, Plugin oder Codezeile zu identifizieren, statt die Seite einfach neu zu laden.
• Ein Uptime-Monitoring einrichten, das schon beim ersten 500 alarmiert, nicht erst, wenn die Seite komplett offline ist.
• Während geplanter Wartungsarbeiten 503 statt 500 zurückgeben, weil 503 Google signalisiert, dass der Ausfall vorübergehend ist, und so verhindert, dass URLs aus dem Index fallen.
• Plugin- und Theme-Kompatibilität vor jedem WordPress-Update prüfen, besonders bei Shops oder Seiten mit individuellen Integrationen.
• SSL-Zertifikat und PHP-Version nach jeder Hosting-Migration kontrollieren, zwei häufige und leicht übersehene Ursachen.
• Bei einem Fehler nach einer kürzlichen Änderung Plugins oder Themes einzeln deaktivieren, statt das gesamte Update blind zurückzurollen.

• Während einer Migration oder Wartung 500 statt 503 zurückgeben, was das Verschwinden von Seiten aus dem Index beschleunigen kann.
• Einen nur zeitweise auftretenden 500 ignorieren, in der Annahme, das Problem sei gelöst, nur weil der nächste Aufruf funktioniert.
• Ein komplettes Update zurückrollen, ohne vorher die Logs zu prüfen, und so die Chance verpassen, das tatsächlich fehlerhafte Plugin zu identifizieren.
• Einen 500 mit einem Fehler 404 verwechseln und einen Serverfehler wie fehlenden Inhalt behandeln.
• Die Uptime der Seite nicht überwachen und das Problem erst bemerken, wenn ein Kunde oder die Search Console es Tage später meldet.