Ukryty koszt AI w e-commerce: jak boty obciążają sklepy internetowe

Sklep internetowy może nie mieć żadnego czatu AI, żadnego generatora opisów, żadnej integracji z GPT, Claude czy Gemini. A i tak płacić za AI. Nie w panelu rozliczeń za tokeny, tylko w czasie ładowania strony, wyższym zużyciu CPU, przeciążonej bazie danych, błędach 5xx, wolniejszym koszyku i spadku CVR, czyli współczynnika konwersji.

To nie jest teoria z prezentacji o cyberbezpieczeństwie. Według 2026 Thales Bad Bot Report boty odpowiadały za 53% ruchu internetowego, 40% całego ruchu stanowiły złe boty, a 20% ataków botów AI było wymierzonych w strony retailowe. Thales podaje też, że liczba ataków botów wspieranych AI wzrosła rok do roku 12,5 raza. Dla sklepu oznacza to proste ryzyko: coraz większa część ruchu nie przychodzi po zakup, tylko po dane, indeksację, testowanie zabezpieczeń albo przeciążenie aplikacji.

Boty nie kupują, ale zużywają serwer jak najaktywniejszy klient

Najbardziej mylący objaw to rosnący ruch. Właściciel sklepu widzi więcej wejść i przez chwilę może wyglądać to jak sukces: kampania działa, SEO ruszyło, sezon sprzedażowy się rozkręca. Problem zaczyna się wtedy, gdy obok ruchu rośnie TTFB, panel administracyjny zwalnia, listing kategorii ładuje się kilka sekund, a konwersja nie idzie w górę. Często idzie w dół.

W e-commerce trzeba rozdzielić kilka typów automatów, bo wrzucanie ich do jednego worka prowadzi do złych decyzji:

• price scrapers — pobierają ceny, promocje, dostępność, warianty, EAN-y, opisy i parametry produktów;
• AI crawlers — czytają treści pod wyszukiwarki AI, odpowiedzi generatywne, trening modeli albo funkcje użytkownika;
• search crawlers — Googlebot, Bingbot i podobne roboty wyszukiwarek, które mogą być potrzebne do SEO;
• SEO crawlery i monitoringi — narzędzia audytowe, uptime monitoring, porównywarki, integracje marketplace;
• fraud/bad bots — automaty do credential stuffingu, testowania kuponów, cardingu, przejmowania kont albo ataków na API.

Dla serwera różnica między klientem a botem bywa brutalna. Klient obejrzy kategorię, dwa produkty, doda coś do koszyka albo wyjdzie. Bot potrafi wejść w setki kombinacji: kategoria + producent, kategoria + rozmiar, kolor + cena, sortowanie + paginacja, filtr + parametr w URL. Każdy taki adres może uruchomić zapytania do bazy, przeliczenie dostępności, moduł rekomendacji, cache, indeks wyszukiwarki wewnętrznej i skrypty platformy.

Największy problem robi faceted navigation, czyli filtry, sortowania i paginacje. Google wprost ostrzega, że crawl takich adresów może zużywać dużo zasobów obliczeniowych przez liczbę URL-i i operacji potrzebnych do wyrenderowania stron. Jeśli filtrowane adresy nie muszą pojawiać się w wynikach wyszukiwania, Google rekomenduje ograniczanie ich crawlowania, między innymi przez robots.txt.

Typowy scenariusz wygląda tak:

• sklep ma kategorię z 800 produktami;
• każdy produkt ma kilka wariantów;
• filtry tworzą osobne adresy URL;
• sortowanie i paginacja dokładają kolejne parametry;
• bot zaczyna przechodzić po kombinacjach;
• serwer liczy tysiące widoków, których człowiek nigdy nie zobaczy.

I wtedy koszt AI nie polega na tym, że sklep używa sztucznej inteligencji. Koszt polega na tym, że cudze automaty traktują sklep jak darmową bazę danych.

Cloudflare pokazywał, że od maja 2024 do maja 2025 ruch crawlerów AI i wyszukiwarek wzrósł o 18%, a sam GPTBot zwiększył liczbę requestów o 305%. W tej samej analizie ChatGPT-User urósł o 2825%, choć jego udział w całym crawlowaniu był nadal dużo mniejszy niż udział największych robotów.

To ważny niuans. Nie każdy bot AI jest atakiem. Część działa jako crawler wyszukiwarki AI, część jako robot treningowy, część pobiera stronę na życzenie użytkownika. OpenAI rozdziela między innymi OAI-SearchBot i GPTBot, a ustawienia dla nich są niezależne: można dopuścić robota wyszukiwarki, a ograniczyć crawlera używanego do treningu modeli. Anthropic też opisuje osobne boty: ClaudeBot, Claude-User i Claude-SearchBot, z różnymi skutkami blokowania.

Dlatego pierwsza zasada brzmi: nie blokuj wszystkiego po nazwie AI. Najpierw ustal, co dany automat robi, ile kosztuje serwer i czy daje sklepowi jakąkolwiek wartość.

Logi, Cloudflare i adresy URL: gdzie naprawdę widać problem

GA4 jest pomocne, ale nie wystarczy. Część botów nie wykonuje JavaScriptu, część nie zachowuje się jak zwykły użytkownik, część w ogóle nie pojawi się w analityce tak, jak pojawia się człowiek. Dlatego diagnostykę trzeba zacząć od miejsc, które widzą żądania do serwera: logi serwera, WAF/CDN, Cloudflare, panel hostingu, monitoring aplikacji i logi błędów.

Najpierw trzeba zestawić dwie osie czasu: kiedy sklep zwalniał i kiedy spadała konwersja. Sam wzrost ruchu niczego nie dowodzi. Dowodem robi się dopiero zestaw sygnałów: duża liczba requestów, nietypowe URL-e, obce ASN-y, brak wartości sprzedażowej i realny wpływ na wydajność.

W logach sprawdziłbym w tej kolejności:

• top IP według liczby requestów;
• top user-agent według liczby requestów;
• top URL według liczby wejść;
• kraje, regiony i operatorów/ASN;
• liczbę żądań na minutę z jednego IP albo jednej puli;
• kody odpowiedzi: 200, 301/302, 403, 404, 429, 499, 5xx;
• godziny skoków obciążenia;
• ścieżki z parametrami: ?filter=, ?sort=, ?page=, ?price=, ?producer=, ?color=, ?size=;
• endpointy API, wyszukiwarki wewnętrznej, koszyka i kont użytkownika.

Dobre pytanie diagnostyczne nie brzmi: „czy mam boty?”. Każdy większy sklep je ma. Pytanie brzmi: które boty generują koszt bez wartości.

Jeżeli na górze listy URL-i są produkty i kategorie, trzeba sprawdzić zachowanie. Jeżeli na górze są filtrowane listingi, paginacja, sortowanie i kombinacje parametrów, trop jest mocniejszy. Jeżeli jeden IP albo jedna pula IP robi setki wejść w kilka minut, ale nie przechodzi do koszyka, nie odpala checkoutu i nie wykonuje ścieżki typowej dla klienta, to nie wygląda jak sprzedaż.

Praktyczny podział decyzji:

• Googlebot/Bingbot — nie blokować pochopnie; najpierw zweryfikować, czy to prawdziwy robot.
• AI crawler z jasnym user-agentem — zdecydować, czy sklep chce być widoczny w danym ekosystemie AI, czy ogranicza trening i masowe crawlowanie.
• price scraper podszywający się pod przeglądarkę — ograniczać po zachowaniu, IP, ASN, tempie i ścieżkach.
• ruch z API/konta/koszyka — traktować jako wyższe ryzyko, bo może dotyczyć fraudu, credential stuffingu albo testowania logiki biznesowej.
• monitoring, integracje, feedy, marketplace — dodać do allowlisty dopiero po potwierdzeniu źródła.

Samo pole user-agent jest za słabe jako dowód. Da się wpisać „Googlebot” i udawać robota Google. Google zaleca weryfikację przez reverse DNS oraz forward DNS albo porównanie IP z publikowanymi zakresami. To powinien być standard przed blokowaniem ruchu, który wygląda jak wyszukiwarka.

W Cloudflare albo innym WAF-ie najczęściej najszybciej widać trzy rzeczy: kraje, ASN-y i ścieżki. Jeżeli sklep sprzedaje wyłącznie w Polsce, a nagle duży techniczny ruch przychodzi z regionów bez znaczenia biznesowego, to jest trop. Nie wyrok. Blokowanie całych krajów bywa skuteczne w małym sklepie lokalnym, ale w B2B, eksporcie, dropshippingu, branżach specjalistycznych albo przy klientach zagranicznych może odciąć realny przychód.

Dobre progi trzeba ustalić na podstawie własnego ruchu. Nie ma jednej liczby, która pasuje do każdego sklepu. Dla małego WooCommerce kilkaset requestów na listingi z jednego IP w krótkim czasie może być nienormalne. Dla dużego sklepu na Magento będzie to tylko szum. Sensowna procedura to nie „ustaw limit z internetu”, tylko:

1. Weź normalny dzień sprzedażowy bez awarii.
2. Sprawdź medianę i górne 5% ruchu dla kategorii, filtrów i produktów.
3. Porównaj z dniem, w którym serwer miał skok CPU albo błędy 5xx.
4. Oznacz ścieżki, które rosną najmocniej.
5. Dopiero wtedy ustaw limity dla konkretnych URL-i, nie dla całej strony.

Najczęstszy błąd: właściciel sklepu widzi problem i od razu kupuje droższy hosting. Czasem to daje kilka tygodni spokoju. Ale jeśli źródłem jest bot mielący tysiące kombinacji filtrów, mocniejszy serwer tylko drożej obsłuży ten sam śmietnik.

Jak ograniczać boty bez odcinania SEO, klientów i integracji

Najpierw ogranicza się kosztowne ścieżki, nie cały internet. To najbezpieczniejsza kolejność. W praktyce zacząłbym od rate limitingu na listingach, filtrach, paginacji, wyszukiwarce wewnętrznej i parametrach URL. Produkt, koszyk, checkout i panel klienta wymagają osobnej ostrożności, bo tam łatwo uderzyć w prawdziwego użytkownika.

Najwyższy priorytet mają działania o małym ryzyku:

• ograniczenie crawl dla filtrów bez wartości SEO;
• usunięcie z linkowania wewnętrznego kombinacji, które tworzą śmietnik URL-i;
• limity requestów dla parametrów filtrów i sortowania;
• cache dla kategorii i produktów;
• osobne reguły dla wyszukiwarki wewnętrznej;
• challenge tylko dla podejrzanych wzorców, nie dla wszystkich;
• blokowanie konkretnych IP/ASN dopiero po potwierdzeniu;
• monitoring błędów 429, 403 i 5xx po wdrożeniu reguł.

robots.txt pomaga przy uczciwych crawlerach, ale nie jest ochroną przed agresywnym scraperem. Robot, który respektuje zasady, może przestać crawlowac filtrowane adresy. Scraper cenowy może ten plik zignorować. Dlatego robots.txt nadaje się do zarządzania crawlem, a nie do realnej ochrony danych.

Trzeba też rozumieć różnicę między robots.txt, noindex i canonical:

• robots.txt ogranicza crawl, czyli pobieranie adresów przez roboty, które respektują reguły;
• noindex usuwa stronę z indeksu, ale robot musi ją najpierw pobrać i zobaczyć znacznik;
• canonical wskazuje preferowany adres, ale Google traktuje go jako sygnał, nie twardą regułę.

Google potwierdza, że aby zobaczyć noindex, musi najpierw crawlowac stronę, a blokada w robots.txt może uniemożliwić odczyt tego znacznika. Przy canonicalach Google również zastrzega, że wskazanie kanonicznego URL-a jest sugestią, a nie regułą; wyszukiwarka może wybrać inną wersję, jeśli sygnały są sprzeczne.

Decyzja dla filtrów powinna wyglądać tak:

• jeśli filtr ma wartość SEO i sprzedażową, np. „buty trekkingowe męskie rozmiar 44” w dużym sklepie, można rozważyć indeksowalną stronę z czystym URL-em, unikalnym title, H1 i opisem;
• jeśli filtr jest tylko technicznym zawężeniem, np. sortowanie po cenie, parametr widoku, losowa kombinacja koloru i producenta, lepiej nie dawać mu pełnej ścieżki do indeksacji;
• jeśli kombinacje filtrów tworzą tysiące URL-i, priorytetem jest ograniczenie crawlu i linkowania, nie dopisywanie opisów do wszystkiego;
• jeśli sklep już ma zaindeksowany śmietnik, trzeba zaplanować wyjście: noindex tam, gdzie strona ma zostać pobrana i usunięta z indeksu, oraz robots.txt tam, gdzie celem jest oszczędzenie zasobów po uporządkowaniu indeksacji.

Nie każdą blokadę trzeba wdrażać od razu jako twarde 403. Często lepsze są stopnie:

1. Logowanie i obserwacja — przez 24–72 godziny, jeśli sklep nie leży.
2. Rate limiting — dla ścieżek kosztownych, np. filtry, paginacja, search.
3. Managed challenge — dla podejrzanych krajów, ASN-ów, braku cookies, nietypowego tempa.
4. Blokada IP/ASN — gdy zachowanie jest jednoznaczne i powtarzalne.
5. Zmiany strukturalne — przebudowa filtrów, cache, indeksacja, zapytania SQL, sposób generowania URL-i.

W małych sklepach największy efekt często daje jedna decyzja: nie pozwalać botom chodzić po nieskończonych kombinacjach filtrów. W większych sklepach dochodzi drugi temat: API. Thales podaje, że w 2025 roku 27% ataków botów było wymierzonych w API, a 21% w logikę biznesową. To nie jest już tylko problem wejść na kategorie. To także logowanie, koszyk, dostępność, ceny dynamiczne, kupony, konta klientów i endpointy używane przez aplikacje.

Twarde blokady mają swoje miejsce, ale trzeba je stosować po diagnozie. Zablokowanie całego kraju może być rozsądne, jeśli sklep jest lokalny, nie wysyła za granicę, nie ma partnerów zagranicznych i dane pokazują czysty ruch techniczny bez sprzedaży. W innym przypadku to siekiera, nie skalpel. Podobnie z blokowaniem wszystkich crawlerów AI: można ograniczyć treningowe pobieranie treści, ale można też zmniejszyć widoczność w odpowiedziach AI lub wyszukiwarkach generatywnych. To decyzja biznesowa, nie tylko techniczna.

Najrozsądniejszy start jest prosty: sprawdzić top URL-e, top IP, top user-agenty, kraje, ASN-y i momenty spadku konwersji. Jeżeli na szczycie są filtry, paginacja i parametry, najpierw ogranicza się te ścieżki. Dopiero potem kupuje droższy hosting. Odwrotna kolejność zwykle kończy się większą fakturą i tym samym bałaganem w logach.

FAQ

Czy boty AI mogą obciążać sklep, nawet jeśli nie używam AI na stronie?
Tak. Sklep może być crawlowany przez boty AI, scrapery cenowe, wyszukiwarki, narzędzia SEO i automaty pobierające dane. Nie trzeba mieć wdrożonego GPT, Claude ani Gemini, żeby ponosić koszt takiego ruchu.

Po czym poznać, że problemem są boty, a nie zwykli klienci?
Najczęściej po nietypowej liczbie requestów z jednego IP lub ASN, masowym odwiedzaniu filtrów i paginacji, wejściach z krajów bez znaczenia sprzedażowego, braku ścieżki produkt → koszyk → checkout oraz skokach CPU/RAM w tych samych godzinach.

Czy GA4 wystarczy do diagnozy?
Nie. GA4 może pokazać część anomalii, ale wiele botów nie wykonuje JavaScriptu albo nie zachowuje się jak użytkownik. Do rzetelnej diagnozy potrzebne są logi serwera, WAF/CDN, Cloudflare, panel hostingu i analiza najczęściej odwiedzanych URL-i.

Czy robots.txt zatrzyma scrapery cen?
Nie musi. Robots.txt działa na boty, które respektują reguły. Uczciwe crawlery mogą się do niego zastosować, ale agresywny scraper może go zignorować. Dlatego robots.txt traktuj jako narzędzie kontroli crawlu, a nie zabezpieczenie przed kradzieżą danych.

Czy blokować wszystkie boty AI?
Nie automatycznie. Najpierw rozdziel roboty treningowe, wyszukiwarkowe i pobierające stronę na żądanie użytkownika. Blokada może zmniejszyć obciążenie, ale może też ograniczyć widoczność sklepu w odpowiedziach AI lub wyszukiwarkach generatywnych.

Czy warto od razu przejść na droższy hosting?
Tylko jeśli sklep realnie nie wyrabia mimo uporządkowanego ruchu. Gdy problemem są boty mielące filtry, paginację i parametry URL, mocniejszy hosting często tylko drożej obsłuży niepotrzebne requesty. Najpierw logi i ograniczenie śmieciowego crawlu, potem decyzja o zasobach.

Od czego zacząć, gdy sklep zwalnia i spada konwersja?
Najpierw porównaj godziny spadku CVR z obciążeniem serwera. Potem sprawdź top URL-e, IP, user-agenty, kraje i ASN-y. Jeśli dominują filtrowane listingi, sortowania, paginacja albo dziwne parametry, pierwszym błędem do usunięcia jest niekontrolowany crawl tych adresów.