Site key errors after a reCAPTCHA upgrade usually come from a mismatch between the key you created, the script you load, the domain you serve, and the backend verification endpoint you call. Newer Enterprise and cloud-console flows can make that mismatch easier to create because the labels look similar while the integration details differ.
Developers often describe this as "the new reCAPTCHA is broken." Sometimes the docs are confusing. More often, the project is using a v2-style render call with a v3 or Enterprise key, a staging domain that is not allowed, an old secret in the backend, or a cached page that still contains the previous site key.
Start with key type
Confirm whether the key is for checkbox, invisible, score-based, Android, iOS, or Enterprise assessment. Then confirm the frontend script and render method match that type. A key copied from the wrong project or wrong product can produce errors that look like script failures.
Check domain and hostname rules
Production, staging, preview, www, non-www, and Pages subdomains should be accounted for deliberately. Do not loosen domain controls permanently just to get a test working. Instead, add the exact hostnames you use and remove old ones when they are no longer needed.
Align backend verification
If you migrate from classic reCAPTCHA to Enterprise, backend verification may change from a simple siteverify call to an assessment flow. That means different credentials, request shape, response fields, and action checks. If frontend and backend are from different generations, the token can look valid in the browser and fail on the server.
Clear stale deploy artifacts
Static hosts, CDNs, WordPress caches, build systems, and tag managers can keep old keys alive. After changing CAPTCHA keys, purge the cache and inspect the actual HTML delivered to the browser. Do not rely only on repository code or admin settings.
Make errors actionable
Log key identifier, route, hostname, action name, provider error category, and deploy version. Do not log secrets or full tokens. If a new key fails only on one route, inspect that route's bundle and form lifecycle. If it fails everywhere, inspect provider settings and backend credentials first.
rCAPTCHA emphasizes per-site clarity because key and domain mismatches are operational mistakes, not mysteries. The faster a site owner can see which host and key failed, the faster users stop seeing broken verification screens.
Related reading
- CAPTCHA verification failed: why verification fails and how to recover
- Invalid-input-response: debugging bad CAPTCHA tokens
- Cloudflare Turnstile vs Google reCAPTCHA
References
- https://cloud.google.com/recaptcha/docs/create-key-website
- https://cloud.google.com/recaptcha/docs/create-assessment-website
Try rCAPTCHA on your own site
Start with a minimal free testing plan, add a real site key, and see per-site verification data before moving to a paid tier.