Was sind HTTP-Statuscodes?

Ein HTTP-Statuscode ist eine dreistellige Zahl, mit der ein Webserver jede einzelne Anfrage beantwortet. Sie steht in der ersten Zeile der Antwort, noch vor dem Inhalt, und sagt in einem Wort, was passiert ist: ausgeliefert, verschoben, nicht vorhanden, kaputt. Menschen sehen davon meist nur die Fehlerseite. Für Browser, Suchmaschinen und jede Schnittstelle ist die Zahl dagegen die eigentliche Antwort — und deshalb entscheidet sie darüber, ob eine Seite im Index landet, ob ein Umzug seine Sichtbarkeit behält und ob eine Störung zum Rankingverlust wird.

Diese Seite ist als Nachschlagewerk gebaut: erst die fünf Klassen, dann eine Tabelle mit allen Codes, die im Alltag einer Unternehmenswebsite vorkommen, und danach die Entscheidungen, an denen sich im Zweifel alles aufhängt — 301 oder 302, 404 oder 410, 429 oder 503.

Wie ein Statuscode entsteht

Jeder Aufruf einer Adresse ist eine Anfrage an einen Server: Bitte liefere dieses Dokument. Der Server antwortet mit einem Kopfteil und meist einem Inhalt. Die erste Zeile des Kopfteils nennt die Protokollversion, die Zahl und einen kurzen Text — zum Beispiel HTTP/1.1 404 Not Found. Der Text daneben ist nur eine Lesehilfe und darf von Server zu Server abweichen; ausgewertet wird ausschließlich die Zahl.

Die erste Ziffer bestimmt die Klasse, die beiden folgenden den Einzelfall. Daraus ergibt sich eine Eigenschaft, die den Umgang mit unbekannten Codes sehr einfach macht: Wer die Klasse kennt, kann auch mit einem Code umgehen, den er noch nie gesehen hat. Ein 418 ist dann erst einmal „irgendein Anfragefehler“, ein 507 „irgendein Serverfehler“ — und schon damit ist klar, wer dran ist.

Praktisch wichtig ist, dass die Zahl an drei verschiedenen Stellen entstehen kann: im Webserver, in einem vorgeschalteten Dienst wie CDN, Load Balancer oder Web Application Firewall, und in der Anwendung selbst. Antwortet eine der vorderen Stationen, kommt die Anfrage bei der Anwendung nie an — und die Logdatei der Anwendung bleibt leer, obwohl der Besucher einen Fehler gesehen hat. Bei der Fehlersuche lohnt es sich deshalb, von außen nach innen zu gehen, statt zuerst im Quelltext zu lesen.

Die zweite Trennung ist noch wichtiger: Statuscode und sichtbare Seite sind zwei unabhängige Dinge. Eine Seite kann „Diesen Inhalt gibt es nicht mehr“ anzeigen und trotzdem den Code 200 senden — für den Besucher plausibel, für Suchmaschinen eine Falschaussage. Umgekehrt darf eine liebevoll gestaltete Fehlerseite mit Suchfeld und Menü selbstverständlich den Code 404 liefern. Maßgeblich ist immer die Zahl, nie der Text auf dem Bildschirm. Wer einen Fehler meldet oder ausschließt, muss deshalb immer sagen, welchen Code der Server geschickt hat — nicht, was auf der Seite stand.

Die fünf Klassen und was sie bedeuten

Die folgende Tabelle beantwortet die beiden Fragen, die für Betreiber einer Website zählen: Was heißt das für den Betrieb, und was heißt das für die Sichtbarkeit in der Suche?

Als Merksatz: 2xx liefert, 3xx verweist, 4xx verweigert, 5xx versagt. Die Klasse sagt, wer handeln muss — 4xx ist Aufräumarbeit in Inhalten und Verlinkung, 5xx ist ein Fall für Technik und Betrieb.

Die wichtigsten Statuscodes in der Übersicht

Es gibt deutlich mehr Codes als diese Liste, aber im Alltag einer Unternehmenswebsite begegnen Ihnen fast ausschließlich die folgenden. Die letzte Spalte ist das, was auf dem Weg zur Lösung tatsächlich hilft.

Zwei Codes aus den Zwischenbereichen sorgen regelmäßig für Verwirrung, weil sie kein Standard sind: 499 schreibt der Webserver nginx ins Protokoll, wenn der Besucher die Verbindung abbricht, bevor eine Antwort fertig ist — ein Hinweis auf Geduld, nicht auf einen Defekt. Die Reihe 520 bis 527 stammt von Cloudflare und beschreibt Probleme zwischen Cloudflare und Ihrem Server. Beide gehören in die Diagnose, aber in keine Statuscode-Tabelle eines Standards.

1xx — Zwischenmeldungen

Die 1xx-Klasse ist die einzige, die Betreiber praktisch nie zu Gesicht bekommen: Sie enthält Zwischenmeldungen vor der eigentlichen Antwort. 100 Continue bestätigt, dass der Server einen größeren Datenstrom annimmt, bevor der Client ihn sendet. 101 Switching Protocols meldet den Wechsel auf ein anderes Protokoll, typischerweise beim Aufbau einer dauerhaften Verbindung für Chat- oder Live-Funktionen.

Interessant für die Ladezeit ist 103 Early Hints: Damit kann ein Server schon vor der fertigen Antwort mitteilen, welche Schriftarten, Stildateien oder Bilder der Browser gleich brauchen wird. Der Browser lädt diese Dateien parallel, statt auf den ersten Datenblock der Seite zu warten — ein Hebel für den Ladezeitwert, der zu den Core Web Vitals zählt. Voraussetzung ist ein Server oder CDN, der Early Hints unterstützt; eine Aufgabe für die Technik, keine Einstellung im Redaktionssystem.

Für die Suche hat die Klasse keine Bedeutung. Erscheint ein 1xx-Code in einem Prüfbericht als endgültige Antwort, deutet das auf einen fehlkonfigurierten Proxy hin: Eine Zwischenmeldung ist nie das Ende einer Antwort.

2xx — Erfolg

200 OK ist der Zustand, den jede Seite haben muss, die Besucher und Suchmaschinen erreichen soll. Alles andere in dieser Klasse gehört in die Technik: 201 Created quittiert einen neu angelegten Datensatz, etwa nach einem Formular; 204 No Content meldet Erfolg ohne Inhalt und ist für Hintergrundaufrufe gedacht; 206 Partial Content liefert einen Abschnitt einer großen Datei und ist bei Videos und Downloads der Normalfall.

Für Betreiber liegt die Gefahr dieser Klasse nicht im Code, sondern in seiner falschen Verwendung. Ein 200 ist eine Zusage: Hier steht etwas, das sich zu lesen lohnt. Gibt eine leere Suchergebnisseite, eine abgelaufene Veranstaltung, eine unbesetzte Kategorie oder ein zurückgezogener Artikel diese Zusage ab, sammeln Suchmaschinen beliebig viele Adressen ohne Substanz. Was dann passiert, steht weiter unten im Abschnitt zum Soft 404.

Umgekehrt gilt: Ein 204 oder 206 als Antwort auf einen normalen Seitenaufruf ist immer ein Fehler. Browser zeigen dann eine weiße Fläche, Suchmaschinen sehen eine Seite ohne Inhalt, und niemand bekommt eine Fehlermeldung, die auf die Ursache zeigt.

3xx — Weiterleitungen

Die wichtigste Klasse für alle, die eine Website umbauen, umziehen oder zusammenlegen — und die Klasse, in der am meisten Sichtbarkeit verschenkt wird. Sie teilt sich in drei Gruppen auf, die man nicht verwechseln darf.

Dauerhaft: 301 und 308. Beide sagen, dass die alte Adresse nicht mehr zurückkommt. Suchmaschinen übernehmen das Ziel in den Index und geben den Wert eingehender Verweise weitgehend weiter. Was eine 301-Weiterleitung technisch tut und wo sie eingerichtet wird, steht in der eigenen Erklärung dazu.

Vorübergehend: 302, 303 und 307. Hier bleibt die ursprüngliche Adresse die maßgebliche. 303 See Other hat dabei eine klar abgegrenzte Aufgabe: Nach einem abgeschickten Formular schickt es den Besucher per GET auf eine Bestätigungsseite, damit ein Neuladen die Bestellung nicht ein zweites Mal auslöst.

Kein Umzug: 304. 304 Not Modified ist die Antwort auf eine bedingte Anfrage — der Client fragt, ob sich seit seinem letzten Abruf etwas geändert hat, und bekommt ein „nein“ ohne Inhalt zurück. Er nimmt dann seine Kopie aus dem Cache. Das ist kein Fehler, sondern gesparte Übertragung, und zwar auch gegenüber Suchmaschinen.

Unabhängig vom Code entscheiden drei Eigenschaften darüber, ob eine Weiterleitung nützt oder schadet:

• Das Ziel muss passen. Weiterleitungen auf die inhaltlich nächste Seite behalten ihren Wert. Wird ein ganzer Bereich gesammelt auf die Startseite umgebogen, wertet Google das häufig als Soft 404 — und der Besucher muss von vorn anfangen.
• Ketten kosten. Leitet A nach B, B nach C und C erst dann auf das Ziel, zahlt jeder Aufruf diese Umwege mit Wartezeit. Googlebot bricht nach rund zehn Sprüngen ganz ab — und so lange wartet kein Besucher. Nach jedem Umbau gehören alte Regeln auf das jetzige Endziel umgeschrieben, nicht hintereinander gestapelt.
• Schleifen machen Seiten unerreichbar. Zeigen zwei Regeln wechselseitig aufeinander, entsteht ein Umleitungskreis. Browser brechen mit einer Fehlermeldung ab, Crawler ebenso — die Seite ist faktisch nicht vorhanden.

Wer nach 305 und 306 sucht: Beide existieren im Standard, werden aber von Browsern nicht mehr ausgewertet und spielen seit Langem keine Rolle.

301 oder 302 — was wann

Diese Entscheidung ist die teuerste in der ganzen Liste, weil ein falscher Code nicht auffällt: Die Weiterleitung funktioniert, der Besucher landet richtig, und nur die Suchmaschine zieht die falsche Schlussfolgerung. Die Regel selbst ist einfach — kommt die alte Adresse zurück oder nicht?

Was passiert, wenn man es falsch macht? Eine dauerhaft eingesetzte 302 hält die alte Adresse im Index: Rankings, Verweise und Snippets hängen weiter an einer Seite, die es inhaltlich nicht mehr gibt. Das fällt oft erst Monate später auf, wenn jemand fragt, warum die neuen Seiten nicht wachsen.

Zwei Punkte entlasten dabei die Entscheidung. Erstens kostet eine Weiterleitung heute keinen Verweiswert mehr: Google hat ausdrücklich bestätigt, dass bei 3xx-Antworten kein PageRank verfällt — die alte Sorge, jeder Sprung knabbere an der Linkkraft, ist erledigt. Zweitens gibt es eine Mindestdauer: Eine eingerichtete Weiterleitung soll nach Googles eigener Empfehlung wenigstens ein Jahr bestehen bleiben, besser unbefristet. Solange irgendwo ein Lesezeichen, ein fremder Verweis oder ein gedrucktes Dokument die alte Adresse nennt, hat die Regel ihren Zweck.

Der umgekehrte Fehler ist seltener, aber unangenehmer: Browser merken sich eine 301 sehr lange. Wer versehentlich eine falsche dauerhafte Weiterleitung ausliefert und sie später korrigiert, erreicht damit zwar Suchmaschinen und neue Besucher — Stammkunden mit der alten Regel im Browserspeicher landen trotzdem weiter am falschen Ziel. Dauerhaft heißt wirklich dauerhaft; im Zweifel beginnt man mit 302 und stellt um, sobald die Entscheidung steht.

Beim Umbau einer Website entscheidet die Weiterleitungstabelle über die gesamte vorhandene Sichtbarkeit: Adressen aus Sitemap, Crawl und Search Console zusammenziehen, jeder alten Adresse ein Ziel zuordnen, nach dem Livegang erneut erfassen und abgleichen. Genau dieser Teil ist der Kern eines Website-Relaunchs — die Gestaltung fällt auf, die Weiterleitungstabelle entscheidet über die Anfragen.

Nicht verwechseln: Ein Canonical-Tag ist keine Weiterleitung. Er ist ein Hinweis auf die bevorzugte Fassung, die Adresse bleibt abrufbar und antwortet weiter mit 200. Soll eine Adresse endgültig verschwinden, ist 301 das stärkere und eindeutigere Signal.

4xx — Fehler auf Anfrageseite

Der Name führt in die Irre: „Clientfehler“ heißt nicht, dass der Besucher etwas falsch gemacht hat. In der Praxis stammen die meisten 4xx-Antworten aus der eigenen Website — aus veralteten Verweisen, gelöschten Inhalten oder zu streng eingestellten Schutzmechanismen.

404 ist kein Alarm. Dass Adressen verschwinden, gehört zum Normalbetrieb des Webs, und Suchmaschinen gehen davon aus. Kritisch wird es durch Lage und Menge: Ein toter Verweis im Menü, im Angebotspfad oder in einer automatisch versendeten E-Mail kostet unmittelbar Anfragen, und eine gelöschte Adresse, auf die von außen verwiesen wird, verschenkt eine fremde Empfehlung. Wie man solche Verweise aufspürt und in welcher Reihenfolge man sie abarbeitet, steht ausführlich unter Broken Link.

403 und 429 sind die tückischsten Codes dieser Klasse, weil im Browser alles einwandfrei aussieht. Abgewiesen wird nur der automatische Abruf — und damit auch der von Suchmaschinen. Ursache ist fast immer ein Schutzmechanismus: eine Firewall-Regel, ein Bot-Schutz beim Hoster, eine Sperre nach Herkunftsland oder eine Begrenzung der Abrufe pro Minute. Solche Sperren zählen zu den häufigsten unsichtbaren Blockern der Indexierung, und sie treffen nicht nur Google: Wer die Abruf-Bots der KI-Dienste aussperrt, erscheint in deren Antworten nicht mehr — welcher KI-Crawler wofür zuständig ist, ist eine eigene Frage.

401 gehört auf Testumgebungen, nicht auf öffentliche Seiten. Taucht er in einem Crawl der Live-Website auf, ist meist ein Verzeichnisschutz von der Entwicklung in den Betrieb mitgewandert. 400 entsteht typischerweise durch falsch zusammengesetzte Adressen: ein doppeltes Fragezeichen in einem Kampagnenlink, ein nicht kodiertes Sonderzeichen, ein kopiertes Leerzeichen am Ende. 405 betrifft Formulare und Schnittstellen — die Adresse existiert, nimmt aber keine Absendung per POST an. 451 ist ein Spezialfall für rechtlich erzwungene Sperren und sollte nicht als dekorativer Ersatz für 403 verwendet werden.

404 vs. 410: wann eine Seite wirklich weg ist

Beide Codes sagen: Hier ist nichts. Der Unterschied liegt in der Gewissheit. 404 Not Found heißt „ich finde nichts“ — vielleicht ein Tippfehler, vielleicht kommt der Inhalt zurück. 410 Gone heißt „war hier, ist bewusst entfernt, kommt nicht zurück“. Die erste Antwort ist eine Beobachtung, die zweite eine Aussage.

Für Besucher macht das keinen Unterschied, denn beide landen auf derselben Fehlerseite. Für Suchmaschinen schon: Eine 410 ist eine Entscheidung des Betreibers, und darauf reagiert Google erfahrungsgemäß zügiger — die Adresse fällt früher aus dem Index, während bei einem 404 noch eine Zeit lang nachgefragt wird, ob doch wieder etwas da ist. Falsch ist aber keiner der beiden Codes; ein 404 für eine gelöschte Seite führt zum gleichen Ziel, nur langsamer.

Zwei Dinge gehören nicht in diese Tabelle, weil sie regelmäßig falsch gemacht werden. Erstens: eine Fehlerseite, die den Code 200 sendet. Das ist der Soft 404 — eine Unwahrheit gegenüber jedem automatischen Abruf. Zweitens: alle gelöschten Adressen gesammelt auf die Startseite umbiegen. Beides sieht nach Aufräumen aus und erzeugt stattdessen Adressen, die im Index stehen, ohne eine Frage zu beantworten.

Eine gute Fehlerseite senkt den Schaden erheblich: Sie sagt in einem Satz, was passiert ist, bietet Suchfeld und Hauptmenü und verweist auf die wichtigsten Bereiche. Ein noindex braucht sie nicht — ein 404 oder 410 schließt die Indexierung bereits aus. Wichtig ist nur, dass jede dieser Seiten denselben Fehlercode ausliefert, auch wenn das Redaktionssystem sie als normale Seite verwaltet.

Und ein kaufmännischer Hinweis: Bevor Sie eine Adresse auf 410 setzen, prüfen Sie, ob von außen auf sie verwiesen wird. Fremde Verweise sind bereits bezahlte Empfehlungen. Gibt es eine inhaltlich nahe Seite, holt eine 301 sie zurück; gibt es keine, ist 410 die ehrliche Antwort.

5xx — Fehler auf Serverseite

Bei 5xx ist nicht die Anfrage das Problem, sondern die Antwort. Die Unterscheidung zwischen den vier häufigen Codes ist deshalb kein Detail, sondern die halbe Diagnose: Sie sagt, an welcher Stelle der Kette Sie suchen müssen.

• 500 — in der Anwendung. Der Code selbst ist inhaltsleer; er bedeutet nur, dass etwas abgebrochen ist. Die eigentliche Information steht im Fehlerprotokoll der Anwendung, mit Zeitstempel und Ablaufverfolgung.
• 502 — zwischen den Diensten. Der Webserver hat eine Antwort erhalten, kann sie aber nicht verwenden, oder der Anwendungsprozess läuft nicht mehr. Nach einem Deployment ist 502 der klassische Hinweis darauf, dass der neue Prozess noch nicht hochgefahren ist.
• 503 — bewusst oder überlastet. Entweder ist ein Dienst gestoppt, oder er weist Anfragen ab, weil er am Limit ist. Als gesetzte Antwort bei Wartungsarbeiten ist 503 richtig, als Dauerzustand ein Kapazitätsproblem.
• 504 — zu langsam. Eine nachgelagerte Stelle hat die Zeitgrenze überschritten: eine schwere Datenbankabfrage, eine fremde Schnittstelle, ein Import im Hintergrund. 504 tritt gehäuft genau dann auf, wenn viele Besucher gleichzeitig kommen.

Für die Sichtbarkeit zählt bei 5xx vor allem die Dauer. Eine Störung von Minuten bleibt ohne Folgen — Suchmaschinen versuchen es später erneut. Ziehen sich Serverfehler über Tage, stuft Google die betroffenen Adressen zurück und senkt die Abrufrate für die ganze Website; die Erholung dauert dann erkennbar länger als der Ausfall selbst. Das ist der Grund, warum durchgehende Erreichbarkeit kein Komfortthema ist: Wer Fehlerquoten und Antwortzeiten nicht im Blick hat, erfährt vom Problem durch einen Rankingverlust statt durch eine Warnmeldung.

Ein Serverfehler an einer einzigen Stelle wiegt dabei schwerer als an allen anderen: Liefert die robots.txt selbst eine 5xx-Antwort, kann es passieren, dass Crawler die komplette Website vorübergehend als gesperrt einstufen — nicht nur die eine Adresse. Dieselbe Datei muss übrigens, wenn sie gar nicht vorhanden ist, einen klaren 404 liefern und nicht eine gestaltete Fehlerseite mit Code 200.

Praktisch gehören deshalb drei Dinge zusammen: eine Überwachung, die bei steigender Fehlerquote meldet und nicht erst bei völligem Ausfall; Fehlerprotokolle, die lange genug aufbewahrt werden, um ein Muster zu erkennen; und eine Stelle, die reagiert. Antwortzeiten und Fehlerquoten laufend im Blick zu behalten ist deshalb Teil von Betrieb und Wartung und keine Sonderaufgabe nach dem ersten Vorfall.

429 und 503 — wenn der Server bremst

Diese beiden Codes gehören zusammen, weil sie dasselbe sagen: „nicht jetzt, versuch es später“. Richtig eingesetzt sind sie die freundlichsten Antworten, die ein Server geben kann — falsch eingesetzt kosten sie mehr Sichtbarkeit als ein echter Ausfall.

429 Too Many Requests ist eine Begrenzung: Ein Besucher, ein Skript oder ein Bot hat in kurzer Zeit zu viele Anfragen gestellt. Die Regel dafür steht selten in der Anwendung, sondern meist in einem Schutzmechanismus davor. Das macht den Code gefährlich, denn er trifft automatische Abrufe zuerst — Suchmaschinen-Bots, Prüfwerkzeuge und die Abruf-Bots der KI-Dienste. Einzelne Crawler holen sehr viele Seiten in kurzer Folge; eine Begrenzung, die auf menschliches Tempo eingestellt ist, sperrt sie zuverlässig aus.

503 Service Unavailable ist eine Ansage: Der Dienst antwortet gerade nicht, soll aber wiederkommen. Für geplante Arbeiten ist das der korrekte Code. Eine Wartungsseite mit Code 200 richtet dagegen echten Schaden an, weil der Hinweistext als Seiteninhalt in den Index gerät — und zwar für jede Adresse, die während der Arbeiten abgerufen wird.

Bei beiden Codes gehört der Kopfzeileneintrag Retry-After dazu. Er nennt die Wartezeit in Sekunden oder als Zeitpunkt und ist die einzige Möglichkeit, einem automatischen Abruf eine sinnvolle Rückkehr vorzuschlagen. Ohne diese Angabe entscheidet der Crawler selbst, wann er es erneut versucht.

Vier Punkte aus der Praxis:

• Nicht pauschal nach Tempo sperren. Wer Abrufe pro Minute begrenzt, sollte bekannte Suchmaschinen-Bots ausnehmen oder ihnen ein eigenes, höheres Limit geben.
• Die Quelle prüfen, nicht die Bezeichnung. Eine Kennung im Anfragekopf ist beliebig fälschbar. Wer echte Bots von Nachahmern trennen will, prüft die Herkunftsadresse statt die Selbstauskunft.
• Zwischenspeichern statt abweisen. Erzeugt eine Übersichtsseite bei jedem Abruf Last, ist die Lösung ein Zwischenspeicher — nicht eine Sperre für die, die sie abrufen.
• 503 hat ein Ablaufdatum. Nach wenigen Tagen behandelt Google eine dauerhafte 503 nicht mehr als Pause. Dauert ein Umbau länger, braucht die Adresse eine echte Entscheidung: 301, 410 oder eine Seite mit Inhalt.

In Server- und Firewall-Protokollen lässt sich beides nachsehen: Welcher Bot bekommt wie oft eine 429, und von welcher Station kommt die Antwort? Oft genügt es, ein einzelnes Limit anzuheben, um die Erfassung der Website wieder in Gang zu bringen. Dass Sperren dieser Art überhaupt entstehen, liegt selten an einer Entscheidung — meist sind sie in einem Hosting- oder CDN-Paket voreingestellt und stehen in keiner robots.txt.

Der Sonderfall Soft 404

Ein Soft 404 ist kein Statuscode, sondern eine Einschätzung von Google: Die Adresse antwortet mit 200, hinter der Antwort steht aber kein brauchbarer Inhalt. Typische Auslöser sind ausgelaufene Angebote mit Platzhaltertext, leere Suchergebnisse, vergangene Termine, unbesetzte Kategorien und Sammelweiterleitungen, die auf der Startseite enden.

Der Schaden ist doppelt. Nach außen entstehen Adressen im Index, die niemandem weiterhelfen und das Bild der Website in den Suchergebnissen verwässern. Nach innen gehen Abrufe für Seiten verloren, hinter denen nichts Neues steht. Beides wächst mit der Größe der Website: Bei zwanzig Seiten fällt es nicht auf, bei einem Katalog mit tausenden Adressen bestimmt es, was überhaupt noch erfasst wird.

An der Statuszeile ist ein Soft 404 nicht zu erkennen — ein Prüfwerkzeug sieht 200 und ist zufrieden. Sichtbar wird er im Bericht zur Seitenindexierung der Search Console, wo Google ihn als eigene Kategorie führt. Die Behebung richtet sich nach dem Einzelfall: Inhalt ergänzen, wenn die Seite gebraucht wird; per 301 auf die passende Nachfolgeseite leiten, wenn es eine gibt; den ehrlichen Code 404 oder 410 senden, wenn nichts mehr kommt. Was keine Lösung ist: die Seite auf noindex setzen und den 200er stehen lassen — die Adresse verschwindet aus der Suche, der Abruf bleibt.

Welche Codes Google wie behandelt

Suchmaschinen lesen Statuscodes anders als Browser: Ein Browser braucht nur zu wissen, was er anzeigen soll, eine Suchmaschine zieht aus derselben Zahl eine Entscheidung über den Index. Die folgende Übersicht fasst zusammen, was aus einem Code für die Suche folgt.

Drei Abgrenzungen sorgen dabei besonders oft für Missverständnisse. Erstens: Eine per robots.txt gesperrte Adresse liefert gar keinen Statuscode, weil sie nie abgerufen wird. Das ist ein völlig anderer Zustand als 404 — Google kennt die Adresse unter Umständen trotzdem und kann sie ohne Inhalt listen. Zweitens: noindex setzt eine 200er-Antwort voraus; auf einer Fehlerseite ist die Angabe wirkungslos, weil der Code die Seite schon ausschließt. Drittens: Statuscodes sind Signale über eine Adresse, keine Bewertung der Qualität. Eine saubere Weiterleitungstabelle verbessert kein schwaches Angebot — sie verhindert nur, dass ein starkes seine Position verliert. Wie Indexierung insgesamt abläuft, erklärt die eigene Übersicht dazu.

In der Google Search Console finden Sie die Codes nicht als Zahlen, sondern als Kategorien im Bericht zur Seitenindexierung: „Nicht gefunden (404)“, „Soft 404“, „Serverfehler (5xx)“, „Weiterleitungsfehler“, „Seite mit Weiterleitung“ und „Durch robots.txt blockiert“. Jede dieser Zeilen lässt sich öffnen und listet die betroffenen Adressen. Das ist die Sicht von Google auf Ihre Website — und sie weicht regelmäßig von dem ab, was ein eigener Crawl ergibt.

Statuscodes, Crawling und Indexierung

Statuscodes sind das Steuerungsmittel für den Abruf einer Website. Jeder Abruf kostet den Server Rechenzeit und die Suchmaschine Geduld, und beides ist begrenzt. Wie viel davon tatsächlich eine Rolle spielt, hängt an der Größe: Bei einer Unternehmenswebsite mit wenigen hundert Adressen ist das Crawl-Budget kein Thema, bei Katalogen, Shops und Portalen mit vielen tausend Adressen bestimmt es, wie schnell Änderungen überhaupt ankommen.

Google nennt als Größenordnung, ab der sich die Frage überhaupt lohnt, zwei Fälle: über eine Million Seiten bei wöchentlicher Änderung, oder über zehntausend Seiten, die sich täglich ändern. Darunter gilt: Antwortet der Server zügig und ohne Fehler, hebt Google die Abrufrate von selbst an — Statuscodes und Antwortzeiten sind damit die beiden Hebel, die Sie direkt in der Hand haben.

Vier Zusammenhänge sind dabei praktisch relevant:

• Weiterleitungsketten verbrauchen Abrufe doppelt. Jeder Schritt ist eine eigene Anfrage. Eine Kette aus drei Sprüngen kostet drei Abrufe, um eine Seite zu lesen, die auch in einem erreichbar wäre.
• Fehlerseiten in Masse verschieben die Reihenfolge. Je mehr Adressen mit 404 antworten, desto mehr Abrufe laufen auf Inhalte, die es nicht gibt — während neue Seiten warten. Welche technischen Hürden den Abruf sonst bremsen, behandelt Crawlability.
• 304 und saubere Zwischenspeicher senken die Last. Wer bedingte Anfragen korrekt beantwortet, lässt unveränderte Seiten billig abhaken. Das schafft Luft für die Adressen, die sich wirklich geändert haben.
• Die Sitemap gehört auf 200er beschränkt. In eine Sitemap gehören nur Adressen, die mit 200 antworten und indexiert werden sollen. Weitergeleitete, gesperrte und gelöschte Adressen darin sind ein widersprüchliches Signal: Sie werden gemeldet und dann abgewiesen.

Dazu ein Punkt, der in der Messung häufig untergeht: Aufrufe von Fehlerseiten erscheinen in der Webanalyse als gewöhnliche Seitenaufrufe. Ohne eine eigene Markierung der Fehlerseite sieht niemand, dass ein Teil des Verkehrs auf einer Sackgasse gelandet ist — die Zahlen sehen normal aus, nur die Anfragen fehlen. Lohnend ist deshalb ein regelmäßiger Blick auf die tatsächlich ausgelieferten Codes; in der laufenden SEO-Betreuung gehört diese Prüfung fest zum Monatsrhythmus und nicht in die Kategorie „fällt auf, wenn es weh tut“.

Statuscodes prüfen

Sechs Wege, jeder mit einem anderen Blickwinkel. Wer einen Fehler sucht, braucht meist zwei davon: einen für den Einzelfall und einen für das Gesamtbild.

1. Entwicklerwerkzeuge im Browser. Im Netzwerkbereich steht zu jeder Anfrage der Code, inklusive aller Weiterleitungsschritte und aller nachgeladenen Dateien. Der schnellste Weg für eine einzelne Adresse. Wichtig: Vor der Prüfung den Zwischenspeicher abschalten, sonst sehen Sie den Stand von gestern.

2. Kommandozeile. curl -I https://ihre-domain.de/seite fordert nur den Kopfteil an und zeigt Code und Kopfzeilen ohne Seiteninhalt. Mit curl -IL läuft der Aufruf jeden Schritt einer Weiterleitungskette ab und zeigt sie einzeln — so finden Sie Ketten und Schleifen in Sekunden. Mit -A lässt sich eine andere Kennung mitschicken; genau damit sehen Sie, ob Ihr Server automatischen Abrufen anders antwortet als einem Browser.

3. Ein Crawler für die eigene Website. Programme wie Screaming Frog oder Sitebulb gehen die Website Adresse für Adresse durch und liefern eine vollständige Liste mit Codes, Zielen und Kettenlängen. Entscheidend für die Reparatur ist nicht die Liste der Fehler, sondern die Angabe, von welcher Seite aus der fehlerhafte Verweis gesetzt ist — ohne sie kennen Sie das Symptom und nicht die Stelle.

4. Google Search Console. Zwei Werkzeuge, zwei Zwecke: Der Bericht zur Seitenindexierung zeigt das Gesamtbild aus Sicht von Google, die URL-Prüfung sagt für eine einzelne Adresse, welchen Code Google beim letzten Abruf bekommen hat. Das ist die einzige Quelle, die Ihnen die Sicht der Suchmaschine zeigt — und bei 403- oder 429-Problemen oft die einzige, die den Fehler überhaupt sieht.

5. Crawling-Statistiken der Search Console. In den Einstellungen liegt eine Auswertung, die im Alltag oft übersehen wird: Sie bricht die Abrufe der letzten Monate nach Antwortcode auf. Steigt dort der Anteil der 5xx- oder 404-Antworten, sehen Sie es dort früher als in den Rankings — und Sie sehen, ob Google überhaupt noch im gewohnten Umfang abruft.

6. Serverprotokolle. Die ehrlichste Quelle. Dort steht, welche Adressen wirklich abgerufen wurden, von wem, wie oft und mit welcher Antwort. Daraus ergibt sich die Reihenfolge der Arbeit von selbst: Eine Fehleradresse mit hunderten Abrufen pro Woche ist wichtiger als zwanzig, die niemand anfragt. Dieselben Protokolle zeigen auch, ob ein Code aus der Anwendung oder aus einem vorgeschalteten Dienst stammt.

Ein Hinweis zur Methode: Prüfen Sie Verdachtsfälle immer zweimal — einmal als Browser, einmal mit einer Bot-Kennung. Weicht das Ergebnis ab, liegt der Fehler nicht in der Seite, sondern in einer Regel davor. Und prüfen Sie nach jedem Umbau erneut; Weiterleitungsregeln überleben Umbauten, der Inhalt dahinter nicht immer. Eine vollständige Aufnahme aller ausgelieferten Codes samt Fundstelle und Reihenfolge der Reparatur ist Teil unseres technischen SEO-Audits.

Häufige Fragen zu HTTP-Statuscodes

Was bedeutet 3xx?

Die Klasse der Weiterleitungen: Der gewünschte Inhalt liegt unter einer anderen Adresse. 301 und 308 sind dauerhaft, 302, 303 und 307 vorübergehend, 304 meldet einen unveränderten Stand für den Zwischenspeicher.

Was ist der Unterschied zwischen 301 und 302?

301 sagt „dauerhaft“, 302 sagt „vorübergehend“. Bei 301 tritt im Index die neue Adresse an die Stelle der alten, und der Wert eingehender Verweise geht auf sie über. Bei 302 bleibt die alte Adresse die maßgebliche. Für einen echten Umzug eingesetzt, kann 302 die Sichtbarkeit monatelang an der falschen Adresse halten.

Wann nehme ich 410 statt 404?

Wenn Sie den Inhalt selbst entfernt haben und sicher sind, dass er nicht zurückkommt. 410 ist eine Aussage, 404 nur eine Beobachtung — deshalb reagiert Google auf 410 in der Regel schneller. Gibt es einen inhaltlich passenden Nachfolger, ist weder 404 noch 410 richtig, sondern 301.

Was ist der Unterschied zwischen 403 und 404?

404 heißt „diese Adresse kenne ich nicht“, 403 heißt „ich kenne sie, lasse Sie aber nicht hinein“. Ein 403 auf einer öffentlichen Seite ist deshalb fast immer ein Konfigurationsfehler: Der Inhalt ist da, eine Regel davor weist den Abruf ab.

Welchen Code sende ich bei Wartungsarbeiten?

503 mit der Angabe Retry-After. Damit weiß ein Crawler, dass er später wiederkommen soll. Eine Wartungsseite mit Code 200 sorgt dagegen dafür, dass der Hinweistext als Seiteninhalt in den Index gerät. Dauert der Umbau länger als ein paar Tage, braucht die Adresse eine echte Entscheidung.

Wie viele Weiterleitungen darf eine Kette haben?

Am besten keine: Jede Regel sollte direkt auf das Endziel zeigen. Zwei Schritte sind in der Praxis unkritisch, ab drei steigen Ladezeit und Risiko, dass ein Crawler abbricht. Nach jedem Umbau lohnt es sich, bestehende Regeln gegen das aktuelle Ziel zu prüfen, statt neue davorzusetzen.

Schadet ein 404-Fehler dem Ranking?

Einzeln nicht. Schaden entsteht durch Lage und Menge: tote Verweise an wichtigen Stellen, Adressen mit fremden Verweisen, die ins Nichts laufen, oder ein erheblicher Teil der Abrufe, der auf Fehlerseiten endet.

Muss ich meine 404-Seite auf noindex setzen?

Nein. Der Code 404 schließt die Indexierung bereits aus, die Angabe ist wirkungslos. Wichtig ist das Umgekehrte: dass Ihre Fehlerseite wirklich 404 und nicht 200 sendet.

Was bedeutet 304 in einem Crawl-Bericht?

Dass der Abruf bedingt gestellt und mit „unverändert“ beantwortet wurde. Das ist kein Fehler, sondern gesparte Übertragung. Nur wenn Seiten trotz Änderungen 304 melden, stimmt etwas mit den Zwischenspeicher-Kopfzeilen nicht.

Was ist 429 und warum trifft es nur Bots?

429 ist eine Begrenzung der Abrufe pro Zeiteinheit. Menschen erreichen solche Grenzwerte selten, automatische Abrufe dauernd — deshalb sehen Besucher eine einwandfreie Website, während Suchmaschinen und KI-Dienste abgewiesen werden. Die Regel steht meist in einem Bot-Schutz oder CDN, nicht in der Anwendung.

Ist 443 ein Statuscode?

Nein. 443 ist der Netzwerkport, über den HTTPS läuft — wie 80 für unverschlüsseltes HTTP. Statuscodes sind immer dreistellig und stehen in der Antwort des Servers, nicht in der Adresse.

Was ist 418 oder 420?

Scherz- und Sonderfälle. 418 („I’m a teapot“) stammt aus einem Aprilscherz-Standard, 420 ist kein offizieller Code, sondern eine Eigenentwicklung einzelner Anbieter für Überlastung. Im produktiven Einsatz hat beides nichts verloren.

Was bedeuten 499 und 520?

Beide sind keine Standardcodes. 499 schreibt nginx ins Protokoll, wenn der Besucher die Verbindung vor der Antwort abbricht. Die Reihe 520–527 kommt von Cloudflare und beschreibt Probleme zwischen Cloudflare und dem Server dahinter — die Ursache liegt dann fast immer beim eigenen Server, nicht beim Dienst davor.

Wie erkenne ich einen Soft 404?

Nicht am Code, sondern am Inhalt: Die Adresse meldet 200 und zeigt nichts Nutzbares. Google führt solche Fälle im Bericht zur Seitenindexierung als eigene Kategorie auf; ein Prüfwerkzeug übersieht sie, weil die Statuszeile in Ordnung ist.

Welcher Code ist bei einem Relaunch richtig?

301 für jede alte Adresse mit einem eindeutigen Nachfolger, 410 für ersatzlos entfernte Inhalte, 404 für Adressen, die nie existiert haben. Sammelweiterleitungen auf die Startseite sind keine Lösung — sie verlieren sowohl den Besucher als auch das Signal.

Zusammenfassung

HTTP-Statuscodes sind die kürzeste Form der Wahrheit über eine Website: 2xx ausgeliefert, 3xx verschoben, 4xx nicht vorhanden oder nicht erlaubt, 5xx kaputt. Vier Entscheidungen entscheiden über die Sichtbarkeit — bei Umzügen konsequent 301 statt 302, bei ersatzlos entfernten Inhalten 410 statt Dauerprovisorium, bei Wartung 503 mit Retry-After statt 200, und bei Schutzmechanismen ein Limit, das automatische Abrufe nicht aussperrt.

Alles Übrige ist Kontrolle. Ein eigener Crawl, der Bericht zur Seitenindexierung und die Serverprotokolle zeigen gemeinsam, welche Codes Ihre Adressen tatsächlich senden — und das ist regelmäßig etwas anderes als das, was auf dem Bildschirm steht.