HTTP-Statuscodes — Komplette Liste & Bedeutung

Der Server hat die Anfrage-Header erhalten, und der Client kann mit dem Senden des Body fortfahren.

Wann verwenden: Wird als Antwort auf eine Anfrage mit Expect: 100-continue gesendet, damit ein Client vorab prüfen kann, ob ein großer Upload akzeptiert wird, bevor er ihn überträgt.

Der Server stimmt zu, auf das im Upgrade-Header des Clients genannte Protokoll zu wechseln.

Wann verwenden: Beim Upgrade einer HTTP/1.1-Verbindung auf WebSocket (Upgrade: websocket).

WebDAV: Der Server hat die Anfrage angenommen, aber die Verarbeitung noch nicht abgeschlossen.

Wann verwenden: Verhindert, dass ein Client bei langen WebDAV-Vorgängen ein Timeout bekommt. Heute selten verwendet.

Erlaubt dem Server, Link-Header (Preload / Preconnect) zu senden, bevor die finale Antwort fertig ist.

Wann verwenden: Senden, während das Backend die Seite noch erzeugt, damit der Browser kritisches CSS, Fonts oder Skripte früher laden kann.

Die Anfrage war erfolgreich. Der Body enthält die angeforderte Ressource oder das Ergebnis der Aktion.

Wann verwenden: Die Standard-Erfolgsantwort für GET sowie für POST/PUT, wenn du einen Body zurückgibst.

SEO-Auswirkung: Der einzige Status, mit dem eine Seite samt Inhalt indexiert werden kann. Achte darauf, dass „Nicht gefunden“-Seiten keine 200 zurückgeben (ein „Soft 404“).

Die Anfrage war erfolgreich und eine neue Ressource wurde erstellt.

Wann verwenden: Nach einem POST (oder PUT), der etwas anlegt; füge einen Location-Header hinzu, der auf die neue Ressource zeigt.

Die Anfrage wurde zur Verarbeitung angenommen, die Verarbeitung ist aber noch nicht abgeschlossen.

Wann verwenden: Asynchrone Jobs: Stelle die Arbeit in eine Warteschlange und gib eine URL zurück, unter der der Client das Ergebnis abfragen kann.

Die Antwort wurde von einem transformierenden Proxy verändert und weicht von der 200-Antwort des Ursprungsservers ab.

Wann verwenden: Wird von Proxys gesetzt, die Inhalte verändern; Ursprungsserver sollten ihn normalerweise nicht senden.

Die Anfrage war erfolgreich und es gibt bewusst keinen Antwort-Body.

Wann verwenden: DELETE-Anfragen, Autosave-Endpunkte und CORS-Preflight-Antworten, bei denen nichts zurückgegeben werden muss.

Die Anfrage war erfolgreich und der Client soll die Dokumentansicht zurücksetzen (z. B. ein Formular leeren).

Wann verwenden: Selten; weist den User Agent an, das Formular zurückzusetzen, das die Anfrage gesendet hat.

Der Server liefert nur den Byte-Bereich, der mit einem Range-Header angefordert wurde.

Wann verwenden: Video-Streaming, fortsetzbare Downloads und Download-Manager.

WebDAV: Der Body ist ein XML-Dokument mit eigenen Statuscodes für mehrere Teilanfragen.

Wann verwenden: Stapelverarbeitung bei WebDAV, wenn einzelne Elemente erfolgreich sein oder fehlschlagen können.

WebDAV: Mitglieder einer Bindung wurden bereits früher in derselben 207-Antwort aufgeführt.

Wann verwenden: Verhindert, dass dieselbe Ressource innerhalb einer Multi-Status-Antwort wiederholt aufgelistet wird.

Der Server hat ein GET mit angewendeten Instanzmanipulationen (Delta-Encoding) beantwortet.

Wann verwenden: HTTP-Delta-Encoding (RFC 3229); in der Praxis fast nie zu sehen.

Die Ressource liegt in mehreren Darstellungen vor, und der Client (oder Nutzer) soll eine auswählen.

Wann verwenden: Selten; die Inhaltsauswahl erfolgt meist automatisch.

SEO-Auswirkung: Google kann eine der Optionen wählen; nutze besser eine einzelne 301 auf die kanonische Version.

Die Ressource hat eine neue dauerhafte URL, die im Location-Header angegeben ist.

Wann verwenden: Domain-Umzüge, HTTP → HTTPS, geänderte Slugs, Zusammenführen doppelter Seiten.

SEO-Auswirkung: Die Standardmethode, um eine Seite zu verschieben: Suchmaschinen übertragen Ranking-Signale und indexieren die neue URL. Browser können bei einer 301 POST zu GET ändern — nutze 308, wenn die Methode erhalten bleiben muss.

Die Ressource liegt vorübergehend unter einer anderen URL.

Wann verwenden: Kurzlebige Weiterleitungen wie Wartungsseiten, A/B-Tests oder Login-Abläufe.

SEO-Auswirkung: Google behandelt sie als temporär und behält meist die ursprüngliche URL im Index. Ist der Umzug dauerhaft, verwende 301.

Der Client soll das Ergebnis per GET von einer anderen URL abrufen.

Wann verwenden: Das Muster „Post/Redirect/Get“: Nach einem Formular-POST leitest du auf eine Bestätigungsseite weiter.

SEO-Auswirkung: Wird wie eine temporäre Weiterleitung behandelt.

Die gecachte Kopie ist noch gültig; es wird kein Body gesendet.

Wann verwenden: Antwort auf bedingte Anfragen (If-None-Match / If-Modified-Since), wenn sich die Ressource nicht geändert hat.

SEO-Auswirkung: Gut für die Crawl-Effizienz: Googlebot nutzt seine gecachte Kopie erneut und spart so Crawl-Budget.

Veraltet. Ursprünglich wurde der Client angewiesen, die Ressource über einen Proxy abzurufen.

Wann verwenden: Nicht verwenden — Browser ignorieren ihn aus Sicherheitsgründen.

Wie 302, aber der Client muss die Anfrage mit derselben Methode und demselben Body wiederholen.

Wann verwenden: Temporäre Weiterleitungen von POST/PUT-Anfragen; Browser zeigen bei HSTS-Upgrades außerdem „307 Internal Redirect“ an.

SEO-Auswirkung: Temporär — die ursprüngliche URL bleibt meist im Index.

Wie 301, aber der Client muss dieselbe Methode und denselben Body beibehalten.

Wann verwenden: Dauerhafte Umzüge von API-Endpunkten oder Formularzielen, bei denen ein POST ein POST bleiben muss.

SEO-Auswirkung: Google behandelt 308 wie 301 und überträgt die Signale auf die neue URL.

Der Server kann die Anfrage nicht verarbeiten, weil sie fehlerhaft ist (falsche Syntax, ungültiges JSON, zu großes Cookie …).

Wann verwenden: Validierungsfehler, die du nicht genauer beschreiben kannst; füge eine Fehlermeldung im Body hinzu.

SEO-Auswirkung: Seiten mit 4xx-Antworten werden aus dem Index entfernt.

Authentifizierung ist erforderlich und fehlte oder war ungültig. Trotz des Namens bedeutet er „nicht authentifiziert“.

Wann verwenden: Fehlendes oder abgelaufenes Token bzw. fehlende oder abgelaufene Zugangsdaten. Muss einen WWW-Authenticate-Header enthalten.

SEO-Auswirkung: Crawler können sich nicht anmelden, daher werden Seiten hinter 401 nicht indexiert — genau das willst du bei privaten Bereichen.

Für die zukünftige Nutzung reserviert; manche APIs verwenden ihn, wenn eine Zahlung oder ein Kontingent-Upgrade nötig ist.

Wann verwenden: Nicht standardisierte Abrechnungsfehler (z. B. ein abgelaufenes Abo).

Der Server hat die Anfrage verstanden, verweigert aber die Autorisierung. Erneutes Anmelden hilft nicht.

Wann verwenden: Der Nutzer ist angemeldet, hat aber keine Berechtigung, oder der Zugriff wird über IP, WAF oder Dateirechte blockiert.

SEO-Auswirkung: Nicht indexiert. Prüfe, ob deine Firewall oder dein Bot-Schutz Googlebot nicht versehentlich 403 zurückgibt.

Der Server kann die angeforderte Ressource nicht finden.

Wann verwenden: Die URL hat nie existiert oder wurde ohne Ersatz entfernt. Zeige eine hilfreiche eigene 404-Seite an.

SEO-Auswirkung: Normal und unschädlich für Seiten, die wirklich nicht existieren; Google entfernt sie mit der Zeit. Leite URLs mit Backlinks oder klarem Ersatz per 301 weiter.

Die HTTP-Methode wird für diese URL nicht unterstützt (z. B. POST an eine reine Lese-Seite).

Wann verwenden: Gib ihn mit einem Allow-Header zurück, der die unterstützten Methoden auflistet.

Der Server kann keine Antwort liefern, die den Accept-Headern der Anfrage entspricht.

Wann verwenden: Strikte Inhaltsauswahl; viele APIs liefern stattdessen einfach ihr Standardformat.

Wie 401, aber der Client muss sich am Proxy authentifizieren.

Wann verwenden: Wird von Unternehmens- oder Forward-Proxys mit einem Proxy-Authenticate-Header gesendet.

Der Server hat das Zeitlimit überschritten, während er darauf wartete, dass der Client das Senden der Anfrage abschließt.

Wann verwenden: Inaktive oder sehr langsame Verbindungen; Clients können es erneut versuchen.

Die Anfrage steht im Widerspruch zum aktuellen Zustand der Ressource.

Wann verwenden: Bearbeitungskonflikte, doppelte eindeutige Schlüssel oder Versionskonflikte beim optimistischen Sperren.

Die Ressource wurde dauerhaft entfernt und kommt nicht zurück.

Wann verwenden: Bewusst gelöschte Inhalte, abgelaufene Angebote oder Kampagnen.

SEO-Auswirkung: Google behandelt 410 wie 404, entfernt die URL aber eventuell etwas schneller.

Der Server verlangt einen Content-Length-Header.

Wann verwenden: Uploads ohne Längenangabe, wenn Chunked-Encoding nicht akzeptiert wird.

Eine Bedingung in den Anfrage-Headern (If-Match, If-Unmodified-Since) ergab „falsch“.

Wann verwenden: Optimistische Nebenläufigkeit: Lehne ein Update ab, weil sich die Ressource seit dem Lesen durch den Client geändert hat.

Der Body der Anfrage ist größer als vom Server erlaubt (früher „Payload Too Large“).

Wann verwenden: Datei-Uploads über deinem Limit — z. B. nginx’ client_max_body_size.

Die URL ist länger, als der Server verarbeiten kann.

Wann verwenden: Meist ein Bug: riesige Query-Strings oder Weiterleitungsschleifen, die immer weitere Parameter anhängen.

Das Format des Body (Content-Type) wird nicht unterstützt.

Wann verwenden: Eine API erwartet application/json, bekommt aber Formulardaten oder XML.

Der Range-Header fordert Bytes außerhalb der Datei an.

Wann verwenden: Fortsetzen eines Downloads hinter dem Ende einer Datei, die kleiner geworden ist.

Der Server kann die Anforderung im Expect-Header nicht erfüllen.

Wann verwenden: Ablehnen von Uploads mit Expect: 100-continue.

Ein Aprilscherz aus RFC 2324 (Hyper Text Coffee Pot Control Protocol): Der Server weigert sich, Kaffee zu kochen, weil er eine Teekanne ist.

Wann verwenden: Nur für Easter Eggs. Manche Dienste geben ihn zurück, um automatisierte oder unerwünschte Anfragen abzuweisen, er hat aber keine standardisierte Bedeutung.

Die Anfrage hat einen Server erreicht, der für diesen Host keine Antwort erzeugen kann.

Wann verwenden: Wiederverwendung von HTTP/2-Verbindungen über Hostnamen hinweg, deren Zertifikat oder Konfiguration nicht passt.

Die Syntax ist gültig, aber der Inhalt scheitert an der inhaltlichen Validierung.

Wann verwenden: Validierungsfehler bei Formularen oder APIs (fehlendes Pflichtfeld, ungültige E-Mail). Beliebt in Rails- und Laravel-APIs.

WebDAV: Die Ressource ist gesperrt.

Wann verwenden: Eine Datei ist von einem anderen Nutzer ausgecheckt oder gesperrt.

WebDAV: Die Anfrage ist fehlgeschlagen, weil eine vorherige Anfrage, von der sie abhing, fehlgeschlagen ist.

Wann verwenden: Stapelverarbeitung, bei der ein Fehler alle weiteren Vorgänge abbricht.

Der Server verarbeitet keine Anfrage, die möglicherweise wiederholt wird (TLS 1.3 Early Data / 0-RTT).

Wann verwenden: Schutz nicht-idempotenter Anfragen, die in TLS-Early-Data gesendet werden, vor Replay-Angriffen.

Der Client muss auf ein anderes Protokoll wechseln, das im Upgrade-Header genannt ist.

Wann verwenden: Clients auf eine neuere Protokollversion zwingen.

Der Server verlangt, dass die Anfrage bedingt ist (z. B. mit If-Match).

Wann verwenden: Verhindert „verlorene Updates“, indem unbedingte PUT/PATCH-Anfragen abgelehnt werden.

Der Client hat in einem bestimmten Zeitraum zu viele Anfragen gesendet (Rate Limiting).

Wann verwenden: API-Rate-Limits und Schutz vor Brute-Force-Angriffen. Füge einen Retry-After-Header hinzu.

SEO-Auswirkung: Googlebot verlangsamt sein Crawling, wenn er 429 (und 503) sieht. Dauerhafte 429er können dazu führen, dass URLs entfernt werden.

Ein Header (oft Cookie) oder alle Header zusammen sind zu groß.

Wann verwenden: Meist durch angesammelte Cookies verursacht; das Löschen der Cookies für die Seite behebt es für Nutzer.

Die Ressource ist aus rechtlichen Gründen gesperrt — Zensur, Gerichtsbeschlüsse oder regionale Vorschriften. Die Zahl verweist auf Ray Bradburys Fahrenheit 451.

Wann verwenden: Inhalte, die aufgrund einer Löschaufforderung entfernt oder gesetzlich geo-beschränkt wurden.

SEO-Auswirkung: Wird wie andere 4xx-Codes behandelt: nicht indexiert.

Ein allgemeiner Fehler: Der Server ist auf einen unerwarteten Zustand gestoßen.

Wann verwenden: Unbehandelte Exceptions, abgestürzte Skripte, kaputte .htaccess-Regeln. Prüfe deine Server-Logs.

SEO-Auswirkung: Kurze Ausfälle werden toleriert; bestehen 5xx-Fehler über Tage, drosselt Google das Crawling und entfernt irgendwann URLs.

Der Server unterstützt die benötigte Funktion nicht (oft eine unbekannte Methode).

Wann verwenden: Eine Methode, die der Server gar nicht kennt — im Gegensatz zu 405 für eine bekannte, aber nicht erlaubte Methode.

Ein Gateway oder Proxy hat eine ungültige Antwort vom vorgelagerten Server erhalten.

Wann verwenden: Dein App-Server (PHP-FPM, Node, Gunicorn) ist abgestürzt oder hat hinter nginx, einem Load Balancer oder einem CDN Unsinn zurückgegeben.

SEO-Auswirkung: Wie andere 5xx: Kurzzeitig ist es okay, dauerhafte Fehler schaden Crawling und Indexierung.

Der Server kann die Anfrage vorübergehend nicht bearbeiten — überlastet oder wegen Wartungsarbeiten nicht erreichbar.

Wann verwenden: Geplante Wartung oder Überlastung. Füge Retry-After hinzu, um anzugeben, wann der Client zurückkommen soll.

SEO-Auswirkung: Der richtige Code für geplante Ausfallzeiten: Google behält die Seite im Index und versucht es später erneut. Liefere ihn nicht länger als ein, zwei Tage aus.

Ein Gateway oder Proxy hat rechtzeitig keine Antwort vom vorgelagerten Server erhalten.

Wann verwenden: Langsame Datenbankabfragen oder vorgelagerte APIs, die das Proxy-Timeout überschreiten.

SEO-Auswirkung: Dauerhafte Timeouts senken die Crawl-Rate und können zur Deindexierung führen.

Der Server unterstützt die in der Anfrage verwendete HTTP-Version nicht.

Wann verwenden: Sehr alte oder sehr neue Protokollversionen, die ein Server nicht verarbeiten kann.

Fehlkonfiguration des Servers: Die gewählte Variante ist selbst so konfiguriert, dass sie verhandelt, was eine Schleife erzeugt.

Wann verwenden: Ein Konfigurationsfehler bei der Inhaltsauswahl.

WebDAV: Der Server kann die zur Vervollständigung der Anfrage nötige Darstellung nicht speichern.

Wann verwenden: Die Festplatte oder das Nutzerkontingent ist voll.

WebDAV: Der Server hat beim Verarbeiten der Anfrage eine Endlosschleife erkannt.

Wann verwenden: Manche Hoster (z. B. cPanel/CloudLinux) geben ihn auch zurück, wenn ein Konto seine Ressourcenlimits erreicht.

Weitere Erweiterungen der Anfrage sind erforderlich (RFC 2774, inzwischen historisch).

Wann verwenden: In der Praxis kaum verwendet.

Der Client muss sich authentifizieren, um Netzwerkzugriff zu erhalten.

Wann verwenden: Captive Portals in Hotel-, Flughafen- oder Café-WLANs.

nginx schließt die Verbindung, ohne eine Antwort zu senden.

Wann verwenden: In nginx konfiguriert, um schädliche oder unerwünschte Anfragen still zu verwerfen.

Wird von nginx protokolliert, wenn der Client die Verbindung schloss, bevor der Server geantwortet hat.

Wann verwenden: Du siehst ihn in Logs, wenn Nutzer die Seite verlassen oder ein Client-Timeout kürzer ist als deine Antwortzeit.

Cloudflare hat vom Ursprungsserver eine leere, unbekannte oder unerwartete Antwort erhalten.

Wann verwenden: Abstürze des Ursprungs, zu große Header oder Verbindungsabbrüche. Prüfe die Fehler-Logs des Ursprungs.

SEO-Auswirkung: Wird wie ein 5xx-Fehler behandelt.

Der Ursprungsserver hat die Verbindung von Cloudflare abgelehnt.

Wann verwenden: Der Webserver ist gestoppt oder eine Firewall blockiert die IP-Bereiche von Cloudflare.

SEO-Auswirkung: Wird wie ein 5xx-Fehler behandelt.

Cloudflare konnte keine TCP-Verbindung zum Ursprung aufbauen.

Wann verwenden: Überlasteter Ursprung, falscher DNS-Eintrag oder eine Firewall, die Pakete verwirft.

SEO-Auswirkung: Wird wie ein 5xx-Fehler behandelt.

Cloudflare hat sich mit dem Ursprung verbunden, doch dieser hat nicht innerhalb von 100 Sekunden geantwortet.

Wann verwenden: Lang laufende Anfragen; verschiebe sie in Hintergrund-Jobs.

SEO-Auswirkung: Wird wie ein 5xx-Fehler behandelt.

Der TLS-Handshake zwischen Cloudflare und dem Ursprung ist fehlgeschlagen.

Wann verwenden: Der Ursprung hat kein gültiges Zertifikat oder unterstützt weder SNI noch die TLS-Versionen, die Cloudflare verwendet.

SEO-Auswirkung: Wird wie ein 5xx-Fehler behandelt.

Cloudflare (im Modus Full Strict) konnte das Zertifikat des Ursprungs nicht validieren.

Wann verwenden: Abgelaufenes oder selbstsigniertes Zertifikat des Ursprungs — installiere ein gültiges oder ein Cloudflare Origin CA-Zertifikat.

SEO-Auswirkung: Wird wie ein 5xx-Fehler behandelt.