HTTP-Statuscodes für SEO: 200, 301, 404 und 503

Wenn eine URL verschwindet, fragen Entwickler das SEO-Team oft: „Welchen Status soll diese Seite liefern?“ Die Antwort steht nicht allein in einer auswendig gelernten Tabelle. Sie hängt davon ab, ob eine gleichwertige Ressource existiert, ob die Unterbrechung vorübergehend oder dauerhaft ist und was ein Crawler bei seinem nächsten Besuch tun soll.

Der falsche Status kann Fehlerseiten erzeugen, die weiterhin 200 liefern, lange Weiterleitungsketten oder Tausende 503-Antworten, die das Crawling verringern. Die richtige Wahl lässt Browser, Suchbots, Caches, Monitoring-Systeme und Wartende denselben Zustand verstehen.

Der HTTP-Status ist eine Nachricht des Servers

Wann immer ein Browser oder Crawler eine URL anfordert, antwortet der Server mit einem Statuscode. Die fünf Hauptklassen sind:

• 1xx: Informationen während der Verarbeitung.
• 2xx: Die Anfrage wurde erfolgreich bearbeitet.
• 3xx: Eine andere Adresse oder Aktion ist erforderlich.
• 4xx: Die Client-Anfrage kann so, wie sie gesendet wurde, nicht erfüllt werden.
• 5xx: Der Server kann eine gültige Anfrage nicht abschließen.

Für SEO muss der Status zum sichtbaren Inhalt passen. Eine Seite, die „Produkt nicht gefunden“ meldet, aber 200 OK liefert, erzeugt eine Soft 404. Eine vollständige Seite, die mit 500 antwortet, gibt Crawlern einen Fehler, dessen Body ignoriert wird. Status und Body sollten keine unterschiedlichen Geschichten erzählen.

2xx-Antworten: Erfolg garantiert keine Indexierung

200 OK

200 bedeutet, dass der Server eine erfolgreiche Antwort geliefert hat. Google kann den Inhalt an die weitere Verarbeitung übergeben, doch eine Indexierung ist nicht garantiert. Die Seite kann trotzdem ausgeschlossen werden – wegen noindex, eines Canonicals auf eine andere URL, Duplikaten, unzureichenden Werts oder anderer Qualitätssignale.

Liefern Sie 200 nur, wenn eine URL echten Inhalt bietet. Verwenden Sie es nicht, um jede Adresse technisch „am Leben“ zu halten, nachdem ein Produkt oder Artikel entfernt wurde.

204 No Content

204 besagt, dass die Anfrage ohne Antwort-Body erfolgreich war. Es passt zu manchen APIs und Aktionen, die keine Darstellung benötigen, nicht zu einer Landingpage, die für die Suche gedacht ist. Eine leere HTML-Seite kann kein nützliches Ergebnis liefern, nur weil ihr Status zur Erfolgsklasse gehört.

206 Partial Content

206 ist üblich, wenn ein Client einen Bereich eines Videos oder einer großen Datei anfordert. Es ist nicht der normale Standard für ein HTML-Dokument. Liefert ein CDN oder Proxy unerwartet für jede Seite 206, prüfen Sie die Regeln für Range-Anfragen und Caching.

3xx-Antworten: gewollte Verlagerung

301 Moved Permanently

Verwenden Sie 301, wenn eine Adresse dauerhaft verschoben wurde und ein gleichwertiges Ziel existiert. Typische Fälle:

• Änderung eines Artikel-Slugs.
• Wechsel von HTTP zu HTTPS.
• Zusammenführung von Artikeln mit derselben Intention.
• Ersatz einer Kategoriestruktur.
• Weiterleitung eines alten Produkts auf einen wirklich gleichwertigen Nachfolger.

Das Ziel muss zum alten Bedarf passen. Ein eingestelltes Produkt auf die Startseite oder eine zu breite Kategorie weiterzuleiten, frustriert Besucher und kann wie eine Soft 404 behandelt werden.

302 Found

302 passt zu einer vorübergehenden Verlagerung: ein kurzes Experiment, eine alternative Seite während der Wartung, zeitlich begrenztes Routing oder eine Kampagne, die zur ursprünglichen URL zurückkehrt. Ist die Verlagerung dauerhaft geworden, ändern Sie die Antwort auf 301, damit ihr Zweck für jeden Client eindeutig ist.

Google kann mehrere Weiterleitungstypen nach Abwägung breiterer Signale ähnlich verarbeiten. Den richtigen Status zu wählen bleibt dennoch wichtig für Browser, Caches, andere Clients und künftige Wartende.

303 See Other

303 folgt oft auf eine POST-Anfrage und schickt den Client per GET auf eine Ergebnisseite. Ein abgesendetes Formular, das zu einer Bestätigungsseite führt, ist ein häufiges Beispiel. Das ist ein Anwendungsablauf und nicht das Hauptwerkzeug einer SEO-URL-Migration.

307 und 308

307 Temporary Redirect und 308 Permanent Redirect behalten die HTTP-Methode bei der Verlagerung bei. 308 ist dauerhaft, 307 vorübergehend. Sie können für gewöhnliche GET-Migrationen dienen, doch Entwickler sollten das Beibehalten der Methode verstehen, bevor sie sie für Formulare und APIs einsetzen.

Weiterleitungsketten: eine Entscheidung, gestreckt über alte URL-Generationen

Ein Artikel begann bei A, zog nach B und später nach C. Leitet A noch auf B und B auf C weiter, braucht jeder Besuch zwei Hops. Eine etablierte Website kann Ketten aus fünf oder sechs Schritten ansammeln, die niemand bewusst entworfen hat.

Die Kosten umfassen:

• Mehr Latenz für Besucher und Crawler.
• Zusätzliche Serveranfragen.
• Schwierigeres Debugging von Canonicals und Analytics.
• Höheres Risiko für einen fehlgeschlagenen Hop oder eine Schleife.
• Interne Links, die eine veraltete Architektur konservieren.

Jede alte Adresse sollte direkt auf das aktuelle Ziel zeigen. Nutzen Sie den Redirect Chain Checker, um jeden Hop, Status, Schleifen und die endgültige URL zu prüfen. Aktualisieren Sie anschließend interne Links, Canonicals und Sitemaps auf die endgültige Adresse, statt sich dauerhaft auf Weiterleitungen zu verlassen.

4xx-Antworten: Probleme mit Adresse oder Zugriff

400 Bad Request

Erhält ein Crawler eine andere Antwort, prüfen Sie die tatsächliche Anfrage sowie autorisierte Server- oder Edge-Protokolle. Öffentliche Cloudflare-Erkennung zeigt keine WAF-Regeln, Header-Limits oder Kontorichtlinien.

401 Unauthorized

401 verlangt eine Authentifizierung. Es ist richtig für angemeldete Bereiche, private APIs und Dokumente mit Berechtigungen. Inhalte, die ranken sollen, können nicht zugleich eine Anmeldung des Crawlers verlangen. Verwenden Sie 401 nicht zur Steuerung der Crawl-Rate; lösen Sie Serverkapazität und URL-Architektur direkt.

403 Forbidden

403 besagt, dass der Server die Anfrage verstanden, aber abgelehnt hat. Übermäßig aggressive CDN-, WAF- und Anti-Bot-Einstellungen können es fälschlich an gültige Crawler liefern. Beginnen öffentliche Seiten, den Index zu verlassen, vergleichen Sie Logs nach Zeit, User-Agent und verifizierter IP, statt einem User-Agent-String allein zu vertrauen.

404 Not Found

404 ist korrekt, wenn eine Ressource nicht existiert und keinen gleichwertigen Ersatz hat. Nicht jede 404 ist ein „SEO-Fehler“, der eine Weiterleitung braucht. Eine falsch getippte Adresse, ein eingestelltes Produkt oder ein entfernter Testartikel darf normal 404 liefern.

Eine nützliche 404-Seite sollte:

• Kurz erklären, dass die Ressource nicht verfügbar ist.
• Navigation und Suche gegebenenfalls beibehalten.
• Verwandte Bereiche vorschlagen, ohne eine Weiterleitung zu erzwingen.
• Weiterhin den Status 404 liefern, nicht 200.

410 Gone

410 stellt ausdrücklich fest, dass die Ressource absichtlich entfernt wurde. Für die Google-Suche führen dauerhaft gelieferte 404 und 410 beide dazu, dass die URL entfernt oder nicht indexiert wird. Wählen Sie 410, wenn die Anwendung weiß, dass die Ressource beendet ist, und 404, wenn sie schlicht fehlt. Tausende gültige 404 nur in der Hoffnung auf eine schnellere Entfernung in 410 zu ändern, bringt wenig.

429 Too Many Requests

429 zeigt an, dass ein Client zu viele Anfragen gestellt hat. Google behandelt es als Signal für Serverüberlastung und kann das Crawling vorübergehend verringern. Liefert ein Rate Limiter häufig 429 an Crawler, prüfen Sie Kontingente, Caches und Verifizierungsregeln. Alle Limits zu entfernen ist nicht die Antwort; verlässliche Kapazität ist es.

5xx-Antworten: Der Server versagt

500 Internal Server Error

500 steht für einen nicht näher bestimmten Anwendungs- oder Serverfehler. Gelegentliche vorübergehende Fehler kommen vor, doch eine hohe Rate über viele URLs weist auf ein Problem bei Deployment, Datenbank, Abhängigkeit oder Kapazität hin.

502 Bad Gateway

502 tritt häufig auf, wenn ein Proxy oder CDN eine ungültige Antwort von einem Upstream-Dienst erhält. Prüfen Sie den Zustand des Anwendungsservers, Timeouts zwischen den Schichten, internes DNS und Verbindungslimits.

503 Service Unavailable

503 ist angemessen bei kurzer Wartung oder vorübergehender Überlastung. Ein Retry-After-Header kann Clients mitteilen, wann sie es erneut versuchen sollen. Eine Wartungsseite sollte 503 liefern, nicht 200; andernfalls können Suchsysteme auf der ganzen Website denselben Wartungstext als gültigen Inhalt antreffen.

Lassen Sie 503 nicht tagelang bestehen, wenn die Website tatsächlich geschlossen oder die Ressource dauerhaft verschwunden ist. Anhaltende Serverfehler können schließlich indexierte URLs entfernen und die Crawl-Aktivität der gesamten Website verringern.

504 Gateway Timeout

504 bedeutet, dass ein Gateway zu lange auf seinen Upstream gewartet hat. Suchen Sie nach langsamen Datenbankabfragen, abhängigen APIs, Cache-Misses, erschöpften Workern und uneinheitlichen Timeouts zwischen CDN und Origin.

Eine Entscheidungstabelle für Statuscodes

Die Tabelle ist ein Ausgangspunkt. Im E-Commerce kann ein vorübergehend vergriffenes Produkt weiterhin 200 mit Produktinformationen, Verfügbarkeit und Alternativen liefern. Ein dauerhaft eingestelltes Produkt mit nahezu gleichwertigem Nachfolger kann 301 verwenden; ohne sinnvollen Ersatz sind 404 oder 410 ehrlicher.

Soft 404: Erfolgsstatus, gescheiterter Inhalt

Zu den typischen Soft-404-Fällen gehören:

• Eine leere Produktmenge, die 200 liefert.
• Jede fehlerhafte URL, die die Startseite rendert.
• Interne Suchseiten ohne Ergebnis, die indexierbar bleiben.
• Gelöschter Inhalt, der nur Header und Footer hinterlässt.
• Nicht verwandte URLs, die auf eine breite Kategorie weiterleiten.

Prüfen Sie den Bericht zur Seitenindexierung in der Search Console und nehmen Sie Stichproben der betroffenen URLs. Fügen Sie einer Fehlervorlage nicht nur einige Sätze hinzu, um einer Einstufung zu entgehen. Liefern Sie den ehrlichen Status oder Inhalt, der den ursprünglichen Bedarf wirklich beantwortet.

robots.txt kann keinen Antwortstatus ersetzen

Ein Disallow für /old-page in der robots.txt teilt einem Crawler nur mit, dass er den Body nicht abrufen darf; die Seite kann daher weiter in den Suchergebnissen erscheinen, ohne dass bekannt ist, ob sie verschoben wurde, verschwunden ist oder eine Anmeldung verlangt – prüfen Sie dies mit dem Robots.txt Checker.

Wurde die URL verschoben, leiten Sie sie weiter. Ist sie verschwunden, liefern Sie 404 oder 410. Bleibt sie verfügbar, soll aber nicht indexiert werden, lassen Sie Crawler zugreifen und noindex lesen. Der Robots.txt Checker findet versehentliche Sperren, doch der URL-Lebenszyklus gehört weiterhin in die Antwort.

Statuscodes pro Template prüfen, nicht an ein paar polierten Seiten

Eine Startseite mit 200 sagt wenig über die Katalog-Gesundheit. Nehmen Sie Stichproben und aggregieren Sie pro Template:

1. Startseite und Hauptnavigation.
2. Kategorien, Paginierung und Filter.
3. Lieferbare, vorübergehend nicht verfügbare und eingestellte Produkte.
4. Neue, alte, umbenannte und gelöschte Artikel.
5. Varianten mit Parametern, Groß-/Kleinschreibung, Schrägstrich und Hostnamen.
6. Sitemaps, robots.txt, Schlüsselbilder und wichtige Dateien.

Vergleichen Sie jeden Status mit seinem Canonical, den Robots-Direktiven, der Sitemap-Zugehörigkeit und den internen Links. Eine 301-URL sollte nicht in einer Sitemap bleiben. Eine 404 sollte nicht Tausende interne Links erhalten. Eine 200-Seite, die indexiert werden soll, sollte nicht anderswohin kanonisiert werden.

Nutzen Sie den SEO Checker, um eine repräsentative Antwort und ihre On-Page-Signale zu prüfen, und führen Sie dann ein kostenloses SEO-Audit durch, um wiederholte Fehler auf Template-Ebene zu finden.

Überwachen, bevor der Traffic fällt

Richten Sie Warnungen für die 5xx-Rate, die Antwortzeit und Statusänderungen bei kritischen URLs ein. Führen Sie nach jedem Deployment oder jeder Migration einen Smoke-Test durch, der Folgendes abdeckt:

• Startseite, Anmeldung und Umsatzseiten.
• Eine repräsentative URL je Template.
• Robots.txt und den Sitemap-Index.
• Weiterleitungen von alten Adressen.
• Einen nicht existierenden Pfad, um eine echte 404 zu bestätigen.

Server-Logs sollten Status, Pfad, Dauer, User-Agent und Request-ID lange genug aufbewahren, um Vorher-Nachher-Vergleiche zu ermöglichen. Betrifft ein Fehler nur einen Bot oder eine Region, beantworten Logs die Frage meist schneller, als eine Seite von einem einzelnen Laptop neu zu laden.

Fazit

Ein HTTP-Statuscode ist ein kompakter Vertrag zwischen Server und Client. Suchsysteme nutzen diesen Vertrag, um zu verstehen, ob Inhalt existiert, verschoben wurde, verschwunden oder vorübergehend nicht verfügbar ist. Wählen Sie den Code nach dem echten URL-Lebenszyklus, halten Sie ihn konsistent mit dem Body und bereinigen Sie Sitemaps und interne Links nach jeder Verlagerung.

Leiten Sie nicht jeden Fehler auf die Startseite um, liefern Sie für leere Seiten kein 200 und verwenden Sie robots.txt nicht, um einen unentschiedenen Lebenszyklus zu verbergen. Ein klares Statussystem lässt Besuchern, Crawlern und Betreibern weniger Raum für Rätselraten.

Quellen: Google Search Central zu HTTP-Statuscodes und Crawling und Googles Hinweise zu Weiterleitungen.