HTTP-Statuscodes erklärt: 200, 301, 404, 503 und mehr

Was ist ein HTTP-Statuscode?

Jede HTTP-Antwort beginnt mit einer Statuszeile, zum Beispiel HTTP/1.1 200 OK oder HTTP/2 404. Die dreistellige Zahl ist der Statuscode, der Text dahinter nur eine lesbare Beschreibung (bei HTTP/2 und HTTP/3 entfällt er ganz). Der Code teilt dem Client – Browser, Suchmaschine oder Monitor – mit, wie die Anfrage ausgegangen ist und was als Nächstes zu tun ist. Die Bedeutungen sind in RFC 9110 festgelegt und werden von der MDN-Dokumentation praxisnah beschrieben; beide finden Sie unten in den Quellen.

Für Website-Betreiber ist der Statuscode das knappste Signal, ob eine Seite funktioniert. Er ist zugleich die Grundlage jeder Website-Überwachung: Ein Monitor ruft eine Adresse auf, liest den Code und entscheidet daraus, ob die Prüfung gelungen ist. Wer die Codes versteht, kann Alarme einordnen, statt nur zu reagieren.

Welche Codeklassen gibt es?

Die erste Ziffer genügt für eine Grobeinordnung. Die Tabelle zeigt die fünf Klassen und wie ein Monitor sie typischerweise behandelt.

Wichtig ist die Blickrichtung: „4xx“ heißt nicht, dass der Besucher etwas falsch gemacht hat. Es heißt nur, dass der Server die Anfrage so, wie sie ankam, nicht erfüllen kann oder will. Ein kaputter interner Link, eine gelöschte Seite oder eine zu strenge Firewall erzeugen 4xx-Antworten, obwohl der Fehler bei Ihnen liegt.

Was bedeuten die 2xx-Codes?

200 OK ist der Normalfall: Die Anfrage war erfolgreich, der Inhalt wird ausgeliefert. 201 Created und 204 No Content begegnen Ihnen vor allem bei APIs: Eine Ressource wurde angelegt, beziehungsweise die Anfrage war erfolgreich, liefert aber bewusst keinen Inhalt. Wer einen API-Endpunkt überwacht, sollte wissen, welchen Erfolgscode der Endpunkt tatsächlich liefert.

Das Entscheidende: 200 sagt nur, dass der Server etwas ausgeliefert hat, nicht, dass es das Richtige war. Mehr dazu im Abschnitt zu Soft-Fehlern weiter unten.

Wie unterscheiden sich 301, 302, 307 und 308?

Weiterleitungen sind die häufigste Quelle von Verwirrung. Es gibt zwei Fragen: Ist die Weiterleitung dauerhaft oder vorübergehend, und darf der Client die Methode ändern (aus POST wird GET)?

Für die Suchmaschinenoptimierung gilt die Faustregel: dauerhafte Änderungen mit 301 oder 308 melden, vorübergehende mit 302 oder 307. Die Details zu Ketten und Schleifen behandelt der Ratgeber Weiterleitungen und Redirect-Ketten. Für das Monitoring genügt hier: Ein Monitor folgt Weiterleitungen und bewertet das Endergebnis. Eine Kette 301 → 301 → 200 ist ein Erfolg, eine Kette, die nie endet oder zu lang wird, ist ein Fehler.

Welche 4xx-Fehler sollten Sie kennen?

Bei 4xx-Codes lohnt der Blick auf die genaue Zahl, weil Ursache und Gegenmaßnahme stark variieren.

Besonders tückisch ist 403: Besucher sehen die Seite, der Monitor nicht. Der Grund ist fast immer ein Sicherheitsfilter, der automatisierte Anfragen blockiert. Die Prüfanfragen von UPTIMESHIELD tragen den User-Agent UPTIMESHIELD-Monitor, den Sie in Firewall oder Bot-Schutz erlauben können. Mehr zum Umgang mit solchen Störquellen steht in Falsche Ausfallalarme vermeiden.

Was bedeuten 500, 502, 503 und 504?

5xx-Codes sagen: Die Anfrage war in Ordnung, der Server hat sie aber nicht erfüllt. Für Betreiber sind sie die wichtigsten Alarmsignale.

Der 503 hat eine Sonderrolle: Er ist laut RFC 9110 ausdrücklich für vorübergehende Nichtverfügbarkeit gedacht und darf einen Retry-After-Header mitschicken, der sagt, wann ein neuer Versuch sinnvoll ist. Für Suchmaschinen ist ein kurzer 503 während einer Wartung ein klareres Signal als eine Fehlerseite mit Status 200. Ein Beispiel für nginx:

location / {
    if (-f /var/www/maintenance.flag) {
        return 503;
    }
    # ... normale Konfiguration
}
error_page 503 @wartung;
location @wartung {
    add_header Retry-After 1800 always;
    root /var/www/wartung;
    rewrite ^ /index.html break;
}

Beachten Sie bei CDNs und Reverse-Proxys, dass diese eigene, nicht standardisierte Codes verwenden können (etwa die 52x-Reihe bei Cloudflare oder 499 bei nginx für einen vom Client abgebrochenen Aufruf). Ihre Bedeutung steht in der Dokumentation des jeweiligen Dienstes.

Warum reicht ein 200 nicht als Beweis?

Viele Anwendungen liefern eine Fehlerseite mit Status 200 aus, zum Beispiel „Datenbankverbindung fehlgeschlagen“ oder eine leere Seite nach einem PHP-Fehler. Suchmaschinen nennen das „Soft-404“, wenn eine nicht vorhandene Seite mit 200 antwortet; im Monitoring spricht man von einem Soft-Fehler. Ein reiner Statuscode-Check bleibt dabei grün, die Besucher sehen aber nichts Brauchbares.

Zwei Gegenmittel sind in der Praxis bewährt:

• Keyword-Prüfung: Der Monitor sucht einen Text, der nur bei funktionierender Seite erscheint (Firmenname im Footer), oder einen Text, der nie erscheinen darf („Fatal error“, „Wartungsarbeiten“).
• JSON-Prüfung bei APIs: Statt nur den Code zu lesen, wird ein Wert im Antwortobjekt kontrolliert, zum Beispiel status gleich ok.

Welche Prüfarten es gibt, steht unter Monitortypen. Wo auch diese Prüfungen an ihre Grenzen stoßen, beschreibt Grenzen automatischer Website-Prüfungen.

Wie prüfen Sie Statuscodes selbst?

Mit curl sehen Sie, was ein Monitor sieht. Die Option -I sendet eine HEAD-Anfrage und zeigt nur die Header, -L folgt Weiterleitungen:

# Nur Statuszeile und Header
curl -I https://example.com/

# Weiterleitungen verfolgen, jede Station anzeigen
curl -sIL https://example.com/ | grep -iE '^(HTTP|location)'

# Nur den Endcode und die Zahl der Weiterleitungen ausgeben
curl -o /dev/null -sL -w "%{http_code} nach %{num_redirects} Weiterleitung(en)\n" http://example.com/

Ein häufiger Stolperstein: Manche Server beantworten HEAD anders als GET (etwa mit 405 oder 403). Kommt ein Fehler nur im Monitor, probieren Sie beide Methoden aus. Die Sofortprüfung im Uptime Checker zeigt den Statuscode außerdem ohne Konto für eine einzelne Adresse.

Wie wertet ein Monitor Statuscodes aus – ein Rechenbeispiel

Die Verfügbarkeit berechnet sich als erfolgreiche Prüfungen geteilt durch gewertete Prüfungen; wie das im Detail abläuft, zeigt Verfügbarkeit berechnen.

Welche Entscheidungsregeln helfen im Alltag?

• Wenn 5xx: Serverseite prüfen (Logs, Dienste, Ressourcen). Hält der Fehler über mehrere Prüfungen an, ist es ein echter Ausfall.
• Wenn 403 nur im Monitor: Firewall oder Bot-Schutz vermuten und die Monitor-Kennung freigeben, nicht den Monitor abschalten.
• Wenn 404 auf einer wichtigen Seite: Zuerst prüfen, ob die URL sich geändert hat oder eine Rewrite-Regel fehlt; danach 301 setzen.
• Wenn 301 auf 301 auf 301: Kette verkürzen, jede zusätzliche Station kostet Zeit.
• Wenn 200, aber Inhalt falsch: Keyword-Monitor ergänzen.
• Wenn 429: Zu viele Anfragen von derselben Quelle; Limit anpassen statt Intervall unnötig zu verkürzen.

Welche Fehler passieren bei Statuscodes häufig?

Checkliste: Statuscodes im Griff

• Startseite liefert 200 (nach höchstens einer Weiterleitung von http auf https).
• Nicht vorhandene Adressen liefern einen echten 404, keine Seite mit 200.
• Dauerhafte Umzüge laufen über 301 oder 308, Ketten haben höchstens zwei Stationen.
• Der Wartungsmodus liefert 503, idealerweise mit Retry-After.
• Firewall und Bot-Schutz lassen den Monitor-User-Agent durch.
• Für kritische Seiten gibt es zusätzlich eine Inhaltsprüfung per Keyword.
• Für APIs ist der erwartete Erfolgscode bekannt (200, 201 oder 204).

Grenzen und Einordnung

Statuscodes sind ein Protokollsignal, kein Qualitätsurteil. Sie sagen nichts darüber, ob eine Seite korrekt dargestellt wird, ob JavaScript läuft oder ob der Warenkorb funktioniert. Ein Monitor sieht außerdem nur die Antwort an den Messstandort: Besteht ein Problem nur für bestimmte Regionen, Netze oder eingeloggte Nutzer, bleibt es unter Umständen unsichtbar. Hinzu kommt, dass Server sich nicht immer an die Konventionen halten; manche liefern bei Fehlern 200, andere melden 500, obwohl nur ein Teilbereich betroffen ist.

Aus diesen Gründen ersetzt die Auswertung von Statuscodes weder Fehlerprotokolle noch Nutzertests. Sie liefert aber in Sekunden die erste, belastbare Einordnung, ob Besucher überhaupt etwas erhalten.

Wie setzen Sie das mit UPTIMESHIELD um?

Der HTTP/HTTPS-Monitor ruft Ihre Adresse im gewählten Intervall auf, folgt Weiterleitungen und wertet den Endcode aus: 2xx gilt als Erfolg, 4xx und 5xx zählen als Fehlschlag. Eine fehlgeschlagene Prüfung wird sofort einmal wiederholt, und die Störung gilt standardmäßig erst nach 2 aufeinanderfolgenden Fehlschlägen (einstellbar von 1 bis 5). Für Soft-Fehler ergänzen Sie einen Keyword- oder API/JSON-Monitor; eine Übersicht aller acht Typen bietet die Seite Monitortypen.

So gehen Sie vor: Legen Sie ein kostenloses Solo-Konto an, erstellen Sie einen HTTP-Monitor für die Startseite und einen Keyword-Monitor für eine wichtige Unterseite, und hinterlegen Sie Ihre Benachrichtigungskanäle. Die Berechnung und das Statusmodell dahinter dokumentiert die Messmethodik.