Gravity Forms documents a honeypot spam reason stating that version_hash was not included in the submission. Valid users can hit this when cached markup and current JavaScript do not agree, optimization removes or delays required behavior, custom rendering omits the field, or a programmatic submission bypasses the normal browser path.
Use this when legitimate Gravity Forms entries appear in Spam with the missing version_hash note, especially on cached, AJAX, multipage, embedded, optimized, or headless forms.
Quick answer
Open one affected entry and confirm the exact spam note. Enable Gravity Forms core logging for a short test window, compare uncached and cached form HTML, inspect the browser payload, and test with optimization layers disabled one at a time. Fix the stale or incomplete rendering path instead of disabling the honeypot globally.
What to check first
- Record the form ID, page URL, entry timestamp, spam note, render method, AJAX state, cache status, optimization settings, browser, and consent state.
- Capture the initial HTML and submitted request for a clean uncached session, then repeat from CDN cache, page cache, logged-in bypass, mobile, and any embedded context.
- Review Gravity Forms core logs for version_hash validation, GFAPI bypass messages, form version changes, and the final spam decision.
- Temporarily isolate page cache, HTML minification, JavaScript delay, combine or defer, custom template code, and headless or API submission layers one variable at a time.
- Purge only the affected cache paths, rebuild assets, retest valid and deliberately invalid controls, and confirm other forms remain protected.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Confirm the exact spam reason | Record the form ID, page URL, entry timestamp, spam note, render method, AJAX state, cache status, optimization settings, browser, and consent state. | Valid cached and uncached submissions include the expected hash and remain Active. |
| Compare cached and uncached payloads | Capture the initial HTML and submitted request for a clean uncached session, then repeat from CDN cache, page cache, logged-in bypass, mobile, and any embedded context. | A deliberately invalid control still reaches Spam with the correct reason. |
| Read the core log | Review Gravity Forms core logs for version_hash validation, GFAPI bypass messages, form version changes, and the final spam decision. | The fix works across AJAX, multipage, mobile, and embedded variants used by the site. |
| Isolate one rendering layer | Temporarily isolate page cache, HTML minification, JavaScript delay, combine or defer, custom template code, and headless or API submission layers one variable at a time. | Temporary logs are disabled or cleaned according to the site's privacy policy. |
Why this usually happens
- Cached form markup can outlive the form version or required JavaScript state.
- A performance tool can delay or remove the script that inserts the expected value.
- Custom rendering or programmatic submission can omit fields the normal form renderer supplies.
- Disabling the honeypot hides the symptom while reducing a useful spam control.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
form_id: 12
entry_note: version_hash was not included
ajax: true
page_cache: hit
html_optimization: enabled
request_field_present: false
uncached_control: pass
next_variable: javascript_delay
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Confirm the exact spam reason
- Compare cached and uncached payloads
- Read the core log
- Isolate one rendering layer
- Purge, retest, and preserve protection
Decision rule
Change the cache, rendering, or submission path only after the missing field is reproduced there. Keep the honeypot enabled unless a documented temporary test requires otherwise, and restore it immediately after the controlled comparison.
What to tell the client or owner
Share form and entry IDs, exact spam note, page and cache variants, rendered and submitted field presence, core-log lines, isolated plugin or template behavior, fix, control tests, and log cleanup.
Production verification checklist
- Valid cached and uncached submissions include the expected hash and remain Active.
- A deliberately invalid control still reaches Spam with the correct reason.
- The fix works across AJAX, multipage, mobile, and embedded variants used by the site.
- Temporary logs are disabled or cleaned according to the site's privacy policy.
Mistakes to avoid
- Do not mark an entry Not Spam before preserving its note and timing evidence.
- Do not disable every cache and optimization layer at once.
- Do not expose full form payloads or personal data in shared logs.
- Do not assume a successful uncached admin test represents anonymous visitors.
Questions teams ask during testing
Is version_hash the visible honeypot field?
No. Gravity Forms describes it as a JavaScript-inserted site-specific validation value used by the honeypot system. The entry note identifies when it was missing or wrong.
Can GFAPI submissions legitimately bypass the check?
Gravity Forms logs can identify programmatic GFAPI submission behavior. Treat that path separately from a normal browser submit and verify its intended validation controls.
When HandL WP should help
HandL WP can trace Gravity Forms markup through CDN, page cache, optimization, JavaScript, and submission handling, fix the stale layer, and preserve effective spam controls.
If this is active on a production site, fix Gravity Forms honeypot false positives.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Connect this early click earner to one Gravity Forms 2.10.5 owner
Use the Gravity Forms 2.10.5 query owner support cluster to route broad version intent into distinct logging, upload, export, spam, mail, CSS, and script diagnostics without publishing competing pages.
Retest the Gravity Forms 3.1 field-level link rule
Gravity Forms 3.1 adds No Links/URLs for supported fields. Use the No Links/URLs and Advanced Honeypot test to separate visible validation, spam classification, stored entries, retries, notifications, and CRM outcomes.
Check the WAF layer for Gravity Forms 3.0 submissions
When an entry never reaches WordPress, use the Gravity Forms 3.0 browser-log WAF rejection test to correlate the browser request, firewall rule, origin log, stored entry, and notification without applying a broad security bypass.
Test the Gravity Forms 3.1.1.1 maintenance fixes
After confirming the installed build, use the Gravity Forms 3.1.1.1 empty value sanitized log test to separate display noise from rejected input. Teams that triage entries in wp-admin should also run the entry star keyboard and screen reader test before closing the update.
Helpful references