Form spam isn’t new - we've written about it before. It’s been around since the beginning, and like most developers, I’ve always had a go-to list of ways to deal with it: a honeypot field, some version of CAPTCHA, maybe CleanTalk or Akismet, and if I’m feeling thorough, a firewall plugin like Wordfence.
That’s been enough for years. But recently, two of our client sites, both running Gravity Forms, started getting slammed with spam submissions. Nonsense messages like “I enjoyed our conversation,” “ihsdifdsifsji,” and “thank you for your help” were flooding their inboxes every day.
All the usual tools were already in place. CleanTalk? Active. Honeypots? Set up. reCAPTCHA v3 with a high threshold? Running. Delayed submissions? Configured. Wordfence with country blocking? On. Still, the spam kept coming.
And no, it wasn’t coming from foreign IPs. These were all US-based, often from the same regions our clients serve. We couldn’t just block entire countries or narrow the firewall rules without cutting off real leads.
This kind of spam doesn’t just make your client think their form isn’t working. It can actually cause them to miss legitimate submissions buried under junk. And if you’re the one who built the site, they’re looking to you to fix it.
Here are the three methods that actually made a difference for us, after everything else failed.
We make some damn good websites.
Hit Us Up1. Switching from reCAPTCHA to Cloudflare Turnstile
Google’s reCAPTCHA has become more of a problem than a solution. Even version 3, which is supposed to work silently in the background, still slows things down and often doesn’t stop much.
Turnstile, on the other hand, has been solid. Once we switched the affected sites to Turnstile, spam dropped off almost instantly. It’s free, doesn’t slow down page loads, and doesn’t require people to click on fire hydrants or traffic lights.
If you're using Gravity Forms, there's a Turnstile add-on that makes setup quick.
2. Using Cloudflare’s Bot Protection and WAF Rules
If the site is already on Cloudflare (and we usually set up clients that way), we turn on their bot management tools. Most people skip these features or don’t realize how useful they can be.
We use:
-
Rate limiting to block repeat form submissions
-
Rules that block suspicious user agents
-
Filters that look for keywords or patterns in spam content
This stops a lot of low-effort bot spam before it even reaches the server. For most clients, this works quietly in the background and doesn’t interfere with real users.
3. Adding Custom Filters Based on Content and Behavior
For spam that still sneaks through, we use a scoring system based on common spam signals. These include:
-
Submissions that come in under 5 seconds
-
Forms submitted with no mouse movement or tab interaction
-
Email addresses from known spammy domains like
.ru
-
Entries that include links or flagged words like “free software” or “download here”
-
Non-English characters on English-only sites
Each of these gets a score. If the total score crosses a certain threshold, the submission is blocked or flagged for review.
These filters don’t just stop spam—they stop the kind that slips past commercial tools. And they’re invisible to normal users.
Why We Don’t Use User-Blocking Tricks
Some people suggest using logic questions like “how many letters are in the company name” or hiding the submit button unless a condition is met. That might work, but we don’t like to make the form harder for real people to use. Most visitors aren’t going to bother solving puzzles just to get in touch. We avoid anything that adds friction unless we’ve exhausted every behind-the-scenes fix.
Bonus: When We Need More
If nothing else works and the client really needs a higher level of protection, we’ll consider something like OOPSpam. It’s a paid service and can get pricey, but it’s smart and effective. So far, we haven’t had to use it often, but it’s a good option to keep in the back pocket.