CAPTCHA problems in WordPress can be deceptive when the CAPTCHA markup is present but the frontend JavaScript does not initialize reliably. In one support case, users intermittently saw a “prove you are human” requirement on Gravity Forms, but the expected CAPTCHA challenge was not visible.
The investigation showed that the affected forms were using Simple CAPTCHA with Cloudflare Turnstile, not a native Gravity Forms CAPTCHA field. The Turnstile scripts were present in the logged-out page source, but WP Rocket was deferring those assets. Because the issue was intermittent and difficult to reproduce consistently, the developer excluded the Turnstile plugin’s JavaScript from WP Rocket’s deferred-loading behavior. The client was then asked to monitor future submissions.
Issue background
A WordPress site received reports that some form users were being asked to “prove you are human,” but no visible CAPTCHA appeared.
The affected form was built with Gravity Forms. The site also had:
- Simple CAPTCHA with Cloudflare Turnstile
- WP Rocket
- Gravity Forms reCAPTCHA settings configured separately
The Gravity Form itself did not contain a native CAPTCHA field, which initially raised the question of whether that was the problem.
The team also noted that logged-in testing could give a false positive, so the investigation specifically emphasized testing while logged out or in an incognito window.
Diagnosis
The developer first reviewed a related earlier incident and found that the site had previously experienced a Cloudflare Turnstile problem rather than a native Gravity Forms reCAPTCHA failure.
Logged-out inspection of several public forms showed that the Turnstile integration was present and loading its expected assets.
The forms included render hooks such as:
cf-turnstile-gf-8
cf-turnstile-gf-9
cf-turnstile-gf-1The pages were also loading the Turnstile JavaScript with WP Rocket defer behavior applied:
data-rocket-defer deferThat meant the CAPTCHA was not missing from the page markup. The stronger explanation was an intermittent frontend timing or render-order issue caused by WP Rocket deferring the Turnstile JavaScript.
This matched both the prior incident and the current symptoms: the problem did not happen every time, so a normal test could appear successful even while real users occasionally encountered a broken CAPTCHA state.
Resolution steps
The documented troubleshooting and fix were:
- Test while logged out. CAPTCHA and caching behavior can differ between administrators and normal visitors, so public-form QA should be performed in an incognito or logged-out session.
- Inspect the actual frontend markup. The developer confirmed that Cloudflare Turnstile scripts and Gravity Forms render hooks were present on multiple forms.
- Do not assume a missing Gravity Forms CAPTCHA field is the cause. In this setup, CAPTCHA protection came from the separate Simple CAPTCHA with Cloudflare Turnstile plugin.
- Check whether WP Rocket is deferring CAPTCHA assets. The Turnstile JavaScript was being loaded with WP Rocket’s defer behavior.
- Treat the issue as an intermittent JavaScript timing conflict. Because the problem could not be reproduced reliably, the team focused on the strongest confirmed risk factor instead of waiting for a perfect reproduction.
- Exclude the Turnstile plugin JavaScript from deferred loading. The developer excluded all JavaScript under:
/wp-content/plugins/simple-cloudflare-turnstile/from WP Rocket’s deferred JavaScript behavior.
- Leave the rest of WP Rocket optimization intact. The change targeted only the Turnstile assets rather than disabling deferred JavaScript globally.
- Monitor future submissions. Because the failure was intermittent, the client was asked to watch for additional reports after the exclusion was added.
The task does not document a second wave of failures after the change, but it also does not include a long-term measurement proving the issue could never recur. The completed action was the targeted WP Rocket exclusion and subsequent monitoring.
Final outcome
The investigation confirmed that Cloudflare Turnstile was present on the affected Gravity Forms and that the main risk was WP Rocket deferring the Turnstile JavaScript.
The developer excluded the Simple CAPTCHA with Cloudflare Turnstile plugin’s JavaScript from WP Rocket’s deferred-loading behavior. That was considered sufficient to address the intermittent rendering problem, and the client was asked to monitor future form submissions.
The broader lesson is that a CAPTCHA can fail even when its HTML and script tags are present. When the issue only affects some users, test as a logged-out visitor and inspect optimization features that defer or reorder JavaScript. A targeted exclusion is usually safer than disabling performance optimization across the entire site.
If Cloudflare Turnstile or Gravity Forms CAPTCHA protection works inconsistently on your WordPress site, contact Freshy. Our WordPress team can trace the form, CAPTCHA, and caching layers and isolate the specific script behavior causing the failure.
