reCAPTCHA v3 score explained: how sites judge visitors without a challenge
reCAPTCHA v3 does not show a challenge. It runs in the background on the page, watches the visitor, and returns a score from 0.0 to 1.0, where a higher number means the visitor is more likely to be a human. The site's backend decides what to do with the score. A signup form might let a visitor through at 0.7 and block them at 0.3. Scarnox support for reCAPTCHA v3 is coming soon. This guide explains how the score works and the legitimate ways to keep automated work from being scored as a bot.
How the score is produced
The page loads the reCAPTCHA script and calls it for an action, such as login or signup. The script collects signals in the browser and sends them to Google, which returns a token. The site's server then sends the token to Google's verification endpoint, along with its secret key, and receives back a score and an action name.
The score is a risk estimate built from several kinds of signal:
- the browser environment, including whether it looks like a standard desktop browser;
- the behaviour on the page, such as mouse movement, scrolling and timing;
- the history of the visitor with that site, such as previous successful sessions;
- the request pattern, including how often and how fast requests arrive from one address.
The exact weighting is not published, and it changes. What is public is the contract: the site chooses a threshold, and the score decides the outcome.
Why automation scores low
Automated traffic tends to score low for predictable reasons. A headless browser with default settings has unusual signals. A new session has no history. A fast, regular request pattern looks unlike a person browsing. Datacenter addresses are treated with more suspicion than home connections. Each one is a signal, and several together can push the score below the threshold.
Because there is no visible challenge, a low score often means a silent failure. The page loads, the form is rejected, and nothing tells you why. Build your logging so you can see the error from the server side.
Legitimate ways to keep your score healthy
These approaches are for your own work and for legitimate data collection:
- Use a real browser profile. A normal browser with ordinary settings and extensions is less likely to be scored as a bot than a bare headless build. The browser fingerprinting guide explains how the browser environment is read.
- Keep sessions warm. Keep cookies across requests, and do not start every page from a blank state.
- Pace requests. Human visitors do not load a hundred pages in a second. Add delays and randomise them within a sensible range.
- Avoid obvious giveaways. Default user agents, missing language settings and inconsistent screen sizes are easy signals to fix.
- Test against your own threshold. If you run the site, read the score in staging and check which signals push it down. Google's test keys are useful for testing the integration without real scoring.
These steps reduce false positives on real work. They are not a way to fake a human score for abuse, and no approach here changes the fact that the site owner decides the threshold.
What the score does not do
The score does not prove that a visitor is human, and it does not tell you why a visitor scored low. A low score can come from an unusual but legitimate browser, a shared network or a VPN. Treat the score as one input. If your legitimate job keeps scoring low, the honest answer is often to ask the site owner for an allowlist or an API.
Where Scarnox stands
Scarnox does not solve reCAPTCHA v3 live today. The only live task type is PopularCaptcha, proxyless. reCAPTCHA v3 is coming soon. A score-based solver has to return a token the site accepts, which is a different problem from solving a visible puzzle, so the integration details will be documented in the API reference when support ships.
Create an account to start with free trial credit, no card needed, and you will be ready when the type is live.
Reading the score in your own logs
Because there is no visible challenge, the only way to understand a score-based failure is to log it. On your own site, record the score, the action name and the success flag that your backend receives from the verification call, together with the request's timestamp and the path it came from. Over a week of traffic, the pattern usually shows which pages or flows score low. A flow that is always low may be a real problem for legitimate users, such as a signup step that happens too quickly after page load, rather than a bot problem.
Compare scores for the same action across different browsers and networks, too. If a normal visitor on a home connection scores well and the same visitor on a corporate VPN scores poorly, the score is responding to the network, not to the browser, and the fix is a conversation about access rather than any change to automation.
Keep the logs free of personal data. A score and an action name are enough to diagnose most problems, and storing more than you need creates a privacy obligation you do not want.
Scrape responsibly
Check robots.txt and the site's terms before a scraping job. Keep your rate low, avoid collecting personal data you do not need, and remember that a score-based check is the site's chosen way of protecting itself. Working around it at scale is a sign that the job should be reconsidered or agreed with the owner. The is web scraping legal guide covers the wider picture.