If WordPress accepts the login form but sends you back to it, trace the redirect chain and authentication cookie before resetting the password repeatedly. A host mismatch, cached login response or incorrect HTTPS interpretation can prevent a valid login from persisting.
Identify which failure you have
Record the first URL, final URL and displayed message. A 429 response belongs to rate-limit diagnosis. A wrong-password message belongs to credential recovery. An endless redirect sequence or a return to the form needs a session-path investigation.
Try the known canonical login URL in a clean browser profile with cookies permitted for that site. Do not disable your firewall or two-factor authentication. Keep an existing authorized admin session open while investigating so you retain a recovery route.
Inspect the browser's evidence privately
Open Developer Tools > Network, preserve the request log and submit one authorized login attempt. Inspect the sequence of hosts and schemes. Check whether the response sets an authentication cookie and whether the following request sends it.
Never paste cookie values, credentials or a full unredacted network archive into a public support ticket. The useful evidence is the cookie's presence, blocked reason, domain/path scope and redirect destinations, not the secret value.
Login attempt: Cookie accepted for correct host. Admin navigation: Session survives refresh. Second tab: Authorized page opens. Logout: Protected page requires login. Explanatory checklist, not a customer test result.
Compare the URL configuration
Check the site's home and siteurl settings and any WP_HOME or WP_SITEURL constants. They may legitimately differ when WordPress is installed in a subdirectory. Do not force them to match without understanding the installation layout.
| Observed pattern |
Investigation |
| www changes to apex after login |
Canonical host and cookie scope |
| HTTPS repeatedly changes to HTTP |
Proxy and origin scheme configuration |
| Cookie is blocked by the browser |
The browser's stated reason and cookie attributes |
| One cached response repeats |
Login/session cache exclusions |
For a reverse proxy, ask the host to verify trusted forwarding and HTTPS detection. Blindly trusting a client-supplied forwarding header is not a safe repair. Keep encryption enabled between the required layers.
Isolate a customization carefully
If configuration is consistent, reproduce on staging with the same login or security extension settings. Test the smallest suspected component first. Renaming every plugin directory on a live shop can interrupt payments, access controls and background jobs.
Inspect recent changes to SSO, custom login routes and redirect hooks. A successful core login followed by an extension redirect is a different failure from WordPress rejecting the authentication cookie.
Confirm persistence and logout
After a repair, log in, navigate to a second admin page, refresh and open another admin tab. Then log out and confirm that the protected page requires authentication again. Test the intended canonical host, not an accidental alternate hostname.
Ask HandL WP to trace the login path with redacted destinations and timestamps if the cycle remains unexplained. Preserve authentication protections while investigating.
Reference: WordPress login troubleshooting.
References reviewed October 4, 2026. Examples are explanatory; production changes require an appropriate backup and authorized access.