# Dwanaście kategorii botów: jak czytać ruch automatów w portfelu

> W pierwszych trzydziestu godzinach pomiaru 85% żądań do witryn wysłały automaty, a większość podpisywała się jak zwykła przeglądarka. Opisujemy taksonomię dwunastu kategorii, weryfikację rDNS, wersjonowanie reguł i to, co z ruchu botów raportować klientowi.

Opublikowano: 2026-09-11 · Aktualizacja: 2026-09-16
Źródło: https://kompasfirm.pl/kartografia/klasyfikacja-botow-w-portfelu

---
Pierwsze trzydzieści godzin pomiaru ruchu na witrynach platformy dało 8557 żądań, z których 85% wysłały automaty, a 72% wszystkich żądań skończyło się kodem 404. Najciekawsza lekcja nie leży jednak w proporcjach, tylko w tym, jak łatwo o błędną klasyfikację: znacząca część automatów podpisywała się jako zwykły Chrome i dopiero analiza zachowania, nie podpisu, odsłoniła skanery. Ten materiał opisuje taksonomię, którą stosujemy, jej mechanizmy weryfikacji i sposób przełożenia ruchu botów na raport dla klienta.

## Taksonomia: dwanaście kategorii zamiast worka „boty"

Każde żądanie dostaje przy zapisie jedną z dwunastu kategorii:

- **regular_browser**: ruch wyglądający na zwykłą przeglądarkę; jedyna pula, w której mieszczą się ludzie,
- **search_crawler**: roboty indeksujące wyszukiwarek (Google, Bing, Seznam, Yandex, DuckDuckGo),
- **ai_training_crawler**: roboty zbierające treść do trenowania modeli,
- **ai_search_crawler**: roboty wyszukiwania AI, pobierające strony pod odpowiedzi asystentów,
- **ai_user_agent**: asystent działający na żądanie konkretnego użytkownika,
- **seo_crawler**: crawlery narzędzi SEO,
- **social_preview**: generatory podglądów linków z komunikatorów i portali,
- **monitoring**: automaty sprawdzające dostępność,
- **http_client**: biblioteki programistyczne przyznające się do bycia biblioteką,
- **headless_browser**: przeglądarki bez interfejsu,
- **security_scanner**: automaty odpytujące znane ścieżki podatności,
- **unknown_automation**: automat bez dopasowanej reguły.

Rozdzielenie trzech kategorii AI nie jest pedanterią. Trening, indeks odpowiedzi i wizyta na żądanie użytkownika to trzy różne zjawiska o różnej wartości dla klienta: pierwsza buduje obecność w „wiedzy" modeli, druga w cytowaniach, trzecia oznacza, że ktoś właśnie o klienta zapytał. W raporcie każda zasługuje na osobne zdanie.

## Weryfikacja: podpis to deklaracja, nie dowód

Rdzeń klasyfikatora to reguły dopasowujące deklarowaną tożsamość, ale dla robotów, których obecność raportujemy jako wartość (wyszukiwarki, najwięksi operatorzy AI), sama deklaracja nie wystarcza: żądanie przechodzi **weryfikację wstecznym DNS**, potwierdzającą, że przyszło z infrastruktury deklarowanego operatora. W tabelach i na wykresach rozdzielamy wizyty zweryfikowane od niezweryfikowanych, a wskaźniki takie jak pokrycie crawlem liczymy wyłącznie na zweryfikowanych.

Druga warstwa działa w przeciwną stronę: zdejmuje wiarygodność podpisom przeglądarek. Automat podpisany jako Chrome, którego zachowanie odpowiada sondowaniu podatności, jest klasyfikowany po tym zachowaniu. Wniosek z pierwszej doby pomiaru był jednoznaczny: **bez tej warstwy kategoria „przeglądarka" byłaby w większości skanerami**, a każdy wskaźnik liczony na „ludziach" byłby fikcją. Szczegółowych progów tej heurystyki celowo nie publikujemy.

## Wersjonowanie reguł: prawo do zmiany zdania

Reguły klasyfikacji mają numer wersji zapisywany przy każdym żądaniu. Gdy reguły się poprawiają, komenda reklasyfikacji przelicza historię wstecz i podnosi wersję, a agregaty są przebudowywane. Dwie zasady tego procesu okazały się ważniejsze, niż początkowo sądziliśmy:

- **reklasyfikacja może degradować, nie awansować**: automat może zostać przeklasyfikowany na inną kategorię automatu, ale nigdy z powrotem na przeglądarkę, bo do tej decyzji brakuje już pełnego kontekstu żądania,
- **wskaźniki okresowe wymagają pokrycia historią**: wniosek „pokrycie crawlem spadło" wolno sformułować tylko wtedy, gdy pomiar obejmuje cały porównywany okres; ósma godzina zbierania danych nie uprawnia do zdań o tygodniu.

Obie zasady weszły do systemu po realnych pomyłkach pierwszych dni i obie są rodzajem pokory wobec danych, którą warto przenieść także do raportów pisanych ręcznie.

## Dlaczego inne narzędzia pokazują inne liczby

Pytanie, które pada w każdym raporcie: „a w statystykach hostingu mam trzy razy więcej". Trzy źródła liczą trzy różne rzeczy. Statystyki hostingu liczą żądania bez klasyfikacji, więc zawierają wszystkie dwanaście kategorii naraz. Narzędzia w przeglądarce (GA4 i podobne) widzą tylko to, co wykona skrypt: skanery i większość robotów nie wykonują skryptów, więc ich tam nie ma, ale nie ma też ludzi, którzy odrzucili zgodę. Moduł platformy liczy ludzi po zgodzie (i mówi wprost, że niedoszacowuje), automaty serwerowo w pełni, a zapytania serwerowo i kompletnie. Jeśli klient porównuje liczby między narzędziami, jedyną wspólną jednostką są zapytania; reszta wymaga zdania o tym, co dane narzędzie w ogóle widzi.

## Co z ruchu botów raportować klientowi

Propozycja czterech zdań, które da się postawić na danych z modułu:

1. **Obecność w wyszukiwarkach**: „stronę regularnie odwiedza zweryfikowany Googlebot i Bingbot, crawl obejmuje podstrony ofertowe". Brak takiego zdania to zadanie techniczne, nie ozdoba raportu.
2. **Higiena crawlu**: „zmarnowany crawl utrzymuje się nisko, robot nie traci budżetu na błędy". Wskaźnik liczony na zweryfikowanych robotach indeksujących, więc odporny na szum skanerów.
3. **Obecność w obiegu AI**: „stronę pobierały roboty OpenAI, Anthropic i Apple". Względy na przyszłość cytowań; kontekst rynkowy tych proporcji opisuje [Cloudflare w danych o crawlu AI](https://blog.cloudflare.com/ai-search-crawl-refer-ratio-on-radar/).
4. **Szum odfiltrowany**: „większość ruchu automatów to skanery, które nie mają na tej platformie czego szukać i nie wchodzą do żadnych statystyk wyników". Jedno zdanie, które uprzedza pytanie klienta o „dziwne wejścia" z innych narzędzi.

Czego nie raportować: sumy „ruchu botów" jako zagrożenia. Skanery są tłem internetu, a ich blokowanie na ślepo bywa kosztowne, bo łatwo zablokować przy okazji robota, na którym klientowi zależy. Wersję tego argumentu dla właścicieli firm utrzymujemy na blogu głównym, we wpisie o [udziale botów w ruchu stron](/blog/ile-ruchu-na-stronie-firmowej-to-boty); do raportów agencyjnych można z niego linkować bez obaw o żargon.