FORM SPAMStop bots, not customers
SELLWRIGHTContact form spam costs more than a cluttered inbox. It buries real enquiries, triggers automations that create junk CRM records and wastes your team's time. The usual fix, a puzzle CAPTCHA, puts the burden on every genuine visitor instead. We prefer layers: several quiet checks that bots fail and people never notice.
Why use layers instead of one big check?
Because each check catches a different kind of bot, and none is perfect on its own. A honeypot catches simple scripts that fill in every field. A time check catches scripts that submit instantly. Server-side validation catches anything that skipped your form entirely, and rate limiting stops floods from one source. An invisible challenge such as Cloudflare Turnstile handles the smarter bots. Together they add no visible step for a person.
How does a honeypot field work?
A honeypot is an extra field that people never see, so only bots fill it in. Hide it with a class in your stylesheet rather than an inline style, give it a plausible name, and set autocomplete="off" so the browser is not permitted to fill it in automatically. Because display: none removes the field from the accessibility tree, screen reader users never meet it either.
<!-- form -->
<div class="form-extra">
<label for="website_url">Leave this field empty</label>
<input type="text" id="website_url" name="website_url" autocomplete="off">
</div>
/* stylesheet */
.form-extra { display: none; }
// server, before anything is saved or sent
if (data.website_url) return showThankYou(); // looks normal, nothing storedWhen the honeypot is filled, respond as if the message was sent, then do not save or forward it. Telling a bot exactly why it failed only helps it adapt.
What else should the server check?
Everything, because checks in the browser are easy to bypass. MDN is clear that form data must be validated on the server as well as the client, since a malicious user can alter the request. On every submission we check:
- Fill time: the form carries a signed timestamp from when it loaded, and submissions that arrive faster than a person could type are dropped.
- Field rules: a valid email address, a sensible message length, and no links in fields that should never contain them, such as a name.
- Expected fields only: reject requests with missing required fields or extra fields your form does not have.
- Rate limits: cap submissions from one IP address over a short window and return
429 Too Many Requests, optionally with aRetry-Afterheader. If the site runs through Cloudflare, a rate limiting rule can block or challenge excess requests before they reach your server.
Where does Cloudflare Turnstile fit?
Turnstile is Cloudflare's CAPTCHA alternative, and it is the layer we add when the others are not enough. It can be embedded in any website without sending your traffic through Cloudflare, and it does not ask visitors to solve a visual puzzle. There are three widget modes: managed, which shows a checkbox only when a visitor looks risky; non-interactive, which shows a small widget with a loading spinner; and invisible, which runs entirely in the background.
The widget adds a hidden cf-turnstile-response field to your form. Your server must send that token to Cloudflare's Siteverify API with your secret key, because the widget on its own does not protect the form. Each token can be validated once and is valid for five minutes, so plan for the visitor who leaves the form open and submits later.
How do you know it is working?
Log each rejected submission with the time and the reason: honeypot, fill time, a failed rule, a rate limit or a failed Turnstile check. Review that log every month. If a real enquiry ever shows up in it, loosen the rule that caught it; if spam still reaches the inbox, find the layer it slipped past and tighten that one.
Run all of these checks before any automation fires, so junk never becomes a CRM record or a sales alert in the first place.
Where to start
Add a honeypot and server-side validation first; both are quick to build and invisible to customers. Then watch the log for a few weeks before deciding on Turnstile. Our automation and integrations service builds the whole path from form to CRM, and every lead, handled automatically shows the flow we usually connect it to.
FAQ
Frequently asked questions
Is Cloudflare Turnstile a CAPTCHA?
Cloudflare describes it as a CAPTCHA alternative. It runs its challenges without a visual puzzle and, in managed mode, shows a simple checkbox only when a visitor looks risky. Whichever mode you choose, your server still has to validate every token through the Siteverify API before it accepts the submission.
Does a honeypot field hurt accessibility?
Not if it is hidden properly. A field hidden with display: none is removed from the accessibility tree, so screen readers do not announce it, and autocomplete="off" stops the browser filling it in for real visitors. Give it a clear label anyway, so anyone who sees it when styles fail to load knows to leave it empty.
Can bots get past a honeypot?
Some can, which is why the honeypot is one layer of several. Bots that render pages and skip hidden fields still meet the fill time check, the server-side rules, the rate limit and, if needed, Turnstile. We add the layers in that order and only move to the next one when the log shows spam getting through.
What should happen when a real customer is blocked?
Make the failure friendly. If a rule or a Turnstile check rejects a submission that looks genuine, show a short message with your email address or phone number so the person can still reach you. Then review the rejection log and loosen any rule that ever catches a real enquiry.
Should we keep a record of rejected spam?
Keep a short log of rejections with the time and reason, then delete it on a schedule. That is enough to tune the rules without holding on to junk or personal data you do not need. Never forward rejected submissions into your CRM, email sequences or other automations.
