WordPress Form Honeypot: How ReportedIP Hive Cuts Comment Spam to Near Zero
A honeypot field alone stops the bots that fill in every input; it does nothing against a script written to skip the one field it should skip. ReportedIP Hive 2.1.53 pairs its existing comment honeypot with an execution proof that catches the second kind too, and scores the two together so a scripted submission almost never reaches an inbox or a comment thread.
What a WordPress honeypot field actually does
A honeypot field is an extra input added to a form, hidden from sighted visitors with CSS, hidden from screen readers with aria-hidden, and never touched by a human who cannot see it. A scripted submission that fills in every field it finds fills that one too, and a filled honeypot is proof of automation with no legitimate exception. ReportedIP Hive has run one on its comment form since version 2.1.2: a field named reportedip_hive_hp, positioned off-screen, excluded from tab order and from autocomplete.
Why a honeypot alone stopped being enough
A honeypot only catches a script that fills in fields indiscriminately. A script written against a specific site, or one that reads a form’s markup and skips anything with aria-hidden or an off-screen class, walks straight past it. The gap is content heuristics cannot close either, wording changes faster than a filter can learn it, so ReportedIP Hive 2.1.53 added a second, independent question: did this client ever load the page and run its JavaScript at all?
That question does not care what the submission says. A client posting straight at wp-comments-post.php without ever fetching the article page cannot have run a script that lives on that page, whatever the comment body claims to be about.
How the execution proof reaches its verdict
The server plants one hidden anchor field on the form. A small script then adds a second field next to it, named differently on every install so one crafted payload cannot fit two sites. Reading both fields back on submission sorts every request into one of four verdicts:
| Verdict | What the submission carried | What it means |
|---|---|---|
tripped | The honeypot field, filled in | Classic bot behaviour: filled a field a human never sees |
proved | Honeypot empty, proof field present | A browser rendered the form and ran its script |
failed | Honeypot empty, proof field missing, this form is known to render it | Reached a real page, script never ran, no readable evidence a human is behind it |
absent | Neither field present | This submission never went through our form at all |
The distinction between failed and absent matters for a genuine edge case: a visitor who has switched off JavaScript. Hive records, at most once a day, that a comment form actually rendered the anchor; that record decides whether a missing proof field reads as “the script never ran here” or “we never planted a field on this form to begin with.” A theme with hand-written comment markup, or a site that has switched the layer off, gets the lenient absent reading rather than being treated as suspicious for something it never had.
What each signal is worth in the spam score
Comments run through a separate scorer, ReportedIP_Hive_Comment_Spam_Filter, that combines the execution-proof verdict with link and identity signals. A comment needs a score of 4 or more to be filed as spam:
| Signal | Score | Reaches the threshold of 4 alone? |
|---|---|---|
Honeypot field filled in (tripped) | +6 | Yes, with two points to spare |
Rendered the form, script never ran (failed) | +4 | Yes, exactly at the line |
| Author name is itself a URL | +4 | Yes |
| A link with no message in a short comment | +4 | Yes |
| More links than the configured maximum | +3 | No, needs a second signal |
No honeypot field on the request at all (absent, no render history) | +1 | No, needs a second signal |
A filled honeypot alone clears the threshold with margin to spare. A missing execution proof alone clears it exactly, which is deliberate: it is the one signal a genuine reader without JavaScript can produce on their own, so it stops at filing the comment for manual review rather than feeding the address into the IP block ladder.
What happens next depends on the form
The three surfaces the layer covers do not carry the same risk, so they do not get the same consequence:
- Comments that score above the threshold are filed as spam or refused outright, whichever action the site has configured under Firewall → Spam Defence. A visitor without JavaScript loses nothing but a delay to manual approval.
- Sign-up forms refuse a failed submission outright and say why, since a new account is a heavier commitment than a comment.
- Password reset refuses on a filled honeypot, but never on a missing proof alone: an administrator locked out of their own site is worse than the spam this stops, so a browser without JavaScript can still recover an account.
Every refusal fails open. An exhausted lookup quota, a timeout or an unreachable network reads as no opinion rather than a block, and switching on Report-Only mode logs every verdict without refusing a single submission, useful for reading a week of logs before deciding what to enforce.
Since when, and how to turn it off
The comment honeypot has run since Hive 2.1.2. The execution proof, the four-way verdict and the scoring above shipped together in version 2.1.53, alongside extending the community reputation check that used to run on the login page alone to comments, sign-ups and password resets. Both layers run on every plan for free.
The whole execution-proof layer lives under Firewall → Spam Defence, with a site-wide switch and a separate one for the sign-up and password-reset forms. A site whose comment markup is unusual enough to trip false failed verdicts can disable the layer entirely with REPORTEDIP_HIVE_DISABLE_FORM_PROOF in wp-config.php.
Frequently asked
Can a honeypot field block a real visitor?
Not on its own. The honeypot field is invisible and untouched by anyone using a mouse, keyboard or screen reader, so a human never fills it in. The one case that needs a separate rule is a visitor with JavaScript switched off, which is why a missing execution proof stops at filing a comment for review instead of blocking the address.
Does the honeypot field affect accessibility?
The field carries aria-hidden="true", a tabindex of -1 and autocomplete="off", so assistive technology and password managers both skip it the same way a sighted mouse user does.
Is a form honeypot GDPR compliant?
The field and the proof script collect nothing about the visitor beyond whether two hidden fields were present on submission, no fingerprinting, no third-party request. See the WordPress plugin documentation for the plugin’s full data-handling summary.
Related reading
- Form execution proof and the new quickstart, in full
- A different honeypot: banning scanners on their first probe of a bait file path
WordPress’s own comment_form hook reference documents where the honeypot field is printed. See the WordPress plugin documentation for the full settings reference. Explore ReportedIP Hive →