Boty AI 2026: przewodnik po crawlerach i kontroli dostępu

Logi serwera wyglądają dziś inaczej niż trzy lata temu. Obok Googlebota i Bingbota przewijają się przez nie GPTBot, ClaudeBot, PerplexityBot, Amazonbot, Bytespider i kilkanaście mniej znanych nazw. Część z nich zbiera materiał do trenowania modeli, część pobiera stronę dopiero wtedy, gdy ktoś zadaje pytanie w czacie, a część nie deklaruje zamiarów w żaden czytelny sposób. Ten przewodnik porządkuje, kto odwiedza Twój serwis w 2026 roku i jak sterować jego dostępem bez odcinania się od wyszukiwarek.

Kto naprawdę odwiedza Twój serwer w 2026

Pierwszym krokiem nie jest blokowanie, lecz pomiar. Dopóki nie wiesz, jaki procent zapytań do Twojego serwera generują boty AI, każda decyzja o dostępie jest zgadywaniem. Najprostsza diagnostyka to agregacja pola user agent z logów access serwera za ostatnie 30 dni i policzenie liczby żądań oraz wolumenu transferu per bot. Na typowym serwisie treściowym o kilkuset podstronach rozkład wygląda z grubsza tak: Googlebot odpowiada za największy pojedynczy udział, dalej plasują się Bingbot i Applebot, a suma wszystkich crawlerów AI mieści się zazwyczaj w przedziale od kilku do kilkudziesięciu procent całego ruchu automatycznego. Im więcej publikujesz, tym wyższy ten udział.

Druga rzecz do sprawdzenia od razu: czy deklarowany user agent jest prawdziwy. Nazwa w logu to zwykły nagłówek HTTP, który każdy może sobie ustawić, i właśnie dlatego OpenAI, Anthropic, Perplexity oraz Google publikują zakresy adresów IP swoich crawlerów. Jeżeli widzisz w logach „GPTBot” z adresu poza oficjalną listą, patrzysz na scraper korzystający z cudzej reputacji. Weryfikacja przez odwrotne DNS lub dopasowanie do zakresów IP powinna poprzedzać każdą wdrażaną regułę.

Boty treningowe kontra boty odpowiadające na żywo

Najważniejszy podział w całym tym zestawieniu nie dotyczy właściciela bota, lecz momentu, w którym bot pobiera stronę. Boty treningowe crawlują szeroko i z wyprzedzeniem, żeby zasilić zbiór danych do uczenia modelu. Z takiego pobrania nie wynika dla Ciebie żadne bezpośrednie wyświetlenie ani cytowanie. Boty odpowiadające na żywo działają odwrotnie: uruchamiają się w chwili, gdy użytkownik zadaje pytanie, pobierają kilka adresów i to właśnie ich pobranie przekłada się na cytowanie z linkiem w odpowiedzi.

Trzecia kategoria to boty indeksujące dla wyszukiwarek AI. Siedzą pośrodku: crawlują z wyprzedzeniem jak boty treningowe, ale budują indeks obsługujący odpowiedzi na żywo. OAI-SearchBot i PerplexityBot należą do tej grupy. Zablokowanie ich jest w praktyce zablokowaniem sobie wejścia do wyników, więc decyzja o nich ma zupełnie inną wagę niż decyzja o crawlerze treningowym.

Ten podział ma konsekwencję praktyczną, którą łatwo przegapić. Jeżeli w robots.txt dopiszesz blokadę na wszystko, co ma w nazwie „AI”, z dużym prawdopodobieństwem odetniesz także warstwę, która przynosi ruch. Rozdzielenie treningu od wyszukiwania jest dziś realnie możliwe i to właśnie jego brak stoi za większością nieudanych wdrożeń. Opisaliśmy ten mechanizm szerzej przy okazji zmian w polityce Cloudflare wobec treningu modeli, gdzie dobrze widać, że jedna reguła nie wystarczy do opisania obu intencji.

Pełna lista user agentów i ich właścicieli

Poniższa tabela zbiera boty, które realnie pojawiają się w logach polskich serwisów. Kolumna „funkcja” mówi o deklarowanym przeznaczeniu, kolumna „wpływ na widoczność” o tym, czy zablokowanie bota może Cię kosztować wyświetlenia.

Dwie pozycje z tej tabeli bywają źródłem nieporozumień. Google-Extended i Applebot-Extended to nie crawlery, lecz tokeny sterujące, które wpisuje się do robots.txt. W logach ich nie zobaczysz, bo żadne żądanie nie przychodzi pod taką nazwą. Służą wyłącznie do zadeklarowania, że treść może być crawlowana przez wyszukiwarkę, ale nie ma być wykorzystana do trenowania modeli. Dokumentację obu tokenów warto czytać u źródła, bo zakres ich działania bywa korygowany; po stronie Google opisuje go dokumentacja crawlerów w Search Central, a po stronie OpenAI oficjalna strona botów z aktualnymi zakresami IP.

Blokada w robots.txt: co faktycznie działa

robots.txt pozostaje podstawowym narzędziem i w większości przypadków wystarczającym, ale trzeba rozumieć jego naturę. To deklaracja, nie zapora. Działa dokładnie tak długo, jak bot chce jej przestrzegać. Duzi dostawcy przestrzegają, bo mają interes w utrzymaniu relacji z wydawcami i są rozliczani publicznie za każdą wpadkę. Scrapery bez marki do stracenia nie przestrzegają wcale.

Plik czyta się od najbardziej specyficznego dopasowania user agenta, co oznacza, że blok dla konkretnej nazwy nadpisuje blok ogólny. Typowa poprawna konfiguracja, która odcina trening i zostawia otwartą warstwę odpowiedzi, wygląda tak:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Trzy błędy powtarzają się na tyle często, że warto je wymienić wprost. Pierwszy: wpisanie Disallow: / pod User-agent: * w nadziei, że dotknie to tylko botów AI. Dotknie wszystkich, włącznie z Googlebotem. Drugi: blokada crawlera przy jednoczesnym oczekiwaniu, że marka nadal będzie cytowana w danym silniku. Trzeci: przeniesienie reguł z innego serwisu bez sprawdzenia, czy nazwy user agentów są wciąż aktualne, bo dostawcy je zmieniają i rozdzielają. Pełny przegląd gotowych reguł wraz z uzasadnieniem każdej z nich zebraliśmy w osobnym materiale o tym, co blokować w robots.txt, a co wpuszczać.

Warto też wiedzieć, czego robots.txt nie potrafi. Nie wyraża intencji warunkowej w rodzaju „wpuść do wyszukiwania, nie używaj do treningu” inaczej niż przez osobne tokeny producenta. Propozycje standaryzacji tej warstwy, od nagłówka Content-Signal po prace grupy roboczej IETF nad preferencjami AI, są wciąż w toku i żadna z nich nie ma jeszcze statusu powszechnie respektowanego standardu. Na dziś jedyną pewną ścieżką są tokeny poszczególnych dostawców.

Blokada po stronie serwera i CDN

Jeżeli chcesz egzekwować decyzję, a nie tylko ją zadeklarować, reguła musi żyć warstwę niżej. Na poziomie serwera wystarcza dopasowanie user agenta i zwrócenie kodu 403, w Nginx przez dyrektywę if ($http_user_agent ~* "GPTBot|ClaudeBot|Bytespider"), w Apache przez RewriteCond na HTTP_USER_AGENT. Takie rozwiązanie jest tanie i natychmiastowe, ale ma oczywistą lukę: blokuje po nazwie, którą scraper może dowolnie zmienić.

Mocniejszy wariant to weryfikacja po adresie IP: pobierasz oficjalną listę zakresów dostawcy, odświeżasz ją cyklicznie i przepuszczasz tylko żądania z tych zakresów. To jedyna metoda, która realnie odsiewa podszywanie się, ale listy się zmieniają, więc ma sens głównie przy mierzalnym problemie wydajnościowym.

Najmniej pracochłonna opcja to warstwa CDN. Cloudflare, Fastly i Akamai mają gotowe kategorie botów AI z przełącznikiem w panelu, a część dostawców dorzuca rozliczanie dostępu per crawl. Przewaga nie leży w samej regule, lecz w sygnałach niedostępnych dla pojedynczego serwera: reputacji adresu, wzorcach zachowania, odciskach połączenia TLS. Dzięki temu CDN łapie także ruch bez rozpoznawalnej nazwy.

Niezależnie od wybranej warstwy pamiętaj o jednej rzeczy: zwracaj 403, nie 503. Kod 503 część crawlerów interpretuje jako chwilową awarię i wraca częściej, co podnosi obciążenie zamiast je obniżać.

Koszt otwarcia i koszt zamknięcia dostępu

Decyzja o dostępie to wybór między dwoma rodzajami kosztu, a nie między kosztem i jego brakiem.

Koszt otwarcia jest przede wszystkim infrastrukturalny. Crawlery AI potrafią pobierać agresywniej od wyszukiwarek, bo nie optymalizują budżetu crawlowania pod kątem świeżości indeksu. Na serwisie bez pamięci podręcznej strony każde żądanie uruchamia PHP i zapytania do bazy, więc kilkanaście tysięcy dodatkowych pobrań miesięcznie potrafi podnieść rachunek za hosting albo po prostu spowolnić serwis dla ludzi. Drugi składnik to utrata kontroli nad treścią, której nikt nie wyceni w złotówkach, ale która ma znaczenie przy materiałach kosztujących realną pracę redakcyjną.

Koszt zamknięcia jest widocznościowy i z reguły wyższy, niż wydaje się w momencie podejmowania decyzji. Jeżeli odetniesz warstwę odpowiadającą na żywo, Twoja marka przestaje się pojawiać w odpowiedziach silników, z których coraz większa część użytkowników startuje swoje poszukiwania. Odwrócenie tej decyzji nie działa natychmiast: od zdjęcia blokady do powrotu cytowań mijają tygodnie, bo indeks musi zostać odbudowany. Co gorsza, utraty nie zobaczysz w standardowych raportach, o czym pisaliśmy w analizie tego, czego Search Console nie pokazuje o widoczności w AI.

Osobna pozycja na liście kosztów to czas zmarnowany na pozorne rozwiązania. Plik llms.txt bywa przedstawiany jako sposób sterowania dostępem modeli, choć nim nie jest i nie jest też respektowanym sygnałem rankingowym. Sprawdziliśmy to na własnym serwisie w eksperymencie z llms.txt i cytowaniami w ChatGPT, z wynikiem, który nie pozostawia wątpliwości. Dodanie pliku nie zaszkodzi, ale nie zastępuje ani robots.txt, ani reguły na serwerze.

Jak zdecydować, co wpuścić na własnym serwisie

Nie ma jednej właściwej konfiguracji, bo koszt zamknięcia zależy od modelu biznesowego. Są natomiast trzy wzorce, które pokrywają większość realnych przypadków.

Serwis, który zarabia na ruchu i na byciu znajdowanym, powinien zostawić otwartą całą warstwę odpowiadającą na żywo i zamknąć wyłącznie boty czysto treningowe. Taka konfiguracja nic nie kosztuje w widoczności, a zdejmuje z serwera najagresywniejszy ruch. To domyślna rekomendacja dla blogów firmowych, serwisów usługowych i sklepów.

Wydawca, dla którego treść sama jest produktem, może pozwolić sobie na ostrzejszą politykę: blokada treningu plus negocjowany lub rozliczany dostęp dla pozostałych, najwygodniej przez CDN. Tu zamknięcie jest decyzją biznesową, nie techniczną.

Serwis z treścią wrażliwą albo objętą umowami powinien zacząć od blokady wszystkiego, co nie jest wyszukiwarką, i otwierać pojedyncze boty po świadomej decyzji. Warto wtedy oddzielić katalogi: otwarty blog, zamknięta część zasobowa.

Niezależnie od wzorca ustal właściciela tej decyzji i terminarz przeglądu. Lista user agentów zmienia się kilka razy w roku, a reguła nietknięta przez dwa lata blokuje dziś coś innego, niż zakładał jej autor. Kwartalny przegląd logów i porównanie z oficjalnymi listami dostawców to pół godziny pracy, która chroni przed cichą utratą kanału. Jeżeli obsługujesz tę warstwę dla klientów, wpisz ją wprost do zakresu usługi; jak to poukładać, rozkładamy na części w materiale o scope usług AIO dla agencji.

Najkrótsze podsumowanie

• Zacznij od logów, nie od reguł. Bez pomiaru nie wiesz, czy masz problem.
• Rozdziel boty treningowe od odpowiadających na żywo. To jedyny podział, który ma znaczenie dla widoczności.
• robots.txt wystarcza wobec dużych dostawców, nie wystarcza wobec scraperów.
• Weryfikuj po IP, jeśli blokada ma być egzekwowana, nie tylko zadeklarowana.
• Zwracaj 403, nigdy 503.
• Przeglądaj konfigurację co kwartał, bo nazwy user agentów się zmieniają.

FAQ