Obciążenie sklepu rośnie z tygodnia na tydzień, choć sprzedaż stoi w miejscu. W nocy serwer bywa bardziej zajęty niż w dzień, a wykresy ruchu nie zgadzają się z Google Analytics. Brzmi znajomo? Ten wzorzec widzimy u klientów coraz częściej — i niemal zawsze przyczyna jest ta sama.
Skąd się bierze ten ruch
Po zajrzeniu w surowe logi serwera (nie w analitykę — boty nie wykonują JavaScriptu, więc Analytics ich nie widzi) obraz zwykle wygląda tak:
- Crawlery AI — GPTBot, ClaudeBot, PerplexityBot, Bytespider i dziesiątki mniejszych. Część uczciwie się przedstawia w User-Agent, część nie.
- Scrapery cen — konkurencja lub porównywarki pobierające katalog kilka razy dziennie, często podszywające się pod zwykłe przeglądarki.
- Agresywne roboty „SEO” — crawlery narzędzi analitycznych, które potrafią odpytywać sklep szybciej niż Googlebot.
Sam ruch botów nie byłby problemem, gdyby nie jeden szczegół: nawigacja warstwowa. Sklep na Magento, PrestaShop czy Shopware ma filtrowanie po atrybutach — kolor, rozmiar, cena, producent. Kombinacji filtrów są miliony, a bot przechodzący po wszystkich linkach generuje adresy, których nie ma w cache. Każde takie wejście to pełne wykonanie aplikacji: zapytania do bazy, zapytania do Elasticsearch, budowanie strony od zera.
Efekt: klient płaci zasobami serwera za cudze scrapowanie, a w szczycie kampanii — kiedy dochodzi prawdziwy ruch — sklep zaczyna zwalniać.
Jak to zdiagnozować w 15 minut
- Porównaj logi serwera z analityką. Jeśli serwer obsługuje 3× więcej żądań, niż Analytics pokazuje sesji — masz ruch botów.
- Zlicz User-Agenty:
awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -30. Wszystko, co nie jest przeglądarką ani Googlebotem/Bingbotem, to kandydaci do wycięcia. - Sprawdź cache hit ratio w Varnishu/FPC. Nagły spadek trafień w cache przy rosnącym ruchu to klasyczny ślad botów w nawigacji warstwowej.
- Spójrz na rozkład godzinowy. Ruch klientów ma dobowy rytm; boty crawlują płasko przez całą dobę — stąd „zajęty serwer o 3 w nocy”.
Jak to zatrzymać — warstwami
Nie ma jednego przełącznika. Skuteczna ochrona to kilka warstw, od najtańszej do najcięższej:
robots.txt — uczciwe crawlery AI (GPTBot, ClaudeBot, CCBot) respektują dyrektywy. To pierwszy, darmowy krok — ale zatrzyma tylko tych uczciwych.
Reguły WAF i bot management (np. Cloudflare) — odsiewają ruch podszywający się pod przeglądarki na podstawie fingerprintu, nie User-Agenta. Prawdziwe roboty wyszukiwarek zostają na białej liście.
Rate limiting na nawigacji warstwowej — nikt nie klika w 40 kombinacji filtrów na minutę. Limit na wzorcach URL z parametrami filtrów tnie masowe odpytywanie, nie przeszkadzając klientom.
Challenge zamiast blokady — wątpliwy ruch dostaje weryfikację (managed challenge), zanim dotknie aplikacji. Klient z prawdziwą przeglądarką przejdzie ją niezauważalnie.
Statyka z edge — obrazki, CSS i JS serwowane z CDN nie obciążają serwera nawet wtedy, gdy bot je pobiera.
Efekt z naszej praktyki
W sklepie, od którego zaczęła się ta historia, po wdrożeniu powyższych warstw obciążenie wróciło do poziomu realnego ruchu, wykresy serwera znów pokrywają się z analityką, a rezerwa wydajności, którą klient chciał dokupować, okazała się niepotrzebna — bo odzyskał tę, którą zjadały boty.
Jeśli podejrzewasz, że Twój sklep płaci za cudze scrapowanie — odezwij się. Analiza logów i diagnoza są po naszej stronie, bezpłatnie.