LiveChat 
Support 
ERROR for site owner: Invalid domain for site key — What It Means and How to Fix It
You opened your own contact form, expected a tidy little reCAPTCHA checkbox, and instead got a red-bordered box shouting “ERROR for site owner: Invalid domain for site key.” The form won’t submit, visitors can’t reach you, and the message sounds like it’s blaming you personally. It is, gently. But don’t worry. This is one of the most common reCAPTCHA mistakes, and the fix is almost always quick.
Here’s the short version, because I know you’re probably mid-panic: the domain that’s serving your form isn’t on the list of domains registered for that reCAPTCHA site key. Google’s reCAPTCHA service checks where the request is coming from, doesn’t find your current domain on its approved list, and refuses to load. Let me walk you through what that really means and exactly how to get your form working again.
Key Takeaways
• “Invalid domain for site key” means the domain currently serving your form is not registered in the reCAPTCHA admin console for that specific site key. reCAPTCHA only loads on domains you’ve explicitly added.
• The most common trigger is a www vs. non-www mismatch, registeringexample.combut loading the form onwww.example.com(or the reverse).
• It can also mean you’re testing on localhost or a staging URL that was never added to the key’s domain list.
• Sometimes the cause is using the wrong key pair entirely, or mixing up the site key and secret key, or pasting a key from a different reCAPTCHA version.
• The fix is almost always to add the exact domain to the key in the reCAPTCHA admin console, then clear your cache. Changes are usually live within minutes.
Here’s the part that catches even experienced developers off guard, so let me say it plainly: reCAPTCHA treats example.com and www.example.com as completely separate domains unless you’ve explicitly handled them. There is a saving grace, registering the bare root domain (example.com) automatically covers all of its subdomains, including www.example.com. But the reverse is *not* true: register only www.example.com and your root example.com will throw this error. So the single most reliable habit is to register the root domain without the www, and reCAPTCHA quietly covers every subdomain underneath it. The second insight people miss: this error is *purely* about the domain list, not about your keys being broken or your code being wrong. If the form works on one URL of your site but not another, you don’t have a code bug, you have a missing domain entry. Once you internalize those two facts, this error stops being mysterious. For the bigger picture on how domains and their variants actually behave, see the Domain Names: The Complete Guide to How They Work, Choosing One, and Owning Your Address.
What does “invalid domain for site key” actually mean?
In plain language: the web address where your form lives is not on the approved domain list attached to your reCAPTCHA site key.
When you created your reCAPTCHA, Google gave you a *site key* (the public one in your page code) and a *secret key* (the private one your server uses). Tied to that pair is a list of domains you registered, the only places that key is allowed to run. Each time your form loads, the reCAPTCHA widget reports the domain it’s running on back to Google’s servers.
Google then checks that domain against your approved list. If it matches, the widget loads normally. If it doesn’t, Google refuses and shows “ERROR for site owner: Invalid domain for site key.” It’s a security feature, not a glitch. It stops someone from copying your public site key and using it on their own website. The message points at you, the owner, because you’re the only one who can update that domain list.
So the question to ask is never “what’s wrong with my key?” It’s “is the exact domain I’m viewing actually registered for this key?“
What commonly causes this reCAPTCHA error?
In my experience troubleshooting these, nearly every case falls into a short list of patterns. Once you recognize yours, the fix becomes obvious.
- www vs. non-www mismatch. You registered
yourdomain.combut the form loads onwww.yourdomain.com, or you registered only the www version and the root throws the error. This is far and away the most frequent cause. - Testing on localhost or 127.0.0.1. You’re developing locally, but
localhostwas never added to the key. reCAPTCHA doesn’t recognize it by default. - Staging or preview URLs. The site runs fine in production but breaks on
staging.yourdomain.com, a*.netlify.apppreview, or a temporary hosting URL that isn’t on the list. - Using the wrong key pair. You copied a site key from a *different* reCAPTCHA registration, maybe an old project, that’s scoped to a different domain.
- Mixing up reCAPTCHA versions. A v2 key pasted into a v3 setup (or vice versa) won’t validate correctly and can surface domain or key-type errors.
- A brand-new domain or recent migration. You just moved to a new domain and forgot the reCAPTCHA list still points at the old one.
- A typo in the registered domain. A stray character, an extra
www, orhttp://left in the domain field, since you should enter the domain only, no protocol, no path.
Notice the thread running through every one of these: the domain being served doesn’t exactly match a domain on the list. That’s the whole error in a sentence.
Cause-to-fix reference table
| Cause | Fix |
|---|---|
| Form loads on www but only non-www is registered | Register the root domain (yourdomain.com); it covers www and all subdomains |
| Only www was registered; root domain fails | Add the root domain yourdomain.com to the key’s domain list |
| Testing on localhost / 127.0.0.1 | Add localhost (and 127.0.0.1) to the key, or use Google’s test keys |
| Staging or preview URL not listed | Add the staging domain to the key, or use a separate key for staging |
| Wrong site key copied from another project | Replace it with the site key from the correct registration |
| reCAPTCHA v2 key used in a v3 integration (or vice versa) | Generate the right key type for your version and swap it in |
| Domain changed or site migrated | Add the new domain to the existing key’s list |
| Protocol/path or typo in the registered domain | Re-enter the bare domain only, no http://, www, or trailing slash |
How do I fix “invalid domain for site key”? (Step by step)
Work through these in order. The fix is usually finished before your coffee gets cold.
- Open the reCAPTCHA admin console and register your domain. Go to the reCAPTCHA admin console, select the site key that’s failing, open its settings, and look at the Domains list. Add the exact domain your form runs on, entering just the domain (
yourdomain.com), with nohttps://, nowww, and no trailing slash. Save. Changes typically take effect within a few minutes.
- Match www vs. non-www the smart way. Don’t list both variants individually if you can avoid it. Instead, register the root domain (
yourdomain.com) on its own. reCAPTCHA automatically extends that to every subdomain, includingwww.yourdomain.com,blog.yourdomain.com, and so on. This single habit prevents most recurrences of this error.
- Confirm you’re using the right key pair. Double-check that the site key in your page’s HTML matches the registration you just edited. It’s easy to paste a key from an old project. While you’re there, make sure you haven’t swapped the site key and secret key, the site key goes in your front-end widget, the secret key stays on your server for verification and never appears in page source.
- Check the reCAPTCHA version matches your key. A v2 “I’m not a robot” key and a v3 invisible-score key are not interchangeable. If you’re seeing a related “invalid key type” message alongside this, generate a key for the correct version in the admin console and update your code.
- Handle localhost and staging properly. For local development, add
localhostand127.0.0.1to the key’s domain list, or use Google’s official testing keys that always pass. For staging environments, either add the staging domain to your key or, cleaner still, create a *separate* reCAPTCHA key just for staging so you never mix test and production traffic.
- Clear your cache and hard-refresh. Browsers and caching plugins love to hold onto the old, broken state. After updating the domain list, clear your browser cache, do a hard refresh (Ctrl+F5), and if you run a caching or CDN layer, purge it too. Test in an incognito window to be sure you’re seeing the live version.
How do localhost and staging environments fit in?
A quick, useful fact: reCAPTCHA does not recognize localhost automatically, which is why so many developers hit this error the moment they start testing a form locally. Google’s verification needs a real, registered domain, and your local machine isn’t one unless you tell it so.
You have two clean options. First, add localhost and 127.0.0.1 directly to your site key’s domain list in the admin console, fine for solo development. Second, and my preference for teams, use Google’s published test keys, a special site/secret pair that always validates on any domain and is meant purely for development. Just remember to swap in your real keys before going live, because the test keys show a visible warning and provide no real spam protection.
For staging sites, treat the staging domain as its own first-class domain. Either add it to your production key or, better, register a dedicated staging key. Keeping them separate means a test bot run never pollutes your production analytics, and a mistake in staging can’t break the real form.
How is the site key different from the secret key?
The distinction matters here, because mixing the two is a sneaky cause of this and related errors. Your site key is public and your secret key is private, and they live in two completely different places.
The site key belongs in your front-end HTML, inside the reCAPTCHA widget that visitors’ browsers load. It’s meant to be visible, anyone can view your page source and see it, which is exactly why the domain restriction exists in the first place. The domain list is what stops a stranger from lifting your public site key and bolting it onto their own site.
The secret key belongs only on your server. After a visitor solves the challenge, your back-end sends the response token *and* the secret key to Google to confirm the result. The secret key must never appear in page source, JavaScript, or anywhere a browser can read it. If you accidentally place the secret key where the site key should go, the widget won’t render correctly, and you may see domain or configuration errors that look a lot like this one. When in doubt, regenerate the pair and place each key in its proper home.
Is this error a security problem?
No, and that’s the reassuring part: this error is reCAPTCHA working exactly as designed. The domain check exists to protect *you*. Without it, anyone could copy your public site key, paste it on a spam farm, and ride on your reCAPTCHA reputation. The “invalid domain” block is the wall that keeps your key tied to your sites and nobody else’s.
So when you see this message on your own site, it’s not a breach or a hack. It’s a configuration gap, your current domain simply hasn’t been added to the approved list yet. Fix the list and the wall opens for you. The same strictness that’s annoying you right now is the feature that stops bad actors from abusing your credentials.
How DarazHost helps you avoid domain mismatches like this
Most “invalid domain for site key” headaches trace back to messy domain configuration, www and non-www pointing in different directions, a half-finished migration, or DNS that never settled cleanly. That’s where solid hosting pays off. With DarazHost, your domain and DNS are set up correctly from the start, and we make it simple to enforce a single canonical version of your site (www or non-www) with a proper redirect, so your form always loads on one predictable domain. That consistency means you register *one* domain in the reCAPTCHA console and it just works. And if you do get stuck matching a domain to your key, our 24/7 support team can walk you through the DNS and redirect side so the reCAPTCHA piece falls into place. Fewer moving parts, fewer mismatch errors.
Frequently asked questions
Do I need to register both www and non-www versions of my domain? Usually not. If you register the bare root domain (yourdomain.com), reCAPTCHA automatically covers all of its subdomains, including www.yourdomain.com. Register only the www version, though, and your root domain will fail. Registering the root is the safest single entry.
How long does it take for a new domain to start working after I add it? Changes in the reCAPTCHA admin console are typically live within a few minutes. If the error persists after that, it’s almost always your browser or CDN cache. Hard-refresh, purge any caching layer, and test in an incognito window to confirm.
Why does reCAPTCHA work on my live site but not on localhost? reCAPTCHA doesn’t recognize localhost automatically, it needs a registered domain. Add localhost and 127.0.0.1 to your key’s domain list, or use Google’s official test keys during development and swap in your real keys before launch.
Could this be caused by using the wrong key type instead of the wrong domain? Yes. A reCAPTCHA v2 key used in a v3 integration (or the reverse) can trigger domain or “invalid key type” errors. Confirm the key in your code matches the version your site implements, and regenerate the correct type in the admin console if needed.
I entered my domain but still see the error. What did I get wrong? Check the format. Enter the domain only, no http:// or https://, no www, and no trailing slash or path. A stray protocol or typo means reCAPTCHA never matches it. Re-enter the clean bare domain, save, then clear your cache.
The calm bottom line
“ERROR for site owner: Invalid domain for site key” sounds like an accusation, but it’s really just a checklist item: the domain serving your form isn’t on the approved list for that key. Encryption, code, and keys are usually fine, the domain entry is simply missing. Open the reCAPTCHA admin console, add your root domain (which covers www and every subdomain), confirm you’re using the right site key for the right reCAPTCHA version, handle localhost or staging deliberately, and clear your cache. Do that and your form is back in minutes. Methodical beats panicked, every single time.
