Invisible Anti-Spam & CAPTCHA — reCAPTCHA Alternative for All Forms

Yes. For the kind of spam that plagues almost every site — automated, mass-sent — the typical experience after activation is that it simply stops: every message now costs the sender real computing power, which breaks the economics of sending thousands of them. That result has held up across years of production use. And the protection is actively maintained: when a new generation of protocol-aware bots learned to reuse a solved challenge across many submissions, version 5.0 closed that route with single-use, signed tokens. For the rare rest — targeted spam written by humans — the flag-and-inbox workflow keeps you in control instead of promising magic.

No. There is nothing to see, click or solve. The proof-of-work starts in the background as soon as the page has loaded and is typically finished within a second or two — long before they hit Send .

No. Unlike reCAPTCHA, hCaptcha or Turnstile the spam protection involves no external service at all — no keys, no registration, no third-party scripts, no rate limits.

No. The plugin ships a few kilobytes of JavaScript, loads no external resources and causes no layout shift. The computation happens on the visitor’s device in the background; the server-side check is a single fast lookup.

Yes. The challenge token is fetched via Ajax at runtime, so fully cached pages stay protected. One thing to know: right after installing or updating, clear your page cache once so the plugin’s JavaScript is included everywhere.

All public forms — including hand-coded and custom ones. The plugin recognizes submissions by their signature (the request’s characteristic fields and actions) instead of integrating with specific form plugins, so it is not limited to a fixed list. WordPress core, WooCommerce and the several dozen builders listed above come pre-configured; any other form is added without code in under a minute via direct analysis mode: submit it once, click save.

Everything the spam protection touches stays on your server: no cookies, no sessions, no tracking, no external requests. IP addresses are only stored as SHA-256 hashes, and password fields are never stored with saved messages. That means no consent banner is needed for the spam protection — friendly to GDPR (DSGVO, RGPD) and similar privacy laws. The one thing that can leave your server is a message you type yourself when deactivating the plugin — see the next question.

The spam protection: never. There is exactly one exception, and it only happens if you make it happen. When you deactivate the plugin, a box asks what went wrong. If you type something and press Send and deactivate , that text is sent to the plugin author’s server at programmiere.de and kept for 90 days. The plugin’s name and version number travel with it. Nothing else is stored with it — no IP address, no address of your site, no referring page, no browser details, and nothing from your forms. Press Deactivate without sending , or leave the box empty, and nothing at all is transmitted. Full details: https://programmiere.de/GDPRCompliantRecaptcha/

Yes: checkout, login, registration, password reset, comments and product reviews are covered out of the box.

Every submission has to pay for itself with a small proof-of-work computation. This makes mass spam economically expensive and silently filters out low-effort bots — the vast majority of spam. Like any anti-spam solution (including CAPTCHAs), it cannot fully prevent targeted, low-volume spam sent by a determined human or a bot that invests real computing power per message; for those rare cases, use the flag-instead-of-block option and the spam inbox to keep an eye on what comes through.

Right after installation this is usually a caching issue: the proof-of-work JavaScript is not yet included in cached pages. Clear the cache on your webserver (or caching plugin) and in your browser. JavaScript might crash due to an incompatibility with another plugin. Press F12 on the affected page and check the browser console for errors — and please report the issue in the support forum; such reports are usually addressed within a day.

Since 6.0, gibberish detection is off unless you switch it on for individual fields, so this should no longer happen on its own. If you did switch it on for a field: open the message, look at the reason line — it names the field that triggered it — and use that field’s button to stop checking it. Fields carrying tokens, licence keys or reference numbers are random by design and are not suitable for this check; message and subject fields are.

Activate the Analysis mode Submit the affected form and look for the captured entry in the Analytic Box Open the entry and add it to the protection scope If the submission does not appear there either, please post in the support forum

The protection works by having the visitor’s browser silently solve a small puzzle before a form is submitted. If that puzzle is never solved, a genuine submission looks exactly like a bot, so it gets flagged. Right after an update there are three common reasons for this, all quick to rule out:

1. 01Stale server code / OPcache. The update changed the database schema, but your server may still be running the previous version’s PHP code from its OPcache — the two no longer match. Flush the OPcache (restart PHP-FPM, or use your host’s “Flush OPcache” button), then clear any page/object cache. 5.1 also tries to do this automatically on update, but some hosts still need it done once by hand.
2. 02A cached page serving the old script. If a full-page cache is serving pre-update HTML, browsers load the previous version’s script against the new server. Purge your page cache (and CDN) once after updating.
3. 03A reverse proxy / CDN without Trusted Proxies set. If your site sits behind Cloudflare, a load balancer or similar and the plugin sees the proxy’s IP instead of the visitor’s, the check cannot line up. Set your proxy’s address under Settings → Trusted proxies.

To confirm which one it is: open the affected page, press F12 → Console, and look for a warning from “gdpr-recaptcha”; on the Network tab, check that the get_stamp request returns clean JSON (no PHP notice/HTML before it). Sharing that in the support forum pins it down immediately.

When you use the Borlabs Script Blocker to scan for JavaScript, the scan does not work properly while this plugin is active. Deactivate this plugin for the scan and reactivate it afterwards.

Check the browser console (F12) on the problematic page for messages Post in the support forum with as many details as possible — issues are usually fixed quickly If the protection does not work on a specific form, a short note with the form plugin’s name is enough to get it looked at