Kod 200 OK

TL;DR — Odpowiedź 200 OK to komunikat serwera: „oto strona, o którą prosisz, wszystko jest w porządku”. To cichy kod powodzenia, którego chcesz na każdej stronie, którą chciałbyś pokazać w Google. Sam kod 200 nie gwarantuje jednak zindeksowania strony — Google nadal sprawdza, czy treść zasługuje na indeksowanie. A 200 na stronie, która jest faktycznie zepsuta albo pusta, to błąd, nie zielone światło.

Co oznacza 200 OK

Za każdym razem, gdy Twoja przeglądarka albo Googlebot prosi serwer o stronę, serwer odpowiada trzycyfrowym kodem statusu, zanim wyśle cokolwiek więcej. 200 OK to kod „wszystko dobrze” — serwer znalazł to, o co prosisz, i zwraca wynik, zwykle wraz z treścią strony. (Technicznie specyfikacja dopuszcza w pewnych przypadkach 200 z pustym ciałem, ale strona, którą chcesz udostępniać ludziom, powinna zawsze mieć rzeczywiste ciało). To kod, którego prawie nigdy nie zauważasz, bo oznacza, że nic nie poszło źle. 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 podsumowuje go trzema słowami w przewodniku Ahrefs po kodach statusu HTTP: “200 OK – All good. Everything is successful.” (tłumaczenie) „Kod 200 OK: wszystko dobrze. Wszystko się udało.”

Dla stron w Twojej witrynie, które mają być znajdowane w wyszukiwarce, 200 jest dokładnie tym kodem, który powinny zwracać.

Dlaczego 200 to nie cała historia

Oto część pomijana przez większość stron odpowiadających na pytanie „co oznacza 200”: 200 sprawia, że Twoja strona jest rozważana do indeksowania, ale nie gwarantuje jej wejścia do indeksu. To dwie zupełnie różne rzeczy.

Potraktuj 200 jak bilet, który pozwala wejść do środka. Gdy już wejdziesz, Google nadal decyduje, czy warto zachować treść — czy jest wysokiej jakości, czy jest niemal duplikatem innej strony, czy jest cienka albo pusta, czy zawiera tag noindex, który mówi Google, żeby nie wchodził? Każda z tych rzeczy może sprawić, że całkowicie zdrowa strona 200 nadal nie zostanie zindeksowana.

Jeśli więc strona zwraca 200, ale nie pojawia się w Google, problemem nie jest kod statusu — problemem jest treść albo konfiguracja.

Pułapka: 200, które naprawdę oznacza „nie znaleziono”

Najbardziej podstępny błąd to strona zwracająca 200, której treść mówi „to nie istnieje”. Produkt wyprzedany z pustą stroną, usunięty artykuł, który nadal ładuje pusty szablon, albo strona wyników wyszukiwania z zerową liczbą wyników — serwer wysyła radosne 200, ale w środku nie ma nic rzeczywistego.

Google zagląda poza kod do rzeczywistej treści, uznaje stronę za pustą albo błędną i oznacza ją jako soft 404 w Search Console — traktując ją tak samo jak prawdziwą stronę „nie znaleziono”. Jest to szeroko opisane w artykule o błędach soft 404; krótko mówiąc: jeśli strona rzeczywiście zniknęła, powinna zwracać 404 albo 410, a nie 200.

Jedna zasada do zapamiętania

Strona, którą chcesz mieć w Google, powinna zwracać 200 z rzeczywistą treścią. Jeśli strona zniknęła, użyj 404 albo 410. Jeśli została przeniesiona, przekieruj ją (301). Jeśli jest duplikatem innej strony, użyj tagu canonical. Chcesz poznać dokładne sformułowanie Google, różnicę między 200 i 204 oraz sposób sprawdzenia, co faktycznie otrzymał Googlebot? Przejdź do karty Advanced.

TL;DR — 200 OK to standardowy kod powodzenia 2xx (RFC 9110 §15.3.1): serwer zrealizował żądanie, a dla GET/HEAD ciało jest reprezentacją zasobu. Domyślnie podlega heurystycznemu buforowaniu. Dla SEO jest konieczny, ale niewystarczający — dokumentacja Google mówi: “may index the content, but that’s not guaranteed,” (tłumaczenie) „może zindeksować treść, ale nie jest to gwarantowane”, więc jakość, duplikacja, cienka treść i noindex nadal decydują o wyniku niezależnie od 200. Klasyczny błąd to soft 404: 200 opakowane wokół błędnej lub pustej treści, które Google wykrywa na poziomie treści i zgłasza jako soft 404 niezależnie od kodu. 200 (ciało oczekiwane) różni się od 204 (puste ciało, na stronach traktowane jak soft 404) i 304 (sygnał buforowania, nie decyzja o indeksowaniu). Potwierdź też, co dostał Googlebot — cloaking, blokowanie botów, reguły geograficzne oraz konfiguracja CDN/WAF mogą podać mu inny kod niż Twojej przeglądarce.

Co oznacza 200 w specyfikacji

RFC 9110 (HTTP Semantics) jest aktualnym źródłem prawdy, a §15.3.1 mówi wprost: “The 200 (OK) status code indicates that the request has succeeded.” (tłumaczenie) „Kod statusu 200 (OK) oznacza, że żądanie zakończyło się powodzeniem.” Zawartość ciała zależy od metody żądania. Dla metod istotnych w przypadku stron — GET i HEAD — treść jest reprezentacją docelowego zasobu. RFC dodaje zastrzeżenie: poza odpowiedziami na CONNECT od 200 oczekuje się treści, chyba że sposób opakowania komunikatu wyraźnie sygnalizuje długość zero — dlatego „200 zawsze ma ciało” to skrót myślowy, a nie absolutna reguła. W praktyce dla strony, którą chcesz zindeksować, celem jest prawdziwe ciało, nie puste. 200 jest też domyślnie „heurystycznie buforowalne”, chyba że dyrektywa cache-control mówi inaczej, dlatego nagłówki walidatorów, takie jak ETag i Last-Modified, mają znaczenie na stronach często ponownie crawlownych. 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

Mówiąc ściśle, 200 nie dotyczy wyłącznie stron. RFC opisuje, co oznacza „powodzenie” dla każdej metody:

W przypadku metod innych niż GET często nie zobaczysz 200 — MDN zauważa, że udane żądania PUT lub DELETE “often do not result in a 200 OK response,” (tłumaczenie) „często nie skutkują odpowiedzią 200 OK”, a częstsze są 201 Created lub 204 No Content. Żadna z tych kwestii nie ma znaczenia dla SEO adresów stron; najważniejsza zasada jest taka, że dla dokumentu, który chcesz zindeksować, celem jest 200 z rzeczywistym ciałem.

Konieczny, ale niewystarczający do indeksowania

To najważniejsza rzecz do poprawnego zrozumienia i obszar, w którym większość konkurencyjnych stron słownikowych mówi po prostu nieprawdę. Twierdzą, że „200 oznacza, iż strona zostanie zindeksowana”. Własna dokumentacja Google mówi inaczej. Dla odpowiedzi 200 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.” (tłumaczenie) „przekazuje wszystko, co otrzymał, do następnego etapu przetwarzania… W wyszukiwarce Google kolejnym systemem jest potok indeksowania. Systemy indeksowania mogą zindeksować treść, ale nie jest to gwarantowane.” 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

200 jest więc umową dotyczącą odpowiedzi HTTP, a nie obietnicą dotyczącą losu strony w wyszukiwarce. Po odpowiedzi 200 Google niezależnie ocenia:

• Jakość — strony cienkie, niskowartościowe albo automatycznie wygenerowane mogą nie zostać zindeksowane.
• Duplikację — niemal duplikat silniejszego URL-a może zostać połączony z tym URL-em, zamiast być zindeksowany samodzielnie (właśnie to kontroluje tag canonical).
• Dyrektywy — noindex w tagu meta albo nagłówku X-Robots-Tag wyklucza stronę, nawet przy idealnym 200.

Przewodnik Patricka w Ahrefs wyznacza tę samą granicę na poziomie całej rodziny kodów: “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 tej rodziny pozwala na indeksowanie. Jednak odpowiedzi bez treści są traktowane jako błąd braku strony i nie zostaną zindeksowane.” 200 sprawia, że strona jest uprawniona do indeksowania; nie sprawia, że jest zindeksowana.

Pułapka soft 404

Najostrzejszą ilustracją tego, że „200 to nie cała historia”, jest soft 404. Dokumentacja Google o kodach statusu opisuje mechanizm wprost: “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (tłumaczenie) „Jeśli treść sugeruje błąd w wyszukiwarce Google, pustą stronę albo komunikat błędu, Search Console pokaże błąd oznaczający brak strony.” Zwróć uwagę, co to oznacza — klasyfikacja opiera się na wyrenderowanej treści, a nie na kodzie HTTP. Potok indeksowania Google zagląda poza 200 do tego, co rzeczywiście znajduje się na stronie, i jeśli odczytuje to jako „nie znaleziono”, przypisuje stronę do tej samej kategorii i raportuje ją jak prawdziwe 404.

Przypadki do sprawdzenia intuicją: wycofany produkt, którego strona ładuje teraz pusty szablon; usunięty artykuł, który nadal zwraca powłokę 200; filtrowana strona kategorii albo wynik wyszukiwania z zerową liczbą elementów i komunikatem „nic tu nie ma”. Każdy zwraca technicznie poprawne 200, jednocześnie mówiąc użytkownikom i Google, że nie ma tu nic do zobaczenia.

Ta witryna ma osobny artykuł o błędach soft 404, opisujący mechanikę wykrywania i poprawki — nie będę ich tu powtarzać. Wniosek dla dyskusji o 200 jest prosty: zwracanie 200 na stronie, która naprawdę zniknęła, tworzy warunki dla soft 404. Poprawka polega na dopasowaniu kodu do rzeczywistości.

Powiązana pułapka: powodzenie transportu nie oznacza powodzenia aplikacji

Warto krótko o tym wspomnieć, bo temat pojawia się w kręgach API i monitoringu: warstwa HTTP i warstwa aplikacji mogą się nie zgadzać. Endpoint API może wysłać 200 z obiektem błędu JSON w ciele; strona może wysłać 200, gdy zależność backendu po cichu zawiodła i zamiast prawdziwej treści wyrenderowała uszkodzony blok. Linia statusu mówi „dostarczono poprawnie” — i tylko to twierdzi. To, czy ładunek jest rzeczywiście poprawny, to osobne pytanie, na które kod statusu nie odpowiada. Praktycy naprawdę różnią się w poglądach, czy API powinno sygnalizować błąd statusem innym niż 200, czy statusem 200 opakowującym ładunek błędu; to kontrakt wybierany przez każdy zespół, a nie reguła HTTP. Dla SEO tej witryny odpowiednikiem na poziomie strony jest opisany wyżej soft 404 — zasada jest ta sama: nie ufaj samej linii statusu, sprawdź, co faktycznie zawiera ciało.

200 a 204 i 304 — nie myl ich

Trzy kody, które ludzie mylą, choć tylko jeden jest sukcesem typu „oto Twoja strona”:

204 jest prawdziwym kodem powodzenia, ale jego puste ciało nie daje crawlerowi nic do zindeksowania — na URL-u strony trafia więc do kategorii soft 404 (to osobny artykuł; nie myl przypadku pustego ciała z normalnym 200). 304 nie należy nawet do tej samej rodziny — odpowiada na żądanie warunkowe (If-None-Match / If-Modified-Since), informując klienta, że jego kopia z pamięci podręcznej nadal jest aktualna. Nie zawiera ciała i nic nie mówi o tym, czy indeksować; jest mechanizmem wydajności crawl, a nie duplikatem 200. Częste pytanie „200 a 304 — czy to nie to samo?” myli optymalizację buforowania z odpowiedzią powodzenia.

Potwierdź, co faktycznie widzi Googlebot

Oto luka pomijana przez niemal każdy konkurencyjny artykuł: różni żądający mogą otrzymać różne kody dla tego samego URL-a. Twoja przeglądarka może zobaczyć czyste 200, a Googlebot coś innego — czasem celowo (cloaking, będący naruszeniem Search Essentials Google), częściej przypadkowo z powodu reguł WAF/blokowania botów, targetowania po adresie geo-IP, logiki brzegu CDN albo konfiguracji testu A/B, która nie działa poprawnie dla botów.

„200 w mojej przeglądarce” nie jest więc dowodem, że „Google widzi 200”. Właściwa diagnostyka polega na sprawdzeniu, co otrzymał sam Googlebot:

• GSC URL Inspection — uruchom Live Test, aby zobaczyć status i wyrenderowaną treść pobraną przez Google, a nie to, co widzi Twój komputer.
• Logi serwera / CDN-u — źródło prawdy o tym, jaki kod faktycznie otrzymał każdy user-agent.

Zwykłe curl -I z terminala jest przydatne, ale to tylko kolejny żądający, który może trafić na inne reguły brzegowe niż Googlebot — traktuj je jako punkt danych, a nie ostateczne słowo.

Jak sprawdzać i monitorować odpowiedzi 200s

• DevTools przeglądarki — karta Network, przeładuj stronę, kliknij żądanie dokumentu i odczytaj kolumnę Status.
• Wiersz poleceń — curl -I https://example.com/page dla nagłówków pojedynczego żądania, curl -IL, aby śledzić łańcuch przekierowań.
• Google Search Console — URL Inspection pokazuje zcrawlowany status i umożliwia Live Test.
• Bing Webmaster Tools — jego narzędzie URL Inspection służy po stronie Bing do potwierdzenia, co otrzymał Bingbot. (Bing nie publikuje osobnej dokumentacji „jak kody statusu wpływają na indeksowanie”, tak jak Google — wolę powiedzieć to wprost, niż wymyślać stanowisko Bing.)
• Crawlery — Screaming Frog i Ahrefs Site Audit zbiorczo pokazują kody statusu w całej witrynie; bezpłatny Ahrefs SEO Toolbar pokazuje kod bieżącej strony.

Zdrowy stan wygląda tak: ważne, kanoniczne URL-e konsekwentnie zwracają 200 z rzeczywistą treścią, a strony, które powinny zniknąć albo zostać przeniesione, zwracają 404/410 lub 301 zamiast mylącego 200.

Decyzja w jednym wierszu

Dopasuj kod do rzeczywistości. Chcesz mieć w indeksie → 200 z obszerną, wartościową treścią. Zniknęła na dobre → 404 albo 410 (zobacz 404-not-found). Przeniesiona → 301. Duplikat innego URL-a → wskaż tag canonical na preferowaną wersję, zamiast próbować wymuszać kod inny niż 200. 200 jest zielonym światłem dla stron, które rzeczywiście na nie zasługują — niczym więcej i niczym mniej.

Podsumowanie AI

Skrócona wersja wariantu Advanced:

• 200 OK to standardowy kod powodzenia 2xx (RFC 9110 §15.3.1): serwer zrealizował żądanie, a dla GET/HEAD ciało reprezentuje zasób. Domyślnie podlega heurystycznemu buforowaniu. RFC opisuje ciało jako oczekiwane, ale nie absolutnie wymagane — 200 o długości zero jest technicznie prawidłowe, choć strona, którą chcesz zindeksować, potrzebuje prawdziwego ciała.
• Konieczny, ale niewystarczający do indeksowania. Własna dokumentacja Google mówi, że systemy indeksowania “may index the content, but that’s not guaranteed.” (tłumaczenie) „systemy indeksowania mogą zindeksować treść, ale nie jest to gwarantowane”. Jakość, duplikacja, cienka treść i noindex są oceniane dodatkowo po 200. Większość konkurencyjnych stron myli się, pisząc „200 = zindeksowano”.
• Pułapka soft 404: 200 opakowane wokół błędnej/pustej treści jest wykrywane na poziomie treści i zgłaszane w Search Console jako soft 404 — „jeśli treść sugeruje błąd… Search Console pokaże błąd soft 404”. 200 na stronie, która rzeczywiście zniknęła, tworzy warunki dla tego błędu. Zobacz artykuł o soft-404-errors.
• Równoległa pułapka: warstwa HTTP i warstwa aplikacji mogą się nie zgadzać — 200 może opakowywać ładunek błędu API albo po cichu uszkodzony blok backendu. Linia statusu twierdzi tylko, że transport się udał, a nie że ładunek jest poprawny.
• 200 a 204 i 304: 200 = sukces z rzeczywistym ciałem (uprawniony do indeksowania); 204 = sukces z pustym ciałem, traktowany jak soft 404 na URL-ach stron (zobacz 204-no-content); 304 = sygnał buforowania odpowiadający na żądanie warunkowe, a nie decyzja o indeksowaniu.
• Potwierdź, co otrzymał Googlebot. Różni żądający mogą widzieć różne kody jednego URL-a z powodu cloakingu, blokowania botów, reguł geograficznych albo konfiguracji CDN/WAF. „200 w mojej przeglądarce” ≠ „Google widzi 200”. Sprawdź to przez Live Test w GSC URL Inspection albo logi serwera, nie tylko w przeglądarce czy curl.
• Dopasuj kod do rzeczywistości: potrzebne → 200 z prawdziwą treścią; zniknięte → 404/410; przeniesione → 301; zduplikowane → tag canonical. Jak mówi Patrick, “200 OK – All good. Everything is successful” (tłumaczenie) „Kod 200 OK oznacza, że wszystko przebiegło pomyślnie.” — dla strony, która rzeczywiście zasługuje na obecność.

Dokumentacja oficjalna

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

Specyfikacja HTTP i dokumentacja przeglądarki

• RFC 9110 §15.3.1 — 200 OK — autorytatywna definicja: żądanie zakończone powodzeniem, semantyka ciała zależna od metody i heurystyczna możliwość buforowania.
• MDN — 200 OK — omówienie prostym językiem, domyślna możliwość buforowania oraz uwaga o PUT/DELETE (częstsze są 201/204).

Google Search Central

• Jak kody statusu HTTP oraz błędy sieci i DNS wpływają na wyszukiwarkę Google — sformułowanie dotyczące obsługi 2xx („może zindeksować treść, ale nie jest to gwarantowane”) i odsyłacz do soft 404.
• Błędy soft 404 — raport indeksowania stron — własna definicja Google sytuacji, gdy 200 jest w rzeczywistości błędem, oraz wyjaśnienie, dlaczego zwracanie kodu powodzenia dla usuniętej strony jest złą praktyką.
• Cloaking — dlaczego URL może podawać użytkownikom i Googlebotowi różny kod/treść oraz dlaczego manipulacyjne działanie tego typu narusza zasady.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — sposób po stronie Bing na potwierdzenie odpowiedzi HTTP otrzymanej przez Bingbota. (Nie istnieje dokument autorstwa Bing opisujący, jak kody statusu wpływają na indeksowanie.)

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 200 (OK) status code indicates that the request has succeeded.” (tłumaczenie) „Kod statusu 200 (OK) oznacza, że żądanie zakończyło się powodzeniem.” — RFC 9110, HTTP Semantics, §15.3.1. Przeczytaj sekcję

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.” (tłumaczenie) „Kod odpowiedzi HTTP 200 OK oznacza powodzenie żądania. Odpowiedź 200 OK jest domyślnie buforowalna.” Przejdź do cytatu

Google Search Central — obsługa 2xx / 200

• “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.” (tłumaczenie) „Google przekazuje wszystko, co otrzymał, do następnego etapu przetwarzania (zależnego od produktu). W wyszukiwarce Google kolejnym systemem jest potok indeksowania. Systemy indeksowania mogą zindeksować treść, ale nie jest to gwarantowane.” — dokument Google o kodach statusu HTTP, wpis dotyczący 200. Dokument Google o kodach statusu

• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (tłumaczenie) „Jeśli treść sugeruje błąd w wyszukiwarce Google, pustą stronę albo komunikat błędu, Search Console pokaże błąd soft 404.” — ten sam dokument, odsyłacz dotyczący soft 404. Dokument Google o kodach statusu

Patrick Stox — Ahrefs

• “200 OK – All good. Everything is successful.” (tłumaczenie) „200 OK — wszystko przebiegło pomyślnie.” — z mojego przewodnika po kodach statusu HTTP na blogu Ahrefs. Przejdź do cytatu

• “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (tłumaczenie) „Zasadniczo strony z tej grupy mogą być indeksowane. Wyjątek stanowią odpowiedzi bez zawartości: wyszukiwarka potraktuje je jak brak strony i pominie w indeksie.” — z tego samego przewodnika, w części o obsłudze rodziny 2xx przez Google. Przejdź do cytatu

200 OK — szybka ściąga

Co to jest

200 a mylone z nim kody

Jaki kod powinien zwracać ten URL?

• Chcesz mieć go w indeksie → 200 z rzeczywistą, wartościową treścią.
• Zniknął na dobre → 404 albo 410 (zobacz 404-not-found).
• Przeniesiony pod nowy URL → 301.
• Duplikat innego URL-a → zachowaj 200 i dodaj tag canonical do preferowanej wersji.
• Celowo pusty (API/beacon) → 204 (zobacz 204-no-content) — nigdy na stronie.

Najważniejsze fakty

• 200 sprawia, że strona jest uprawniona do indeksowania, ale nie zindeksowana — Google osobno decyduje na podstawie jakości, duplikacji, cienkiej treści i noindex.
• 200 na stronie, która faktycznie zniknęła albo jest pusta, jest w oczach Google soft 404.
• Różni żądający mogą zobaczyć różne kody jednego URL-a — potwierdź, co otrzymał Googlebot, przez GSC URL Inspection albo logi serwera, a nie tylko przez przeglądarkę czy curl.
• Sprawdzaj kody za pomocą: karty Network w DevTools, curl -I / curl -IL, GSC/Bing URL Inspection, Screaming Frog oraz Ahrefs Site Audit/Toolbar.

Popularne mity o 200 OK

„Kod statusu 200 oznacza, że strona jest zindeksowana.” Fałsz. 200 oznacza, że serwer pomyślnie zwrócił treść; indeksowanie jest osobną decyzją na dalszym etapie. Własna dokumentacja Google mówi, że systemy indeksowania “may index the content, but that’s not guaranteed.” (tłumaczenie) „mogą zindeksować treść, ale nie jest to gwarantowane.” Jakość, duplikacja, cienka treść i noindex są oceniane dodatkowo po 200.

„Jeśli Search Console pokazuje soft 404, mój serwer ma błąd.” Niekoniecznie. Soft 404 nie jest kodem wysyłanym przez serwer — to etykieta nakładana przez Google na podstawie niezgodności między statusem 200 a treścią, która wygląda jak błąd albo pusta strona. Serwer robi dokładnie to, do czego został skonfigurowany (wysyła 200); problemem jest treść, a nie nagłówek.

„200 zawsze oznacza dobrze, kropka.” Nie zawsze. 200 na URL-u, który powinien zwrócić 404 — usunięty produkt, wygasłe ogłoszenie, pusta strona wyników wyszukiwania — jest aktywnie złym rozwiązaniem. Zachęca do obsługi jako soft 404 i może marnować crawl na ponowne odwiedzanie URL-a bez żadnej wartości.

„Moja przeglądarka pokazuje 200, więc Google na pewno też widzi 200.” Nie ma gwarancji. Blokowanie botów, cloaking, reguły geo-IP i konfiguracja CDN/WAF mogą podać Googlebotowi inną odpowiedź niż ludzkiej przeglądarce. Zweryfikuj to przez URL Inspection albo logi serwera.

„200 i 204 są zasadniczo tym samym — oba oznaczają powodzenie.” Oba należą do 2xx, ale 204 ma z założenia puste ciało. To dobre dla API i beaconów, a złe dla strony, którą chcesz zindeksować — 204 na URL-u strony jest traktowane jak soft 404 (zobacz 204-no-content).

„200 a 304 — czy to nie ta sama idea?” Nie. 304 Not Modified to mechanizm buforowania odpowiadający na żądanie warunkowe (If-None-Match / If-Modified-Since) i mówiący klientowi, aby użył kopii z pamięci podręcznej. Nie zawiera ciała i nie jest decyzją o indeksowaniu — to inna koncepcja niż 200.

Dlaczego strona 200 OK nadal może nie działać

Search Console oznacza URL jako soft 404

Objaw: URL zwraca 200, ale Page Indexing zgłasza go jako soft 404.

Prawdopodobna przyczyna: Ciało odpowiedzi wygląda na puste, zepsute albo przypomina stronę błędu. Typowe przypadki to wycofany produkt bez użytecznych informacji, usunięty artykuł w kompletnym skądinąd szablonie albo strona wyszukiwania bez wyników.

Poprawka: Dopasuj odpowiedź do rzeczywistości. Przywróć wartościową treść, jeśli strona powinna istnieć; zwróć 404 albo 410, jeśli zniknęła; użyj 301, jeśli została przeniesiona. Ponownie uruchom Live Test w URL Inspection i potwierdź, że odpowiedź oraz wyrenderowana treść są teraz zgodne.

Twoja przeglądarka dostaje 200, ale Googlebot nie

Objaw: DevTools albo curl pokazuje 200, a Google nie może pobrać ani zindeksować URL-a.

Prawdopodobna przyczyna: CDN, WAF, reguła geo, reguła botów albo eksperyment podaje Googlebotowi inną odpowiedź. Twoje własne żądanie nie jest dowodem tego, jakie żądanie wykonał Google.

Poprawka: Porównaj zwykłe żądanie z żądaniem używającym user-agenta Googlebota, a następnie sprawdź URL Inspection i logi serwera/CDN-u. Popraw regułę brzegową i potwierdź w Live Test, że odpowiedź ma 200 oraz to samo wartościowe ciało, które otrzymują użytkownicy.

Strona ma 200, ale nadal nie jest zindeksowana

Objaw: Kod statusu jest prawidłowy, ale URL pozostaje wykluczony z indeksu.

Prawdopodobna przyczyna: 200 sprawia tylko, że treść kwalifikuje się do przetwarzania. noindex, konflikt duplikatu/canonical albo treść niskiej wartości nadal mogą ją wykluczyć.

Poprawka: Przestań zmieniać kod statusu. Sprawdź dyrektywy indeksowania, canonical wybrany przez Google oraz rzeczywistą treść. Pomyślna odpowiedź HTTP nie jest werdyktem indeksowania.

Odpowiedzi 200, które opowiadają niewłaściwą historię

To uproszczone przykłady. Linia statusu jest technicznie poprawna, ale ciało określa, czy to powodzenie jest uczciwe.

Pusta powłoka produktu: mylące 200

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

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

Jeśli produkt zniknął na stałe i nie ma zamiennika, zwróć 404 albo 410. Jeśli pozostała użyteczna strona produktu — specyfikacje, alternatywy, pomoc albo informacje o dostępności — 200 może nadal być właściwy, ponieważ strona ma rzeczywisty cel.

Usunięty artykuł z zamiennikiem: użyj przekierowania

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

Szablonowa strona 200 z komunikatem „artykuł usunięty” zostawia użytkowników bez wyjścia i zachęca do klasyfikacji soft 404. Odpowiednim miejscem docelowym powinien być zamiennik wskazany przez serwerowe 301.

Wewnętrzne wyszukiwanie bez wyników: użyteczne czy puste

200 może być uczciwe, gdy strona pomaga użytkownikom przeformułować wyszukiwanie, przeglądać kategorie albo znaleźć alternatywy. Cienka strona zawierająca tylko „0 wyników” wygląda jak błąd mimo kodu powodzenia. O różnicy decyduje użyteczność ciała, a nie liczba 200.

Sortowanie podejrzanych odpowiedzi 200

Wklej eksport crawl z URL-em, statusem, tytułem, canonicalem, możliwością indeksowania i krótką próbką tekstu ciała. Ten prompt oddziela powodzenie HTTP od problemów z treścią i indeksowaniem.

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

Sprawdzaj odpowiedź zamiast ufać stronie

Sprawdź pojedynczą odpowiedź za pomocą curl

Uruchom te polecenia w macOS, Linuksie albo WSL. Pierwsze odczytuje nagłówki odpowiedzi; drugie pobiera również ciało, aby można było potwierdzić, że 200 zawiera rzeczywistą treść.

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

Poszukaj linii statusu 200, a następnie otwórz page.html. Same nagłówki nie ujawnią soft 404.

Porównaj zwykłe żądanie z user-agentem 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"

Różnica jest powodem do sprawdzenia reguł CDN/WAF i logów, a nie dowodem, że sam Googlebot otrzymał odpowiedź ze sfałszowanego żądania. Potwierdź rzeczywiste pobranie w URL Inspection.

Sprawdź listę odpowiedzi innych niż 200

Umieść po jednym URL-u w każdym wierszu pliku urls.txt:

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

To znajduje oczywiste niezgodności statusu. Nie ocenia, czy ciało 200 zawiera wartościową treść, więc podejrzane szablony i zgłoszenia soft 404 trzeba sprawdzić dodatkowo.

Narzędzia do walidacji odpowiedzi 200

Bezpłatne narzędzie Patricka

• Bulk HTTP Status Code Checker — wklej do 500 URL-i, aby zebrać kody statusu, końcowe miejsca docelowe, łańcuchy przekierowań i opóźnienie w jednym eksporcie. Użyj go do znalezienia URL-i, które w rzeczywistości nie zwracają 200; następnie osobno sprawdź ciało i Search Console pod kątem błędów typu „nie znaleziono”, ponieważ narzędzie sprawdzające status nie ocenia jakości treści ani indeksowania.

Dowody z wyszukiwarek i serwera

• Google Search Console URL Inspection — porównaj wynik z indeksu z aktywnym pobraniem i przejrzyj wyrenderowaną treść, którą może pobrać Google.
• Bing Webmaster Tools URL Inspection — sprawdź odpowiedź, którą Bingbot zgłasza jako otrzymaną.
• Logi serwera i CDN-u — potwierdź, jaki kod statusu otrzymały rzeczywiste żądania crawlerów; logi są mocniejszym dowodem niż zmiana user-agenta w curl.
• Panel Network w DevTools przeglądarki — zweryfikuj żądanie dokumentu, nagłówki odpowiedzi i ciało w bieżącej sesji przeglądarki.

Sprawdź się: 200 OK

Pięć krótkich pytań o znaczenie 200 dla SEO. Wybierz odpowiedź przy każdym, a potem sprawdź wynik.

Dziennik zmian