20 procent wszystkich odpowiedzi „OK” z sieci otrzymywanych przez AI nie jest w porządku

Moje niedawne eksperymenty ze skrobaniem stron internetowych wspomaganym przez AI uświadomiły mi, jak bardzo sieć staje się coraz bardziej „zamknięta”. Oczywiście impulsem do tego odwrotu jest gwałtowny wzrost skrobania stron internetowych przez AI, którego nieustanne zapotrzebowanie na nowe dane może doprowadzić do wyłączenia domen.

To dobry pretekst, by domeny zrobiły to, co wiele z nich chciało zrobić od dawna: udostępniały treści tylko zalogowanym użytkownikom (choć, rzecz jasna, Googlebot zwykle ma wolną rękę). Facebook zakończył stopniowe wdrażanie tej polityki w 2023 roku, a Twitter/X zrobił to samo w tym samym roku. Reddit przyjmie ją jeszcze w tym miesiącu.

Dzięki temu domenie łatwiej spełnić wymogi dotyczące egzekwowania ograniczeń wiekowych obowiązujących w poszczególnych krajach, ponieważ użytkownik jest już zarejestrowany. Co ważniejsze, dane użytkownika można zachować, wykorzystywać do lokalnej analityki, a także — jeśli pozwalają na to lokalne przepisy — sprzedawać brokerom danych i firmom zajmującym się AI.

Gdzie indziej środki ukierunkowane na ochronę przed botami (a nie na rejestrowanie użytkowników) odnotowały wzrost o ponad 58% rok do roku, według Cloudflare. Nasilająca się aktywność botów naturalnie skłania strony internetowe do dokładniejszego sprawdzania adresów VPN i serwerów proxy, co może pozbawić dostępu legalnych użytkowników, podobnie jak każdego „złośliwego” ruchu.

Anegdotycznie rzecz ujmując, mam wrażenie, że coraz częściej trafiam na odpowiedzi blokujące lub testy weryfikacyjne — do tego stopnia, że zdarza mi się nawet porzucić stronę, gdy zaczyna je wyświetlać. Skoro wiadomo, że ściany CAPTCHA zniechęcają użytkowników i potencjalnych klientów, można sobie wyobrazić presję, która skłania właścicieli domen do ich wdrażania mimo tej wady.

Test CAPTCHA ze strony archive.is, jednej z wielu witryn, które stosują testy weryfikacyjne, często w reakcji na nadmierną liczbę zautomatyzowanych (a nie wykonywanych przez ludzi) żądań.

Wszystkie te nowe i nasilające się utrudnienia mają częściowo charakter logistyczny (bo nie każda domena jest w stanie wytrzymać napór), ale często są też rodzajem taktyki negocjacyjnej, mającej sprawdzić, czy firmy zajmujące się AI zaoferują pojedynczą lub zbiorową formę wynagrodzenia za wszystkie te dane, których tak desperacko pragną, a które aż do teraz przez tak długi czas były dostępne za darmo.

Ponieważ roboty indeksujące AI muszą działać na dużą skalę, zwykle korzystają z bezinterfejsowych instancji Chrome w ramach platformy Playwright. Obecnie w przypadku coraz większej liczby domen kończy się to błędem 403 („zabronione”) (czyli: serwer wie, że ruch jest zautomatyzowany, i każe mu się wynosić):

Lokalna instalacja changedetection.io próbuje odpytywać witrynę, ale witryna nie akceptuje wykrytej przeglądarki używanej przez platformę i zwraca odpowiedź 403 („Zabronione”).

Oczekiwana jest odpowiedź klienta „200” („OK”), nawet jeśli trzeba za nią zapłacić fortunę farmie mieszkaniowych serwerów proxy i zastosować przy tym różne inne podstępne metody nieoparte na działaniach człowieka.

Nie ma nic lepszego niż odpowiedź 200; innymi słowy, żaden kod odpowiedzi klienta nie niesie bardziej pozytywnego sygnału. Nie jest to też odpowiedź niejednoznaczna: nigdy nie oznacza „prawie w porządku”, „będzie w porządku później” ani „jest coraz bardziej w porządku” — oznacza „w porządku!”. Jeśli coś nie jest w porządku, nie jest to odpowiedź 200.

Witaj! Wynoś się

Jednak według nowego artykułu naukowego ten brak szczegółowości może znacząco zniekształcać zbiory danych AI, oszacowania statystyczne oraz raportowanie statusu „dobry” w sytuacjach, gdy wcale tak nie jest.

Badanie* szacuje, że około jedna piąta odpowiedzi z kategorii 200 w ogóle nie zawiera użytecznej treści strony, lecz zamiast niej zwraca puste struktury witryn, testy CAPTCHA, ograniczenia dostępu lub strony zastępcze.

W artykule stwierdzono:

„20,9% stron, które klient statyczny otrzymuje ze statusem 200, nie zawiera głównej treści strony: są to struktury aplikacji, testy dla botów, strony blokujące, strony błędów i zastępcze oraz treści częściowe”.

W efekcie niecierpliwe systemy zautomatyzowane wpadają w pułapkę własnej prostoty, ponieważ odpowiedź „200” można uznać za pomyślne pobranie, nawet jeśli w jego wyniku pojawia się jedynie ściana CAPTCHA, paywall lub inna przeszkoda.

W artykule opisano siedem rodzajów treści, które często komplikują interpretację odpowiedzi 200:

Siedem kategorii treści, które w odpowiedzi 200 zdecydowanie nie oznaczają, że wszystko jest „w porządku”. Źródło

Na potrzeby badania przez trzy dni testowano 10 307 adresów internetowych za pomocą zarówno podstawowego programu pobierającego strony, jak i przeglądarki obsługującej JavaScript. Odpowiedzi klasyfikowano na podstawie pobranej treści, a nie kodów statusu HTTP.

Największymi kategoriami „bezużytecznych” odpowiedzi 202 były puste szkielety stron internetowych oraz strony błędów lub zastępcze, które łącznie odpowiadały za ponad dwie trzecie niepowodzeń.

W przypadku pustych szkieletów stron witryna może wyświetlać menu i nawigację, pozostawiając pusty artykuł lub wykaz produktów, o który poproszono; w tym drugim przypadku zamiast żądanej treści może pojawić się niezwiązana strona lub strona główna. Oba przypadki mogą jednak otrzymać ten sam status HTTP 200 co udane pobranie użytecznej i wartościowej treści.

Jako rozwiązanie problemu w artykule zaleca się, by narzędzia pobierające strony informowały o tym, co faktycznie zostało pobrane, zamiast polegać na kodach statusu HTTP. Proste kontrole pozwalające wykryć nietypowo krótkie strony, podejrzane przekierowania i treści przypominające strony, które nie istnieją, mogłyby bowiem wskazać większość niepowodzeń.

Bardziej zasobożerne narzędzia przeglądarkowe można by wtedy uruchamiać tylko wtedy, gdy wygląda na to, że strona nie załadowała się prawidłowo. Ponadto w ramach oceniania systemów AI można by sprawdzać, czy cytowane źródła rzeczywiście zawierają oczekiwane informacje, zamiast zakładać, że odpowiedź HTTP 200 oznacza pomyślne pobranie treści.

Autor nowego opracowania zauważa również, że „proste heurystyki” mogą bez trudu wykryć około 86% bezużytecznych odpowiedzi, wykorzystując podstawowe kontrole długości strony, przekierowań i podobieństwa do stron, które nie istnieją:

Porównanie strategii pobierania stron: renderowanie tylko stron oznaczonych jako podejrzane pozwoliło odzyskać nieco więcej użytecznej treści (81,4%) niż renderowanie każdej strony (80,3%), a jednocześnie skróciło średni czas pobierania jednej strony z 20,6 do 5,8 sekundy. 

Dlaczego tak wiele odpowiedzi 200 jest błędnych?

W społecznościach programistów od lat toczy się pewna dyskusja na temat tego, czy błąd 202 („Zaakceptowano” – „Żądanie zaakceptowano, ale nie zostało jeszcze zrealizowane”) mógłby pomóc rozróżnić te „nieudane” żądania ze statusem 200. W rzeczywistości jednak kod 202 nie obejmuje wszystkich przypadków opisanych w nowym artykule, a żaden istniejący kod nie jest w stanie tego zrobić.

Choć artykuł nie omawia tej kwestii szczegółowo, powody, dla których właściciele domen dopuszczają błędy 200, mogą zasługiwać na dalsze badania w przyszłych pracach poświęconych temu tematowi.

Jednym z powodów może być to, że każdy status inny niż 200 oznacza w istocie jakiś rodzaj strony błędu lub przeszkodę, w tym najczęstsze błędy 404 („nie znaleziono”) – występujące wtedy, gdy żądana treść po prostu nie istnieje. Niektórzy uważają, że nadmiar takich błędów prowadzi do kar w SEO (i przypuszczalnie w GEO), choć Google zaprzecza, by tak było.

Google uznaje błędne odpowiedzi 200 za „miękkie” błędy 404. Wyraźnie mogą one być uznawane za większy problem niż zwykłe błędy 404, ponieważ są w istocie „zwodniczymi” odpowiedziami, niezależnie od tego, czy pojawiają się celowo.

Dryf cytowań

Jeśli wszystko to wydaje się czepianiem szczegółów, warto wziąć pod uwagę petabajtową skalę danych rutynowo gromadzonych (lub których zgromadzenie jest podejmowane) na potrzeby trenowania AI. Jeśli pełna jedna piąta tych danych jest niewiarygodna lub wręcz wprowadza w błąd, trudno zbyć dalsze konsekwencje jako swego rodzaju „błąd uboczny”. Takie fałszywe odpowiedzi mogą bowiem znacząco i niekorzystnie wpływać na rozkład danych w zbiorach oraz na wyniki trenowania modeli AI na tych danych.

Jednym z istotnych problemów związanych z błędnymi odpowiedziami 200 jest na przykład „dryf cytowań”: wygenerowana przez AI odpowiedź przestaje być poparta stroną internetową, która pierwotnie została przytoczona jako dowód. Strona mogła się zmienić, odpowiedni tekst mógł zostać usunięty albo link może teraz prowadzić gdzie indziej.

Nowe badanie wykazało, że pozorny dryf cytowań wzrósł z 5,8% do 21,9%, gdy wszystkie odpowiedzi HTTP 200 uznawano za udane pobrania, niezależnie od zawartej w nich treści.

Oznacza to, że można błędnie uznać, iż źródło się zmieniło, zniknęło lub przestało potwierdzać twierdzenie wygenerowane przez AI, tylko dlatego, że zamiast pierwotnego materiału pobrano stronę z testem CAPTCHA, pustą stronę lub inną przeszkodę.

Wystarczy powiedzieć, że tak jest!

Problem potwierdziły również testy z użyciem celowo nieistniejących adresów internetowych. Gdy w witrynach żądano losowych, wymyślonych ścieżek, 13,1% tych, które odpowiedziały, zwróciło status 200 („OK”), mimo że żądane strony nie istniały^†.

„13,1% witryn, które odpowiedziały na próbę z losową ścieżką, zwróciło status 200 (S1: 10,5%, S2: 13,3%, S3: 17,3%, S4: 13,7%, S5: 13,1%). Każda taka odpowiedź z definicji jest miękkim błędem 404, ale nie każda o tym informuje.

„W eksploracyjnej analizie 172 miękkich błędów 404 osoba klasyfikująca uznała 98 za błąd lub stronę zastępczą, 32 za powłokę, a 28 za treść: strona główna lub wykaz udostępnione pod losową ścieżką wyglądają jak zwykła strona”.

Wnioski

Gdyby problem został rozpoznany na wyższym poziomie, IANA mogłaby ewentualnie utworzyć nowy, bardziej odpowiedni kod statusu HTTP, na przykład [X] („Żądanie zakończyło się powodzeniem, ale żądana treść nie została dostarczona”). Choć taki kod rzeczywiście opisywałby to, co się dzieje, wymagałby oczywiście nieprawdopodobnie dużego wglądu w transakcję po stronie hosta.

Podobne kody już istnieją, ale żaden nie pasuje do końca: 451 („Niedostępny z powodów prawnych”) jest niejednoznaczny i dość alarmujący (!); 206 („Częściowa treść”) jest technicznie trafny, ale przeznaczony dla niekompletnych danych (pobrań); a zaskakująco istniejący kod 203 („Informacje nieautorytatywne”), utworzony w 1997 roku, ma jedynie peryferyjny związek z omawianym przypadkiem.

Być może najbliżej pasuje kod o nieintuicyjnej nazwie: 103 („Wczesne wskazówki”), który informuje, że nie wszystkie zasoby danego adresu URL zostały jeszcze załadowane (choć byłaby to oczywiście całkowicie błędna interpretacja zamierzonego znaczenia tego kodu).

* „Kiedy 200 OK nie jest odpowiedzią: ciche niepowodzenia pobierania podczas agentycznego pozyskiwania treści z sieci”. Warto pamiętać, że artykuł został napisany najwyraźniej przede wszystkim z myślą o odczycie maszynowym, być może w celu przeszukiwania przez AI, i sam w sobie niełatwo się go czyta.

^† Wybaczcie mechaniczny cytat, ale cały artykuł jest napisany w ten sposób, jak wspominam wyżej, z myślą o „czytelności maszynowej”, a nie zrozumiałości dla człowieka, choć nie przedstawiono go w formacie JSON.

Opublikowano po raz pierwszy w środę, 4 listopada 2026 r.