Google reCAPTCHA v3

A public job application form that accepts file uploads attracts bots. The plugin can put Google reCAPTCHA v3 in front of it, which scores each submission in the background instead of asking anyone to identify traffic lights — genuine applicants never see a challenge, and never know it ran.

That invisibility is also the catch. Because there is nothing to click, the only way to know reCAPTCHA is doing its job is to configure it fully — and one field in particular decides whether it filters anything at all. Read the threshold section below before you rely on it.

How v3 differs from v2

reCAPTCHA v2 is the checkbox and the image grid: the visitor passes or fails, and the outcome is binary. v3 never interrupts. It watches the interaction and returns a score from 0.0 to 1.0, where 1.0 is very likely a person and 0.0 is very likely a bot, and leaves you to decide where the line falls. The plugin only supports v3 — it loads Google’s v3 script, so a v2 key pair will not work here.

Getting reCAPTCHA keys

Visit the Google reCAPTCHA admin console and register your site:

  1. Click + Create to add a new site.
  2. Enter a label (e.g., your site name).
  3. Select Score based (v3) as the reCAPTCHA type.
  4. Add your domain(s).
  5. Submit the form and copy the Site Key and Secret Key.

Register every domain the form is reachable on, including a staging or www variant if you use one. Keys are tied to the domains listed here.

Plugin configuration

Navigate to Loxo Jobs → Settings and scroll to the Job Application Settings section (see Plugin Settings for the full settings reference):

  1. Tick Enable reCAPTCHA v3.
  2. Enter your reCAPTCHA Site Key (the public key, sent to visitors’ browsers).
  3. Enter your reCAPTCHA Secret Key (the private key, used server-side to verify each token).
  4. Enter a value in reCAPTCHA Score Threshold — see below. Do not leave it blank.
  5. Save, then submit a test application yourself to confirm the form still goes through.

Enabling reCAPTCHA loads Google’s script on every page of your site, not only job pages, and Google’s reCAPTCHA badge appears in the bottom-right corner throughout. The plugin does nothing to hide it, which is what Google’s terms ask for — if you suppress the badge with your own CSS, you must add Google’s attribution text to the form instead.

The score threshold

This is the field that decides whether reCAPTCHA filters anything, and it is blank on a new install. A blank threshold is read as 0.0, and no score can fall below 0.0 — so with the field empty, every submission Google verifies is accepted no matter how bot-like it scored. The form is protected in name only.

The field description mentions a default of 0.5. That default never reaches the saved setting, so treat the field as required: type a number between 0.0 and 1.0 and save it. 0.5 is the value to start with.

Note that even with a blank threshold, submissions still fail if the token is missing altogether, or if Google refuses to verify it — an expired or already-used token, or the wrong keys. That is why a misconfigured install can look like it is working — rejections happen, they are just not the score-based ones you wanted.

Choosing a value

Scores cluster at the ends. Ordinary visitors on ordinary connections score near 1.0; crude automation scores near 0.0. The middle is thin, and it is mostly real people in unusual circumstances — a corporate VPN, a privacy-hardened browser, mobile carrier NAT, a first-ever visit that goes straight to the form.

  • 0.3 — permissive. Blocks only obvious automation. Use it if legitimate applicants are being turned away.
  • 0.5 — the sensible starting point for most sites.
  • 0.7 — strict. Expect to lose some real applicants on VPNs and shared networks.

Weigh the two failure modes honestly. A spam application costs a recruiter thirty seconds; a blocked applicant is gone, silently, and you will never hear about it. For a job board, err low.

Google’s own admin console charts the score distribution for your site once traffic accumulates. Set 0.5, leave it a fortnight, then look at where your real submissions actually sit before tightening.

What happens on submission

  • When the applicant clicks Apply, the plugin holds the submission, asks Google for a token, attaches it to the form and then submits.
  • The site verifies that token with Google, sending the secret key and the applicant’s IP address.
  • Google replies with a pass/fail and a score. A fail rejects the application outright; a pass is then checked against your threshold.
  • A rejected applicant is sent back to the job page and sees “reCAPTCHA validation failed. Please try again.” — nothing tells them why, and nothing tells you it happened.
  • A passing submission carries on to Loxo as normal.

Verification results are handed to the swpl_log logging hook, so unless you run a logging plugin that listens on it, rejections leave no record anywhere in WordPress.

Troubleshooting

Every application is rejected, including your own test

Check the secret key field first. With reCAPTCHA enabled and the secret key empty, verification fails before Google is ever contacted, and every single application is refused. The same happens if the site key is empty: the plugin then never loads Google’s script, no token is generated, and the server rejects the tokenless submission. Both keys must be filled in, or the feature must be switched off — an enabled but half-configured reCAPTCHA closes the form completely.

“reCAPTCHA verification is required but not available”

This browser alert means Google’s script did not load. Ad blockers, privacy extensions, a strict content security policy, a cookie-consent tool that defers third-party scripts, or a region that cannot reach google.com will all do it. Test in a clean browser profile; if it works there, the block is on the visitor’s side, and a cookie banner holding the script back is the most common cause you can actually fix.

Keys rejected, or v2 keys used by mistake

Keys are specific to their reCAPTCHA type and to the domains registered with them. A v2 pair pasted into these fields fails at the first hurdle, as does a v3 pair registered for a different domain. In the Google console, open the site and confirm it reads score-based v3 and that its domain list contains the exact host your form runs on. Swapping the site and secret keys around produces the same symptom, so check that too.

Legitimate applicants are being blocked

Lower the threshold to 0.3 and see whether the complaints stop. If they do not, the problem is not the score — work through the two sections above. Because a blocked applicant usually just leaves, treat any single report as representing several silent ones.

FAQ

Does reCAPTCHA protect anything besides the application form?

No. Only the job application form is checked. The script loads site-wide, but the plugin verifies tokens on application submissions alone — comments, contact forms and logins are untouched.

Can I see how many applications were blocked?

Not in the plugin — there is no counter and no admin log screen. The Google reCAPTCHA console shows request volume and score distribution for your site, which is the closest you will get.

Is reCAPTCHA a problem for GDPR?

It sends the applicant’s IP address to Google as part of verification, so mention it in your privacy policy alongside the consent wording on the form. If your cookie tool blocks third-party scripts until consent is given, make sure reCAPTCHA is allowed once the applicant accepts, or the form will refuse their submission.

Related documentation