Kody błędów HTTP

TL;DR — Kody błędów HTTP to odpowiedzi „coś poszło nie tak”, które Twój serwer wysyła zamiast normalnego „200 OK”. Występują w dwóch rodzinach: 4xx (strona nie istnieje lub jest zablokowana — problem klienta) i 5xx (sam serwer ma problemy). Google traktuje je bardzo różnie: 4xx po prostu usuwa stronę z wyników wyszukiwania; 5xx powoduje, że Google spowalnia indeksowanie całej Twojej witryny, dopóki serwer nie wróci do normy. I mimo paniki, jaką wywołują, błędy 404 nie są karą — musisz naprawić tylko te, które mają znaczenie.

Czym są kody błędów HTTP

Kody statusu HTTP to standaryzowane metadane odpowiedzi pogrupowane w klasy błędów klienta 4xx i błędów serwera 5xx. Dowód potwierdzający to twierdzenie Primary standard or official documentation supporting the adjacent article claim. Zakres: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 RFC 9110: Status codes Google dokumentuje odmienne traktowanie tych rodzin odpowiedzi podczas indeksowania i przeszukiwania. Dowód potwierdzający to twierdzenie Primary standard or official documentation supporting the adjacent article claim. Zakres: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google: HTTP and network errors

Za każdym razem, gdy przeglądarka lub bot wyszukiwarki żąda strony, Twój serwer odpowiada trzycyfrowym kodem statusu. 200 oznacza „oto strona, wszystko w porządku”. Kody błędów to te z zakresu 400 i 500 — oznaczają, że żądanie nie powiodło się.

Istnieją dwie rodziny, a różnica między nimi jest najważniejszą rzeczą na tej stronie:

• 4xx — błędy klienta. Problem leży po stronie żądania: strona nie istnieje (404), została trwale usunięta (410) lub nie masz do niej dostępu (401, 403). Dla wyszukiwarki 4xx oznacza w zasadzie „nie ma tu żadnych treści.”
• 5xx — błędy serwera. Problem leży po Twojej stronie: serwer uległ awarii (500), system, od którego zależy, nie działa (502, 504) lub jest przeciążony albo w trakcie konserwacji (503). Dla wyszukiwarki 5xx oznacza „sam serwer jest teraz uszkodzony.”

Jak Google reaguje na każdą rodzinę

Tutaj rodziny się rozdzielają:

• Strona z kodem 4xx po prostu znika z wyników wyszukiwania. Google uznaje, że treść nie istnieje, i z czasem usuwa URL ze swojego indeksu. Co ważne, wiele błędów 404 nie spowalnia sposobu, w jaki Google indeksuje resztę Twojej witryny.
• Kod 5xx powoduje, że Google wolniej indeksuje całą Twoją witrynę. Gdy serwer zgłasza błędy, Google zwalnia, aby nie pogarszać sytuacji. Twoje już zaindeksowane strony pozostają w indeksie na początku — Google zaczyna je usuwać dopiero, gdy błędy się utrzymują. Gdy serwer znów działa prawidłowo, indeksowanie samo przyspiesza.

Rzecz, którą większość ludzi myli

Stos błędów 404 to nie kara. John Mueller z Google wprost stwierdził, że błędy 404 „nie są sygnałem jakości, nie są sygnałem SEO”. Zepsute i nieistniejące strony to normalna część internetu. Więc gdy otwierasz Search Console i widzisz tysiące błędów „Nie znaleziono”, nie panikuj — musisz naprawić tylko te, które mają znaczenie: strony, do których ludzie nadal linkują, strony w Twojej mapie witryny, strony, które miały ruch. Te naprawdę martwe mogą po prostu pozostać 404.

Jedynym wzorcem, który naprawdę ma udokumentowane negatywne skutki, jest serwer, który ciągle zwraca błędy 5xx — w tym przypadku Google ogranicza indeksowanie i ostatecznie usuwa strony. Nawet wtedy jest to odwracalne: napraw serwer, a wszystko wróci do normy.

Szybki przegląd kodów

Każdy z nich ma własną szczegółową stronę — oto wersja w jednym zdaniu:

• 401 / 403 — strona jest zablokowana (musisz się zalogować lub nie masz dostępu).
• 404 — strona nie znaleziona. 410 — strona usunięta na dobre.
• 429 — „zbyt wiele żądań” (ograniczenie szybkości). Wygląda jak błąd klienta, ale Google traktuje go jak błąd serwera.
• 451 — zablokowana z powodów prawnych (usunięcie treści, blokada na poziomie kraju).
• 500 / 502 / 503 / 504 — rodzina błędów serwera (awaria, zły bramkarz, niedostępność, przekroczenie czasu bramki).
• Miękki 404 — podstępny: strona, która mówi „nie znaleziono”, ale zwraca kod 200, więc Google nadal ją sprawdza.

Chcesz poznać mechanikę — dokładnie jak reaguje szybkość indeksowania Google, kiedy strony są usuwane z indeksu, jak prawidłowo wyłączyć witrynę i jak monitorować to wszystko w Search Console? Przełącz się na zakładkę Zaawansowane.

TL;DR — Kody błędów HTTP to klasy statusów 4xx (błąd klienta) i 5xx (błąd serwera). Google wyznacza między nimi wyraźną granicę behawioralną: 4xx (z wyjątkiem 429) oznacza „treść nie istnieje” — URL jest usuwany z indeksu, bez „wpływu na szybkość indeksowania”; 5xx (oraz 429) oznacza „serwer zawodzi” — Google proporcjonalnie ogranicza indeksowanie, początkowo zachowuje zaindeksowane URL-e, a usuwa je z indeksu tylko wtedy, gdy błędy się utrzymują, a następnie stopniowo zwiększa szybkość indeksowania po odzyskaniu sprawności. 429 jest numerycznie kodem 4xx, ale Google nazywa go „błędem serwera”. Treść z jakiejkolwiek odpowiedzi z błędem jest ignorowana. Błędy 404 nie są sygnałem jakości (Mueller) — segreguj według linków/ruchu, nie naprawiaj wszystkiego i pamiętaj, że rzeczywisty wpływ pojedynczego błędu zależy od URL-a (robots.txt ma specjalną obsługę błędów, której zwykła strona nie ma). Miękkie błędy 404 (kod 200, który wygląda jak „nie znaleziono”) są oznaczane przez Google jako marnotrawstwo budżetu indeksowania — dotyczy to głównie dużych witryn, a nie jest gwarantowanym efektem na każdej stronie. W przypadku planowanego przestoju użyj 503 + Retry-After, utrzymując go „co najwyżej przez kilka dni”, i nigdy nie zwracaj 503 dla robots.txt. Monitoruj rodzinę kodów przez raport Page Indexing w GSC. Ten hub mapuje i kieruje do każdego pojedynczego kodu.

Jedno rozróżnienie, które przenika cały temat

Kod protokołu opisuje wynik HTTP; etykieta w Search Console opisuje, jak Google sklasyfikowało zaobserwowane pobranie. Dowód potwierdzający to twierdzenie Primary standard or official documentation supporting the adjacent article claim. Zakres: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 RFC 9110: Status codes Nie wyciągaj pojedynczej przyczyny źródłowej ani dokładnego czasu usunięcia z samej rodziny kodów. Dowód potwierdzający to twierdzenie Primary standard or official documentation supporting the adjacent article claim. Zakres: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google: HTTP and network errors

Cztery warstwy są spłaszczane do „to jest 404”, gdy ludzie mówią o błędach, a ich rozróżnienie sprawia, że reszta tej strony ma sens:

1. Semantyka protokołu — co kod statusu oznacza zgodnie ze specyfikacją HTTP (404 oznacza „nie znaleziono” i koniec).
2. Zaobserwowane pobranie — co Googlebot faktycznie otrzymał w odpowiedzi na konkretne żądanie w konkretnym czasie, co może różnić się od tego, co widzi przeglądarka.
3. Przetwarzanie w wyszukiwarce — jak potok indeksowania Google klasyfikuje i reaguje na to zaobserwowane pobranie (usuwa URL, ogranicza indeksowanie, ignoruje treść).
4. Przyczyna źródłowa — faktyczny powód po Twojej stronie serwera (zły wdrożenie, przeciążona baza danych, reguła WAF), którego sam kod statusu nigdy Ci nie powie.

Znajomość rodziny (4xx vs 5xx) mówi Ci, na którą z pierwszych trzech warstw patrzysz. Nigdy nie zastępuje warstwy 4 — nadal musisz sam ustalić, dlaczego.

Dokumentacja Google jasno przedstawia ten podział i warto go przyswoić, zanim cokolwiek innego: błędy 4xx oznaczają “the content doesn’t exist” (tłumaczenie) „treść nie istnieje”; błędy 5xx oznaczają “the server itself is failing.” (tłumaczenie) „sam serwer zawodzi”. To dwa zupełnie różne problemy, a potok indeksowania Google reaguje na nie na dwa zupełnie różne sposoby.

Najpierw przydatna kotwica: nawet kod sukcesu nie jest obietnicą. Google mówi wprost, że “for Google Search, an HTTP 2xx (success) status code doesn’t guarantee indexing.” (tłumaczenie) „W przypadku wyszukiwarki Google kod statusu HTTP 2xx (success) nie gwarantuje indeksowania”. Kody błędów są właściwie bardziej deterministyczną połową obrazu — jednoznacznie mówią Google: albo „nie istnieje”, albo „uszkodzone”.

Jak Google traktuje błędy 4xx

W przypadku błędów klienta zachowanie Google jest jednolite i bezpośrednie: „Google nie używa treści z URL-i, które zwracają kody statusu 4xx,” oraz „roboty Google informują kolejny system przetwarzania, że treść nie istnieje.” Nawet jeśli Twoja strona 403 lub 404 wyświetla ścianę prawdziwego tekstu, żadna jego część nie zostanie zaindeksowana — treść odpowiedzi z błędem jest ignorowana.

Wynikają z tego dwie konsekwencje:

• Wcześniej zaindeksowane URL-e są usuwane. Gdy strona konsekwentnie zwraca 4xx, Google z czasem usuwa ją z indeksu.
• Brak kary za szybkość indeksowania. To obala mit: „Kody statusu 4xx, z wyjątkiem 429, nie mają wpływu na szybkość indeksowania.” Góra błędów 404 nie spowalnia indeksowania reszty Twojej witryny przez Google.

Ten ostatni punkt niweczy zły instynkt: nie próbuj ograniczać Googlebota za pomocą 401 lub 403. Google wyraźnie ostrzega: “don’t use 401 and 403 status codes for limiting the crawl rate.” (tłumaczenie) „Nie używaj kodów statusu 401 i 403 do ograniczania szybkości indeksowania.” Ściana uwierzytelniania nie spowalnia indeksowania — po prostu czyni treść niewidoczną.

Jak Google traktuje błędy 5xx (i 429)

Błędy serwera wyzwalają gałąź “the server is struggling” (tłumaczenie) „serwer ma trudności”, a tutaj Google celowo chroni Twoją witrynę:

• Najpierw ograniczana jest szybkość indeksowania, proporcjonalnie do wolumenu. “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling,” (tłumaczenie) „Błędy serwera 5xx i 429 skłaniają roboty Google do tymczasowego spowolnienia indeksowania”, a “the decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error.” (tłumaczenie) „spadek szybkości indeksowania jest proporcjonalny do liczby poszczególnych adresów URL, które zwracają błąd serwera.” Kilka błędów 500 ledwo rejestruje; awaria całej witryny mocno ogranicza indeksowanie.
• Zaindeksowane adresy URL są zachowywane… dopóki błędy nie będą się utrzymywać. “Already indexed URLs are preserved in the index, but eventually dropped,” (tłumaczenie) „Zaindeksowane adresy URL są zachowywane w indeksie, ale ostatecznie usuwane”, a Google “removes from the index URLs that persistently return a server error.” (tłumaczenie) „usuwa z indeksu adresy URL, które trwale zwracają błąd serwera.” Krótki problem nie powoduje deindeksacji; trwała awaria tak.
• Treść z 5xx jest również ignorowana. “Any content Google receives from URLs that return a 5xx status code is ignored.” (tłumaczenie) „Wszelka treść, którą Google otrzymuje z adresów URL zwracających kod statusu 5xx, jest ignorowana.”
• Odzyskiwanie jest automatyczne, ale stopniowe. “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (tłumaczenie) „Gdy serwer zacznie odpowiadać kodem statusu 2xx, Google stopniowo zwiększa szybkość indeksowania witryny.” Google szybko się wycofuje i ostrożnie wraca do pełnej szybkości — nie ma ręcznego „odblokowania”, po prostu naprawiasz przyczynę źródłową i czekasz.

Dlaczego 429 należy do kategorii błędów serwera

To najczęściej pomijany niuans w większości przewodników. 429 Too Many Requests jest liczbowo kodem 4xx, ale Google traktuje go jako sygnał serwera: “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (tłumaczenie) „Roboty Google traktują kod statusu 429 jako sygnał, że serwer jest przeciążony, i jest on uznawany za błąd serwera.” Tak więc WAF lub ogranicznik szybkości, który zacznie wysyłać 429 do Googlebota, ograniczy Twoje indeksowanie w taki sam sposób, jak fala błędów 500 — nie usunie poszczególnych stron tak, jak robi to 404. Kiedy rozbijam kody w moim przewodniku po kodach statusu HTTP w Ahrefs, umieszczam 429 z błędami serwera właśnie z tego powodu: jest to “a form of rate-limiting to protect the server,” (tłumaczenie) „forma ograniczania szybkości w celu ochrony serwera”, i powoduje, że Google zwalnia.

Mapa rodziny kodów błędów

Oto szybki widok segregacji całej rodziny. Każdy kod poniżej to osobny szczegółowy przewodnik zagnieżdżony pod tym hubem (są też na pasku bocznym):

Błędy blokowania / dostępu

• 401 Unauthorized — klient nie zidentyfikował się lub nie zweryfikował się, gdy było to potrzebne. Zablokowany dla Googlebota za żądaniem uwierzytelnienia.
• 403 Forbidden — klient jest znany, ale nie ma praw dostępu.

Błędy nieznalezienia

• 404 Not Found — żądany zasób nie został znaleziony.
• 404 vs 410 — praktyczna różnica między „nie znaleziono” a „usunięto” (jest mniejsza, niż ludzie myślą).
• 410 Gone — jak 404, ale dodatkowo informuje, że zasób nie wróci. Usuwa strony nieco szybciej.

Kod o podwójnej tożsamości

• 429 Too Many Requests — ograniczanie szybkości; liczbowo 4xx, ale Google traktuje go jako błąd serwera dla celów szybkości indeksowania.

Prawny

• 451 Niedostępne z przyczyn prawnych — zablokowany z przyczyn prawnych: blokady na poziomie kraju, usunięcia DMCA.

Błędy serwera (5xx)

• 500 Internal Server Error — serwer napotkał problem, z którym nie może sobie poradzić.
• 502 Bad Gateway — zła odpowiedź z serwera nadrzędnego.
• 503 Service Unavailable — serwer jest przeciążony lub wyłączony na czas konserwacji (poprawny kod na planowane przestoje).
• 504 Gateway Timeout — brak odpowiedzi na czas z serwera nadrzędnego.

Przypadek pułapki

• Soft 404 — strona, która zwraca 200 OK, ale wygląda na „nie znaleziono”. Najgorsze z obu światów — więcej na ten temat poniżej.

Zepsute przekierowania są blisko błędów, ale klasyfikowane osobno (Google wyświetla je jako “Redirect error” w Search Console, odróżniając je od normalnego, działającego “Page with redirect”). Domyślnie roboty Google “podążają za maksymalnie 10 skokami przekierowań” zanim się poddadzą; łańcuch, który jest zbyt długi, zapętla się lub zawiera zły URL, zamienia się w ten status Redirect-error.

Czy błąd HTTP szkodzi Twojemu SEO?

Zacznijmy od werdyktu: odosobniony błąd na zwykłej stronie prawie nigdy nie jest problemem, a 404 konkretnie nie są sygnałem rankingowym ani jakościowym. Mueller był w tej kwestii jednoznaczny i powtarzał to wielokrotnie. Ten odruch — “mam 50 000 błędów 404, moja strona musi być ukarana” — to mit numer jeden, który należy obalić. Błędy są normalną częścią internetu; posiadanie stron zwracających 404 lub 410 to technicznie poprawny sposób obsługi URL-i, które nie istnieją.

“Odosobniony” nie oznacza jednak “zawsze nieszkodliwy” — prawdziwy wpływ zależy od tego, co zwraca błąd. Zwykła strona zwracająca 404 to nic; specjalny zasób to co innego. Google ma dla robots.txt własne zasady obsługi błędów, odrębne od zwykłych URL-i, więc błąd serwera na robots.txt może wpłynąć na indeksowanie w sposób, w jaki 404 na zwykłej stronie nigdy by nie wpłynął. Oceniaj błąd po tym, na jakim URL-u występuje i co od niego zależy, a nie tylko po kodzie statusu.

Jedyny wzorzec z realnym, udokumentowanym mechanizmem to utrzymujące się, masowe błędy 5xx: ograniczenie tempa indeksowania → ostateczne usunięcie z indeksu. I nawet to jest proporcjonalne do tego, ile URL-i zwraca błędy i generalnie odwracalne, gdy serwer się odzyska — Google opisuje powrót do normy jako stopniowy, a nie natychmiastowy, więc traktuj dokładny czas, częstotliwość ponownych prób i szybkość odzyskiwania jako zależne od dowodów (to, co opisują dokumenty Google) a nie jako stałą gwarancję. Rozróżnienie, które robi Mueller, jest tym, które warto zapamiętać: tempo indeksowania reaguje na błędy serwera (429/500/503/timeouty), a nie na 404.

Marnowanie zasobów indeksowania a usuwanie z indeksu — dwie różne szkody

Pomocne jest rozdzielenie dwóch sposobów, w jakie błędy mogą Cię kosztować:

• Usuwanie z indeksu — utrzymujące się 4xx (strona usunięta jako “nieistniejąca”) lub utrzymujące się 5xx (strony usunięte po długotrwałej awarii serwera). Chodzi o strony opuszczające indeks.
• Marnowanie budżetu indeksowania — głównie problem dużych witryn. Przewodnik Google po budżecie indeksowania zauważa, że “if the site slows down or responds with server errors, the limit goes down and Google crawls less.” (tłumaczenie) „Jeśli witryna zwalnia lub odpowiada błędami serwera, limit spada i Google indeksuje mniej”. Ale prawdziwym marnotrawcą budżetu jest miękki 404: “soft 404 pages will continue to be crawled, and waste your budget.” (tłumaczenie) „Strony z miękkim 404 będą nadal indeksowane i będą marnować Twój budżet”. Ponieważ miękki 404 wygląda na żywy (zwraca 200), Google ciągle sprawdza stronę, której tak naprawdę nie ma. Dlatego miękki 404 to przypadek „najgorszy z obu światów” — nie znika czysto jak prawdziwe 404, tylko pozostaje i spala zapytania.

Pułapka miękkiego 404 ma dwie częste przyczyny, które warto wymienić: niestandardowy szablon “strona nie znaleziona”, który zwraca 200 zamiast prawdziwego 404, oraz masowe przekierowanie każdego martwego URL-a na stronę główną — Google również rozpoznaje ten wzorzec jako miękki 404. Przyjazna strona 404 jest dobra dla UX i w pełni zalecana — pod warunkiem, że nadal zwraca rzeczywisty kod statusu HTTP 404.

Jak poprawnie przeprowadzić planowany przestój

Gdy celowo wyłączasz witrynę (lub sekcję), poprawnym kodem jest 503 Service Unavailable z nagłówkiem Retry-After — nigdy 4xx. Wytyczne Google “Pause your online business” są konkretne:

• “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code.” (tłumaczenie) «Jeśli pilnie potrzebujesz wyłączyć witrynę na 1-2 dni, zwróć stronę błędu informacyjnego z kodem odpowiedzi HTTP 503.»
• “This is an extreme measure that should only be taken for a very short period of time (a few days at most),” (tłumaczenie) «To skrajny środek, który należy stosować tylko przez bardzo krótki czas (co najwyżej kilka dni),» ponieważ “completely closing a site even for just a few weeks can have negative consequences on Google’s indexing of your site.” (tłumaczenie) «całkowite zamknięcie witryny nawet na zaledwie kilka tygodni może mieć negatywne konsekwencje dla indeksowania Twojej witryny przez Google.»
• “Don’t block the website by returning 403, 404, 410 HTTP status codes” (tłumaczenie) «Nie blokuj witryny, zwracając kody statusu HTTP 403, 404, 410» podczas przestoju — kod 4xx oznacza „trwale usunięte”, co jest dokładnie złym sygnałem dla tymczasowej awarii.
• Pułapka, którą większość pomija: “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.” (tłumaczenie) «Nie zwracaj kodu odpowiedzi HTTP 503 dla pliku robots.txt, ponieważ blokuje to całe indeksowanie.» Zwracaj 503 dla swoich stron, nie dla robots.txt.

Jak monitorować całą rodzinę w Search Console

Na co dzień spotkasz te błędy w raporcie Indeksowanie stron w Search Console, gdzie każdy z nich odpowiada innemu statusowi:

• Nie znaleziono (404) — “this page returned a 404 error when requested.” (tłumaczenie) «ta strona zwróciła błąd 404 po zapytaniu.»
• Błąd serwera (5xx) — “your server returned a 500-level error when the page was requested.” (tłumaczenie) «Twój serwer zwrócił błąd poziomu 500, gdy strona została zapytana.»
• Zablokowano z powodu nieautoryzowanego żądania (401) — “the page was blocked to Googlebot by a request for authorization.” (tłumaczenie) «strona została zablokowana dla Googlebota przez żądanie autoryzacji.»
• Zablokowano z powodu braku dostępu (403) — kod 403, gdy podano poświadczenia, ale nie przyznano dostępu.
• Zablokowano z powodu innego problemu 4xx — kod 4xx nieobjęty innym statusem; użyj URL Inspection do debugowania.
• Miękki 404 — “user-friendly ‘not found’ message but not a 404 HTTP response code.” (tłumaczenie) «przyjazny dla użytkownika komunikat „nie znaleziono”, ale nie kod odpowiedzi HTTP 404.»
• Błąd przekierowania — zbyt długi łańcuch, pętla, zbyt długi URL lub zły URL w łańcuchu.

Każdy status wskazuje inną przyczynę źródłową i ścieżkę naprawy. Po rozwiązaniu jednego użyj Validate Fix, aby zainicjować ponowne indeksowanie — ale ustaw realistyczne oczekiwania co do czasu; ponowne indeksowanie nie jest natychmiastowe. I pamiętaj o sformułowaniu Google: “it’s fine for a URL not to be indexed for the right reasons — for example… a 404 for a page that you’ve removed and have no replacement for.” (tłumaczenie) «to normalne, że URL nie jest indeksowany z właściwych powodów — na przykład… 404 dla strony, którą usunąłeś i nie masz dla niej zamiennika.» Nie każdy błąd to zadanie do wykonania.

Sam Search Console nie wystarczy, aby na nim działać — to jeden punkt obserwacyjny, próbkowany i opóźniony. Gdy logujesz błąd do triage, zapisz co najmniej: URL, kiedy go zaobserwowałeś, punkt obserwacyjny (Search Console vs. sprawdzenie na żywo vs. logi serwera/CDN), user agent, z którego przyszło żądanie, metodę HTTP, finalny kod statusu i ścieżkę odpowiedzi (w tym łańcuch przekierowań), czy to jednorazowe czy powtarzające się, oraz krok weryfikacji po naprawie po ponownym wdrożeniu. Triangulacja GSC z aktywnym sprawdzeniem statusu i własnymi logami to sposób, aby nieaktualny wiersz raportu zamienić w potwierdzony, możliwy do naprawienia problem.

Jak naprawiać i priorytetyzować błędy

• Triage 404 według wartości. Napraw te z linkami przychodzącymi, wewnętrznymi, obecnością w sitemapie lub utrzymującym się ruchem — przekieruj je 301 do odpowiedniej strony, aby odzyskać siłę linków. Pozwól naprawdę martwym URL-om zwracać 404 lub 410. Jak ująłem to w moim przewodniku Ahrefs, praktyczną naprawą większości z nich jest to, że “you just need to 301 redirect each of these pages to a relevant page” (tłumaczenie) «po prostu musisz przekierować 301 każdą z tych stron do odpowiedniej strony» — ale tylko tam, gdzie istnieje odpowiedni cel. Nie przekierowuj wszystkiego hurtowo na stronę główną (to miękki 404).
• 410 vs 404 ma marginalne znaczenie. Kod 410 usuwa stronę nieco szybciej niż 404; praktyczna różnica SEO jest niewielka. Użyj 410, gdy chcesz jednoznacznie wskazać, że coś zniknęło na dobre, ale nie oczekuj, że będzie dramatycznie lepsze.
• Napraw przyczynę źródłową 5xx. Poprawki są po stronie serwera: pojemność i limity czasu dla 500, zdrowie upstream/CDN dla 502/504 oraz reguły WAF lub ograniczania szybkości błędnie działające na Googlebota dla 403/429. Potwierdź prawdziwego bota odwrotnym/bezpośrednim sprawdzeniem DNS, zanim zaczniesz ograniczać mu szybkość.
• Warte wymienienia typowe przyczyny źródłowe: błędy aplikacji i bazy danych oraz przeciążone hosty (5xx), awarie upstream/CDN (502/504), ograniczanie szybkości lub blokowanie botów przez WAF (403/429), zepsute migracje i nieaktualne linki wewnętrzne (404) oraz źle skonfigurowane „przyjazne strony błędów” (miękki 404).

Bing: podobny wzorzec, nie niezależnie zweryfikowany kod po kodzie

Publiczne oświadczenia Binga wskazują ten sam kierunek co podejście Google — kody z zakresu 400 są traktowane jako brakujące lub zabronione, a kody z zakresu 500 sygnalizują problemy serwera, które działają na niekorzyść efektywności indeksowania — ale nie zweryfikowałem niezależnie pełnej, aktualnej zgodności kod po kodzie z własną dokumentacją Binga, więc traktuj to jako orientacyjne, a nie potwierdzone dopasowanie jeden do jednego. Fabrice Canel opisuje cel Binga jako “crawl efficiency north star … to crawl a URL only when the content has been added … updated,” (tłumaczenie) „północna gwiazda efektywności indeksowania … aby indeksować URL tylko wtedy, gdy treść została dodana … zaktualizowana”, a trwałe błędy działają bezpośrednio przeciwko temu — Bing wydaje zasoby indeksowania na URL-e, które nie przynoszą świeżych, indeksowalnych treści. Bing zaleca również 503 z Retry-After na planowane przerwy techniczne, zamiast serwowania stron błędów jako 200. Powierzchnie błędów indeksowania Binga znajdziesz w Bing Webmaster Tools (URL Inspection, Crawl Control, Site Scan).

Gdzie dalej

Ta strona jest koncepcyjnym centrum dla rodziny kodów błędów. Znajduje się w szerszym klastrze HTTP Status Codes (pełny obraz 1xx–5xx, plus przekierowania i kody sukcesu); to podcentrum jest mapą dla error połowy tego. Każdy kod poniżej to osobne szczegółowe omówienie:

Zablokowane / dostęp

• 401 Unauthorized — co wyzwala status “Blocked due to unauthorized request” i dlaczego ściany autoryzacji nie ograniczają Googlebota.
• 403 Forbidden — poświadczenia podane, ale odrzucone, oraz wzorce WAF/blokowania botów, które powodują fałszywe 403 dla Googlebota.

Nie znaleziono

• 404 Not Found — jak Google radzi sobie z brakującymi stronami, dlaczego to nie kara i które 404 warto faktycznie naprawić.
• 404 vs 410 — realna, niewielka różnica i kiedy sięgać po które.
• 410 Gone — sygnał “trwale usunięte” i jego nieco szybsze usunięcie z indeksu.

Ograniczanie szybkości

• 429 Too Many Requests — 4xx, który zachowuje się jak 5xx, i jak zapobiec, aby limity szybkości ograniczały Twoje indeksowanie.

Prawne

• 451 Niedostępne z przyczyn prawnych — usunięcia, blokady krajowe i jak prawne usunięcia się pojawiają.

Błędy serwera

• 500 Internal Server Error — ogólna awaria serwera i jak znaleźć jej przyczynę.
• 502 Bad Gateway — awarie upstream/proxy.
• 503 Service Unavailable — poprawny kod na konserwację i planowane przerwy (z pułapką robots.txt).
• 504 Gateway Timeout — przekroczenie czasu upstream.

Przypadek pułapki

• Soft 404 — 200, które czyta się jako usunięte, dlaczego marnuje budżet indeksowania i jak zamienić je na prawdziwe 404.

Zepsute przekierowania są obsługiwane osobno jako status Redirect error — powiązany, ale skategoryzowany osobno w Search Console.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Dwie rodziny, dwa zachowania. 4xx = „treść nie istnieje”; 5xx = „serwer zawodzi”. Pipeline indeksowania Google reaguje na każdą z nich bardzo różnie.
• 4xx (z wyjątkiem 429): treść jest ignorowana, URL wypada z indeksu i nie ma „wpływu na szybkość indeksowania”. Nie używaj 401/403 do ograniczania Googlebota — Google wyraźnie tego zabrania.
• 5xx (i 429): Google najpierw ogranicza indeksowanie (proporcjonalnie do liczby błędnych URL-i), początkowo zachowuje zaindeksowane URL-e, a usuwa z indeksu tylko wtedy, gdy błędy utrzymują się. Odzyskiwanie jest automatyczne, ale szybkość indeksowania wraca stopniowo.
• 429 jest wyjątkiem: numerycznie to 4xx, ale Google traktuje go jako „błąd serwera” w kontekście szybkości indeksowania — zachowuje się jak 5xx.
• 404 nie jest sygnałem jakości/rankingu (Mueller). Nie panikuj z powodu liczby błędów; triażuj według linków, obecności w sitemap i ruchu — przekieruj 301 te, które mają znaczenie, a martwe strony pozostaw jako 404/410.
• Wpływ pojedynczego błędu zależy od URL-a, nie tylko od kodu statusu — zwykła strona zwracająca 404 to nic wielkiego, ale specjalne zasoby, takie jak robots.txt, mają własną obsługę błędów i mogą wpływać na indeksowanie inaczej.
• Soft 404 to pułapka: 200, który wygląda jak „nie znaleziono”, co Google oznacza jako marnowanie budżetu indeksowania, ponieważ ciągle sprawdza stronę, która wygląda na żywą — dotyczy to głównie dużych witryn, a nie jest gwarantowanym efektem na każdej stronie.
• 410 vs 404 to różnica marginalna — 410 znika nieco szybciej; praktyczna różnica jest niewielka.
• Planowany przestój: użyj 503 + Retry-After, „maksymalnie kilka dni”, nigdy 403/404/410, i nigdy nie zwracaj 503 dla robots.txt (blokuje to całe indeksowanie).
• Monitoruj przez raport Page Indexing w GSC — siedem statusów (404, 5xx, 401, 403, inne 4xx, soft 404, błąd przekierowania) — plus własne testy na żywo i logi serwera, i używaj Validate Fix.
• Publiczne wypowiedzi Binga wskazują ten sam kierunek co Google — ale pełna zgodność kod po kodzie nie jest niezależnie zweryfikowana; Bing również zaleca 503 + Retry-After na czas przestoju.

Oficjalna dokumentacja

Dokumentacja źródłowa od wyszukiwarek.

Google

• Kody statusu HTTP, błędy sieciowe i błędy DNS — definitywny dokument o tym, jak Google obsługuje 4xx, 5xx, 429, przekierowania oraz błędy sieciowe/DNS.
• Raport Page Indexing (Pomoc Search Console) — każdy status błędu, który zobaczysz na co dzień (404, 5xx, 401, 403, inne 4xx, soft 404, błąd przekierowania) oraz Validate Fix.
• Optymalizuj budżet indeksowania — jak błędy serwera zmniejszają limit indeksowania i dlaczego soft 404 marnują budżet.
• Wstrzymaj działalność online w Google Search — playbook 503 + Retry-After dla planowanego przestoju i czego nie robić.
• Błędy soft 404 — czym jest soft 404 i jak go naprawić.
• Spraw, aby strony 404 były bardziej przydatne — starsze, ale wciąż aktualne wskazówki: przyjazna strona 404 jest w porządku pod warunkiem, że zwraca prawdziwy kod 404.

Bing / Microsoft

• Alerty o błędach indeksowania (Pomoc Bing Webmaster Tools) — gdzie Bing pokazuje błędy indeksowania.
• bingbot Series: Maximizing Crawl Efficiency — „północna gwiazda efektywności indeksowania” Binga, której trwałe błędy szkodzą.

Cytaty ze źródła

Oficjalne wypowiedzi Google i Bing. Każdy link to link bezpośredni, który przenosi do cytowanego fragmentu na stronie źródłowej.

Google — podział 4xx vs 5xx

• “For Google Search, an HTTP 2xx (success) status code doesn’t guarantee indexing.” (tłumaczenie) „W przypadku wyszukiwarki Google kod statusu HTTP 2xx (success) nie gwarantuje indeksowania”. — Google Search Central docs. Przejdź do cytatu
• “Google doesn’t use the content from URLs that return 4xx status codes.” (tłumaczenie) „Google nie używa treści z adresów URL zwracających kody statusu 4xx”. Przejdź do cytatu
• “The 4xx status codes, except 429, have no effect on crawl rate.” (tłumaczenie) „Kody statusu 4xx, z wyjątkiem 429, nie wpływają na szybkość indeksowania”. Przejdź do cytatu

Google — 5xx i 429

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling.” (tłumaczenie) „Błędy serwera 5xx i 429 skłaniają crawlery Google do tymczasowego spowolnienia indeksowania”. Przejdź do cytatu
• “already indexed URLs are preserved in the index, but eventually dropped.” (tłumaczenie) „Już zaindeksowane adresy URL pozostają w indeksie, ale ostatecznie są z niego usuwane”. Przejdź do cytatu
• “Any content Google receives from URLs that return a 5xx status code is ignored.” (tłumaczenie) „Każda treść otrzymana przez Google z adresów URL zwracających kod statusu 5xx jest ignorowana”. Przejdź do cytatu
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (tłumaczenie) „Crawlery Google traktują kod statusu 429 jako sygnał przeciążenia serwera i uznają go za błąd serwera”. Przejdź do cytatu

Google — budżet indeksowania i miękki 404

• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (tłumaczenie) „Jeśli witryna zwalnia lub odpowiada błędami serwera, limit spada i Google indeksuje mniej”. Przejdź do cytatu
• “Soft 404 pages will continue to be crawled, and waste your budget.” (tłumaczenie) „Strony z miękkim błędem 404 będą nadal indeksowane i marnują Twój budżet”. Przejdź do cytatu

Google — planowany przestój

• “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code.” (tłumaczenie) „Jeśli musisz pilnie wyłączyć witrynę na 1–2 dni, zwróć informacyjną stronę błędu z kodem odpowiedzi HTTP 503”. Przejdź do cytatu
• “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.” (tłumaczenie) „Nie zwracaj kodu odpowiedzi HTTP 503 dla pliku robots.txt, ponieważ blokuje to całe indeksowanie”. Przejdź do cytatu

Google — to normalne, że nie jesteś indeksowany

• “It’s fine for a URL not to be indexed for the right reasons — for example, an expected robots.txt rule on your site, a noindex tag on the page, a duplicate URL, or a 404 for a page that you’ve removed and have no replacement for.” (tłumaczenie) „Brak indeksowania adresu URL jest w porządku, jeśli wynika z właściwych przyczyn — na przykład oczekiwanej reguły robots.txt, tagu noindex, duplikatu adresu URL lub błędu 404 na usuniętej stronie bez zamiennika”. — Pomoc Search Console. Przejdź do cytatu

John Mueller, Google — 404 nie są sygnałem jakości

• “404s are not a quality signal, it’s not a SEO signal.” (tłumaczenie) „Błędy 404 nie są sygnałem jakości ani sygnałem SEO”. Przeczytaj relację
• O reakcjach na tempo indeksowania: “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts… (404s are generally fine & once discovered, Googlebot will retry them anyway)… Once things settle down on the server, the crawl rate will return to normal automatically.” (tłumaczenie) „Tak szybkiej reakcji szybkości indeksowania oczekiwałbym tylko przy odpowiedziach 429, 500, 503 lub przekroczeniach limitu czasu. Błędy 404 są zasadniczo w porządku, a po ich wykryciu Googlebot i tak ponowi próby. Gdy sytuacja na serwerze się uspokoi, szybkość indeksowania automatycznie wróci do normy”. Przeczytaj relację

Fabrice Canel, Microsoft Bing

• “Our crawl efficiency north star is to crawl a URL only when the content has been added (URL not crawled before), updated (fresh on-page context or useful outbound links).” (tłumaczenie) „Naszą nadrzędną zasadą efektywności indeksowania jest pobieranie adresu URL tylko wtedy, gdy treść została dodana — adres nie był wcześniej indeksowany — lub zaktualizowana, na przykład o nowy kontekst na stronie bądź przydatne linki wychodzące”. Przejdź do cytatu

Którym błędem zająć się najpierw?

Gdy pojawi się partia błędów, pracuj według tej kolejności triage — najpierw zdrowie serwera, potem brakujące strony, bo tam kryje się prawdziwe, ogólnoserwisowe ryzyko.

1. Czy widzisz błędy 5xx lub 429 (błąd serwera lub wzrost limitów czasu)?

• Tak → Traktuj to jako pilne. To gałąź, która ogranicza indeksowanie w całym serwisie i może usunąć strony z indeksu, jeśli się utrzyma. Znajdź przyczynę teraz: pojemność serwera / limity czasu (500), zdrowie upstream/CDN (502/504) lub WAF / ogranicznik szybkości błędnie blokujący Googlebota (403/429). Odzyskanie jest automatyczne po powrocie do 2xx, ale tempo indeksowania wraca stopniowo.
• Nie → Przejdź dalej; 4xx nie ma wpływu na tempo indeksowania.

2. Czy to miękki 404 (kod 200 oznaczający „nie znaleziono”)?

• Tak → Popraw kod odpowiedzi. Albo zwróć prawdziwy 404/410, albo jeśli strona się przeniosła, przekieruj ją 301 na odpowiednią stronę. Przestań masowo przekierowywać martwe adresy URL na stronę główną. Miękkie 404 marnują budżet indeksowania, bo Google ciągle je sprawdza.
• Nie → Kontynuuj.

3. Czy to 404 / 410 (Nie znaleziono / Usunięto)?

• Czy adres URL ma linki przychodzące, linki wewnętrzne, obecność w mapie witryny lub utrzymujący się ruch?
  • Tak → Przekieruj go 301 na odpowiednią stronę, aby odzyskać wartość.
  • Nie → Zostaw go. Naprawdę martwa strona powinna po prostu zwracać 404/410 — to nie jest kara i nie musisz jej naprawiać.

4. Czy to 401 / 403 (Zablokowano)?

• Czy ta strona powinna być publiczna? Tak → Popraw konfigurację uwierzytelniania/uprawnień lub regułę WAF, która blokuje Googlebota. Nie → To w porządku, że jest zablokowana — ale nie oczekuj, że 401/403 ograniczy Googlebota; to tylko sprawia, że treść jest niewidoczna.

5. Czy to 451 (Prawny)?

• To prawne usunięcie lub blokada geograficzna, a nie błąd techniczny — obsłuż to przez proces prawny/zgodnościowy, a nie SEO.

6. Czy to błąd przekierowania?

• Skróć łańcuch (Google podąża za maksymalnie ~10 przeskokami), przerwij pętlę lub napraw zły/zbyt długi adres URL w łańcuchu, aby prowadził do jednego końcowego 200.

Usunięcie z indeksu czy marnowanie budżetu indeksowania — z jaką szkodą faktycznie się mierzysz?

• Strony znikają z indeksu? → Szukaj utrzymujących się błędów 4xx (usuniętych jako „nie istnieją”) lub utrzymujących się błędów 5xx (usuniętych po ciągłych awariach). Pojedyncze błędy tego nie robią.
• Budżet indeksowania jest marnowany (duże witryny)? → Szukaj miękkich 404 i masowych błędów — stron, które są ciągle ponownie indeksowane, bo wyglądają na żywe.

Ściągawka: kod błędu → zachowanie → naprawa

Jak Google traktuje każdy kod

Szybkie fakty

• 4xx (oprócz 429): treść ignorowana, URL usunięty, zero wpływu na szybkość indeksowania.
• 5xx + 429: najpierw ograniczanie, usuń z indeksu tylko jeśli trwałe, odzyskiwanie jest stopniowe.
• 404 nie są sygnałem jakości/rankingu — triażuj według linków/ruchu.
• Soft 404 = pułapka: 200, który czyta się jako usunięty → marnuje budżet indeksowania.
• Planowany przestój = 503 + Retry-After, „co najwyżej kilka dni”, nigdy 403/404/410 — i nigdy nie 503 dla robots.txt (blokuje całe indeksowanie).
• Przekierowania: Google podąża do ~10 przeskoków; zbyt długie/zapętlone łańcuchy = „Błąd przekierowania” w GSC.

Statusy indeksowania stron w GSC do obserwowania Nie znaleziono (404) · Błąd serwera (5xx) · Zablokowane z powodu nieautoryzowanego żądania (401) · Zablokowane z powodu zabronionego dostępu (403) · Zablokowane z powodu innego problemu 4xx · Soft 404 · Błąd przekierowania — następnie Zweryfikuj naprawę, gdy rozwiązane.

Zasoby warte Twojego czasu

Moje powiązane teksty

• Kody statusu HTTP i ich wpływ na SEO — mój pełny przegląd kod po kodzie: 4xx, 5xx, 429 i praktyczne naprawy, w całym zakresie kodów statusu.
• 11 typów przekierowań i ich wpływ na SEO — strona przekierowań, która jest główną przyczyną zarówno błędów przekierowań, jak i soft 404s.
• Przewodnik dla początkujących po technicznym SEO — gdzie kody statusu wpisują się w szerszy obraz.

Moje wystąpienia

• Jak działa wyszukiwarka (SlideShare) — mój przegląd indeksowania, renderowania, indeksowania i serwowania, w tym jak kody statusu bramkują pipeline. (Moje stałe zastrzeżenie: „To moje rozumienie systemów… nie będzie w 100% kompletne ani dokładne”).

Z branży

• Spadek indeksowania Googlebota? Mueller wskazuje błędy serwera (Search Engine Journal) — artykuł zakotwiczający rozróżnienie „szybkość indeksowania reaguje na 429/500/503/timeouty, nie na 404s”, słowami Muellera.
• Kompletny przewodnik po kodach statusu HTTP dla SEO (Search Engine Land) — szerokie odniesienie do każdej klasy statusu.
• Objaśnienie kodów statusu HTTP (Semrush) — przegląd rodzin kodów skoncentrowany na implementacji.
• Przewodnik SEO po kodach statusu HTTP (Search Engine Journal) — odniesienie kod po kodzie z kontekstem SEO.
• r/TechSEO — społeczność do debugowania błędów indeksowania i indeksowania.

Model dwóch szkód: zniknięcie a ograniczanie indeksowania

Nie priorytetyzuj błędu HTTP wyłącznie na podstawie pierwszej cyfry. Zapytaj, którą z dwóch szkód powoduje.

Szkoda 1: URL informuje, że treść nie istnieje

Większość odpowiedzi 4xx informuje Google, że żądana treść jest niedostępna. Google nie indeksuje zwróconej treści, a trwale dotknięty URL może zostać usunięty z indeksu. Zakres zwykle dotyczy samego URL-a; zwykłe odpowiedzi 4xx nie informują Google, że cały serwer jest niezdrowy. Wyjątkiem jest 429, które Google traktuje jak problem z dostępnością serwera.

Pytanie decyzyjne: Czy ten URL ma istnieć, otrzymywać ruch lub zachowywać linki? Jeśli tak, napraw błędny status lub przekieruj użytkowników do rzeczywiście równoważnego miejsca docelowego. Jeśli nie, 404 lub 410 może być właściwym wynikiem, a nie problemem SEO.

Szkoda 2: serwer informuje, że nie może niezawodnie odpowiadać

Odpowiedzi 5xx i 429 sygnalizują problemy z dostępnością lub wydajnością. Google może ograniczyć indeksowanie, aby nie zwiększać obciążenia; tylko trwałe awarie zagrażają zaindeksowanym URL-om. Szkoda może zatem wykraczać poza jeden zawodny URL, prowadząc do wolniejszego odkrywania i odświeżania w całej witrynie.

Pytanie decyzyjne: Czy awaria jest na tyle trwała lub szeroka, aby zmienić zachowanie robota indeksującego? Jeśli tak, potraktuj to jako incydent infrastrukturalny i przywróć niezawodne odpowiedzi. Nie „naprawiaj” tego w Search Console.

Nakładka priorytetowa: wartość i intencja

Po wybraniu szkody uszereguj dotknięte URL-e według tego, czy powinny być aktywne, mieć linki wewnętrzne lub zewnętrzne, znajdować się w mapie witryny, otrzymywać ruch z wyszukiwarki lub reprezentować krytyczny szablon. Liczba błędów bez tego kontekstu nie jest listą priorytetów.

Macierz dowodów/działań: co zapisać dla każdego błędu

Model dwóch szkód mówi ci, z którym problemem masz do czynienia. Ta macierz to, co faktycznie należy zapisać dla każdego dotkniętego URL-a, zanim zdecydujesz, co z nim zrobić — pominięcie którejkolwiek z tych kolumn sprawia, że lista triażowa zamienia się w zgadywankę:

Prompt: zamień eksport błędów z GSC w kolejkę triażową

Wyeksportuj listę dotkniętych URL-i z Search Console i wzbogać ją tam, gdzie to możliwe, o kod statusu, obecność w mapie witryny, kliknięcia/wyświetlenia organiczne, linki wewnętrzne, linki zewnętrzne i zamierzony stan URL-a. Wklej tylko nie wrażliwe dane.

You are triaging an HTTP-error URL export for technical SEO. Use only the supplied
columns. Do not assume that every 404 is a problem or that every 5xx is permanent.

For each URL:
1. Classify the response as 4xx disappearance risk, 5xx/429 crawl-throttling risk,
   soft-404 mismatch, or insufficient evidence.
2. Decide whether the URL appears intended to exist, based only on sitemap presence,
   links, traffic, template, and the supplied intended-state field.
3. Assign priority: incident-now, high, medium, low, or expected/no fix.
4. Explain the priority using the exact supplied signals.
5. Recommend the next verification, not a guessed root cause.

Prioritize broad or persistent 5xx/429 incidents first, then intended URLs with
traffic or links, then sitemap/internal-link hygiene. Keep intentional 404/410 URLs
out of the fix queue. Return a table plus a short list of missing data that would
change the ranking.

DATA:
[PASTE SANITIZED EXPORT HERE]

Zweryfikuj wynik na podstawie aktywnych kontroli statusu i zamierzonej mapy URL-i witryny przed przypisaniem pracy.

Narzędzia do triażu błędów

• Bulk HTTP Status Code Checker — wklej wyeksportowane adresy URL, aby zebrać aktualne kody statusu, łańcuchy przekierowań, miejsca docelowe i opóźnienia, a następnie filtruj i eksportuj wynik. To zamienia nieaktualny wiersz raportu w bieżący dowód HTTP.
• Website Down Checker — sprawdź, czy podejrzewany incydent 5xx jest zewnętrznie odtwarzalny, zanim zmienisz ustawienia aplikacji lub crawlera.
• Raport Page Indexing w Google Search Console — zidentyfikuj grupy powodów Google i przykłady, których dotyczą; użyj URL Inspection do reprezentatywnej kontroli na żywo.
• Logi dostępu serwera lub CDN — zmierz wskaźniki błędów widzianych przez crawlera i odróżnij problem pojedynczego adresu URL od ogólnego wzorca dostępności w całym serwisie.

Search Console raportuje to, co zaobserwował Google; nie zastępuje to żywego żądania ani dowodów z serwera potrzebnych do znalezienia przyczyny.

Docelowe adresy URL zwracające błędy

Metryka: Liczba i udział adresów URL, które mają być aktywne, ale zwracają 4xx, 5xx lub 429, podzielone według rodziny odpowiedzi i szablonu.

Co to mówi: Oddziela rzeczywiste wady dostępności/indeksowania od celowego czyszczenia 404/410.

Jak to wyciągnąć: Połącz bieżący crawl lub eksport Bulk HTTP Status Code Checker z sitemap.xml, grafem linków wewnętrznych i zamierzonym spisem adresów URL.

Benchmark / realistyczny zakres: Celem jest zero niezamierzonych błędów na adresach URL, które muszą być aktywne. Oczekiwane wycofane adresy URL należy śledzić osobno, a nie wpychać w wymyślony ogólny wskaźnik błędów dla całego serwisu.

Częstotliwość: Codziennie dla krytycznych szablonów i podczas wydań; co tydzień dla szerszego spisu.

Wskaźnik błędów żądań crawlera

Metryka: Żądania wyszukiwarek zwracające 4xx, 429 lub 5xx jako udział zweryfikowanych żądań crawlera, podzielone według statusu, nazwy hosta i grupy ścieżek.

Co to mówi: Pokazuje, czy marnotrawstwo crawlera koncentruje się na wycofanych adresach URL, czy błędy serwera mogą tłumić popyt na crawl.

Jak to wyciągnąć: Agreguj zweryfikowane żądania crawlera z logów dostępu CDN lub serwera; nie polegaj wyłącznie na stringu user-agent, gdy dostępna jest weryfikacja.

Benchmark / realistyczny zakres: Ustal normalną mieszankę dla swojego serwisu. Celowe 404 mogą być uzasadnione; niewyjaśnione odpowiedzi 5xx/429 na docelowych adresach URL nie powinny być traktowane jako normalny szum bazowy.

Częstotliwość: Monitoruj ciągle alerty 5xx/429; przeglądaj trendy segmentowane co tydzień.

Trend spisu błędów w Search Console

Metryka: Liczby dotkniętych adresów URL według powodu Page Indexing, w połączeniu z reprezentatywnym stanem adresu URL i datą aktualizacji raportu.

Co to mówi: Czy obserwowany przez Google spis zmniejsza się po poprawkach, czy rozszerza się na dodatkowe szablony.

Jak to wyciągnąć: Wyeksportuj tabele powodów Page Indexing i zachowaj datowane migawki; sprawdź przykłady za pomocą URL Inspection i żywych żądań.

Benchmark / realistyczny zakres: Porównaj z zamierzonym stanem serwisu i jego własnymi wcześniejszymi migawkami. Search Console jest próbkowany i opóźniony, więc nie wymyślaj progu przejścia w czasie rzeczywistym.

Częstotliwość: Co tydzień i po tym, jak Google miał czas na ponowne przecrawlowanie wdrożonej poprawki; używaj logów i kontroli na żywo do natychmiastowego monitorowania incydentów.

Sprawdź się: kody błędów HTTP

Pięć szybkich pytań o to, jak Google radzi sobie z błędami 4xx i 5xx. Wybierz odpowiedź na każde, a następnie sprawdź.

Dziennik zmian