WordPress reCAPTCHA Not Working: Causes and the Fix

A customer's contact form was working fine on Monday. By Wednesday every submission fails with "reCAPTCHA verification failed" — or the checkbox just never loads. Nothing in the theme or plugin list changed. This is one of the most common "it was fine yesterday" tickets we see, and it's almost always one of five things.

Symptom: what "reCAPTCHA broken" actually looks like

It shows up in a few different shapes, and the fix depends on which one you've got:

• The checkbox or "I'm not a robot" box never renders — the form area is just blank where it should sit.
• A red banner reading "ERROR for site owner: Invalid domain for site key".
• A grey watermark that says "This reCAPTCHA is for testing purposes only. Please report to the site admin."
• The box loads and the visitor ticks it, but submission still fails with "reCAPTCHA verification failed, please try again".
• Two checkboxes stacked on top of each other, or the form submits twice.

Cause 1: the site key doesn't match the domain

Google reCAPTCHA keys are registered against specific domains in the reCAPTCHA admin console. If you migrated the site to Getwebup, switched from http:// to https://, moved from a staging subdomain to the live domain, or the site is reachable on both www and non-www without the keys covering both — the key stops validating and you get the "Invalid domain for site key" banner.

This is the single most common cause after a migration, because the site key was issued for oldhost.example.com and nobody updated it for example.com.

Fix

1. Open the reCAPTCHA admin console and select the site.
2. Under Settings → Domains, add every domain and subdomain the form is actually served on: example.com, www.example.com, and any staging domain you still use for testing.
3. Save, then hard-refresh the page (Ctrl/Cmd+Shift+R) — reCAPTCHA config is cached client-side for a few minutes.

Cause 2: two plugins are both loading reCAPTCHA

This is the one that produces the double-checkbox or the form silently failing. It's common on sites where a contact form plugin (Contact Form 7, WPForms, Gravity Forms) has its own reCAPTCHA integration and a security plugin (Wordfence, iThemes Security) or a login-protection plugin also injects reCAPTCHA on the same page. Both try to render into the same DOM slot, or both fire a token verification request, and Google's API only expects one render per page.

Fix

• Go through Plugins → Installed Plugins and check settings for anything that mentions "reCAPTCHA", "CAPTCHA", or "spam protection" — not just your form plugin.
• Pick one plugin to own reCAPTCHA and disable the integration (not the whole plugin) in the others.
• If you can't tell which plugin is injecting the extra script, open DevTools → Network, filter for recaptcha, and reload the page — you'll see every script pulling from google.com/recaptcha/api.js, each with a different render= site key in the URL.

Cause 3: v2 and v3 keys got mixed up

reCAPTCHA v2 (the checkbox) and v3 (invisible, score-based) use different key pairs and different verification endpoints. A very common mistake: someone pastes a v3 site key into a plugin field that expects v2, or vice versa. The checkbox will either not render at all, or it'll render but every verification call to Google's siteverify endpoint comes back invalid.

Check which version your plugin actually expects (its settings page usually says "v2 Checkbox" or "v3 Invisible" explicitly) and re-generate keys of the matching type in the admin console if needed.

Cause 4: caching plugins are serving a stale page

If you fixed the domain or the key and it's still broken for visitors — but works fine for you in an incognito window — a full-page cache (WP Super Cache, LiteSpeed Cache, W3 Total Cache, or Cloudflare's edge cache) is very likely still serving the old HTML with the old site key baked in.

Fix

# Purge WordPress-level cache from the plugin's admin screen, then
# if you're on Getwebup's LiteSpeed-backed hosting, also purge via WP-CLI:
wp litespeed-purge all

# If Cloudflare sits in front of the site, purge the edge cache too:
# Cloudflare dashboard → Caching → Configuration → Purge Everything

After purging, test from a private/incognito window on a different network (mobile data works well) so you're not just hitting your own browser cache.

Cause 5: a firewall or ad-blocker is stripping the script

Some visitors run browser extensions (uBlock Origin, Privacy Badger) or corporate network filters that block google.com/recaptcha outright, treating it as tracking. There's not much you can do about a visitor's own ad-blocker, but if every visitor is affected, check your own server-side firewall — ModSecurity or a WAF rule can occasionally block the outbound callback to siteverify if your hosting has strict egress rules. On Getwebup VPS plans this is rare, but worth a quick check in ModSecurity's audit log (/usr/local/apache/logs/modsec_audit.log) if you're self-managing a server.

Prevention

• Register both www and non-www versions of the domain in the reCAPTCHA console the day you set it up — not after the first support ticket.
• Keep a note of which plugin "owns" reCAPTCHA on each site so the next person doesn't add a second integration.
• After any domain change, migration, or SSL move, re-check the reCAPTCHA admin console domain list as part of your go-live checklist.
• Consider switching to Cloudflare Turnstile if you're already proxying through Cloudflare — it avoids the domain-key coupling entirely and doesn't show a visible challenge to most real visitors.

Quick diagnostic checklist

1. Open DevTools → Console on the form page. Any red errors mentioning recaptcha?
2. Open DevTools → Network, filter recaptcha. How many script requests fire, and do their site keys match?
3. Confirm the exact domain in the browser address bar is listed in the reCAPTCHA admin console.
4. Purge every layer of cache (plugin, LiteSpeed, Cloudflare) and retest in a private window.
5. Confirm the plugin's reCAPTCHA version (v2/v3) matches the key type you generated.

Nine times out of ten it's the domain list or a duplicate plugin integration — both take under five minutes to fix once you know where to look.