HTTP-Statuscodes für SEO

Kurzdefinition

Ein HTTP-Statuscode ist eine dreistellige Antwort des Servers auf die Anfrage eines Clients. Browser, Crawler, Monitoring-Dienst oder API sehen diese Antwort, bevor sie etwas mit dem eigentlichen Inhalt anfangen können.

Für SEO beantwortet der Code zunächst eine einfache Frage: Hat der Crawler Inhalt erhalten, wurde er an eine andere Adresse geschickt, ist die Ressource nicht verfügbar oder liegt ein Serverproblem vor? Über die Indexierung entscheidet der Code allein nicht. Eine Seite kann 200 OK liefern und trotzdem nicht indexierbar, dupliziert, leer oder für ein Suchergebnis ungeeignet sein.

Die fünf Antwortklassen

HTTP teilt Statuscodes in fünf Klassen ein:

Die Klasse ist nur der Anfang. 404 und 429 beginnen beide mit einer 4, werden von Google aber grundverschieden behandelt. Entscheidend sind der genaue Code und seine Ursache.

2xx: Eine erfolgreiche Anfrage ist kein Indexierungsversprechen

200 OK ist die normale Antwort einer funktionierenden HTML-Seite. Google kann den empfangenen Inhalt damit an seine Indexierungssysteme weiterreichen. Google weist ausdrücklich darauf hin, dass eine 2xx-Antwort keine Indexierung garantiert.

Auch eine technisch erfolgreiche Seite kann fehlerhaft sein:

• Sie enthält eine Fehlermeldung oder fast keinen Hauptinhalt.
• Eine `noindex`-Anweisung schließt sie von der Indexierung aus.
• Ihr Canonical verweist auf eine andere URL.
• Wesentliche Inhalte wurden nicht gerendert.
• Sie liefert die falsche Sprache, den falschen Markt oder einen falschen Nutzerzustand aus.
• Sie ist ein Duplikat und Google wählt eine andere kanonische Version.

204 No Content gilt auf Protokollebene ebenfalls als erfolgreich, liefert aber keinen Inhalt zur Verarbeitung. Für manche APIs und Aktionen ist das sinnvoll, nicht für eine normale Landingpage, die in der Suche erscheinen soll.

304 Not Modified gehört formal zur 3xx-Klasse, ist jedoch keine Weiterleitung. Die Antwort teilt einem Client mit bedingter Anfrage mit, dass seine gespeicherte Version noch aktuell ist. Googles Indexierung behält dann die vorhandene Fassung und berechnet höchstens Signale für die URL neu; ansonsten hat der Code keine Wirkung auf die Indexierung. Nebenbei spart er Übertragung und Serverarbeit.

3xx: Dauerhafte und vorübergehende Umzüge unterscheiden

Weiterleitungen sind sinnvoll, wenn eine Ressource umgezogen ist, mehrere URL-Varianten auf eine Adresse zusammengeführt werden oder ein Inhalt in einem echten Nachfolger aufgegangen ist.

Die wichtigsten serverseitigen Redirects sind:

• 301 Moved Permanently und 308 Permanent Redirect für einen dauerhaften Umzug;
• 302 Found und 307 Temporary Redirect für eine vorübergehende Änderung;
• 303 See Other für besondere Abläufe, bei denen der Client eine andere Ressource abrufen soll.

Google folgt den gängigen Redirects. 301 und 308 wertet Google als starkes Signal dafür, dass das Ziel kanonisch werden soll, 302 und 307 nur als schwaches. Bei einer temporären Weiterleitung kann deshalb die Quell-URL weiterhin in den Suchergebnissen erscheinen.

Bei normalen GET-Anfragen sehen 301 und 308 für Nutzer meist gleich aus. Auf Protokollebene bewahren 307 und 308 jedoch Anfragemethode und Body. Ältere Clients können die Methode nach 301 oder 302 ändern. Das ist bei Formularen und APIs wichtiger als bei einer üblichen Seitenmigration.

Ein Redirect wird zum SEO-Problem, wenn er:

• auf ein sachlich unpassendes Ziel führt;
• in einem weiteren Redirect, einem Fehler oder einer blockierten Seite endet;
• eine Schleife erzeugt;
• interne Links und Sitemaps auf der alten URL zurücklässt;
• als temporär markiert ist, obwohl der Umzug dauerhaft bleibt;
• viele gelöschte Seiten auf eine allgemeine Startseite schickt, die ihre Absicht nicht erfüllt.

Googles Crawler folgen standardmäßig bis zu 10 Weiterleitungsschritten. Das ist eine Obergrenze, kein Ziel für die Architektur. Eine direkte Weiterleitung ist für Nutzer, Crawler, Analytics und spätere Wartung leichter verständlich. Wie du bei Protokoll- und Host-Wechseln alle Varianten auf eine sichere Adresse bündelst, zeigen die HTTP- und HTTPS-Grundlagen für SEO.

4xx: Nicht gefunden, nicht autorisiert oder verboten

Eine gewöhnliche 4xx-Antwort sagt Google, dass der Response-Body nicht als Seiteninhalt verwendet werden soll. Bereits indexierte URLs, die weiter 4xx liefern, verschwinden mit der Zeit aus dem Index. Für diesen Zweck behandelt Google die gängigen 4xx-Codes gleich. Die wichtige Ausnahme ist 429 Too Many Requests, denn diesen Code wertet Google als Zeichen einer Serverüberlastung.

Häufige Fälle sind:

• 400 Bad Request: Der Server hält die Anfrage für fehlerhaft.
• 401 Unauthorized: Eine gültige Authentifizierung fehlt.
• 403 Forbidden: Der Server versteht die Anfrage, verweigert aber den Zugriff.
• 404 Not Found: Unter dieser URL wurde aktuell keine Ressource gefunden.
• 410 Gone: Die Ressource wurde wissentlich dauerhaft entfernt.

Liefert eine öffentliche Seite 401 oder 403, lohnt sich eine Untersuchung. Authentifizierung, Firewall, Bot-Schutz, CDN-Regel, regionale Sperre oder Origin-Konfiguration können Crawler unbeabsichtigt aussperren. Diese Codes eignen sich nicht dazu, Googles Crawl-Rate zu steuern.

404 und 410 sind nicht automatisch Fehler

Ist ein Inhalt verschwunden und gibt es keinen nahen Ersatz, ist 404 oder 410 eine ehrliche Antwort. Eine Website wird nicht besser, wenn jede alte Adresse pauschal auf die Startseite umgeleitet wird.

Handlungsbedarf entsteht vor allem dann, wenn das übrige System die fehlende URL weiterhin wie eine aktive Seite behandelt. Prüfe:

• interne Links zur fehlenden URL;
• Einträge in einer XML-Sitemap;
• wertvolle externe Links oder weiterhin vorhandene Besuche;
• ein Produkt, einen Artikel oder eine Kategorie, die noch existieren sollte;
• einen relevanten Nachfolger mit praktisch demselben Zweck.

Je nach Fall wird die Seite wiederhergestellt, der Link korrigiert, der Sitemap-Eintrag entfernt oder ein Redirect auf einen nahen Nachfolger gesetzt. Der Statuscode allein kann diese Entscheidung nicht treffen.

Googles Dokumentation verspricht keinen Rankingvorteil für 410 gegenüber 404. Beide teilen mit, dass Inhalt nicht verfügbar ist. Nutze 410, wenn die dauerhafte Entfernung bekannt und beabsichtigt ist, nicht als Trick für ein vermeintlich schnelleres Ergebnis.

Soft 404: Wenn Code und Seite einander widersprechen

Ein Soft 404 ist kein HTTP-Statuscode. Es ist Googles Diagnose für eine URL, die erfolgreich antwortet, aber wie eine Fehlerseite, eine leere Seite oder eine Seite ohne sinnvollen Hauptinhalt wirkt.

Typische Beispiele:

• Ein gelöschtes Produkt zeigt "Produkt nicht gefunden" mit 200 OK.
• Eine interne Suche ohne Treffer wirkt wie eine fehlende Seite.
• Ein clientseitiger Router zeigt eine 404-Ansicht, während der Server weiterhin 200 liefert.
• Ein Rendering-Fehler lässt nur Navigation und Fehlermeldung übrig.

Ist die Ressource wirklich entfernt, sollte der Server 404 oder 410 liefern. Ist sie umgezogen, braucht sie einen dauerhaften Redirect auf einen passenden Ersatz. Existiert der Inhalt noch, musst du prüfen, was Googlebot tatsächlich empfangen und gerendert hat. Dabei helfen die URL-Prüfung und der Bericht zur Seitenindexierung in Search Console.

429 und 5xx: Überlastung und Serverfehler

429 Too Many Requests teilt mit, dass ein Client ein Anfragelimit überschritten hat. Google behandelt 429 wie einen Serverfehler und nicht wie eine gewöhnliche fehlende Seite.

Die wichtigsten 5xx-Antworten sind:

• 500 Internal Server Error: unspezifischer Fehler in Anwendung oder Server;
• 502 Bad Gateway: Gateway oder Proxy erhält eine ungültige Antwort vom vorgelagerten Dienst;
• 503 Service Unavailable: Dienst ist vorübergehend nicht erreichbar oder überlastet;
• 504 Gateway Timeout: Gateway wartet vergeblich auf die Antwort eines vorgelagerten Dienstes.

Wiederholte 5xx- und 429-Antworten veranlassen Googles Crawler, langsamer zu crawlen. Indexierte URLs können zunächst im Index bleiben, bei anhaltenden Fehlern aber später herausfallen. Sobald wieder stabile erfolgreiche Antworten kommen, steigt die Crawl-Aktivität schrittweise und nicht sofort.

Bei einer kurzen geplanten Wartung oder echten Überlastung ist 503 ehrlicher als eine hübsche Fehlerseite mit Status 200. HTTP erlaubt bei 503 zusätzlich den Header Retry-After, der kompatiblen Clients einen Zeitpunkt für den nächsten Versuch nennt. Halte den Ausfall kurz und prüfe den gesamten Auslieferungsweg mit CDN, Proxy, Anwendung, Datenbank und Origin.

Für einen Notfall, in dem Googlebot den Server überfordert, nennt Google in seiner Anleitung zur Crawl-Rate vorübergehende 500-, 503- oder 429-Antworten statt 200 als Bremse. Google rät zugleich davon ab, das länger als ein bis zwei Tage zu tun, weil URLs, die über mehrere Tage diese Codes liefern, aus dem Index fallen können. Das ist eine Notfallmaßnahme und keine dauerhafte Crawl-Strategie.

Statuscodes prüfen, ohne das falsche Problem zu lösen

Ein brauchbarer Audit gruppiert Befunde nach Ursache, Template und geschäftlicher Bedeutung. Beginne mit diesen Fragen:

1. Welche indexierbaren und intern verlinkten URLs enden in 4xx oder 5xx?
2. Welche Sitemap-URLs leiten weiter oder schlagen fehl?
3. Welche internen Links führen noch über Redirects?
4. Welche Redirect-Ketten enden an einem unpassenden, nicht indexierbaren oder defekten Ziel?
5. Welche erfolgreichen Seiten wirken leer oder zeigen einen Fehlerzustand?
6. Treten Fehler nur vereinzelt, in einem Template oder auf dem gesamten Host auf?
7. Zeigen Serverlogs dieselben Antworten für Suchmaschinen-Crawler?
8. Welche URLs erhalten noch Besuche, Impressionen oder wertvolle externe Links?

Danach braucht jede Gruppe einen beabsichtigten Zielzustand:

Das Ziel ist nicht, jede URL grün zu färben. Die Serverantwort soll zu der Entscheidung passen, die das Team über diese Ressource tatsächlich getroffen hat.

Was Crawl Foundry prüfen kann

Der Site Audit von Crawl Foundry crawlt die Website mit eigenem Crawler und erfasst für jede gecrawlte URL Statuscode und Weiterleitungen. Weiterleitungsketten mit mehreren Sprüngen erscheinen als eigener Befund, zusammen mit den betroffenen URLs. Im selben Crawl liegen Canonical- und Robots-Angaben, Indexierbarkeit und interne Links vor, jeder Link mit Quelle, Ziel, Ankertext und Position. Der Vergleich zweier Läufe zeigt, ob eine Korrektur die Antworten tatsächlich verändert hat.

Damit wird aus einer allgemeinen Fehlerliste ein nachvollziehbarer Befund an konkreten URLs. Site Audit beweist jedoch nicht, wie Googlebot sich in der Vergangenheit verhalten hat, liest keine privaten Serverlogs und ersetzt Search Console nicht. Er entscheidet auch nicht, ob eine fehlende Seite wiederhergestellt, entfernt oder weitergeleitet werden soll. Dafür bleiben Kontext und redaktionelle Verantwortung nötig.

FAQ

Welche HTTP-Statuscodes sind für SEO besonders wichtig?

Am häufigsten begegnen dir 200, 301, 302, 404, 410, 429, 500, 502, 503 und 504. Hinzu kommen 401 und 403, wenn öffentliche Inhalte unerwartet geschützt sind. Entscheidend ist, ob die Antwort zum beabsichtigten Zustand der URL passt.

Ist jede 404-Antwort schlecht für SEO?

Nein. Für eine fehlende Ressource ohne nahen Ersatz ist 404 korrekt. Untersuchen solltest du defekte interne Links, veraltete Sitemap-Einträge, wertvolle Backlinks und versehentlich entfernte Seiten.

Ist ein Soft 404 schlimmer als ein echter 404?

Es handelt sich um einen anderen Fehler. Ein echter 404 teilt den fehlenden Zustand eindeutig mit. Ein Soft 404 sendet einen erfolgreichen Status, zeigt aber fehlenden oder leeren Inhalt. Technische Antwort und Seiteninhalt widersprechen einander. Beide Fälle können teuer sein, wenn eine wichtige Seite versehentlich verschwunden ist.

Sollte ein dauerhafter Redirect 301 oder 308 verwenden?

Beide gelten für Google als dauerhafte Signale. Nutze den Code, den dein System korrekt unterstützt. 308 ist sinnvoll, wenn Anfragemethode und Body zwingend erhalten bleiben müssen. Für normale Seitenmigrationen ist eine sauber umgesetzte 301 weiterhin üblich und passend.

Erkennt Crawl Foundry jedes Statuscode-Problem?

Nein. Crawl Foundry zeigt die Antworten und Weiterleitungen, die der eigene Crawl erhalten hat. Sporadische Ausfälle, Unterschiede nach User-Agent, Probleme einzelner Edge-Standorte und frühere Googlebot-Antworten können wiederholte Tests, Monitoring, Search Console und Serverlogs erfordern.

Verwandte Begriffe

• Crawling
• Indexierung
• Redirects
• Canonical Tag
• Fortgeschrittene technische SEO
• HTTP- und HTTPS-Grundlagen
• Googlebot

Quellen und weiterführende Links

• Google: Auswirkungen von HTTP-Statuscodes auf Google-Crawler
• Google Search Central: Redirects und Google Search
• Google Search Central: Crawling-Fehler und Soft 404 beheben
• MDN: HTTP-Statuscodes
• RFC 9110: HTTP Semantics

Fazit

Statuscodes funktionieren dann gut, wenn sie die Wahrheit sagen. Eine aktive Seite braucht nützlichen Inhalt und eine erfolgreiche Antwort. Ein dauerhafter Umzug sollte direkt zum Nachfolger führen. Eine entfernte Seite darf korrekt 404 liefern. Ein vorübergehender Ausfall sollte sich nicht als gesunde Seite ausgeben.

Gutes Technical SEO zählt deshalb nicht nur Fehler. Es vergleicht die Antwort mit dem beabsichtigten Seitenzustand, den verweisenden Links, dem ausgelieferten Inhalt und den Belegen der Suchmaschinen. So wird aus einem Statuscode-Bericht ein Reparaturplan statt eines weiteren Dashboards.