Crawlery AI w logach serwera – jak sprawdzić, czy ChatGPT, Claude i Perplexity odwiedzają Twoją stronę?

Crawlery AI nie zawsze są widoczne w Google Analytics, ale zostawiają ślad w logach serwera. To właśnie tam można sprawdzić, czy stronę odwiedzają boty OpenAI, Anthropic, Perplexity i innych systemów AI, jakie adresy URL pobierają, z jakich IP korzystają oraz czy ich aktywność nie obciąża infrastruktury. Dla działań GEO i technicznego SEO analiza logów staje się jednym z najprostszych sposobów na ocenę, czy treści są realnie dostępne dla asystentów AI.

Największy błąd polega dziś na traktowaniu wszystkich botów AI tak samo. Część z nich służy do trenowania modeli, część do wyszukiwania i cytowania treści w odpowiedziach, a część działa dopiero wtedy, gdy użytkownik wklei konkretny adres URL do czatu. Blokada jednego typu bota może chronić treści przed wykorzystaniem treningowym, a blokada innego może ograniczyć widoczność strony w odpowiedziach AI.

Dlaczego logi serwera są ważniejsze niż GA4 przy analizie botów AI?

Google Analytics, Matomo czy inne klasyczne narzędzia analityczne mierzą przede wszystkim zachowanie użytkowników, którzy uruchamiają kod śledzący w przeglądarce. Crawlery AI działają inaczej: pobierają zasób z serwera, często bez ładowania JavaScriptu, bez sesji użytkownika i bez standardowego zdarzenia analitycznego. W efekcie mogą intensywnie odwiedzać stronę, ale w raportach ruchu pozostaną niewidoczne.

Logi serwera to techniczny zapis każdego żądania HTTP. W zależności od konfiguracji serwera zawierają m.in. datę, IP, metodę żądania, pobrany URL, kod odpowiedzi, rozmiar odpowiedzi, referer i nagłówek User-Agent. Ten ostatni pozwala wstępnie rozpoznać bota, np. GPTBot, OAI-SearchBot, ClaudeBot albo PerplexityBot.

Z perspektywy GEO logi odpowiadają na trzy praktyczne pytania:

• czy systemy AI w ogóle pobierają treści z domeny;
• które sekcje serwisu są odwiedzane najczęściej;
• czy serwer, CDN albo WAF nie blokuje botów, które w robots.txt teoretycznie mają dostęp.

To ostatnie jest szczególnie ważne. Strona może mieć poprawny robots.txt, a jednocześnie Cloudflare, Akamai, reguły firewalla albo limitowanie zapytań mogą zwracać botom błędy 403 lub 429. Z perspektywy widoczności w AI efekt jest podobny: crawler nie pobiera treści, więc model ma mniejszą szansę ją zacytować.

Jakie typy crawlerów AI warto rozróżniać?

W technicznym SEO najważniejsze jest rozdzielenie botów według celu działania, a nie tylko według właściciela. OpenAI, Anthropic i Perplexity używają różnych User-Agentów do różnych zadań. Dlatego ta sama domena może jednocześnie blokować bota treningowego i pozwalać botowi wyszukiwawczemu.

OpenAI

Anthropic

Perplexity

Takie rozróżnienie pokazuje, dlaczego ogólna komenda „zablokuj boty AI” jest zbyt szeroka. Jeżeli firma chce chronić treści przed trenowaniem modeli, a jednocześnie zachować szansę na cytowanie w odpowiedziach AI, lepszym rozwiązaniem jest osobna polityka dla botów treningowych i wyszukiwawczych.

Jak znaleźć crawlery AI w logach serwera?

Najprostsza analiza zaczyna się od pobrania surowych logów. W hostingu współdzielonym mogą być dostępne w panelu jako „Raw Access Logs”. Na serwerach z dostępem SSH typowe lokalizacje to:

/var/log/nginx/access.log
 /var/log/apache2/access.log

W pierwszym kroku wystarczy przefiltrować logi po najważniejszych User-Agentach:

grep „GPTBot” /var/log/nginx/access.log
 grep „OAI-SearchBot” /var/log/nginx/access.log
 grep „ClaudeBot” /var/log/nginx/access.log
 grep „Claude-SearchBot” /var/log/nginx/access.log
 grep „PerplexityBot” /var/log/nginx/access.log

Do szybkiego przeglądu kilku botów naraz można użyć:

egrep „GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot|Perplexity-User” /var/log/nginx/access.log

Przykładowy wpis w logu może wyglądać tak:

192.0.2.15 – – [04/Oct/2026:14:32:10 +0200] „GET /blog/geo-a-seo/ HTTP/1.1” 200 18492 „-” „Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot”

Sam User-Agent nie wystarcza jednak do ostatecznej weryfikacji. Każdy skrypt może podszyć się pod GPTBot lub ClaudeBot, dlatego po wstępnym filtrowaniu należy sprawdzić IP.

Jak zweryfikować, czy bot jest prawdziwy?

Weryfikacja autentyczności bota chroni przed spoofingiem, czyli fałszowaniem nagłówka User-Agent. Najprostszy wariant to Reverse DNS:

host 192.0.2.15

W przypadku OpenAI wynik powinien wskazywać domenę należącą do OpenAI, a następnie adres można dodatkowo porównać z oficjalnymi listami IP publikowanymi przez operatora. Analogicznie w przypadku Anthropic należy korzystać z aktualnej dokumentacji i list źródłowych, a przy Perplexity — z oficjalnych zakresów oraz obserwacji z warstwy CDN/WAF.

Dobre minimum audytowe wygląda następująco:

1. Wyciągnij wszystkie żądania z User-Agentami AI.
2. Zgrupuj je po IP, User-Agent, kodzie odpowiedzi i adresie URL.
3. Zweryfikuj IP dla najaktywniejszych botów.
4. Oznacz żądania jako prawdziwy bot, podejrzany bot albo nierozpoznany automat.
5. Sprawdź, czy boty otrzymują kody 200, czy wpadają w 403, 404, 429, 500, 502 lub 504.

Dopiero taki zestaw danych mówi, czy strona jest realnie dostępna dla crawlerów AI. Sam zapis w robots.txt nie pokazuje, czy bot rzeczywiście może pobrać HTML.

Jak interpretować aktywność crawlerów AI?

Pierwszy odruch często sprowadza się do pytania: „czy bot był na stronie?”. Lepsze pytanie brzmi: „co dokładnie pobrał i z jakim skutkiem?”. Sama obecność GPTBot albo ClaudeBot nie oznacza jeszcze, że strona będzie widoczna w odpowiedziach AI.

W logach należy ocenić kilka warstw:

Ważne jest także rozróżnienie intencji. Duży ruch GPTBot może oznaczać pobieranie treści do celów treningowych, ale nie musi przełożyć się na wejścia z ChatGPT. Z kolei aktywność OAI-SearchBot jest bliżej związana z wyszukiwaniem i widocznością w odpowiedziach ChatGPT Search.

Jak ustawić robots.txt bez utraty widoczności w AI?

Najbezpieczniejszy model to osobne reguły dla botów treningowych, wyszukiwawczych i wywoływanych przez użytkownika. Przykładowy schemat dla firmy, która chce zachować widoczność w odpowiedziach AI, ale ograniczyć udział treści w treningu modeli, może wyglądać tak:

# OpenAI – widoczność w ChatGPT Search
 User-agent: OAI-SearchBot
 Allow: /
 
 # OpenAI – ograniczenie treningu modeli
 User-agent: GPTBot
 Disallow: /
 
 # Anthropic – widoczność w wyszukiwaniu Claude
 User-agent: Claude-SearchBot
 Allow: /
 
 # Anthropic – ograniczenie treningu modeli
 User-agent: ClaudeBot
 Disallow: /
 
 # Perplexity – widoczność w odpowiedziach Perplexity
 User-agent: PerplexityBot
 Allow: /

To nie jest uniwersalny wzorzec dla każdej branży. Serwisy newsowe, bazy wiedzy, portale z płatnym dostępem i sklepy z unikalnymi danymi produktowymi mogą przyjąć bardziej restrykcyjną politykę. Firmy usługowe, B2B i e-commerce, którym zależy na cytowaniu przez AI, zwykle nie powinny blokować wszystkich botów jednym wpisem User-agent: * Disallow: /.

Konfigurację należy testować w praktyce. Po zmianie robots.txt sprawdź, czy boty nadal pobierają najważniejsze adresy URL i czy nie pojawiają się błędy po stronie CDN lub WAF. W wielu przypadkach problemem nie jest sam plik robots.txt, tylko dodatkowe zabezpieczenia, które blokują boty mimo deklarowanego Allow.

Jakie błędy najczęściej zniekształcają analizę logów?

Najczęstszy błąd to utożsamianie każdego User-Agenta z prawdziwym botem. Bez weryfikacji IP można pomylić oficjalnego crawlera z tanim scraperem podszywającym się pod znaną nazwę.

Drugi błąd to analiza zbyt krótkiego okresu. Jednodniowy wycinek logów może nie pokazać realnego wzorca, bo crawlery AI często działają falami. Do sensownej analizy przydaje się minimum 30 dni, a w większych serwisach lepiej porównywać miesiące.

Trzeci błąd to patrzenie wyłącznie na liczbę żądań. Jeżeli bot pobrał 500 URL-i, ale większość z nich zwróciła 404 albo 429, wniosek jest zupełnie inny niż przy 500 poprawnych odpowiedziach 200. Dla GEO ważniejsza jest jakość dostępu do najważniejszych treści niż sama skala crawlowania.

Czwarty błąd to blokowanie botów bez rozróżnienia celu. Zablokowanie bota treningowego i bota wyszukiwawczego ma inne skutki. Dla widoczności w AI najgroźniejsze jest przypadkowe odcięcie tych crawlerów, które odpowiadają za aktualne wyszukiwanie, cytowania i pobieranie stron na żądanie użytkownika.

Jak mierzyć skuteczność analizy logów pod GEO?

Analiza logów powinna kończyć się nie tylko listą botów, ale zestawem wskaźników do monitorowania. Dzięki temu da się ocenić, czy zmiany w robots.txt, WAF i strukturze strony poprawiają dostępność treści dla AI.

W praktyce najlepiej przygotować prosty arkusz: bot, typ bota, liczba żądań, liczba unikalnych URL-i, liczba błędów, najczęściej pobierane katalogi, najczęstsze IP, status weryfikacji i rekomendowana akcja.

Co zrobić po pierwszym audycie?

Po pierwszym przeglądzie logów zwykle pojawiają się trzy typy działań. Pierwszy dotyczy dostępności: poprawa błędów 4xx/5xx, udostępnienie ważnych treści w HTML, aktualizacja sitemap i upewnienie się, że crawlerzy nie trafiają tylko na przypadkowe adresy.

Drugi dotyczy kontroli: rozdzielenie botów w robots.txt, ustawienie limitów częstotliwości dla agresywnych crawlerów i weryfikacja reguł WAF. Nie każdą aktywność AI należy blokować, ale każdą warto mierzyć.

Trzeci dotyczy widoczności: porównanie logów z wynikami testów w ChatGPT, Claude i Perplexity. Jeżeli bot pobiera stronę, ale AI nie cytuje marki, problem może leżeć nie w crawlability, lecz w strukturze treści, autorytecie źródła lub braku zewnętrznych potwierdzeń.

Źródła

• OpenAI Developers, „Overview of OpenAI Crawlers”.
• Anthropic Help Center, „Does Anthropic crawl data from the web, and how can site owners block the crawler?”.
• Cloudflare Blog, „Perplexity is using stealth, undeclared crawlers to evade website no-crawl directives”.
• Cloudflare, dokumentacja Verified Bots i materiały dotyczące bot management.
• Dokumentacja i materiały techniczne dotyczące robots.txt.