Stop form spam without wrecking your conversion rate

Spam filtering for forms fails when teams treat it as one switch. It is at least three separate problems. Naive bots scrape the web and POST to any form they find - high volume, low sophistication. Targeted scripts are written against your specific form and walk right past generic defences. Human spam is typed by real people in spam farms or by opportunists dropping SEO links and pitches - it has real keystrokes behind it and looks, structurally, exactly like a real submission.

Each class needs a different layer, and the layers should escalate in cost so that the cheapest defences handle the bulk of the traffic and your legitimate visitors never pay the price. A CAPTCHA stops sophisticated bots, but if you reach for it first you tax every real user to catch a problem the honeypot already solved for free. The discipline is to stack defences from cheapest to most expensive and let each one filter what the one before it missed.

The rest of this guide walks the stack in that order. The spam-protection overview is the doc index if you want to dig into any single layer, and the blog post comparing honeypot, reCAPTCHA, and hCaptcha has the head-to-head detail.

Your first two layers cost nothing, run on every plan including Free, and are on by default on every form.

A honeypot field is an invisible field that a human never sees but an automated bot reliably fills in. Any submission that populates it is silently rejected. Because real visitors never encounter the field, it has zero conversion cost while catching the majority of drive-by bot traffic. There is nothing to configure - it is injected automatically. The honeypot doc explains how the field is hidden and why it works.

Rate limiting is the second free layer: it throttles repeated submissions from the same source so a script cannot flood your endpoint with thousands of requests. The thresholds are documented in the rate-limits doc.

For a low-traffic contact form, these two layers alone often handle effectively all of the spam you will ever see. Only add more when you can point to junk that is actually getting through.

When targeted spam slips past the structural layers, you write rules against your actual abuse patterns rather than waiting for a generic filter to catch up.

Custom rules let you block or flag submissions based on their content and context: reject disposable email domains, flag any message containing certain links or phrases, block submissions in languages you do not serve, or require a field to match a pattern. The point of custom rules is precision - you are encoding what your spam looks like, which a model trained on the global average cannot know.

Rules are cheap to run and cost legitimate users nothing, so they sit early in the stack. They are also the right escape hatch when a later layer consistently misses a category of spam you care about: rather than fighting the AI threshold, layer a custom rule on top that catches the specific pattern. Start with one or two rules aimed at the abuse you are actually seeing, not a wall of speculative filters.

Structural checks and your own rules catch bots and known-bad patterns, but they cannot tell that a perfectly-formed message is a copy-pasted pitch that has been sprayed across thousands of forms. That is what reputation filtering is for.

Reputation services score a submission against a global corpus of known spam - content and sender signals seen across many sites - and flag the matches. It is the layer that catches content-level junk that passes every structural test because the text itself is recognised, not the shape of the request. Reputation filtering complements your custom rules: rules encode what you know about your spam, reputation encodes what the network knows.

This layer sits above the free defences because it relies on an external corpus, and below AI moderation because it matches against known spam rather than reasoning about novel content. For the conceptual background on how content-level filtering differs from structural checks, see the post on AI spam moderation beyond regex.

The hardest spam to catch is human-written: manually-typed junk that lands real keystrokes on a real keyboard but is still garbage - SEO link drops, copy-pasted bot pitches, harassment, and phishing attempts. Structural and reputation layers were never designed to catch it, because it is structurally indistinguishable from a real message. This is the one layer that reliably does.

On Pro plans and above, every submission runs through a language-model moderation classifier that reads the submission body and returns a score from 0.0 to 1.0 - higher means more likely spam. Each form has a moderation threshold (default 0.75): submissions scoring at or above it are filed in the spam folder rather than deleted, so a false positive costs a click, not a customer. The score also carries a category - harassment, solicitation, phishing, nonsense - shown next to it on the submission.

The threshold is the only knob, and you tune it to your tolerance: lower it (say 0.55) to over-flag and hand-review, raise it (say 0.90) to only catch obvious garbage, or set it to 1.0 to keep the score visible without acting on it. The AI moderation doc covers the score range, where it appears in the UI and API, and exactly how plan gating works. Free plans do not run the classifier - the moderation score is simply absent. The moderate-and-categorize guide goes deeper into using the score alongside auto-categorization.

A CAPTCHA - hCaptcha or reCAPTCHA - stops sophisticated bots that survive every layer above, but it is genuinely a last resort because it is the only defence that taxes your real users. Every challenge costs conversions; depending on your audience, abandonment from CAPTCHA friction typically lands somewhere between 3% and 12%.

That cost is why the order in this guide matters. By the time a submission reaches the CAPTCHA decision, the honeypot, rate limits, custom rules, reputation filtering, and (on paid plans) AI moderation have already removed the overwhelming majority of spam without touching a single real visitor. A CAPTCHA should only carry the residual that those layers cannot - and on many forms that residual is zero, which means no CAPTCHA at all.

When an attack does justify it, configure the CAPTCHA per form - on the one form under attack - never globally as a reflex across every form you run. The how CAPTCHA kills form conversion post has the numbers behind the trade-off.

A working spam strategy is a stack, not a switch. Run them in this order and let each catch what the previous one missed:

1. Honeypot + rate limits - free, automatic, on every form. Catch naive bots and floods.
2. Custom rules - free, precise, aimed at your actual abuse patterns.
3. Reputation filtering - catches known spam content the structural layers pass.
4. AI moderation (Pro and above) - catches human-written junk, files it for review rather than deleting.
5. CAPTCHA - last, per form, only when a real attack justifies the conversion cost.

The two principles to remember: escalate cost so legitimate users rarely pay it, and never delete - flag and file suspect submissions so a false positive is recoverable. Most forms live happily on the first two layers; reach for the higher ones only when the spam you can actually see warrants it.

Ready to lock down a form? Start free - the honeypot and rate limits are already protecting it, and AI moderation is one upgrade away. The stop-form-spam without a CAPTCHA comparison is a good next read.