HTTP-Statuscodes im Überblick
Kein Raten mehr bei 401 vs. 403: eine entwicklerzentrierte Tour durch alle Statusfamilien mit realistischen Beispielen, Anti-Patterns und den Codes, die für SEO wirklich zählen.
Weitere Utilities, die gut zu dieser Anleitung passen:
Warum das wichtig ist
Ein Backend liefert 200 OK mit {"error": "Unauthorized"} im Body. Das Frontend behandelt das als Erfolg, weil der Status 200 war — die Login-Maske hängt in einer Schleife. Kleine Status-Fehler kosten echte Engineering-Stunden und verzerren SEO-Crawls sowie Broken-Link-Reports. Zu wissen, welchen Code Sie wann senden, gehört zum Handwerk.
Drei echte Szenarien
Anfrage ohne Token? 401. Token ohne Berechtigung? 403. Ressource existiert nicht? 404.
Vorhersagbares Client-Verhalten
301 behält PageRank; 302 signalisiert temporär, ohne Rank-Transfer. Bewusst wählen.
Permanente Weiterleitung, Ranking übernommen
503 mit Retry-After-Header sagt Crawlern: später wiederkommen — statt zu de-indexieren.
Suchmaschinen wissen: später erneut versuchen
Die fünf Familien auf einen Blick
| Range | Family | Common members |
|---|---|---|
| 1xx | Informational | 100 Continue, 101 Switching Protocols |
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirection | 301, 302, 304 Not Modified, 308 |
| 4xx | Client Error | 400, 401, 403, 404, 422, 429 |
| 5xx | Server Error | 500, 502, 503, 504 |
Schritt für Schritt — die Status-Referenz nutzen
Öffnen Sie die HTTP-Status-Referenz.
Nach Code oder Beschreibung suchen
„401“, „unauthorized“ oder „rate limit“ eingeben — passende Codes steigen nach oben.
Kanonische Bedeutung lesen
Jeder Eintrag erklärt die Spezifikation — nicht nur, was curl ausgibt.
Praxisnutzung sehen
Hinweise nennen Abweichungen bekannter APIs (GitHub, Stripe, AWS).
SEO-Auswirkung erkennen
Codes sind mit Suchmaschinenbehandlung markiert (indexierbar / nicht, Rank-Transfer / nicht).
Einzeiler kopieren
Beschreibung in API-Doku oder Code-Kommentar übernehmen.
Szenario
POST /admin/users
(No Authorization header)Empfohlene Antwort
401 Unauthorized
WWW-Authenticate: Bearer realm="admin"Szenario
POST /admin/users
Authorization: Bearer eyJ... (valid token, viewer scope)Empfohlene Antwort
403 Forbidden
{"error": "scope_admin_required"}
Profi-Tipps
- 422 für „formal korrekt, semantisch ungültig“ (z. B. JSON mit falschen Feldtypen). 400 für fehlerhaft formatierte Anfragen.
- 204 No Content bei Deletes ist klarer als 200 mit leerem Body — signalisiert bewusst keine Nutzlast.
Retry-Afterbei 429 / 503 immer mitschicken. Gibt klientenseitig das erwartete Wiederholungsdatum vor.- Kein 200 mit
error: ...im Body. Das untergräbt HTTP-Semantik und verwirrt jedes Monitoring.
Typische Stolpersteine
Stolperstein
"Zugriff verweigert" als 404 zurückgeben
Ein vages 404 verbirgt Existenz — manchmal gewollt (z. B. private Repos); bei normalen authentifizierten APIs lieber 403, damit Clients das Auth-Problem erkennen.
Stolperstein
302 für immer cachen
302 ist per Spezifikation temporär, manche Proxys cachen aggressiv. Bei permanenter Weiterleitung 301 senden (oder 308, um die Methode zu erhalten).
Stolperstein
500 bei Client-Fehlern
500 bedeutet Server-Fehler. Bei schlechten Client-Daten 4xx zurückgeben — sonst feuert Ihr Alerting für einen Bug im Client-Code.
Wann dieses Tool nicht passt
- Neues Protokoll designen — HTTP-Status gehört zu HTTP; gRPC, WebSockets und proprietäre Protokolle haben eigene Konventionen.
- In-App-Fehlercodes — gehören neben den HTTP-Code in den Response-Body.
- Monitoring — Ihr APM sollte Status automatisch klassifizieren; diese Referenz dient Designentscheidungen vor dem Rollout.
FAQ
Unterschied zwischen 301 und 308?
Beides sind permanente Weiterleitungen. 308 garantiert Erhalt der HTTP-Methode; 301 erlaubte historisch POST → GET beim Folgen.
Ja, RFC 2324 (1. April 1998), bestätigt in RFC 7168. Ein Scherz-Response, in Produktions-APIs unüblich.
Framework-spezifische Codes (z. B. 419, 440) exponieren?
Wenn möglich vermeiden. Bei IANA registrierten Codes bleiben generische Clients kompatibel.
Nächste Schritte
- Antworten beim Debuggen mit dem URL-Parser inspizieren.
- Git- oder Linux-Befehle beim Triage in den Referenzen Git-Befehle und Linux-Befehle nachschlagen.
- IP/ASN des Upstreams mit dem IP-Lookup prüfen, wenn 502/504 auf nachgelagerte Systeme deuten.