Jak przetrwać zalew ?q=: gdy ruch robotów zamienia wyszukiwanie fasetowe PrestaShop w ryzyko DoS

Budzisz się i widzisz serię wiadomości od klientów z pytaniem, dlaczego strona nie działała o 3 w nocy. Liczba zamówień wygląda normalnie, strona błędu pojawia się tylko chwilami, a panel administracyjny nie pokazuje nic podejrzanego. Hosting wysyła wykres: połączenia MySQL dobiły do limitu, a wszystkie procesy PHP-FPM były zajęte. Żadne z tych żądań nie pochodziło od prawdziwych klientów.

Sklep PrestaShop z wyszukiwaniem fasetowym może być narażony na ten wzorzec zależnie od adresów URL, ruchu robotów i wydajności. Problem ma banalny kształt, przyczyna jest strukturalna, a właściwe rozwiązanie nie jest tym, po które właściciele sklepów zwykle sięgają jako pierwsze. To opis tego, jak faktycznie się przed nim bronić, konkretnie przed zalewem ?q=: momentem, w którym zwykły ruch robotów indeksujących zamienia Twoje własne wyszukiwanie fasetowe w samonapędzającą się powierzchnię odmowy usługi. Ten wpis jest głęboką analizą jednego trybu awarii; jeśli chcesz zobaczyć szerszy obraz, nasza checklista wzmacniania bezpieczeństwa PrestaShop spina wszystkie warstwy w całość.

Objaw

Logi pokazują tysiące żądań do adresów takich jak /category-slug?q=Brand-Brand-A/Brand-Brand-B/Color-Red, każde trochę inne, przychodzące z rotujących adresów IP i z mieszanką deklarowanych user agentów. Część podaje się za Bingbota, część za Chrome, część przedstawia się jako GPTBot, ClaudeBot albo PerplexityBot. Sam adres kategorii jest prawidłowy: to Twoje własne wyszukiwanie fasetowe wystawia filtry marek i atrybutów jako parametry query string. Nieprawidłowa jest skala oraz kombinatoryczna różnorodność tych żądań.

Na forach PrestaShop przez cały 2024 i 2025 rok pojawiały się zgłoszenia tego wzorca od właścicieli sklepów działających na wersjach 1.7.x i 8.x. Schemat jest spójny: już jeden wątek dokumentuje przypadki, w których właściciele sklepów widzieli dziesiątki tysięcy unikalnych adresów URL ?q= indeksowanych dziennie, a kontroler odpowiadał dalej nawet po wyłączeniu modułu ps_facetedsearch.

Pierwszym odruchem właścicieli jest często wyłączenie modułu wyszukiwania fasetowego. Może to ograniczyć obliczenia związane z filtrowaniem, ale nie zatrzymuje żądań do znanych adresów. ps_facetedsearch zapewnia interfejs i logikę filtrów; żądanie GET do /category-slug?q=anything może nadal uruchomić PrestaShop i trafić do kontrolera kategorii po wyłączeniu modułu. Panel filtrów znika, lecz zautomatyzowane programy mogą dalej wywoływać odkryte wcześniej URL-e.

Dlaczego skala rośnie

Kombinatoryczny charakter adresów URL wyszukiwania fasetowego istnieje od czasu pojawienia się modułu. Nowa jest skala zautomatyzowanego ruchu, który znajduje te adresy i je indeksuje.

Analiza Cloudflare z lipca 2025 roku dotycząca ruchu robotów indeksujących w całej sieci Cloudflare wykazała:

• Ruch robotów indeksujących wzrósł o 18% rok do roku, ze szczytami na poziomie 32% w kwietniu 2025 roku.
• Googlebot: wzrost o 96%, z około 30% do 50% całego ruchu indeksującego.
• GPTBot: wzrost o 305%, udział z 2,2% do 7,7%.
• PerplexityBot: z poziomu praktycznie zerowego do zauważalnego w ciągu jednego roku.
• ClaudeBot: spadek liczby żądań o 46% po zmianach z początku 2025 roku.
• Bytespider: spadek o 85%.

Skład tego ruchu zmienia się z miesiąca na miesiąc, ale trend pozostaje ten sam: więcej robotów, więcej adresów URL, częstsze wejścia. Strona kategorii generująca kilkaset kombinacji filtrów staje się celem wszystkiego: od Googlebota budującego indeksy danych strukturalnych po roboty zbierające atrybuty produktów do danych treningowych AI. W połowie 2025 roku Cloudflare zaczęło domyślnie blokować boty trenujące AI w nowych strefach, co jasno pokazuje, jak platforma ocenia kierunek zmian.

Na prawidłowy ruch robotów indeksujących nakłada się znacznie mniejsza, ale bardziej agresywna warstwa wrogiej automatyzacji: programy do masowego pobierania danych, boty wywiadu konkurencyjnego i ruch testujący odporność serwera. One nie respektują robots.txt, agresywnie rotują adresy IP i fałszują legalnie wyglądające ciągi user-agent. Mogą przeciążyć sklep, choć prawidłowe roboty również mogą generować nadmierne obciążenie. Zatrzymywanie tej szerszej kategorii niechcianej automatyzacji, nie tylko zalewu ?q=, to osobna dyscyplina; ogólne podejście opisujemy we wpisie o blokowaniu złych botów i niechcianego ruchu.

Dlaczego oczywiste poprawki nie działają

Większość porad z forów społecznościowych wpada do jednego z pięciu koszyków. Żadna z nich samodzielnie nie wystarczy.

Wyłączenie modułu wyszukiwania fasetowego. Usuwa interfejs, zostawia powierzchnię URL. Kontroler kategorii nadal odpowiada na żądania ?q=.

Dodanie Disallow: /*?q= do robots.txt. Googlebot w dużej mierze to respektuje. Bingbot robi to niespójnie; istnieją publiczne zgłoszenia, że mimo zakazów nadal indeksował niedozwolone wzorce zapytań. Roboty AI respektują robots.txt w bardzo różnym stopniu, zależnie od operatora. Wrogie programy pobierające dane ignorują go całkowicie. Warto to zrobić, ale nigdy nie wystarczy.

Globalna blokada w .htaccess dla każdego URL-a zawierającego ?q=. Łapie boty, ale psuje też własne żądania AJAX filtrów (ten sam wzorzec URL, którego sklep używa do pobierania wyników filtrowania bez przeładowania strony) oraz każdy zapisany lub udostępniony adres URL z filtrem, z którego korzystają prawdziwi klienci. Szkody SEO narastają, jeśli Google zaindeksował którąkolwiek z tych stron filtrów jako kanoniczną dla zapytań z długiego ogona. Jest miejsce na ręcznie dostrojone reguły serwera, tylko nie na rozwiązanie młotkiem; nasz wpis o regułach bezpieczeństwa i wydajności .htaccess dla PrestaShop omawia te, które warto zostawić.

Blokowanie konkretnych user-agentów botów. Gonitwa bez końca. Nowe boty pojawiają się co tydzień, wrogie boty fałszują ciągi UA, a legalne źródła AI (ChatGPT, Perplexity, Copilot), które generują coraz większą część kliknięć przychodzących, też zostałyby zablokowane. Stosunek indeksowania do kliknięć dla botów AI nadal jest słaby, ale nie jest zerowy; własne dane Cloudflare pokazują, że odesłania istnieją.

Pełnostronicowe buforowanie adresów ?q=. Gdy roboty pobierają wiele różnych kombinacji filtrów i rzadko je powtarzają, współczynnik trafień w pamięć podręczną może być niski. Zapisywanie każdego nowego URL-a może zwiększać liczbę zapisów bez znacznego odciążenia serwera źródłowego. Zmierz powtarzalność żądań i działanie pamięci podręcznej, zanim oprzesz na niej ochronę.

Pozostała opcja, której dotyczy reszta tego wpisu, to przeniesienie decyzji o tym, kto może uderzać w te adresy, całkowicie przed PrestaShop, tam, gdzie można ją podjąć tanio i bez uruchamiania PHP.

Właściwa poprawka: Cloudflare Managed Challenge dla kształtu wyszukiwania fasetowego

Cloudflare Managed Challenge może pomóc: ocenia dopasowane żądania przed PrestaShop i nie wymaga listy nazw konkretnych botów. Niektóre przeglądarki przechodzą bez interakcji, inne otrzymują interaktywne wyzwanie lub go nie przechodzą. Wyjątek dla X-Requested-With: XMLHttpRequest może zachować działanie filtrów AJAX, ale ten nagłówek jest banalnie łatwy do podrobienia i nie dowodzi, że żądanie pochodzi z interfejsu sklepu.

Użyj jednej reguły niestandardowej dla żądań GET z q, dodając warunek oceny bota tylko wtedy, gdy subskrypcja obejmuje Bot Management. Sam płatny plan nie daje dostępu do cf.bot_management.score. Przed włączeniem dowolnego wariantu sprawdź rzeczywiste trasy kategorii i wszystkie inne zastosowania q. Dodaj warunek and ograniczający regułę do potwierdzonych ścieżek kategorii z filtrami, gdy inne trasy również używają tego parametru. Pierwszy test przeprowadź na małym, jawnie określonym zestawie takich ścieżek. Uwzględnij ścieżkę bazową sklepu, prefiksy językowe oraz lokalizowane i własne trasy modułów/API; wykluczenia /module/ i /api/ obejmują tylko te ścieżki w katalogu głównym.

Jeśli subskrypcja obejmuje Bot Management

Wyklucz zweryfikowane boty wewnątrz tej reguły. Zachowaj not cf.client.bot w konkretnej regule q. Nie pomijaj globalnie wszystkich kolejnych reguł niestandardowych: pozostałe zabezpieczenia powinny nadal obejmować zweryfikowane roboty. cf.client.bot to klasyfikacja Cloudflare, a nie blokada bezpieczeństwa ani gwarancja, że dany robot nie przeciąży sklepu.

Sprawdzaj prawdopodobną automatyzację na potwierdzonych trasach z filtrami. Połącz opisane wyżej ograniczenie tras z tymi warunkami logicznymi:

• http.request.method eq "GET"
• oraz len(http.request.uri.args["q"]) >= 0, żądanie zawiera parametr q
• oraz not cf.client.bot. Nie jest zweryfikowanym robotem indeksującym
• oraz not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest"), żądanie nie zawiera tego łatwego do podrobienia znacznika AJAX
• oraz not starts_with(http.request.uri.path, "/module/")
• oraz not starts_with(http.request.uri.path, "/api/")
• oraz cf.bot_management.score gt 1 and cf.bot_management.score lt 30, wybrany tutaj zakres niskich ocen wskazujących na prawdopodobną automatyzację

Akcja: Managed Challenge. Reguła obejmuje pasujące żądania GET z q na wybranych trasach, z wyjątkiem zweryfikowanych botów, żądań ze znacznikiem AJAX i zidentyfikowanych ścieżek modułów/API. W wariancie Bot Management musi też pasować zakres oceny. Żądania, które przejdą wyzwanie lub nie podlegają regule, nadal mogą dotrzeć do serwera źródłowego. Reguła nie zatrzymuje całej automatyzacji.

Dla cf.bot_management.score eq 1 możesz dodać regułę przed regułą z wyzwaniem. Zachowaj ten sam zakres kategorii, warunki GET z q oraz wyjątki dla zweryfikowanych botów, AJAX, modułów i API. Ocena 1 to najsilniejsza klasyfikacja ruchu jako automatycznego w Cloudflare, nie dowód złych zamiarów. Przetestuj Managed Challenge lub, jeśli fałszywe trafienia są akceptowalne, Block, zanim rozszerzysz zakres.

Bez Bot Management (również Free i Pro)

Free i Pro obsługują reguły niestandardowe oraz Managed Challenge, ale nie obsługują wyrażeń regularnych ani akcji Log tych reguł. Business obsługuje regex, lecz nie Log; Enterprise udostępnia oba. Sprawdź dostępność w planach i wymagania operatorów w dokumentacji Cloudflare. Poniższe wspólne warunki nie używają regex i nie zakładają żadnego prefiksu URL kategorii. Przed włączeniem połącz je z opisanym wyżej zakresem rzeczywistych tras:

http.request.method eq "GET"
and len(http.request.uri.args["q"]) >= 0
and not cf.client.bot
and not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest")
and not starts_with(http.request.uri.path, "/module/")
and not starts_with(http.request.uri.path, "/api/")

Bez uprawnienia do Bot Management nie używaj cf.bot_management.score. Pole cf.threat_score polecane w starszych poradnikach jest trwale ustawione na 0 i nie rozróżnia ryzykownych żądań.

len(http.request.uri.args["q"]) >= 0 jest prawidłowym sprawdzeniem obecności parametru: brak klucza w mapie powoduje, że porównanie w języku Cloudflare daje false. Zobacz udokumentowane zachowanie brakujących wartości. Nie dowodzi to jednak, że q oznacza filtr. Sprawdź puste i wypełnione wartości, adresy wyszukiwania oraz lokalizowane lub własne trasy modułów/API. Filtry zakodowane w przepisanej ścieżce wymagają osobnego dopasowania opartego na rzeczywistych trasach sklepu.

Po poniższych kontrolach użyj Managed Challenge dla dopasowanego ruchu. URL filtra pozostaje bez zmian, lecz klient musi móc przejść ewentualne wyzwanie. Nie ma gwarancji jednego kliknięcia ani stałej liczby rund komunikacji. Sprawdź zakładki i udostępnione linki w prawdziwych przeglądarkach, także mobilnych, oraz filtrowanie AJAX: strona wyzwania zwrócona jako odpowiedź AJAX może zepsuć interfejs. Zweryfikowane boty, żądania ze znacznikiem AJAX i klienci przechodzący wyzwanie nadal mogą obciążać serwer źródłowy.

Ważne zastrzeżenia przed włączeniem reguł

Testuj narzędziami dostępnymi w swoim planie. W Enterprise możesz używać Log przez 24–48 godzin i sprawdzić zdarzenia przed włączeniem Managed Challenge. Free, Pro i Business nie udostępniają akcji Log dla reguł niestandardowych: najpierw przejrzyj dostępne dane Security Analytics i logi żądań, a następnie uruchom kontrolowany test Managed Challenge na niewielkim zestawie potwierdzonych tras kategorii i obserwuj Security Events. Sprawdź też prawidłowy ruch wyszukiwania, modułów/API, sitemap i narzędzi analitycznych. Rozszerzaj regułę dopiero po kontroli fałszywych trafień i zachowania przeglądarek. Szczegółowość analityki i logów zależy od planu; zobacz tabelę dostępności Cloudflare.

Wyjątek X-Requested-With chroni UX, ale nie jest granicą bezpieczeństwa. Każdy klient HTTP może wysłać ten nagłówek i ominąć tę regułę, łącznie z warunkiem oceny bota. Klienci AJAX, którzy pomijają nagłówek, nie korzystają z wyjątku. cf.client.bot klasyfikuje zweryfikowane boty, a ocena szacuje automatyzację; żadne z tych pól samo niczego nie blokuje. Zachowaj pozostałe zabezpieczenia i monitoruj obciążenie generowane przez wyłączony z reguły ruch, także zweryfikowane roboty.

Proxy dla każdej publicznej nazwy hosta WWW (orange-cloud), ale poprawna obsługa poczty i rekordów innych niż HTTP. Poczta/MX i inne rekordy nie-HTTP zasadniczo nie powinny być obejmowane proxy Cloudflare, a proxy orange-cloud nie ochroni usług nie-HTTP w ten sam sposób. Prawdziwe ryzyko to dowolny rekord DNS-only (grey-cloud), taki jak mail, dev czy subdomena administracyjna, który wskazuje na ten sam serwer co sklep, bo ujawnia źródłowy adres IP WWW. Każdy, kto znajdzie serwer źródłowy, może całkowicie ominąć Cloudflare i uderzać bezpośrednio w PrestaShop. Trzymaj pocztę i inne rekordy nie-HTTP jako DNS-only, ale upewnij się, że nie wskazują na źródłowy adres IP WWW ani go nie ujawniają: przenieś pocztę, dev i admin na osobne IP albo je ogranicz. Przejrzyj panel DNS, zanim zaufasz WAF-owi.

Ogranicz serwer źródłowy do adresów IP Cloudflare. Nawet gdy wszystko jest obejmowane proxy, twardo zablokuj serwer źródłowy na firewallu tak, aby przyjmował HTTP/HTTPS tylko z opublikowanych zakresów IP Cloudflare. W przeciwnym razie atakujący, który pozna źródłowy adres IP ze starej historii DNS, może uderzać w niego bezpośrednio. Przy ograniczaniu dostępu do serwera źródłowego upewnij się też, że działa wyłącznie po HTTPS od początku do końca; nasz przewodnik o konfiguracji SSL i HTTPS w PrestaShop omawia certyfikat i przekierowania tak, aby brzeg sieci i serwer źródłowy były zgodne.

Jeśli zależy Ci na odesłaniach z wyszukiwania AI, obserwuj wpływ. Niektóre roboty AI pomagają usługom odkrywać strony, do których później mogą kierować linki. Wyzwania dla ich żądań mogą wpływać na odkrywanie i potencjalnie odesłania, zależnie od faktycznie objętych robotów i tras. Sprawdź analitykę po tygodniu i porównaj wartościowe wizyty z ograniczeniem obciążenia serwera źródłowego; bilans zależy od sklepu.

Rozwiązanie awaryjne: override Dispatchera

Jeśli Cloudflare nie jest dziś dostępne, rozwiązaniem awaryjnym w PHP może być override Dispatchera przekierowujący wybrane nie-AJAX-owe żądania kategorii ?q= na tę samą kategorię bez filtra. Ogranicz go do potwierdzonych tras kategorii z filtrami: usuwanie q w całym sklepie usuwałoby też parametry wyszukiwania lub modułów/API.

Punkt rozszerzenia to override/classes/Dispatcher.php: klasa rozszerza DispatcherCore i nadpisuje dispatch(). Najpierw rozpoznaj lub jawnie dopasuj trasę kategorii dla bieżącego sklepu i języka. Obsługuj tylko żądania GET z kluczem q w sparsowanym query string i bez przetestowanego znacznika AJAX (HTTP_X_REQUESTED_WITH, porównanie bez rozróżniania wielkości liter). Wyklucz wyszukiwanie i wszystkie trasy modułów/API. Przeanalizuj $_SERVER['REQUEST_URI'], usuń tylko q i odbuduj query przez http_build_query(), zachowując pozostałe parametry. Adres docelowy musi zachować ścieżkę kategorii, ścieżkę bazową sklepu i prefiks językowy oraz używać skonfigurowanego adresu sklepu; samo Tools::getShopDomainSsl(true) nie dodaje podkatalogu sklepu. Unikaj pętli przekierowań. Wyślij wybraną odpowiedź Location i wykonaj exit; w pozostałych przypadkach wywołaj parent::dispatch().

Na wybranych trasach kategorii 301 trwale usuwa filtr z bezpośrednich linków. Stosuj je tylko wtedy, gdy te URL-e mają stale prowadzić do niefiltrowanej kategorii. Najpierw przetestuj przekierowanie tymczasowe, zanim zastosujesz trwałe, które może być buforowane. Żądania ze znacznikiem AJAX pozostają wyłączone, także boty kopiujące nagłówek, więc sprawdź filtrowanie w rzeczywistym motywie. Sprawdź istniejące override'y Dispatchera i zgodność modułów, a po instalacji wyczyść pamięć podręczną indeksu klas. Ogranicza to pracę przy pasujących żądaniach, ale nie eliminuje startu PHP ani nie chroni wszystkich endpointów.

Trzy kompromisy, które trzeba rozumieć przed wdrożeniem:

• Wpływ na SEO. Przekierowanie URL-a filtra na niefiltrowaną kategorię zmienia cel i może wpłynąć na pozycje dla zapytań z długiego ogona. Przed wdrożeniem sprawdź Search Console. Zachowaj wartościowe strony filtrów lub przypisz je jawnie do odpowiednich stron docelowych; nie zakładaj, że wszystkie URL-e fasetowe mają małą wartość w wyszukiwarce.
• Zakładki i udostępnienia. W zakresie przekierowania zapisane linki tracą widok filtrowany. Reguła Cloudflare zachowuje URL, jeśli użytkownik przejdzie ewentualne wyzwanie; dołączenie przekierowania nadal usuwa filtr.
• Pomaga tylko na obciążenie po stronie PHP. Żądanie nadal trafia do PHP, tylko szybko kończy się 301 zamiast generować pełną stronę kategorii. Jeśli wąskim gardłem jest liczba połączeń, a nie CPU, pomaga to mniej niż poprawka na brzegu sieci.

Wdrażaj to jako rozwiązanie tymczasowe. Przenieś ochronę do Cloudflare tak szybko, jak możesz.

Brzeg sieci kontra serwer źródłowy: która poprawka na które wąskie gardło

Te dwie obrony nie są wymienne. Wybierz według tego, gdzie Twój sklep faktycznie cierpi.

Łącz obie metody tylko wtedy, gdy utrata widoku filtrowanego pod wybranymi bezpośrednimi linkami jest akceptowalna. Override nadal przekierowuje, nawet jeśli Cloudflare przepuści odwiedzającego, i nie zastępuje ochrony przed całym ruchem docierającym do serwera źródłowego.

Perspektywa architektoniczna: wymień samą powierzchnię URL

Indeksowalne strony filtrów powinny być celowymi adresami URL, a nie przypadkowymi kombinacjami dla robotów indeksujących.

Obie metody mogą ograniczyć niepożądany ruch na istniejących URL-ach ps_facetedsearch. Żadna nie zmienia dużej publicznej przestrzeni kombinacji filtrów udostępnianej przez moduł.

Inna klasa modułu filtrów unika problemu u źródła: stan filtrów żyje po stronie klienta (albo w pojedynczym AJAX POST), publiczny URL pozostaje czysty, a indeksowalne stają się tylko świadomie przygotowane strony docelowe SEO, na przykład ręcznie zbudowana strona dla "męskich butów do biegania", a nie każda kombinacja marki, koloru i rozmiaru. Właśnie w tym stylu zbudowaliśmy Filter Revolution, częściowo jako odpowiedź na dokładnie takie wzorce ruchu. Co to oznacza dla Ciebie? Zmniejsza publiczną powierzchnię URL o wysokiej kardynalności, dzięki której ps_facetedsearch jest atrakcyjny dla robotów indeksujących. To oznacza mniej kombinatorycznych stron do odkrycia przez boty i potencjalnie mniejsze obciążenie od robotów, a wszystko konfigurowane z panelu administracyjnego, bez rozgałęziania motywu. To nie jest magiczna tarcza przeciw robotom indeksującym AI, bo nic nią nie jest, i nie usuwa wstecznie z indeksu adresów, które Google i Bing już znalazły. Może to ograniczyć odkrywanie nowych kombinacji filtrów, ale znane URL-e i endpointy AJAX nadal potrzebują odpowiedniej kontroli ruchu.

Jeśli i tak planujesz przebudowę wyszukiwania fasetowego, rozważ wymianę modułu. Gdy obecny pasuje do sklepu, utrzymuj regułę Cloudflare i sprawdzaj ją po zmianach tras, działania AJAX lub ruchu.

Jeszcze jedno: puste koszyki

W rdzeniu PrestaShop żądanie GET strony kategorii nie tworzy automatycznie wiersza ps_cart dla każdego odwiedzającego. Zapis koszyka zależy od przebiegu obsługi żądania, motywu i modułów oraz od tego, czy tworzą lub zapisują koszyk. Jeśli automatyzacja wywołuje takie zachowanie, puste koszyki mogą się gromadzić, spowalniać listy administracyjne lub zniekształcać obsługę porzuconych koszyków. Potwierdź przyczynę we własnym sklepie, zanim przypiszesz każdy anonimowy koszyk botowi.

Skuteczna reguła na brzegu sieci może ograniczyć nowe koszyki botów pochodzące z przechwyconego ruchu; nie gwarantuje zatrzymania całego przyrostu i nie czyści istniejących wierszy. Sprawdź zainstalowane narzędzia czyszczenia i zasady przechowywania danych. Ukrycie potwierdzonych koszyków botów w licznikach i listach może przywrócić wygodę pracy, zachowując dane do analizy. Anonimowy lub pusty koszyk sam w sobie nie dowodzi działania bota. Jeśli usuwanie jest potrzebne, wykonaj kopię zapasową i kontrolowane czyszczenie chroniące prawidłowe koszyki oraz powiązania z zamówieniami. To osobne zadanie obok kontroli ruchu.

Gdzie to pasuje do szerszej ochrony sklepu

Zalew ?q= to jeden konkretny tryb awarii, ale płaszczyzna kontroli, którą budujesz, aby go zatrzymać, przydaje się w całej reszcie strategii bezpieczeństwa. Kilka powiązanych zadań, które warto ustawić po wdrożeniu reguły na brzegu sieci:

• Blokady per odwiedzający i bany IP. Gdy jedno źródło dalej sonduje po wyzwaniu, potrzebujesz czystego sposobu na odcięcie go i zobaczenie, kto w Ciebie uderza; zobacz dodatkowe informacje o klientach i bany IP.
• Spam w formularzach, osobno od zalewów ruchu. Ta sama automatyzacja, która indeksuje fasety, będzie też atakować formularze kontaktowe i rejestracyjne; odpowiedzią jest wyzwanie przy wysyłce formularza, zobacz reCAPTCHA dla PrestaShop.
• Jeśli nie możesz jeszcze zaktualizować rdzenia. Sklepy uwięzione na starszym PrestaShop mają mniej natywnych dźwigni; podejście z regułą brzegową i override z tego wpisu jest częścią szerszej strategii wirtualnego łatania opisanej w zaawansowanym wzmacnianiu bezpieczeństwa sklepów, których nie możesz jeszcze zaktualizować.
• Jeśli to dla Ciebie nowy temat. Jeśli powyższa terminologia jest przytłaczająca, zacznij od prostego przewodnika dla właścicieli sklepów i idź dalej krok po kroku.

Najczęściej zadawane pytania

Dlaczego wyłączenie modułu wyszukiwania fasetowego nie zatrzymuje zalewu ?q=?

Wyłączenie ps_facetedsearch usuwa interfejs filtrów i może ograniczyć obliczenia filtrowania, lecz znane adresy takie jak /category-slug?q=anything mogą nadal uruchamiać PrestaShop i trafiać do kontrolera kategorii. Zautomatyzowane programy wciąż mogą je wywoływać.

Czy Disallow w robots.txt naprawia zalew ?q=?

Pomaga, ale samodzielnie nigdy nie wystarcza. Disallow blokuje pobieranie stron przez roboty, nie pojawianie się w indeksie, a co kluczowe, respektują go tylko dobrze zachowujące się roboty indeksujące. Googlebot w dużej mierze go przestrzega, Bingbot robi to niespójnie, roboty indeksujące AI różnią się zależnie od operatora, a wrogie programy pobierające dane ignorują go całkowicie. Ruch ignorujący robots.txt wymaga osobnych zabezpieczeń; nawet roboty przestrzegające reguł mogą przeciążyć dozwolone adresy. Warto to zrobić, ale nigdy nie jest to cała odpowiedź. Obecność w mapie witryny zależy od modułu sitemap i jego konfiguracji lub polityki URL-i, a nie od samej wersji rdzenia PrestaShop. Wykluczenie niepożądanych adresów filtrów może ograniczyć ich odkrywanie, ale nie zatrzymuje żądań do znanych URL-i.

Dlaczego nie zablokować po prostu w .htaccess każdego URL-a zawierającego ?q=?

Globalna blokada obejmuje też prawidłowe filtry AJAX, zapisane URL-e filtrów i inne zastosowania q, takie jak wyszukiwanie czy API. Reguła Managed Challenge o ograniczonym zakresie może zmniejszyć niepożądany ruch, zachowując adresy. Wyjątki dla zweryfikowanych botów i znacznika AJAX pozostawiają część automatyzacji poza regułą, dlatego sprawdź rzeczywiste żądania filtrów i monitoruj pozostałe obciążenie serwera źródłowego.

Jaka jest najszybsza poprawka, jeśli dziś nie mogę wdrożyć Cloudflare?

Przetestowany override/classes/Dispatcher.php może przekierowywać nie-AJAX-owe żądania GET z q na jawnie rozpoznanych trasach kategorii z filtrami. Zachowaj ścieżkę bazową sklepu, prefiks językowy i pozostałe parametry; wyłącz wyszukiwanie oraz trasy modułów/API. Sprawdź zgodność override'ów i wyczyść pamięć podręczną indeksu klas. Używaj 301 tylko wtedy, gdy trwała utrata tych URL-i filtrów jest zamierzona. PHP nadal startuje, a boty mogą naśladować wyjątek AJAX, więc to rozwiązanie tymczasowe o ograniczonym zakresie, nie pełna ochrona przed zalewem.

Dlaczego ten zalew wypełnia też tabelę koszyków tysiącami pustych koszyków?

Może się tak dziać, jeśli motyw, moduły lub przebieg obsługi żądania tworzą i zapisują koszyki podczas automatycznych wizyt. Sam GET kategorii nie tworzy w rdzeniu PrestaShop wiersza ps_cart dla każdego odwiedzającego. Ustal, który komponent zapisuje koszyki. Filtrowanie na brzegu sieci może ograniczyć odpowiedni ruch, ale istniejące niechciane wiersze wymagają osobnego, kontrolowanego czyszczenia. Anonimowych koszyków nie wolno automatycznie uznawać za koszyki botów.

Przestań owijać problem ochroną, zmniejsz powierzchnię

Poprawki Cloudflare i Dispatchera chronią istniejącą powierzchnię URL o wysokiej kardynalności, ale jej nie usuwają. Filter Revolution utrzymuje stan filtrów po stronie klienta, dzięki czemu publiczny URL pozostaje czysty, a indeksowalne stają się tylko świadomie przygotowane strony docelowe SEO: mniej kombinatorycznych stron do odkrycia przez roboty indeksujące już na starcie. Obok reguły na brzegu sieci Cleanup Revolution porządkuje zanieczyszczenie koszyków botami, a Security Revolution obejmuje szersze wzmacnianie bezpieczeństwa, którego ten zalew jest tylko jednym fragmentem.

Szybka checklista

• Włącz Cloudflare dla domeny. Proxy'uj każdą publiczną nazwę hosta WWW (orange-cloud); pocztę i inne rekordy nie-HTTP trzymaj jako DNS-only i upewnij się, że nie wskazują na źródłowy adres IP WWW ani go nie ujawniają.
• Utwórz regułę q o ograniczonym zakresie z not cf.client.bot wewnątrz niej. Enterprise: obserwuj przez 24–48 godzin z akcją Log. Free/Pro/Business: sprawdź dostępne Security Analytics i logi żądań, potem przetestuj Managed Challenge na kilku potwierdzonych trasach kategorii i monitoruj Security Events.
• Sprawdź rzeczywiste URL-e kategorii, inne zastosowania q, lokalizowane/własne ścieżki modułów i API oraz AJAX i zapisane linki w prawdziwych przeglądarkach. Potwierdź oczekiwany dostęp robotów i zmierz ruch nadal docierający do serwera źródłowego.
• Po sprawdzeniu fałszywych trafień w Enterprise można przełączyć Log na Managed Challenge; w Free/Pro/Business rozszerzaj kontrolowany test tylko na zweryfikowane trasy. Nadal monitoruj Security Events i obciążenie serwera źródłowego.
• Ogranicz firewall serwera źródłowego do zakresów IP Cloudflare. To zamyka pętlę.
• Jeśli Cloudflare nie jest dostępne, przetestuj override Dispatchera ograniczony do kategorii, zachowujący ścieżkę bazową sklepu i pozostałe parametry zapytania, oraz zaplanuj migrację.
• Jeśli i tak czeka Cię przebudowa modułu filtrów, rozważ całkowitą wymianę ps_facetedsearch.
• Osobno posprzątaj zanieczyszczenie koszyków w panelu administracyjnym, aby administracja koszykami pozostała używalna.

Zakończenie

Kombinacje adresów filtrów mogą stwarzać ryzyko DoS, gdy ruch robotów przekracza wydajność sklepu. Ryzyko zależy od modułu filtrów, dostępnych tras, ruchu i zasobów; nie jest nieuniknione w każdej instalacji PrestaShop. Sprawdź rzeczywiste wzorce żądań i dobierz zabezpieczenia zachowujące prawidłowe użycie sklepu.

Reguła niestandardowa bez oceny bota jest dostępna w Cloudflare Free, ale analiza tras, testy przeglądarek i stały monitoring nadal wymagają pracy. Dostrojony WAF i ograniczony dostęp do serwera źródłowego dają podstawę do dalszej ochrony; credential stuffing, masowe pobieranie danych i fałszywe przejścia do kasy wymagają własnych zabezpieczeń.

Pełne podejście warstwowe znajdziesz ponownie w checkliście wzmacniania bezpieczeństwa PrestaShop. Jeśli chcesz zobaczyć, co dzieje się, gdy sklep zostaje przejęty przez coś bardziej wyrafinowanego niż nadużycie robotów indeksujących, przeczytaj anatomię ataku w stylu Magecart na sklep PrestaShop 1.7.x. Plan obrony ma w obu przypadkach ten sam kształt: tanie kontrole na brzegu sieci, wąskie wyjątki tylko tam, gdzie są konieczne, i absolutnie żadnych deklaracji bezpieczeństwa opartych na ciągach user-agent.