Błąd 4xx a indeks Google: tymczasowa ochrona URL-i

Gdy ważny adres URL zaczyna zwracać błąd 4xx, Google nie musi go od razu usuwać z indeksu. Gary Illyes napisał, że wyszukiwarka może wtedy „tymczasowo ochronić URL przed natychmiastowym wypadnięciem z indeksu”, więc strona dalej pojawia się w wynikach, tyle że bez fragmentu opisu i bez favicony.

Adres, który zwraca 4xx dłużej, i tak w końcu z indeksu zniknie, bo tej zasady Google nie zmieniło. Wypowiedź Illyesa porównałem z dokumentacją, a serwer VLC, od którego wszystko się zaczęło, sprawdziłem sam.

Skąd ta wypowiedź: strona VLC bez favicony

Na początku listopada 2026 roku zespół VideoLAN, który rozwija odtwarzacz VLC, poprosił na LinkedInie o pomoc, bo z wyniku Google zniknęła favicona strony, a oni, jak pisali, niczego nie zmieniali. Strona główna VLC dalej była w wynikach, na drugim miejscu pod stroną pobierania.

Komentujący szukali winy m.in. w zbyt małym pliku favicony. Illyes wyjaśnił, że serwer VLC zwracał kod 418 („I’m a teapot”), czyli żartobliwy status z prima aprilisowej specyfikacji z 1998 roku (RFC 2324), którego prawdziwa strona nie powinna wysyłać. Google traktuje go według Illyesa jak „większość innych błędów 4xx: w zasadzie jako »nie znaleziono«”.

Strona mimo to nie wypadła z indeksu, bo VLC to zdaniem Illyesa „prawdopodobnie jedna z najważniejszych stron w internecie” i wyszukiwarka tymczasowo wstrzymała jej usunięcie. Barry Schwartz z Search Engine Roundtable, który opisał sprawę 5 listopada, podsuwa jeszcze jedno wyjaśnienie: strona mogła zostać w wynikach także dlatego, że ludzie wyszukują ją po nazwie. Google tego nie potwierdziło.

Co dzieje się z chronionym URL-em

Ochrona ma swoją cenę. Google dostaje błąd zamiast treści, więc, jak napisał Illyes, „nie wie już, co jest na stronie” i nie ma czego pokazać. W wyniku zostaje tylko link i ostatni dobry tytuł, jaki wyszukiwarka zapamiętała, a fragment opisu (snippet) i favicona znikają.

Krok po kroku wygląda to tak:

URL jest w indeksie, ma treść, tytuł i faviconę.
Serwer zaczyna odpowiadać robotowi kodem 4xx.
Google nie usuwa ważnego URL-a od razu, ale nie ma świeżej treści. W wynikach zostaje link i ostatni znany tytuł.
Gdy serwer znów zwraca 200 z treścią, dane odświeżają się przy kolejnych wizytach robota. Jeśli błąd się utrzymuje, URL zostanie usunięty, tak jak opisuje to dokumentacja.

VLC zatrzymało się na trzecim kroku. Według Illyesa strona znów zwraca 200 z treścią, więc wynik „powinien się wkrótce sam wyrównać”.

Schwartz dopisał, że pod koniec października favicona jego serwisu też na kilka dni zniknęła z wyników i wróciła dopiero po zmianie ustawień Cloudflare. Przeczucie podpowiada mu, że chodziło o obronę przed luką w PHP, o której pisałem przy wyłączaniu strony na czas łatania PHP, ale niczego tu nie przesądza.

Skąd 418: sprawdziłem serwer VLC

Illyes nie wyjaśnił, dlaczego serwer VLC odpowiadał czajnikiem. Sprawdziłem to 10 listopada 2026 roku, wysyłając zapytania o stronę główną videolan.org z różnymi nagłówkami User-Agent:

User-Agent	Kod odpowiedzi
Przeglądarka (Chrome)	200
Googlebot	200
GPTBot (OpenAI)	418
PerplexityBot	418

Kod 418 dalej wychodzi z serwera, tylko trafia teraz do wybranych botów AI, podczas gdy Googlebot i zwykła przeglądarka dostają 200. Serwis SaaS Link Building sprawdził wcześniej więcej botów i dostał podobny wynik. Moje zapytania szły z adresu IP spoza Google, więc nie wiem, co dokładnie widział prawdziwy Googlebot w czasie problemu.

Podejrzewam, że reguła, która miała odcinać boty AI, przez jakiś czas łapała też Google. VideoLAN ani Google tego nie potwierdzili, ale tak dziś często blokuje się boty AI: w WAF, w CDN albo w konfiguracji serwera, a nie tylko w robots.txt. Wpis w robots.txt to prośba, którą robot najwyżej zignoruje, natomiast reguła w WAF od razu odsyła mu kod błędu, więc jedno złe dopasowanie wystarczy, żeby Googlebot dostał 4xx. Różnice między tymi podejściami opisałem w artykule o botach AI i robotach wyszukiwarek.

Co mówi dokumentacja Google o kodach 4xx

Strona Google o tym, jak kody HTTP wpływają na roboty, nie przewiduje żadnych wyjątków:

Google nie używa treści z adresów zwracających 4xx. URL, który wcześniej był używany, a teraz zwraca 4xx, „z czasem” przestaje być używany. Dokumentacja nie podaje żadnego terminu.
W Google Search adresy zwracające 4xx nie są indeksowane, a te już zaindeksowane są usuwane z indeksu.
Wszystkie błędy 4xx poza 429 są traktowane tak samo: robot przekazuje dalej informację, że treść nie istnieje. Nowo napotkane strony 404 nie są przetwarzane, a częstotliwość odwiedzin stopniowo spada.
Kod 429 (zbyt wiele żądań) Google traktuje jak błąd serwera, czyli sygnał przeciążenia. Kodów 401 i 403 nie należy używać do ograniczania tempa crawlowania, bo nie mają na nie wpływu.

Dokumentacja zaznacza też, że opisuje około 20 najczęstszych kodów i pomija „bardziej egzotyczne, takie jak 418”. Z wypowiedzi Illyesa wiemy teraz, że 418 działa jak zwykłe 4xx. O ochronie ważnych URL-i dokumentacja nie wspomina wcale.

Przy kodach 5xx Google opisuje coś podobnego: zaindeksowane adresy zostają w indeksie, ale wypadają, jeśli błąd się utrzymuje. Różnica polega na tym, że zasadę dla 5xx Google zapisało w dokumentacji, a o ochronie wybranych adresów z 4xx wiemy tylko z jednego komentarza Illyesa.

Wnioski dla SEO technicznego

Na ochronę lepiej nie liczyć

Obejmuje URL-e, które Google uznaje za ważne, a kryteriów tej „ważności” nikt nie zna. Sklep, blog czy firma lokalna raczej się do nich nie łapią. Przypadek VLC pokazuje, jak Google traktuje jedną z najpopularniejszych stron w sieci, i niewiele mówi o tym, co stałoby się z Twoim adresem.

Okno na naprawę istnieje, ale nie wiadomo, jak długie

Ważna podstrona może zacząć przypadkiem zwracać 4xx po zmianie reguł WAF albo po wdrożeniu i wtedy liczy się szybkość reakcji. Część adresów może przez jakiś czas zostać w wynikach w gorszej formie, ale Google nie podało żadnych liczb, więc nie zakładam „bezpiecznego” terminu.

Pozycja może się trzymać, a ruch spadać

Chroniony URL zachowuje miejsce w wynikach, więc narzędzie do śledzenia pozycji problemu nie pokaże. Wynik bez opisu i favicony mniej zachęca do kliknięcia, dlatego przy ważnych stronach warto obok pozycji śledzić CTR i kliknięcia w Search Console.

Jak sprawdzić, skąd zniknęła favicona

Jeśli przy ważnej stronie w wynikach został sam link i tytuł, trzeba sprawdzić, jaki kod odpowiedzi dostaje robot:

Inspekcja adresu URL w Search Console i test wersji opublikowanej pokazują, co widzi Googlebot.
Logi serwera i CDN ujawniają kody, których nie widać w przeglądarce, np. 418 albo 403 wysyłane tylko części ruchu.
W regułach WAF i ochrony antybotowej trzeba przejrzeć dopasowania po User-Agent. Jeśli blokujesz boty AI, upewnij się, że reguła nie obejmuje Googlebota ani Googlebot-Image, który pobiera faviconę.

Czego nie wiemy

Illyes napisał „tymczasowo” i „od razu”, ale nie podał, jak długo ochrona trwa. Nie wiadomo też, po czym Google poznaje, że URL jest ważny, ani czy ochrona dotyczy każdego kodu 4xx, bo przykład dotyczy 418, a Illyes mówił ogólnie o 4xx. Nie wiemy wreszcie, czy to nowy mechanizm, czy stary, którego Google dotąd nie opisało. Komentarz wyjaśnia jeden przypadek i niczego nie zapowiada.

Podsumowanie

Google może na krótko zatrzymać w indeksie ważny adres, który zaczął zwracać błąd 4xx, żeby ludzie nadal go znajdowali. Płaci się za to gorszym wynikiem, bo bez treści z serwera Google nie pokaże opisu ani favicony, tylko link i ostatni znany tytuł. URL-e z trwałym błędem 4xx nadal są usuwane z indeksu.

Przypadek VLC pokazuje też, skąd takie błędy się biorą: serwer, który dziś odpowiada kodem 418 botom AI, przez jakiś czas odpowiadał nim także Google. Jeśli blokujesz boty AI w WAF albo na serwerze, sprawdź, czy reguła nie łapie Googlebota, i pilnuj kodów odpowiedzi ważnych stron.

Często zadawane pytania

Czy Google usuwa z indeksu stronę, która zwraca błąd 4xx?

Tak. Według dokumentacji Google adresy zwracające 4xx nie są indeksowane, a te już zaindeksowane są z czasem usuwane. Gary Illyes dodał, że w przypadku ważnych URL-i usunięcie może się opóźnić, bo Google tymczasowo je chroni.

Jak długo Google chroni ważny URL zwracający 4xx?

Nie wiadomo. Illyes mówił o ochronie „tymczasowej” i nie podał terminów ani kryteriów, według których strona jest uznawana za ważną. Nie należy zakładać, że ochrona obejmie Twoją stronę.

Dlaczego strona VLC straciła faviconę w wynikach Google?

Według Illyesa serwer zwracał kod 418. Google potraktowało go jak błąd 4xx, więc nie miało treści strony i nie mogło pokazać opisu ani favicony. Po powrocie do kodu 200 wynik powinien się odświeżyć.

Czy kod 429 działa tak samo jak pozostałe błędy 4xx?

Nie. Według dokumentacji Google kod 429 jest traktowany jak błąd serwera, czyli sygnał przeciążenia, i spowalnia crawlowanie. Pozostałe kody 4xx oznaczają dla Google, że treść nie istnieje.

Czy blokada botów AI może zaszkodzić widoczności w Google?

Tak, jeśli reguła w WAF, CDN lub na serwerze obejmie też Googlebota. Wtedy robot Google dostaje błąd 4xx, a strona traci opis i faviconę w wynikach albo wypada z indeksu. Reguły dopasowane po User-Agent trzeba testować także dla Googlebota i Googlebot-Image.

Co zrobić, gdy ważna strona zwraca błędny kod 4xx?

Jak najszybciej przywrócić kod 200 z właściwą treścią, a następnie sprawdzić adres w Search Console. Warto też przejrzeć logi serwera, CDN i reguły WAF, bo błędny kod bywa efektem konfiguracji, a nie samej aplikacji.