An invalid site key message usually appears before WordPress checks a password. The browser-facing credential does not match the current hostname, provider property, or reCAPTCHA integration type.
Identify the exact key pair and environment, correct the single broken mapping, and keep a separate administrator recovery path while login protection is unavailable.
What it means
The site key is a public identifier used by the browser. Its paired secret stays on the server for verification. Both belong to a specific provider configuration and supported integration type.
A secret, analytics ID, or key from another service cannot substitute for the site key.
A realistic WordPress example
A staging site moves to production and displays an invalid key. The administrator copied credentials from another property and later switched reCAPTCHA versions, so the hostname, public key, secret, and client integration no longer agree.
Creating or selecting the correct production pair for the supported version resolves the browser error and restores server verification.
Why it matters and when to use it
The error can block every legitimate login while providing no useful challenge to automated traffic. It may also indicate that credentials were copied through an unsafe channel.
Use this diagnosis when the provider rejects the key before a challenge appears, especially after a hostname, environment, or integration change.
A straightforward route for beginners
- Record the exact provider message and page hostname.
- Confirm the reCAPTCHA type supported by the WordPress integration.
- Verify that the browser field contains the public site key, not the secret or another identifier.
- Check the allowed production and staging hostnames in the provider account.
- Enter the paired secret in the server-side field and clear relevant caches.
- Test challenge success, failure, login, and password recovery from a clean browser.
The advanced route
Inspect the client network request and rendered source for duplicate or stale keys injected by a plugin, theme, tag manager, or cache. Confirm that only the intended integration loads on the login route.
Trace server verification without logging the token or secret. Record the credential owner, key type, allowed hosts, environment, configuration location, rotation date, and test result.
Risks, common mistakes, backup, and rollback
Repeatedly creating keys without removing stale configuration can leave several active credentials and no clear owner. Exposing the secret in page source, tickets, or logs requires rotation, even if the original problem was only a mismatch.
Save the prior challenge settings and keep a known-good administrator session. If the replacement still blocks users, disable only the affected challenge while you restore the verified pair.
How AIOWS helps:
AIOWS Login Manager
AIOWS Login Manager centralizes supported login protection, challenge, recovery, IP-rule, and activity-review controls. Its supported challenge settings provide a clear place to correct the reCAPTCHA credential mapping.
Change only the invalid configuration and test the login route from a logged-out browser. Keep an administrator session open until correct and incorrect credentials, challenge failure, and password recovery behave as expected.
Login Manager cannot change the provider’s hostname registration or recover a secret exposed outside WordPress. Maintain provider-account ownership and rotate compromised credentials through the provider.
Related AIOWS articles
- How to Add reCAPTCHA to the WordPress Login Page
- How to Limit Login Attempts in WordPress
- How to Read WordPress Login Activity Logs
Conclusion and recommended route
Match the site key and secret to the same provider property, supported integration type, and exact hostname. Remove stale injected or cached copies, and rotate the secret if it ever appeared in client output or ordinary documentation.
