200 OK: Bedeutung

TL;DR — Eine 200 OK-Antwort bedeutet: Der Server sagt „Hier ist die angeforderte Seite, alles ist in Ordnung.“ Das ist der unauffällige Erfolgscode, den jede Seite zurückgeben soll, die in Google erscheinen soll. Ein 200 allein garantiert jedoch nicht, dass die Seite indexiert wird — Google prüft weiterhin, ob der Inhalt eine Indexierung wert ist. Ein 200 für eine tatsächlich defekte oder leere Seite ist ein Fehler, kein grünes Signal.

Was 200 OK bedeutet

Wenn Ihr Browser oder Googlebot einen Server nach einer Seite fragt, antwortet der Server mit einem dreistelligen Statuscode, bevor er irgendetwas anderes sendet. 200 OK ist der Code für „alles in Ordnung“ — der Server hat die angeforderte Ressource gefunden und liefert sie zurück, normalerweise einschließlich des Seiteninhalts. (Technisch erlaubt die Spezifikation in manchen Fällen einen 200-Status mit leerem Body, aber für eine Seite, die Menschen lesen sollen, ist jedes Mal ein echter Body erwünscht.) Sie bemerken diesen Code fast nie, weil er bedeutet, dass nichts schiefgelaufen ist. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Patrick Stox fasst es im Ahrefs-Leitfaden zu HTTP-Statuscodes in drei Wörtern zusammen: “200 OK – All good. Everything is successful.” (Übersetzung) Der Status ist 200 OK; alles ist in Ordnung und erfolgreich.

Für die Seiten Ihrer Website, die Menschen in der Suche finden sollen, ist 200 genau der Statuscode, den sie zurückgeben sollen.

Warum ein 200 nicht die ganze Geschichte erzählt

Hier liegt der Teil, den die meisten Seiten zur Frage „Was bedeutet 200?“ überspringen: Ein 200 bringt Ihre Seite in die Prüfung für die Indexierung, aber nicht garantiert in den Index. Das sind zwei sehr unterschiedliche Dinge.

Betrachten Sie den 200 als Eintrittskarte. Nach dem Einlass entscheidet Google weiterhin, ob der Inhalt es wert ist, behalten zu werden — ist er hochwertig, nahezu ein Duplikat einer anderen Seite, dünn oder leer, oder enthält er ein noindex-Tag, das Google fernhalten soll? Jeder dieser Punkte kann dazu führen, dass eine vollkommen gesunde 200-Seite trotzdem nicht indexiert wird.

Wenn eine Seite also 200 zurückgibt, aber in Google nicht erscheint, liegt das Problem nicht am Statuscode — sondern am Inhalt oder an der Konfiguration.

Die Falle: ein 200, der in Wirklichkeit „nicht gefunden“ bedeutet

Der tückischste Fehler ist eine Seite, die 200 zurückgibt, deren Inhalt aber sagt: „Das gibt es nicht.“ Ein nicht lieferbares Produkt mit einer leeren Seite, ein gelöschter Artikel, der weiterhin eine leere Vorlage lädt, eine Suchergebnisseite ohne Treffer — der Server sendet einen freundlichen 200, aber dort ist nichts Reales.

Google schaut über den Code hinaus auf den tatsächlichen Inhalt, entscheidet, dass die Seite leer oder fehlerhaft ist, und kennzeichnet sie in der Search Console als Soft 404 — behandelt sie also wie eine echte „Nicht gefunden“-Seite. Das wird im Artikel zu Soft-404-Fehlern ausführlich behandelt; kurz gesagt: Ist eine Seite tatsächlich verschwunden, sollte sie 404 oder 410 zurückgeben, nicht 200.

Die eine Regel, die Sie sich merken sollten

Eine Seite, die in Google erscheinen soll, sollte mit echtem Inhalt 200 zurückgeben. Ist die Seite verschwunden, verwenden Sie 404 oder 410. Wurde sie verschoben, leiten Sie die URL weiter (301). Ist sie ein Duplikat einer anderen Seite, verwenden Sie ein Canonical-Tag. Googles genaue Formulierung, den Unterschied zwischen 200 und 204 und die Prüfung dessen, was Googlebot tatsächlich erhalten hat, finden Sie im Tab Fortgeschritten.

TL;DR — 200 OK ist der standardmäßige 2xx-Erfolgscode (RFC 9110 §15.3.1): Der Server hat die Anfrage erfüllt und der Body stellt bei GET/HEAD eine Repräsentation der Ressource dar. Standardmäßig ist die Antwort heuristisch cachebar. Für SEO ist 200 notwendig, aber nicht ausreichend — Googles eigene Dokumentation sagt, die Indexierungspipeline “may index the content, but that’s not guaranteed,” (Übersetzung) „den Inhalt indexieren kann, aber das nicht garantiert ist“, sodass Qualität, Duplikate, dünner Inhalt und noindex zusätzlich zum 200 über das Ergebnis entscheiden. Der klassische Fehler ist der Soft 404: ein 200 um fehlerhaften oder leeren Inhalt herum, den Google auf Inhaltsebene erkennt und unabhängig vom Code als Soft 404 meldet. Vergleichen Sie 200 (Body erwartet) mit 204 (leerer Body, auf Seiten wie ein Soft 404 behandelt) und 304 (ein Caching-Signal, keine Indexierungsentscheidung). Prüfen Sie außerdem, was Googlebot erhalten hat — Cloaking, Bot-Blockierung, Geo-Regeln und CDN-/WAF-Konfiguration können ihm einen anderen Code liefern als Ihrem Browser.

Was 200 laut Spezifikation bedeutet

RFC 9110 (HTTP Semantics) ist die aktuelle maßgebliche Quelle, und §15.3.1 ist eindeutig: “The 200 (OK) status code indicates that the request has succeeded.” (Übersetzung) „Der Statuscode 200 (OK) zeigt an, dass die Anfrage erfolgreich war.“ Was der Body enthält, hängt von der Request-Methode ab. Bei den für Seiten wichtigen Methoden GET und HEAD ist der Inhalt eine Repräsentation der Zielressource. Die RFC schränkt dies außerdem ein: Abgesehen von Antworten auf CONNECT wird von einem 200 erwartet, dass er Inhalt überträgt, sofern die Nachrichtenrahmung nicht ausdrücklich eine Länge von null signalisiert — „ein 200 hat immer einen Body“ ist also eine Kurzform, keine absolute Regel. In der Praxis ist für eine Seite, die indexiert werden soll, genau diese Kurzform das Ziel: ein echter Body, kein leerer. Ein 200 ist standardmäßig außerdem “heuristically cacheable” (Übersetzung) „heuristisch cachebar“, sofern keine Cache-Control-Direktive etwas anderes sagt; deshalb sind Validierungs-Header wie ETag und Last-Modified bei häufig erneut gecrawlten Seiten relevant. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Technisch gilt 200 nicht nur für Seiten. Die RFC legt fest, was „Erfolg“ je nach Methode bedeutet:

Bei Methoden außer GET sehen Sie häufig keinen 200 — MDN weist darauf hin, dass erfolgreiche PUT- oder DELETE-Anfragen “often do not result in a 200 OK response,” (Übersetzung) „oft nicht zu einer 200-OK-Antwort führen“, während 201 Created oder 204 No Content üblicher sind. Für Seiten-URLs ist das nicht SEO-relevant; die zentrale Aussage lautet: Für ein Dokument, das indexiert werden soll, ist 200 mit echtem Body das Ziel.

Notwendig, aber nicht ausreichend für die Indexierung

Das ist der wichtigste Punkt, den es richtig zu verstehen gilt, und genau hier liegen die meisten konkurrierenden Glossarseiten eindeutig falsch. Sie sagen: „200 bedeutet, dass die Seite indexiert wird.“ Googles eigene Dokumentation sagt etwas anderes. Bei einem 200 gibt Google “passes on whatever it received to the next processing step… For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (Übersetzung) „alles, was es erhalten hat, an den nächsten Verarbeitungsschritt weiter … Für Google Search folgt anschließend die Indexierungspipeline. Die Indexierungssysteme können den Inhalt indexieren, aber das ist nicht garantiert.“ Evidence for this claim Google passes a 2xx response to its indexing pipeline, which may index the content but does not guarantee that it will do so; error-like content can be classified as a soft 404. Scope: Google Search handling of 2xx page responses and soft 404s. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Der 200 ist also ein Vertrag über die HTTP-Antwort, keine Zusage über das Schicksal der Seite in der Suche. Nach dem 200 bewertet Google unabhängig:

• Qualität — dünne, wenig wertvolle oder automatisch erzeugte Seiten werden möglicherweise nicht indexiert.
• Duplikate — ein nahezu identisches Duplikat einer stärkeren URL kann dieser URL zugeordnet werden, statt selbst indexiert zu werden (das Canonical-Tag steuert diesen Fall).
• Direktiven — ein noindex in einem Meta-Tag oder einem X-Robots-Tag-Header hält die Seite auch bei einem perfekten 200 aus dem Index.

Auch Patricks Ahrefs-Leitfaden zieht diese Linie auf Ebene der gesamten Statuscode-Familie: “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (Übersetzung) „Die meisten 2xx-Codes ermöglichen die Indexierung von Seiten. Solche Antworten werden jedoch als Soft 404 behandelt und nicht indexiert.“ Der 200 macht eine Seite indexierungsfähig; er macht sie nicht indexiert.

Die Soft-404-Falle

Das deutlichste Beispiel dafür, dass „200 nicht die ganze Geschichte ist“, ist der Soft 404. Googles Dokumentation zu Statuscodes beschreibt den Mechanismus: “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (Übersetzung) „Wenn der Inhalt der Google-Suche einen Fehler nahelegt — eine leere Seite oder eine Fehlermeldung —, zeigt die Search Console einen Soft-404-Fehler an.“ Entscheidend ist: Die Klassifizierung basiert auf dem gerenderten Inhalt, nicht auf dem HTTP-Code. Googles Indexierungspipeline schaut über den 200 hinaus auf den tatsächlichen Seiteninhalt. Wirkt er wie „nicht gefunden“, wird die Seite wie eine echte 404 eingeordnet und gemeldet.

Die Fälle für den Realitätscheck: eine ausgelistete Produktseite, die jetzt eine leere Vorlage lädt, ein gelöschter Artikel, der weiterhin eine 200-Hülle zurückgibt, eine gefilterte Kategorieseite oder ein Suchergebnis mit null Einträgen und der Meldung „Hier gibt es nichts“. Jede dieser Seiten liefert technisch korrekt 200, teilt Nutzern und Google aber mit, dass es nichts zu sehen gibt.

Diese Website hat einen eigenen Artikel zu Soft-404-Fehlern mit den Erkennungsmechanismen und Lösungen — ich wiederhole sie hier nicht. Für die Diskussion über 200 bleibt die einfache Schlussfolgerung: 200 auf einer wirklich verschwundenen Seite ist die Voraussetzung für einen Soft 404. Die Lösung besteht darin, den Code an die Realität anzupassen.

Eine verwandte Falle: Transporterfolg ist kein Anwendungserfolg

Ein kurzer, abgegrenzter Einschub, weil dieses Thema in API- und Monitoring-Kreisen auftaucht: HTTP- und Anwendungsebene können voneinander abweichen. Ein API-Endpunkt kann 200 mit einem JSON-Fehlerobjekt im Body senden; eine Seite kann 200 senden, während eine Backend-Abhängigkeit unbemerkt ausgefallen ist und statt des eigentlichen Inhalts einen defekten Block rendert. Die Statuszeile sagt „ordnungsgemäß ausgeliefert“ — mehr behauptet sie nicht. Ob die Payload tatsächlich korrekt ist, ist eine separate Frage, die der Statuscode nicht beantwortet. Fachleute sind sich uneinig, ob eine API einen Fehler mit einem Status ungleich 200 oder mit 200 und einer Fehler-Payload signalisieren sollte; das ist ein Vertrag, den jedes Team selbst festlegt, keine HTTP-Regel. Für den SEO-Fokus dieser Website ist die entsprechende Seitenversion dasselbe Soft-404-Problem: Vertrauen Sie nicht allein der Statuszeile, sondern prüfen Sie, was der Body tatsächlich enthält.

200 vs. 204 vs. 304 — nicht gleichsetzen

Drei Codes werden häufig verwechselt, und nur einer davon ist der Erfolgscode „Hier ist Ihre Seite“:

204 ist ein echter Erfolgscode, aber sein leerer Body gibt einem Crawler nichts zu indexieren — auf einer Seiten-URL landet er daher im Soft-404-Bereich (das ist ein separater Artikel; verwechseln Sie den Fall des leeren Bodys nicht mit einem normalen 200). 304 gehört nicht einmal zur selben Familie — er beantwortet eine bedingte Anfrage (If-None-Match / If-Modified-Since), indem er dem Client mitteilt, dass seine Cache-Kopie noch aktuell ist. Er enthält keinen Body und sagt nichts darüber aus, ob indexiert werden soll; er dient der Crawl-Effizienz und ist kein Duplikat von 200. Die häufige Frage „200 und 304 — sind das nicht dasselbe?“ setzt eine Caching-Optimierung mit einer Erfolgsantwort gleich.

Bestätigen, was Googlebot tatsächlich sieht

Hier lassen fast alle konkurrierenden Artikel eine Lücke: Verschiedene Clients können für dieselbe URL unterschiedliche Codes erhalten. Ihr Browser kann einen sauberen 200 sehen, während Googlebot etwas anderes erhält — manchmal absichtlich (Cloaking, ein Verstoß gegen Googles Search Essentials), häufiger versehentlich durch WAF-/Bot-Blockierungsregeln, Geo-IP-Targeting, CDN-Edge-Logik oder ein A/B-Testing-Setup, das bei Bots fehlschlägt.

„In meinem Browser ist es 200“ ist daher kein Beweis dafür, dass „Google 200 sieht“. Die richtige Diagnose besteht darin, zu prüfen, was Googlebot selbst erhalten hat:

• GSC-URL-Prüfung — führen Sie einen Live-Test aus, um Status und gerenderten Inhalt zu sehen, die Google abruft, nicht das, was Ihr Rechner sieht.
• Server-/CDN-Logs — die maßgebliche Quelle dafür, welchen Code jeder User-Agent tatsächlich erhalten hat.

Ein einfaches curl -I aus Ihrem Terminal ist nützlich, stellt aber nur eine weitere Client-Anfrage dar, für die andere Edge-Regeln gelten können als für Googlebot — behandeln Sie das Ergebnis als Datenpunkt, nicht als letztes Wort.

200er prüfen und überwachen

• Browser-DevTools — Tab „Network“, neu laden, die Dokumentanfrage anklicken und die Spalte „Status“ lesen.
• Kommandozeile — curl -I https://example.com/page für die Header einer einzelnen Anfrage, curl -IL zum Verfolgen der Weiterleitungskette.
• Google Search Console — die URL-Prüfung meldet den gecrawlten Status und ermöglicht einen Live-Test.
• Bing Webmaster Tools — mit dem URL-Inspection-Tool lässt sich auf Bing-Seite prüfen, was Bingbot erhalten hat. (Bing veröffentlicht keine eigene Dokumentation dazu, wie Statuscodes die Indexierung beeinflussen — das ist besser, als eine Bing-Richtlinie zu erfinden.)
• Crawler — Screaming Frog und Ahrefs Site Audit zeigen Statuscodes für die gesamte Website gesammelt; die kostenlose Ahrefs SEO Toolbar zeigt den Code der gerade geöffneten Seite.

So sieht „gesund“ aus: Ihre wichtigen, kanonischen URLs geben konsistent 200 mit echtem Inhalt zurück, und Seiten, die verschwunden oder verschoben sein sollten, liefern 404/410 oder stattdessen 301 — keinen irreführenden 200.

Die Entscheidung in einer Zeile

Passen Sie den Code an die Realität an. Soll die Seite indexiert werden → 200 mit substanziellen Inhalten. Dauerhaft verschwunden → 404 oder 410 (siehe 404-not-found). Verschoben → 301. Duplikat einer anderen URL → verweisen Sie mit einem Canonical-Tag auf die bevorzugte Version, statt einen Code ungleich 200 erzwingen zu wollen. Der 200 ist das grüne Signal für Seiten, die es wirklich verdienen — nicht mehr und nicht weniger.

KI-Zusammenfassung

Eine verkürzte Zusammenfassung der fortgeschrittenen Fassung:

• 200 OK ist der standardmäßige 2xx-Erfolgscode (RFC 9110 §15.3.1): Der Server hat die Anfrage erfüllt und der Body stellt bei GET/HEAD die Ressource dar. Standardmäßig ist er heuristisch cachebar. Die RFC beschreibt einen Body als erwartet, nicht als absolut zwingend — ein 200 mit Länge null ist technisch gültig, aber eine Seite, die indexiert werden soll, braucht einen echten Body.
• Notwendig, aber nicht ausreichend für die Indexierung. Googles eigene Dokumentation sagt: “may index the content, but that’s not guaranteed.” (Übersetzung) „Die Indexierungssysteme können den Inhalt indexieren, aber das ist nicht garantiert.“ Qualität, Duplikate, dünner Inhalt und noindex werden zusätzlich zum 200 bewertet. Die meisten konkurrierenden Seiten liegen falsch, wenn sie „200 = indexiert“ sagen.
• Die Soft-404-Falle: Ein 200 um fehlerhaften oder leeren Inhalt herum wird auf Inhaltsebene erkannt und in der Search Console als Soft 404 gemeldet — “if the content suggests an error… Search Console will show a soft 404 error.” (Übersetzung) „Wenn der Inhalt auf einen Fehler hindeutet, zeigt die Search Console einen Soft-404-Fehler an.“ Ein 200 auf einer tatsächlich verschwundenen Seite ist die Voraussetzung dafür. Siehe den Artikel zu Soft-404-Fehlern.
• Eine parallele Falle: HTTP- und Anwendungsebene können voneinander abweichen — ein 200 kann ein API-Fehler-Payload oder einen still defekten Backend-Block enthalten. Die Statuszeile bestätigt nur den erfolgreichen Transport, nicht die Korrektheit des Payloads.
• 200 vs. 204 vs. 304: 200 = Erfolg mit echtem Body (für die Indexierung geeignet); 204 = Erfolg mit leerem Body, auf Seiten-URLs wie ein Soft 404 behandelt (siehe 204-no-content); 304 = ein Caching-Signal für eine bedingte Anfrage, keine Indexierungsentscheidung.
• Prüfen Sie, was Googlebot erhalten hat. Verschiedene Clients können wegen Cloaking, Bot-Blockierung, Geo-Regeln oder CDN-/WAF-Konfiguration unterschiedliche Codes für eine URL sehen. „200 in meinem Browser“ ≠ „Google sieht 200“. Prüfen Sie dies über den Live-Test der GSC-URL-Prüfung oder Server-Logs, nicht nur mit Browser oder curl.
• Passen Sie den Code an die Realität an: gewünscht → 200 mit echtem Inhalt; verschwunden → 404/410; verschoben → 301; Duplikat → Canonical-Tag. Wie Patrick sagt: „200 OK – Alles in Ordnung. Alles ist erfolgreich“ — für eine Seite, die wirklich dort sein sollte.

Offizielle Dokumentation

Primärquellen dazu, was 200 bedeutet und wie Google damit umgeht.

HTTP-Spezifikation und Browserreferenz

• RFC 9110 §15.3.1 — 200 OK — die maßgebliche Definition: erfolgreiche Anfrage, Body-Semantik je Methode und heuristische Cachebarkeit.
• MDN — 200 OK — verständliche Einordnung, standardmäßige Cachebarkeit und die Besonderheit bei PUT/DELETE (201/204 sind stattdessen üblich).

Google Search Central

• Wie HTTP-Statuscodes sowie Netzwerk- und DNS-Fehler die Google-Suche beeinflussen — die Formulierung zur 2xx-Behandlung (“may index the content, but that’s not guaranteed” (Übersetzung) „kann den Inhalt indexieren, aber das ist nicht garantiert“) und der Querverweis zum Soft 404.
• Soft-404-Fehler — Bericht zur Seitenindexierung — Googles eigene Definition des 200, der in Wirklichkeit ein Fehler ist, und warum ein Erfolgsstatus für eine verschwundene Seite keine gute Praxis ist.
• Cloaking — warum eine URL Nutzern einen anderen Code oder Inhalt liefern kann als Googlebot und warum dies bei Manipulationsabsicht ein Verstoß ist.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — die Bing-Funktion zur Bestätigung der HTTP-Antwort, die Bingbot für eine URL erhalten hat. (Es gibt keine von Bing verfasste Dokumentation dazu, wie Statuscodes die Indexierung beeinflussen.)

Zitate aus den Quellen

Wörtlich dokumentierte Aussagen. Jeder Link führt als Deep-Link direkt zur zitierten Passage auf der Quellseite.

Die HTTP-Spezifikation

• “The 200 (OK) status code indicates that the request has succeeded.” (Übersetzung) „Der Statuscode 200 (OK) zeigt an, dass die Anfrage erfolgreich war.“ — RFC 9110, HTTP Semantics, §15.3.1. Abschnitt lesen

MDN Web Docs

• “The HTTP 200 OK success status response code indicates that a request has succeeded. A 200 OK response is cacheable by default.” (Übersetzung) „Der Erfolgsstatuscode HTTP 200 OK zeigt an, dass eine Anfrage erfolgreich war. Eine 200-OK-Antwort ist standardmäßig cachebar.“ Zum Zitat springen

Google Search Central — 2xx-/200-Behandlung

• “Google passes on whatever it received to the next processing step (which is product specific). For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (Übersetzung) „Google gibt alles, was es erhalten hat, an den nächsten Verarbeitungsschritt weiter (der produktspezifisch ist). Für die Google-Suche ist das nächste System die Indexierungspipeline. Die Indexierungssysteme können den Inhalt indexieren, aber das ist nicht garantiert.“ — Googles Dokumentation zu HTTP-Statuscodes, Eintrag zu 200. Googles Statuscode-Dokumentation

• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (Übersetzung) „Wenn der Inhalt für die Google-Suche auf einen Fehler hindeutet, eine leere Seite oder eine Fehlermeldung enthält, zeigt die Search Console einen soft 404-Fehler.“ — dieselbe Dokumentation, Querverweis zum Soft 404. Googles Statuscode-Dokumentation

Patrick Stox — Ahrefs

• “200 OK – All good. Everything is successful.” (Übersetzung) „200 OK – Alles in Ordnung. Alles ist erfolgreich.“ — aus meinem Leitfaden zu HTTP-Statuscodes im Ahrefs-Blog. Zum Zitat springen

• “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (Übersetzung) „Die meisten 2xx-Antworten können die Indexierung zulassen. Antworten ohne Inhalt gelten dagegen als Soft-404s und erscheinen nicht im Index.“ — aus demselben Leitfaden zur Behandlung der 2xx-Familie. Zum Zitat springen

200 OK — Kurzreferenz

Was es ist

200 im Vergleich zu den häufig verwechselten Statuscodes

Welchen Code sollte diese URL zurückgeben?

• Soll in den Index → 200 mit echtem, substanziellem Inhalt.
• Dauerhaft verschwunden → 404 oder 410 (siehe 404-not-found).
• Auf eine neue URL verschoben → 301.
• Duplikat einer anderen URL → den 200 beibehalten und ein Canonical-Tag auf die bevorzugte Version setzen.
• Absichtlich leer (API/Beacon) → 204 (siehe 204-no-content) — niemals auf einer Seite.

Kurzfakten

• Ein 200 macht eine Seite für die Indexierung geeignet, aber nicht indexiert — Google entscheidet dies separat anhand von Qualität, Duplikaten, dünnem Inhalt und noindex.
• Ein 200 für eine tatsächlich verschwundene oder leere Seite ist aus Googles Sicht ein Soft 404.
• Verschiedene Clients können für eine URL unterschiedliche Codes sehen — prüfen Sie über die GSC-URL-Prüfung oder Server-Logs, was Googlebot erhalten hat, nicht nur über Browser oder curl.
• Prüfen Sie Codes mit: DevTools-Network-Tab, curl -I / curl -IL, GSC-/Bing-URL-Prüfung, Screaming Frog, Ahrefs Site Audit/Toolbar.

Häufige Mythen über 200 OK

„Ein 200-Statuscode bedeutet, dass die Seite indexiert ist.“ Falsch. 200 bedeutet, dass der Server erfolgreich Inhalt zurückgegeben hat; die Indexierung ist eine nachgelagerte, separate Entscheidung. Googles eigene Dokumentation sagt: “may index the content, but that’s not guaranteed.” (Übersetzung) „Die Indexierungssysteme können den Inhalt indexieren, aber das ist nicht garantiert.“ Qualität, Duplikate, dünner Inhalt und noindex werden zusätzlich zum 200 bewertet.

„Wenn die Search Console einen Soft 404 zeigt, hat mein Server einen Fehler.“ Nicht unbedingt. Soft 404 ist kein Code, den Ihr Server sendet — es ist eine Bezeichnung, die Google aufgrund des Widerspruchs zwischen dem 200-Status und einem Inhalt vergibt, der wie ein Fehler oder eine leere Seite wirkt. Der Server tut genau das, wofür er konfiguriert wurde (200 senden); das Problem liegt im Inhalt, nicht im Header.

„200 ist immer gut, ohne Ausnahme.“ Nicht immer. Ein 200 für eine URL, die 404 liefern sollte — ein gelöschtes Produkt, ein abgelaufenes Angebot, eine leere Suchergebnisseite — ist schädlich. Er kann dazu führen, dass Google die URL als Soft 404 behandelt und erneut crawlt, obwohl sie nichts Sinnvolles bietet.

„Mein Browser zeigt 200, also sieht Google definitiv auch 200.“ Nicht garantiert. Bot-Blockierung, Cloaking, Geo-IP-Regeln und CDN-/WAF-Konfiguration können Googlebot eine andere Antwort liefern als einem menschlichen Browser. Überprüfen Sie dies mit der URL-Prüfung oder den Server-Logs.

„200 und 204 sind im Grunde dasselbe — beide bedeuten Erfolg.“ Beide gehören zu 2xx, aber 204 hat absichtlich einen leeren Body. Das ist für APIs und Beacons in Ordnung und für eine Seite, die indexiert werden soll, falsch — ein 204 auf einer Seiten-URL wird wie ein Soft 404 behandelt (siehe 204-no-content).

„200 und 304 — ist das nicht dasselbe?“ Nein. 304 Not Modified ist ein Caching-Mechanismus, der eine bedingte Anfrage beantwortet (If-None-Match / If-Modified-Since) und den Client anweist, seine Cache-Kopie zu verwenden. Er enthält keinen Body und ist keine Indexierungsentscheidung — ein anderes Konzept als 200.

Warum eine 200-OK-Seite trotzdem scheitert

Die Search Console bezeichnet die URL als Soft 404

Symptom: Die URL gibt 200 zurück, aber der Bericht zur Seitenindexierung meldet sie als Soft 404.

Wahrscheinliche Ursache: Der Response-Body wirkt leer, defekt oder wie eine Fehlerseite. Häufige Fälle sind ein ausgelistetes Produkt ohne nützliche Produktinformationen, ein gelöschter Artikel in einer ansonsten vollständigen Vorlage oder eine Suche ohne Treffer.

Lösung: Passen Sie die Antwort an die Realität an. Stellen Sie substanziellen Inhalt wieder her, wenn die Seite existieren soll, geben Sie 404 oder 410 zurück, wenn sie verschwunden ist, oder verwenden Sie 301, wenn sie verschoben wurde. Führen Sie den Live-Test der URL-Prüfung erneut aus und bestätigen Sie, dass Antwort und gerenderter Inhalt jetzt übereinstimmen.

Ihr Browser erhält 200, Googlebot aber nicht

Symptom: DevTools oder curl zeigt 200, während Google die URL nicht abrufen oder indexieren kann.

Wahrscheinliche Ursache: Ein CDN, eine WAF, eine Geo-Regel, eine Bot-Regel oder ein Experiment liefert Googlebot eine andere Antwort. Das Ergebnis Ihrer eigenen Anfrage belegt nicht, welche Antwort Googles Anfrage erhält.

Lösung: Vergleichen Sie eine normale Anfrage mit einer Anfrage mit Googlebot-User-Agent und prüfen Sie anschließend URL-Prüfung sowie Server-/CDN-Logs. Korrigieren Sie die Edge-Regel und bestätigen Sie, dass der Live-Test 200 mit demselben substanziellen Body erhält, den Nutzer erhalten.

Die Seite ist 200, wird aber trotzdem nicht indexiert

Symptom: Der Statuscode ist gesund, doch die URL bleibt aus dem Index ausgeschlossen.

Wahrscheinliche Ursache: 200 macht den Inhalt nur für die Verarbeitung geeignet. Ein noindex, ein Duplikat-/Canonical-Konflikt oder wenig wertvoller Inhalt kann ihn weiterhin aus dem Index halten.

Lösung: Ändern Sie nicht länger den Statuscode. Prüfen Sie Indexierungsdirektiven, das von Google ausgewählte Canonical und den tatsächlichen Inhalt. Eine erfolgreiche HTTP-Antwort ist kein Indexierungsurteil.

200-Antworten, die ein falsches Bild vermitteln

Dies sind vereinfachte Beispiele. Die Statuszeile meldet technisch einen Erfolg; der Body entscheidet jedoch, ob diese Meldung den tatsächlichen Seitenzustand wiedergibt.

Leere Produkthülle: irreführender 200-Status

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Product unavailable</h1>
<p>There is nothing here.</p>

Wenn das Produkt dauerhaft und ohne Ersatz verschwunden ist, geben Sie 404 oder 410 zurück. Wenn eine nützliche Produktseite bestehen bleibt — mit Spezifikationen, Alternativen, Support oder Verfügbarkeitsinformationen — kann 200 weiterhin angemessen sein, weil die Seite einen echten Zweck erfüllt.

Gelöschter Artikel mit Ersatz: eine Weiterleitung verwenden

HTTP/1.1 301 Moved Permanently
Location: https://example.com/current-guide

Eine Vorlage mit 200, die „Artikel gelöscht“ sagt, lässt Nutzer stranden und kann als Soft 404 eingestuft werden. Ein relevanter Ersatz sollte das Ziel einer serverseitigen 301 sein.

Interne Suche ohne Treffer: nützlich oder leer

Ein 200 kann ehrlich sein, wenn die Seite Nutzern hilft, die Suche neu zu formulieren, Kategorien zu durchsuchen oder Alternativen zu finden. Eine dünne Seite, die nur „0 Ergebnisse“ enthält, wirkt trotz des Erfolgsstatus wie ein Fehler. Der Unterschied ist die Nützlichkeit des Bodys, nicht die Zahl 200.

Verdächtige 200-Antworten triagieren

Fügen Sie einen Crawl-Export mit URL, Status, Titel, Canonical, Indexierbarkeit und einem kurzen Body-Textauszug ein. Dieser Prompt trennt HTTP-Erfolg von Inhalts- und Indexierungsproblemen.

You are auditing URLs that return HTTP 200. Review the pasted rows without assuming that
"200" means "indexed" or "healthy."

For each URL:
1. Classify it as a substantive page, likely soft 404, redirect-needed page, genuinely gone
   page, duplicate/canonical case, or needs manual review.
2. Cite the exact evidence from the supplied title, body sample, canonical, and directives.
3. Recommend one response: keep 200, restore content, 301 to a relevant replacement,
   return 404/410, or fix canonical/noindex signals.
4. Flag any conclusion that cannot be made from the supplied data.

Do not invent page content, redirect targets, or indexing status. End with a prioritized
manual-check list.

PASTE CRAWL ROWS HERE

Die Antwort prüfen, statt der Seite zu vertrauen

Eine Antwort mit curl untersuchen

Führen Sie diese Befehle unter macOS, Linux oder WSL aus. Der erste liest die Response-Header, der zweite lädt zusätzlich den Body herunter, damit Sie prüfen können, ob 200 echten Inhalt enthält.

curl -sI https://example.com/page
curl -sS -D - https://example.com/page -o page.html

Achten Sie auf eine 200-Statuszeile und öffnen Sie anschließend page.html. Header allein können einen Soft 404 nicht sichtbar machen.

Eine normale Anfrage mit einem Googlebot-User-Agent vergleichen

url="https://example.com/page"
curl -sS -o /dev/null -w "default: %{http_code} %{size_download} bytes\n" "$url"
curl -sS -A "Googlebot" -o /dev/null -w "Googlebot UA: %{http_code} %{size_download} bytes\n" "$url"

Ein Unterschied ist ein Grund, CDN-/WAF-Regeln und Logs zu untersuchen, aber kein Beweis dafür, dass Googlebot die Antwort der vorgetäuschten Anfrage erhalten hat. Bestätigen Sie den echten Abruf in der URL-Prüfung.

Eine Liste auf Nicht-200-Antworten prüfen

Schreiben Sie eine URL pro Zeile in urls.txt:

while IFS= read -r url; do
  curl -sS -o /dev/null -w "%{http_code}\t%{url_effective}\n" "$url"
done < urls.txt

Damit finden Sie offensichtliche Statusabweichungen. Ob ein 200-Body substanziell ist, lässt sich damit nicht beurteilen; prüfen Sie daher verdächtige Vorlagen und Soft-404-Berichte weiter.

Tools zur Validierung von 200-Antworten

Patricks kostenloses Tool

• Bulk HTTP Status Code Checker — fügen Sie bis zu 500 URLs ein, um Statuscodes, endgültige Ziele, Weiterleitungsketten und Latenz in einem Export zu sammeln. Finden Sie damit URLs, die nicht tatsächlich 200 zurückgeben; prüfen Sie anschließend Body und Search Console separat auf Soft 404s, da ein Statuscode-Prüfer weder Inhaltsqualität noch Indexierung beurteilen kann.

Suchmaschinen- und Serverbelege

• Google Search Console URL Inspection — vergleichen Sie das indexierte Ergebnis mit einem Live-Abruf und prüfen Sie den gerenderten Inhalt, den Google abrufen kann.
• Bing Webmaster Tools URL Inspection — prüfen Sie die Antwort, die Bingbot nach eigener Meldung erhalten hat.
• Server- und CDN-Logs — bestätigen Sie, welchen Statuscode echte Crawler-Anfragen erhalten haben; Logs sind stärkere Belege als das Ändern eines User-Agents in curl.
• Browser-DevTools-Network-Panel — überprüfen Sie Dokumentanfrage, Response-Header und Body der gerade verwendeten Browsersitzung.

Selbsttest: 200 OK

Fünf kurze Fragen dazu, was 200 für SEO bedeutet. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend.

Änderungsprotokoll