HTTP-Statuscodes verstehen 2026: von 200 bis 500 erklärt

Jede Anfrage im Web bekommt eine dreistellige Antwort zurück, die die meisten Menschen nur als 404 kennen. Dabei steckt hinter jeder Zahl eine präzise Aussage: Ist die Sache dauerhaft weg oder nur verschoben? Darfst du nicht rein, oder hast du dich nur nicht angemeldet? Liegt der Fehler bei dir oder beim Server? Dieser Artikel sortiert die fünf Statuscode-Klassen, erklärt die Codes, die im Alltag wirklich zählen – und zeigt, warum der falsche Code deine API und dein SEO teuer zu stehen kommt.

Die fünf Klassen: was die erste Ziffer verrät

Ein HTTP-Statuscode ist eine dreistellige Zahl, die der Server als Teil jeder Antwort mitschickt. Die maßgebliche Definition steht seit Juni 2022 in RFC 9110 (»HTTP Semantics«), der die früher auf mehrere Dokumente verteilten Regeln zusammenfasst. Die verbindliche Liste aller vergebenen Codes pflegt die IANA in ihrem HTTP Status Code Registry.

Entscheidend ist die erste Ziffer, denn sie legt die Klasse fest: 1xx ist informativ (die Anfrage läuft noch), 2xx bedeutet Erfolg, 3xx ist eine Umleitung, 4xx markiert einen Fehler beim Client – also bei dir oder deinem Browser – und 5xx steht für einen Fehler auf dem Server. Diese grobe Einteilung reicht schon, um 90 Prozent aller Fälle richtig einzuordnen.

Die 1xx-Klasse begegnet dir selten direkt. Interessant ist 103 Early Hints: Damit schickt ein Server schon Hinweise auf nachzuladende Ressourcen, während er die eigentliche Antwort noch baut. Der Rest des Artikels dreht sich um die Codes, die du täglich siehst.

2xx: Erfolg ist nicht gleich Erfolg

Der bekannteste Code ist 200 OK: Die Anfrage war erfolgreich, die Antwort enthält die gewünschten Daten. Für einfache GET-Aufrufe ist das richtig. Doch »erfolgreich« lässt sich präziser ausdrücken, und gerade in APIs lohnt sich die Unterscheidung.

201 Created gehört an das Ende eines erfolgreichen POST, der eine neue Ressource angelegt hat – einen neuen Nutzer, eine neue Bestellung. Zusätzlich gehört in die Antwort ein Location-Header, der auf die Adresse der frisch erzeugten Ressource zeigt. Ein Client weiß dann sofort, wo das neue Objekt zu finden ist, ohne raten zu müssen.

204 No Content ist das Signal »hat geklappt, es gibt aber nichts zurückzugeben«. Typisch nach einem DELETE oder einem PUT, bei dem der Client den neuen Zustand ohnehin schon kennt. Der leere Body ist Absicht. Wer stattdessen ein 200 mit null schickt, zwingt Clients zu unnötigen Sonderfällen.

3xx: 301, 302, 307 und 308 sind nicht austauschbar

Umleitungen sehen von außen gleich aus – der Browser landet auf einer anderen URL – unterscheiden sich aber in zwei Punkten: Ist die Umleitung dauerhaft oder temporär, und darf sich dabei die HTTP-Methode ändern?

301 Moved Permanently sagt: Die Ressource ist für immer umgezogen, merk dir die neue Adresse. Suchmaschinen übertragen den Ranking-Wert auf das Ziel, Browser cachen die Umleitung teils aggressiv. 302 Found dagegen heißt »vorübergehend woanders«, die alte URL bleibt die kanonische. Historisch teilen sich beide ein Problem: Viele Clients ändern bei der Umleitung ein POST fälschlich in ein GET.

Genau das beheben die neueren Codes. 307 Temporary Redirect ist das saubere temporäre Pendant zu 302 und garantiert, dass Methode und Body erhalten bleiben – aus einem POST wird auch nach der Umleitung ein POST. 308 Permanent Redirect (RFC 9110, Abschnitt 15.4.9) ist das methoden-treue Gegenstück zu 301. Faustregel: Für dauerhafte Umzüge von Seiten nimm 301; muss die Methode erhalten bleiben, nimm 308 bzw. 307.

Redirect-Ketten: der stille SEO-Killer

Eine einzelne Umleitung ist billig. Problematisch wird es, wenn sich Umleitungen aneinanderreihen: Die alte HTTP-Seite zeigt per 301 auf HTTPS, das wiederum auf die www-Variante, die dann noch auf eine neue URL-Struktur umleitet. Jeder Sprung kostet einen zusätzlichen Roundtrip und damit Ladezeit.

Für Suchmaschinen sind solche Ketten doppelt schädlich. Google folgt zwar mehreren Weiterleitungen, bricht aber nach einer gewissen Zahl ab, und mit jedem Sprung droht eine Verwässerung der Signale. Noch teurer sind Redirect-Schleifen, bei denen sich zwei URLs gegenseitig umleiten – der Browser bricht dann mit einem Fehler ab, die Seite ist gar nicht mehr erreichbar.

Die Lösung ist unspektakulär: Leite immer direkt auf das endgültige Ziel um, nicht auf die nächste Zwischenstation. Legst du eine neue Weiterleitung an, prüfe, ob das Ziel selbst schon weiterleitet, und verkürze die Kette auf einen einzigen Sprung.

304 Not Modified: der Code, der Bandbreite spart

304 Not Modified ist kein Fehler, sondern ein Effizienz-Signal. Der Client fragt: »Hat sich diese Ressource seit meinem letzten Besuch geändert?« Wenn nicht, antwortet der Server mit 304 und einem leeren Body – der Browser nimmt die Datei aus seinem Cache. Das spart Übertragungsvolumen, gerade bei großen Bildern oder Skripten.

Technisch läuft das über bedingte Anfragen. Der Server schickt beim ersten Mal einen ETag (einen Fingerabdruck des Inhalts) oder ein Last-Modified-Datum mit. Beim nächsten Aufruf sendet der Browser den Wert im Header If-None-Match bzw. If-Modified-Since zurück. Stimmt der Fingerabdruck, gibt es das 304.

401 gegen 403: angemeldet oder berechtigt?

Diese beiden Codes werden ständig verwechselt, obwohl ihre Bedeutung klar getrennt ist. 401 Unauthorized heißt eigentlich »nicht authentifiziert«: Der Server weiß nicht, wer du bist. Es fehlt eine gültige Anmeldung oder ein Token. Der korrekte Umgang: eine Anmeldung nachreichen, dann erneut anfragen. Zur 401 gehört pflichtgemäß ein WWW-Authenticate-Header, der sagt, wie man sich anmelden soll.

403 Forbidden dagegen bedeutet »nicht autorisiert«: Der Server weiß genau, wer du bist – aber du darfst trotzdem nicht. Ein eingeloggter Nutzer, der eine fremde Rechnung abrufen will, bekommt korrekt ein 403. Eine erneute Anmeldung hilft nichts, denn das Problem sind die Rechte, nicht die Identität.

Die Merkregel: 401 = »ich weiß nicht, wer du bist«, 403 = »ich weiß es, und die Antwort ist nein«. Aus Sicherheitsgründen wählen manche Anwendungen bewusst 404 statt 403, um die Existenz einer geschützten Ressource gar nicht erst zu verraten.

404 gegen 410: weg oder für immer weg?

404 Not Found ist der Klassiker: Unter dieser URL liegt nichts. Der Code lässt bewusst offen, warum – vielleicht gab es die Seite nie, vielleicht ist sie temporär offline, vielleicht hast du dich vertippt. Für Suchmaschinen bedeutet das: »Vielleicht komme ich später nochmal vorbei.«

410 Gone ist die härtere, ehrlichere Variante: Die Ressource existierte, wurde aber absichtlich und dauerhaft entfernt und kommt nicht zurück. Google entfernt 410er schneller aus dem Index als 404er, weil die Aussage eindeutiger ist.

Für den Alltag heißt das: Bei Tippfehlern und unbekannten Pfaden ist 404 richtig. Schaltest du dagegen bewusst Inhalte ab und willst sie zügig aus den Suchergebnissen entfernen, ist 410 die passende Wahl.

429: wenn du zu schnell klopfst

429 Too Many Requests ist der Code des Rate-Limitings. Der Server sagt: »Du hast in zu kurzer Zeit zu viele Anfragen geschickt, drossle das Tempo.« APIs setzen das ein, um sich vor Überlastung und Missbrauch zu schützen.

Zur 429 gehört idealerweise ein Retry-After-Header, der als Sekundenzahl oder als Datum angibt, wann du es wieder versuchen darfst. Ein gut gebauter Client wertet diesen Header aus und wartet genau so lange – statt stur weiterzuhämmern und das Limit noch länger zu triggern. Wer regelmäßig 429er kassiert, sollte auf ein exponentielles Backoff setzen: nach jedem Fehlschlag länger warten (1, 2, 4, 8 Sekunden), gern mit etwas Zufall, damit nicht alle Clients gleichzeitig wieder loslegen.

5xx: der Fehler liegt am Server

Sobald die erste Ziffer eine 5 ist, hast du meist nichts falsch gemacht. 500 Internal Server Error ist der Sammelbegriff: Irgendwo im Server-Code ist etwas schiefgegangen, eine unbehandelte Ausnahme, ein Bug. Der Code sagt nur »kaputt«, nicht »warum« – die Ursache steht in den Server-Logs.

Die anderen drei zeigen auf die Infrastruktur davor, meist einen Reverse Proxy oder ein Gateway. 502 Bad Gateway: Das Gateway hat vom Backend eine ungültige Antwort erhalten – oft weil der Backend-Prozess abgestürzt ist. 503 Service Unavailable: Der Dienst ist vorübergehend nicht verfügbar, etwa wegen Wartung oder Überlast; hier passt ein Retry-After-Header gut.

504 Gateway Timeout schließlich heißt: Das Gateway hat gewartet, aber der Backend-Server hat nicht rechtzeitig geantwortet – meist wegen einer zu langsamen Datenbankabfrage oder eines hängenden externen Aufrufs. Die Unterscheidung hilft beim Debugging: 502 deutet auf einen Crash, 504 auf Langsamkeit – zwei völlig verschiedene Baustellen.

418 und andere Kuriositäten

Nicht jeder Code ist bierernst. 418 I'm a teapot stammt aus einem Aprilscherz-RFC von 1998, dem »Hyper Text Coffee Pot Control Protocol«: Eine Teekanne, die gebeten wird, Kaffee zu kochen, antwortet standesgemäß mit 418. Der Code ist bei der IANA offiziell als reserviert vermerkt und taucht bis heute in vielen Frameworks als Easter Egg auf.

Andere Kuriositäten sind 451 Unavailable For Legal Reasons – eine Anspielung auf Ray Bradburys Roman »Fahrenheit 451«, verwendet bei rechtlich gesperrten Inhalten – und 402 Payment Required, das jahrzehntelang reserviert war und erst mit Bezahl-APIs langsam echte Verwendung findet. Der Punkt dahinter: Wer die Logik des Systems versteht, liest an einer dreistelligen Zahl mehr ab als an drei Absätzen Fehlermeldung.

Praxis: richtige Codes setzen und Fehler jagen

Beim Bau einer API ist der Statuscode Teil der Schnittstelle, genauso wichtig wie das JSON. Ein häufiger Anfängerfehler: Alles mit 200 beantworten und den echten Zustand in ein Feld wie "error": true packen. Das zwingt jeden Client, den Body zu parsen, bevor er weiß, ob etwas schiefging, und macht Monitoring blind für Fehler.

Setz die Codes stattdessen semantisch: 400 für kaputte Eingaben, 401/403 für Auth-Probleme, 404 für nicht Gefundenes, 422 für inhaltlich ungültige, aber syntaktisch korrekte Daten, 201 nach dem Anlegen. So versteht jeder HTTP-Client deine Antwort ohne Sonderwissen.

Beim Debugging führt der schnellste Weg über die Kommandozeile: curl -I https://beispiel.de zeigt nur die Header samt Statuscode, curl -IL folgt zusätzlich allen Umleitungen und legt Redirect-Ketten offen. Im Browser leistet der Netzwerk-Tab dasselbe und färbt 4xx/5xx rot ein – ein Blick verrät, ob der Fehler bei dir oder beim Server sitzt.

Was Tools auf CalcSI helfen

Wenn du im Alltag mit HTTP-Antworten hantierst, nimm dir die Nachschlage-Referenz HTTP-Statuscodes zur Hand: Dort findest du jeden Code samt Klasse und Bedeutung, ohne die RFC durchzublättern. Steckt in einer fehlerhaften URL oder einem Location-Header ein kodierter Parameter, machst du ihn mit dem URL-Encoder/Decoder lesbar und erkennst, wohin eine Umleitung wirklich zeigt. Kommt eine API-Antwort verschachtelt und unformatiert zurück, bringt der JSON-Formatter Struktur hinein, sodass du Fehlerobjekte und Felder sofort überblickst. Und wenn du Logfiles nach bestimmten Statuscodes durchsuchen willst – etwa allen 5xx-Zeilen –, baust du dir mit dem Regex-Tester das passende Muster wie \s5\d{2}\s und prüfst es direkt am Beispieltext. Alle vier laufen komplett im Browser.