OpenAI przyznaje: robots.txt może nie obowiązywać bota ChatGPT-User

OpenAI otwarcie zapisało w swojej dokumentacji, że reguły z pliku robots.txt mogą nie obowiązywać bota ChatGPT-User, ponieważ jego wizyty inicjuje człowiek, a nie automatyczny harmonogram indeksowania. Sprawę nagłośnił 14 sierpnia serwis Search Engine Journal, opierając się na aktualnej dokumentacji crawlerów OpenAI oraz na danych z raportu TollBit za pierwsze półrocze 2026 roku. Dla wydawców to nie jest niuans techniczny, tylko potwierdzenie, że wiersz Disallow przestał być twardą granicą, a stał się grzecznościową prośbą.

Problem jest tym poważniejszy, że większość redakcji i sklepów wciąż traktuje robots.txt jak zamek w drzwiach. Tymczasem w ekosystemie asystentów AI powstała trzecia kategoria ruchu, która nie mieści się ani w definicji crawlera treningowego, ani w definicji robota wyszukiwarki. To pobranie strony na wyraźne żądanie użytkownika, i właśnie ta kategoria rozjeżdża się z protokołem, który powstał w 1994 roku.

Kontekst: OpenAI ma trzy boty, a wydawcy blokują je hurtem

Największym źródłem nieporozumień jest to, że OpenAI nie korzysta z jednego robota. W oficjalnej dokumentacji firmy figurują trzy osobne role, z zupełnie różnymi konsekwencjami dla widoczności. GPTBot pobiera treści na potrzeby trenowania modeli. OAI-SearchBot buduje indeks, z którego ChatGPT korzysta przy odpowiadaniu na zapytania, czyli decyduje o tym, czy dana domena w ogóle ma szansę pojawić się w wynikach ChatGPT Search. ChatGPT-User działa natomiast wtedy, gdy konkretna osoba wkleja adres URL do czatu albo prosi asystenta o streszczenie strony.

I to właśnie przy trzecim agencie OpenAI dopisało zastrzeżenie. W dokumentacji pada stwierdzenie, że skoro te działania są inicjowane przez użytkownika, reguły robots.txt mogą nie mieć zastosowania. Innymi słowy: firma nie deklaruje, że plik zignoruje w każdej sytuacji, ale wprost odmawia zobowiązania się do jego przestrzegania w tym trybie.

Konsekwencja praktyczna jest paradoksalna. Wydawca, który w panice wpisuje do robots.txt blokadę wszystkich agentów OpenAI, najczęściej skutecznie odcina tylko ten bot, który realnie przynosi mu widoczność, czyli OAI-SearchBot. Bot, którego chciał zatrzymać, i tak może pobrać stronę, bo poprosił o to człowiek.

Kluczowe fakty: kto co robi i co daje blokada

Ten podział jest sednem sprawy. Trzy boty jednej firmy realizują trzy różne cele biznesowe, a jedyne narzędzie, jakie standard daje wydawcy, to jeden plik tekstowy z listą nazw. Nic dziwnego, że w praktyce wychodzi z tego bałagan. Pisaliśmy już o bliźniaczym przypadku po stronie Google, gdy nowy fetcher asystenta zaczął pobierać strony poza logiką klasycznego indeksowania: NotebookLM jako Gemini Notebook i fetcher omijający robots.txt.

Dlaczego trzydziestoletni protokół przestał wystarczać

Robots Exclusion Protocol powstał w 1994 roku i przez większość swojego istnienia rozwiązywał jeden konkretny problem: jak powiedzieć robotowi wyszukiwarki, żeby nie obciążał serwera pobieraniem katalogów, które i tak nikogo nie interesują. Cała jego konstrukcja zakłada, że po drugiej stronie jest automat działający w pętli, bez udziału człowieka, i że ten automat ma jeden cel, czyli zbudowanie indeksu.

Żadne z tych założeń nie opisuje agenta AI działającego na polecenie użytkownika. Nie ma pętli, jest pojedyncze żądanie. Nie ma indeksowania, jest jednorazowe streszczenie. Nie ma też prostej odpowiedzi na pytanie, czy po drugiej stronie stoi maszyna, czy człowiek posługujący się maszyną. Protokół nie przewiduje pola, w którym agent mógłby zadeklarować cel pobrania, więc wydawca nie ma jak napisać reguły w rodzaju „pobieraj na żądanie użytkownika, ale nie zbieraj do trenowania”.

Do tego dochodzi kwestia egzekwowalności. Robots.txt nigdy nie miał żadnego mechanizmu weryfikacji. Serwer wystawia plik, a to, czy ktokolwiek go przeczyta i posłucha, zależy wyłącznie od dobrej woli po drugiej stronie. Przez dwie dekady ta konwencja działała, bo lista istotnych graczy była krótka, a złamanie jej groziło poważnym kosztem reputacyjnym. Dziś aktywnych agentów są dziesiątki, część z nich nie przedstawia się wcale albo podszywa pod przeglądarkę, a incydenty rozmywają się w szumie. Konwencja oparta na wstydzie przestaje działać, gdy anonimowość jest tania.

Skala zjawiska: dane TollBit za pierwsze półrocze 2026

Deklaracje w dokumentacji to jedno, a logi serwerowe to drugie. Raport TollBit „State of the Bots” za pierwsze półrocze 2026 roku pokazuje, jak często agenci AI faktycznie sięgają po zasoby oznaczone jako zabronione. Na europejskich witrynach objętych badaniem około 15 procent zidentyfikowanych pobierających agentów AI dotarło do adresów URL wprost wykluczonych w robots.txt.

Rozkład nie jest równomierny. ChatGPT-User, Bytespider oraz Youbot pobierały zablokowane podstrony na blisko połowie tych europejskich serwisów, które wymieniły je z nazwy w swoim pliku. Czyli dokładnie tam, gdzie wydawca zadał sobie trud wpisania konkretnej reguły, ta reguła w połowie przypadków nie zadziałała.

Różnica między kontynentami jest wymowna. Europejscy wydawcy blokują agentów AI dwa do trzech razy rzadziej niż amerykańscy, mimo że to właśnie w Europie obowiązuje najostrzejsze prawo autorskie wobec eksploracji tekstów i danych. Można to czytać na dwa sposoby: albo europejskie redakcje wciąż nie uznały tematu za priorytet, albo świadomie nie chcą ryzykować utraty ruchu odsyłającego z asystentów. Obie interpretacje prowadzą do tego samego wniosku: robots.txt nie jest tu narzędziem, na którym da się oprzeć strategię.

Co to znaczy dla SEO i AIO

Pierwszy wniosek jest brutalnie prosty. Jeżeli chcesz naprawdę zablokować pobieranie treści, robots.txt nie wystarcza. Trzeba zejść na poziom serwera lub CDN i egzekwować politykę przez weryfikację adresów IP, podpisy agentów, reguły WAF albo rate limiting. Plik tekstowy komunikuje intencję, ale niczego nie wymusza.

Drugi wniosek dotyczy widoczności i jest znacznie mniej oczywisty. Blokada ChatGPT-User nie chroni treści, a blokada OAI-SearchBot kosztuje obecność w ChatGPT Search. To najgorszy możliwy układ dla kogoś, kto działa po omacku i wpisuje do pliku wszystko, co ma w nazwie „GPT”. Efekt jest taki, że treść dalej trafia do odpowiedzi asystenta, ale domena znika z listy cytowanych źródeł, więc nie dostaje nawet ruchu odsyłającego w zamian.

Trzeci wniosek dotyczy pomiaru. Skoro część pobrań odbywa się poza logiką klasycznego crawlera, standardowa analityka ich nie pokaże, a raporty indeksowania w Search Console nic o nich nie powiedzą. Jedynym rzetelnym źródłem prawdy zostają surowe logi serwera i narzędzia mierzące relację między pobraniami a wizytami. O tym, jak wygląda ten bilans w praktyce, pisaliśmy przy okazji nowych raportów Microsoftu: Clarity liczy, ile AI bierze i ile oddaje.

Praktyczna kolejność działań

• Rozdziel reguły dla GPTBot, OAI-SearchBot i ChatGPT-User zamiast stosować jedną blokadę zbiorczą. To trzy różne decyzje biznesowe.
• Zostaw OAI-SearchBot odblokowany, jeśli zależy Ci na cytowaniach i ruchu z ChatGPT Search. Blokada tego bota to dobrowolna rezygnacja z kanału.
• Zdecyduj świadomie w sprawie GPTBot. Tu blokada działa i realnie ogranicza wykorzystanie treści w trenowaniu, bez kosztu w widoczności.
• Jeżeli ChatGPT-User ma być zatrzymany, przenieś egzekucję na warstwę CDN lub WAF. Wpis w robots.txt potraktuj jako deklarację, nie jako zabezpieczenie.
• Zacznij logować ruch po nazwie agenta. Bez własnych danych każda dyskusja o skali pobrań opiera się na cudzych raportach.
• Sprawdź, czy Twoje ustawienia na poziomie CDN nie zmienią się automatycznie 15 września. Domyślne polityki dostawców właśnie się przestawiają.

Reakcje branży

W środowisku SEO dominuje ton zmęczonej rezygnacji, a nie oburzenia. Argument OpenAI, że pobranie na wyraźne polecenie użytkownika nie jest indeksowaniem, ma logiczne podstawy. Gdy człowiek wkleja adres do przeglądarki, robots.txt też nie obowiązuje, bo protokół nigdy nie miał regulować zachowania ludzi. Pytanie brzmi, czy asystent działający w imieniu użytkownika jest przedłużeniem przeglądarki, czy raczej nowym pośrednikiem, który zbiera przy okazji dane dla siebie.

Perplexity od dawna zajmuje w tej sprawie najbardziej otwarte stanowisko i zasadniczo pomija robots.txt przy żądaniach inicjowanych przez użytkownika. Na drugim biegunie stoi Anthropic, które deklaruje, że wszystkie trzy jego boty respektują plik bez wyjątków. OpenAI zajęło pozycję pośrednią, i to właśnie ta niejednoznaczność irytuje wydawców najbardziej. Sformułowanie „może nie obowiązywać” nie daje się przełożyć na żadną konkretną politykę po stronie serwisu.

Na polskim rynku temat ma dodatkowy wymiar. Krajowe redakcje i sklepy w większości korzystają z gotowych konfiguracji robots.txt dostarczonych przez wtyczki SEO albo agencje, a te pliki bywają nieaktualizowane od lat. W praktyce oznacza to dwie skrajności: albo brak jakichkolwiek reguł dla agentów AI, albo skopiowana z zagranicznego bloga blokada zbiorcza, która odcina OAI-SearchBot i zamyka drogę do cytowań w ChatGPT. Żadna z tych opcji nie jest decyzją, obie są przypadkiem.

Pojawia się też argument, że cała dyskusja jest spóźniona o dwa lata. Robots.txt nigdy nie był mechanizmem egzekwowalnym, tylko konwencją opartą na dobrej woli. Działał, dopóki liczba istotnych graczy była mała, a koszt złamania konwencji reputacyjnie wysoki. Przy kilkudziesięciu agentach, z których część nawet się nie przedstawia, ta równowaga po prostu przestała się utrzymywać.

Cloudflare zmienia domyślne ustawienia od 15 września

Do tej układanki dochodzi ruch największego dostawcy CDN. Cloudflare zapowiedział, że od 15 września na stronach wyświetlających reklamy będzie domyślnie blokować crawlery treningowe oraz agentowe, przepuszczając wyłącznie roboty wyszukiwarek. Boty o mieszanym przeznaczeniu, które nie zadeklarują, w jakiej roli występują w danym żądaniu, mają być na takich stronach blokowane w całości.

Dla milionów serwisów na darmowym planie oraz dla wszystkich nowych rejestracji po tej dacie blokada będzie włączona domyślnie, a odblokowanie wymaga świadomej akcji właściciela. Dotychczasowi klienci płatni zachowują możliwość nadpisania reguł z poziomu panelu. Szerzej o zmianie modelu Cloudflare wobec botów AI pisaliśmy tutaj: Cloudflare kończy z Pay Per Crawl.

To pokazuje, w którą stronę idzie cały rynek. Skoro deklaratywny protokół nie działa, kontrola przenosi się na warstwę infrastruktury, gdzie egzekucja jest techniczna, a nie grzecznościowa. Wydawca przestaje prosić i zaczyna filtrować. Cena tej zmiany jest jednak realna: im szczelniejsza brama, tym większe ryzyko przypadkowego odcięcia botów, które przynoszą cytowania i kliknięcia.

Co dalej

Najbliższe tygodnie zdecydują o tym, czy branża wypracuje standard następcy robots.txt, czy utrwali się model, w którym każdy dostawca CDN definiuje własne reguły. Trwają prace nad rozszerzeniami protokołu pozwalającymi rozróżnić cel pobrania, ale żadne z nich nie ma jeszcze statusu powszechnie wdrożonego. Do tego czasu obowiązuje układ hybrydowy: robots.txt jako sygnał intencji, warstwa serwerowa jako faktyczne egzekwowanie.

Dla polskich wydawców praktyczny priorytet na sierpień i wrzesień jest jasny. Po pierwsze, audyt aktualnego robots.txt pod kątem tego, czy przypadkiem nie blokuje OAI-SearchBot razem z całą resztą. Po drugie, sprawdzenie ustawień AI w panelu CDN przed 15 września, żeby nowa domyślna polityka nie zaskoczyła nikogo spadkiem cytowań. Po trzecie, uruchomienie logowania ruchu agentów, bo bez własnych liczb każda decyzja w tym obszarze będzie oparta na przeczuciu.

Najważniejsze jest jednak przestawienie sposobu myślenia. Pytanie nie brzmi już „jak zablokować AI”, tylko „które pobrania chcę wymienić na widoczność, a które chcę zatrzymać”. Przy trzech botach jednej firmy, z których każdy realizuje inny cel, odpowiedź zbiorcza zawsze będzie błędna.