Experimenting with new technology is part of how Mana works, and so is periodically interrogating our own tooling: is the thing we have used for years still the best answer? The habit matters because most tools stay in place not through a bad decision but because they work. And while something works, few people ask whether anything better exists.
Our bot protection was Google reCAPTCHA for years. It did its job quietly and caused no trouble. That is precisely what made it a good candidate for review — the familiar default that had become invisible, untouched because nothing forced us to touch it. Its turn came up, and we tried Cloudflare Turnstile in its place.
The immediate trigger was rebuilding our contact form and adding newsletter signup. At the same time we removed our public email address from the footer, because a published address reliably attracts spam and address harvesting. Two new forms are a good moment to look at what actually protects them. Where we landed matters less than the criteria that got us there, and those criteria apply just as well at another company.
In bot protection the widget — that little verification box at the bottom of the form — is only the surface. The substance of the protection is decided on the server, and it stays there no matter which provider you pick. Replacing the widget replaces the surface, not the protection.
Why bot traffic is a problem on a B2B site
On a B2B site, bot traffic is rarely an attack in the dramatic sense. The duller version is far more common: automated scripts crawl the web and fill in every form they find. That does damage in four separate places, none of them spectacular, which is why it goes unnoticed for so long.
The first is CRM contamination. Fake or nonsensical submissions land in the sales system and sit there as genuine leads. Someone has to review and filter them, and if nobody does, a salesperson spends real time chasing prospects who do not exist.
The second is distorted measurement. If inbound lead count is one of marketing's metrics, bot submissions inflate it. The team believes a campaign is performing well when part of the lift is machine noise. Bad data turns into a bad decision about where the next marketing spend goes.
The third is newsletter list decay. Fake addresses, or addresses belonging to other people, degrade list quality and with it deliverability — whether the email reaches the inbox or the spam folder. A newsletter sent from a sufficiently polluted list can drag down the reputation of the entire domain.
The fourth is harvesting of a published email address, which is what drove the footer decision. A public address does not need to be enticed into receiving spam. It arrives on its own.
How CAPTCHA works, and what is wrong with it
A CAPTCHA is a test that tries to determine whether a human or a machine is filling in the form before the submission becomes valid. The classic approach does this visibly: click the checkbox, select the images containing a traffic light, type the distorted text. There are two problems with that approach, and neither is technical.
Friction in the customer experience
Every extra step imposed on a user lowers the completion rate. That holds for forms generally and stings particularly in B2B, where a prospect is rare and valuable. The goal is not a thousand conversions out of ten thousand visitors but the handful of serious ones out of a hundred. An image puzzle that has to be solved twice stops someone at the worst possible moment, the instant of submission. The loss is invisible, because anyone who walks away over it disappears without a trace.
Then there is accessibility. A visual puzzle excludes visually impaired users by design, and the audio alternative is typically weak and cumbersome. At a B2B company that takes reachability seriously, this is not a minor detail.
The privacy dimension
reCAPTCHA is a Google service, and to function it forwards browser-derived signals to Google so it can judge whether the behaviour looks human. In a European context that raises a recurring question: on what notice and on what legal basis does a visitor's data reach a third party, and one outside Europe at that. The precise legal assessment depends on the specific configuration, on how consent is handled, and on the prevailing regulatory position. The choice is therefore not purely a technical decision but a privacy one, and most teams skip that consideration.
The practical consequence is where this becomes tangible. Turnstile uses no cookies to operate and builds no profile of the visitor, so it typically requires no separate consent field or consent-banner integration on forms. With reCAPTCHA this is a recurring headache, because the data flowing to Google and the cookie usage make consent handling a separate task every time.
How Turnstile works
Instead of the classic puzzle, Turnstile asks nothing of the user in most cases. The widget runs browser signals and lightweight checks in the background, among them a proof-of-work step: the browser has to complete a small computation, imperceptible to a person but a noticeable cost to a mass bot farm running thousands of submissions at once. Cloudflare calls this a managed challenge — the system decides whether any interaction is needed at all. In a suspicious case it surfaces a simple step, and for the majority it stays invisible.
Once the check has run, the widget issues a token, a short signed attestation that the submission passed. That token is worth nothing on its own until the server confirms with the secret key, at Cloudflare's siteverify endpoint, that it is genuine and valid. This is where protection is decided. If the server skips that step and treats the mere presence of a token as sufficient proof, the widget is decoration, because the token can be forged or replayed.
The familiar alternative, reCAPTCHA, comes in two main variants. v2 is the one most people know: a checkbox, occasionally backed by an image puzzle. v3 is invisible, and rather than allowing or blocking it returns a score between zero and one for how human the visitor appears, leaving the threshold decision to the developer. What all three have in common is the same point that applies to Turnstile — the client only signals, and the server has to make the decision.
What Turnstile does not solve either
It would be convenient to write that we made the switch and the problem was solved. It was not. Several things stayed open.
Effectiveness depends on how serious the attacker is. Turnstile will likely stop a simple, high-volume script. No widget reliably stops a determined, targeted attacker who automates a real browser, or who pays human solvers to work through the challenges. A challenge filters most of the noise, not the best-prepared opponent.
Most of the team's work remains. Server-side token validation is not optional — it is the only point at which the protection takes effect. Alongside it you need rate limiting (capping how many requests you accept from one source in a given period), one or more honeypot fields (a hidden form field a human never sees or fills but a bot does, so a filled one means the submission gets dropped), and measurement, so you can see how much spam gets through. None of these is the widget's job.
And there is vendor dependency. Turnstile ties you to Cloudflare, so an outage on their side means your form's protection falters too. That is not a fault of Turnstile — reCAPTCHA ties you to Google in exactly the same way. It is simply worth being conscious that a step in your process now sits with an external provider.
It follows that reCAPTCHA, or another solution, can remain a good answer. If a company's stack is already deeply Google-centric, if enterprise-grade support, detailed risk analysis or contractual guarantees are required, or if the team has known and operated reCAPTCHA for years, switching carries no necessary business benefit.
A framework for the decision
For a B2B company facing this same decision, five criteria are worth weighing, roughly in this order.
- UX and conversion. What does a lead cost, and how much friction can the submission bear? The more valuable and rare a completion, the more expensive every extra step becomes, and the more a typically invisible check is worth.
- Privacy. What data goes where, and on what notice? With a European audience and in a B2B context, what matters is that bot protection is consistent with the company's own data principles, not merely that it works.
- Existing stack. What does the choice fit, and what does the team already know? Turnstile slots naturally into infrastructure already running on Cloudflare, and reCAPTCHA into a Google-centric one.
- Support and enterprise requirements. Do you need contractual guarantees, risk assessment, detailed logging? Where you do, the service-level agreement can matter more than the widget's convenience.
- Cost and scaling. How far does free go, and what happens at high volume? Turnstile has no volume threshold. reCAPTCHA's free tier is capped, and scaling past it moves you to a paid enterprise level. At high request counts that can be a material difference.
In our case these criteria tipped towards Turnstile. The frictionless, typically invisible experience and the smaller amount of data forwarded to a third party outweighed reCAPTCHA's familiarity. Cost came on top: Turnstile is free with no traffic ceiling, while reCAPTCHA's free allowance is capped and scaling past it moves you to a paid tier. But the substance of the decision was not settled there. However invisible and convenient the widget, our CRM is protected exactly as well as the server-side validation, the rate limiting and the honeypot written behind it. Swapping the widget is an afternoon's work. The discipline behind it is not, and it cannot be outsourced to a provider.
Two lessons remain, and the second is the more important one. The first is that a form's protection is decided on the server, not at the button. The second is that a tool which has proven itself has not proven itself forever. reCAPTCHA was a good choice when we adopted it, and it may still be the right one for someone else. The mistake would not have been staying with it, but never asking why. The cost of a bad default is invisible — it does not ring an alarm and it does not throw errors, it just accumulates quietly in better solutions never adopted. Questioning it, by contrast, is cheap, often a single afternoon. That is the worst possible ratio in a decision: cheap to check, expensive not to, and precisely why the check gets skipped almost everywhere.
So the useful question has two halves. In the short term, where is your form's protection actually decided? The answer is almost always the server, not the button. In the long term, which of your tools have you used for years, working well, and therefore not examined in a long time? Defaults are most dangerous where you have gone longest without thinking about them.
