Boty AI w WooCommerce: jak odciąć zbędny ruch i odciążyć hosting bez utraty widoczności

Diagnoza problemu: dlaczego sklep po migracji zaczął działać wolno

Według materiału opublikowanego na dhosting.pl, problem ujawnił się po migracji butikowego sklepu WooCommerce (właściciel: Andrzej Piłatowicz, Studio Zaiste) na nowe środowisko. Migracja przebiegła bezproblemowo i przez około 30 minut sklep działał poprawnie. Po dwóch dniach jednak czas ładowania podstron wzrósł do kilkunastu, a nawet kilkudziesięciu sekund. W panelu dPanel widoczny był wyraźny skok obciążenia CPU, który utrzymał się na podwyższonym poziomie. Pierwsza reakcja - włączenie dodatkowych zasobów w ramach Elastycznego Skalowania (CPU, RAM, przestrzeń dyskowa) - pozwoliła utrzymać sklep w działaniu, ale nie usunęła przyczyny. Obciążenie nadal było bardzo wysokie, co wskazywało na nienaturalny ruch generujący kosztowne żądania.

Sklep opierał się na WordPress, WooCommerce, ACF Pro, dedykowanym szablonie oraz około 30 wtyczkach (część z repozytorium, część napisanych indywidualnie). Jak wyjaśnia autor case study, Piotr Pantkowski, boty AI zachowują się zupełnie inaczej niż ludzie: metodycznie odwiedzają wszystkie znalezione linki, w tym menu, kategorie, produkty, parametry sortowania, paginację, wyszukiwarkę i filtry. W WooCommerce filtry są szczególnie groźne, bo każda kombinacja atrybutów (kolor, rozmiar, marka, cena, etykieta, parametr techniczny, sortowanie) tworzy unikalny adres URL. Z kilkuset produktów może powstać kilkadziesiąt tysięcy adresów. Dla cache'a każdy nowy URL to "zimne" żądanie - PHP, WordPress, WooCommerce, zapytania do bazy, przeliczenie filtrów, renderowanie od zera. Procesor pracuje na wysokich obrotach, a realni klienci mogą być mało. Takiego ruchu nie widać w Google Analytics - pełny obraz dają logi serwera i statystyki hostingu.

Wielowarstwowa obrona: od Cloudflare po wtyczkę WordPress

Pierwszą warstwą było podpięcie Cloudflare (nawet darmowy plan) i wdrożenie reguł w sekcji Security → Security Rules. Kolejność reguł miała kluczowe znaczenie: najpierw geo-blok (odcięcie kontynentów AF, AN, AS, OC, SA, T1 - decyzja biznesowa dla sklepu sprzedającego tylko w Polsce), potem "Bot gate" (twarda blokada zadeklarowanych botów na ciężkich endpointach), na końcu "Crawler filters" (Managed Challenge na filtrach dla pozostałego ruchu). Dzięki temu jawne boty dostawały blokadę, ukryte automaty - wyzwanie JS/cookies, a realni użytkownicy korzystali ze sklepu. W ciągu doby Cloudflare zatrzymał około 2,39 tys. żądań geo-blokiem i 1,82 tys. regułami crawlerów - łącznie ponad 4 tys. zablokowanych żądań.

Okazało się jednak, że część botów omija Cloudflare i uderza bezpośrednio w origin (prawdziwy serwer). Testy curl potwierdziły: przez Cloudflare GPTBot na /sklep/f/test/ otrzymywał 403, a bezpośrednio na origin - 200 OK (pełne renderowanie). Źródłami adresu IP originu mogły być: subdomeny pocztowe (imap, smtp, poczta) nieproksowane przez Cloudflare, logi Certificate Transparency, bazy passive DNS, nagłówki SMTP. Dlatego konieczna była druga warstwa - reguły w .htaccess działające przed uruchomieniem PHP. Zastosowano dwa typy: hard block (Amazonbot, Bytespider, meta-externalagent, meta-webindexer, FacebookBot, CCBot, PetalBot, MJ12bot, DotBot, Sogou, SeznamBot, Baiduspider - zwracane 403) oraz soft block dla botów AI (GPTBot, ClaudeBot, PerplexityBot) tylko na ciężkich endpointach: /f/, -or-, /koszyk, /zamowienie, /moje-konto, /wp-admin, /wp-json, parametry filter_, min_price, max_price, orderby, product_count, dgwt_wcas, wc-ajax, ^s= (zwracane 429). Strony produktów i kategorii pozostały dostępne.

Trzecia warstwa to własna wtyczka WordPress na hooku plugins_loaded z priorytetem 1 (przed motywem i ciężką logiką WooCommerce). Realizowała trzy funkcje: 1) tarpit dla hard-blockowanych botów - sleep(rand(3,8)), 403, Retry-After: 86400 (uwaga: na hostingu współdzielonym tarpit może zajmować workery PHP, bezpieczniejszy jest szybki 403); 2) soft block 429 dla botów AI na ciężkich endpointach bez opóźnienia (szybkie zwolnienie workera); 3) prosty rate limit per bot per IP (licznik JSON w katalogu tymczasowym, bez bazy danych) - przykładowe limity: GPTBot 30 req/min, SemrushBot 10 req/min, AhrefsBot 30 req/min. Czwarta warstwa - robots.txt - to tylko prośba, nie zabezpieczenie (część botów go ignoruje, zwłaszcza te wywoływane na żądanie użytkownika jak ChatGPT-User). Przykładowe wpisy: GPTBot Disallow na /sklep/f/, /produkty/*/f/, /*-or-*, /*?orderby=, /*?filter_*; ChatGPT-User Allow: /; Amazonbot i meta-externalagent Disallow: /. Warto pamiętać, że nazwy typu Applebot-Extended czy anthropic-ai to tokeny tylko do robots.txt.

Dobre praktyki hostingowe: jak zapobiegać i diagnozować podobne problemy

Z perspektywy hostingu kluczowe jest posiadanie widoczności obciążenia zasobów (CPU, RAM, I/O) w panelu klienta - bez tego diagnoza "dlaczego strona muli" to wróżenie z fusów. W opisanym przypadku dPanel dhosting.pl pokazał skok CPU już po dwóch dniach, co pozwoliło szybko zareagować. Elastyczne Skalowanie (doładowanie zasobów na czas diagnozy) to bezpieczna opcja "na już", ale nigdy nie zastępuje znalezienia przyczyny. Warto regularnie przeglądać logi dostępu (access logs) - one ujawniają User-Agency, endpointy i kody odpowiedzi, których nie ma w analityce JS. Jeśli hosting oferuje staging, testy reguł blokujących warto przeprowadzać tam, by nie zablokować realnych klientów ani wartościowych crawlerów. Cache (page cache, object cache) świetnie działa przy ruchu powtarzalnym, ale przy crawl trapach (tysiące unikalnych URL-i filtrów) staje się nieskuteczny - każdy nowy URL to "miss". Dlatego blokada na poziomie edge (Cloudflare/WAF), serwera (.htaccess) i aplikacji (wtyczka WP) jest skuteczniejsza niż liczenie na cache.

Ważna zasada: nie blokujemy botów AI jako takich, bo coraz więcej użytkowników szuka produktów przez asystentów AI. Celem jest odcięcie tej części ruchu, która generuje koszt bez wartości biznesowej - czyli masowe crawlowanie kombinacji filtrów, sortowania, wyszukiwarki, koszyka, panelu admina, API. Treści produktowe, kategorie, blog mogą pozostać otwarte. Decyzja o twardym zablokowaniu konkretnego bota (np. Amazonbot) zależy od modelu biznesowego - sklep na rynku polskim może nie czerpać wartości z indeksowania w Amazon Search, inny sklep - tak. Rate limiting w wtyczce WP (plik JSON w /tmp) to lekki kompromis: nie idealny przy dużej współbieżności, ale nie obciąża MySQL. Na produkcji warto rozważyć Redis lub Memcached do liczników, jeśli ruch botów jest masowy. Tarpit (sleep) w PHP na hostingu współdzielonym to ryzyko - śpiący proces zajmuje workera; przy ataku rozproszonym może to zaszkodzić dostępności dla użytkowników. Bezpieczniejszy: natychmiastowy 403/429.

Checklista wdrożenia: co zrobić krok po kroku w swoim sklepie

1. Zidentyfikuj problem: sprawdź obciążenie CPU/RAM w panelu hostingu, przeanalizuj logi dostępu (szukaj User-Agentów botów, endpointów z filtrami /f/, -or-, parametrów filter_, orderby, min_price, max_price, dgwt_wcas, wc-ajax, wp-json). 2. Podpięj Cloudflare (DNS proxy) i skonfiguruj reguły Security Rules w kolejności: geo-blok (jeśli sklep jest lokalny), twarda blokada zadeklarowanych botów na ciężkich endpointach (warunek: endpoint ORAZ User-Agent zawiera bot/spider/crawl/gptbot/amazonbot/applebot/perplexity/claudebot/bytespider/ccbot/cohere-ai), Managed Challenge na filtrach (/f/ lub -or-) dla reszty ruchu. 3. Zabezpiecz origin: ogranicz dostęp do portów 80/443 tylko do IP Cloudflare (firewall serwera / security groups), upewnij się, że subdomeny pocztowe nie ujawniają IP originu, rozważ proxy dla poczty lub oddzielny serwer. 4. Dodaj reguły .htaccess: hard block dla agresywnych scraperów/botów SEO (Amazonbot, Bytespider, Meta, CCBot, itd.), soft block 429 dla botów AI (GPTBot, ClaudeBot, PerplexityBot) na ciężkich endpointach (REQUEST_URI lub QUERY_STRING). 5. Wdroż własną wtyczkę WP (mu-plugin lub zwykła, priorytet 1 na plugins_loaded): tarpit/403 dla hard-blockowanych, 429 dla AI botów na ciężkich endpointach, rate limit per IP/bot (plik JSON w sys_get_temp_dir()). 6. Uzupełnij robots.txt: Disallow dla botów AI na wzorcach filtrów, Allow dla botów użytkowych (ChatGPT-User), Disallow dla botów bez wartości. 7. Monitoruj: logi Cloudflare (Security Events), logi serwera (access/error), obciążenie CPU w panelu hostingu. Dostosuj limity rate limit i listy botów na podstawie realnych danych.

Jeśli szukasz hostingu, który w standardzie daje wgląd w obciążenie CPU, Elastyczne Skalowanie i łatwą integrację z Cloudflare, dhosting.pl sprawdzi się w takich scenariuszach.

Jeśli chcesz zgłębić temat, zajrzyj też do naszych powiązanych poradników: Hosting dla sklepu internetowego - co wybrać, Cloudflare w hostingu - jak skonfigurować i co to daje, Bezpieczeństwo WordPress na hostingu - dobre praktyki, Dlaczego backup to podstawa bezpieczeństwa sklepu.

Najczęstsze pytania