What matters first: WordPress attempted to set or read its test cookie and did not receive the expected value. The browser, domain, path, HTTPS detection and response headers all participate.
What this symptom actually tells you
If the error affects every browser, server configuration is more likely than a local privacy setting. Capturing Set-Cookie and the next request shows whether the cookie was issued, stored and returned.
Capture evidence before changing anything
- Inspect Set-Cookie on wp-login.php and the Cookie header on the following request.
- Compare the cookie domain and path with the address in the browser.
- Check WordPress Address, Site Address and HTTPS detection behind proxies.
- Look for headers-already-sent warnings and cached login responses.
Most common causes
- Domain mismatch: The cookie belongs to another host, www variant or old migration domain.
- Secure-cookie mismatch: WordPress believes the request is HTTP while the browser uses HTTPS, or vice versa.
- Cached login page: A CDN or page cache serves stale cookies or nonces.
- Early output: PHP output prevents the Set-Cookie header from being sent.
Safe diagnostic and repair sequence
- Exclude wp-login.php and wp-admin from every full-page cache.
- Correct canonical URLs and forwarded HTTPS handling.
- Remove unintended COOKIE_DOMAIN overrides unless the architecture requires them.
- Clear only the relevant browser cookies and repeat while inspecting headers.
How to choose between the likely causes
Do not treat Domain mismatch and Secure-cookie mismatch as interchangeable. The cookie belongs to another host, www variant or old migration domain. By contrast, wordPress believes the request is HTTP while the browser uses HTTPS, or vice versa. Use two checks to separate them: Inspect Set-Cookie on wp-login.php and the Cookie header on the following request; and compare the cookie domain and path with the address in the browser. Those observations usually show whether the next safe move is to exclude wp-login.php and wp-admin from every full-page cache or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not disable secure or HttpOnly cookie flags to make login work. Fix the scheme and domain detection that caused the mismatch.
How to verify the repair
- Login persists through an admin page refresh.
- The correct authentication cookies are set and returned for the canonical host.
- Other browsers and a clean session behave consistently.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
If the error affects every browser, server configuration is more likely than a local privacy setting. Capturing Set-Cookie and the next request shows whether the cookie was issued, stored and returned.
- 1
Inspect Set-Cookie on wp-login.php and the Cookie header on the following request.
- 2
Compare the cookie domain and path with the address in the browser.
- 3
Check WordPress Address, Site Address and HTTPS detection behind proxies.
- 4
Look for headers-already-sent warnings and cached login responses.
What must be verified
- Login persists through an admin page refresh.
- The correct authentication cookies are set and returned for the canonical host.
- Other browsers and a clean session behave consistently.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Does this error mean the visitor's browser is actually blocking cookies?+
Not necessarily. WordPress shows this message whenever its test cookie was not returned correctly, which is often a server-side issue such as a domain mismatch or a secure-cookie flag conflict rather than a real browser privacy setting. Checking whether the problem affects every browser, not just one visitor, is the fastest way to rule out a local setting.
Is it safe to just disable secure or HttpOnly cookie flags to get logins working again?+
No. Turning off those flags removes a security protection instead of fixing the underlying cause, which is almost always incorrect HTTPS detection or a domain mismatch between the cookie and the site's canonical address. The correct fix is to correct scheme and domain detection, not to weaken the cookie.
Why would this error appear only after a migration or domain change?+
If the cookie was issued for an old domain, a www variant, or a different host than the one now in the address bar, WordPress will not recognize it as valid. Comparing the cookie's domain and path against the current browser address usually reveals this immediately.
Could caching be the reason login keeps failing even after clearing browser cookies?+
Yes. A CDN or full-page cache serving a stale wp-login.php response can hand out old nonces or cookie values regardless of what the browser does. Excluding wp-login.php and wp-admin from every layer of page caching is a required step, not an optional one.