Boty w e-commerce — od scraperów cen po AI crawlery, których Cloudflare nie zatrzymuje

Przez ostatnie kilka lat charakter botów, z którymi mam do czynienia przy sklepach, zmienił się wyraźnie. Pierwszy raz problem był prosty: bot cenowy walił w stronę tak mocno, że hosting padał. Teraz coraz częściej trafiam na ruch, który Cloudflare przepuszcza bez mrugnięcia — bo bot jawnie deklaruje się jako AI crawler, albo odwrotnie: nic nie mówi, ma normalny fingerprint przeglądarki i przychodzi przez residential proxy.

Kilka przypadków z praktyki i sposoby na rozpoznanie.

---

Przypadek 1: bot cenowy, który ubił sklep

Custom CMS, kilkanaście tysięcy SKU. Pewnego dnia strona zaczyna się sypać — hosting ledwo reaguje, panel admina nieresponsywny, 503 wszędzie. Wchodzę w logi.

Jeden user agent, jeden zakres IP z ASN dużego dostawcy chmurowego, równomierny rytm — około 100 żądań na sekundę. Bot odpytywał strony produktowe i kategorie bez żadnego ograniczania się, bez backoffu. Nie wiedział albo nie obchodziło go, że po drugiej stronie jest PHP z bazą i cache, które przy takim wolumenie nie wyrabiają.

Charakterystyki tego ruchu

• user agent wprost deklarujący scraper lub agregator,
• stały, metronomiczny rytm żądań — nic ludzkiego,
• wszystkie IP z jednego ASN chmurowego,
• brak cookies, brak wykonywania JS,
• wyłącznie GET na produkty i kategorie — formularzy nie tyka.

Co zadziałało

Rate limiting po ASN i blokada user agenta w Cloudflare. Na przyszłość: cache na poziomie serwera, żeby nawet gdy bot wpadnie, dostawał statyczną odpowiedź zamiast dobijać się do PHP i bazy.

---

Powtarzający się problem: AI crawlery i boty, których Cloudflare nie wychwytuje

Ten wzorzec widziałem kilka razy — na różnych sklepach, w różnych odstępach czasu, z różnym natężeniem. Za każdym razem trochę inaczej wyglądał na powierzchni, ale mechanizm był ten sam. I za każdym razem standardowe reguły WAF nie zareagowały.

Wariant A: boty, które otwarcie przyznają, że są AI

Część z nich jest uczciwa — GPTBot, ClaudeBot, Amazonbot, meta-externalagent, Bytespider i dziesiątki innych jawnie deklarują w user agencie, że zbierają dane treningowe. Problem w tym, że nawet te „grzeczne” często ignorują robots.txt, nie szanują Crawl-delay i potrafią wygenerować wolumen obciążający serwer — szczególnie na sklepach z dużą liczbą podstron.

Identyfikacja jest prosta (user agent), blokada też. Reguła w Cloudflare WAF albo odpowiednie wpisy w robots.txt dla tych, którzy go respektują. Ale to coraz mniejsza część problemu.

Wariant B: boty podszywające się pod przeglądarki

Tu zaczynają się schody. Na przestrzeni czasu trafiałem na ten wzorzec kilka razy, za każdym razem na innym sklepie i z innym natężeniem — raz był to wyraźny, skupiony atak przez kilka godzin, innym razem ciągły, niski szum przez tygodnie, który zauważyłem dopiero przy analizie logów przy okazji czegoś innego.

Wspólny mianownik wyglądał tak:

• normalny TLS fingerprint — nie odróżnisz od Chrome,
• wykonuje JavaScript, obsługuje cookies, przechodzi przez Cloudflare challenge bez problemów,
• IP z residential proxy — geolokalizacja wskazuje Polskę albo Niemcy, operator lokalny ISP, nic podejrzanego,
• niska częstotliwość na jeden IP (kilka–kilkanaście req/min), ale za nimi stoi pool setek ruchomych adresów,
• łączny wolumen znaczący, rozłożony tak, że reguły per-IP w ogóle nie reagują.

Jeden z tych przypadków był szczególnie uciążliwy: konkretne IP waliło tak systematycznie, że musiałem je zablokować ręcznie — Cloudflare z włączonym interactive challenge nie zareagował. Ruch miał fingerprint normalnej przeglądarki, ale timing i wzorzec nawigacji były wyraźnie maszynowe. Po ręcznej blokadzie w ciągu kilku minut pojawiały się kolejne IP z tego samego ASN. Klasyczny objaw operatora z rotującą pulą adresów.

W innym przypadku natężenie było dużo niższe — kilkanaście requestów na godzinę z dziesiątek różnych adresów — ale wzorzec był identyczny: zawsze te same endpointy, zawsze bez zasobów towarzyszących, bez śladu ludzkiej nawigacji.

Jak to rozpoznać, gdy WAF milczy

Sygnały, które dają informację nawet przy residential proxy i headless browser:

• Wzorzec nawigacji — tylko bezpośrednie URL-e do produktów lub endpointów API, zero ścieżek charakterystycznych dla człowieka (strona główna → kategoria → produkt). Człowiek błądzi, bot idzie prosto do celu.
• Timing — regularny, przewidywalny interwał między żądaniami w ramach sesji. Człowiek ma nieregularny rytm, bot ma scheduler.
• Brak zasobów towarzyszących — normalny użytkownik ściąga HTML, CSS, JS, fonty, obrazki. Bot często bierze tylko HTML albo tylko endpoint API.
• Nagłówki Accept-Language i pochodne — headless w domyślnej konfiguracji ma charakterystyczne wartości; nowoczesne boty je podrabiają, ale nie zawsze bezbłędnie.
• Honeypot links — niewidoczny link w HTML, ukryty przez CSS. Jeśli ktoś go odpytuje, to nie człowiek.
• Proporcja zasobów — stosunek żądań text/html do żądań CSS/JS/obrazków znacznie poniżej normy to sygnał.
• Rotacja IP przy tym samym zachowaniu — ten sam user agent, różne IP, identyczny wzorzec requestów. Agregacja po user agencie, nie po IP, to od razu pokazuje.

Dlaczego Cloudflare tego nie zatrzymuje

Heurystyki Cloudflare opierają się na sygnałach, które zaawansowane boty coraz skuteczniej imitują: TLS fingerprint, wykonywanie JavaScript, obsługa cookies, ludzkie pozory timingu. Residential proxy to dodatkowy problem — IP wygląda jak prawdziwy użytkownik z Polski, a nie jak datacenter w Amsterdamie. Bot score potrafi być zupełnie bezużyteczny przy dobrze skonfigurowanym operatorze.

---

Jak do tego podchodzę

Nie ma jednej reguły, która zatrzyma wszystko. Kilka warstw razem robi jednak dużą różnicę:

1. Logi access jako podstawa diagnostyki — user agent, timing, stosunek HTML do zasobów towarzyszących, zakres ASN. Cloudflare logów nie zastąpi.
2. Blokada znanych AI crawlerów po user agencie — lista jest długa i rośnie; trzymam regułę WAF z aktualizowaną listą.
3. Rate limiting po ASN, nie tylko po IP — przy rotującym pool adresów rate limit per-IP nic nie daje; per-ASN lub per-subnet już reaguje.
4. Cache na poziomie serwera — jeśli bot i tak dostanie odpowiedź, niech to będzie cache, a nie PHP z bazą danych.
5. Honeypot links — tanie, skuteczne, zero false positives dla prawdziwych użytkowników.
6. Ręczna blokada i monitoring po incydencie — przy agresywnym operatorze zdarza się, że żadna automatyka nie reaguje wystarczająco szybko. Blokuję ASN i obserwuję, skąd przychodzą kolejne IP z tego zakresu.