Should your landing page form have a CAPTCHA?

A few weeks of exposure is all it takes for a landing page form to attract its share of automated submissions: fake addresses, promotional messages, injection attempts. The reflex is to add a CAPTCHA — and it's often a miscalculation: the CAPTCHA makes legitimate visitors pay, in friction and abandonment, for what the bots cost you in CRM cleanup. This article puts numbers on that trade-off using the available studies, then walks through the hierarchy of invisible defenses that solve the problem in most cases without hurting anyone. It complements our complete landing page form guide.

What a CAPTCHA actually costs humans

The cost of CAPTCHAs for real visitors has been measured at scale. A 2010 study by Elie Bursztein and his Stanford co-authors (IEEE Symposium on Security and Privacy), based on over a million CAPTCHAs evaluated by humans, measured that a text CAPTCHA takes around 10 seconds of effort on average, that audio CAPTCHAs take nearly three times longer with a much higher failure rate, and that humans are far from solving them every time — with non-native English speakers and older users failing more often. Before it, a 2008 study by Jeff Yan and Ahmad Salah El Ahmad (Symposium on Usable Privacy and Security) had documented CAPTCHAs' systematic usability problems: ambiguous characters, unreadable challenges, near-zero accessibility for visually impaired visitors. Ten seconds of friction and a risk of failure placed right before the submit button, on a page where every superfluous field already costs abandonment — as our analysis of how many form fields to use shows — is exactly the opposite of what you're optimizing for.

The real question: what does spam cost you?

The honest reasoning starts from the other side: what does spam actually cost you? For a landing page capturing emails into an email tool, a few fake addresses a week cost almost nothing — a manual filter or double opt-in eliminates them. For a form that triggers a phone follow-up by a sales rep, every fake lead costs a wasted call: protection pays off sooner. And for a form wired to a tool billed per contact, spam becomes a direct cost. The decision comes down to comparing two losses: legitimate visitors' abandonment caused by friction (usually invisible, therefore underestimated) versus the cost of processing spam (visible, therefore overestimated). For the vast majority of landing pages, the friction costs more than the spam it prevents.

The hierarchy of defenses: from invisible to visible

• 1. The honeypot: a field hidden with CSS that humans never see but bots fill in — any submission with that field filled is rejected. Zero friction, effective against the generic bots that make up most form spam.
• 2. Fill-time checking: a form submitted 800 milliseconds after page load wasn't filled in by a human. Rejecting too-fast submissions costs zero friction.
• 3. Strict server-side validation: email format checked, field lengths bounded, link-heavy content rejected on a contact form — indispensable anyway, CAPTCHA or not.
• 4. Rate limiting: capping submissions per IP address per time window blocks bursts without affecting a normal visitor.
• 5. Double opt-in for email capture: the address only enters the list after a click on the confirmation link — fake addresses eliminate themselves, with a healthier list for deliverability as a bonus (see our article on the newsletter landing page).
• 6. As a last resort, an invisible or discreet challenge: modern solutions like Cloudflare Turnstile or reCAPTCHA v3 score the session without a visual puzzle in most cases, and only show a challenge to suspicious sessions.

This hierarchy has a simple logic: you only inflict a visible challenge on 100% of visitors once the defenses that cost nothing have failed. On LanderKit templates, the honeypot and strict validation take a few lines to set up, since the form code ships as source — one of the concrete advantages of a page whose code you control rather than a closed widget.

If you really must show a CAPTCHA

Some contexts force it: a form under sustained targeted attack, a third-party service requirement, a very-high-traffic campaign attracting bot farms. In that case, three rules limit the damage. First, pick a solution that only shows a challenge to suspicious sessions rather than a systematic image grid. Second, place the challenge after the submit click, not in the middle of the form: a visitor who has already filled everything in is more likely to push through than one stopped before they've started. Third, get the failure message right — a legitimate visitor who fails the challenge must be able to retry without losing what they typed, a topic our article on form microcopy covers in detail.

Then there's compliance: the major providers' CAPTCHAs rely on analyzing the visitor's session, sometimes via cookies and data transfers outside the EU — in France, the CNIL has examined these mechanisms several times, notably on the question of consent. Without going into a legal analysis that depends on the chosen solution and its configuration, the practical point is simple: adding a CAPTCHA is not neutral under GDPR, and deserves the same scrutiny as the rest of the form — our guide to GDPR-compliant forms provides the framework. One more reason to prefer invisible server-side defenses, which don't analyze the visitor.

Measure before and after: the only proof that counts

If you add or remove a protection, measure it: form completion rate before/after, spam volume before/after, and if possible the challenge failure rate for visitors (serious solutions expose it in their dashboard). An A/B test settles it definitively when traffic allows. The typical outcome — far less spam with a honeypot and strict validation, no visible CAPTCHA and no conversion loss — is achievable on most landing pages: the visible CAPTCHA should remain the last-resort exception, not the default reflex.