reCAPTCHA has a browser side that obtains a token and a server side that verifies it. A form can fail because the script never loads, the key does not match the hostname, the token expires or a score threshold rejects legitimate traffic.
Determine which side failed before replacing CAPTCHA or disabling it.
Reproduce the visitor’s context
Record the page, hostname, time, device, browser and network type. Use synthetic form data and inspect console and network activity.
Check whether the reCAPTCHA script loads, whether a token-related request occurs and what the final form endpoint returns. Do not copy or share live tokens; they are temporary security data.
Test while logged out and through the site’s normal consent flow.
Verify key type and hostname
Confirm that the site key and secret belong to the same reCAPTCHA version and project. A v2 checkbox key cannot replace a v3 key, and invisible variants have their own integration requirements.
Review allowed domains for the canonical host, www/non-www choice and any production subdomain. Domain migrations often leave only the old hostname registered.
Keep staging on separate credentials where practical and never expose the secret in page source.
Check consent and script blocking
A cookie manager may block Google scripts until consent. Decide with the site’s privacy owner whether CAPTCHA is essential security or a consent-dependent service, then implement that classification consistently.
If the script is blocked, the form should not remain silently unusable. Provide an accessible explanation and approved fallback.
Inspect Content Security Policy and browser privacy errors rather than asking visitors to disable protection.
Inspect optimisation and loading order
Script delay, defer or combination can run the form before the reCAPTCHA API is ready. Look for undefined callbacks, duplicate API loads and race conditions.
Exclude only the proven CAPTCHA/form handles from a conflicting optimisation, and regenerate affected assets. Do not disable every performance setting without evidence.
Check duplicate form widgets or popups that initialise the API more than once.
Diagnose token expiry
Tokens are short-lived and normally intended for one use. A visitor who completes a long multi-step form may reach the final submit with an expired token.
Reproduce a quick path and a delayed path. Refresh the token through the plugin’s supported workflow immediately before final submission rather than extending acceptance indefinitely.
Prevent double submission from reusing the same token.
Review v3 scores and actions
For score-based reCAPTCHA, inspect server verification result, action name and score for controlled tests. Confirm the expected action matches what the browser requested.
Tune thresholds against real legitimate traffic and complement them with honeypots or rate limits. Do not publish the threshold or detailed abuse rules unnecessarily.
Provide manual review or a fallback for borderline business enquiries where appropriate.
Test keyboard navigation, zoom and screen-reader announcements so the challenge does not become an invisible submission requirement.
Verify server-to-Google communication
The WordPress server must reach the verification endpoint and validate the response. Check DNS, outbound HTTPS, CA trust, server time and PHP errors.
Never skip certificate verification or accept a response without checking success, hostname/action and relevant provider fields.
Store only minimal verification outcomes, not tokens or full form bodies.
Prove legitimate and abusive paths
After the repair, submit on supported desktop and real-mobile browsers, including the normal consent state. Confirm one entry, intended notification and final mailbox delivery.
Test expiry handling and an approved invalid-token case so the user receives a useful error and protection remains active.
Request urgent repair when key ownership is unknown, legitimate scores vary sharply or privacy controls conflict. Share redacted errors and hostname—not secrets, tokens or visitor data.