A correct password can still lead back to the WordPress login screen after a domain or HTTPS move. The login may succeed, but the browser cannot keep the session when the configured URLs, cookie domain or proxy handling disagree.
Trace the address before submitting the form and the address that appears after the redirect. Correct the underlying URL and HTTPS path first, then start a clean browser session to test whether the cookie now stays attached.
Compare the active WordPress settings with the migration plan, then start a clean browser session. Repeated password resets do not diagnose a redirect or cookie mismatch.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Trace the login URL before clearing cookies
| Loop pattern | Inspect | Next check |
|---|---|---|
| Redirects to the old domain | Active home/site URL and overrides | Correct the setting source |
| Switches between HTTP and HTTPS | Proxy scheme and redirect chain | Host and CDN configuration |
| Only one browser fails | Site cookies and browser restrictions | Clean session at the intended URL |
| Host shortcut works, normal login fails | Different entry points | Verify the public login workflow |
| Certain roles land on another page | Membership or login rules | Expected role-specific destination |
Track the address before and after login
- Record the intended login address.
- Note the hostname and scheme after submitting.
- Capture the redirect statuses without copying session secrets.
- Compare a normal login with any hosting shortcut.
- Give the host the redacted chain and the migration time.
Keep the initial login URL and the address shown after submitting the form. Watch for a switch to the old domain, another hostname, or HTTP. A browser Network view can help a developer see the redirect chain without guessing.
Do not share cookies, password-recovery links, or an unreviewed network export publicly. The addresses and redacted response status are normally enough to describe the pattern in an initial support request.
A hosting sign-in shortcut can use a different entry point from a normal WordPress login. Test the intended public login workflow too, so a working host shortcut is not mistaken for a complete repair.
Compare the configured URLs with the installation
Check Settings → General when accessible. WordPress Address points to application files; Site Address points to the public site. They can differ for an intentional subdirectory installation. Identify any WP_HOME or WP_SITEURL override before assuming dashboard values are active.
Configuration constants such as WP_HOME and WP_SITEURL can override database options. A corrected dashboard setting may therefore not be the value actually used. A developer should identify the active source before adding another override.
Back up the configuration and database before corrections. Changing the wrong address can remove dashboard access, while a broad text replacement can affect serialized settings. Use a migration-aware method with a reviewed scope.
Confirm the HTTPS path through the proxy
A CDN or reverse proxy may terminate HTTPS before forwarding a request to the origin. The application still needs to understand the original secure request correctly. If one layer thinks the visit is HTTP while another forces HTTPS, a loop can result.
Ask the host to inspect the request scheme and redirect chain. The correct fix depends on its proxy arrangement. Disabling encryption or forcing a mismatched mode to suppress the symptom can create a different problem.
Keep a single clear policy for the preferred hostname and HTTPS redirects. Review redirects in the host, CDN, plugin, and application rather than adding another rule at each layer.
Start a clean session after the configuration is correct
Old cookies belong to the addresses and session state under which they were created. After the intended URL setup is fixed, clear this site’s cookies or use a clean browser session, then sign in at the current address.
Confirm that the browser accepts the required cookies. Private browsing is useful for comparison, but privacy settings can still restrict them. If only one browser fails, its local settings or stored session become more relevant.
If the site explicitly defines a cookie domain or path, have that setting reviewed for the new installation. Adding cookie constants without understanding the current defaults can make the mismatch harder to resolve.
Check caching and custom login rules
Login and authenticated dashboard responses need appropriate cache handling. A stale redirect or cached login response can persist after the underlying URL change. Ask the cache provider to inspect the relevant route rather than purging every asset indefinitely.
A membership or security plugin may intentionally redirect certain users to a front-end page. That behavior is different from an administrator session failing. Compare the expected destination for the account role and the plugin’s settings.
Use staging for wider plugin comparisons, and keep any temporary access change targeted. Our general login guide covers rejected passwords, blocked pages, and other symptoms unrelated to a move.
Verify both the login and the public domain
Sign out, sign in once at the preferred address, and save a harmless draft change. Then open the public site without a session and confirm it remains on the intended hostname and HTTPS scheme.
Record the final active settings and the layer responsible for redirects. WordPress’s migration guide and login documentation provide the reference for the developer or host reviewing the setup.
Verify a complete session
At the intended address, sign out and sign in once, open the editor and save a harmless draft change. Then check the public site without a session. Both should use the planned hostname and HTTPS path. Record the layer responsible for redirects so that a later rule does not reintroduce the loop.