Kod 204 No Content

TL;DR — Odpowiedź 204 No Content oznacza: „Twoje żądanie się udało, a ja celowo odsyłam pustą stronę”. To kod powodzenia, nie błąd. Jest całkowicie właściwy dla takich rzeczy jak aplikacja zapisująca pracę w tle albo tracker analityczny — ale nie pasuje do prawdziwej strony internetowej, którą chcesz mieć w Google. Puste ciało nie daje Google nic do zindeksowania, więc 204 na stronie jest traktowane jak soft 404.

Czym naprawdę jest 204

Każda odpowiedź wysyłana przez serwer ma kod statusu. Kody 2xx oznaczają „powodzenie”. 200 OK — ten, którego chcesz na swoich stronach — oznacza „oto strona”, razem z całym ciałem. 204 No Content też oznacza powodzenie, ale z ważnym dodatkiem: serwer mówi „zrobiłem to, o co prosiłeś, i celowo nie ma czego Ci pokazać”. 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

Kluczowe słowo to celowo. 204 nie oznacza strony, której nie udało się załadować, ani URL-a, który nie istnieje — to odpowiedź zaprojektowana jako pusta. Pomyśl o niej jak o serwerze przytakującym „gotowe”, ale nieoddającym niczego w zamian.

Dlaczego to problem w przypadku strony internetowej

Google indeksuje treść strony. Jeśli URL zwraca 204, nie ma czego czytać — ciało jest puste z założenia. Własna dokumentacja Google mówi to wprost: “wasn’t able to receive any content and therefore can’t process it.” (tłumaczenie) „nie udało się odebrać żadnej treści, dlatego nie można jej przetworzyć.” Strona, która ma zdobywać pozycje i zwraca 204, nie daje Google niczego do przeanalizowania, co oznacza, że nie zostanie zindeksowana — a w praktyce Search Console często oznacza takie przypadki tak samo jak soft 404: strona technicznie „zakończyła się powodzeniem”, ale nie ma treści wartej indeksowania.

Jeśli więc strona, którą chcesz pozycjonować, pojawia się jako 204 w crawl albo w Search Console, to błąd do naprawienia, a nie coś, co należy pozostawić.

Kiedy 204 jest całkowicie właściwy

Większość napotykanych kodów 204 w ogóle nie dotyczy stron:

• Aplikacje zapisujące w tle. Naciskasz „zapisz”, a aplikacja przechowuje pracę bez przeładowywania strony — serwer może odpowiedzieć 204.
• Analityka i śledzenie. Trackery wysyłają małe żądania typu „beacon”, aby zapisać, że coś się wydarzyło. Nie ma strony do zwrócenia, więc 204 jest dokładnie właściwy.
• Interfejsy aplikacji (API). Gdy jeden system mówi drugiemu, aby coś usunął, często nie ma nic do odesłania — 204 mówi „gotowe”.

Żaden z tych przypadków nie musi trafić do Google, więc 204 jest tam poprawną odpowiedzią, a nie błędem.

Jedna zasada do zapamiętania

Nigdy nie zwracaj 204 dla URL-a, który chcesz, aby ludzie znajdowali w wyszukiwarce. Jeśli strona zniknęła na dobre, użyj 404 albo 410. Jeśli została przeniesiona, przekieruj ją (301). Jeśli powinna zawierać treść, napraw wszystko, co wysyła pustą odpowiedź. Chcesz poznać dokładne sformułowanie Google, przypadki użycia API i beaconów oraz sposób diagnozowania przypadkowego 204? Przejdź do karty Advanced.

TL;DR — 204 jest zgodnym ze specyfikacją kodem powodzenia 2xx (RFC 9110 §15.3.5), który z założenia zwraca puste ciało — ciało musi być puste (bez Content-Length, nawet 0), a przeglądarki mogą odrzucić 204, które wysyła treść. Nie jest błędem i nic nie mówi o istnieniu URL-a, a RFC nie ogranicza go do żadnej stałej listy metod. Prawidłowe użycia to niemal wyłącznie odpowiedzi inne niż dokumenty: REST API DELETE/PUT oraz beacony analityczne (sendBeacon(), Measurement Protocol GA4) — choć praktycy nie zgadzają się, jak często API powinno po niego sięgać. Konsekwencja SEO jest wąska: tabela kodów statusu Google mówi wprost: “Google wasn’t able to receive any content and therefore can’t process it.” (tłumaczenie) „Google nie mogło odebrać żadnej treści, dlatego nie może jej przetworzyć” — co oznacza, że strona, która ma zdobywać pozycje, nie zostanie zindeksowana na podstawie tej odpowiedzi; w praktyce takie przypadki są często oznaczane w Search Console jako soft 404, choć Google nie gwarantuje tej konkretnej etykiety ani terminu usunięcia. Napraw przypadkowe 204 na poziomie strony, przywracając prawdziwe 200 albo używając 404/410/301 zgodnie z intencją.

Co oznacza 204 w specyfikacji

RFC 9110 (HTTP Semantics) nie pozostawia tu wątpliwości: 204 oznacza, że “the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.” (tłumaczenie) „serwer pomyślnie zrealizował żądanie i nie ma dodatkowej treści do wysłania w ciele ładunku odpowiedzi.” To kod powodzenia — z tej samej rodziny 2xx co 200 OK — z celową różnicą: nie ma ciała.

Liczą się trzy szczegóły operacyjne. Po pierwsze, ciało rzeczywiście musi być puste: MDN zauważa, że 204 “must not include any content or the Content-Length header (browsers may reject responses that include content).” (tłumaczenie) „nie może zawierać żadnej treści ani nagłówka Content-Length (przeglądarki mogą odrzucać odpowiedzi zawierające treść)”. To prawdziwy zakaz, a nie luźna konwencja — RFC 9110 §8.6 całkowicie zabrania Content-Length w 204, więc „wyślij po prostu Content-Length: 0” (poprawka, którą widywałem w zaleceniach) również nie jest zgodna ze specyfikacją; odpowiedź kończy się na sekcji nagłówków, kropka. Po drugie, wszelkie nagłówki niesione przez 204 — ETag, Last-Modified — opisują wybraną reprezentację po zakończeniu działania, a nie wysłane ciało. Po trzecie, ETag pojawia się w niektórych odpowiedziach 204 (przykład MDN to PUT aktualizujący zasób w miejscu), ale RFC nie wymaga go w każdym 204 — nie traktuj go jako oczywistości. 204 jest domyślnie heurystycznie buforowalne, chyba że metoda albo jawne nagłówki cache-control mówią inaczej.

Co najważniejsze, 204 nie ma nic wspólnego z tym, czy URL istnieje. Działający endpoint API może poprawnie zwracać 204 bez końca. To różnica względem 404 (nie znaleziono) albo 410 (zniknęło) — te kody dotyczą braku, a 204 pomyślnego żądania, które celowo nie niesie ładunku.

Jak Google traktuje 204

Cała historia SEO jest tu węższa, niż sugeruje standardowy tekst blogów dostawców. Google indeksuje treść. 204 nie ma treści. Własna dokumentacja Google wyróżnia 204 konkretnym, ograniczonym stwierdzeniem: ogólna reguła 2xx mówi, że „Google rozważa treść do przetworzenia”, natomiast osobny wiersz 204 mówi: “Google wasn’t able to receive any content and therefore can’t process it.” (tłumaczenie) „Google nie mogło odebrać żadnej treści, dlatego nie może jej przetworzyć.”

To rzeczywista granica i warto precyzyjnie opisać, co obiecuje, a czego nie. Ogólne wskazówki 2xx na tej samej stronie mówią, że pusta albo przypominająca błąd treść może zostać zgłoszona jako soft 404 — ale sam wiersz 204 nie gwarantuje, że każdy 204 trafi pod tę konkretną etykietę Search Console, a Google nie publikuje dla niego terminu usunięcia. Pewne jest to, że 204 na URL-u z treścią daje potokowi indeksowania Google nic, z czym mógłby pracować, więc stwierdzenie, że URL nie zostanie zindeksowany na podstawie tej odpowiedzi, jest rozsądnym wnioskiem — nie twierdzeniem, które rozszerzałbym na „gwarantowaną utratę pozycji w całej witrynie” albo „automatyczne odzyskanie budżetu crawl”, bo dokumentacja Google nie składa żadnej z tych obietnic. W praktyce Search Console często pokazuje to jako soft 404 — to wzorzec, który widziałem i opisywałem — ale konkretną etykietę i czas traktuj jako obserwowane zachowanie, a nie udokumentowaną gwarancję.

Takie stanowisko zajmowałem we własnych tekstach. W moim przewodniku Kody statusu HTTP i ich wpływ na SEO na blogu Ahrefs, w części o obsłudze odpowiedzi 2xx przez Google, napisałem to wprost: “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (tłumaczenie) „Większość kodów 2xx pozwoli na indeksowanie stron. Jednak kody 204 będą traktowane jako soft 404 i nie zostaną zindeksowane.” Podtrzymuję to jako praktyczne odczytanie; dokładniejsze, aktualne sformułowanie z dokumentacji Google to opis „nie można odebrać ani przetworzyć treści” powyżej — na nie wskazałbym, gdy potrzebujesz dokładnej oficjalnej granicy.

Soft 404 są opisane jako przypadki, które nadal są crawlowne i marnują budżet crawl — ale to ogólna wskazówka Google dotycząca soft 404, a nie obietnica specyficzna dla 204. Użycie 204 nie zwalnia automatycznie zasobów crawl ani nie przekierowuje ich gdzie indziej; własne zastrzeżenie Google mówi, że przydział zasobów zależy od limitów obsługi, jakości witryny i jej zasobów, a nie od kodu statusu, który spowodował wykluczenie. Bezpieczny wniosek: napraw przypadkowy 204, bo uniemożliwia indeksowanie strony, a nie dlatego, że należy Ci się konkretna dywidenda z budżetu crawl.

204 a kody, z którymi jest mylony

Pułapka polega na tym, że 204, puste 200, 404 i 410 mogą wszystkie skończyć jako „soft 404” w GSC, gdy brakuje użytecznej treści — ale dla klienta zgodnego ze specyfikacją sygnalizują zupełnie różne intencje. 410 jest celowym komunikatem „to istniało i zniknęło na stałe”; 204 nigdy nie został zaprojektowany do tego znaczenia i nie powinien znajdować się na URL-ach stron.

Kiedy 204 jest dokładnie właściwy (a nie błędem)

Niemal każda prawidłowa odpowiedź 204 nie jest odpowiedzią dokumentową:

• REST API DELETE / PUT. Gdy klient usuwa zasób albo aktualizuje go w miejscu i nie ma nic sensownego do zwrócenia, 204 jest idiomatyczną odpowiedzią — to własny zalecany wzorzec RFC 9110.
• Beacony analityczne i śledzące. Specyfikacja W3C Beacon, oparta na navigator.sendBeacon(), oczekuje od endpointów beaconów odpowiedzi 204. Endpoint Measurement Protocol Google Analytics 4 zwraca 204 dla zaakceptowanych zdarzeń. Warto zaznaczyć: GA4 zwraca 204 nawet dla zniekształconych albo nieprawidłowych ładunków, więc 204 potwierdza tylko, że endpoint był osiągalny i odpowiedział strukturalnie — nie że zdarzenie faktycznie przetworzono. Nie traktuj 204 beacona jako dowodu powodzenia.
• UX „zapisz bez nawigowania”. PUT, który zapisuje stan w miejscu i zostawia użytkownika na bieżącej stronie — własne ujęcie MDN mówi, że przy 204 “the client doesn’t need to navigate away from its current page.” (tłumaczenie) „klient nie musi opuszczać bieżącej strony”.

Wspólny wniosek: to nie są URL-e, które ktokolwiek powinien indeksować, więc 204 jest poprawny i oczekiwany. Problemem jest wyłącznie 204 na URL-u dokumentu, który ma zdobywać pozycje.

Warto też pamiętać o niuansie: RFC 9110 nie ogranicza 204 konkretnie do DELETE/PUT/beaconów — to tylko częste wzorce. Definicja specyfikacji jest neutralna względem metody; liczy się kontrakt samej metody oraz to, czy zwrócenie reprezentacji byłoby użyteczne. To działa w obie strony. Żądanie GET zwracające 204 jest dozwolone protokołowo — praktycy od lat roztrząsają to na Stack Overflow — ale prawdziwe pytanie w przypadku indeksowalnej strony nie brzmi „czy 204 dla GET jest dozwolone”, tylko „czy ten URL musi przekazać Google reprezentację, aby dało się go znaleźć”, a dla strony, którą chcesz pozycjonować, odpowiedź zawsze brzmi: tak. Reguła SEO nie dotyczy więc użytej metody HTTP; dotyczy tego, czy URL ma być dokumentem.

Warto też wiedzieć, że twierdzenie „204 jest zawsze właściwe dla odpowiedzi API” nie ma powszechnej zgody nawet wśród projektantów API. Własny tekst Postmana wskazuje 204 jako pierwszy wybór dla działań, które nie mają nic do zwrócenia; Brandur Leach przedstawiał przeciwne stanowisko — pusta odpowiedź powodzenia może być nieco szkodliwa dla klientów API oczekujących reprezentacji z powrotem (zaktualizowanego stanu, wygenerowanego ID, obliczonego pola), nawet po udanym zapisie. To uzasadniony kompromis w projektowaniu API dotyczący wygody deweloperów, a nie kwestia poprawności HTTP — 204 pozostaje zgodny ze specyfikacją w obu wariantach — i jest niezależny od pytania SEO tego artykułu. W tekstach o API czasem pojawia się jeszcze jeden błąd: wysyłanie Content-Length: 0 w 204 „dla bezpieczeństwa”. Nie rób tego — RFC 9110 §8.6 całkowicie zabrania Content-Length w odpowiedzi 204, nie tylko wartości niezerowej.

Diagnozowanie i naprawa przypadkowego 204 na poziomie strony

Jeśli crawler (Screaming Frog, Ahrefs Site Audit) albo logi pokazują 204 na stronie, która powinna zawierać treść:

1. Potwierdź, co faktycznie otrzymuje Googlebot. Użyj URL Inspection w Search Console, aby zobaczyć status i wyrenderowaną treść otrzymywaną przez Google — nie tylko to, co widzi Twoja przeglądarka. CDN, worker brzegowy, WAF albo trasa aplikacji mogą zwracać botom 204 lub robić to w określonych warunkach, choć dla Ciebie wszystko wygląda dobrze (ten sam wzorzec „u mnie w przeglądarce działa” co przy przypadkowym 403).
2. Następnie napraw zgodnie z intencją:
   • Strona powinna istnieć i zawierać treść → znajdź logikę serwera/CDN-u/trasy aplikacji wysyłającą 204 i przywróć prawidłowe 200 z rzeczywistym ciałem.
   • Strona zniknęła bez zamiennika → zwróć 404 albo 410.
   • Strona została przeniesiona → 301 na nowy URL.
3. Monitoruj. Obserwuj raport Page Indexing w GSC pod kątem wpisów soft 404, śledź kody statusu crawl w logach i skonfiguruj crawler, aby zgłaszał 204, tak aby przypadkowy kod na szablonie nie zdeindeksował po cichu całej sekcji.

Zapamiętaj taki model mentalny: 204 nie jest „zły”. To precyzyjne narzędzie, właściwe dla endpointów API i beaconów, a błędne dla dokumentów. Problem pojawia się wyłącznie wtedy, gdy używasz go w złym miejscu. Kody pokrewne, takie jak 403, 404, 410 i soft 404, mają własne miejsce w tej decyzji — miejsce 204 jest poza stroną.

Podsumowanie AI

Skrócona wersja wariantu Advanced:

• 204 No Content to kod powodzenia 2xx (RFC 9110 §15.3.5), który z założenia zwraca puste ciało. Nie jest błędem i nic nie mówi o istnieniu URL-a. RFC nie ogranicza go do stałej listy metod — DELETE/PUT/beacony to częste wzorce, a nie wymóg; 204 dla GET jest zgodne z protokołem.
• Ciało musi być puste, bez wyjątków. Według MDN 204 nie może zawierać treści ani nagłówka Content-Length — a RFC 9110 §8.6 zabrania Content-Length całkowicie, więc Content-Length: 0 również nie jest zgodne ze specyfikacją. Wszelkie nagłówki niesione przez 204 opisują wybraną reprezentację po działaniu, a nie przesłane ciało. 204 jest domyślnie heurystycznie buforowalne, ale ETag nie jest gwarantowany w każdej odpowiedzi 204 — przykład MDN pokazuje go w konkretnym przypadku PUT, nie jako regułę uniwersalną.
• Konsekwencja SEO (wąska i precyzyjnie ograniczona): dokumentacja Google o kodach statusu mówi wprost: “Google wasn’t able to receive any content and therefore can’t process it.” (tłumaczenie) „Google nie mogło odebrać żadnej treści, dlatego nie może jej przetworzyć.” To uzasadnia rozsądny wniosek — strona, która ma zdobywać pozycje, nie zostanie zindeksowana na podstawie tej odpowiedzi — ale Google nie gwarantuje konkretnej etykiety soft 404 ani terminu usunięcia dla każdego 204, a użycie 204 nie odzyskuje automatycznie budżetu crawl ani nie dowodzi wpływu na pozycje. Jak pisze Patrick: “204s will be treated as soft 404s and won’t be indexed” (tłumaczenie) „Kody 204 będą traktowane jako soft 404 i nie zostaną zindeksowane.” — to obserwowany przez niego wzorzec praktyczny, choć dokładne oficjalne sformułowanie jest węższe.
• Prawidłowe użycia dotyczą głównie nie-dokumentów: REST API DELETE/PUT oraz beacony analityczne (sendBeacon(), Measurement Protocol GA4). GA4 zwraca 204 nawet dla błędnych zdarzeń, więc 204 beacona nie dowodzi, że zdarzenie zostało przetworzone. Praktycy nie są tu całkowicie zgodni — Postman traktuje 204 jako domyślną odpowiedź działań bez treści, a Brandur Leach twierdzi, że puste powodzenie może być nieco szkodliwe dla klientów oczekujących reprezentacji; to spór o ergonomię API, nie poprawność HTTP.
• 204 nigdy nie jest właściwy dla strony mogącej zdobywać pozycje. Zniknięta bez zamiennika → 404/410; przeniesiona → 301; powinna zawierać treść → napraw serwer/CDN wysyłający 204 i przywróć rzeczywiste 200. Potwierdź, co otrzymuje Googlebot, przez URL Inspection.

Dokumentacja oficjalna

Materiały źródłowe dotyczące znaczenia 204 i obsługi tego kodu przez Google.

Specyfikacja HTTP i dokumentacja przeglądarki

• RFC 9110 §15.3.5 — 204 No Content — autorytatywna definicja: powodzenie, brak ciała ładunku, brak przyczep, heurystyczna możliwość buforowania oraz nagłówki opisujące wybraną reprezentację po działaniu.
• RFC 9110 §8.6 — Content-Length — reguła całkowicie zabraniająca Content-Length w odpowiedzi 204 (nie tylko wtedy, gdy wartość jest niezerowa).
• MDN — 204 No Content — omówienie prostym językiem, ograniczenie pustego ciała i Content-Length, buforowanie, ETag w konkretnym przykładzie oraz przypadek użycia „zapisz bez nawigowania”.

Google Search Central

• Jak kody statusu HTTP oraz błędy sieci i DNS wpływają na wyszukiwarkę Google — tabela kodów statusu, która wymienia 204 z nazwy, oraz definicja soft 404 Google.

Beacony i analityka (prawidłowe przypadki 204)

• W3C — Beacon — specyfikacja navigator.sendBeacon(), która oczekuje odpowiedzi 204 od endpointów beaconów.
• Google Analytics 4 — dokumentacja Measurement Protocol — endpoint zbierania GA4, którego odpowiedzi (w tym 204 dla zaakceptowanych zdarzeń) są opisane tutaj.

Cytaty ze źródła

Wypowiedzi zapisane w źródłach. Każdy link prowadzi bezpośrednio do miejsca z cytowanym fragmentem na stronie źródłowej.

Specyfikacja HTTP

• “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.” (tłumaczenie) „Kod statusu 204 (No Content) oznacza, że serwer pomyślnie zrealizował żądanie i nie ma dodatkowej treści do wysłania w ciele ładunku odpowiedzi.” — RFC 9110, HTTP Semantics, §15.3.5. Przeczytaj sekcję

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.” (tłumaczenie) „Kod pomyślnej odpowiedzi HTTP 204 No Content oznacza, że żądanie zakończyło się powodzeniem, ale klient nie musi opuszczać bieżącej strony. Odpowiedź 204 jest domyślnie buforowalna, a w takich przypadkach zawiera nagłówek ETag.” Przejdź do cytatu

Google Search Central — obsługa 2xx / 204

• “Google wasn’t able to receive any content and therefore can’t process it.” (tłumaczenie) „Google nie mogło odebrać żadnej treści, dlatego nie może jej przetworzyć.” — dokument Google o kodach statusu HTTP, wiersz 204 tabeli 2xx (w odróżnieniu od ogólnej reguły 2xx, zgodnie z którą „Google rozważa treść do przetworzenia”). Dokument Google o kodach statusu

Patrick Stox — Ahrefs

• “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (tłumaczenie) „Strony z większością odpowiedzi 2xx mogą zostać zindeksowane. Odpowiedzi 204 Google uzna jednak za soft 404 i wykluczy z indeksu.” — z mojego przewodnika Kody statusu HTTP i ich wpływ na SEO. Przejdź do cytatu

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.” (tłumaczenie) „Wyjątkiem jest kod statusu 204, który oznacza, że strona została pomyślnie otwarta, ale nie znaleziono treści. Google może pokazać soft 404 w Search Console dla stron zwracających kod 204.” Przejdź do cytatu

Prawidłowe i przypadkowe odpowiedzi 204

Konkretne przypadki pokazujące, gdzie 204 pasuje — i gdzie jest błędem.

Prawidłowo: REST API DELETE

Klient usuwa zasób; nie ma nic do zwrócenia.

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

HTTP/1.1 204 No Content

Brak ciała, brak Content-Length. To idiomatyczna odpowiedź i nigdy nie powinien to być URL, którego oczekujesz w wyszukiwarce.

Prawidłowo: beacon analityczny (sendBeacon)

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

Endpoint nie ma strony do obsłużenia, więc 204 jest dokładnie właściwy. To samo dotyczy endpointu Measurement Protocol GA4 — pamiętaj tylko, że GA4 zwraca 204 nawet dla nieprawidłowych zdarzeń, więc 204 potwierdza odpowiedź endpointu, a nie przetworzenie zdarzenia.

Błędnie: strona z treścią zwracająca 204

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 otrzymuje puste ciało, traktuje URL jak soft 404 i nie zindeksuje go. Poprawka zależy od intencji:

• Powinna istnieć i zawierać treść → przywróć 200 OK z rzeczywistym ciałem (napraw serwer/CDN/trasę aplikacji wysyłającą 204).
• Zniknęła bez zamiennika → 404 albo 410.
• Została przeniesiona → 301 na nowy URL.

Zasada praktyczna: jeśli człowiek ma trafić na URL i coś przeczytać, URL musi zwracać 200 z ciałem. Zarezerwuj 204 dla endpointów komunikacji maszynowej — API i beaconów — gdzie naprawdę nie ma nic do pokazania.

Diagnozowanie nieoczekiwanego 204

Strona jest pusta, a panel Network pokazuje 204

Objaw: URL dokumentu, który powinien wyrenderować treść, zwraca 204 No Content.

Prawdopodobna przyczyna: routing aplikacji, reguła CDN-u, worker brzegowy albo handler błędów emituje odpowiedź powodzenia w stylu API na trasie strony.

Poprawka: Prześledź żądanie przez warstwę zarządzającą odpowiedzią. Jeśli strona powinna istnieć, przywróć 200 z rzeczywistym ciałem. Potwierdź poprawkę świeżym żądaniem nagłówków i przeładowaniem przeglądarki przy wyłączonej pamięci podręcznej.

Search Console zgłasza soft 404 dla URL-a 204

Objaw: URL jest wykluczony jako soft 404, mimo że 204 jest kodem powodzenia.

Prawdopodobna przyczyna: Klasyfikacja dotyczy braku treści, a nie tego, czy kod zaczyna się od 2. 204 z definicji nie ma ciała.

Poprawka: Wybierz odpowiedź według intencji: 200 z treścią dla prawdziwej strony, 301 przy przeniesieniu albo 404/410 dla strony, która zniknęła. Po wdrożeniu zmiany ponownie uruchom URL Inspection.

Twoja przeglądarka i crawler nie zgadzają się co do statusu

Objaw: Strona wygląda normalnie w przeglądarce, ale crawler albo wpis w logu pokazuje 204.

Prawdopodobna przyczyna: Bot, metoda, geografia, pamięć podręczna, WAF albo logika brzegowa zmieniają odpowiedź.

Poprawka: Porównaj GET i HEAD, zwykłe żądania z żądaniami używającymi user-agenta Googlebota oraz dokładne żądanie w logach serwera/CDN-u. Popraw regułę warunkową, a następnie sprawdź, czy obie ścieżki zwracają tę samą zamierzoną odpowiedź.

Klasyfikowanie zestawu URL-i 204 według intencji

Wklej eksport crawl albo logów zawierający URL, metodę żądania, typ treści, referrer albo typ trasy oraz kod odpowiedzi.

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

Znajdowanie przypadkowych odpowiedzi 204

Sprawdź pojedynczy URL i metodę żądania

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

Żądanie dokumentu nie powinno być 204, jeśli URL ma renderować treść. Przetestuj GET i HEAD, ponieważ błędne handlery zależne od metody mogą zwracać różne odpowiedzi.

Porównaj domyślną odpowiedź z odpowiedzią dla user-agenta Googlebota

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"

204 z zerową liczbą pobranych bajtów tylko na jednej ścieżce wskazuje na warunkową logikę serwera, CDN-u albo WAF-u. Użyj prawdziwych logów i URL Inspection, aby potwierdzić, co faktycznie otrzymał Google.

Zgłaszaj 204 z listy URL-i

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

Uruchom to w macOS, Linuksie albo WSL, podając po jednym URL-u w każdym wierszu pliku urls.txt. Sprawdź każdy wynik według intencji trasy; 204 dla API i beaconów nie jest błędem.

Narzędzia do rozdzielania prawidłowych i przypadkowych odpowiedzi 204

Bezpłatne narzędzie Patricka

• Bulk HTTP Status Code Checker — sprawdź do 500 URL-i, odfiltruj wyniki do 204 i wyeksportuj zestaw. Użyj kontekstu trasy i treści, aby oddzielić prawidłowe endpointy API/beaconów od URL-i stron, które powinny zwracać treść.

Potwierdź przyczynę

• Google Search Console URL Inspection — wykonaj test na żywo URL-a strony, aby zobaczyć, co Google może pobrać po zmianie odpowiedzi.
• Logi serwera/CDN-u — ustal, czy 204 zmienia się zależnie od metody, user-agenta, trasy albo lokalizacji brzegu.
• Panel Network w DevTools przeglądarki — odróżnij żądanie dokumentu od wywołań API i beaconów w tle; 204 dla beacona może być poprawne, ale 204 dla dokumentu nie.
• Crawler całej witryny — zinwentaryzuj URL-e dokumentów zwracające 204 i utrzymuj to sprawdzenie w cyklicznych audytach, aby regresja szablonu nie wpłynęła na całą sekcję.

Sprawdź się: 204 No Content

Pięć krótkich pytań o znaczenie 204 i sytuacje, w których jest właściwy. Wybierz odpowiedź przy każdym, a potem sprawdź wynik.

Dziennik zmian