204 No Content: Bedeutung

TL;DR — Eine 204 No Content-Antwort bedeutet: „Ihre Anfrage war erfolgreich, und ich sende absichtlich eine leere Seite zurück.“ Sie ist ein Erfolgscode, kein Fehler. Das ist für Dinge wie das Speichern einer App im Hintergrund oder einen Analytics-Tracker völlig in Ordnung — aber falsch für eine echte Webseite, die in Google erscheinen soll. Ein leerer Body gibt Google nichts zu indexieren, daher behandelt Google einen 204 auf einer Seite wie einen Soft 404.

Was ein 204 tatsächlich ist

Jede Antwort Ihres Servers enthält einen Statuscode. Die 2xx-Codes bedeuten „Erfolg“. 200 OK — der Statuscode, den Sie auf Ihren Seiten wollen — bedeutet „hier ist die Seite“, einschließlich Body. 204 No Content bedeutet ebenfalls Erfolg, aber mit einer Besonderheit: Der Server sagt „Ich habe getan, worum Sie gebeten haben, und es gibt absichtlich nichts anzuzeigen.“ Evidence for this claim RFC 9110 defines 204 No Content as a successful response with no additional content to send and says it is terminated by the header section because it cannot contain content. Scope: HTTP semantics for 204 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.5 — 204 No Content

Das Schlüsselwort ist absichtlich. Ein 204 ist keine Seite, die beim Laden fehlgeschlagen ist, und keine URL, die nicht existiert — es ist eine Antwort, die bewusst leer gestaltet wurde. Stellen Sie sich vor, der Server nickt „erledigt“, ohne etwas zurückzugeben.

Warum das bei einer Webseite ein Problem ist

Google indexiert den Inhalt einer Seite. Gibt eine URL 204 zurück, gibt es keinen Inhalt zu lesen — der Body ist absichtlich leer. Googles eigene Dokumentation sagt es ausdrücklich: “wasn’t able to receive any content and therefore can’t process it.” (Übersetzung) „Google konnte keinen Inhalt empfangen und kann ihn daher nicht verarbeiten.“ Eine Seite, die ranken soll und 204 zurückgibt, liefert Google also nichts, womit es arbeiten kann; sie wird daher nicht indexiert — und in der Praxis kennzeichnet die Search Console solche Seiten häufig wie einen Soft 404: eine Seite, die technisch „erfolgreich“ war, aber keinen indexierbaren Inhalt besitzt.

Wenn also eine Seite, die ranken soll, beim Crawl oder in der Search Console als 204 erscheint, ist das ein zu behebender Fehler und nichts, das Sie so belassen sollten.

Wann ein 204 völlig in Ordnung ist

Die meisten 204-Antworten, die Sie jemals sehen werden, sind überhaupt keine Seiten:

• Apps speichern im Hintergrund. Sie klicken auf „Speichern“, und die App speichert Ihre Arbeit, ohne die Seite neu zu laden — der Server kann mit 204 antworten.
• Analytics und Tracking. Tracker senden winzige „Beacon“-Anfragen, um ein Ereignis zu erfassen. Es gibt keine Seite zurückzugeben, daher ist 204 genau richtig.
• App-Schnittstellen (APIs). Wenn ein System einem anderen sagt, dass etwas gelöscht werden soll, gibt es oft nichts zurückzusenden — 204 sagt „erledigt“.

Nichts davon muss in Google erscheinen, daher ist 204 dort die richtige Antwort und kein Fehler.

Die eine Regel, die Sie sich merken sollten

Geben Sie niemals 204 für eine URL zurück, die Menschen in der Suche finden sollen. Ist eine Seite dauerhaft verschwunden, verwenden Sie 404 oder 410. Wurde sie verschoben, leiten Sie die URL weiter (301). Sollte sie Inhalt haben, beheben Sie die Ursache, die eine leere Antwort ausliefert. Die ausführliche Version — Googles genaue Formulierung, die API- und Beacon-Anwendungsfälle sowie die Diagnose eines versehentlichen 204 — steht im Tab Fortgeschritten.

TL;DR — 204 ist ein spezifikationskonformer 2xx-Erfolgscode (RFC 9110 §15.3.5), der absichtlich einen leeren Body zurückgibt — der Body muss leer sein (auch kein Content-Length, nicht einmal 0), und Browser können einen 204 mit ausgeliefertem Inhalt ablehnen. Er ist kein Fehler und sagt nichts über die Existenz einer URL aus; die RFC beschränkt ihn nicht auf eine feste Liste von Methoden. Legitime Anwendungsfälle sind fast ausschließlich Nicht-Dokument-Antworten: REST-API-DELETE/PUT und Analytics-Beacons (sendBeacon(), GA4 Measurement Protocol) — wobei Praktiker uneinig sind, wie oft APIs darauf zurückgreifen sollten. Die SEO-Folge ist eng begrenzt: Googles Statuscode-Tabelle sagt ausdrücklich, dass Google bei 204 “Google wasn’t able to receive any content and therefore can’t process it” (Übersetzung) „Google konnte keinen Inhalt empfangen und kann ihn daher nicht verarbeiten“ — eine Seite, die ranken soll, wird durch diese Antwort also nicht indexiert; in der Praxis werden solche Seiten in der Search Console häufig als Soft 404 gekennzeichnet, wobei Google weder dieses konkrete Label noch einen Zeitplan für die Entfernung garantiert. Beheben Sie einen versehentlichen 204 auf Seitenebene, indem Sie wieder einen echten 200 liefern oder je nach Absicht 404/410/301 verwenden.

Was 204 laut Spezifikation bedeutet

RFC 9110 (HTTP Semantics) ist eindeutig: Ein 204 bedeutet, dass „der Server die Anfrage erfolgreich erfüllt hat und im Payload-Body der Antwort kein zusätzlicher Inhalt zu senden ist“. Es ist ein Erfolgscode — aus derselben 2xx-Familie wie 200 OK — mit dem bewussten Unterschied, dass es keinen Body gibt.

Drei operative Details sind wichtig. Erstens muss der Body wirklich leer sein: MDN weist darauf hin, dass ein 204 “must not include any content or the Content-Length header (browsers may reject responses that include content).” (Übersetzung) „Eine 204-Antwort darf weder Inhalt noch den Content-Length-Header enthalten; Browser können Antworten mit Inhalt ablehnen.“ Das ist ein echtes Verbot, keine lockere Konvention — RFC 9110 §8.6 untersagt Content-Length bei 204 vollständig, daher ist auch „senden Sie einfach Content-Length: 0“ (eine empfohlene Lösung, die ich gesehen habe) nicht konform; die Antwort endet vollständig am Header-Abschnitt. Zweitens beschreiben Header, die ein 204 trägt — etwa ETag oder Last-Modified — die ausgewählte Repräsentation nach Abschluss Ihrer Aktion, nicht einen gesendeten Body. Drittens erscheint ein ETag bei manchen 204-Antworten (MDNs Beispiel ist ein PUT, das eine Ressource an Ort und Stelle aktualisiert), aber die RFC verlangt ihn nicht für jeden 204 — betrachten Sie ihn nicht als selbstverständlich. Ein 204 ist standardmäßig heuristisch cachebar, sofern Methode oder ausdrückliche Cache-Control-Header nichts anderes bestimmen.

Entscheidend ist: 204 hat nichts damit zu tun, ob eine URL existiert. Ein funktionierender API-Endpunkt kann dauerhaft korrekt 204 zurückgeben. Das unterscheidet ihn von 404 (nicht gefunden) oder 410 (verschwunden) — diese Codes beschreiben Abwesenheit; 204 beschreibt eine erfolgreiche Anfrage, die absichtlich kein Payload trägt.

Wie Google einen 204 behandelt

Das ist die gesamte SEO-Geschichte, und sie ist enger, als es die Standardtexte von Anbieter-Blogs klingen lassen. Google indexiert Inhalt. Ein 204 hat keinen Inhalt. Googles eigene Dokumentation hebt 204 mit einer konkreten, begrenzten Aussage hervor: Während die allgemeine 2xx-Regel lautet, dass “Google considers the content for processing,” (Übersetzung) „Google den Inhalt zur Verarbeitung berücksichtigt“, steht in der eigenen 204-Zeile: “Google wasn’t able to receive any content and therefore can’t process it.” (Übersetzung) „Google konnte keinen Inhalt empfangen und kann ihn daher nicht verarbeiten.“

Das ist die tatsächliche Grenze; es lohnt sich, genau zu sein, was sie verspricht und was nicht. Die allgemeine 2xx-Information auf derselben Seite sagt, dass leerer oder fehlerähnlicher Inhalt möglicherweise als Soft 404 gemeldet wird — die 204-Zeile selbst garantiert jedoch nicht, dass jeder 204 unter genau diesem Label in der Search Console landet, und Google veröffentlicht dafür keinen Zeitplan. Sicher ist: Ein 204 auf einer Content-URL liefert Googles Indexierungspipeline nichts, womit sie arbeiten kann; daher ist die Aussage, dass die URL aufgrund dieser Antwort nicht indexiert wird, eine vernünftige Schlussfolgerung — keine Aussage, die ich zu „garantiertem Rankingverlust für die gesamte Website“ oder „automatischer Erholung des Crawl-Budgets“ ausweiten würde, weil Googles Dokumentation keines dieser Versprechen macht. In der Praxis zeigt die Search Console solche Fälle häufig als Soft 404 — dieses Muster habe ich beobachtet und beschrieben —, aber behandeln Sie Label und Zeitpunkt als beobachtetes Verhalten, nicht als dokumentierte Garantie.

Das ist die Position, die ich in meinen eigenen Texten vertrete. In meinem Leitfaden zu HTTP-Statuscodes und ihren SEO-Auswirkungen im Ahrefs-Blog schreibe ich unter der Behandlung von 2xx-Antworten durch Google direkt: “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 von Seiten erlauben. Solche Antworten werden jedoch als Soft 404 behandelt und nicht indexiert.“ Daran halte ich als praktische Lesart fest; die präzisere aktuelle Formulierung aus Googles eigener Dokumentation ist der Rahmen „kann keinen Inhalt empfangen oder verarbeiten“, auf den ich für die genaue offizielle Grenze verweisen würde.

Soft 404 werden laut Dokumentation weiterhin gecrawlt und verschwenden Crawl-Budget — das ist jedoch Googles allgemeine Soft-404-Hilfe, kein 204-spezifisches Versprechen. Die Verwendung von 204 gibt Crawl-Ressourcen nicht automatisch frei oder leitet sie um; Googles eigene Einschränkung lautet, dass die Ressourcenzuteilung von Serving-Limits, Websitequalität und Bestand abhängt, nicht davon, welcher Statuscode den Ausschluss ausgelöst hat. Die sichere Schlussfolgerung: Beheben Sie einen versehentlichen 204, weil dadurch eine Seite nicht indexiert wird — nicht, weil Ihnen dafür eine bestimmte Crawl-Budget-Dividende zusteht.

204 im Vergleich zu den Codes, mit denen er verwechselt wird

Die Falle ist, dass 204, leerer 200, 404 und 410 in der GSC alle als Soft 404 enden können, wenn kein nutzbarer Inhalt vorhanden ist — für einen spezifikationskonformen Client signalisieren sie jedoch sehr unterschiedliche Absichten. 410 ist das bewusste Signal „Das gab es und ist dauerhaft verschwunden“; 204 wurde nie für diese Bedeutung entwickelt und sollte überhaupt nicht auf Seiten-URLs stehen.

Wann 204 genau richtig ist (kein Fehler)

Fast jeder legitime 204 ist eine Nicht-Dokument-Antwort:

• REST-API DELETE / PUT. Wenn ein Client eine Ressource löscht oder an Ort und Stelle aktualisiert und nichts Sinnvolles zurückzugeben ist, ist 204 die idiomatische Antwort — es ist das von RFC 9110 selbst empfohlene Muster.
• Analytics- und Tracking-Beacons. Die W3C-Beacon-Spezifikation rund um navigator.sendBeacon() erwartet, dass Beacon-Endpunkte mit 204 antworten. Googles Measurement-Protocol-Endpunkt für Analytics 4 gibt für akzeptierte Treffer 204 zurück. Wichtig: GA4 gibt auch bei fehlerhaften oder ungültigen Payloads 204 zurück; ein 204 bestätigt dort daher nur, dass der Endpunkt erreichbar war und strukturell geantwortet hat — nicht, dass der Treffer tatsächlich verarbeitet wurde. Lesen Sie einen Beacon-204 nicht als Erfolgsbeweis.
• „Speichern, ohne wegzunavigieren“-UX. Ein PUT, das den Zustand an Ort und Stelle speichert und den Nutzer auf der aktuellen Seite lässt — MDNs eigene Formulierung lautet, dass ein 204 “the client doesn’t need to navigate away from its current page.” (Übersetzung) Der Client muss bei einem 204 nicht von seiner aktuellen Seite weg navigieren.

Der rote Faden: Diese URLs sollte niemand indexieren, daher ist 204 korrekt und erwartet. Das Problem ist nur ein 204 auf einer Dokument-URL, die ranken soll.

Eine verwandte Nuance: RFC 9110 beschränkt 204 nicht ausdrücklich auf DELETE/PUT/Beacons — das sind lediglich die häufigen Muster. Die Definition der Spezifikation ist methodenneutral; entscheidend sind der Vertrag der jeweiligen Methode und die Frage, ob die Rückgabe einer Repräsentation sinnvoll wäre. Das wirkt in beide Richtungen. Eine GET-Anfrage mit 204 ist protokollkonform — Praktiker diskutieren dies seit Jahren auf Stack Overflow —, aber bei einer indexierbaren Seite lautet die eigentliche Frage nicht „Ist 204 bei GET erlaubt?“, sondern „Muss diese URL Google eine Repräsentation liefern, damit sie auffindbar ist?“, und für eine Seite, die ranken soll, lautet die Antwort immer ja. Die SEO-Regel bezieht sich daher nicht auf die verwendete HTTP-Methode, sondern darauf, ob die URL überhaupt ein Dokument sein soll.

Außerdem ist „204 ist für API-Antworten immer richtig“ selbst unter API-Designern nicht allgemein anerkannt. Postmans eigener Text nennt 204 die Standardwahl für Aktionen ohne Rückgabewert; Brandur Leach hat die Gegenposition vertreten — eine leere Erfolgsantwort kann für API-Clients, die auch nach einem erfolgreichen Schreibvorgang eine Repräsentation erwarten (aktualisierter Zustand, generierte ID, berechnetes Feld), leicht schädlich sein. Das ist ein legitimer Zielkonflikt des API-Designs bei der Entwicklerergonomie, keine Frage der HTTP-Korrektheit — 204 bleibt in beiden Fällen spezifikationskonform — und ist von der SEO-Frage dieses Artikels getrennt. Eine Stelle, an der API-Texte manchmal ungenau werden: Content-Length: 0 bei 204 „zur Sicherheit“ zu senden. Tun Sie das nicht — RFC 9110 §8.6 verbietet Content-Length in einer 204-Antwort vollständig, nicht nur einen Wert ungleich null.

Einen versehentlichen 204 auf Seitenebene diagnostizieren und beheben

Wenn ein Crawler (Screaming Frog, Ahrefs Site Audit) oder Ihre Logs einen 204 für eine Seite zeigen, die Inhalt haben sollte:

1. Bestätigen Sie, was Googlebot tatsächlich erhält. Verwenden Sie die URL-Prüfung in der Search Console, um den Status und den gerenderten Inhalt zu sehen, den Google erhält — nicht nur das, was Ihr Browser sieht. Ein CDN, Edge-Worker, eine WAF oder eine App-Route kann Bots oder unter bestimmten Bedingungen 204 liefern, während für Sie alles richtig aussieht (dasselbe Muster wie „in meinem Browser sieht es gut aus“ bei einem versehentlichen 403).
2. Beheben Sie dann nach Absicht:
   • Die Seite soll mit Inhalt existieren → finden Sie die Server-/CDN-/App-Logik, die 204 ausgibt, und stellen Sie einen korrekten 200 mit echtem Body wieder her.
   • Die Seite ist ohne Ersatz verschwunden → geben Sie 404 oder 410 zurück.
   • Die Seite wurde verschoben → 301 auf die neue URL.
3. Überwachen Sie. Beobachten Sie den GSC-Bericht zur Seitenindexierung auf Soft-404-Einträge, behalten Sie Statuscodes in Ihren Logs im Blick und konfigurieren Sie Ihren Crawler so, dass er 204 markiert, damit ein versehentlicher Status auf einer Vorlage nicht unbemerkt einen ganzen Abschnitt deindexiert.

Das mentale Modell lautet: 204 ist nicht „schlecht“. Es ist ein präzises Werkzeug, das für API- und Beacon-Endpunkte richtig und für Dokumente falsch ist. Der Fehler besteht ausschließlich darin, es am falschen Ort zu verwenden. Verwandte Codes wie 403, 404, 410 und Soft 404 haben jeweils ihren eigenen Platz in dieser Entscheidung — der Platz von 204 ist außerhalb der Seite.

KI-Zusammenfassung

Eine verkürzte Zusammenfassung der Advanced-Version:

• 204 No Content ist ein 2xx-Erfolgscode (RFC 9110 §15.3.5), der absichtlich einen leeren Body zurückgibt. Er ist kein Fehler und sagt nichts darüber aus, ob eine URL existiert. Die RFC beschränkt ihn nicht auf eine feste Methodenliste — DELETE/PUT/Beacons sind häufige Muster, keine Voraussetzung, und 204 bei GET ist protokollkonform.
• Der Body muss ausnahmslos leer sein. Laut MDN darf ein 204 weder Inhalt noch einen Content-Length-Header enthalten — RFC 9110 §8.6 verbietet Content-Length vollständig, daher ist auch Content-Length: 0 nicht konform. Header, die ein 204 trägt, beschreiben die ausgewählte Repräsentation nach der Aktion, nicht einen übertragenen Body. Ein 204 ist standardmäßig heuristisch cachebar, aber ein ETag ist nicht bei jedem 204 garantiert — MDNs Beispiel enthält ihn für einen bestimmten PUT-Fall, nicht als allgemeine Regel.
• SEO-Folge (eng und genau begrenzt): Googles Statuscode-Dokumentation sagt ausdrücklich: “Google wasn’t able to receive any content and therefore can’t process it.” (Übersetzung) Google konnte keinen Inhalt empfangen und kann ihn daher nicht verarbeiten. Daraus folgt vernünftig, dass eine Seite, die ranken soll, aufgrund dieser Antwort nicht indexiert wird — aber Google garantiert weder ein bestimmtes Soft-404-Label für jeden 204 noch einen Zeitplan für die Entfernung; die Verwendung von 204 stellt Crawl-Budget nicht automatisch wieder her und beweist keinen Rankingeffekt. Patrick formuliert es in seinen eigenen Texten so: „204-Codes werden als Soft 404 behandelt und nicht indexiert“ — das praktische Muster, das er beobachtet hat, auch wenn die genaue offizielle Formulierung enger ist.
• Legitime Verwendungen sind überwiegend Nicht-Dokumente: REST-API-DELETE/PUT und Analytics-Beacons (sendBeacon(), GA4 Measurement Protocol). GA4 gibt auch bei fehlerhaften Treffern 204 zurück, daher beweist ein Beacon-204 nicht, dass der Treffer verarbeitet wurde. Auch hier besteht unter Praktikern keine vollständige Einigkeit — Postman behandelt 204 als Standard für Aktionen ohne Rückgabewert, während Brandur Leach argumentiert, dass ein leerer Erfolg für Clients, die eine Repräsentation erwarten, leicht schädlich sein kann; das ist eine API-Ergonomie-Debatte, keine Frage der HTTP-Korrektheit.
• 204 ist für eine rankbare Seite niemals richtig. Ohne Ersatz verschwunden → 404/410; verschoben → 301; sollte Inhalt haben → den Server/das CDN beheben, das 204 ausgibt, und einen echten 200 wiederherstellen. Bestätigen Sie über die URL-Prüfung, was Googlebot erhält.

Offizielle Dokumentation

Primärquellen dazu, was 204 ist und wie Google damit umgeht.

HTTP-Spezifikation und Browserreferenz

• RFC 9110 §15.3.5 — 204 No Content — die maßgebliche Definition: Erfolg, kein Payload-Body, keine Trailer, heuristische Cachebarkeit und Header, welche die ausgewählte Repräsentation nach der Aktion beschreiben.
• RFC 9110 §8.6 — Content-Length — die Regel, die Content-Length in einer 204-Antwort vollständig verbietet (nicht nur bei einem Wert ungleich null).
• MDN — 204 No Content — verständliche Einordnung, Einschränkungen bei leerem Body und Content-Length, Cachebarkeit, ein beispielbezogenes ETag sowie der Anwendungsfall „speichern, ohne wegzunavigieren“.

Google Search Central

• Wie HTTP-Statuscodes sowie Netzwerk- und DNS-Fehler die Google-Suche beeinflussen — die Statuscode-Tabelle, die 204 ausdrücklich nennt, und Googles Definition des Soft 404.

Beacons und Analytics (die legitimen 204-Fälle)

• W3C — Beacon — die Spezifikation für navigator.sendBeacon(), die 204 von Beacon-Endpunkten erwartet.
• Google Analytics 4 — Measurement-Protocol-Referenz — der GA4-Erfassungsendpunkt, dessen Antworten (einschließlich 204 für akzeptierte Treffer) hier dokumentiert sind.

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 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.” (Übersetzung) „Der Statuscode 204 (No Content) zeigt an, dass der Server die Anfrage erfolgreich erfüllt hat und im Payload-Body der Antwort kein zusätzlicher Inhalt zu senden ist.“ — RFC 9110, HTTP Semantics, §15.3.5. Abschnitt lesen

MDN Web Docs

• “The HTTP 204 No Content successful response status code indicates that a request has succeeded, but the client doesn’t need to navigate away from its current page. A 204 response is cacheable by default, and an ETag header is included in such cases.” (Übersetzung) „Der erfolgreiche HTTP-Statuscode 204 No Content zeigt an, dass eine Anfrage erfolgreich war, der Client aber nicht von seiner aktuellen Seite weg navigieren muss. Eine 204-Antwort ist standardmäßig cachebar, und in solchen Fällen ist ein ETag-Header enthalten.“ Zum Zitat springen

Google Search Central — 2xx-/204-Behandlung

• “Google wasn’t able to receive any content and therefore can’t process it.” (Übersetzung) „Google konnte keinen Inhalt empfangen und kann ihn daher nicht verarbeiten.“ — Googles Dokumentation zu HTTP-Statuscodes, die 204-Zeile der 2xx-Tabelle (im Gegensatz zur allgemeinen 2xx-Regel, nach der „Google den Inhalt zur Verarbeitung berücksichtigt“). Googles Statuscode-Dokumentation

Patrick Stox — Ahrefs

• “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. 204-Codes werden jedoch als Soft 404 behandelt und nicht indexiert.“ — aus meinem Leitfaden zu HTTP-Statuscodes und ihren SEO-Auswirkungen. Zum Zitat springen

Matt G. Southern — Search Engine Journal

• “The exception is a 204 status code, which means the page was successfully accessed but no content was found. Google may show a soft 404 in Search Console for pages serving a 204 code.” (Übersetzung) „Die Ausnahme ist ein 204-Statuscode. Das bedeutet, dass auf die Seite erfolgreich zugegriffen wurde, aber kein Inhalt gefunden wurde. Google kann in der Search Console für Seiten, die einen 204-Code liefern, einen Soft 404 anzeigen.“ Zum Zitat springen

Legitime 204-Antworten im Vergleich zu versehentlichen

Konkrete Fälle dafür, wo 204 hingehört — und wo er ein Fehler ist.

Richtig: REST-API DELETE

Ein Client löscht eine Ressource; es gibt nichts zurückzugeben.

DELETE /api/items/42 HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content

Kein Body, kein Content-Length. Das ist die idiomatische Antwort und sollte niemals eine URL sein, die in der Suche erscheinen soll.

Richtig: Analytics-Beacon (sendBeacon)

// Fires a fire-and-forget beacon on page unload
navigator.sendBeacon('/collect', payload);
// Endpoint responds:  HTTP/1.1 204 No Content

Der Endpunkt muss keine Seite ausliefern, daher ist 204 genau richtig. Dasselbe gilt für den Measurement-Protocol-Endpunkt von GA4 — denken Sie nur daran, dass GA4 auch bei fehlerhaften Treffern 204 zurückgibt. Ein 204 bestätigt also, dass der Endpunkt geantwortet hat, nicht dass Ihr Treffer verarbeitet wurde.

Falsch: Eine Inhaltsseite gibt 204 zurück

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content        ← bug: a real page must return 200 + body

Google erhält einen leeren Body, behandelt die URL wie einen Soft 404 und indexiert sie nicht. Die Lösung hängt von der Absicht ab:

• Soll die Seite mit Inhalt existieren → 200 OK mit echtem Body wiederherstellen (die Server-/CDN-/App-Route beheben, die 204 ausgibt).
• Ohne Ersatz verschwunden → 404 oder 410.
• Verschoben → 301 auf die neue URL.

Faustregel: Soll ein Mensch auf der URL landen und etwas lesen, muss sie 200 mit einem Body zurückgeben. Reservieren Sie 204 für maschinelle Endpunkte — APIs und Beacons —, bei denen wirklich nichts anzuzeigen ist.

Einen unerwarteten 204 diagnostizieren

Eine Seite ist leer und das Network-Panel zeigt 204

Symptom: Eine Dokument-URL, die Inhalt darstellen sollte, gibt 204 No Content zurück.

Wahrscheinliche Ursache: App-Routing, eine CDN-Regel, ein Edge-Worker oder ein Fehler-Handler gibt auf einer Seitenroute die API-typische Erfolgsantwort aus.

Lösung: Verfolgen Sie die Anfrage durch die Ebene, welche die Antwort verantwortet. Soll die Seite existieren, stellen Sie 200 mit echtem Body wieder her. Bestätigen Sie die Lösung mit einer neuen Header-Anfrage und einem Browser-Reload ohne Cache.

Die Search Console meldet Soft 404 für eine 204-URL

Symptom: Die URL ist als Soft 404 ausgeschlossen, obwohl 204 ein Erfolgscode ist.

Wahrscheinliche Ursache: Die Klassifizierung bezieht sich auf fehlenden Inhalt, nicht darauf, ob der Code mit 2 beginnt. Ein 204 hat definitionsgemäß keinen Body.

Lösung: Wählen Sie die Antwort nach der Absicht: 200 mit Inhalt für eine echte Seite, 301 für eine Verschiebung oder 404/410 für eine verschwundene Seite. Führen Sie die URL-Prüfung nach der Bereitstellung der Änderung erneut aus.

Browser und Crawler zeigen unterschiedliche Statuscodes

Symptom: Die Seite sieht im Browser normal aus, aber ein Crawler oder Log-Eintrag zeigt 204.

Wahrscheinliche Ursache: Bot-, Methoden-, Geo-, Cache-, WAF- oder Edge-Logik verändert die Antwort.

Lösung: Vergleichen Sie GET und HEAD, normale und Googlebot-User-Agent-Anfragen sowie die exakte Anfrage in Server-/CDN-Logs. Beheben Sie die bedingte Regel und prüfen Sie anschließend, dass beide Pfade dieselbe beabsichtigte Antwort liefern.

Eine Gruppe von 204-URLs nach Absicht klassifizieren

Fügen Sie einen Crawl- oder Log-Export ein, der URL, Request-Methode, Inhaltstyp, Referrer oder Routentyp und Antwortcode enthält.

Classify each HTTP 204 row I provide as:
- likely legitimate API response,
- likely legitimate beacon/background request,
- accidental document/page response, or
- insufficient evidence.

For every row, cite the supplied evidence, explain why 204 does or does not fit, and give
the next verification step. For accidental page responses, recommend exactly one intended
outcome: 200 with content, 301 to a relevant replacement, or 404/410 if gone.

Do not infer that a 204 analytics response means the event was processed. Do not invent
route behavior, redirect targets, or page content. Return a table followed by a prioritized
manual-check queue.

PASTE ROWS HERE

Versehentliche 204-Antworten finden

Eine URL und Request-Methode untersuchen

curl -sS -D - -o /dev/null https://example.com/page
curl -sS -X HEAD -D - -o /dev/null https://example.com/page

Die Dokumentanfrage sollte nicht 204 sein, wenn die URL Inhalt darstellen soll. Testen Sie GET und HEAD, da fehlerhafte methodenspezifische Handler unterschiedliche Antworten liefern können.

Standardantwort und Googlebot-User-Agent-Antwort 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 204 mit null heruntergeladenen Bytes nur auf einem Pfad deutet auf bedingte Server-, CDN- oder WAF-Logik hin. Verwenden Sie echte Logs und die URL-Prüfung, um zu bestätigen, was Google tatsächlich erhalten hat.

204-Antworten aus einer URL-Liste melden

while IFS= read -r url; do
  code=$(curl -sS -o /dev/null -w "%{http_code}" "$url")
  if [ "$code" = "204" ]; then printf '%s\t%s\n' "$code" "$url"; fi
done < urls.txt

Führen Sie dies unter macOS, Linux oder WSL aus; in urls.txt steht eine URL pro Zeile. Prüfen Sie jedes Ergebnis nach Routenzweck — 204 bei APIs und Beacons ist kein Fehler.

Tools zum Trennen legitimer und versehentlicher 204-Antworten

Patricks kostenloses Tool

• Bulk HTTP Status Code Checker — prüfen Sie bis zu 500 URLs, filtern Sie die Ergebnisse auf 204 und exportieren Sie die betroffene Menge. Verwenden Sie Routen- und Inhaltskontext, um gültige API-/Beacon-Endpunkte von Seiten-URLs zu trennen, die Inhalt zurückgeben sollten.

Die Ursache bestätigen

• Google Search Console URL Inspection — testen Sie eine Seiten-URL live, um zu sehen, was Google nach der Änderung der Antwort abrufen kann.
• Server-/CDN-Logs — erkennen Sie, ob 204 nach Methode, User-Agent, Route oder Edge-Standort variiert.
• Browser-DevTools-Network-Panel — unterscheiden Sie die Dokumentanfrage von Hintergrund-API- und Beacon-Aufrufen; 204 bei einem Beacon kann korrekt sein, 204 beim Dokument jedoch nicht.
• Ein vollständiger Website-Crawler — erfassen Sie Dokument-URLs mit 204 und nehmen Sie die Prüfung in wiederkehrende Audits auf, damit eine Regression in einer Vorlage nicht einen ganzen Abschnitt betrifft.

Selbsttest: 204 No Content

Fünf kurze Fragen dazu, was 204 bedeutet und wann der Statuscode richtig ist. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend.

Änderungsprotokoll