reCAPTCHA dla PrestaShop: ochrona przed spamem bez irytowania prawdziwych klientów

Każde zabezpieczenie antyspamowe dodane do sklepu PrestaShop płaci za ochronę tą samą walutą: cierpliwością klienta. Tu pole wyboru, tam siatka obrazków, przy rejestracji bramka „udowodnij, że jesteś człowiekiem”, każde z tych rozwiązań zatrzymuje boty, ale każde prosi też realnego, płacącego klienta o dodatkową pracę, zanim będzie mógł zostawić u Ciebie pieniądze. Najtrudniejsze w reCAPTCHA nie jest jej włączenie. Trudne jest takie włączenie, żeby boty trafiały na ścianę, a prawdziwi klienci niczego nie odczuli. Ten poradnik dotyczy właśnie tej równowagi, zatrzymywania spamu bez obciążania osób, na których naprawdę Ci zależy. Pełną instrukcję konfiguracji krok po kroku dla poszczególnych wersji (pozyskanie kluczy, instalacja modułu, konfiguracja każdego formularza) znajdziesz w kompletnym poradniku konfiguracji reCAPTCHA dla PrestaShop; tutaj skupiamy się na tarciu.

Ostatnia aktualizacja: czerwiec 2026.

Budżet tarcia: ma go każdy formularz i jest mniejszy, niż myślisz

Potraktuj cierpliwość klienta jak budżet, który wydajesz przy każdym formularzu. Zmotywowany kupujący wpisujący dane płatności ma go już prawie zero, podjął decyzję o zakupie, a wszystko, co stanie między nim a przyciskiem „zapłać”, odczyta jako powód do wyjścia. Spamer działa odwrotnie: ma nieskończoną cierpliwość, bo skrypt się nie irytuje. W tej asymetrii tkwi cała gra: potrzebujesz kontroli, która kosztuje boty wszystko, a ludzi nic. reCAPTCHA może być właśnie taką kontrolą albo może stać się powodem porzucenia koszyka, różnica wynika wyłącznie z tego, jak skonfigurujesz ją dla poszczególnych formularzy.

Najczęstszy błąd, jaki widzimy w sklepach PrestaShop, to traktowanie reCAPTCHA jak jednego przełącznika dla całej witryny. Tak to nie działa. Widoczne pole wyboru v2 jest całkowicie rozsądne w formularzu kontaktowym, gdzie ktoś już zdecydował się poświęcić dwie minuty na napisanie wiadomości. To samo pole wyboru w jednostronicowej finalizacji zamówienia jest wyciekiem konwersji. Formularze różnią się tym, ile cierpliwości zostało odwiedzającemu, więc ochrona też powinna się różnić.

Wersje reCAPTCHA według tego, jak bardzo irytują klientów

Ekran konfiguracji pozwala wybrać dostawcę, formularze i próg v3, zamiast sztywno narzucać poziom tarcia.

Moduł podpina się pod rzeczywiste hooki formularzy PrestaShop, zamiast zastępować szablony. Najważniejsze rejestracje hooków wyglądają tak:

$this->registerHook('displayContactContent');
$this->registerHook('displayCustomerLoginFormAfter');
$this->registerHook('displayCustomerAccountForm');
$this->registerHook('displayNewsletterRegistration');
$this->registerHook('actionContactFormSubmitBefore');
$this->registerHook('actionSubmitAccountBefore');
$this->registerHook('actionCustomerLoginBefore');
$this->registerHook('actionNewsletterRegistrationBefore');

Na moment odłóż na bok pytanie „która wersja jest najbezpieczniejsza” i uporządkuj wersje według jedynej osi, która ma znaczenie w tym artykule, jaki koszt ponosi prawdziwy klient:

Główna zasada, jeśli nie chcesz irytować klientów, brzmi: im bliżej pieniędzy znajduje się formularz, tym bardziej niewidoczna musi być ochrona. Przy finalizacji zamówienia użyj v3 albo niczego. Formularz kontaktowy może udźwignąć pole wyboru. Nigdy nie stawiaj bramki z obrazkami przed klientem, który próbuje zapłacić.

Dlaczego v3 jest tutaj domyślną odpowiedzią

reCAPTCHA v3 nie wyświetla interaktywnych wyzwań. Obserwuje zachowanie, ruchy myszy, przewijanie, tempo działania, i przekazuje sklepowi wynik. Konfigurujesz próg używany przez mprrecaptcha, ale prawidłowy klient może zostać zablokowany, jeśli jego wynik jest zbyt niski. Właśnie ta cecha sprawia, że v3 jest właściwym narzędziem, gdy celem jest „nie irytować prawdziwych klientów”: nie ma wyzwania do oblania, siatki do wpatrywania się ani pola wyboru do szukania na telefonie. Koszt przechodzi z doświadczenia klienta na Twoją pracę konfiguracyjną, i dokładnie o taką wymianę chodzi.

Prawdziwe ryzyko niewidocznej ochrony: fałszywe alarmy

Niewidoczna ochrona usuwa widoczne tarcie, ale wprowadza cichsze zagrożenie. Prawidłowy klient może zostać oceniony jako bot i bez komunikatu zablokowany. Nie widzi wyzwania; widzi formularz, który „nie chce się wysłać”, bez żadnego wyjaśnienia. To gorsze niż pole wyboru, bo klient nie może nawet wykonać dodatkowego kroku, żeby przejść dalej. Ten tryb awarii po cichu kosztuje sprzedaż i to przed nim trzeba projektować konfigurację.

Klienci, którzy najłatwiej mogą dostać niski wynik v3, nie robią nic złego:

• Użytkownicy VPN i sieci firmowych, wiele osób korzystających z jednego IP wygląda podobnie do botów. Całe biuro zamawiające z Twojego sklepu B2B może wspólnie dostać niski wynik.
• Przeglądarki nastawione na prywatność, ścisła ochrona przed śledzeniem, blokery reklam lub zmodyfikowane user-agenty ograniczają sygnały, na których opiera się reCAPTCHA.
• Szybcy, zdecydowani kupujący, powracający klient, który dokładnie wie, czego chce, i wypełnia formularz w osiem sekund, może wyglądać jak automatyzacja.
• Użytkownicy mobilni na współdzielonych adresach operatorów, pule NAT operatorów komórkowych współdzielą adresy między tysiącami osób.

To mogą być jedni z Twoich najlepszych klientów. Zbyt agresywnie ustawiony próg odprawia ich bez żadnej informacji zwrotnej. Dwie decyzje projektowe pomagają ich zatrzymać:

• Ostrożnie używaj twardej blokady wyłącznie na podstawie wyniku v3. Idealny wzorzec to najpierw v3, a widoczne wyzwanie tylko dla wyników granicznych, żeby prawdziwy klient miał drogę dalej. Obecna implementacja mprrecaptcha waliduje jednego wybranego dostawcę i twardo odrzuca niskie wyniki v3, więc dopóki nie ma mechanizmu awaryjnego, trzymaj próg konserwatywnie i uważnie obserwuj dane o konwersji.
• Ustaw niski próg i podnoś go powoli. Zacznij od 0.5, obserwuj przez tydzień i zaostrzaj dopiero wtedy, gdy spam nadal przechodzi. Podniesienie progu do 0.7 lub wyżej może powodować fałszywe alarmy, więc rób to dopiero po zmierzeniu własnego rozkładu wyników i wpływu na konwersję, odsetek blokowanego prawdziwego ruchu różni się między sklepami. W razie wątpliwości lepiej przepuścić kilka botów więcej niż odprawić płacącego klienta, boty łatwo posprzątać, utracona sprzedaż przepada.

Gdzie wydawać tarcie, a gdzie nie

Dopasowanie ochrony do cierpliwości, jaka została odwiedzającemu, formularz po formularzu w sklepie PrestaShop:

Z tego wynikają dwie rzeczy. Po pierwsze, finalizacja zamówienia jest święta, nigdy nie stawiaj widocznego wyzwania między klientem a płatnością; jeśli musisz ją chronić, jedynym akceptowalnym wyborem jest niewidoczna v3, a wielu sklepom bardziej opłaca się nie ruszać tego etapu i zatrzymywać boty wcześniej. Po drugie, nie zabezpieczaj formularzy, których boty nie atakują. reCAPTCHA przy polu wyszukiwania to czysty koszt, większa waga strony i ryzyko zablokowania prawdziwego kupującego, bez korzyści antyspamowej, bo nikt nie spamuje pola wyszukiwania.

Podatek wydajnościowy, który klienci odczuwają

„Irytowanie prawdziwych klientów” nie dotyczy tylko wyzwań, dotyczy też szybkości. reCAPTCHA ładuje około 150 KB JavaScriptu z serwerów Google, a v3 chce działać na każdej stronie, którą ocenia. Wrzuć ten skrypt na każdą stronę sklepu, a dodasz zewnętrzne żądanie do strony głównej, stron kategorii i stron produktów. Czyli stron, na których nie ma formularza do ochrony. To mierzalne uderzenie w wynik biznesowy: wolniejsze pierwsze renderowanie strony produktu kosztuje Cię tego samego niecierpliwego klienta, którego próbowałeś zatrzymać.

Rozwiązaniem jest dyscyplina konfiguracji, a nie kompromis w bezpieczeństwie: ładuj skrypt reCAPTCHA tylko na stronach, które faktycznie zawierają chroniony formularz. Moduł reCAPTCHA wstrzykujący skrypt dostawcy globalnie dokłada koszt do stron, na których nie ma żadnego formularza do ochrony; obecne wydanie mprrecaptcha ładuje skrypt dostawcy z nagłówka, gdy ochrona jest włączona, a widżety wstrzykuje tylko dla skonfigurowanych formularzy. Traktuj warunkowe ładowanie skryptu dostawcy jako funkcję wydajnościową, którą warto zweryfikować, bo większość sprzedawców nigdy nie pomyśli, żeby to sprawdzić. Szerszy obraz trzymania robotów indeksujących i botów z dala od stron, zanim w ogóle dotrą do formularza, znajdziesz w artykule blokowanie złych botów i niechcianego ruchu.

Dostępność: tarcie, którego nie widzisz we własnej przeglądarce

Wyzwanie obrazkowe, które dla Ciebie jest drobną irytacją, może być ścianą nie do przejścia dla klienta używającego czytnika ekranu, osoby słabowidzącej albo kogoś z trudnościami motorycznymi, dla kogo „kliknij każdy kwadrat z autobusem” jest naprawdę trudne. reCAPTCHA v2 oferuje alternatywę dźwiękową, ale często jest ona zniekształcona i trudna. Jeśli istotna część Twojej grupy odbiorców korzysta z technologii wspomagających, widoczna bramka z obrazkami nie tylko irytuje. Może całkowicie odciąć prawdziwych klientów od zakupu. To kolejny powód, dla którego niewidoczna, oparta na wyniku ścieżka jest łagodniejszym wyborem domyślnym: nie ma wyzwania, które mogłoby być niedostępne. Tam, gdzie potrzebujesz widocznej kontroli, wybierz zwykłe pole wyboru zamiast wymuszonych siatek obrazków.

Cichsze warstwy, które nie irytują nikogo

Ochrona antyspamowa o najniższym tarciu to taka, której klient nigdy nie spotyka, bo działa na zachowanie bota, a nie człowieka. Najpierw oprzyj się na tych rozwiązaniach, a reCAPTCHA stanie się zabezpieczeniem awaryjnym, nie pierwszą linią obrony:

• Pola-pułapki. Pole formularza ukryte CSS-em, którego ludzie nigdy nie widzą i nigdy nie wypełniają. Boty wypełniają każde znalezione pole, więc wypełniona pułapka oznacza bota złapanego bez żadnego tarcia dla prawdziwych klientów. Nie zatrzyma ukierunkowanego ataku, ale po cichu usuwa masowy spam, który inaczej uzasadniałby ostrzejszą bramkę.
• Limitowanie częstotliwości. Żaden człowiek nie rejestruje 40 kont w godzinę ani nie próbuje 200 logowań w minutę. Ograniczenie liczby zgłoszeń z jednego IP w określonym oknie czasowym zatrzymuje nadużycia ilościowe, nie prosząc o nic tego jednego prawdziwego klienta, który wypełnia formularz raz.
• Potwierdzenie e-mail przy rejestracji. Boty korzystające z jednorazowych skrzynek rzadko klikają link potwierdzający, więc fałszywe konta nigdy się nie aktywują, a prawdziwy klient i tak miał potwierdzić swój adres e-mail.
• Blokady IP i odwiedzających dla recydywistów. Gdy problemem jest konkretne źródło, lepiej zablokować je przy wejściu niż wystawiać wyzwania wszystkim. PrestaShop daje do tego narzędzia bezpośrednio, zobacz dodatkowe informacje o klientach i blokady IP.

Połącz pole-pułapkę, limitowanie częstotliwości i niewidoczną v3, a zatrzymasz przytłaczającą większość zautomatyzowanego spamu bez pokazania choćby jednego wyzwania prawdziwemu klientowi. Widoczne pole wyboru zostaje wtedy czymś, co rezerwujesz dla formularza kontaktowego, gdzie tarcie naprawdę jest akceptowalne.

Jak sprawdzić, czy to działa, bez irytowania klientów w ramach testu

Nie stroisz reCAPTCHA „na oko”. Dwa panele powiedzą Ci, czy równowaga jest właściwa:

• Konsola administracyjna Google reCAPTCHA pokazuje rozkład wyników. Zdrowy sklep ma większość ruchu skupioną wysoko (0.7–0.9) i niewielki ogon niskich wyników. Jeśli duża grupa siedzi przy 0.3–0.5, Twój próg walczy z własnymi klientami, poluzuj go.
• Lejek konwersji w PrestaShop pokazuje stronę kosztową. Zanim dodasz lub zaostrzysz jakąkolwiek bramkę, zapisz współczynnik ukończenia rejestracji i konwersję z koszyka do zamówienia. Po zmianie porównuj te same liczby przez co najmniej 30 dni, wystarczająco długo, żeby zobaczyć realny trend, a nie szum z jednego tygodnia. Spadek ukończonych akcji zbieżny z nową bramką oznacza, że bramka irytuje klientów; płaska linia przy mniejszej ilości spamu to wynik, którego chciałeś.

Stronę botów też łatwo zmierzyć: fałszywe rejestracje i spam z formularza kontaktowego powinny spaść gwałtownie w ciągu kilku dni. Jeśli po włączeniu ochrony spam pozostaje bez zmian, źle skonfigurowane są klucze albo integracja formularza. To nie jest powód, żeby podkręcać próg i zaczynać szkodzić prawdziwemu ruchowi.

Najczęściej zadawane pytania

Która wersja reCAPTCHA najmniej irytuje klientów?

reCAPTCHA v3. Działa po cichu, ocenia zachowanie w tle i nigdy nie pokazuje wyzwania. Nie ma czego oblać ani siatki, w którą trzeba się wpatrywać na telefonie. Dlatego jest właściwym wyborem domyślnym zawsze wtedy, gdy celem jest „nie irytować prawdziwych klientów”, zwłaszcza na formularzach o wysokiej intencji, takich jak finalizacja zamówienia i logowanie. Koszt przechodzi z doświadczenia klienta na Twoją pracę konfiguracyjną, czyli dokładnie tam, gdzie powinien.

Czy dodawać reCAPTCHA do finalizacji zamówienia?

Traktuj finalizację zamówienia jak świętość, nigdy nie stawiaj widocznego wyzwania między klientem a płatnością. Jeśli musisz ją chronić, jedynym akceptowalnym wyborem jest niewidoczna v3, a wielu sklepom bardziej opłaca się zostawić finalizację zamówienia w spokoju i zatrzymać boty wcześniej: przy rejestracji, logowaniu i formularzu kontaktowym. Powracający kupujący, który zaraz zapłaci, ma już prawie zerową cierpliwość.

Od jakiego progu wyniku v3 zacząć?

Zacznij od 0.5, obserwuj przez tydzień i zaostrzaj dopiero wtedy, gdy spam nadal przechodzi. Podniesienie do 0.7 lub wyżej grozi blokowaniem prawdziwych klientów, użytkowników VPN, przeglądarek nastawionych na prywatność, szybkich i zdecydowanych kupujących, użytkowników mobilnych na współdzielonych adresach operatorów, którzy dostają niski wynik nie z własnej winy. Zmierz własny rozkład wyników i wpływ na konwersję, zanim przesuniesz próg, a w razie wątpliwości przepuść kilka botów więcej zamiast odprawiać płacącego klienta.

Czy reCAPTCHA spowalnia sklep?

Może. Skrypt dostawcy ma około 150 KB JavaScriptu z serwerów Google, a v3 chce ładować się na każdej stronie, którą ocenia. Globalne ładowanie dodaje zewnętrzne żądanie do strony głównej, kategorii i produktów. Stron, na których nie ma formularza do ochrony. Rozwiązaniem jest dyscyplina konfiguracji: ładuj skrypt tylko na stronach, które faktycznie zawierają chroniony formularz. Sprawdź to zamiast zakładać; większość sprzedawców nigdy nie myśli, żeby to zweryfikować.

Czy istnieją zabezpieczenia antyspamowe, które w ogóle nie dodają tarcia?

Tak, najpierw oprzyj się na nich, a reCAPTCHA stanie się zabezpieczeniem awaryjnym, nie pierwszą linią obrony. Pola-pułapki (ukryte CSS-em pole, które boty wypełniają, a ludzie go nie widzą), limitowanie częstotliwości per IP, potwierdzenie e-mail przy rejestracji oraz blokady IP dla recydywistów działają na zachowanie bota, nie człowieka. Połącz pole-pułapkę z limitowaniem częstotliwości i niewidoczną v3, a zatrzymasz większość zautomatyzowanego spamu bez pokazania prawdziwemu klientowi choćby jednego wyzwania.

Miejsce reCAPTCHA w szerszej ochronie sklepu

reCAPTCHA zatrzymuje nadużycia formularzy, fałszywe rejestracje, wiadomości spamowe, skryptowane próby logowania. Nie robi nic z atakami, które nie przechodzą przez formularz: skimmerami, włamaniami do systemu plików, exploitami na nieaktualny rdzeń. Zachowaj proporcje. W przypadku ochrony przed brute force przy logowaniu połącz ją konkretnie z mocnym uwierzytelnianiem administratora, opisanym w artykule uwierzytelnianie dwuskładnikowe, zasady haseł i bezpieczeństwo administratora. A pełny obraz zabezpieczania sklepu PrestaShop znajdziesz w liście kontrolnej utwardzania bezpieczeństwa PrestaShop, gdzie ochrona formularzy stoi obok kilkunastu innych naprawdę ważnych działań.

Jeśli potrzebujesz modułu reCAPTCHA dla PrestaShop z konfiguracją dla każdego formularza, wyborem dostawcy, kontrolą progu wyniku v3, obsługą hCaptcha i prawdziwą integracją z hookami PrestaShop, to właśnie to obecnie oferuje mprrecaptcha na mypresta.rocks. Korzyść, którą naprawdę sprzedaje, nie brzmi „zatrzymuje boty”, wiele rozwiązań zatrzymuje boty. Brzmi: zatrzymuje je tak, żeby prawdziwi klienci nigdy nie zauważyli, że ochrona w ogóle istnieje.

Celem nigdy nie było maksymalne bezpieczeństwo za wszelką cenę; sklep owinięty wyzwaniami zatrzymuje i boty, i kupujących. Celem jest sklep bez tarcia dla ludzi, których chcesz obsłużyć, oraz mur dla skryptów, których nie chcesz. Wydawaj budżet tarcia tam, gdzie klienci mają jeszcze cierpliwość, przechodź na niewidoczną ochronę tam, gdzie jej nie mają, mierz zarówno zatrzymany spam, jak i zachowane konwersje, a reCAPTCHA wykona swoje zadanie, nigdy nie stając się powodem czyjegoś wyjścia.