HTTP-Statuscodes erklärt: die, die wirklich verwechselt werden

Die erste Ziffer ist der einzige Teil, den manche Clients lesen

RFC 9110 verlangt, dass ein Client die Klasse eines Statuscodes versteht, auch wenn er den Code selbst nicht kennt, und Unbekanntes wie den x00 seiner Klasse behandelt. Ein Client, der 451 nie gesehen hat, behandelt ihn als 400; ein unbekannter 599 gilt als 500. Diese Regel macht den Raum erweiterbar, und sie bedeutet auch, dass die Klasse fast das gesamte Verhalten trägt: Caches entscheiden daran über Speicherbarkeit, Proxys über Wiederholungen, Crawler über Indexierung — meist bevor irgendetwas aus deinem Antwort-Body gelesen wird.

Praktisch heißt das: Ein 200 mit einem im Body beschriebenen Fehler versteckt das Scheitern dort, wo es sonst niemand sieht. Die Verfügbarkeitsprüfung meldet Grün, das CDN cacht die Fehlerseite, und eine Suchmaschine indexiert sie als echtes Dokument. Das ist das Soft-404-Problem in allgemeiner Form, und es lohnt eine Prüfung, denn die Korrektur ist eine Zeile beim Statuscode, nichts Architektonisches.

Umleitungen: welche dein POST erhalten

Das Vierer-Raster der Umleitungen kreuzt in Wahrheit zwei Fragen: dauerhaft oder temporär, und überlebt die Methode. 301 und 308 sind dauerhaft, 302 und 307 temporär; 307 und 308 sind die beiden, die dem Client jede Änderung der Anfrage verbieten. MDN sagt deutlich, warum es das neuere Paar gibt: 301 verlangte bereits, dass Methode und Body unverändert bleiben, doch ältere Clients setzten das falsch um und wechselten zu GET. Den Bestand konnte niemand reparieren, also wurden zwei neue Codes geprägt, deren Zusicherung in der Definition steht.

Die Wahl folgt also aus dem Verkehr. Für eine Seite, die nur GET erhält, ist 301 in Ordnung und Suchmaschinen sind daran am meisten gewöhnt. Für einen API-Pfad, ein Formularziel oder alles, was POST, PUT oder DELETE empfangen kann, nimm 308, dann kommt die Anfrage unversehrt an. Eine Warnung zur Dauerhaftigkeit: Browser cachen einen 301 aggressiv, manche deutlich länger als erwartet, sodass ein während eines Versuchs ausgelieferter 301 den Versuch auf Rechnern überlebt, auf die du keinen Zugriff hast. Liefere 302 oder 307 aus, solange noch entschieden wird.

Die am häufigsten falsch gelieferten Fehler

401 und 403 sind das Paar, das die meiste Supportzeit kostet. 401 heißt, der Anfrage fehlten gültige Anmeldedaten, und MDN merkt an, dass er mit einem WWW-Authenticate-Header gesendet wird, der das erwartete Verfahren beschreibt — eine Einladung, es mit Anmeldedaten erneut zu versuchen. 403 ist der umgekehrte Fall: Die Anmeldedaten sind vollkommen gültig, und der Client hat für diese Aktion dennoch keine Berechtigung. Ein 401 an einen angemeldeten Nutzer weist dessen Client an, sich neu anzumelden, was genau dieselbe Ablehnung erzeugt, und lässt den Nutzer glauben, seine Anmeldung sei kaputt, obwohl sie es nicht ist.

404 und 410 unterscheiden sich nur im Grad der Gewissheit, und genau darum geht es. MDN ist deutlich: Weiß der Serverbetreiber nicht, ob der Zustand vorübergehend oder dauerhaft ist, gehört dorthin ein 404. 410 nimmt man, wenn man die Sache absichtlich entfernt hat und sie nicht wiederkommt — er ist standardmäßig cachebar und sagt Crawlern, sie sollen aufhören zu fragen. Retry-After wiederum ist ein Header, der entweder eine Verzögerung in Sekunden oder ein HTTP-Datum trägt; bei einem 503 schätzt er, wie lange der Dienst nicht verfügbar ist, bei einem 429 nennt er die Wartezeit bis zur nächsten Anfrage. Er ist ein Hinweis, kein Vertrag, und MDN merkt an, dass die Unterstützung in Clients uneinheitlich ist — doch Googlebot beachtet ihn, was allein schon dafür spricht, ihn bei geplanter Wartung zu setzen.

Häufige Fragen

Sollte eine Website-Migration 301 oder 308 verwenden?

Für Seiten, die nur per GET abgerufen werden, ist 301 die sichere Vorgabe und das, was jeder Crawler und Proxy seit Jahrzehnten beherrscht. Greif zu 308 bei allem, was POST, PUT oder DELETE empfangen kann — Formularendpunkte, API-Routen, Webhook-Empfänger — denn dort verwandelt ein Client, der die Methode stillschweigend herabstuft, eine Umleitung in einen verlorenen Anfragekörper. Nichts spricht dagegen, beides in derselben Migration pro Route zu wählen.

Was sollte eine API bei fehlgeschlagener Validierung liefern?

Nimm 400 Bad Request, wenn die Anfrage selbst fehlerhaft ist und der Server sie nicht parsen kann — kaputtes JSON, ein fehlender Pflicht-Header. Nimm 422 Unprocessable Content, wenn die Syntax stimmt, der Inhalt aber deine Regeln bricht, etwa ein wohlgeformter Body mit einem Enddatum vor dem Startdatum. Nicht liefern solltest du einen 500, der einen Client-Fehler dem Server anlastet und dein Fehlerbudget verschmutzt, und auch keinen 200 mit dem Problem im Body, der das Scheitern vor jeder Schicht zwischen dir und dem Aufrufer verbirgt.

Schaden 404er dem Ranking?

Ein 404 ist eine gültige, ehrliche Antwort und ein normaler Bestandteil jeder Website, die schon eine Weile existiert; eine Seite, die es nicht mehr gibt, sollte das sagen. Der Schaden kommt von den Ersatzlösungen. Ein Soft-404 — eine nette Seite mit Status 200 — hält tote URLs im Index und verbraucht Crawl-Budget für nichts. Jede fehlende Seite pauschal auf die Startseite umzuleiten ist derselbe Fehler im 301-Gewand. War die Entfernung absichtlich und dauerhaft, sagt 410 es unmissverständlich.