You can’t set a reCAPTCHA v3 score. Google assigns it per request, and nothing in your code changes it directly. What you can change is what feeds it: how you name actions, when you request the token, how much of your site runs reCAPTCHA at all, and what your backend does with the result. Fix those and the distribution moves.<\/p>\n
Six changes, ordered by how much they typically help. Measure first, because half the sites that think they have a scoring problem have a threshold problem.<\/p>\n
v3 returns a number between 0.0 and 1.0 with every verification. Google’s wording: 1.0 is very likely a good interaction, 0.0 is very likely a bot. There’s no checkbox and no puzzle, so the number is the entire signal.<\/p>\n
Two things follow from that, and both matter:<\/p>\n
If you’re new to how v3 differs from the checkbox version, our explainer on how reCAPTCHA works<\/a> covers the mechanics.<\/p>\n The reCAPTCHA admin console shows a score distribution for your site and a breakdown for your top ten actions. Look at it before touching code. You’re looking for one of three shapes:<\/p>\n Google also warns that scores in staging or right after you install v3 differ from production, because the model has no history for the site yet. Give it a week of real traffic before drawing conclusions. To sanity-check a single request in isolation, our live reCAPTCHA v3 test page<\/a> returns the raw score for one solve.<\/p>\n This is the biggest single win, and it’s routinely skipped. Google scores each action separately and uses the action’s own history as context. One generic action across the whole site means one blended history, and every page inherits the worst of it.<\/p>\n Rules Google enforces: actions may contain only alphanumeric characters, slashes and underscores, and they must not be user-specific. So v3 scores behaviour, and behaviour needs more than one data point. If the script only loads on your login page, Google sees a visitor who materialises at a form and submits, which is exactly what a bot looks like.<\/p>\n Google’s own recommendation is to load v3 across the site, including pages with no form on them. You don’t have to verify on those pages. Just executing the script gives the model something to work with by the time the visitor reaches the action you care about.<\/p>\n This is also the fix people accidentally undo. Moving the script into a conditional that only fires on the checkout route will drop your scores within days.<\/p>\n reCAPTCHA v3 tokens expire two minutes after they’re issued. Generate one in Long forms, multi-step checkouts and anything with a file upload are where this bites hardest.<\/p>\n The token is worthless until your backend exchanges it. That exchange returns the score, the action, and a hostname, and you should be checking all three.<\/p>\n If you only check A checkout and a newsletter signup shouldn’t share a cutoff. Once you have a week of data per action, set each one where your traffic actually sits.<\/p>\nMeasure before you change anything<\/h2>\n
\n
Fix 1: name your actions, and name them correctly<\/h2>\n
\/\/ One action per meaningful event. Not one for the whole site.\ngrecaptcha.ready(function () {\n grecaptcha.execute("YOUR_SITEKEY", { action: "login" })\n .then(function (token) {\n document.getElementById("recaptcha-token").value = token;\n });\n});<\/pre>\ncheckout\/payment<\/code> is fine, checkout_user_8842<\/code> is not. A user-specific action fragments the history into thousands of buckets with no data in any of them, which is worse than not naming actions at all.<\/p>\nFix 2: run reCAPTCHA on more than the form<\/h2>\n
Fix 3: get the token when you submit, not on page load<\/h2>\n
ready()<\/code> at page load, and any visitor who reads your form for longer than that submits a dead token. Depending on how your backend handles the failure, that reads as a bad score or a hard rejection.<\/p>\n\/\/ Solve on submit so the token is always fresh.\nform.addEventListener("submit", function (e) {\n e.preventDefault();\n grecaptcha.execute("YOUR_SITEKEY", { action: "login" })\n .then(function (token) {\n tokenField.value = token;\n form.submit();\n });\n});<\/pre>\nFix 4: verify server side, and check the action too<\/h2>\n
# Exchange the token for the score. Server side only.\ncurl -X POST https:\/\/www.google.com\/recaptcha\/api\/siteverify \\\n -d secret=YOUR_SECRET_KEY \\\n -d response=THE_TOKEN_FROM_THE_PAGE\n\n# {"success":true,"score":0.9,"action":"login","hostname":"example.com"}<\/pre>\nsuccess<\/code>, you’re not using v3 at all. success<\/code> means the token parsed, not that the visitor looked human. And if you don’t compare action<\/code> against what that endpoint expected, a token minted on your low-value newsletter form works fine on your login endpoint.<\/p>\nFix 5: set a threshold per action, not one for the site<\/h2>\n