reCAPTCHA Invalid Domain for Site Key: How Do You Fix It?

A reCAPTCHA invalid domain for site key error means your contact form shows a warning instead of the checkbox, or the form simply refuses to submit. In this guide, Talha Aslan and team walk you through how to narrow the problem down, which setting to check first, and how to keep it from coming back.

The exact wording can vary by version and language. You may see "invalid domain for site key" or a similar warning. In addition, the official reCAPTCHA FAQ describes a related message for local development: localhost is not in the list of supported domains by default.

In short, the cause is usually a setting, not your code. The error appears when the key, the address, and the key type do not match. Next, we check each of those three pieces one at a time.

How can you narrow down the error in five minutes?

Before you change anything, find where the mismatch sits. The order below moves from the most common cause to the rarest. As a result, most sites find the fix within the first three steps.

1. Copy the exact address of the page with the form.
2. Open the reCAPTCHA admin console and find the key for this site.
3. Confirm that the root domain of that address appears in the key's domain list.
4. Check that the site key on your page matches the key in the console exactly.
5. Compare the key type (v2 checkbox, v2 invisible, or v3) with the setting in your form plugin.
6. Clear your cache and reload the page in a private window.
7. Check whether your cookie consent tool blocks the reCAPTCHA script.

If the problem remains after these steps, move to server side verification. For example, a wrong secret key still shows the widget, but the form never goes through. We cover that split in its own section below.

Also note which page shows the error. If only one of several forms fails, the cause likely sits in that form's plugin or a page level setting. If every form fails, focus on the key settings instead.

How does the domain list trigger a reCAPTCHA invalid domain for site key warning?

Google's domain validation documentation states it plainly: web keys are restricted to the domains you specify and their first level subdomains. In other words, the list you enter draws the boundary of where the key works.

According to the example in that document, adding the root domain also covers the www version and first level subdomains. Therefore, the root domain alone is enough for most sites. On the other hand, if you reuse the same key on a completely different domain, such as a separate campaign site, you will get the warning.

Typos are common too. A trailing slash, a protocol prefix, or a stray space can break an entry. So enter only the bare domain, for example example.com.

• Correct: example.com.
• Unnecessary: www.example.com, because the root already covers it.
• Wrong: a full address with protocol and trailing slash.
• Missing: a second domain where the same site also runs.

Why do www and subdomains cause trouble?

Imagine your site runs on both example.com and shop.example.com. If you listed the root domain, both usually work. However, if you listed only the subdomain, the root address falls outside the key's scope.

Deeper subdomains can behave differently. The official document talks about first level subdomains. So if you use a deep address like test.shop.example.com, test it separately and add it to the list when needed.

Example scenario: a company moves its site from the www address to the bare domain, and the old key only lists the www version. After the redirect, the form shows a warning. The fix is simple: you add the root domain to the list.

What should you do for staging and localhost?

Errors on development machines are very common. Google notes that localhost is not supported by default. It also recommends separate keys for development and production.

Therefore, instead of adding test addresses to your live key, create a second key. That way, heavy test traffic does not pollute the stats for your live site. In addition, your v3 score data stays cleaner.

• Live key: only your real domain.
• Test key: localhost, your staging address, and temporary subdomains.
• Environment settings: pick the key per environment instead of hard coding it.

For v2, Google also offers special test keys that always pass. However, these keys show a warning in the widget so nobody uses them on production traffic. In practice, if you forget to swap the test key at launch, every visitor sees that warning.

What should you do when you cannot fix it yourself?

The steps in this guide solve most cases. Still, on some sites the reCAPTCHA error points to a deeper structural problem: keys buried inside the theme, plugins that override each other, and undocumented cache layers. In those cases, trial and error wastes hours.

If you want a solid setup from the start, take a look at how we approach professional web design. When we build forms, the verification layer, and cache rules to work together from day one, the chance of seeing this error drops noticeably.

On such sites, every new plugin or theme update can bring the same problem back. That is why a simpler structure beats a one time patch. Then again, read the technical sections below first; most of the time you will find the cause yourself.

Also, if you do bring in help, never send your secret key by message. Instead, grant console access to the person who needs it.

What happens when you mix up v2 and v3 keys?

Each reCAPTCHA type uses its own keys. A key you created for the v2 checkbox will not work in a plugin that expects v3. The reverse holds as well. This mix up often looks like a domain warning or an empty space where the widget should be.

For example, if your form plugin has v3 selected but you generated a v2 key, no widget appears and the form fails verification. So the type you pick in the plugin must match the key type in the console.

In short, use the table as a diagnostic map. Find your symptom, then run only that row's check. That way, you never change everything at once and lose track of what worked.

How can you tell the secret key is the problem?

Every reCAPTCHA registration comes with two keys. The site key runs in the browser, while the secret key runs on your server. If the widget appears but the form still fails, the secret key is the most likely suspect.

Google's response verification documentation lists the error codes your server can receive. For example, a missing or malformed secret returns its own code. Likewise, a response that is too old or already used returns a different code.

So check your form plugin's log first. Many plugins record the verification error in detail. Swapping the site key and the secret key by accident also happens more often than you would think; copying both fields again often fixes it.

A quick note: never put the secret key in page source, an email, or a shared document. If you think it leaked, generate a new key in the console.

Why does caching keep the reCAPTCHA error alive?

You fixed the key or the domain list, yet the warning still shows. The most common reason is caching. Your page cache keeps serving the old page with the old key to visitors.

In addition, a reCAPTCHA token is short lived and Google verifies it only once. If a cached page carries a stale token, your server rejects the submission. Therefore, consider excluding form pages from full page caching, or generate the token at the moment of submission.

1. Clear your plugin or server cache.
2. If you use a CDN, purge the page there as well.
3. Test in a private window to bypass the browser cache.
4. Exclude the reCAPTCHA script from script combining and delay settings.

Script delay features deserve special attention. They can hold reCAPTCHA back until the visitor interacts with the page. As a result, the widget loads late, or the form submits without a token and your server turns it away.

After that, save your change and try the form once more from a different device. If both devices behave the same, you know you are looking in the right place.

How can cookie consent block reCAPTCHA?

Cookie consent tools can hold third party scripts until the visitor agrees. reCAPTCHA is a Google script too. So if your tool files it under marketing or analytics, the widget never loads when a visitor declines.

This looks a lot like the domain error, because the visitor just sees a broken form. To tell them apart, accept cookies and try the form again. If the form works after consent, the problem lives in your consent setup.

At this point you also face a legal decision. How you categorize reCAPTCHA and how you describe it in your privacy notice is your responsibility. This article is not legal advice, so make that call with your legal counsel. Our guide on building a GDPR compliant website covers the broader picture, and our piece on Google Consent Mode explains how consent signals work.

Also, if consent is declined, show a clear message instead of silently disabling the form. That way, the visitor understands why the submission failed.

Why does the v3 score threshold reject real visitors?

reCAPTCHA v3 shows no widget at all. Instead, it gives each interaction a score. According to Google's v3 documentation, scores run from 0.0 to 1.0, where 1.0 is very likely a good interaction and 0.0 is very likely a bot.

The document suggests 0.5 as a starting threshold. It also recommends watching your traffic first without taking action, then adjusting the threshold. In other words, a strict threshold on day one can reject real people.

Example scenario: a site sets the threshold very high, and visitors who use a VPN or clear cookies often get bounced. These people never see a domain warning, but they cannot submit the form either. The fix is to review the score distribution in the console and lower the threshold step by step.

You should also verify the action name in v3. The documentation tells you to confirm that the returned action matches the one you expect. If it does not match, your server may reject the request.

Is turning off domain validation a real fix?

The console offers an option to turn off domain name validation. Google provides it for domain lists that are very long, keep changing, or remain unknown. However, the same document clearly calls it a major security risk.

With validation off, any site can use your key. That is why Google requires you to check the hostname field in every verification response and reject unexpected sources. Put simply, you move the check from Google to your own server.

For a business with a single website, this path makes little sense. Adding the domain correctly is both safer and easier to maintain. Only teams that manage many domains and control their server code should consider it.

How do you fix the reCAPTCHA invalid domain for site key error in WordPress form plugins?

On WordPress sites, reCAPTCHA usually comes through a form plugin or a separate security plugin. That is often where the trouble starts: two plugins load two different keys on the same page.

1. List every plugin that adds reCAPTCHA to your site.
2. Let only one of them load reCAPTCHA.
3. Enter the site key and secret key again in that plugin.
4. Make sure the selected version matches the key type in the console.
5. Clear the cache and submit the form in a private window.

For example, if both your form plugin and the security plugin protecting your login page add reCAPTCHA, two scripts collide. One may ask for v2 while the other asks for v3. Therefore, cutting down to a single source is the cleanest fix.

If the form submits but no email arrives, reCAPTCHA may not be the culprit. For that case, see our guide on contact form emails not arriving.

How does form design affect verification errors?

A verification error is a technical problem, yet visitors experience it as a design problem. When a form fails, people usually have no idea why. So a clear message at the moment of failure cuts losses a lot.

For example, a plain message such as "We could not complete verification, please refresh and try again" beats a silent failure every time. Then the visitor knows what to do next.

The overall structure of the form matters as well. Extra fields and confusing steps hurt conversions even when verification works. We cover that in our guide to lead form design for bookings, quotes, and demos.

A separate thank you page also helps with measurement. If visits to that page suddenly drop, your reCAPTCHA settings should be the first place you look.

Which verification alternatives can you consider?

reCAPTCHA is not the only option. There are also privacy friendly verification tools on the market. They usually collect less data, and some never show a puzzle at all.

That said, switching tools does not always fix the issue. Domain lists, key matching, and caching logic work in much the same way across most similar tools. Consequently, learning the basic checks pays off whichever tool you use.

• Honeypot field: a hidden field that bots fill in and people never see.
• Timing check: treat forms that someone fills in too fast as suspicious.
• Server side filter: remove known spam patterns.
• Privacy friendly verification tools: alternative services that work with less data.

For the wider security picture, our overview of the OWASP Top 10 web security risks is a good next read.

Why does the warning appear after a site migration?

A domain change is one of the most common triggers for this error. You move the site to a new address, and content and settings come along unchanged. However, the reCAPTCHA key still lists only the old domain.

So add reCAPTCHA to your migration checklist. Adding the new domain to the existing key's list is usually enough. While the old address still redirects, keep both names; once the redirect ends, you can remove the old one.

The same thing happens when you switch agencies or developers. The previous team may have created the key in their own Google account. As a result, you cannot open the console. In that case, the cleanest route is to create a new key in your own account and enter it on the site.

Images can break after a migration too; if your logo looks soft, see our guide on a blurry logo and images on your website.

How do you confirm the error with browser developer tools?

The warning on screen rarely tells the full story. Opening your browser's developer tools shows the source quickly. In most browsers, you right click the page and choose the inspect option.

In the console tab, look for red lines that mention reCAPTCHA. For example, a network error appears when the script cannot load, and a key mismatch shows its own warning. Next, open the network tab and check whether requests to Google's reCAPTCHA addresses come back successfully.

• No request at all: the script is missing from the page or a plugin blocks it.
• A blocked request: an ad blocker, a consent tool, or a security policy is active.
• A successful request with the warning still visible: the domain list or key type is the likely cause.

This way, you work from evidence instead of guesses. In addition, these screenshots speed things up a lot if a developer helps you; just make sure the secret key never appears in them.

Why do ad blockers and privacy extensions confuse the picture?

Some visitors use the form without trouble while others never see the widget. That pattern usually points to the visitor's browser rather than your domain setting. Ad blockers and privacy extensions can block Google scripts.

So if you saw the error on only one computer, first turn off that browser's extensions and try again. Then open the same page in another browser and over a mobile data connection. If the issue appears in only one setup, your site settings are most likely fine.

Still, do not ignore these visitors. A short note below the form helps when the widget fails to load. For instance, you can suggest pausing the blocker for your site or reaching you by phone or email.

This approach reduces lost leads regardless of the technical cause. Even when verification fails, the customer still finds a way to reach you.

Can a Content Security Policy block reCAPTCHA?

Yes, it can. A Content Security Policy (CSP) is a security header that tells the browser which sources it may load scripts, frames, and connections from. If your server sends a strict policy and Google's reCAPTCHA addresses are not on the allow list, the widget never loads.

In that case, the console shows a clear policy violation warning. The fix is to add the domains Google uses for reCAPTCHA to your script and frame rules. Check the current list in Google's official documentation, because it can change over time.

Security headers often come from your hosting panel, a security plugin, or a CDN. Therefore, you need to find which layer writes the header. Otherwise, a rule you fix in one place gets overridden in another.

A quick note: removing security headers entirely may look like a fast fix, but it opens your site to other risks. Narrowing the rule is always the better choice.

Who should own the key, and how do you manage access?

Every reCAPTCHA key belongs to a Google account. Whoever created the key controls it in the console. So the account that holds the key decides whether you can fix the error at all.

Example scenario: a freelance developer built the site years ago and created the key in a personal account. Now the domain has changed, but nobody can log in to the console. In that case, there is no way to repair the old key; you need a new one.

That is why you should create keys in your company's own Google account. Also, adding more than one owner in the console removes the dependency on a single person. As a result, your forms never end up without an owner when staff or vendors change.

In short, key management looks like a technical detail, but it is part of business continuity. Reviewing the access list at least once a year is a good habit.

How do you prevent the error for good?

Fixing the error once is not enough; you need a small routine so it does not return. The list below covers the basic checks our team runs on every project with forms.

• Create keys in the company's Google account, not a personal one.
• Use separate keys for production and staging.
• Update the domain list after every migration or new subdomain.
• Test the form with a real submission after every plugin update.
• Exclude form pages from full page caching.
• Verify the hostname and action fields on the server.

Then, when an error shows up, you quickly find which setting changed. You also never have to ask who holds the keys.

Write this list down and share it with your team. After that, reuse it as a template on every new project. That way, the reCAPTCHA invalid domain for site key warning will not surprise you on launch day.

When should you generate a brand new key?

Sometimes creating a new key is faster than repairing the old one. Google's FAQ explains that an invalid site key warning means the key is no longer valid, and you need to register a new one.

Also create a new key if you cannot access the console, if you suspect the secret key leaked, or if you want to switch versions. Then remove the old key from the site completely so the two never collide.

A quick note: after you generate a new key, replace both the site key and the secret key at the same time. Changing only one recreates the classic case where the widget shows but the form fails.

After the switch, watch the console stats for a few days. If request volume looks normal and no errors appear, the switch is complete. Otherwise, some leftover code may still load the old key; scan your theme files and plugin settings again.

When does professional help make sense?

You can fix a simple missing domain yourself in a few minutes. However, once the error spreads across several plugins, a custom theme, and multiple cache layers, isolating it takes expertise. At that stage, a wrong setting can throw the door wide open to spam.

Reliable forms mean real customer inquiries. For that reason, web design services that handle form infrastructure, verification, and cache rules together protect you from repeat errors in the long run. Our team also makes sure forms stay easy to test after launch.

Testing is part of that work. Before launch, we send a real submission through every form, then confirm that the notification email arrives. That way, we catch problems before your visitors do.

Finally, the reCAPTCHA error looks scary, but it usually comes down to one setting. Follow the steps in order, test after every change, and keep your keys in your own account.