Jak boty AI crawlają Twoją stronę? Log file analysis dla GPTBot, GoogleOther i PerplexityBot

Pierwszy ślad zwykle nie pojawia się w panelu SEO. Pojawia się w access.log: dziwny user-agent, seria wejść na stare adresy, pobrania obrazów, PDF-ów, parametrów filtrowania, czasem nagły wzrost odpowiedzi 403, 404 albo 5xx. I dopiero wtedy zaczyna się właściwe pytanie: czy to Googlebot, bot AI do treningu modelu, crawler wyszukiwarki AI, czy fetcher uruchomiony przez realnego użytkownika?

To rozróżnienie ma znaczenie. Zablokowanie złego bota może odciąć stronę od widoczności w odpowiedziach AI. Zostawienie wszystkiego bez kontroli może przepalać transfer, obciążać serwer i zasypywać logi bezużytecznymi requestami. Crawl budget w klasycznym sensie dotyczy głównie Google Search, ale praktyczny problem jest szerszy: wszystkie boty konkurują o zasoby serwera, cache, limity aplikacji, transfer i uwagę zespołu technicznego.

Na czerwiec 2026 r. operatorzy crawlerów rozbijają swoje boty na coraz drobniejsze klasy. OpenAI oddziela m.in. GPTBot od OAI-SearchBot i ChatGPT-User, Perplexity opisuje osobno PerplexityBot i Perplexity-User, Anthropic rozdziela ClaudeBot, Claude-User i Claude-SearchBot, Apple ma Applebot oraz kontrolny token Applebot-Extended, a Google dokumentuje m.in. GoogleOther, GoogleOther-Image, GoogleOther-Video, Google-CloudVertexBot i Google-Extended. To nie są kosmetyczne różnice w nazwach. To różne konsekwencje dla indeksowania, treningu modeli, widoczności w AI search i obciążenia infrastruktury.

Nie każdy bot AI robi to samo: crawler, fetcher, indeks, trening

Najgorszy błąd w analizie logów to wrzucenie wszystkiego z frazą „bot” do jednego worka. Googlebot nie jest tym samym co GoogleOther. GPTBot nie jest tym samym co ChatGPT-User. PerplexityBot nie oznacza automatycznie treningu modelu. A Google-Extended i Applebot-Extended to w praktyce sygnały kontroli wykorzystania danych, a nie zwykłe crawlery chodzące po stronie jak klasyczny robot wyszukiwarki.

Najprościej podzielić ruch na pięć klas:

• crawlery wyszukiwarkowe — np. Googlebot, Googlebot-Image, Googlebot-Video, Applebot;
• crawlery AI search / discovery — np. OAI-SearchBot, PerplexityBot, Claude-SearchBot;
• boty treningowe lub sygnały kontroli treningu — np. GPTBot, ClaudeBot, Google-Extended, Applebot-Extended;
• fetchery użytkownika — np. ChatGPT-User, Perplexity-User, Claude-User;
• crawlery produktowe i techniczne — np. GoogleOther, GoogleOther-Image, GoogleOther-Video, Google-CloudVertexBot, Google-InspectionTool.

Różnica jest konkretna. OpenAI podaje, że GPTBot służy do pobierania treści, które mogą być użyte w treningu modeli, natomiast OAI-SearchBot odpowiada za pojawianie się stron w funkcjach wyszukiwania ChatGPT. ChatGPT-User działa przy akcjach inicjowanych przez użytkownika i nie jest automatycznym crawlerem sieci; sama dokumentacja zaznacza, że przy takich działaniach reguły robots.txt mogą nie mieć zastosowania.

Perplexity również rozdziela intencje. PerplexityBot ma surfować i linkować strony w wynikach Perplexity, a dokumentacja mówi wprost, że nie służy do crawlowania treści dla modeli bazowych. Perplexity-User obsługuje zapytania użytkowników i według dokumentacji generalnie ignoruje robots.txt, bo fetch został wywołany przez użytkownika. To jest ważny niuans przy audycie: blokada PerplexityBot nie rozwiązuje automatycznie wszystkich wizyt Perplexity w logach.

U Anthropic podział jest podobny, ale nazwy są inne. ClaudeBot dotyczy treści mogących trafić do przyszłych zbiorów treningowych, Claude-User obsługuje zapytania użytkowników Claude, a Claude-SearchBot indeksuje treści pod jakość wyników wyszukiwania. Anthropic deklaruje też obsługę niestandardowego Crawl-delay w robots.txt, co bywa przydatne przy serwerach, które nie padają, ale źle znoszą krótkie piki requestów.

Google jest osobnym przypadkiem, bo jego rodzina crawlerów miesza klasyczne SEO, usługi produktowe i mechanizmy AI. Googlebot wpływa na Google Search, Discover, Google Images, Google Video i inne funkcje wyszukiwarki. GoogleOther jest opisany jako ogólny crawler różnych zespołów produktowych Google do pobierania publicznie dostępnych treści, np. jednorazowych crawlów dla prac R&D. GoogleOther-Image i GoogleOther-Video są wariantami zoptymalizowanymi pod publicznie dostępne adresy obrazów i wideo, a Google-CloudVertexBot dotyczy crawlów zlecanych przez właścicieli stron przy budowie agentów Vertex AI — bez wpływu na Google Search.

Najbardziej zdradliwy jest Google-Extended. Nie ma osobnego user-agenta w requestach HTTP. To token w robots.txt, którym wydawca zarządza tym, czy treści crawlowane przez Google mogą być używane m.in. do trenowania przyszłych generacji modeli Gemini oraz do grounding w Gemini Apps i Vertex AI. Google podaje też wprost, że Google-Extended nie wpływa na obecność strony w Google Search ani nie jest sygnałem rankingowym.

W praktyce decyzja wygląda tak:

• chcesz być widoczny w Google Search — nie blokuj bez powodu Googlebota;
• chcesz być widoczny w ChatGPT search — nie blokuj bez powodu OAI-SearchBot;
• chcesz być widoczny w Perplexity — uważaj z blokadą PerplexityBot;
• nie chcesz wspierać treningu modeli — rozważ blokadę GPTBot, ClaudeBot, Google-Extended, Applebot-Extended;
• masz problem z obciążeniem — najpierw sprawdź konkretne ścieżki, statusy i typy plików, nie blokuj całych rodzin crawlerów w ciemno.

To ostatnie jest najważniejsze. Log file analysis nie służy do stworzenia najdłuższej listy banów. Służy do rozdzielenia ruchu, który przynosi widoczność, od ruchu, który zjada zasoby albo narusza politykę treści.

Logi serwera: jak policzyć realny koszt GPTBot, GoogleOther i PerplexityBot

Nie zaczynałbym od robots.txt. Zacząłbym od eksportu logów z ostatnich 14–30 dni. Jeden dzień potrafi kłamać: boty chodzą falami, niektóre wracają po deployu, inne po zmianie sitemap, a jeszcze inne wpadają na stare adresy po linkach z zewnętrznych źródeł. Przy dużym serwisie, e-commerce albo portalu z newsami minimum to tydzień, ale sensowniejszy obraz daje miesiąc.

W logach muszą znaleźć się pola, które pozwalają policzyć nie tylko „ile było wejść”, ale co dokładnie zostało pobrane:

• timestamp — godzina requestu;
• host — szczególnie przy wielu subdomenach;
• IP źródłowe i poprawnie ustawione real IP za CDN-em;
• user-agent;
• metoda HTTP;
• URL path i query string;
• status HTTP;
• liczba wysłanych bajtów;
• request time i najlepiej upstream response time;
• cache status, jeśli działa CDN lub reverse proxy;
• referer, choć przy botach często będzie pusty.

Dopiero wtedy filtrujesz user-agenty. Przykładowo:

zgrep -hE 'GPTBot|OAI-SearchBot|ChatGPT-User|PerplexityBot|Perplexity-User|ClaudeBot|Claude-User|Claude-SearchBot|Applebot|Googlebot|GoogleOther|Google-CloudVertexBot' /var/log/nginx/access.log* > boty-ai.log

Ten filtr jest tylko początkiem. User-agent można podszyć. Google w swojej dokumentacji ostrzega, że sam nagłówek HTTP user-agent może być spoofowany, a crawlerów Google należy weryfikować także po IP i reverse DNS. Apple opisuje identyfikację Applebota przez reverse DNS w domenie applebot.apple.com oraz przez publiczny plik CIDR. OpenAI i Perplexity publikują zakresy IP dla swoich botów.

W raporcie nie wystarczy kolumna „requests”. Dla każdego bota policzyłbym co najmniej:

• liczbę requestów;
• liczbę unikalnych URL-i;
• udział 2xx, 3xx, 4xx, 5xx;
• transfer w MB/GB;
• p95 czasu odpowiedzi;
• najczęściej pobierane katalogi;
• najczęściej pobierane parametry URL;
• udział plików ciężkich: PDF, obrazy, wideo, ZIP;
• udział requestów do robots.txt i sitemap;
• liczbę requestów z niezweryfikowanych IP przy znanym user-agencie.

Przykładowa tabela decyzyjna może wyglądać tak:

Najbardziej praktyczny wskaźnik to koszt jednej wartościowej wizyty bota. Nie ma tu oficjalnego cennika jak w reklamach. Koszt liczysz z własnej infrastruktury: transfer, CPU, cache miss, czas aplikacji, koszt log storage, alerty i ryzyko degradacji crawl capacity dla Google. Google podaje, że crawl capacity limit spada, gdy strona zwalnia albo zwraca błędy serwera; to jest miejsce, gdzie AI crawlery mogą pośrednio zaszkodzić SEO, nawet jeśli same nie „zużywają” Googlebotowego crawl budgetu.

Dla Google Search klasyczny crawl budget ma sens głównie przy dużych i często aktualizowanych serwisach. Google wskazuje orientacyjnie: duże strony z ponad 1 mln unikalnych stron i umiarkowanie częstymi zmianami, średnie lub większe serwisy z ponad 10 tys. unikalnych stron zmieniających się codziennie oraz witryny z dużą liczbą adresów „Discovered — currently not indexed”. Te liczby nie są twardymi progami, ale dobrze ustawiają priorytety. Mały blog z kilkudziesięcioma wpisami zwykle nie potrzebuje wielkiej operacji crawl-budgetowej. Sklep z filtrowaniem po kolorze, rozmiarze, cenie i sortowaniu — już tak.

W analizie logów szukałbym przede wszystkim czterech wzorców.

Pierwszy: boty chodzą po śmieciach parametrycznych. Jeżeli GPTBot, GoogleOther albo Googlebot pobierają tysiące adresów z ?sort=, ?filter=, ?session=, ?utm_, to problemem nie jest bot. Problemem jest wystawienie nieskończonej przestrzeni URL-i.

Drugi: boty pobierają ciężkie pliki bez sensu biznesowego. GoogleOther-Image i GoogleOther-Video są opisane jako warianty do publicznie dostępnych obrazów i wideo. Jeśli w logach widać masowe pobrania oryginalnych plików z /uploads/original/, a do publikacji używasz wersji zoptymalizowanych, to masz kandydatów do blokady ścieżkowej.

Trzeci: boty dostają 5xx. To nie jest tylko problem crawlera. To sygnał, że aplikacja, cache albo baza danych nie wytrzymuje. Dla Google wolne odpowiedzi i błędy serwera obniżają crawl capacity limit, więc naprawa 5xx ma wyższy priorytet niż dopisywanie kolejnego user-agenta do blokady.

Czwarty: blokada nie działa, bo bot nie jest tym botem. Jeśli widzisz user-agent Googlebot, ale IP nie przechodzi weryfikacji, to nie jest problem Googlebota. To problem podszywania się. Taki ruch obsługujesz regułami WAF, rate limitingiem i weryfikacją źródła, nie robots.txt.

Robots.txt, WAF i decyzja: co blokować, co zostawić, czego nie ruszać

Robots.txt jest dobrym narzędziem do zarządzania ruchem zgodnych botów. Nie jest zabezpieczeniem prywatnych danych. MDN słusznie ostrzega, że robots.txt nie powinien służyć do ukrywania wrażliwych ścieżek, bo plik jest publiczny i może wręcz podpowiedzieć atakującym, gdzie szukać.

Dlatego hierarchia decyzji powinna być taka:

1. Prywatne, płatne, poufne?
   Nie robots.txt, tylko logowanie, autoryzacja, paywall, kontrola sesji, ewentualnie WAF.
2. Publiczne, ale bez zgody na trening AI?
   Blokuj boty treningowe lub tokeny kontroli użycia danych: GPTBot, ClaudeBot, Google-Extended, Applebot-Extended.
3. Publiczne i chcesz widoczności w AI search?
   Nie blokuj automatycznie OAI-SearchBot, PerplexityBot, Claude-SearchBot.
4. Problemem jest koszt infrastruktury?
   Najpierw blokuj ścieżki niskiej wartości: parametry, sortowania, archiwa techniczne, oryginalne media, wyniki wyszukiwania wewnętrznego.
5. Problemem są fałszywe boty?
   Robots.txt nie pomoże. Potrzebujesz weryfikacji IP, reverse DNS, reguł WAF i limitów.

Przykładowa konfiguracja dla strony, która chce być widoczna w AI search, ale nie chce wspierać treningu modeli OpenAI:

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

To rozdzielenie ma sens, bo OpenAI opisuje te ustawienia jako niezależne: można pozwolić OAI-SearchBot, aby strona pojawiała się w wynikach ChatGPT search, i jednocześnie zablokować GPTBot, aby zasygnalizować brak zgody na użycie treści do treningu modeli bazowych. OpenAI podaje też, że dla wyników wyszukiwania dostosowanie do zmian w robots.txt może potrwać około 24 godzin.

Dla Google nie mieszałbym Googlebota z GoogleOther:

User-agent: Googlebot
Allow: /

User-agent: GoogleOther
Disallow: /search/
Disallow: /filter/
Disallow: /uploads/original/

User-agent: GoogleOther-Image
Disallow: /uploads/original/

User-agent: GoogleOther-Video
Disallow: /video/raw/

User-agent: Google-Extended
Disallow: /

To nie jest uniwersalna recepta. To przykład decyzji: zostawiamy Googlebot, ograniczamy GoogleOther na niskowartościowych lub kosztownych zasobach, a Google-Extended blokujemy, jeśli firma nie chce wykorzystania treści w opisanych przez Google zastosowaniach Gemini i grounding. Google dokumentuje też, że reguły dla GoogleOther, GoogleOther-Image i GoogleOther-Video nie wpływają na konkretny produkt tak jak Googlebot wpływa na Search.

Dla Anthropic można rozdzielić trening od wyszukiwania:

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Claude-User
Allow: /

Jeśli problemem jest tempo pobierania, Anthropic deklaruje obsługę niestandardowego Crawl-delay. Tego nie przenosiłbym bezmyślnie na Google, bo Google w swojej specyfikacji robots.txt wskazuje, że obsługuje user-agent, allow, disallow i sitemap, a inne pola, takie jak crawl-delay, nie są wspierane.

Dla Apple decyzja jest inna:

User-agent: Applebot
Allow: /

User-agent: Applebot-Extended
Disallow: /

Apple podaje, że Applebot zasila m.in. wyszukiwanie w Spotlight, Siri i Safari, a Applebot-Extended pozwala wydawcom odmówić wykorzystania treści do treningu modeli Apple. Co ważne: Applebot-Extended nie crawluje stron samodzielnie; jest używany do określenia, jak można wykorzystać dane zebrane przez Applebota.

Technicznie trzeba też uważać na błędy w samym robots.txt. Google traktuje większość błędów 4xx dla robots.txt — poza 429 — tak, jakby poprawny plik robots.txt nie istniał, czyli zakłada brak ograniczeń. Przy błędach 5xx Google najpierw wstrzymuje crawling na 12 godzin, potem może przez 30 dni używać ostatniej dobrej wersji, a plik robots.txt zwykle cache’uje do 24 godzin. Plik musi być UTF-8, a Google egzekwuje limit rozmiaru 500 KiB. To są parametry, które w dużych serwisach potrafią zdecydować, czy blokada faktycznie działa.

WAF jest potrzebny, ale nie jako młotek do wszystkiego. Perplexity zaleca przy konfiguracji WAF łączenie warunku user-agent z zakresem IP z oficjalnych endpointów, a nie samo dopasowanie nazwy bota. To rozsądna zasada dla wszystkich większych botów: nazwa w user-agencie bez weryfikacji źródła jest tylko deklaracją.

Jest jeszcze jedna pułapka. Anthropic ostrzega, że blokowanie adresów IP zamiast ustawienia robots.txt może nie dawać trwałego opt-outu, bo crawler musi być w stanie przeczytać robots.txt. Czyli: jeśli chcesz zrezygnować z crawlowania przez zgodnego operatora, ustaw robots.txt. Jeśli widzisz podszywanie, abuse albo ignorowanie zasad — dopiero wtedy wchodzą WAF, rate limiting, challenge i blokady sieciowe.

Najrozsądniejsza kolejność wdrożenia jest prosta:

• najpierw mapa botów z logów;
• potem weryfikacja IP / reverse DNS;
• potem raport kosztu: requesty, URL-e, transfer, statusy, p95 czasu odpowiedzi;
• potem blokady ścieżkowe dla śmieciowych URL-i;
• dopiero na końcu globalne blokady user-agentów.

Jeżeli trzeba zacząć od jednej rzeczy, zacząłbym od znalezienia botów generujących 5xx i chodzących po parametrach. To najszybciej odcina realny problem: nie dyskusję o AI, tylko marnowanie zasobów na adresach, których nikt nie powinien crawlować.

FAQ: najczęstsze pytania o boty AI i log file analysis

Czy blokada GPTBot blokuje widoczność strony w ChatGPT search?
Nie musi. OpenAI rozdziela GPTBot od OAI-SearchBot: pierwszy dotyczy treści mogących służyć do treningu modeli, drugi odpowiada za pojawianie się stron w funkcjach wyszukiwania ChatGPT. Jeśli chcesz ograniczyć trening, ale zachować szansę na widoczność, blokuj GPTBot, a nie OAI-SearchBot.

Czy GoogleOther to po prostu Googlebot pod inną nazwą?
Nie. Googlebot wpływa na Google Search i powiązane powierzchnie, a GoogleOther jest ogólnym crawlerem używanym przez różne zespoły Google do pobierania publicznie dostępnych treści, np. dla prac badawczo-rozwojowych. Blokada GoogleOther nie jest tym samym co blokada Googlebota.

Czy robots.txt wystarczy do ochrony treści przed AI?
Do sygnalizowania preferencji zgodnym crawlerom — tak. Do ochrony prywatnych lub płatnych treści — nie. Dla takich zasobów potrzebna jest autoryzacja, paywall, kontrola dostępu i konfiguracja serwera, bo robots.txt jest publiczny i nie stanowi zabezpieczenia.

Jak szybko zobaczę efekt zmiany w robots.txt?
Nie od razu. OpenAI i Perplexity wskazują, że dostosowanie systemów do zmian może potrwać do około 24 godzin, a Google zwykle cache’uje robots.txt do 24 godzin, z wyjątkami przy błędach lub problemach z odświeżeniem pliku. W praktyce sprawdzaj logi po 24, 48 i 72 godzinach, a pełniejszy obraz oceniaj po tygodniu.

Od czego zacząć, jeśli nie mam jeszcze żadnego procesu?
Wyciągnij logi z 30 dni i zrób pierwszy raport dla: Googlebot, GoogleOther, GPTBot, OAI-SearchBot, PerplexityBot, Perplexity-User, ClaudeBot, Claude-SearchBot i Applebot. Najpierw usuń 5xx, pętle parametrów, ciężkie pliki bez wartości i fałszywe boty podszywające się pod znane user-agenty. Globalne blokady zostaw na koniec — po danych, nie przed nimi.