HTTP-Statuscodes: der komplette Leitfaden zu allen Antwortcodes

Jede HTTP-Antwort beginnt mit einer dreistelligen Zahl, und diese Zahl ist die kürzestmögliche Auskunft des Servers darüber, was mit deiner Anfrage passiert ist. Meistens siehst du sie nie: die Seite lädt, der Browser macht weiter. Sichtbar wird die Zahl erst, wenn etwas schiefgeht – also genau dann, wenn du wissen musst, was sie bedeutet.

Statuscodes sind aber nicht nur Diagnose, sondern Anweisungen. Ein 301 sagt einer Suchmaschine, ihren Indexeintrag dauerhaft zu verschieben; ein 429 sagt einem Client genau, wie er sich zurücknehmen soll; ein 503 sagt einem Crawler, später wiederzukommen statt deine Seite zu entfernen. Den falschen Code zurückzugeben ist eine der leisesten Möglichkeiten, Traffic zu verlieren, denn sichtbar geht nichts kaputt. Dieser Leitfaden geht jede Klasse durch, die Codes, denen du wirklich begegnest, und wie du prüfst, was eine URL tatsächlich zurückgibt.

Warum Statuscodes wichtig sind

Vier Zielgruppen lesen deine Statuscodes, und jede handelt anders:

• Browser. Sie entscheiden, ob sie einer Weiterleitung folgen, eine Kopie aus dem Cache wiederverwenden und einen Formularinhalt erneut senden.
• Suchmaschinen. Der Code entscheidet, ob eine URL indexiert, mit einer anderen zusammengeführt, später erneut versucht oder verworfen wird. Eine freundliche „Nicht gefunden“-Seite mit 200 auszuliefern ist der klassische Fehler: dem Crawler wird gesagt, die Seite existiere, und er behält sie im Index.
• API-Clients. Gut geschriebene Clients verzweigen anhand des Codes. Ein 429 oder 503 lohnt einen erneuten Versuch; ein 400 nie, denn eine fehlerhafte Anfrage erneut zu senden erzeugt denselben Fehler.
• Dein eigenes Monitoring. Fehlerquoten und Alarme bauen fast immer auf Statuscodes auf. Ein Dienst, der 200 mit einem Fehler im Rumpf zurückgibt, ist für seine eigenen Dashboards unsichtbar.

Die fünf Klassen

Die erste Ziffer sagt dir, wer verantwortlich ist und was als Nächstes zu tun ist. Wenn du nur eines behältst, dann diese Tabelle.

Die Trennung zwischen 4xx und 5xx ist praktisch die wichtigste, denn sie beantwortet die einzige Frage, die während eines Vorfalls zählt: muss ich das beheben oder die andere Seite?

Die Codes, denen du wirklich begegnest

Es gibt Dutzende registrierte Codes, aber ein Arbeitstag umfasst vielleicht fünfzehn. Die Erfolgscodes sind die einfachsten. 200 OK ist die normale Antwort. 201 Created ist die richtige Antwort auf ein POST, das etwas erzeugt hat, und sollte einen Location-Header auf die neue Ressource tragen. 204 No Content sagt, die Anfrage war erfolgreich und es gibt absichtlich nichts zurückzusenden – die richtige Antwort auf ein DELETE. 206 Partial Content ist das, was Videosprünge und fortsetzbare Downloads möglich macht.

Weiterleitungen: 301, 302, 307 und 308

Weiterleitungen verursachen mehr SEO-Schaden als jede andere Klasse, fast immer weil die dauerhafte und die temporäre Form vertauscht werden.

• 301 Moved Permanently – die URL hat sich endgültig geändert. Suchmaschinen übertragen Ranking-Signale auf die neue Adresse und ersetzen die alte irgendwann im Index. Verwende es für Domain-Umzüge, den Wechsel von HTTP zu HTTPS und das Hinzufügen oder Entfernen von www.
• 302 Found – temporär. Die alte URL bleibt indexiert, weil du gesagt hast, sie kommt zurück. Verwende es für A/B-Tests, kurze Wartungsfenster und Geo-Routing, das du rückgängig machen willst.
• 307 Temporary Redirect – wie 302, aber Methode und Rumpf bleiben garantiert erhalten. Ein mit 307 weitergeleitetes POST kommt als POST an; historisch machten manche Clients aus einem weitergeleiteten POST ein GET.
• 308 Permanent Redirect – das dauerhafte Gegenstück zu 307: dieselbe Caching-Semantik wie 301, mit erhaltener Methode.
• 304 Not Modified – eigentlich keine Weiterleitung. Es antwortet auf eine bedingte Anfrage und heißt „deine Kopie im Cache ist noch gültig“ – deshalb überträgt eine gut konfigurierte Website weit weniger Daten, als ihr Seitengewicht vermuten lässt.

Zwei Regeln: verkette nie Weiterleitungen, wo ein Sprung genügt, denn jeder Sprung kostet Latenz und Crawl-Budget; und leite nie alle fehlenden Seiten auf die Startseite. Das Zweite sieht ordentlich aus und erzählt Nutzern wie Crawlern etwas Falsches.

Client-Fehler: 400, 401, 403, 404 und 429

Die 4xx-Familie sagt, dass die Anfrage selbst das Problem war. Die Unterschiede lohnen sich, denn Clients verhalten sich bei jedem anders.

• 400 Bad Request – fehlerhafte Syntax: kaputtes JSON, ein fehlendes Pflichtfeld, ein nicht interpretierbarer Parameter. So wie gesendet nie wiederholbar.
• 401 Unauthorized – falsch benannt; es bedeutet nicht authentifiziert. Keine Zugangsdaten oder solche, die der Server nicht prüfen konnte. Sollte einen WWW-Authenticate-Header enthalten.
• 403 Forbidden – der Server weiß, wer du bist, und du darfst es trotzdem nicht. Erneutes Anmelden hilft nicht.
• 404 Not Found – unter dieser URL existiert nichts. Der Server sagt nicht, ob je etwas existierte.
• 405 Method Not Allowed – die URL existiert, aber nicht für dieses Verb. Füge einen Allow-Header mit den erlaubten hinzu.
• 409 Conflict – die Anfrage kollidiert mit dem aktuellen Zustand, etwa ein doppelter Schlüssel oder eine veraltete Version.
• 410 Gone – die Ressource existierte und wurde absichtlich entfernt. Suchmaschinen verwerfen ein 410 schneller als ein 404, also die bessere Wahl, wenn du Inhalte bewusst zurückgezogen hast.
• 422 Unprocessable Content – die Syntax ließ sich lesen, aber die Werte scheitern an der Validierung. Nützlich, um „ich kann das nicht lesen“ von „ich habe es gelesen und es ist falsch“ zu trennen.
• 429 Too Many Requests – du hast ein Ratenlimit überschritten. Immer mit einem Retry-After-Header kombinieren; ohne ihn wiederholen Clients sofort und verschärfen die Überlast.

Server-Fehler: 500, 502, 503 und 504

Ein 5xx heißt, deine Anfrage war vernünftig und der Server versagte dennoch. Die vier häufigen zeigen auf verschiedene Schichten, was sie bei einem Vorfall wirklich nützlich macht.

• 500 Internal Server Error – eine unbehandelte Ausnahme in der Anwendung. Der generische Sammelcode und das Erste, wonach man in den Logs sucht.
• 502 Bad Gateway – ein Proxy oder Load Balancer erhielt eine ungültige oder leere Antwort vom Backend. Meist ist die Anwendung hinter dem Proxy abgestürzt oder hat nicht gelauscht.
• 503 Service Unavailable – der Server ist überlastet oder in Wartung. Das ist der einzige Code der Familie, den du absichtlich zurückgeben solltest, mit Retry-After-Header, während geplanter Ausfallzeit: Crawler behalten die Seite und kommen wieder.
• 504 Gateway Timeout – der Proxy hat auf das Backend gewartet und aufgegeben. Deutet auf eine langsame Abhängigkeit statt auf einen Absturz.

Während eines Ausfalls sagt dir der Unterschied zwischen 502 und 504, ob deine Anwendung gestorben oder nur langsam geworden ist – oft der schnellste verfügbare Hinweis.

Statuscodes und SEO

Suchmaschinen behandeln den Statuscode als die verbindliche Aussage über eine URL und vertrauen ihm mehr als allem im Seitenrumpf. Daraus folgen vier Dinge:

1. Soft-404s verschwenden Crawl-Budget. Eine „Seite nicht gefunden“-Meldung mit 200 hält eine tote URL im Index, wo sie mit deinen echten Seiten konkurriert. Gib ein echtes 404 oder 410 zurück.
2. Nutze 301 für dauerhafte Umzüge. Ein 302 bei einem echten Umzug lässt die alte URL im Index und teilt die Signale auf zwei Adressen auf.
3. Halte Weiterleitungsketten kurz. Jeder Sprung kostet Latenz, und Crawler folgen nur einer begrenzten Anzahl, bevor sie aufgeben. Lass die alte URL direkt auf das Endziel zeigen.
4. Gib während der Wartung 503 zurück. Ein 503 mit Retry-After sagt einem Crawler, wiederzukommen. Ein Timeout oder ein 500 sieht wie eine kaputte Website aus.

Weiterleitungen hängen auch mit HTTPS zusammen. Steht deine Weiterleitung von http:// auf https://, ist aber das Zertifikat ungültig oder abgelaufen, sehen Besucher eine Browser-Warnung, bevor die Weiterleitung überhaupt zählt. Es lohnt sich also, das Zertifikat gleich mit dem SSL Checker zu kontrollieren.

So prüfst du einen Statuscode

Dein Browser verbirgt den Code bei erfolgreichem Laden, du musst ihn also ausdrücklich erfragen. Drei verlässliche Wege:

1. Das Netzwerk-Panel des Browsers. Entwicklertools öffnen, neu laden und die Spalte Status lesen. Das zeigt die ganze Weiterleitungskette, was eine einzelne Zahl nicht kann.
2. curl -I https://example.com. Eine HEAD-Anfrage gibt Statuszeile und Header aus, ohne den Rumpf zu laden. Mit -L folgst du Weiterleitungen und siehst jeden Sprung.
3. Eine durchsuchbare Referenz. Wenn du die Zahl hast und Bedeutung, Pflichten und typische Ursachen brauchst, listet unsere Referenz der HTTP-Statuscodes jeden Code samt Handlungsempfehlung.

Zwei Dinge jenseits der Zahl selbst. Erstens: teste genau die URL, die ein Nutzer aufrufen würde, mit oder ohne Schrägstrich am Ende, denn beide lösen oft unterschiedlich auf. Zweitens: ist die Antwort ein 429, lies den Wert von Retry-After und prüfe, ob die Wartelogik deines Clients ihn wirklich beachtet; der Ratenlimit-Rechner macht aus einem Limit konkrete Abstände.

Häufige Fehler, die du vermeiden solltest

• 200 mit einem Fehler im Rumpf zurückgeben. Monitoring, Caches, Crawler und Clients lesen den Code, nicht dein JSON. Der folgenreichste Fehler der Liste.
• 302 für einen dauerhaften Umzug. Ranking-Signale bleiben an der alten URL, manchmal monatelang.
• Alle 404 auf die Startseite leiten. Das verbirgt defekte Links vor dir und erzeugt Soft-404s für Crawler.
• 403, wo 401 hingehört. Ein Client mit 403 versucht keine Anmeldung, denn 403 sagt, dass Authentifizierung nicht das Problem ist.
• 429 ohne Retry-After. Clients raten dann, meist auf „sofort“ – genau das Verhalten, das das Limit verhindern soll.
• Wartung als Timeout ausliefern. Gib 503 mit Retry-After zurück, damit deine Indexeinträge erhalten bleiben.
• Lange Weiterleitungsketten nach einer Migration. Jede Migration fügt einen Sprung hinzu; fasse sie beim nächsten Eingriff in die Regeln zu einem zusammen.

Prüfe deine eigenen Statuscodes

Statuscodes sind die günstigste Diagnose im Web: eine Zahl, keine Anmeldung und eine eindeutige Antwort darauf, ob eine URL funktioniert, umgezogen ist oder versagt hat. Prüfe zuerst, was deine wichtigen Seiten zurückgeben, stelle sicher, dass deine Weiterleitungen dort dauerhaft sind, wo sie es sein sollen, und dort temporär, wo es nötig ist, und sorge dafür, dass jeder Fehlerpfad einen Code zurückgibt, der zum Geschehenen passt.

Verwandte Tools und Leitfäden:

• HTTP-Statuscodes – durchsuchbare Referenz für jeden Antwortcode.
• Ratenlimit-Rechner – macht aus einem Limit sichere Abstände und ein Retry-After.
• DNS-Abfrage – prüfe, ob eine Domain auflöst, bevor du ihre Antworten debuggst.
• SSL Checker – kontrolliere das Zertifikat hinter deiner HTTPS-Weiterleitung.
• 301 oder 302: Welche Weiterleitung, und was SEO sieht - welche Weiterleitung passt und was jede für dein Ranking bedeutet.
• 404 oder 410: Was beides Google über eine gelöschte Seite sagt - was jeder Code Google über eine gelöschte Seite sagt.

Häufige Fragen