HTTP-Statuscode: Was er ist und welche Codes Ihre Sichtbarkeit kosten

Der HTTP-Statuscode ist das erste Signal jeder Webserver-Antwort und steuert, wie Crawler und Clients mit einer URL weiter umgehen. Vor diesem dreistelligen Code passiert weder Indexierung noch Anzeige im Browser. Bei einem Industrie-Relaunch mit mehreren tausend Produkt-URLs entscheidet die Statuscode-Sauberkeit darüber, ob bestehende Sichtbarkeit erhalten bleibt oder im Indexierungsbericht der Google Search Console wegbricht.

Was ist ein HTTP-Statuscode?

Ein HTTP-Statuscode ist die kategorische Antwort eines Webservers auf eine HTTP-Anfrage. Der Code besteht aus drei Ziffern und einer Klartext-Beschreibung (englisch Reason Phrase), beispielsweise 200 OK oder 404 Not Found. Er erscheint in der ersten Zeile der Server-Antwort, der sogenannten Statuszeile, und wird vor dem eigentlichen Inhalt übertragen.

Die zentrale Spezifikation für HTTP-Statuscodes ist RFC 9110 (HTTP Semantics), seit Juni 2022 der offizielle Standard. RFC 9110 hat den älteren RFC 7231 abgelöst und gilt protokoll-versions-übergreifend für HTTP/1.1, HTTP/2 und HTTP/3. Das verbindliche Register aller offiziellen Codes führt die IANA im HTTP Status Code Registry.

Der Statuscode steuert, wie Browser, Crawler und Caches mit der URL weiter umgehen: ob sie den Inhalt anzeigen, der Weiterleitung folgen, die Anfrage als gescheitert behandeln oder einen Server-Fehler protokollieren. Damit ist der Code in der SEO-Diagnose der erste Indikator, ob eine URL überhaupt erreichbar und crawlbar ist.

Wie funktioniert ein HTTP-Statuscode?

Jede Interaktion zwischen Client (Browser, Crawler, App) und Server folgt dem Request-Response-Zyklus. Der Client sendet eine HTTP-Anfrage an eine URL; der Server antwortet mit drei Bestandteilen: einer Statuszeile (mit dem Statuscode), einem Header-Block (mit Meta-Informationen wie Content-Type, Cache-Control, Location) und optional einem Antwortkörper (HTML, JSON, Bild, Datei).

Der Statuscode ist die erste Information, die der Client liest. Er entscheidet auf Basis dieses Codes, was als Nächstes geschieht:

• Bei 2xx rendert der Browser den Inhalt, der Crawler übergibt die Seite an die Indexierungs-Pipeline.
• Bei 3xx folgt der Client dem Location:-Header und ruft die neue URL auf.
• Bei 4xx interpretiert der Client den Fehler; bei wiederholten 404-Antworten entfernt Google die URL aus dem Index.
• Bei 5xx versucht der Crawler die URL später erneut, der Browser zeigt eine Fehlerseite.

Erst nach dieser Code-Auswertung kommen Inhalt, Markup oder Caching ins Spiel. Diese Reihenfolge ist die zentrale Begründung dafür, warum Statuscode-Hygiene jeder Content-Optimierung vorausgeht: Wer zuerst Inhalte oder Meta-Tags optimiert, ohne die Statuscodes zu prüfen, riskiert, an Seiten zu arbeiten, die der Crawler überhaupt nicht oder mit dem falschen Code erreicht.

Der Statuscode kommt nie isoliert: Er steht in der Statuszeile zusammen mit der HTTP-Versionsangabe (etwa HTTP/2 200), gefolgt vom Header-Block und gegebenenfalls einem Antwortkörper. Header wie Cache-Control, ETag oder Last-Modified ergänzen den Code mit Caching-Anweisungen, der Location-Header trägt bei 3xx-Codes die Ziel-URL, und der Retry-After-Header signalisiert bei 503-Antworten, wann ein erneuter Aufruf erfolgen darf. Diese Header-Kombinatorik erklärt, warum zwei Antworten mit demselben Code (etwa 301) unterschiedlich gecacht und unterschiedlich von Crawlern interpretiert werden können.

Da RFC 9110 die Semantik protokoll-versions-übergreifend definiert, gelten dieselben Statuscodes für HTTP/1.1, HTTP/2 und HTTP/3. Der Wechsel auf HTTP/3 (über das QUIC-Transport-Protokoll) verändert die Übertragung, aber nicht die Statuscode-Logik: Eine 301-Antwort bleibt eine 301-Antwort, egal welche Protokoll-Version den Server-Client-Dialog trägt.

Welche HTTP-Statuscodes gibt es?

HTTP-Statuscodes sind dreistellig und in fünf Klassen organisiert. Die erste Ziffer signalisiert die Klasse; die folgenden beiden Ziffern spezifizieren den konkreten Status innerhalb der Klasse.

Insgesamt führt das IANA-Register über 60 offiziell registrierte Codes plus Reserve-Bereiche. Für die Praxis im technischen Mittelstand sind aber nur etwa 12-15 Codes routinemäßig relevant.

1xx: Informativ

1xx-Codes sind Zwischenantworten, die der Server vor der eigentlichen Antwort schickt. Sie kommen in der Praxis selten direkt zum Tragen, weil Browser und Crawler sie meist intern behandeln. Praxis-relevant sind zwei Codes: 100 Continue (der Server bestätigt, dass der Client mit dem Senden eines großen Request-Bodys fortfahren darf, etwa beim Upload von technischen Dokumenten oder Datenblättern) und 103 Early Hints (ein Hinweis auf vorgelagerte Ressourcen, der das Vorab-Laden von Stylesheets und Skripten erlaubt, bevor die finale 200-Antwort kommt).

Für die SEO-Diagnose sind 1xx-Codes irrelevant: Googlebot wertet sie nicht als Crawl-Ergebnis, sie tauchen in den Crawl-Statistiken der Search Console auch nicht als eigene Klasse auf.

2xx: Erfolg

2xx-Codes melden eine erfolgreiche Verarbeitung. Der wichtigste Code ist 200 OK: die Anfrage wurde erfolgreich beantwortet, der Server liefert den Inhalt aus. Weitere relevante Codes der Klasse: 201 Created (für API-Endpunkte nach erfolgreicher Ressourcen-Erzeugung), 204 No Content (die Anfrage war erfolgreich, der Server hat aber bewusst keinen Antwortkörper) und 206 Partial Content (Teil-Antwort bei Range-Requests, etwa für Streaming oder fortgesetzte Downloads).

In B2B-Audits ist 200 OK der Standardwert: Wenn eine Produktseite, ein Datenblatt oder eine Kategorie-URL diesen Code zurückliefert, ist sie technisch erreichbar. Ob sie deshalb auch indexiert wird, ist eine separate Frage (siehe Sektion zur SEO-Relevanz).

3xx: Weiterleitung

3xx-Codes fordern den Client auf, eine andere URL aufzurufen. Die wichtigsten Vertreter dieser Klasse: 301 Moved Permanently (dauerhaft, mit Konsolidierung von Ranking-Signalen), 302 Found (temporär), 307 Temporary Redirect (temporär, die HTTP-Methode bleibt erhalten), 308 Permanent Redirect (dauerhaft, Methode bleibt erhalten) und 304 Not Modified (eine Cache-Antwort: der Inhalt hat sich seit der letzten Anfrage nicht geändert).

Bei jeder Migration entscheidet die korrekte Wahl zwischen 301 und 302 darüber, ob die akkumulierten Ranking-Signale auf die neue URL übertragen werden oder bei der alten Adresse verbleiben. 304 ist hingegen ein Performance-Code: er reduziert das Crawl-Volumen für unveränderte Seiten, weil der Server keinen vollständigen Antwortkörper sendet.

4xx: Client-Fehler

4xx-Codes signalisieren, dass der Client einen Fehler in der Anfrage gemacht hat. SEO-relevant sind vor allem vier Codes: 404 Not Found (die Ressource existiert nicht), 410 Gone (die Ressource wurde dauerhaft entfernt, ein schnelleres Deindexierungs-Signal als 404), 403 Forbidden (Zugriff verweigert, oft falsch konfiguriert) und 429 Too Many Requests (Rate-Limiting, das Googlebot ausbremsen kann). Hinzu kommt 400 Bad Request für syntaktisch fehlerhafte Anfragen, das aber meist nur in API-Kontexten auftaucht.

Bei großen B2B-Katalogen ist der 4xx-Anteil im Crawl-Statistiken-Bericht ein zentraler Frühindikator: ein Sprung von zwei auf zehn Prozent nach einem Relaunch zeigt verlässlich, dass das Redirect-Mapping unvollständig war.

5xx: Server-Fehler

5xx-Codes melden, dass der Server eine valide Anfrage nicht verarbeiten konnte. Praxis-relevant: 500 Internal Server Error (genereller Server-Fehler), 502 Bad Gateway (der Upstream-Server antwortet nicht korrekt, häufig bei Reverse-Proxy-Setups), 503 Service Unavailable (Server überlastet oder in Wartung; mit Retry-After-Header für geplante Wartungsfenster) und 504 Gateway Timeout (der Upstream-Server antwortet nicht in der vorgegebenen Zeit).

Wiederholte 5xx-Antworten an Googlebot wirken sich direkt auf das Crawl-Verhalten aus: Google reduziert dann die Crawl-Frequenz und verlangsamt damit die Verarbeitung neuer oder aktualisierter Inhalte. Bei Industrie-Sites mit Lastspitzen (Messezeiten, Kampagnen-Launches) ist das ein häufig übersehener Hebel der technischen SEO.

Welche HTTP-Codes sind für SEO wichtig?

Für die Suchmaschinenoptimierung sind aus den über 60 offiziellen Codes vor allem sieben Statuscodes entscheidend. Sie tauchen in praktisch jedem technischen SEO-Audit, jeder Migrations-Diagnose und jedem GSC-Monitoring routinemäßig auf, weil sie darüber entscheiden, ob eine URL indexiert, weitergeleitet oder verworfen wird:

Die meisten Agenturen optimieren Title-Tags, bevor sie überhaupt prüfen, ob die Status-Verteilung der eigenen Domain im Crawl-Statistiken-Bericht plausibel ist. Eine Domain mit 12 Prozent 4xx-Anteil und schwankender 5xx-Rate verliert Crawl-Budget, egal wie gut die Title-Optimierung ist.

Im B2B-Kontext kommt eine zweite Eigenheit hinzu: Industrie-Websites haben oft große Bestände an Filter-, Sortier- und Parameter-URLs (Materialgruppen, Normen, Anwendungsbereiche), die technisch alle mit 200 OK antworten, aber inhaltlich identisch oder fast identisch zur Hauptkategorie sind. Wenn diese Varianten ohne Canonical-Tag oder ohne noindex indexiert werden dürfen, entsteht eine Indexierungs-Inflation, die Googlebot Crawl-Kapazität an irrelevanten URLs entzieht. Die Status-Antwort bleibt unauffällig (200), das eigentliche Problem zeigt sich erst im Indexierungsbericht.

HTTP 200 ist Crawl-Status, keine Indexierungs-Garantie

Ein häufiger Denkfehler im technischen Mittelstand: Wenn curl ein 200 OK zurückgibt, sei die Seite bei Google im Index. Das stimmt nicht.

HTTP 200 bestätigt ausschließlich, dass der Server die Anfrage erfolgreich beantwortet hat. Indexierung ist ein nachgelagerter Prozess in drei Stufen: Googlebot crawlt die URL (200-Bestätigung), rendert die Seite (JavaScript-Ausführung, falls relevant), bewertet sie über Qualitäts- und Duplicate-Filter und entscheidet erst dann, ob sie in den Index aufgenommen wird. Der reine Crawl-Statuscode ist also nur der Türöffner, nicht das Indexierungs-Urteil.

Die Trennung lässt sich in der Search Console konkret ablesen: „Einstellungen → Crawl-Statistiken“ zeigt die Status-Verteilung aller Googlebot-Requests, „Indexierung → Seiten“ zeigt, welche dieser gecrawlten URLs tatsächlich indexiert wurden. Bei B2B-Websites mit umfangreichen Filter- oder Parameter-URLs ist die Differenz zwischen beiden Werten oft groß. Genau dort entscheidet sich, ob Crawl-Budget produktiv eingesetzt wird oder ob Googlebot tagelang über Varianten von URLs läuft, die ohnehin nie in den Index aufgenommen werden.

HTTP-Statuscode in der Praxis: Diagnose und Steuerung

Wie prüft man den HTTP-Statuscode einer URL?

Der HTTP-Statuscode einer einzelnen URL lässt sich auf drei Wegen prüfen, je nach Tiefe und Anzahl der zu prüfenden URLs.

Browser-DevTools (Einzel-URL, schnell): Im Browser die URL aufrufen, DevTools öffnen (Rechtsklick → „Untersuchen“ oder F12), den Tab „Netzwerk“ wählen und die Seite neu laden. In der Spalte „Status“ steht der Code. Beim Klick auf einen Eintrag erscheinen alle Header inklusive Statuszeile und Location-Feld bei Weiterleitungen.

Kommandozeile mit curl (Einzel-URL, präzise):

# Header anzeigen, Body unterdrücken
curl -I https://beispiel.de/seite

# Weiterleitungen verfolgen und alle Header zeigen
curl -ILs https://beispiel.de/alte-url

Der Schalter -I fordert nur den Header an (HEAD-Request), -L folgt Weiterleitungen, -s unterdrückt Fortschritts-Ausgaben. Ergebnis ist die saubere Statuszeile (HTTP/2 200, HTTP/2 301, …) plus Header-Block. Für Audits größerer URL-Listen lässt sich curl mit einer URL-Datei und Shell-Schleifen automatisieren.

Google Search Console (Domain-weit, SEO-relevant): Für die SEO-Diagnose ist die Search Console das Werkzeug der Wahl, weil sie zeigt, wie Googlebot die Seiten sieht und nicht ein beliebiger Browser-Aufruf.

• „URL-Prüfung“ (Suchleiste oben): Einzel-URL-Status inklusive Crawl, Index und Rendering.
• „Einstellungen → Crawl-Statistiken“: Aggregierte Status-Verteilung aller Googlebot-Requests der letzten 90 Tage, gruppiert nach Statuscode-Klasse.
• „Indexierung → Seiten“: Indexierungs-Status (gecrawlt, indexiert, ausgeschlossen) mit Fehler-Kategorien wie „Soft 404“ oder „Weiterleitungsfehler“.

Status-Diagnose bei B2B-Migrationen

Im B2B-Relaunch entscheidet sich der Wert der Statuscode-Hygiene konkret. Ein Maschinenbau-Hersteller migriert 4.000 Produkt-Datenblätter von /produkte/ nach /produkt-katalog/. Ohne vollständiges Redirect-Mapping liefern die alten URLs danach 404 Not Found; die Search Console meldet das im Indexierungsbericht innerhalb von zwei bis vier Wochen. Wer auf den Wechsel mit pauschalen Weiterleitungen auf die Kategorie-Startseite reagiert, produziert Soft-404-Ergebnisse: Google interpretiert das als Fehler und entwertet die zugehörigen Backlinks. In der Audit-Praxis von RED RAM MEDIA ist das die häufigste Migrations-Panne im technischen Mittelstand, noch vor falschen Canonical-Tags oder fehlerhaften XML-Sitemaps.

Der Diagnose-Pfad in der Search Console ist immer derselbe: Crawl-Statistiken → Status-Verteilung → Vergleich vor/nach Migration. Steigt der 4xx- oder 5xx-Anteil über das normale Rauschen hinaus, wird die zugehörige URL-Liste exportiert und gegen das geplante Redirect-Mapping abgeglichen. Bei sauberer Migration sollten die 4xx-Spitzen innerhalb weniger Wochen wieder auf das Vor-Migrations-Niveau zurückgehen.

Auch jenseits von Migrationen lohnt sich der regelmäßige Blick auf die Status-Verteilung. Eine plötzliche Häufung von 5xx-Antworten an einem Wochentag deutet meist auf zyklische Lastspitzen oder geplante Wartungsfenster ohne Retry-After-Header hin. Wer konstante Anteile an 403-Antworten sieht, hat oft eine fehlerhafte ACL-Regel im CDN oder in der Server-Konfiguration. Diese Muster lassen sich nur mit der Search Console diagnostizieren, weil sie speziell die Googlebot-Sicht zeigt; ein externer Crawler-Test oder ein Browser-Aufruf liefert die Sicht eines anderen Clients.

Inoffizielle und proprietäre Codes

Neben den offiziellen IANA-Codes setzen einzelne Software-Anbieter eigene Statuscodes ein. Für B2B-Websites mit Cloudflare oder Microsoft IIS sind diese Codes in der Diagnose relevant.

Cloudflare-spezifische 5xx-Codes (520-526): Cloudflare nutzt diesen Bereich für Origin-Server-Fehler, also Probleme zwischen dem Cloudflare-Edge und dem dahinterliegenden Server. 521 Web Server Is Down signalisiert, dass der Origin-Server nicht erreichbar ist; 522 Connection Timed Out, dass die TCP-Verbindung zum Origin nicht zustande kommt; 525 SSL Handshake Failed, dass die TLS-Verhandlung mit dem Origin scheitert. In den Cloudflare-Logs und im Traffic-Bericht der Search Console tauchen diese Codes als 5xx auf, und Googlebot behandelt sie wie reguläre Server-Fehler.

Microsoft IIS Sub-Statuscodes: IIS erweitert offizielle Codes um Subkategorien wie 401.3 (Zugriff verweigert wegen ACL-Konfiguration) oder 404.4 (kein Handler für die Datei-Endung registriert). Diese Subcodes erscheinen nur in den IIS-eigenen Logs, nicht im offiziellen HTTP-Standard. Für die SEO-Diagnose reicht die Hauptklasse, aber bei der internen Server-Fehlersuche zeigen die Subcodes präziser, an welcher Stelle der Pipeline die Anfrage scheitert.

Der ebenfalls offizielle Code 451 Unavailable For Legal Reasons (RFC 7725, 2016) signalisiert eine rechtlich begründete Sperrung. Bei DSGVO-Geo-Blocking oder international tätigen B2B-Anbietern mit länderspezifischen Vertriebsbeschränkungen ist das ein relevanter Sonderfall: Wer eine Inhalts-Kategorie für bestimmte Länder sperren muss, sollte 451 statt 403 oder 404 zurückgeben, damit Suchmaschinen die juristische Ursache erkennen können.

Fazit & Takeaways

• Status-Hygiene zuerst, Content-Optimierung danach: Vor jeder Title- oder Meta-Optimierung in der Search Console unter „Einstellungen → Crawl-Statistiken“ die Status-Verteilung prüfen. Steigt der 4xx-Anteil über fünf bis zehn Prozent oder schwankt der 5xx-Anteil deutlich, hat das Statuscode-Problem Priorität.
• 200 OK ≠ indexiert: Die beiden Werte stehen in unterschiedlichen Berichten. Crawl-Status: Crawl-Statistiken. Index-Status: „Indexierung → Seiten“. Wer beide nicht parallel liest, übersieht systematische Lücken zwischen Crawling und Indexierung.
• Vor Migrationen Redirect-Mapping pflegen: Jede alte URL muss eine neue Ziel-URL haben, sonst entstehen 404 oder Soft-404. Bei Industrie-Sites mit großen Produktkatalogen ist die Mapping-Tabelle die Pflichtgrundlage; ohne sie wird die Status-Verteilung nach Go-Live unkontrollierbar.
• Mit curl -I einzelne URLs verifizieren: Vor dem Go-Live jede strategisch wichtige URL einzeln auf den erwarteten Code prüfen. Eine 301-Weiterleitung muss in einem Schritt zur finalen URL führen, ohne Chain, 302 oder Loop dazwischen.
• Bei geplanter Wartung 503 statt 500: Wartungsfenster mit 503 Service Unavailable und Retry-After-Header signalisieren. Googlebot pausiert dann das Crawling, statt die URLs als fehlerhaft zu werten.

Verwandte Begriffe

• 301-Weiterleitung: Dauerhafte Weiterleitung (Code 301) zur Konsolidierung von Ranking-Signalen bei URL-Änderungen.
• 302-Weiterleitung: Temporäre Weiterleitung (Code 302) für kurzfristige Umleitungen, ohne Signal-Konsolidierung.
• 404-Fehler: Standard-Statuscode für nicht gefundene Ressourcen (Code 404), führt nach wiederholtem Crawling zur Deindexierung.
• Crawler: Suchmaschinen-Bot, der HTTP-Anfragen stellt und auf Basis der Statuscodes entscheidet, wie eine URL im Index behandelt wird.
• Indexierung: Der nachgelagerte Prozess, bei dem Google eine erfolgreich gecrawlte Seite (HTTP 200) bewertet und in den Suchindex aufnimmt.
• Suchmaschinenoptimierung: Die übergeordnete Disziplin, in der HTTP-Statuscodes als technische Diagnose-Grundlage dienen.

Autor: Daniel Neubauer, Inhaber RED RAM MEDIA und seit über 16 Jahren auf technische SEO-Audits, Statuscode-Hygiene und verlustfreie Relaunches im B2B-Umfeld spezialisiert.

Häufige Fragen (FAQ)

Was ist ein HTTP-Statuscode?

Ein HTTP-Statuscode ist ein dreistelliger Antwortcode, den ein Webserver auf jede HTTP-Anfrage zurückliefert. Er ordnet die Antwort einer von fünf Klassen zu — 1xx (Informativ), 2xx (Erfolg), 3xx (Weiterleitung), 4xx (Client-Fehler) oder 5xx (Server-Fehler) — und steuert damit das Verhalten von Browsern, Crawlern und Caches. Die zentrale Spezifikation ist RFC 9110, das offizielle Register führt die IANA.

Was bedeutet HTTP Status?

HTTP Status ist die Kurzform für HTTP-Statuscode und bezeichnet die kategorische Antwort eines Webservers auf eine HTTP-Anfrage. Der Status erscheint in der ersten Zeile der Server-Antwort (Statuszeile) und besteht aus dreistelliger Code-Nummer plus Klartext-Beschreibung, etwa „200 OK“ oder „404 Not Found“. In der SEO-Diagnose ist der Status der erste Indikator, ob eine URL überhaupt crawlbar ist.

Welche HTTP-Statuscodes sind für SEO am wichtigsten?

Für SEO entscheidend sind sieben Codes: 200 (OK, Standard für indexierbare Seiten), 301 (dauerhafte Weiterleitung mit Konsolidierung von Ranking-Signalen), 302 (temporäre Weiterleitung ohne dauerhafte Konsolidierung), 404 (Not Found, führt nach wiederholtem Crawling zur Deindexierung), 410 (Gone, schnelleres Deindexierungs-Signal als 404), 500 (Internal Server Error) und 503 (Service Unavailable, mit Retry-After-Header für geplante Wartung).

Wie prüfe ich den HTTP-Statuscode einer URL?

Der HTTP-Statuscode einer URL lässt sich auf drei Wegen prüfen: in den Browser-DevTools (Tab „Netzwerk“, Spalte „Status“), per Kommandozeile mit curl -I https://beispiel.de/url (zeigt nur den Header) oder in der Google Search Console unter „URL-Prüfung“ für einzelne URLs sowie in „Einstellungen → Crawl-Statistiken“ für die aggregierte Verteilung aller Googlebot-Requests einer Domain.

Bedeutet HTTP 200, dass Google die Seite indexiert?

HTTP 200 bestätigt, dass der Server die Anfrage erfolgreich beantwortet hat. Indexierung ist ein separater Prozess: Googlebot crawlt die Seite (200-Bestätigung), bewertet sie inhaltlich (Qualitäts- und Duplicate-Filter, Rendering) und entscheidet erst dann, ob sie in den Index aufgenommen wird. Der reine Crawl-Statuscode reicht also nicht — den tatsächlichen Index-Status zeigt der Indexierungsbericht in der Search Console.