Boty AI w sklepie WooCommerce: jak odciąć zbędny ruch, odciążyć hosting i nie stracić widoczności w AI. Case study

Poznaj autora

Andrzej Piłatowicz – klient dhosting.pl, właściciel butikowej pracowni Studio Zaiste, od ponad 15 lat związany z e-commerce. Zaczynał od UX/UI i designu: projektowania interfejsów, architektury informacji i optymalizacji konwersji. Z czasem przeszedł w stronę web developmentu oraz rozwoju stron, sklepów i narzędzi AI. Dzięki temu na projekty patrzy całościowo, łącząc perspektywę biznesową, techniczną i użytkową.

Wstęp

Boty internetowe nie są nowym problemem. Od lat po stronach chodzą crawlery wyszukiwarek, narzędzia SEO, scrapery cenowe czy automaty zbierające treści. W ostatnim czasie coraz większym wyzwaniem stają się jednak boty związane z AI – szczególnie wtedy, gdy trafiają na rozbudowane sklepy WooCommerce z dużą liczbą filtrów, parametrów i dynamicznie generowanych adresów URL.

W tym case study pokazujemy, jak jeden ze sklepów WooCommerce po migracji na dhosting.pl zaczął mierzyć się z nagłym wzrostem obciążenia, dlaczego samo zwiększenie zasobów nie rozwiązało problemu i jak udało się ograniczyć sztuczny ruch przy pomocy kilku warstw ochrony: Cloudflare, reguł na poziomie serwera, własnego pluginu WordPress oraz pliku robots.txt. Warto dodać, że na poprzednim hostingu cały serwis działał wolno i nie było możliwości sprawdzenia dlaczego – w hostingu EWH klient widzi m.in. obciążenie procesora. 

To nie jest uniwersalna recepta do bezrefleksyjnego skopiowania 1:1. To raczej praktyczny przykład diagnozy i podejścia „defense in depth”, czyli kilku warstw zabezpieczeń, z których każda łapie inny typ niepożądanego ruchu.

Początek problemu: migracja, szybki start i nagłe spowolnienie

Historia zaczęła się dość zwyczajnie: od migracji sklepu WooCommerce z innego hostingu na dhosting.pl.

Sama migracja przebiegła bezproblemowo. Sklep został przeniesiony, sprawdzony i po około 30 minutach działał już na nowym środowisku. Początkowo wszystko wyglądało dobrze – strona ładowała się poprawnie, sklep działał stabilnie, a podstawowe testy nie wykazywały problemów.

Po dwóch dniach mój klient zgłosił jednak, że strona zaczęła działać wolno. Czas ładowania podstron wynosił momentami od kilkunastu do nawet kilkudziesięciu sekund. Po wejściu do dPanelu okazało się, że obciążenie CPU wyraźnie wzrosło względem pierwszych dni po migracji i utrzymywało się na podwyższonym poziomie.

Pierwszą reakcją było włączenie dodatkowych zasobów w ramach Elastycznego Skalowania. To ważna funkcja po stronie hostingu, bo pozwala klientowi zwiększyć dostępne zasoby, takie jak CPU, RAM czy przestrzeń dyskowa. Podniesienie zasobów pozwoliło utrzymać sklep w działaniu na czas diagnozy, ale nie usuwało przyczyny: obciążenie nadal było bardzo wysokie.

To był pierwszy sygnał, że problemem nie jest wyłącznie „za mały serwer”, ale coś, co generuje nienaturalnie duży i kosztowny ruch. W badanym sklepie wykorzystano między innymi:

• WordPress,
• WooCommerce,
• ACF Pro,
• dedykowany szablon,
• część wtyczek z repozytorium WordPressa,
• część wtyczek napisanych indywidualnie,
• łącznie około 30 wtyczek.

Dlaczego boty AI są problemem dla sklepów WooCommerce?

Dla użytkownika problem wygląda prosto: „strona muli”. Po stronie serwera sytuacja jest jednak bardziej złożona.

Człowiek odwiedzający sklep zwykle zachowuje się przewidywalnie. Wchodzi na stronę główną, otwiera kilka kategorii, sprawdza parę produktów, może używa filtrów, a potem wychodzi albo składa zamówienie. Bot działa inaczej.

Crawler potrafi wejść we wszystko, co znajdzie na stronie: menu, kategorie, wpisy blogowe, produkty, parametry sortowania, paginację, wyszukiwarkę i filtry. W WooCommerce filtry są szczególnie problematyczne, bo mogą generować ogromną liczbę kombinacji adresów URL.

Przykład? Sklep może mieć kilkaset realnych produktów, ale jeśli każdy produkt da się filtrować po kolorze, rozmiarze, marce, cenie, etykiecie, parametrze technicznym czy sortowaniu, to liczba możliwych adresów URL rośnie bardzo szybko. Z pozornie niewielkiego katalogu może powstać kilkadziesiąt tysięcy, a czasem nawet więcej unikalnych adresów.

Dla bota każdy taki adres wygląda jak osobna podstrona do odwiedzenia.

To właśnie tzw. crawl trap, czyli pułapka indeksowania. Bot wpada w system filtrów i zaczyna metodycznie odwiedzać kolejne kombinacje adresów, które z punktu widzenia realnego użytkownika często nie mają żadnej wartości.

Dlaczego cache nie zawsze pomaga?

W normalnym ruchu page cache potrafi znacząco odciążyć serwer. Jeżeli wielu użytkowników odwiedza tę samą stronę produktu albo kategorię, cache może podać gotową wersję strony bez każdorazowego uruchamiania PHP, zapytań do bazy danych i renderowania całego widoku. Problem zaczyna się wtedy, gdy bot generuje tysiące unikalnych adresów.

Dla cache’a każdy nowy adres URL to potencjalnie świeże żądanie. Jeżeli adres nie był wcześniej odwiedzony, cache nie ma gotowej odpowiedzi. W efekcie żądanie przechodzi pełną ścieżkę:

1. uruchomienie PHP,
2. załadowanie WordPressa,
3. załadowanie WooCommerce,
4. wykonanie zapytań do bazy danych,
5. przeliczenie filtrów,
6. wyrenderowanie strony od zera.

Przy realnym ruchu użytkowników większość odwiedzin może być tania dla serwera. Przy botach chodzących po tysiącach kombinacji filtrów niemal każde wejście może być kosztowne. Efekt? Procesor pracuje na wysokim obciążeniu, mimo że liczba prawdziwych klientów na stronie wcale nie musi być duża.

Co ważne, takiego ruchu często nie widać w Google Analytics ani podobnych narzędziach analitycznych. One pokazują głównie zachowania użytkowników, a nie pełny obraz żądań trafiających do serwera. Pełny obraz widać dopiero w logach serwera albo statystykach hostingu.

Czy boty należy blokować?

Najprostsza odpowiedź brzmi: to zależy. Nie każdy bot ma taką samą wartość i nie każdy generuje taki sam koszt. Część z nich może być całkowicie zbędna dla danego sklepu, część może wspierać widoczność treści w wyszukiwarkach lub narzędziach AI, a część może być po prostu agresywnym scraperem, który nie wnosi (w danym momencie) żadnej wartości biznesowej.

Warto przy tym pamiętać o szerszym trendzie: coraz więcej osób szuka produktów i usług nie w Google, ale pytając asystentów AI. Strona całkowicie odcięta od botów AI z czasem znika z odpowiedzi, rekomendacji i porównań generowanych przez te narzędzia. Dlatego celem nie jest blokada ruchu AI jako takiego, tylko odcięcie tej jego części, która generuje koszt bez wartości.

Dlatego problemem nie jest samo blokowanie botów, tylko blokowanie ich bez świadomości, co dokładnie odcinamy. W praktyce warto patrzeć na boty selektywnie:

• które boty generują duży ruch,
• które trafiają w kosztowne endpointy,
• które odwiedzają filtry, wyszukiwarkę, koszyk lub panel administracyjny,
• które mogą mieć wartość dla widoczności sklepu,
• które są wyłącznie obciążeniem.

Dopiero na tej podstawie można zdecydować, czy danego bota dopuścić, ograniczyć, czy całkowicie zablokować.

Warstwa 1: Cloudflare

Pierwszym krokiem było wpięcie Cloudflare. Klient wcześniej z niego nie korzystał, a nawet darmowa wersja daje sporo możliwości analizy i filtrowania ruchu. Po podłączeniu Cloudflare wdrożono kilka reguł bezpieczeństwa w sekcji: Cloudflare → Security → Security Rules

Strategia była dwupoziomowa: najpierw odciąć oczywiście niepotrzebny ruch geograficzny, a następnie ograniczyć boty chodzące po filtrach i ciężkich endpointach.

Reguła 1: blokada wybranych kontynentów

Pierwsza reguła blokowała ruch spoza Europy i Ameryki Północnej. Warto od razu zaznaczyć: główne crawlery, takie jak Googlebot, GPTBot czy ClaudeBot, skanują właśnie z Ameryki Północnej, więc ta reguła z założenia ich nie dotyczy. Geoblok służy do odsiania śmieciowego ruchu z pozostałych regionów, a nie do walki z botami AI.

(ip.src.continent in {"AF" "AN" "AS" "OC" "SA" "T1"})
Akcja:
Block

W tym konkretnym przypadku była to świadoma decyzja biznesowa. Sklep sprzedawał wyłącznie na rynek polski, więc ruch z Azji, Afryki, Oceanii czy Ameryki Południowej na stronach produktowych był uznany za mało wartościowy i w dużej części podejrzany.

To oczywiście nie jest reguła dla każdego sklepu. Jeżeli sklep sprzedaje globalnie, taki geoblok mógłby zaszkodzić sprzedaży. Ale przy sklepie nastawionym wyłącznie na Polskę był to akceptowalny kompromis.

Geoblok jest więc tylko pierwszą warstwą odsiewania, przygotowującą grunt pod kolejne reguły.

Reguła 2: Managed Challenge na filtrach

Druga reguła celowała w endpointy generujące crawl trap. W tym sklepie filtry obsługiwała własna wtyczka, która generowała adresy zawierające /f/.

Reguła wyglądała więc tak:

(http.request.uri.path contains "/f/")
Akcja:
Managed Challenge

W przypadku innych popularnych rozwiązań adresy filtrów mogą wyglądać inaczej. Dla przykładu przy niektórych konfiguracjach filtrów w URL-ach mogą pojawiać się segmenty łączone przez -or-.

Wtedy reguła może wyglądać tak:

(http.request.uri.path contains "-or-")
Akcja również:
Managed Challenge

Dlaczego nie twarde Block?

Bo filtry są potrzebne realnym klientom. Gdyby zablokować je całkowicie, użytkownicy mogliby stracić możliwość normalnego korzystania ze sklepu. Managed Challenge pozwala przerzucić decyzję na Cloudflare. Prawdziwy użytkownik w przeglądarce zwykle przechodzi weryfikację automatycznie, natomiast prosty bot bez obsługi JavaScriptu, cookies i sesji może utknąć na wyzwaniu.

To dobry kompromis: nie zabijamy funkcjonalności sklepu, ale utrudniamy masowe crawlowanie filtrów.

Reguła 3: twarda blokada zadeklarowanych botów na ciężkich endpointach

Trzecia reguła była bardziej precyzyjna. Łączyła dwa warunki:

1. żądanie trafia w ciężki endpoint, np. filtry, wyszukiwarkę, sortowanie, panel admina,
2. User-Agent wskazuje, że mamy do czynienia z botem.

Przykładowe fragmenty warunków obejmowały między innymi:

http.request.uri.path contains "/f/"
http.request.uri.path contains "-or-"
http.request.uri.query contains "filter_"
http.request.uri.query contains "min_price="
http.request.uri.query contains "max_price="
http.request.uri.query contains "orderby="
http.request.uri.query contains "product_count="
http.request.uri.query contains "dgwt_wcas"
oraz User-Agenty zawierające m.in.:
bot
spider
crawl
gptbot
amazonbot
applebot
perplexity
claudebot
bytespider
ccbot
cohere-ai

W tej regule można było zastosować twarde Block, ponieważ warunek był zawężony. Nie blokowano wszystkich użytkowników na filtrach, tylko żądania, które jednocześnie:

• trafiały w problematyczne endpointy,
• pochodziły od klienta deklarującego się jako bot.

To istotna różnica. Realny użytkownik nie wysyła w User-Agencie wartości typu GPTBot, ClaudeBot czy Bytespider.

Kolejność reguł ma znaczenie

W Cloudflare reguły powinny być ustawione tak, aby się uzupełniały, a nie przeszkadzały sobie nawzajem. W tym przypadku kolejność była następująca:

1. Geo-block – najpierw odcina niepotrzebne regiony.
2. Bot gate – twardo blokuje zadeklarowane boty na filtrach i ciężkich endpointach.
3. Crawler filters – łapie pozostały podejrzany ruch na filtrach przez Managed Challenge.

Dzięki temu jawne boty dostają blokadę, ukryte lub mniej oczywiste automaty dostają wyzwanie, a realni użytkownicy nadal korzystają ze sklepu. Po wdrożeniu tych reguł Cloudflare w ciągu doby pokazał między innymi:

• około 2,39 tys. zablokowanych żądań przez blokadę kontynentów,
• około 1,82 tys. zablokowanych żądań przez reguły dotyczące crawlerów na wyszukiwarce i filtrach.

Łącznie dało to ponad 4 tysiące zatrzymanych żądań w 24 godziny.

Problem: boty omijały Cloudflare i uderzały bezpośrednio w origin

Po wdrożeniu Cloudflare obciążenie lekko spadło, ale nie tak mocno, jak można było oczekiwać. W logach serwera nadal było widać ruch botów. To oznaczało, że część żądań omija Cloudflare i trafia bezpośrednio na serwer źródłowy, czyli origin.

Origin to właściwy serwer, na którym działa WordPress. Po poprawnym wdrożeniu Cloudflare ruch HTTP/S powinien przechodzić najpierw przez Cloudflare, a dopiero potem do originu. Jeżeli jednak ktoś zna prawdziwy adres IP serwera, może próbować połączyć się bezpośrednio, z pominięciem całej warstwy ochronnej.

W logach originu widać było między innymi żądania tego typu:

GPTBot GET /sklep/f/... 200 OK

Amazonbot GET /produkty/.../f/... 200 OK

Meta-externalagent GET /produkty/...-or-... 200 OK

Najważniejszy był tutaj kod odpowiedzi:

200 OK

Oznaczał on, że bot nie został zablokowany. Serwer wyrenderował pełną stronę, czyli wykonał kosztowną pracę. Cloudflare tego ruchu nie widział, bo żądania w ogóle przez niego nie przechodziły.

Test diagnostyczny

Problem potwierdził prosty test.

Żądanie przez Cloudflare:

curl -I -A "GPTBot" https://[domena-sklepu]/sklep/f/test/
Odpowiedź:
HTTP/2 403
Żądanie bezpośrednio na origin, z pominięciem Cloudflare:
curl -I --resolve [domena-sklepu]:443:<origin-ip> -A "GPTBot" https://[domena-sklepu]/sklep/f/test/
Odpowiedź:
HTTP/2 200

Wniosek był prosty: Cloudflare działał poprawnie dla ruchu, który przez niego przechodził. Problemem był ruch bezpośredni na origin.

Skąd boty mogą znać adres IP originu?

W materiale wskazano kilka możliwych źródeł:

• subdomeny pocztowe, takie jak imap, smtp czy poczta, które często nie są proxowane przez Cloudflare,
• publiczne logi Certificate Transparency,
• bazy passive DNS przechowujące historyczne rekordy A,
• nagłówki SMTP w wiadomościach wychodzących.

Niezależnie od źródła efekt jest ten sam: jeżeli bot zna prawdziwy adres IP serwera, może próbować ominąć Cloudflare. Dlatego sama konfiguracja na poziomie CDN/WAF nie wystarczyła. Trzeba było domknąć ochronę także na poziomie serwera.

Warstwa 2: blokada na poziomie .htaccess

Kolejnym krokiem było dodanie reguł w .htaccess. To ważna warstwa, bo działa wcześniej niż WordPress. Żądanie może zostać odrzucone przez Apache/LiteSpeed zanim uruchomi się PHP, WooCommerce, motyw i wtyczki.

Wdrożono dwa typy blokad:

1. hard block – dla botów uznanych za niewnoszące wartości dla sklepu,
2. soft block – dla botów AI tylko na ciężkich endpointach.

Przykładowa konfiguracja:

RewriteEngine On
# Hard block - boty bez wartości dla sklepu
RewriteCond %{HTTP_USER_AGENT} (Amazonbot|Bytespider|meta-externalagent|meta-webindexer|FacebookBot|CCBot|PetalBot|MJ12bot|DotBot|Sogou|SeznamBot|Baiduspider) [NC]
RewriteRule .* - [F,L]
# Soft block - AI boty blokowane tylko na ciężkich endpointach
RewriteCond %{HTTP_USER_AGENT} (GPTBot|ClaudeBot|PerplexityBot) [NC]
RewriteCond %{REQUEST_URI} (/f/|-or-|/koszyk|/zamowienie|/moje-konto|/wp-admin|/wp-json) [OR]
RewriteCond %{QUERY_STRING} (wc-ajax=|filter_|min_price=|max_price=|orderby=|product_count=|dgwt_wcas|^s=)
RewriteRule .* - [F,L]

Podejście było selektywne. Boty takie jak Amazonbot, Bytespider, crawlery Meta czy agresywne scrapery SEO zostały zablokowane twardo. W tym sklepie, sprzedającym wyłącznie na rynek polski, właściciel ocenił, że ruch Amazonbota nie przekłada się na żadną wartość biznesową. Dla sklepów obecnych na Amazon lub liczących na widoczność w Amazon Search i asystencie Rufus ta ocena może wyglądać zupełnie inaczej, dlatego to decyzja do podjęcia indywidualnie, a nie uniwersalna rekomendacja.

Natomiast boty AI, takie jak GPTBot, ClaudeBot czy PerplexityBot, były blokowane tylko na ciężkich endpointach:

• filtrach produktowych,
• kombinacjach -or-,
• koszyku,
• checkoucie,
• panelu użytkownika,
• /wp-admin,
• /wp-json,
• parametrach sortowania i wyszukiwania.

Strony produktów, kategorii i treści blogowe mogły pozostać dla nich dostępne. To najważniejsza zasada całego wdrożenia: nie blokować wszystkiego, tylko odciąć botom dostęp do miejsc, które generują największy koszt i najmniejszą wartość. Dzięki temu sklep pozostaje widoczny w odpowiedziach i rekomendacjach narzędzi AI, bo boty nadal mają dostęp do treści, które faktycznie mają wartość, a jednocześnie przestają krążyć po tysiącach kombinacji filtrów, które wartości nie mają żadnej.

Warstwa 3: własny plugin WordPress

Ostatnią warstwą był własny plugin WordPress. Jego zadaniem było złapanie przypadków, które przeszły przez wcześniejsze sita, oraz dodanie prostego rate limitu dla botów, które nadal miały dostęp do wybranych części strony.

Plugin działał bardzo wcześnie, na hooku plugins_loaded z priorytetem 1, czyli zanim załaduje się motyw, większość wtyczek i ciężka logika WooCommerce.

Uproszczony fragment mechanizmu:

add_action('plugins_loaded', function() {
$ua_lower = strtolower($_SERVER['HTTP_USER_AGENT'] ?? '');
$ip = $_SERVER['REMOTE_ADDR'] ?? 'unknown';
// Hard block + tarpit

foreach ($hard_block as $bot) {
if (strpos($ua_lower, $bot) !== false) {
sleep(rand(3, 8));
http_response_code(403);
header('Retry-After: 86400');
exit('Access denied');
       }
   }

// Soft block dla AI botów - tylko na ciężkich endpointach

foreach ($ai_bots as $bot) {
       if (strpos($ua_lower, $bot) !== false) {
           $should_block =
               strpos($uri, '/f/') !== false ||
               strpos($uri, '-or-') !== false ||
               preg_match('/wc-ajax=|filter_|orderby=/', $query);

           if ($should_block) {
               http_response_code(429);
               exit('Rate limited');
           }
           apply_rate_limit($ip, $bot, 30, 60);
       }
   }
}, 1);

Plugin realizował trzy funkcje.

1. Tarpit dla wybranych botów

Dla botów z grupy hard block zastosowano tzw. tarpit, czyli krótkie opóźnienie przed zwróceniem odpowiedzi 403.

sleep(rand(3, 8));

Z perspektywy bota oznacza to wolniejszą odpowiedź. Z perspektywy CPU koszt jest niski, bo proces w tym czasie „śpi”.

Trzeba jednak bardzo uważać z takim mechanizmem. Śpiący proces nadal zajmuje workera PHP. Przy bocie wysyłającym wiele równoległych żądań zbyt długi sleep może zaszkodzić stronie, bo zajmie pulę workerów potrzebną realnym użytkownikom.

Dlatego w tym wdrożeniu tarpit zastosowano tylko dla wybranych botów i tylko jako element hard blocku. Na hostingu współdzielonym, gdzie liczba równoległych procesów PHP jest ograniczona, tarpit należy stosować bardzo ostrożnie albo wcale. Bezpieczniejszą opcją jest szybka odpowiedź 403, która natychmiast zwalnia proces.

2. Soft block dla AI botów na ciężkich endpointach

Dla botów AI zastosowano odpowiedź: Too Many Requests

ale tylko wtedy, gdy trafiały w ciężkie endpointy: filtry, koszyk, panel administracyjny, API lub parametry generujące dynamiczne widoki.

To ważne rozróżnienie. Błąd 429 komunikuje ograniczenie tempa lub dostępności, ale nie jest tak definitywny jak 403. Dodatkowo odpowiedź była zwracana szybko, bez opóźnienia, żeby jak najszybciej zwolnić worker PHP.

3. Rate limit per bot per IP

Dla botów, które mogły odwiedzać dozwolone części sklepu, wdrożono prosty rate limit per bot i per IP.

Licznik żądań był przechowywany jako plik JSON w katalogu tymczasowym, bez angażowania bazy danych. To świadomy kompromis: mechanizm nie jest idealny przy dużej współbieżności, ale jest lekki i nie dokłada obciążenia do MySQL. Przykładowe limity z materiału:

• GPTBot: 30 żądań na minutę,
• SemrushBot: 10 żądań na minutę,
• AhrefsBot: 30 żądań na minutę.

Wartości zostały dobrane na podstawie tego, co realnie było widać w logach.

Warstwa 4: robots.txt

Ostatnim elementem był plik robots.txt.

Przykład:

User-agent: GPTBot
Disallow: /sklep/f/
Disallow: /produkty/*/f/
Disallow: /*-or-*
Disallow: /*?orderby=
Disallow: /*?filter_*
User-agent: ChatGPT-User
Allow: /
User-agent: Amazonbot
Disallow: /
User-agent: meta-externalagent
Disallow: /

Trzeba jednak powiedzieć jasno: robots.txt nie jest zabezpieczeniem. To prośba, nie zapora. Część botów respektuje te reguły, ale część je ignoruje. Dotyczy to szczególnie botów wywoływanych na żądanie użytkownika, takich jak ChatGPT-User czy Perplexity-User, które pobierają stronę w momencie, gdy ktoś o nią zapyta w czacie i nie zawsze sprawdzają robots.txt. To kolejny argument, żeby realną ochronę opierać na blokadach serwerowych. W analizowanym przypadku w logach nadal było widać żądania do adresów, które zgodnie z intencją nie powinny być crawlowane.

Warto też pamiętać, że niektóre nazwy, jak Applebot-Extended czy anthropic-ai, to tokeny przeznaczone wyłącznie do pliku robots.txt. Nie występują jako User-Agent w żądaniach HTTP, więc dodawanie ich do reguł .htaccess lub Cloudflare nie zablokuje żadnego ruchu. Jeżeli chcesz ograniczyć wykorzystanie treści do trenowania modeli Apple, właściwym miejscem jest właśnie robots.txt z tokenem Applebot-Extended.

Dlatego robots.txt należy traktować jako warstwę informacyjną dla botów dobrej woli. Twardą ochronę zapewniały dopiero:

1. Cloudflare,
2. .htaccess,
3. plugin WordPress.

Efekt wdrożenia

Poprawa przyszła w dwóch fazach. Pierwsza faza, czyli Cloudflare, dała widoczny efekt w statystykach zablokowanych żądań. W ciągu około 24 godzin Cloudflare zatrzymał ponad 4 tysiące żądań związanych z geoblokadą i ruchem crawlerów na filtrach oraz wyszukiwarce. Wpływ na CPU był jednak ograniczony, bo część botów nadal omijała Cloudflare i uderzała bezpośrednio w origin.

Druga faza, czyli .htaccess oraz plugin WordPress, przyniosła właściwy spadek obciążenia. Boty omijające Cloudflare zaczęły dostawać odpowiedzi 403 lub 429 na poziomie serwera albo bardzo wczesnego etapu WordPressa, zanim uruchamiała się ciężka logika WooCommerce.

Według danych z wdrożenia CPU sustained spadło z około: 5 GHz do około: 1,5 GHz czyli o około 65% względem stanu sprzed wdrożenia.

Po ustabilizowaniu sytuacji można było wrócić do pierwotnego limitu rdzeni w panelu hostingu, który wcześniej został tymczasowo podniesiony na czas diagnozy.

Końcowa architektura ochrony

Ostateczne rozwiązanie było oparte o kilka warstw.

1. Cloudflare WAF

Cloudflare łapał ruch, który przechodził przez CDN. Tu działały:

• reguły geograficzne,
• blokady botów,
• Managed Challenge na filtrach,
• Custom Rules dla ciężkich endpointów.

2. .htaccess

Reguły na poziomie Apache/LiteSpeed łapały ruch bezpośredni na origin, czyli taki, który omijał Cloudflare.

To była kluczowa warstwa dla botów uderzających bezpośrednio w IP serwera.

3. Plugin WordPress

Plugin obsługiwał przypadki brzegowe:

• tarpit dla wybranych botów,
• soft block dla AI botów na kosztownych endpointach,
• rate limit per bot per IP.

Działał bardzo wcześnie, żeby ograniczyć koszt obsługi niechcianych żądań.

4. robots.txt

robots.txt pełnił rolę sygnału dla botów respektujących standard. Nie był traktowany jako realna zapora, tylko jako dodatkowa warstwa informacyjna.

Najważniejsze wnioski

Największy problem nie polegał na tym, że sklep miał za mało zasobów. Problemem był wzorzec ruchu: boty AI i scrapery trafiały w dynamiczne adresy generowane przez filtry WooCommerce, powodując tysiące kosztownych żądań, których cache nie był w stanie skutecznie obsłużyć.

Samo zwiększenie CPU mogło pomóc chwilowo, ale nie usuwało przyczyny. Samo Cloudflare również nie wystarczyło, bo część ruchu omijała CDN i trafiała bezpośrednio na origin.

Dopiero połączenie kilku warstw dało realny efekt:

• Cloudflare ograniczył ruch przechodzący przez CDN,
• .htaccess zatrzymał boty uderzające bezpośrednio w serwer,
• plugin WordPress dodał rate limiting i obsługę przypadków brzegowych,
• robots.txt przekazał instrukcje botom, które respektują standard.

W praktyce najlepszym podejściem nie okazało się „blokujemy wszystkie boty”, tylko:

blokujemy botom dostęp do miejsc, które generują nam największy (zbędny) koszt, a zostawiamy otwarte te części sklepu, które mogą mieć wartość biznesową.

Dla sklepów WooCommerce szczególnie ważne są filtry, sortowania, wyszukiwarka, koszyk, checkout, panel użytkownika i API. To właśnie tam najczęściej powstaje crawl trap, który potrafi zamienić zwykły sklep w generator tysięcy ciężkich, dynamicznych żądań.

Ten przypadek dobrze pokazuje, że ruch botów nie powinien być traktowany zero-jedynkowo. Dla jednego sklepu dany crawler może być neutralny albo wręcz pożądany, dla innego – całkowicie zbędny. Wszystko zależy od rynku, typu strony, modelu sprzedaży, widoczności w AI i tego, jak bot zachowuje się w praktyce.

Najgorszym scenariuszem jest sytuacja, w której właściciel sklepu nie wie, kto odwiedza jego stronę, ile kosztuje go ten ruch i które boty generują największe obciążenie. Najlepszym – gdy może zobaczyć najaktywniejsze boty i świadomie zdecydować, które z nich chce dopuścić, a które nie mają dla niego żadnej wartości.

Od redakcji dhosting

Część opisanej w tym case study ochrony zrealizujesz dziś bezpośrednio w dPanelu. Serwerową blokadę wybranych botów po User-Agencie, którą autor skonfigurował ręcznie w .htaccess, włączysz w sekcji Boty AI jednym przełącznikiem, bez edycji plików konfiguracyjnych i bez wiedzy technicznej. Blokada działa na poziomie serwera, więc obejmuje także ruch omijający Cloudflare i trafiający bezpośrednio w origin, a zablokowany bot otrzymuje odpowiedź 403, zanim uruchomi się PHP i WordPress.

Sekcję znajdziesz w dPanelu: Strony WWW, wybierz stronę, Boty AI. Przy każdym bocie zobaczysz opis jego działania oraz naszą rekomendację, a blokadę włączysz i wyłączysz w dowolnym momencie, osobno dla każdej strony www. Domyślnie wszystkie boty pozostają dozwolone. To Ty decydujesz, które z nich mają dostęp do Twojej strony. Instrukcję krok po kroku ze zrzutami ekranu znajdziesz w artykule Aktywacja blokady botów AI w dPanelu.

Bardziej zaawansowane elementy, takie jak reguły warunkowe na ciężkich endpointach czy rate limiting, nadal wymagają własnej konfiguracji, dokładnie takiej, jaką opisał autor. Przegląd dodatkowych warstw ochrony (robots.txt, metatagi, TDMRep, twarda blokada na serwerze) zebraliśmy w poradniku Jak w uniwersalny sposób blokować boty AI i LLM na stronie WWW.