Replace default CAPTCHA with server-side spam scoring.

Why CAPTCHA is the wrong layer

On-page CAPTCHAs solve "is this a real browser session" — a question that stopped being useful around the time bots started running real headless browsers. They don't solve "is this content spammy," which is the question that actually matters. A bot driving Chromium can pass reCAPTCHA v3 reliably; a real customer trying to fill out a contact form on their phone often can't.

The cost shows up in conversion data. Form-completion rates typically drop 3-15% when reCAPTCHA is on the page, and the drop is concentrated in users on flaky connections, older browsers, and accessibility tools — exactly the visitors who shouldn't be paying the tax. Meanwhile the spam keeps coming, because spam is a content-classification problem and CAPTCHA is a session problem.

The replacement pattern

The form goes from this:

<!-- before: reCAPTCHA on every form, every visitor pays the friction tax -->
<form action="/api/contact" method="POST">
  <input type="email" name="email" required>
  <textarea name="message" required></textarea>
  <div class="g-recaptcha" data-sitekey="6Lc..."></div>
  <button type="submit">Send</button>
</form>
<script src="https://www.google.com/recaptcha/api.js" async defer></‌script>

To this:

<!-- after: clean form, classification on the server -->
<form action="/api/contact" method="POST">
  <input type="email" name="email" required>
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>

And the work moves to the server-side handler that was already processing the form anyway. About 15 added lines:

// /api/contact handler — what reCAPTCHA was protecting, now done server-side.
// The drop threshold is not a constant: /v1/predict returns max_confidence,
// the highest score the model may return on its own word. Only a score above
// it carries evidence beyond the model, so only that is safe to drop.

export async function POST(req: Request) {
  const { email, message } = await req.json();

  let probability = 0;
  let ceiling = null;
  try {
    const resp = await fetch("https://api.siftfy.io/v1/predict", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "X-API-Key": process.env.SIFTFY_KEY!,
      },
      body: JSON.stringify({ text: message }),
      signal: AbortSignal.timeout(2000),
    });
    if (resp.ok) ({ spam_probability: probability, max_confidence: ceiling = null } = await resp.json());
  } catch {
    // Fall open on transport failure — losing one borderline lead beats
    // breaking the form for everyone during a Siftfy outage.
  }

  if (ceiling !== null && probability > ceiling) {
    // Always 200 to the form; the user sees "thanks" and the spammer
    // doesn't learn the threshold.
    return Response.json({ ok: true });
  }

  await sendEmail({ to: process.env.INBOX!, from: email, body: message });
  return Response.json({ ok: true });
}

The user's experience is the form they expected. The score never touches the browser, so spammers can't probe for it. And the third-party Google script that was tracking every visitor is gone — privacy improves and your CSP gets simpler.

What about hCaptcha, Cloudflare Turnstile, friendly-captcha?

They solve the privacy and accessibility problems with reCAPTCHA but they don't solve the layer problem. They're still asking "is this a real browser session" — they're just asking it more politely. A motivated bot using a real browser still passes; a real customer on a stale browser still occasionally fails. They're improvements, not a rethink.

The case for keeping a Turnstile-style invisible challenge is when you face volumetric abuse — someone is firing 1,000 submissions a second to exhaust your free tier. A stop-the-flood layer makes sense there. But for content quality — junk vs. real — the right tool is content classification.

Want both checks in one call? Content Gate

Siftfy's Content Gate (private beta) puts an invisible check on the form and judges the text in the same server-side call. Its siteverify response carries a 0–100 bot score with coarse reasons, and on an enforce site it blocks sessions at a threshold you set per form, 90 by default. There is still no puzzle and no cookie. It is bot-resistant, not bot-proof: a real browser driven carefully can still score low, so the content check stays the backstop.

Try the live demo to see the exact response a backend gets, or read Content Gate vs Cloudflare Turnstile for how it differs from a pass/fail challenge.

Edge cases worth handling

• Volumetric abuse. Pair Siftfy with a basic rate-limiter (per-IP or per-session). Classification is per-message; it doesn't help when a script is brute-forcing the endpoint. One IP, 100 requests/min, all blocked at the edge — that's a different layer.
• Honeypot + Siftfy. A hidden form field that real users won't fill in is a free extra signal that costs zero user friction. Reject anything where the honeypot is non-empty before calling Siftfy — saves a request quota.
• Multilingual forms. The model is primarily English-trained. The confidence ceiling is per-language and can be lower than English, so read it from each response rather than raising a constant.
• Don't reveal the score. Always 200 on hard block. A 4xx tells the spammer to rephrase; a 200 tells them their content shipped, and they stop tuning.