Giraforms protects WordPress forms from spam with four built-in layers: a honeypot field (invisible trap for bots), a submission speed check (blocks instant bot submissions), IP-based rate limiting (caps submissions per IP per hour), and optional CAPTCHA support including Cloudflare Turnstile, reCAPTCHA v2/v3, and hCaptcha. The first three layers are active by default — no configuration needed.
Form spam is one of the most common problems for WordPress site owners. A single unprotected contact form can receive hundreds of bot submissions per day — filling your inbox with garbage, skewing your analytics, and occasionally triggering spam filters on legitimate emails. The instinctive solution — slapping a reCAPTCHA checkbox on everything — creates a different problem: friction for real users.
Akismet reports blocking over 7.5 million spam form submissions every hour across WordPress sites worldwide — making spam protection one of the most critical form features for any publicly accessible site (Akismet, 2024).
Why reCAPTCHA alone isn't enough
Google's reCAPTCHA v2 — the "I'm not a robot" checkbox — was effective in 2016. In 2025, sophisticated bots routinely bypass it using CAPTCHA-solving services and AI-powered image recognition tools. Meanwhile, the friction it creates is very real for your legitimate visitors: the checkbox, the image grid challenges, the loading delays. Research from Baymard Institute (2023) found that traditional CAPTCHAs cause up to 33% of users to abandon a form before completing it.
There's also the GDPR angle: reCAPTCHA sends data to Google's servers, which requires disclosure in your privacy policy and potentially a cookie consent mechanism. For European users, this adds compliance overhead. The better approach is to layer multiple invisible defenses — and only resort to a CAPTCHA when the invisible layers aren't enough.
Layer 1 — Honeypot fields
A honeypot is a hidden form field — invisible to human users via CSS, but present in the raw HTML. When an automated bot parses the page and fills in all form fields (which is how most simple bots work), it fills the honeypot field too. Giraforms checks whether the honeypot was filled on submission: if yes, the submission is silently discarded as spam. If the honeypot is empty (as it would be for any real user who can't see it), the submission proceeds normally.
This technique has zero impact on user experience. Real users never interact with the honeypot field at all. Giraforms adds a honeypot automatically to every form without any configuration on your part. This single layer eliminates a large percentage of unsophisticated automated submissions.
Layer 2 — Submission speed check
Humans read a form, think about their answers, tab between fields, and type responses. Even a fast typist takes 15–30 seconds to complete a basic contact form. Bots, on the other hand, parse and submit a form in milliseconds — often under one second.
Giraforms tracks the time between when the page loads and when the form is submitted. If a submission arrives faster than a configurable threshold (defaulting to 3 seconds — far too fast for any human), it's flagged as automated and rejected. This adds another invisible filter with zero user experience impact. The only edge case is pre-filled forms auto-submitted by browser tools — but those are rare and typically legitimate, so the threshold can be adjusted down in settings if needed.
Layer 3 — IP-based rate limiting
Even a sophisticated bot that bypasses the honeypot and speed check will reveal itself through volume. Giraforms tracks the number of submissions from each IP address within a configurable time window. If a single IP submits too many times in an hour — far more than any real user would — additional attempts from that IP are temporarily blocked.
This stops flood attacks where a bot attempts to overwhelm your inbox or database with hundreds of submissions in rapid succession. The rate limit is set conservatively by default, so real users who legitimately submit a form once (or even a few times if they made an error) are never affected. You can adjust the threshold in Giraforms → Settings → Spam Protection to match your site's actual traffic patterns.
Layer 4 — CAPTCHA (for extreme cases)
When the three invisible layers aren't sufficient — high-traffic sites, persistent targeted campaigns, or sophisticated bots that simulate human behavior — adding a CAPTCHA provides a final verification step. Giraforms supports three CAPTCHA providers:
| Provider | User experience | Cost | Privacy |
|---|---|---|---|
| Cloudflare Turnstile | Mostly invisible — auto-passes real users | Free tier (1M/month) | No Google dependency |
| reCAPTCHA v3 | Fully invisible — score-based | Free | Sends data to Google |
| reCAPTCHA v2 | Checkbox + possible image challenge | Free | Sends data to Google |
| hCaptcha | Image challenges, but GDPR-friendlier | Free tier available | Privacy-focused alternative |
Our recommendation: use Cloudflare Turnstile. It's the most user-friendly option — the vast majority of real users pass it automatically without seeing any challenge. It's free, doesn't require Google, and has better GDPR characteristics than reCAPTCHA. Sign up for a free Cloudflare account, get your Site Key and Secret Key from the Turnstile dashboard, and enter them in Giraforms → Settings → Spam Protection.
How to configure spam protection in Giraforms
Navigate to WP Admin → Giraforms → Settings → Spam Protection. The honeypot and speed check are always active and require no input. For rate limiting, you can adjust the threshold (default: 10 submissions per IP per hour). For CAPTCHA, select your provider and enter the Site Key and Secret Key from your provider's dashboard. Save settings. The CAPTCHA will appear on all Giraforms forms site-wide from that point on.
No configuration needed for baseline protection. Install Giraforms, create a form, and honeypot + speed check + rate limiting are already working. Only add a CAPTCHA if you encounter persistent spam that passes the invisible layers.
What if legitimate users are getting blocked?
If you receive reports that real users can't submit your form, check the Giraforms → Submissions panel — blocked submissions are logged separately with a reason code (honeypot triggered, too fast, rate limit exceeded, CAPTCHA failed). This helps diagnose the issue. If the rate limit is blocking users on slow connections who are trying again after a failed submission, raise the threshold in settings. If the speed check is catching users who auto-fill forms with password managers, lower the minimum submission time requirement. The settings are designed to be tuned, not just toggled.