Honeypot, czas wypełnienia, Turnstile czy reCAPTCHA i filtry treści - warstwy, które wycinają 95-99% spamu z formularza bez męczenia klientów obrazkami.
Formularz kontaktowy miał przynosić zapytania od klientów, a przynosi „oferty pozycjonowania", losowe ciągi znaków i linki do aptek? Spam z formularzy to osobna kategoria problemu - nie zatrzyma go filtr antyspamowy skrzynki, bo wiadomości technicznie wysyła Twoja własna strona. Zatrzymać trzeba boty, zanim klikną „wyślij". Dobra wiadomość: trzy proste mechanizmy odsiewają zdecydowaną większość śmieci bez męczenia prawdziwych klientów przepisywaniem rozmazanych literek.
Za ponad 90% zgłoszeń stoją automaty. Boty skanują internet w poszukiwaniu formularzy, rozpoznają pola po nazwach (name, email, message) i wysyłają tysiące zgłoszeń na godzinę - licząc, że część trafi na strony wyświetlające treść wiadomości publicznie (księgi gości, komentarze) albo że zmęczony właściciel kliknie w link. Reszta to tani spam ręczny, zwykle „oferty współpracy" pisane przez ludzi kopiujących szablon.
Ten podział ma znaczenie praktyczne: przeciw botom działają mechanizmy techniczne (honeypot, czas, CAPTCHA), przeciw ludziom - tylko filtry treści. Dlatego żadna pojedyncza metoda nie daje 100% i sensowna ochrona to dwie-trzy warstwy.
Honeypot to dodatkowe pole formularza ukryte przed ludźmi (CSS chowa je z ekranu), ale widoczne w kodzie strony. Człowiek go nie wypełni, bo go nie widzi; bot wypełnia wszystko jak leci. Zgłoszenie z wypełnionym polem-pułapką odrzuca się bez słowa.
Zalety: zero tarcia dla użytkownika, zero zależności od zewnętrznych usług, działa od ręki. Wady: najprostsze boty łapie znakomicie, te sprytniejsze (renderujące stronę jak przeglądarka) potrafią pułapkę ominąć. Dlatego honeypot to fundament, nie całość ochrony.
W praktyce nie piszesz tego samodzielnie: WPForms, Contact Form 7 (z wtyczką Honeypot), Fluent Forms i Forminator mają honeypot wbudowany albo jako jedno kliknięcie w ustawieniach. Jeśli Twój formularz go nie ma - włącz dziś.
Człowiek potrzebuje kilkunastu-kilkudziesięciu sekund na wypełnienie formularza; bot wysyła go w ułamku sekundy po załadowaniu strony. Pomiar czasu między wyświetleniem a wysłaniem to drugi cichy filtr: zgłoszenia poniżej np. 3 sekund lądują w koszu. Podobnie działają testy JavaScript - pole wypełniane skryptem dopiero w przeglądarce odsiewa boty, które w ogóle nie wykonują JS.
Te mechanizmy również znajdziesz gotowe: w ustawieniach antyspamowych nowoczesnych wtyczek formularzy figurują jako „minimum time to submit" czy „JavaScript token". Zestaw honeypot + czas + token JS zatrzymuje lwią część automatów - nadal przy zerowym tarciu dla klienta.
CAPTCHA to zamek najcięższego kalibru - i jedyna warstwa, którą klient widzi. Dlatego zakładamy ją wtedy, gdy ciche metody nie wystarczają, a nie „na zapas". Współczesne opcje różnią się mocno:
| Mechanizm | Jak działa dla użytkownika | Uwagi |
|---|---|---|
| reCAPTCHA v3 (Google) | niewidoczna - ocenia zachowanie, zwraca wynik 0-1 | bez tarcia, ale wymaga progu odcięcia i przekazuje dane do Google - do odnotowania w polityce prywatności |
| reCAPTCHA v2 | checkbox „nie jestem robotem", czasem obrazki | skuteczna, lecz obrazkowe zagadki realnie zniechęcają część klientów |
| Cloudflare Turnstile | zwykle samo „ptaszek zaskoczył" bez zagadek | darmowa, lżejsza prywatnościowo alternatywa; wspierana przez większość wtyczek formularzy |
| pytanie quizowe („ile to 2+3") | proste pole tekstowe | zaskakująco skuteczne na boty, zero zewnętrznych usług; słabe przy botach celowanych |
Nasza praktyka z wdrożeń: na stronę firmową zaczynamy od honeypot + czas; jeśli spam nadal przecieka, dokładamy Turnstile albo reCAPTCHA v3. Wersję z obrazkami zostawiamy na przypadki oblężenia - każdy dodatkowy klik na drodze do wysłania zapytania to realnie mniej zapytań, co widać w statystykach konwersji.
Pamiętaj też o stronie prawnej: zewnętrzna CAPTCHA ładuje skrypt z serwerów dostawcy i przetwarza dane odwiedzających - wpis do polityki prywatności jest konieczny. Co powinno się w niej znaleźć, opisuje poradnik o regulaminie, polityce prywatności i cookies.
Na wiadomości pisane przez ludzi techniczne pułapki nie działają - tu wchodzą reguły treści, dostępne w większości wtyczek formularzy:
Dwie ustawienia formularza, które nie blokują spamu, ale decydują, czy w ogóle zobaczysz zgłoszenia od klientów:
Wysyłka przez uwierzytelniony SMTP, nie przez funkcję mail() PHP. Formularz wysyłający „na goło" ma sfałszowaną kopertę nadawcy i regularnie ląduje w spamie własnego właściciela. Skonfiguruj wtyczkę SMTP z danymi prawdziwej skrzynki w Twojej domenie - wtedy zgłoszenia przechodzą SPF/DKIM jak zwykła poczta. Jeżeli zgłoszenia „czasem nie dochodzą", zacznij diagnozę od tekstu dlaczego maile trafiają do spamu.
Pole „Od" to Twoja domena, adres klienta w „Odpowiedz do". Ustawienie adresu klienta jako nadawcy to podszywanie się pod cudzą domenę - z DMARC-em odbiorców takie wiadomości przepadają. Poprawny układ: From: formularz@twojadomena.pl, Reply-To: adres z formularza.
Przy okazji: zgłoszenia niech zapisują się też w bazie (większość wtyczek ma „entries") - gdy mail ugrzęźnie, nic nie ginie.
Efekt typowy dla takiego zestawu: ze skrzynki znika 95-99% śmieci, a klient nadal wysyła zapytanie jednym kliknięciem. Formularz to często pierwszy kontakt klienta z firmą - warto, żeby działał bezbłędnie; to część szerszego tematu, który omawiamy w poradniku o stronie internetowej dla małej firmy.
Spamu z formularza nie zatrzymuje się jednym magicznym przełącznikiem, tylko warstwami: ciche pułapki na boty (honeypot, czas, token JS), CAPTCHA dopiero gdy trzeba i w wersji nieuciążliwej, filtry treści na spam ludzki, a pod spodem poprawna wysyłka SMTP, żeby prawdziwe zgłoszenia w ogóle dochodziły. Tak ustawiony formularz pracuje latami bez dotykania.
Klientom naszego hostingu pomagamy skonfigurować i wysyłkę SMTP, i ochronę formularzy w ramach zwykłej pomocy technicznej - a serwerowy antyspam po stronie skrzynek dokłada ostatnią warstwę, gdyby coś jednak przeciekło.
Wszystkie poradniki z kategorii: Firma w internecie