Visitor Control: blokowanie złych botów i niechcianego ruchu

Otwórz panel administracyjny PrestaShop, przejdź do Statystyki → Odwiedzający online w spokojne popołudnie, a możesz zobaczyć więcej „odwiedzających” niż masz rzeczywistych klientów. Duża część ruchu w każdym sklepie jest zautomatyzowana, crawlery, scrapery, skrypty i sondy, które nigdy nie zamierzają niczego kupić. Część tej automatyzacji jest krwiobiegiem Twojego biznesu: Googlebot musi indeksować sklep, aby mógł on pojawiać się wysoko w wynikach wyszukiwania. Reszta kosztuje Cię pieniądze. Zużywa CPU i transfer na hostingu, wypełnia tabele koszyków śmieciowymi danymi, zniekształca każdy raportowany wskaźnik konwersji, a, w przypadku botów testujących wykradzione dane logowania i skanerów podatności, bywa pierwszym krokiem realnego ataku. Ten poradnik pokazuje, jak odróżnić te dwie grupy w sklepie PrestaShop, jak wykryć tę szkodliwą we własnych logach i bazie danych oraz jak ją odciąć, nie blokując przypadkiem Google ani prawdziwego klienta.

To rozdział o botach i automatyzacji w naszej serii poświęconej bezpieczeństwu. Celowo trzyma się swojego zakresu: blokowanie pojedynczych uciążliwych ludzi po adresie IP omawiamy w artykule Customer Extra Info and IP Bans; zatrzymywanie spamu w formularzach za pomocą wyzwania opisuje reCAPTCHA for PrestaShop; przeciążenie wyszukiwania fasetowego wywołane przez crawlery ma osobną, szczegółową analizę w tekście o przetrwaniu zalewu ?q=; a reguły serwera WWW znajdziesz w artykule reguły bezpieczeństwa PrestaShop .htaccess. Jeśli chcesz zobaczyć, gdzie filtrowanie botów mieści się w szerszym obrazie, zacznij od pełnej listy kontrolnej wzmacniania bezpieczeństwa.

Zrecenzowano w czerwcu 2026 pod kątem aktualnego działania Statystyk PrestaShop i Menedżera SQL oraz nadal obowiązujących zaleceń dotyczących weryfikacji Googlebota przez odwrotny DNS.

Nie wszystkie boty są wrogiem, a blokowanie niewłaściwych szkodzi

Najdroższym błędem, jaki sprzedawcy popełniają przy blokowaniu botów, jest nadmierne blokowanie. Zablokuj Googlebota w przypływie zapału pod hasłem „zatrzymać boty”, a nie dostaniesz bezpieczniejszego sklepu, dostaniesz sklep, który znika z wyszukiwarki. Dlatego pierwszym zadaniem jest jasna taksonomia, bo reguły blokowania będą traktować te dwie grupy w przeciwny sposób.

Zwróć uwagę na wniosek: toporne narzędzie, które blokuje „boty” wyłącznie na podstawie reputacji, jest niebezpieczne, bo dobre i złe listy nakładają się pod względem stosowanych technik. Skuteczne filtrowanie dotyczy tożsamości i zachowania, a nie jednego przełącznika włącz/wyłącz.

Jak rozpoznać ruch złych botów konkretnie w PrestaShop

Nie potrzebujesz zewnętrznego panelu analitycznego, żeby zobaczyć problem, PrestaShop już rejestruje większość danych, a resztę zapisuje Twój hosting. Są trzy miejsca, do których warto zajrzeć, od najłatwiejszego.

1. Statystyki w panelu administracyjnym (kontrola w dwie minuty)

W sekcji Statystyki panele Pochodzenie odwiedzających, Nie znaleziono stron i Najczęściej oglądane strony są cichymi sygnałami ostrzegawczymi. Zalew błędów 404 na ścieżkach, których Twój sklep nigdy nie miał (/wp-login.php, /.env, /administrator/), to skaner podatności przechodzący po ogólnej liście exploitów. To nawet nie są ścieżki PrestaShop, i właśnie po tym widać, że masz do czynienia z bezmyślnym botem. „Najczęściej oglądana strona”, która nagle jest stroną logowania albo odzyskiwania hasła, a nie produktem, to typowy podpis ataku z użyciem wykradzionych danych logowania.

2. Baza danych (uczciwe liczby)

PrestaShop zapisuje sesje w ps_connections i ps_guest. Pamiętaj, że ps_guest przechowuje przetworzone atrybuty przeglądarki i systemu operacyjnego (przeglądarka, wersja, system operacyjny, rozdzielczość ekranu), a nie surowy ciąg User-Agent. W standardowym PrestaShop nie ma kolumny http_user_agent, więc nie spodziewaj się, że odczytasz dosłowny identyfikator agenta z bazy. Tabele dają natomiast wolumen żądań na adres IP, a to wystarcza, żeby wyłapać źródło bombardujące sklep. Zapytanie takie jak poniżej (uruchom je w Parametry zaawansowane → Menedżer SQL, dostosuj prefiks) szereguje ostatnich odwiedzających według liczby odsłon:

SELECT c.ip_address, COUNT(*) AS hits FROM ps_connections c WHERE c.date_add > DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY c.ip_address ORDER BY hits DESC LIMIT 50;

Pojedynczy adres IP z setkami odsłon w ciągu jednego dnia nie jest klientem. Prawdziwy kupujący ładuje kilka stron; scraper przechodzi po całym katalogu po kolei. Aby zobaczyć rzeczywisty User-Agent wysłany przez każdy adres IP, a właśnie tam scrapery często zdradzają się pustymi, generycznymi albo skryptowymi identyfikatorami, przeczytaj surowy log dostępu serwera (omówiony niżej) albo użyj modułu zapisującego surowy User-Agent, ponieważ własne tabele PrestaShop nie przechowują go dosłownie.

3. Tabele koszyków (charakterystyczny ślad PrestaShop)

Oto objaw niemal unikalny dla PrestaShop, który dezorientuje tysiące sprzedawców: dziesiątki porzuconych koszyków bez klienta i bez produktów, pojawiających się w Zamówienia → Koszyki zakupowe. PrestaShop tworzy wiersz koszyka w swoich przepływach koszyka i sesji w momencie dotknięcia punktu końcowego dodawania do koszyka. Puste koszyki gości mogą powstawać z wielu powodów, botów i crawlerów, modułów tworzących koszyki z wyprzedzeniem albo zwykłego zachowania sesji, więc nie zakładaj, że odpowiada za nie konkretny crawler. Zanim oskarżysz, zablokujesz albo dodasz do białej listy jakiegokolwiek crawlera, potwierdź w logach, które źródło faktycznie trafiło w ten punkt końcowy. Koszyki są prawdziwymi wierszami w bazie danych, ale w takich przypadkach są artefaktami, nie utraconą sprzedażą, a właściwą reakcją jest ich rozpoznanie i czyszczenie, nie blokowanie crawlera, którego udziału nie potwierdziłeś. Rozłożyliśmy to na części w naszej notatce o koszykach tworzonych przez boty; praktyczny wniosek jest taki, że puste koszyki gości zwykle są osobliwością logowania, a nie sytuacją alarmową.

4. Log dostępu serwera (źródło prawdy)

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

Surowy log dostępu pokazuje każde żądanie wraz z adresem IP, User-Agentem i czasem. To źródło prawdy, którego analityka nie może udawać, bo analityka oparta na JavaScript w przypadku większości botów nawet się nie uruchamia. Szukaj jednego adresu IP żądającego stron produktów w idealnej kolejności, żądań bez User-Agenta oraz serii wejść na /login, /password-recovery i create-account. W tym logu potwierdzisz też, czy „Googlebot” jest prawdziwy, autentyczny Googlebot w odwrotnym wyszukiwaniu DNS rozwiązuje się do hosta googlebot.com / google.com; fałszywy tylko podaje tę nazwę, ale rozwiązuje się do losowego adresu IP z centrum danych.

Drabina obrony: najpierw najtańsze i najszersze warstwy

Filtrowanie botów działa warstwowo, a rozsądna kolejność polega na tym, by zacząć od mechanizmów, które zatrzymują najwięcej ruchu przy najmniejszym wysiłku i najniższym ryzyku fałszywego alarmu. Wchodzisz po tej drabinie tylko tak wysoko, jak wymaga tego Twój problem.

robots.txt, ustaw oczekiwania, nie barierę

PrestaShop może wygenerować sensowny robots.txt w sekcji Parametry sklepu → Ruch & SEO → SEO & URL-e → Generuj robots.txt. Plik mówi dobrze wychowanym crawlerom, aby pomijały koszyk, realizację zamówienia, wyniki wyszukiwania i strony konta, co ogranicza marnowanie budżetu indeksowania przez boty, które chcesz zatrzymać. Rozumiej jasno jego ograniczenie: dobre boty go respektują, złe ignorują, więc jest to narzędzie budżetu indeksowania, nigdy kontrola bezpieczeństwa. Nie wpisuj tam ścieżki z nadzieją, że ją ukryjesz; publikujesz mapę tego, czego wolałbyś nie pokazywać.

WAF na brzegu sieci, krok o największej dźwigni

Postawienie Cloudflare (albo porównywalnego WAF) przed sklepem przenosi walkę całkowicie poza Twój hosting: znane złe adresy IP, żądania niewyglądające jak prawdziwa przeglądarka i zalewy wolumetryczne są filtrowane na brzegu sieci, zanim kiedykolwiek dotrą do PHP. W darmowym planie dostajesz tryb walki z botami, bazę reputacji IP, kontrole integralności przeglądarki i podstawowe reguły limitowania tempa, wystarczająco dużo, by zdjąć większość śmieciowej automatyzacji z serwera. Dla większości małych i średnich sklepów PrestaShop ten jeden ruch robi więcej niż wszystko inne razem wzięte, a to ta sama warstwa brzegowa, na której mocniej oprzesz się wtedy, gdy ruch crawlerów zmieni się w zalew ?q= w wyszukiwaniu fasetowym zdolny położyć sklep.

Limitowanie tempa, oddzielanie ludzi od skryptów po prędkości

Prawdziwy klient przeglądający sklep ładuje może pięć do dziesięciu stron na minutę; scraper przechodzący po katalogu ładuje ich sto. Limit tempa per IP (zwracający HTTP 429 po przekroczeniu progu) automatycznie wyłapuje tę różnicę. Najbardziej niezawodnie działa na brzegu sieci (Cloudflare) albo na poziomie serwera WWW. Ustawiaj go hojnie, sufit powinien być wyraźnie powyżej ludzkiego przeglądania, aby wspólne IP biura albo operatora komórkowego, za którym siedzi wielu prawdziwych klientów, nie zostało ukarane za duży ruch.

Wyzwania formularzy i honeypoty, dla formularzy na celowniku

Scrapery chcą Twoich stron; boty spamujące chcą Twoich formularzy. Rejestracja, logowanie, kontakt i newsletter to miejsca, w których koncentrują się automatyczne wysyłki, a niewidoczne wyzwanie zatrzymuje je bez męczenia prawdziwych kupujących, to osobny temat opisany w reCAPTCHA for PrestaShop. Honeypot je uzupełnia: ukryte pole, którego człowiek nigdy nie zobaczy, ale głupi automat do wypełniania formularzy posłusznie uzupełni, sam oznaczając się jako bot bez żadnego kosztu dla klientów.

Blokowanie po tożsamości z panelu administracyjnego PrestaShop

Warstwy powyżej to infrastruktura. Potrzebujesz jednak także mechanizmu, po który sięgniesz bez SSH i bez dewelopera, miejsca, w którym możesz powiedzieć „z tego kraju mam tylko oszustwa i scrapery, pokaż mu wyzwanie” albo „ten User-Agent z hostingu bombarduje logowanie, zablokuj go” bezpośrednio z administracji. To warstwa aplikacji i właśnie tutaj natywne działanie w PrestaShop się opłaca: blokada wykonywana jest z pełnym kontekstem sesji (zna grupę klienta, kraj, agenta) i przetrwa aktualizacje szablonu oraz rdzenia, bo nie jest doklejona do plików konfiguracji serwera, o których później zapomnisz.

Jedna uwaga, zanim sięgniesz po blokadę IP: blokuj adresy IP chirurgicznie. Adresy domowe i komórkowe są recyklingowane. Dzisiejszy adres IP scrapera może jutro należeć do płacącego klienta u tego samego operatora. Pojedyncze domowe adresy IP blokuj tylko jako krótkotrwały, przeglądany środek; trwałe blokady zakresów IP zostaw dla centrów danych i VPN-ów, gdzie nie ma prawdziwych klientów. (Blokowanie konkretnej nadużywającej osoby po IP to inne zadanie, obsługiwane w Customer Extra Info and IP Bans.) Przy szerokich działaniach reguły krajów i User-Agentów są zwykle bezpieczniejsze i mniej pracochłonne niż gonienie pojedynczych adresów.

Gdzie pasuje Visitor Control

Visitor Control przechowuje decyzje blokowania właściwe dla sklepu w panelu administracyjnym.

Dodanie zaufanych sieci do białej listy zapobiega temu, by szerokie reguły blokad objęły Twój własny zespół.

Tabela zebranych odwiedzających to ps_mprvc_info. Ta szybka kontrola pokazuje, czy w ostatnim ruchu dominuje jeden kraj albo typ urządzenia:

SELECT country_code, device_type, COUNT(*) AS hits
FROM ps_mprvc_info
WHERE date_add > DATE_SUB(NOW(), INTERVAL 24 HOUR)
GROUP BY country_code, device_type
ORDER BY hits DESC
LIMIT 20;

Właśnie tę lukę miał zamknąć nasz moduł Visitor Control. Wykonuje dwa zadania z poziomu panelu administracyjnego, bez konfiguracji na serwerze i bez podłączania zewnętrznej usługi. Po pierwsze, blokuje niechcianych odwiedzających po IP, kraju albo User-Agencie, możesz więc po cichu odprawić znanego scrapera albo kraj, z którego przychodzi wyłącznie ruch testujący karty płatnicze, korzystając z własnej obsługi żądań PrestaShop zamiast ręcznie edytowanych linii w .htaccess. Po drugie, pokazuje, kim naprawdę są Twoi odwiedzający: urządzenie, IP i kraj widoczne bezpośrednio na profilu klienta, dzięki czemu przy ocenie, czy dany wzorzec to bot, czy prawdziwy kupujący, opierasz się na dowodach, a nie zgadywaniu. Co Ci to daje? Decyzja o zablokowaniu albo przepuszczeniu przestaje być zadaniem administratora serwera, które odkładasz na później, a staje się dwuminutową decyzją podejmowaną z tego samego ekranu, z którego prowadzisz sklep, a ponieważ to moduł, reguły przetrwają kolejną aktualizację PrestaShop.

W przypadku opisanego wcześniej, specyficznego dla PrestaShop szumu z koszykami botów, pustych koszyków gości zniekształcających liczniki w panelu administracyjnym, właściwe narzędzia są po stronie koszyków: oznaczają i czyszczą koszyki botów bez blokowania crawlerów, które mogą je legalnie tworzyć. Sens rozdzielenia tych zadań polega na precyzji: filtrujesz ruch, którego nie chcesz, a jednocześnie zachowujesz boty budujące pozycje w wyszukiwarce i indeksowanie, które przekłada się na sprzedaż.

Praktyczna konfiguracja warstwowa dla normalnego sklepu

Nie potrzebujesz korporacyjnej umowy na zarządzanie botami, żeby poradzić sobie z codziennym zalewem. W typowym sklepie PrestaShop taki zestaw zatrzymuje zdecydowaną większość złej automatyzacji przy niewielkiej konfiguracji i zasadniczo bez ryzyka dla prawdziwych klientów:

• Postaw darmowy plan Cloudflare przed sklepem, największa pojedyncza redukcja śmieciowego ruchu, na brzegu sieci, zanim kosztuje Cię choćby cykl CPU.
• Wygeneruj poprawny robots.txt z sekcji Ruch & SEO, aby dobre crawlery pomijały koszyk, wyszukiwanie i strony konta oraz wydawały swój budżet na produkty.
• Dodaj niewidoczne wyzwanie do formularzy rejestracji, logowania, kontaktu i newslettera.
• Blokuj po kraju i User-Agencie wzorce, które potwierdziłeś jako boty, z panelu administracyjnego, a blokady IP utrzymuj krótkie i celowane.
• Raz w miesiącu przejrzyj logi i zapytanie w Menedżerze SQL, blokuj potwierdzonych recydywistów i weryfikuj każdy podejrzany „Googlebot” przez odwrotny DNS, zanim mu zaufasz.

Najczęściej zadawane pytania

Czy blokowanie botów zaszkodzi mojej pozycji w Google?

Tylko jeśli zablokujesz niewłaściwe. Crawlery wyszukiwarek (Googlebot, Bingbot) i boty podglądu w mediach społecznościowych muszą mieć do Ciebie dostęp, zablokuj je, a w kolejnych tygodniach Twoje strony wypadną z wyszukiwarki albo udostępnione linki będą wyświetlać się bez podglądu. Cała praca polega na odróżnieniu ich od scraperów, botów testujących dane logowania i skanerów podatności. Blokuj po potwierdzonej tożsamości i zachowaniu, weryfikuj każdego „Googlebota” odwrotnym DNS przed obdarzeniem go zaufaniem, a ograniczysz śmieciowy ruch bez ruszania botów, które przyprowadzają klientów.

Dlaczego mój sklep ma tyle pustych porzuconych koszyków bez klienta?

PrestaShop tworzy wiersz koszyka w momencie dotknięcia punktu końcowego dodawania do koszyka, więc puste koszyki gości mogą pochodzić od botów, crawlerów, modułów tworzących koszyki z wyprzedzeniem albo zwykłego zachowania sesji. To prawdziwe wiersze, ale zwykle artefakty, nie utracona sprzedaż. Nie zakładaj, że odpowiada za nie konkretny crawler, potwierdź w logu dostępu, które źródło faktycznie trafiło w ten punkt końcowy, a potem wyczyść szum zamiast ślepo blokować crawlera, którego udziału nie potwierdziłeś.

Czy robots.txt wystarczy, żeby trzymać złe boty z dala?

Nie. robots.txt jest respektowany przez dobre crawlery i ignorowany przez złe, więc jest narzędziem budżetu indeksowania, nigdy kontrolą bezpieczeństwa. Warto go wygenerować (Ruch & SEO → Generuj robots.txt), aby zatrzymać uprzejme crawlery przed marnowaniem budżetu na URL-e koszyka, wyszukiwania i konta, ale nigdy nie wpisuj tam ścieżki z nadzieją, że ją ukryjesz, bo publikujesz mapę tego, czego wolałbyś nie pokazywać. Dla botów, które go ignorują, potrzebujesz WAF na brzegu sieci, limitowania tempa i blokowania opartego na tożsamości.

Jaka jedna rzecz da mi największy efekt?

W przypadku większości małych i średnich sklepów postaw darmowy plan Cloudflare (albo porównywalny WAF) przed sklepem. Filtruje znane złe adresy IP, oczywiste nie-przeglądarki i zalewy wolumetryczne na brzegu sieci, zanim kiedykolwiek dotrą do PHP, a nawet w darmowym planie dostajesz tryb walki z botami, reputację IP, kontrole integralności przeglądarki i podstawowe limitowanie tempa. Ten jeden ruch zazwyczaj robi więcej niż wszystko inne razem wzięte.

Czy powinienem trwale blokować adresy IP scraperów?

Działaj chirurgicznie. Adresy domowe i komórkowe są recyklingowane. Dzisiejszy adres IP scrapera może jutro należeć do płacącego klienta u tego samego operatora, dlatego pojedyncze domowe adresy IP blokuj tylko jako krótkotrwały, przeglądany środek. Trwałe blokady zakresów rezerwuj dla centrów danych i VPN-ów, gdzie nie ma prawdziwych klientów, a przy szerszych działaniach preferuj reguły krajów i User-Agentów, bo są bezpieczniejsze i mniej wymagające w utrzymaniu niż gonienie pojedynczych adresów.

Nastawienie, które utrzymuje to podejście w ryzach, jest tym samym, od którego zaczęliśmy: celem nigdy nie jest „blokować boty”, tylko „blokować boty, które Ci zabierają, i wpuszczać te, które przyprowadzają klientów”. Dobrze ustaw taksonomię, czytaj dowody z własnego sklepu, zanim użyjesz młotka, i dodawaj warstwy tylko tak daleko, jak zmusza Cię ruch. Zrobione w ten sposób filtrowanie botów jest jedną z cichszych wygranych w bezpieczeństwie sklepu. Niewidoczne dla klientów, którzy mają znaczenie, a jednocześnie zatrzymujące stały odpływ zasobów, jakości analityki i powierzchni ataku, którą w przeciwnym razie oddawałbyś skryptom. Gdy zechcesz wpiąć to w resztę zabezpieczeń, lista kontrolna wzmacniania bezpieczeństwa i napisany prostym językiem poradnik bezpieczeństwa dla właścicieli sklepów spinają całą serię w całość.