Seven methods that block automated form submissions without asking your visitors to prove anything — ranked by how well each one actually holds up, including the ones that no longer do.
Every form on the public internet gets automated traffic. If you run a contact form, a demo request, a newsletter signup or an event registration, some share of what lands in your inbox was never typed by a person. The usual reflex is to bolt on a CAPTCHA — and the usual result is that the spam keeps arriving while your real visitors do unpaid labour to get through.
This guide covers what works instead. It is written for the person who has to make the decision, not for a search engine: every method below includes what it catches, what it misses, and when it is not worth the effort.
A CAPTCHA asks a visitor to prove they are human before you will accept their submission. That design has three structural problems, and none of them are fixed by picking a nicer-looking CAPTCHA.
It taxes the wrong party. The overwhelming majority of people who see your challenge are real customers. You are adding a step to every genuine submission in order to inconvenience a minority of automated ones.
It is an accessibility barrier. Image and audio challenges are a known obstacle for screen reader users, people with dyslexia, people with low vision, and anyone with a motor impairment that makes precise clicking hard. WCAG does not forbid CAPTCHAs, but it does require an accessible alternative — and in practice most implementations ship without a usable one.
It answers a question that is easy to fake and stops asking. A solved challenge is a single yes/no signal collected before the form is filled in. It tells you nothing about how the submission was actually composed, and commercial solving services — 2Captcha, Anti-Captcha, CapMonster and similar — have made the yes/no cheap to buy: human click-farms will solve reCAPTCHA challenges for roughly $1–2 per 1,000. Meanwhile the signals that would have exposed the bot — timing, field order, input cadence — are never examined, because the gate already opened.
"Stop showing CAPTCHAs" and "stop inspecting traffic" are not the same decision. Everything below inspects more than a CAPTCHA does. The difference is that the inspection happens on your side instead of in front of your customer.
Ranked by how much spam each one removes for the effort it costs, on a typical marketing site. Nothing here is exotic; several you can ship this afternoon.
| Method | Catches | Effort | Still works? |
|---|---|---|---|
| Behavioural analysis | Nearly all automated submissions | Low (hosted) / High (own) | Yes |
| Submission timing | Scripted fast-fill bots | Low | Yes |
| Rate limiting | Volume attacks, list bombing | Low | Yes |
| Server-side validation | Malformed and injected payloads | Low | Yes |
| Disposable email detection | Throwaway signups | Low | Partly |
| Honeypot fields | Naive form-fillers | Very low | Partly |
| Keyword / content filtering | Recognisable spam text | Medium, ongoing | Rarely |
Humans and scripts fill in forms differently, and the differences are not subtle. People move a pointer or move focus between fields, type at an irregular cadence, correct themselves, and take seconds to minutes overall. Scripts populate fields in DOM order, in milliseconds, with no interaction events at all, often from an environment that reports a browser it is not.
Reading those signals catches far more than a challenge does, because there are many of them and a bot has to get all of them right. It is also invisible: a real visitor submits a form and nothing happens to them. The cost is that doing this well is not a weekend project — you need signal collection that survives real-world browsers, and a scoring model that is updated as automation tools change.
Record when the form was rendered, compare it to when it was submitted, and reject anything implausibly fast. A person who genuinely fills in four fields does not do it in 400 milliseconds.
Implement it server-side with a signed timestamp — a plain hidden input with the render time is trivially rewritten by the client. Set the floor low enough that a fast, familiar user is never caught: two seconds is defensible for a multi-field form, and much less for a single email field. Consider an upper bound too, since some scripts sit on a page for hours.
Cap submissions per IP, per session and per target address over a rolling window. This does nothing against a single carefully-paced bot, and everything against the volume attacks that actually hurt: signup-form list bombing, credential probing, and the scraped-list blasts that fill a CRM overnight.
Rate limit at the edge where you can — a CDN or WAF rule is cheaper and faster than application code — and remember to key on something more durable than IP alone, since a distributed attack rotates addresses.
Validate on the server, always, regardless of what the browser already checked. Enforce field types, lengths and allowed characters; reject submissions carrying fields your form never rendered; strip or refuse URLs in fields that have no reason to contain one.
This will not stop a bot that fills your form correctly, but it removes an entire class of junk and it is the layer that protects you from the submissions designed to do damage rather than merely waste your time.
Checking the submitted address against a list of throwaway and temporary mail domains removes a visible chunk of low-quality signups, and helps protect your sender reputation as a side effect.
Its limits are worth knowing. The domain lists are never complete, new ones appear constantly, and some of your genuine users have legitimate reasons to use an alias service. Use it to score a submission, not as a sole reason to reject one.
Add a field a human will never see and never fill — hidden with CSS, positioned off screen, or rendered with a name that looks appealing to an automated filler. If it comes back populated, the submitter was not a person.
It costs almost nothing, so add one. But be honest about the ceiling: commercial
spam tooling has known this trick for years, and many form-fillers now skip fields
that are hidden or suspiciously named. Hide it in a way that does not announce
itself — avoid name="honeypot" — and never hide it with
type="hidden", which every bot ignores by default.
A honeypot hidden with display:none is invisible to sighted users but
may still be announced and focusable for someone using a screen reader — who then
fills it in and gets silently rejected. Hide it from assistive technology too, with
aria-hidden="true" and tabindex="-1" on the input.
Blocking submissions containing particular words or link patterns is the oldest approach here, and the weakest. Spam text mutates continuously, the rules need constant tending, and the false positives are painful in a way the others are not — a real prospect writing about "SEO services" should not be silently binned.
It has one good use: filtering the human-written spam that behavioural detection correctly identifies as human, because a paid form-filler in a click farm really is a person. Keep it narrow and keep it reviewable.
You do not need all seven. A sensible progression, stopping wherever your problem stops:
SpamKill is step four as a hosted service. It renders two versions of every form — a clean one for people, an obfuscated one for automated fillers — and scores the submission on behaviour rather than content, at 99.9% accuracy across more than 100M+ submissions screened for 1,500+ businesses. Visitors see nothing; the rare flagged person verifies in one step and continues, and anything held is recoverable rather than deleted. Plans start from $29/month, with a 30-day free trial, no credit card.
If steps one to three already solved your problem, you do not need us. That is a real answer, and it is the one we would give you on a call.
"The spam stopped" is not a measurement, because you cannot see what you blocked or what you lost. Track three things instead:
Stacking two form gates. Running a CAPTCHA and a behavioural system on the same form gives you the friction of one and the accuracy of neither: each sees part of the picture, and your real users still get stopped by whichever is weaker. Choose the layer that inspects the submission. Network-level protection at your CDN operates at a different layer and is fine to keep.
Blocking silently. If a rejected submission leaves no trace, you will not discover a false positive until a customer tells you they tried to reach you three times — if they bother.
Trusting the client. Timestamps, honeypot state and validation all have to be enforced server-side. Anything decided in the browser is a suggestion.
Tuning once and walking away. Automated traffic changes. A rule set that was effective a year ago is being routed around today, which is the fundamental reason per-trick defences drift and scored, updated detection does not.
Yes. CAPTCHAs are only one way to tell a human from a bot, and they are the only one that makes the human do the work. Honeypot fields, submission timing, behavioural signals, rate limiting and server-side validation all identify bots without asking the visitor for anything. Most sites get further with a combination of those than with a CAPTCHA alone.
Partly. A hidden field that only a bot fills still catches naive form-fillers, and it costs nothing to add, so it is worth doing. But commercial spam tools have read the honeypot playbook: many now skip fields that are visually hidden or named like a trap. Treat a honeypot as a cheap first filter, not as your whole defence.
Not if you replace it with something that works. A CAPTCHA only inspects whether a challenge was solved; it cannot see how the form was filled in. Behaviour-based detection has more signal to work with, not less. What changes is who does the work — the detection moves from your visitor to your server.
No. Stacking two form gates gives you the friction of the CAPTCHA and the accuracy of neither, because each system sees only part of the picture and real users still get stopped by the weaker one. Pick the layer that inspects the submission. Network-level protection such as a WAF or bot-management rule at your CDN sits at a different layer and is fine to run alongside.
Look at the timing and the pattern. Submissions that arrive within a second or two of page load, in bursts, from the same network, with fields filled in perfect field order, are automated. Real spam from real humans — paid form-fillers — looks different and needs a different answer, usually content filtering and rate limits rather than bot detection.
They do not ban CAPTCHAs outright, but they make them hard to justify. WCAG treats an image or audio challenge as a barrier that needs an accessible alternative, and screen reader users, people with dyslexia and people with motor impairments all measurably struggle with them. A detection method that asks the visitor for nothing has no accessibility surface at all.
Run your real form HTML through the Form Transformer and get the protected version back — no signup, no card, nothing to install.
Open the Form Transformer