How to Fix ‘Error for Site Owner: Invalid Key Type’ in Google reCAPTCHA

The “Error for Site Owner: Invalid Key Type” message in Google reCAPTCHA usually means your website is trying to use a reCAPTCHA key that doesn’t match the version or setup you’ve configured. Put simply, your site might be attempting to show a reCAPTCHA v2 checkbox while using a v3 key, or maybe you’re using an Enterprise key where it doesn’t belong, or the wrong key pair is sitting inside your plugin or custom form.

This is a configuration problem on your end, not something visitors can fix by clearing their browser cache. Switching browsers might temporarily mask the issue, but the real solution is making sure your site key, secret key, reCAPTCHA type, domain, and plugin settings all line up correctly.

What This reCAPTCHA Error Actually Means

Google reCAPTCHA keys aren’t interchangeable across different modes. A key created for one type of reCAPTCHA has to be used with the matching client-side and server-side setup.

Google’s official reCAPTCHA guide explains that reCAPTCHA uses a key pair: a site key that goes on your page and a secret key your backend uses to verify the user response. If your page is using the wrong type of site key, Google can’t render or validate the widget properly.

The “Invalid Key Type” error most often shows up when:

• You generated a reCAPTCHA v3 key but your form expects reCAPTCHA v2 Checkbox.
• You generated a v2 Invisible key but your plugin is set up for a visible checkbox.
• You copied an Enterprise key into a plugin that only works with classic reCAPTCHA v2 or v3.
• You changed the reCAPTCHA type in your plugin but didn’t generate a new matching key.
• Your caching layer is still serving old JavaScript with an outdated site key.

Google currently separates reCAPTCHA into multiple key and integration types, including reCAPTCHA v3, reCAPTCHA v2 Checkbox, reCAPTCHA v2 Invisible, and additional options through Google Cloud. Google’s reCAPTCHA type comparison is helpful when you need to confirm which type your site should actually be using.

Common Causes of “Invalid Key Type”

Before you start replacing keys, it helps to identify the exact mismatch. Most fixes come down to one of these causes.

How to Fix “Error for Site Owner: Invalid Key Type”

The safest approach is to verify your current key type first, then either correct the website setting or generate a fresh matching key. Don’t randomly paste new keys into your site without checking the reCAPTCHA type—that’s usually how the mismatch starts in the first place.

1. Check Which reCAPTCHA Type Your Website Expects

Start from wherever reCAPTCHA is configured on your website. On WordPress, this is typically inside a form, login security, membership, or anti-spam plugin.

Look for a setting named something like:

• reCAPTCHA Type
• Google reCAPTCHA Version
• Captcha Provider
• Spam Protection
• Bot Protection

The option will usually be one of these:

• reCAPTCHA v2 Checkbox — the visible “I’m not a robot” checkbox.
• reCAPTCHA v2 Invisible — no checkbox by default, triggered during form submission.
• reCAPTCHA v3 — score-based verification with no visible challenge.
• reCAPTCHA Enterprise — Google Cloud-based reCAPTCHA integration.

If your plugin says it supports only v2, don’t use a v3 key. If it says it supports only classic reCAPTCHA, don’t use an Enterprise key.

2. Check the Key Type in Google reCAPTCHA Admin

Next, open the Google reCAPTCHA admin area where the key was created. Check the label, key type, and allowed domains.

For classic reCAPTCHA, use the Google reCAPTCHA admin console. For Enterprise keys, use the Google Cloud reCAPTCHA area. Google’s website key creation documentation notes that when creating a website key, you choose whether it’s score-based v3 or challenge-based v2.

Compare the key type in Google with the type selected on your website:

If these don’t match, you’ve found the main cause.

3. Create a New Key with the Correct Type

If the key type is wrong, create a new key instead of trying to force the old one to work. A reCAPTCHA v3 key can’t become a v2 checkbox key just by changing your form plugin setting.

1. Open the reCAPTCHA admin console: Sign in with the Google account that manages your site keys.
2. Create a new site entry: Use a clear label such as example.com contact form v2 or example.com login v3.
3. Select the correct type: Choose v2 Checkbox, v2 Invisible, or v3 based on what your website actually supports.
4. Add your domain: Enter the domain without https://, paths, or trailing slashes. Use example.com, not https://example.com/contact.
5. Submit and copy both keys: Copy the new site key and secret key from the same newly created entry.

4. Replace Both the Site Key and Secret Key

Don’t replace only one key. The site key and secret key must come from the same reCAPTCHA entry.

In WordPress, you’ll usually find these fields under your plugin settings. Depending on the plugin, the path may look like one of these:

• Forms plugin: WordPress Dashboard → Forms → Settings → CAPTCHA or reCAPTCHA
• Security plugin: WordPress Dashboard → Security → Login Security → reCAPTCHA
• WooCommerce anti-spam plugin: WordPress Dashboard → WooCommerce → Settings → reCAPTCHA
• Membership plugin: WordPress Dashboard → Membership → Settings → Spam Protection

Paste the new site key and secret key, then save the settings. If your site uses custom code instead of a plugin, update both the frontend script and backend verification code.

5. Make Sure the Frontend Code Matches the Key Type

If you’re using custom HTML or JavaScript, the frontend implementation must match the key type. The most common developer mistake is using a v3 key with v2 widget markup.

A reCAPTCHA v2 checkbox typically uses markup like this:

<script src="https://www.google.com/recaptcha/api.js" async defer></script>

<div class="g-recaptcha" data-sitekey="YOUR_V2_SITE_KEY"></div>

A reCAPTCHA v3 integration looks different because it runs JavaScript and returns a score. Google’s reCAPTCHA v3 documentation shows that v3 uses grecaptcha.execute() with an action name, and the returned token should be sent to your backend for verification.

<script src="https://www.google.com/recaptcha/api.js?render=YOUR_V3_SITE_KEY"></script>

<script>
grecaptcha.ready(function() {
  grecaptcha.execute('YOUR_V3_SITE_KEY', {action: 'submit'}).then(function(token) {
    document.getElementById('recaptcha_token').value = token;
  });
});
</script>

If your page has <div class="g-recaptcha"> markup but your key is v3, you’re likely to see a key type error. If your page loads api.js?render=SITE_KEY but the key is v2 checkbox, that’s also a mismatch.

6. Verify the Backend Is Using the Correct Secret Key

Even after the widget loads, your backend must verify the token with the matching secret key. For classic reCAPTCHA, the verification request normally goes to Google’s siteverify endpoint.

POST https://www.google.com/recaptcha/api/siteverify
secret=YOUR_SECRET_KEY
response=USER_RESPONSE_TOKEN

For v3, your backend should also check the action and score, not only whether success is true. Google notes that v3 returns a score and action, and the action should be verified server-side to make sure the token was created for the expected interaction.

If your form plugin handles backend verification automatically, you usually don’t need to edit code. But if you recently migrated from one plugin to another, check that old constants, environment variables, or theme functions aren’t still injecting a different secret key.

7. Clear Cache at Every Layer

reCAPTCHA key changes often appear not to work because the frontend page is cached. If the old site key is still present in the HTML, Google will keep showing the same error.

Clear these layers in order:

1. WordPress cache plugin: Clear full-page cache, minified JS, and combined assets.
2. Server cache: Clear Nginx FastCGI cache, LiteSpeed cache, Varnish, or hosting-level cache if enabled.
3. CDN cache: Purge Cloudflare, Bunny CDN, QUIC.cloud, or any other CDN serving cached HTML or JavaScript.
4. Browser cache: Test in a private window or hard refresh using Ctrl + F5 / Cmd + Shift + R.

If you run your sites behind a reverse proxy, caching and security layers can complicate debugging. For related infrastructure hardening, this guide on Nginx rate limiting is helpful when you want bot protection beyond form-level CAPTCHA.

8. Check the Domain List

A domain mismatch usually gives a different error, such as “Invalid domain for site key,” but it’s still worth checking while you’re already in the reCAPTCHA console.

Use only the hostname. Don’t include protocol, paths, ports, or query strings.

For local development, don’t assume production keys will work cleanly. Google’s reCAPTCHA troubleshooting guide advises using separate development and production keys, and only allowing localhost on a development key when needed.

WordPress-Specific Fixes

On WordPress, this error is almost always caused by a mismatch between plugin settings and Google’s key type. The code is usually fine—the configuration isn’t.

Fix for Contact Form Plugins

If the error appears on a contact form, newsletter form, quote form, or registration form, open the form plugin’s CAPTCHA settings.

1. Confirm the selected reCAPTCHA version: Check whether the plugin is set to v2 Checkbox, v2 Invisible, or v3.
2. Confirm plugin support: Some older plugins support only v2. A v3 key won’t work there.
3. Replace both keys: Use a matching site key and secret key from the same Google reCAPTCHA entry.
4. Save plugin settings: Then edit and resave the affected form if the plugin stores CAPTCHA settings per form.
5. Clear cache: Purge page cache and JavaScript optimization cache.

If you’re troubleshooting performance or cache behavior at the same time, the article on cache warmup requests can help you understand why old assets sometimes remain visible after a configuration change.

Fix for Login and Registration Pages

If the error appears on /wp-login.php, WooCommerce account pages, or a membership login form, check the security plugin first. Security plugins often add reCAPTCHA to login, registration, lost password, and comment forms separately.

Look for checkboxes such as:

• Enable reCAPTCHA on login form
• Enable reCAPTCHA on registration form
• Enable reCAPTCHA on lost password form
• Enable reCAPTCHA on WooCommerce checkout
• Enable reCAPTCHA on comments

If one plugin adds v2 and another plugin adds v3 to the same page, disable one of them. Loading multiple reCAPTCHA integrations on the same form can create confusing behavior, especially when each plugin injects a different key.

Fix for WooCommerce Checkout

WooCommerce checkout pages often combine several plugins: payment gateways, anti-fraud tools, form validation plugins, and spam protection. If the error appears only during checkout, check whether reCAPTCHA is enabled in more than one plugin.

Use this order:

1. Disable duplicate CAPTCHA features: Keep reCAPTCHA enabled in only one plugin.
2. Match the key type: Use v2 keys for v2 checkout CAPTCHA, or v3 keys for score-based checkout protection.
3. Exclude checkout from aggressive JS optimization: Delay/defer settings can break reCAPTCHA execution.
4. Test with a low-value product: Confirm that checkout validation works without blocking real customers.

Custom Code Checklist for Developers

If you’re not using a plugin, inspect the actual HTML source and backend environment variables. The browser console alone may not tell the full story.

Check the Rendered Page Source

Open the affected page, view source, and search for:

recaptcha
g-recaptcha
api.js
data-sitekey
grecaptcha.execute

You’re looking for two things:

• Which site key is actually being sent to the browser.
• Whether the integration style is v2 widget markup or v3 JavaScript execution.

If the source contains an old key even after you updated settings, your cache is still serving the old page.

Check Environment Variables

For Laravel, Node.js, Django, Rails, or other custom applications, keys are often stored in environment files.

RECAPTCHA_SITE_KEY=your_site_key_here
RECAPTCHA_SECRET_KEY=your_secret_key_here
RECAPTCHA_VERSION=v3

After changing these values, restart the application process if your framework loads environment variables only at boot.

# Example for a systemd-managed app
sudo systemctl restart your-app.service

# Example for PM2
pm2 restart your-app

# Example for Docker Compose
docker compose restart

If you use a reverse proxy in front of your application, make sure the proxy isn’t serving stale cached HTML. For HTTPS and reverse proxy setups, the guide on Caddy transparent proxy gives helpful context for how frontend traffic can be separated from backend applications.

Check Server-Side Verification

For v3, verification shouldn’t stop at success. You should also inspect score, action, and hostname. A minimal verification response may include fields like:

{
  "success": true,
  "score": 0.9,
  "action": "submit",
  "challenge_ts": "2026-04-25T10:00:00Z",
  "hostname": "example.com"
}

For production use, check that:

• success is true.
• hostname matches your domain.
• action matches the action you expected.
• score meets your threshold if using v3.

How to Tell Whether You Need v2, v3, or Enterprise

The right reCAPTCHA type depends on your website and how much control you need over user verification.

For a basic WordPress contact form, v2 Checkbox is often the easiest to debug. For a polished login or checkout flow, v3 can be better, but only if your plugin or custom code handles scores properly.

Testing After the Fix

Once you replace the keys and clear cache, test the affected form carefully. Don’t test only as a logged-in administrator, because some plugins hide CAPTCHA from admins.

1. Open a private browser window: This avoids admin-session behavior and browser cache.
2. Load the affected page: Confirm the error message is gone.
3. Submit a normal test entry: Make sure the form sends successfully.
4. Check the browser console: Look for JavaScript errors related to api.js or grecaptcha.
5. Check plugin logs: Some form plugins record failed CAPTCHA validation attempts.
6. Check server logs: Look for blocked POST requests, 403 responses, or security plugin interference.

If your application uses Redis, queues, or background processing for form submissions, slow backend services can look like form failures. For deeper backend troubleshooting, the guide on diagnosing Redis issues may help separate CAPTCHA problems from infrastructure problems.

What If the Error Still Appears?

If the message still appears after creating a fresh matching key, work through this shorter diagnostic list.

• View page source: Confirm the new site key is actually visible in the rendered HTML.
• Disable optimization temporarily: Turn off JavaScript delay, defer, combine, and minify options.
• Disable duplicate CAPTCHA plugins: Use only one reCAPTCHA integration on the same form.
• Check staging versus production: Make sure you didn’t paste staging keys on the live site.
• Confirm Enterprise support: Don’t use Enterprise keys unless your plugin or code explicitly supports them.
• Regenerate the key pair: If you’re unsure where the keys came from, create a clean new pair and replace both values.

Google’s troubleshooting documentation says an invalid site key can mean the site key is no longer valid and should be replaced. While “Invalid Key Type” is more specifically a type mismatch, creating a fresh key with the correct type is still the cleanest fix when the original setup is unclear.

Preventing the Error in Future

Once fixed, document the key type and where it’s used. This prevents the same problem from returning during plugin migrations, redesigns, staging pushes, or security plugin changes.

A practical key naming pattern looks like this:

example.com - WordPress Contact Form - v2 Checkbox - Production
example.com - WordPress Login - v3 - Production
staging.example.com - Contact Form - v2 Checkbox - Staging

Also keep these habits:

• Use one key pair per website or environment.
• Don’t mix v2, v3, and Enterprise keys.
• Don’t paste keys from screenshots, old notes, or another domain.
• After changing keys, purge all caches before testing.
• Keep a private record of which plugin uses which reCAPTCHA type.

Final Thoughts

The fastest way to fix “Error for Site Owner: Invalid Key Type” in Google reCAPTCHA is to stop treating it like a browser issue and treat it as a key-type mismatch. Check what your website or plugin expects, check what type of key you created in Google, then make both sides match.

For most WordPress sites, the fix is straightforward: create a new reCAPTCHA key with the correct version, paste both the site key and secret key into the plugin, clear all caches, and test as a logged-out visitor. If you’re using custom code, also verify that the frontend markup, JavaScript execution method, and backend verification logic all match the same reCAPTCHA type.