HTTP-Statuscodes für SEO richtig einsetzen
Serverantworten korrekt ausliefern, Indexierungsfehler erkennen und Ausfälle sauber behandeln
Serverantworten korrekt ausliefern, Indexierungsfehler erkennen und Ausfälle sauber behandeln
Jeder Abruf einer URL endet mit einer HTTP-Antwort. Ihr dreistelliger Statuscode beschreibt, ob die Anfrage erfolgreich war, eine weitere Aktion erfordert oder fehlgeschlagen ist. Suchmaschinen verwenden dieses Signal, bevor sie den sichtbaren Inhalt bewerten: Eine optisch vollständige Seite mit falschem Status kann deshalb anders verarbeitet werden als beabsichtigt.
Für SEO genügt es nicht, dass eine URL im Browser „funktioniert“. Eine gelöschte Seite darf nicht als 200 OK erscheinen, ein kurzer Serverausfall nicht als 404 Not Found und ein dauerhafter Umzug nicht als dauerhaft bestehende temporäre Umleitung. Status, Inhalt und tatsächlicher Zustand der Ressource müssen dieselbe Aussage treffen.
RFC 9110 ordnet Statuscodes fünf Klassen zu. Für die Indexierung sind vor allem 2xx, 3xx, 4xx und 5xx relevant; 1xx sind vorläufige Antworten innerhalb der HTTP-Kommunikation und normalerweise kein eigenständiges SEO-Steuerungsmittel.
| Klasse | Bedeutung | Typische SEO-Folge |
|---|---|---|
| 2xx | Anfrage erfolgreich | Inhalt kann verarbeitet werden; Indexierung ist trotzdem nicht garantiert |
| 3xx | Weitere Aktion oder Umleitung | Crawler folgt je nach Code dem Ziel und bewertet die URL-Beziehung |
| 4xx | Anfrage kann clientseitig nicht erfüllt werden | URL wird gewöhnlich nicht indexiert oder bei anhaltendem Fehler entfernt |
| 5xx | Server kann eine gültige Anfrage nicht erfüllen | Crawling wird verlangsamt; dauerhafte Fehler gefährden die Indexierung |
Der Code allein erklärt nicht jede Indexierungsentscheidung. Eine 200-Antwort bedeutet nur, dass der Abruf auf HTTP-Ebene erfolgreich war. Google kann die Seite wegen noindex, Canonicalisierung, Duplikaten oder unzureichendem Inhalt trotzdem nicht aufnehmen.
200 OK passt zu einer erreichbaren Seite, deren Antwort den angeforderten Inhalt enthält. Für normale indexierbare HTML-Seiten ist das der erwartete Erfolgsstatus. Ein leerer Body, eine Fehlermeldung oder eine Seite ohne Hauptinhalt kann trotz 200 als Soft 404 erkannt werden.
204 No Content bezeichnet eine erfolgreiche Antwort ohne Inhalt. Der Code ist für Aktionen oder APIs sinnvoll, aber nicht für eine Landingpage, die Suchmaschinen indexieren sollen. 206 Partial Content wird bei Teilabrufen verwendet, etwa für Medien, und sollte nicht versehentlich die reguläre HTML-Antwort ersetzen.
304 Not Modified ist eine Antwort auf einen bedingten Abruf. Sendet ein Crawler beispielsweise If-None-Match oder If-Modified-Since und der Inhalt ist unverändert, kann der Server ohne Body mit 304 antworten. Google verwendet dann die zuvor abgerufene Fassung. ETag und Last-Modified müssen dafür zuverlässig zum tatsächlichen Inhalt passen.
301 und 308 kennzeichnen dauerhafte, 302 und 307 vorübergehende Umleitungen. 303 verweist nach einer Aktion auf eine andere Ressource; 304 ist trotz seiner Nummer keine Weiterleitung auf eine neue URL. Für einen echten URL-Wechsel gehören Status und Location-Header in die Serverantwort.
Eine Weiterleitung ist nur richtig, wenn ein sinnvolles Ziel existiert. Gelöschte Produktseiten pauschal auf die Startseite zu schicken, kann wie ein Soft 404 behandelt werden und hilft Nutzern nicht. Auswahl, Methodensemantik und Testverfahren erläutert der Beitrag SEO-Weiterleitungen richtig einsetzen.
404 Not Found sagt nach RFC 9110 nicht, ob das Fehlen vorübergehend oder dauerhaft ist. 410 Gone ist präziser, wenn der Betreiber weiß, dass die Ressource dauerhaft entfernt wurde. Google akzeptiert beide Codes für nicht mehr vorhandene Inhalte; es ist nicht nötig, vorhandene 404-Antworten massenhaft auf 410 umzustellen.
Eine individuelle Fehlerseite darf Navigation, Suche und hilfreiche Links enthalten. Entscheidend bleibt der HTTP-Status 404 oder 410. Wird dasselbe Template mit 200 OK ausgeliefert, entsteht ein Soft 404. Auch fast leere Seiten, fehlgeschlagene Datenbankabfragen oder nicht geladene JavaScript-Inhalte können von Google entsprechend eingeordnet werden.
# entfernte URL prüfen
curl -I https://www.example.de/nicht-mehr-vorhanden/
# erwartet
HTTP/2 410
content-type: text/html; charset=utf-8404-Antworten sind auf einer gewachsenen Website normal. Handlungsbedarf besteht vor allem bei wichtigen URLs, internen Links auf Fehlerseiten, plötzlichen Anstiegen oder falschen Statuscodes. Eine URL ohne interne oder externe Relevanz muss nicht auf ein beliebiges Ziel umgeleitet werden.
401 Unauthorized bedeutet, dass gültige Zugangsdaten fehlen, und verlangt nach RFC 9110 mindestens eine passende WWW-Authenticate-Angabe. 403 Forbidden bedeutet, dass der Server die Anfrage verstanden hat, den Zugriff aber verweigert. Beide Codes passen zu geschützten Bereichen, nicht zu öffentlich indexierbaren Seiten.
Google weist ausdrücklich darauf hin, 401 oder 403 nicht zur Begrenzung der Crawlrate einzusetzen. Wer Crawler bei Lastproblemen sperrt, beschreibt eine erreichbare Ressource fälschlich als geschützt oder verboten. Für Überlastung sind vorübergehende Serverantworten vorgesehen.
429 Too Many Requests signalisiert Rate Limiting. 503 Service Unavailable bezeichnet eine vorübergehende Nichtverfügbarkeit, etwa während Wartung oder Überlastung. Beide Codes veranlassen Google-Crawler, ihre Abrufe zeitweise zu verlangsamen. Sie dürfen daher nicht als dauerhaftes Betriebsmodell dienen.
Mit Retry-After kann der Server einen Zeitpunkt oder eine Anzahl Sekunden bis zum nächsten sinnvollen Versuch nennen. RFC 9110 definiert dieses Feld für 503; RFC 6585 erlaubt es auch bei 429. Google dokumentiert zugleich, dass länger als wenige Tage anhaltende Nichtverfügbarkeit zur Entfernung betroffener URLs aus dem Index führen kann.
HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Cache-Control: no-store
Content-Type: text/html; charset=utf-8Eine Wartungsseite mit 200 wäre dagegen ein Soft 404 oder könnte den eigentlichen Inhalt ersetzen. Auch die Startseite darf bei einem vollständigen Ausfall 503 senden. Nach Behebung muss jede betroffene URL wieder ihren normalen individuellen Status liefern.
| Status | Bedeutung | Typische Ursache |
|---|---|---|
| 500 | Interner Serverfehler | Anwendungsfehler oder abgebrochene Verarbeitung |
| 502 | Ungültige Antwort eines Upstream-Servers | Proxy, CDN oder Gateway erreicht das Backend fehlerhaft |
| 503 | Dienst vorübergehend nicht verfügbar | Wartung, Kapazitätsgrenze oder gezielte Laststeuerung |
| 504 | Upstream-Antwort überschreitet das Zeitlimit | Langsame Anwendung, Datenbank oder externe Schnittstelle |
Google ignoriert den Inhalt von 5xx-Antworten, reduziert bei gehäuften Fehlern die Crawlrate und entfernt dauerhaft fehlerhafte URLs schließlich aus dem Index. Ein CDN sollte echte Backend-Ausfälle daher nicht mit einer gecachten 200-Seite oder pauschalen 404-Antwort verschleiern. Ursache, betroffene Ebene und Zeitfenster gehören in Monitoring und Serverlogs.
Eine Single-Page-Application liefert häufig für jede Route dasselbe App-Shell-Dokument mit 200 aus. Zeigt die Anwendung nach dem Rendern „Seite nicht gefunden“, bleibt die Serverantwort trotzdem erfolgreich. Google kann das als Soft 404 erkennen; andere Crawler oder Monitoring-Systeme sehen möglicherweise nur 200.
Der Router muss unbekannte URLs serverseitig mit 404 beantworten. Bei Server-Side Rendering oder Edge Rendering kann der Status zusammen mit dem HTML gesetzt werden. Wenn erst eine API feststellt, dass ein Datensatz fehlt, sollte die Architektur diesen Zustand an die HTTP-Antwort der Dokument-URL zurückgeben. Weitere Fallstricke beschreibt JavaScript SEO richtig umsetzen.
Ein einzelner Browseraufruf reicht nicht, weil Weiterleitungen automatisch verfolgt und Fehlerseiten optisch kaschiert werden können. curl zeigt die erste Antwort; mit einer Ausgabevorlage lässt sich die vollständige Kette untersuchen.
# Header der ersten Antwort
curl -I https://www.example.de/produkt-123/
# Status, Redirect-Zahl und endgültige URL
curl -L -s -o /dev/null \
-w '%{http_code} %{num_redirects} %{url_effective}\n' \
https://www.example.de/produkt-123/In der Google Search Console helfen URL-Prüfung, Seitenindexierung und Crawl-Statistiken dabei, den von Google ermittelten Zustand mit Serverlogs und eigenem Crawl abzugleichen.
Gesamtzahlen allein sind wenig aussagekräftig. Ein 404-Anstieg kann durch externe Tippfehler entstehen oder durch eine fehlerhafte interne Navigation. 5xx können einzelne Produktseiten, eine API, einen ganzen Host oder nur eine Region betreffen. Sinnvoll sind Zeitreihen nach Statusklasse, Verzeichnis, Template, Host, User-Agent und Antwortzeit.