What a CAPTCHA Actually Costs You
A CAPTCHA works. That is not in dispute. The question nobody asks before installing one is what it costs on the other side of the ledger, because that cost is invisible: the enquiries that never arrive leave no log entry and no notification.
Every extra interaction between a visitor and a submitted form loses some proportion of genuine users. Published figures vary by industry and form length, but the direction is consistent and the effect is larger on mobile, where an image challenge on a small screen over a slow connection is a meaningful obstacle. For a local service business taking twenty enquiries a month, a few percent is not a rounding error — it is the difference between a quiet month and a normal one.
There is a second cost that gets less attention. Image and audio challenges are a genuine accessibility barrier, and in several jurisdictions an inaccessible enquiry form is a compliance problem rather than a design preference. Invisible scoring variants avoid the visual challenge, but they work by profiling the visitor, which brings its own disclosure obligations under GDPR.
Spam that reaches your inbox is visible and annoying, so it feels urgent. Enquiries lost at the form are invisible and silent, so they feel like nothing. The second number is usually the larger one.
Where Contact Form 7 Spam Actually Enters
Most people picture a bot filling in the visible form the way a person would. Very little spam works that way. The overwhelming majority posts directly to the endpoint, skipping your page, your styling and any JavaScript you loaded entirely.
This matters because it determines which defences can possibly work. Anything that runs in the browser — a JavaScript check, a field that only appears after interaction, a client-side validation rule — is never executed by a bot that never loaded your page. It filters nothing. Only a check that runs on the server, after the request arrives and before the handler fires, sees every submission.
The practical consequence is that the ordering of your defences matters more than the number of them. A stack of five client-side tricks stops less than one correctly placed server-side check.
The Layers That Work, In Order of Return
No single technique stops everything, but they are not equally valuable either. Ordered by what they catch per unit of effort and risk:
- Honeypot field. A field hidden from humans by CSS that automated submitters fill in anyway. Costs nothing, breaks nothing, invisible to real visitors, and catches a large share of naive bots. There is no reason not to have one.
- Rate limiting per IP. Bots submit at volumes humans never reach. Capping submissions per address per window removes bulk attacks without ever touching a genuine visitor. Watch the shared-IP case — an office or a mobile carrier NAT can put many real people behind one address.
- Server-side keyword and pattern filtering. Runs on the submitted payload after it arrives. Catches the recurring content patterns — link spam, SEO pitches, cryptocurrency, the same three templates the tools ship with — before any handler or email fires.
- Timing checks. A form submitted under two seconds after page load was not filled in by a person reading it. Cheap, and effective against the middle tier of bots that do render the page.
- Optional AI classification. For the residual that survives everything above, particularly the hand-written or well-disguised kind. Worth it only after the cheaper layers are in place, since it has a per-request cost and an external dependency.
Put the free, deterministic checks first and the expensive or external ones last. If a honeypot catches a submission there is no reason to spend an API call classifying it.
What This Means for Contact Form 7 Specifically
Contact Form 7 ships no spam protection of its own beyond optional integrations, which is why almost every guide reaches for a CAPTCHA plugin. The integrations it does offer are worth understanding before you add anything.
Akismet integration is built in and works well on comment-style content, but it was trained on comment spam and its accuracy on service enquiry forms is noticeably weaker. It is also a paid service for commercial use, and it sends submission content to a third party — which is a disclosure you now have to make.
The more important point is architectural: Contact Form 7 exposes a server-side hook that runs before the mail handler. Any check placed there sees every submission, including the ones that never loaded your page, and can reject before an email is generated or an entry stored. That is the correct insertion point, and it is the one a client-side CAPTCHA does not occupy.
How to Verify It Worked
Almost nobody checks. The form stops producing obvious spam, the problem feels solved, and nobody notices that genuine enquiries also stopped arriving. Two things need measuring, not one.
First, that spam is actually being blocked rather than silently delivered somewhere you stopped looking. Any filtering worth running keeps a log of what it rejected and why, so you can read the rejections rather than trust a counter.
Second, and more important, that you are not blocking real people. Read the blocked log weekly for the first month. A genuine enquiry sitting in it is a false positive, and false positives are far more expensive than the spam you are trying to remove. If the log is difficult to read or does not record a reason per rejection, you cannot answer this question and you should fix that before tuning anything else.
Submit your own form from mobile data, with a real message, and confirm it arrives. Then check that it is not in the blocked log. Do this after every change to the filtering rules.
When a CAPTCHA Is Still the Right Answer
Being honest about this matters more than being consistent. A CAPTCHA earns its conversion cost when you are facing a targeted, adaptive attacker rather than background automated noise — someone who is specifically working around your defences and adjusting when you change them.
It is also reasonable on forms where the cost of a fraudulent submission is high and the cost of a lost enquiry is low: account registration, password reset, anything that creates a record or triggers a paid action. A contact form for a local service business is the opposite case on both axes, which is why the default advice fits it so badly.
For ordinary background spam on an enquiry form, the layered server-side approach removes effectively all of it while leaving the form a single step for the person on the other end. That is the trade worth making.
- The plugin we built for this — server-side keyword filtering, honeypot, rate limiting and optional AI detection, with a readable blocked log so you can audit false positives.
- Install it from WordPress.org — free, GPL-2.0+, no account required.