Google Analytics pokaże ci ludzi. Search Console pokaże ci Googlebota. Żadne z tych narzędzi nie powie ci, ile razy w zeszłym tygodniu ClaudeBot pobrał twój cennik ani czy PerplexityBot w ogóle zna twoją stronę. Jedynym miejscem, w którym widać całą prawdę o botach AI, są surowe logi serwera. To one rejestrują każde żądanie HTTP, również te, które nie wykonują JavaScriptu i nigdy nie odpalą żadnego skryptu śledzącego.
Ten tekst jest praktycznym rozszerzeniem tematu, który opisaliśmy w przewodniku kontrola crawlerów AI w 2026. Tam chodziło o to, jak decydować, kto ma dostęp do twoich treści. Tutaj zajmujemy się warstwą niżej: jak sprawdzić, co naprawdę się dzieje, i jak zbudować monitoring, który sam się odzywa, gdy coś odbiega od normy.
Skąd wziąć logi na typowym hostingu i CDN
Punkt wyjścia jest banalnie prosty, ale to właśnie na nim wysypuje się większość projektów. Musisz wiedzieć, który element infrastruktury widzi ruch jako pierwszy, bo tylko jego logi są kompletne.
- Hosting współdzielony (cPanel, DirectAdmin): logi Apache lub LiteSpeed znajdziesz zwykle w katalogu
logs/lubaccess-logs/w katalogu domowym. Bywają rotowane co dobę i kasowane po kilku dniach, więc ustaw własny cron, który kopiuje je w bezpieczne miejsce. - VPS z Nginx: domyślnie
/var/log/nginx/access.log. Sprawdź konfiguracjęlog_format, bo standardowy format combined zawiera user agenta, a niektóre okrojone formaty już nie. - Cloudflare i inne CDN: tu pojawia się największa pułapka. Jeśli CDN serwuje treść z cache, żądanie nigdy nie dociera do serwera origin i w logach hostingu go nie zobaczysz. Potrzebujesz Logpush albo przynajmniej analityki po stronie CDN.
- WordPress za reverse proxy: upewnij się, że w logach nie masz wszędzie tego samego adresu IP proxy. Bez nagłówka
X-Forwarded-Forstracisz możliwość weryfikacji, kto naprawdę pukał.
Praktyczna zasada: zanim zbudujesz jakikolwiek raport, weź jeden dzień logów i porównaj liczbę żądań z liczbą odsłon w analityce. Jeśli logi pokazują trzykrotnie więcej, jesteś na dobrej drodze. Jeśli pokazują mniej, patrzysz na niewłaściwe źródło.
Parsowanie i klasyfikacja user agentów
Standardowy wiersz w formacie combined (opisanym w dokumentacji Apache HTTP Server) zawiera wszystko, czego potrzebujesz: adres IP, znacznik czasu, metodę i ścieżkę, kod odpowiedzi, rozmiar, referrer oraz user agenta. Klasyfikacja polega na dopasowaniu fragmentu user agenta do listy znanych crawlerów.
Nie zaczynaj od zera. Aktualne sygnatury zebraliśmy w osobnym zestawieniu: GPTBot, ClaudeBot, PerplexityBot i Google-Extended. Kluczowe jest jednak coś innego niż sama lista. Boty AI dzielą się na dwie kategorie o zupełnie różnym znaczeniu biznesowym, co szczegółowo tłumaczymy w tekście o tym, czym różni się crawler treningowy od bota pobierającego stronę na żywo.
Ta różnica musi być zaszyta w twoim modelu danych od pierwszego dnia. Minimalna klasyfikacja wygląda tak:
| Kategoria | Przykłady | Co oznacza wzrost |
|---|---|---|
| Wyszukiwarki klasyczne | Googlebot, Bingbot | Normalna indeksacja, pilnuj budżetu crawl |
| Crawlery treningowe AI | GPTBot, ClaudeBot, CCBot | Twoje treści trafiają do zbiorów uczących |
| Boty odpytujące na żywo | ChatGPT-User, Perplexity-User | Ktoś zadał pytanie i model sięga po twoją stronę teraz |
| Narzędzia SEO | AhrefsBot, SemrushBot | Zwykle konkurencja lub twoje własne audyty |
| Niesklasyfikowane | reszta | Worek do cotygodniowego przeglądu |
Worek „niesklasyfikowane” jest najważniejszą kolumną w całym raporcie. Nowe boty pojawiają się co kwartał, a jedyny sposób, by je wyłapać, to regularnie sortować nieznane user agenty malejąco po liczbie żądań i dopisywać te, które urosły.
Wskaźnik crawl to referral i jak go liczyć
Samo liczenie odwiedzin botów szybko robi się nudne i nic nie wnosi do decyzji biznesowych. Znacznie ciekawsze pytanie brzmi: czy z tego pobierania cokolwiek do ciebie wraca? Do tego służy wskaźnik crawl to referral.
Definicja jest prosta. W danym oknie czasowym (proponuję 7 dni) bierzesz liczbę żądań wykonanych przez boty jednego dostawcy i dzielisz ją przez liczbę sesji przychodzących z interfejsu tego samego dostawcy. Ruch odsyłający rozpoznasz po referrerze zawierającym chatgpt.com, perplexity.ai czy claude.ai.
Wynik czytasz następująco: 2000 oznacza, że na dwa tysiące pobranych stron przypada jedna realna wizyta człowieka. Wartość bezwzględna nie mówi wiele, bo różni dostawcy działają w innej skali. Liczy się kierunek zmian w czasie i porównanie dostawców między sobą. Rosnący mianownik przy stabilnym liczniku to dobra wiadomość: jesteś cytowany częściej. Rosnący licznik przy zerowym mianowniku przez kilka tygodni z rzędu oznacza, że ponosisz koszt transferu bez żadnego zwrotu.
Zanim jednak wyciągniesz z tego wniosek, że trzeba blokować, przeczytaj analizę tego, czy blokada botów AI szkodzi widoczności w Google. Decyzja bywa mniej oczywista, niż sugeruje sam rachunek kosztów.
Progi alertów: kiedy reagować
Alert, który odzywa się codziennie, przestaje być alertem po tygodniu. Dlatego progi ustawiaj względem własnej historii, nie względem okrągłych liczb wziętych z sufitu. Zbierz cztery tygodnie danych, policz medianę i odchylenie, dopiero potem definiuj reguły.
- Skok wolumenu: liczba żądań pojedynczego bota w ciągu doby przekracza trzykrotność mediany z ostatnich 28 dni. Reakcja: sprawdź, czy nie odkrył pętli w filtrach lub kalendarzu.
- Nowy bot z impetem: nieznany wcześniej user agent generuje ponad 500 żądań w dobę. Reakcja: zaklasyfikuj go i zdecyduj o dostępie.
- Wzrost odpowiedzi 5xx dla botów: udział błędów serwera w ruchu botów przekracza 2 procent. Reakcja: prawdopodobnie serwer się dławi, sprawdź obciążenie.
- Zanik ruchu: bot, który odwiedzał cię codziennie przez miesiąc, milczy od 72 godzin. Reakcja: sprawdź, czy ktoś nie zmienił robots.txt albo reguł WAF.
- Boty w strefach prywatnych: jakiekolwiek żądanie crawlera do koszyka, panelu klienta czy adresów z parametrami sesji. Reakcja: natychmiastowa, to wyciek adresów.
Ostatni próg jest jedynym, który zasługuje na powiadomienie w trybie natychmiastowym. Pozostałe spokojnie mogą trafiać do zbiorczego raportu porannego.
Wykrywanie podszywania się pod boty AI
User agent to zwykły ciąg znaków, który każdy może sobie wpisać. Scrapery notorycznie podszywają się pod GPTBota, licząc na to, że administrator przepuści taki ruch bez pytania. Weryfikacja opiera się na dwóch mechanizmach.
Pierwszy to odwrotne DNS. Bierzesz adres IP z logu, robisz zapytanie PTR, a otrzymaną nazwę hosta rozwiązujesz z powrotem na adres. Jeśli wynik zgadza się z wyjściowym IP, a nazwa należy do domeny dostawcy, żądanie jest autentyczne. Google opisuje tę procedurę w dokumentacji Google Search Central, a ta sama logika działa dla innych operatorów.
Drugi to oficjalne listy zakresów IP. OpenAI, Anthropic i Perplexity publikują pliki JSON z aktualnymi podsieciami swoich crawlerów. Pobieranie ich raz na dobę i porównywanie z logami jest tańsze obliczeniowo niż odwrotne DNS przy każdym wierszu.
Wynik weryfikacji zapisuj jako osobną kolumnę w danych, a nie jako filtr odrzucający wiersze. Liczba fałszywych żądań podszywających się pod boty AI jest sama w sobie ciekawym wskaźnikiem bezpieczeństwa i warto obserwować, jak rośnie.
Prosty dashboard z danych logowych
Nie potrzebujesz platformy klasy enterprise. Skrypt w Pythonie uruchamiany co godzinę z crona, wynik ładowany do SQLite lub zwykłego pliku Parquet, wizualizacja w Metabase albo w arkuszu. Cztery widoki wystarczą na start.
- Wolumen w czasie z podziałem na kategorie botów, w ujęciu dobowym za ostatnie 90 dni.
- Top 50 adresów URL pobieranych przez boty AI, zestawione z pozycją tych stron w twojej strukturze serwisu.
- Crawl to referral dla każdego dostawcy osobno, jako linia tygodniowa.
- Rozkład kodów odpowiedzi serwowanych botom. Jeśli widzisz tam masę odpowiedzi 404, boty krążą po nieistniejących adresach i marnują twoje zasoby.
Drugi widok zwykle bywa najbardziej pouczający. Bardzo często okazuje się, że crawlery AI z uporem pobierają archiwa tagów, strony paginacji i wyniki wyszukiwania wewnętrznego, czyli dokładnie te miejsca, na których cytowaniu w ogóle ci nie zależy.
Co zrobić, gdy jeden bot zjada zasoby serwera
Zdarza się, że pojedynczy crawler generuje więcej żądań niż cały ruch organiczny. Kolejność działań ma znaczenie, bo najmocniejsze narzędzia bywają nieodwracalne w skutkach.
Zacznij od dyrektywy Crawl-delay w pliku robots.txt, choć część botów ją ignoruje. Następnym krokiem jest ograniczenie przepustowości na poziomie serwera, na przykład modułem limit_req w Nginx, z osobną strefą dla znanych user agentów botów. Dopiero gdy to nie pomoże, sięgaj po odpowiedź 429 z nagłówkiem Retry-After, która jest poprawnym sygnałem „zwolnij”, a nie „wynoś się”.
Twarde blokowanie kodem 403 zostaw na koniec. Traktuj je jako decyzję strategiczną, a nie techniczną łatkę, i zapisz w dokumentacji datę oraz powód. Za pół roku nikt nie będzie pamiętał, dlaczego akurat ten bot wisi na czarnej liście, a treść, której nie widzą modele językowe, nie może zostać przez nie zacytowana.
FAQ
Czy do monitoringu botów AI wystarczy Google Analytics?
Nie. Boty nie wykonują JavaScriptu, więc w GA4 są praktycznie niewidoczne. Analityka pokaże ci najwyżej ruch odsyłający z interfejsów czatów, czyli mianownik wskaźnika crawl to referral. Licznik znajdziesz wyłącznie w logach serwera.
Jak długo trzymać logi, żeby monitoring miał sens?
Minimum 90 dni dla danych zagregowanych do poziomu godzinowego. Surowe wiersze wystarczy przechowywać 14 dni, potem można je skasować, zachowując same podsumowania. To wystarcza do liczenia median i wykrywania trendów sezonowych.
Czy blokowanie botów AI obniży moją widoczność w Google?
Google-Extended jest niezależny od Googlebota, więc jego blokada nie wpływa na indeksację w klasycznej wyszukiwarce. Wpływa natomiast na obecność treści w odpowiedziach generowanych przez AI. Szczegóły opisaliśmy w osobnej analizie poświęconej temu zagadnieniu.
Ile żądań na dobę to już nietypowa liczba?
Nie ma uniwersalnej wartości, bo wszystko zależy od wielkości serwisu. Bezpieczniejszym punktem odniesienia jest stosunek liczby żądań do liczby adresów URL w sitemapie. Jeśli bot pobiera jedną stronę więcej niż dwa razy dziennie, prawdopodobnie krąży po pętli.
Czy odwrotne DNS trzeba robić dla każdego wiersza logu?
Nie i nie warto. Wystarczy weryfikować unikalne adresy IP raz na dobę i cache’ować wynik. Przy typowym serwisie oznacza to kilkaset zapytań zamiast setek tysięcy.