Spam Protection Setup

Comment-form defenses

Honeypot field Default ON

An invisible form field added via the comment_form_after_fields hook. Real users don’t see it (CSS hides it) so they never fill it. Bots that scrape the form’s HTML fill every field they find, so any submission with the honeypot field filled is rejected with a 403 before it reaches WordPress’s comment handler.

Adds no user friction, no CAPTCHA UI, no visitor-data sharing. Catches the large majority of comment-spam bots since they’re running generic scrape-and-submit toolkits.

Time-based submission check Default ON

The form embeds a server-time timestamp at render. Submissions faster than 3 seconds after form load are almost certainly bots (no human reads and composes a comment that fast); submissions with a timestamp older than 1 hour are treated as stale tokens (the user was gone long enough that the form is likely being replayed). Both cases get rejected.

Keyword detection with Unicode-aware word boundaries Default ON

Comment content is checked against a keyword blocklist that spans Latin and non-Latin scripts. This is Unicode-aware because PHP’s default \b word boundary is ASCII-only, which historically missed spam in Japanese, Korean, Arabic, Hebrew, Thai, Chinese, and other scripts. GuardPress uses PCRE’s Unicode mode so multi-byte-character word boundaries match correctly.

Link spam detection Default ON

Comments with an unusually high link-to-text ratio (more links than plausible for a real reader response) are rejected. Configurable threshold.

Disposable-email detection Default ON

Author email addresses are matched against a list of known disposable-email providers (temp-mail, guerrillamail, mailinator, and hundreds of others). Match rejects the comment.

Login-form defenses

Login honeypot Default OFF

An invisible honeypot on the wp-login.php form, same shape as the comment-form honeypot. Off by default because it modifies the login-form DOM, and some custom login themes and page-builder login widgets don’t survive the injected field cleanly. Turn on under GuardPress → Settings → Spam Protection after testing on a staging site.

The verification hook runs at the WordPress authenticate filter at priority 100, which fires after WordPress core’s username/password handler at priority 20. So a bot supplying valid credentials but filling the honeypot is still rejected. Order matters: you get both defenses at once.

What Spam Protection does not cover

Third-party form plugins have their own submission handlers that don’t go through the WordPress comment or login hooks. Their anti-spam settings are separate:

• Contact Form 7: enable its built-in Constant Contact / Akismet / reCAPTCHA integrations, or use FormForge which ships with honeypot + time-check natively
• WPForms: anti-spam tab in each form’s settings; enable the honeypot and reCAPTCHA options
• Gravity Forms: per-form Anti-Spam Honeypot in Form Settings
• WooCommerce checkout: add reCAPTCHA / Turnstile via a checkout-CAPTCHA plugin; the checkout form doesn’t hit the comment or login hooks
• BuddyPress registration: enable BuddyPress’s own moderation queue and connect to Akismet if configured

If you want a full-site honeypot solution that catches every form, look at FormForge for the form-builder use case, plus keep the GuardPress Spam Protection module on for the comment / login pair.