Skip to content
GravityAgent

Competitor and platform details verified on 2026-09-09 against the sources listed at the end. If you find something out of date, tell us at [email protected] and we will fix it.

A Gravity Forms site with the anti-spam honeypot switched on and a CAPTCHA on every form still collects junk. Less of it than before, but enough that somebody opens the Entries screen most mornings and deletes a handful of enquiries that were never enquiries.

That is not a misconfiguration, and a fourth check of the same kind will not fix it. Each of the usual defences tests something specific and does it well, and what gets through is precisely the traffic that passes those tests. This page is about what each one tests and what that leaves open.

The three defences most Gravity Forms sites run

Gravity Forms' spam-prevention guide describes the built-in anti-spam honeypot as several techniques at once: the traditional hidden honeypot field, a JavaScript-inserted site-specific version hash, state validation checks, and an optional Submission Speed Check, which the guide says flags submissions completed faster than a human could. The same guide describes the Akismet integration as sending form submissions to the Akismet service for analysis. Google's reCAPTCHA v3 documentation describes what that product returns: a score for each request without user friction, where 1.0 is very likely a good interaction and 0.0 is very likely a bot, on which you can take variable action in the context of your site.

Three different questions, all three worth asking. What follows is about the traffic that answers all three correctly.

What a honeypot actually tests

A honeypot asks whether the thing filling in the form behaves like a browser driven by a person: a field a person cannot see stays empty, a value only the page's own JavaScript writes is present, a form is not completed faster than anyone can type.

Every one of those is a question about the client, not about the message. It costs the visitor nothing and it removes the crude volume bots, so leave it on. But a person at a keyboard in an ordinary browser answers all three correctly, because the honest answer to all three is "a person, in a browser, at human speed". So does an automated tool driving a real browser. Nothing in a honeypot reads the message.

What a CAPTCHA actually tests

A modern CAPTCHA is a reputation score for the session: a score for each request, and an action on that score which is yours to choose.

Two things follow, and neither is a criticism of the product. The score is about the interaction, not the content, so a message that reads like an advert scores exactly as well as one that reads like an enquiry when both were typed by a person in an ordinary session. And because a wrong block costs a real enquiry, most site owners set a cautious threshold and let anything borderline through. That gap is deliberate, and the traffic living in it is the traffic you are deleting by hand.

What a content filter actually tests

A content filter does read the message. Akismet's own site describes it as powered by machine learning and says it learns more about spam, and gets more accurate, with each site it protects, across the hundred million sites it names. Gravity Forms' guide gives the practical version: it helps catch spam using random or gibberish values, or the wrong language.

That is a reputation system for content, and reputation is a strong signal whenever the content has a history: it is what makes such a filter so effective against the payload sent to a hundred thousand sites in an afternoon. A message composed once, for your site, that no other site has received, has no history to look up. And a cross-site network cannot know what your own inbox knows: that a surveyor never receives a genuine enquiry about search-engine packages, or that every real booking on your form names a date.

The submissions that pass all three

In the entries people actually complain about, the same shapes come up:

  • The outreach pitch written as an enquiry: a real name, a real company, one accurate sentence about your website, and an offer to redesign it or rank it.
  • The partnership note: a guest post, a "collaboration", a request to add a link to a page you already have.
  • The human-completed form fill. Somebody is paid a few pence to open your form in a real browser and type, because that is cheaper than defeating a check.
  • The plausible enquiry where a URL is the entire point of sending it.

None of this is technically remarkable, and that is the point. Every one is well-formed, arrives from a real browser at human speed, and carries text nobody else has received.

Why an LLM-written enquiry is harder still

Writing a thousand distinct, fluent, grammatical messages used to be the expensive part of this work, and it is not any more. A sender can generate a different message for every site, each naming the business correctly because it was written from the site's own pages. Every signal that depends on repetition, on templated text or on clumsy language is weaker than it was two years ago. What is left is not a property of the text in isolation; it is the relationship between the message and the site it was sent to.

What a judgment-based filter adds

Instead of asking whether the client behaved like a browser, or whether these words have been seen before, ask the three questions a person asks when they read the entry:

  • Does this read like someone who wants what this site sells?
  • Is it consistent with the form it arrived on, and with what that form is for?
  • Has the owner already decided that messages like this one are, or are not, spam?

None of those has a yes-or-no answer. They are judgments, and a judgment can be wrong. So the question that matters is not how clever the filter is. It is what it does when it is unsure, and what happens on the day the service behind it is unreachable. A filter that reads content is only worth running if being unsure costs you nothing.

If you want one number to judge any of this by, count what is left in your Entries table over a week. That is what a judgment-based filter has to move, and it is the only figure worth measuring after you add one.

Where GravityAgent fits

We make one of these, so read this section as a description rather than the conclusion of the argument above.

GravityAgent scores each submission against a profile it builds automatically from your site's public pages, and against the corrections you have already made on that form. It sits behind the defences above rather than replacing them: an entry another plugin has already marked as spam is left alone, and no call is made at all. Keep your honeypot. Keep your CAPTCHA.

Only a clean verdict at or above the action threshold of 0.85 marks an entry as spam. Anything else — no verdict, a timeout, a monthly limit reached — admits the entry and marks it Not scored, with a reason you can read on the entry. It fails open, so a problem never costs a lead. When you mark an entry Spam or Not Spam with Gravity Forms' own buttons, that correction becomes an example for that site's later submissions; nothing is fine-tuned and there is no cross-customer model.

On our benchmark, locked on 2026-09-05: 0 false positives on 95 genuine submissions and 87.2% recall on spam, over 220 reviewed items across six synthetic sites, with an expected calibration error of 0.053. The set is synthetic and we say so; read it as evidence that the threshold is set conservatively, not as a forecast for your form.

It is free for 250 scored submissions a month on one site, with no card, and it needs Gravity Forms 2.6 or later, WordPress 6.0 or later and PHP 7.4 or later. The download page has the current build; the documentation sets out what the plugin sends and what is stored.

Sources

Competitor and platform facts were verified on 2026-09-09 from the vendors' own pages:

Every GravityAgent figure here comes from our fact sheet, which carries the date each was last verified. GravityAgent is not affiliated with Gravity Forms, Rocketgenius, Google or Akismet. Product names belong to their owners.