"ERROR for site owner: Invalid domain for site key" — Why reCAPTCHA Rejects Your Own Website

Every reCAPTCHA site key carries an allowlist of domains it is permitted to run on. When the widget loads, Google checks the hostname of the page serving it against that list. If the hostname is not covered, the widget refuses to render and shows the "Invalid domain for site key" banner instead — visible to every visitor, even though only the site owner can fix it. Google's own troubleshooting documentation is blunt about the cause: the key is being used on a hostname that was never registered for it.

That sounds like a configuration mistake you would catch immediately. In practice, support threads from the official reCAPTCHA group to Google Sites embeds show the error appearing weeks or months after a working launch — because the page started rendering from a hostname nobody thought of as "a different domain."

The Five Traps That Trigger It on Working Sites

1. Embeds and iframes render from someone else's domain

If your form is embedded in a page builder, helpdesk portal, landing-page tool, or a Google Sites page, the CAPTCHA does not execute on yourdomain.com — it executes on the hosting platform's domain or the iframe's origin. Form vendors like Zoho Forms document exactly this failure: the form works on your site but errors inside the embed, because the embed's hostname was never added to the key. The fix is to add every hostname the form actually renders from — your domain and the platform's.

2. The www / apex mismatch

Registering www.example.com covers its subpaths, and registering the root domain example.com covers its subdomains. But teams who registered only a deeper hostname — say, shop.example.com — and later moved the form to example.com or www.example.com get the error, because domain coverage flows downward to subdomains, not upward to parents. The safe pattern is to register the root domain; per Google's guidance, subdomains are then covered automatically.

3. Staging, preview, and migration hostnames

Hosting-platform troubleshooting guides such as WHMCS's KB see this constantly: a site is cloned to staging.example.com, a *.pages.dev preview, or a temporary migration URL, and the production site key travels with the clone. The key is valid; the hostname is not. Either add the staging hostname to the key or — better for security — use a separate key or Google's test keys outside production.

4. The wrong key in the wrong slot

Most platforms ask for two values: the site key (public, rendered in HTML) and the secret key (server-side only). Pasting the secret into the site-key field, or pasting a key pair that belongs to a different property in a multi-site setup, produces domain and key errors that look identical from the visitor's side. When the error appears right after "fixing" credentials, re-copy both values from the reCAPTCHA admin console and confirm which property they came from.

5. The 30-minute propagation window

Domain-list changes are not instant. Google documents that updates can take up to 30 minutes to take effect — long enough for an admin to conclude the fix "didn't work," try something else, and end up with a config that is wrong in a new way. After editing the domain list, wait, then re-test in a private window so a cached failure does not mislead you.

The Fix, Step by Step

1. Identify the real rendering hostname. Open the failing page, check the address bar — and if the form is embedded, inspect the iframe's src to find the origin actually executing the widget.
2. Open the key in the admin console. In the reCAPTCHA admin console, select the site key your page uses — verify the key string matches what is in your HTML, not just the project name.
3. Add root domains, without protocol or path. Enter example.com, not https://example.com/contact. Subdomains are covered by the root entry.
4. Save, wait, and re-test. Allow up to 30 minutes; test in a private window from the exact failing URL.
5. Leave domain verification on. The admin console offers a switch to disable domain checking entirely. Turning it off makes the error disappear — and lets anyone reuse your site key on any website, polluting your analytics and risk data. If you must disable it (some multi-tenant setups do), Google's docs require you to validate the hostname yourself in the siteverify response server-side.

Why This Error Is a Design Smell, Not Just a Typo

Notice who suffers while the domain list is wrong: your visitors. The error banner is addressed "to the site owner," but it is rendered to every user, and the form behind it is unusable the entire time. A misconfiguration that should be an internal alert becomes a public outage — the same failure shape we cover in our guides to common reCAPTCHA errors and regional loading failures.

Defensively, that argues for two habits. First, treat verification configuration as code: keep the domain list, key IDs, and environment mapping in your deployment notes so a staging clone or domain migration includes the CAPTCHA config in its checklist. Second, monitor the widget like a dependency — a synthetic check that loads your form and asserts the widget rendered will catch a domain mismatch in minutes instead of after a week of silent lost signups. Verification systems with lighter client-side footprints, such as rCAPTCHA's behavioral approach, reduce the number of moving parts that can fail publicly — but any third-party verification, ours included, deserves the same monitoring discipline.

People Also Ask: Invalid Domain for Site Key FAQ

What does "ERROR for site owner: Invalid domain for site key" mean?

The reCAPTCHA site key on the page is not authorized for the hostname the page is being served from. The widget refuses to render until the domain is added to the key's allowlist in the reCAPTCHA admin console, or until the page uses a key that covers that domain.

Do I need to add every subdomain to the domain list?

No. Registering the root domain covers its subdomains automatically. You only need separate entries for entirely different domains — including the domains of platforms that embed your form in an iframe.

I added the domain but the error is still there. Why?

Domain-list changes can take up to 30 minutes to propagate. If the error persists beyond that, confirm you edited the same key the page actually uses, check for typos in the domain entry, and verify the form is not rendering inside an iframe from a different, unlisted origin.

Is it safe to turn off domain verification?

It makes the error vanish, but it also lets any website on the internet run your site key. If you disable it, Google's documentation says you must check the hostname field of every siteverify response on your server and reject tokens from hostnames you do not own. Otherwise, keep verification on and maintain the list.

Conclusion

"Invalid domain for site key" is the most honest error in the CAPTCHA family: the key really is being used somewhere it was never registered to run. The work is finding out where that "somewhere" is — an embed platform, a staging clone, an apex/www mismatch, or a key pasted into the wrong property. Add root domains, respect the propagation window, keep domain verification enabled, and put a synthetic check on your forms so the next configuration drift pages you — not your would-be customers.

Sources & Further Reading

• Google Cloud: Troubleshoot reCAPTCHA integration issues
• Google reCAPTCHA admin console (domain settings)
• Google reCAPTCHA group: "ERROR for site owner: Invalid site key"
• Google Sites community: embed reCAPTCHA invalid-domain thread
• WHMCS KB: Troubleshooting reCAPTCHA Invalid Domain for Site Key
• Zoho Forms FAQ: invalid domain for site key on embedded forms