A WordPress admin login redirect loop fix starts with evidence, not repeated password attempts. A successful login that immediately returns to the login screen usually points to a session, URL, HTTPS, plugin, or cache problem.
This issue can affect every administrator or only one browser. It can also appear after a domain change, SSL adjustment, migration, plugin update, hosting change, or caching configuration. The safest approach isolates one layer at a time and preserves a way back into the site.
Recognize the login loop before changing settings
WordPress normally sets a browser cookie after authentication. The cookie proves that the browser has an active session. If WordPress cannot set, read, or validate it, the login may appear to succeed before the site sends you back to wp-login.php.
First, record what happens. Note the login address, the final address, the browser, the device, and whether the loop affects other users. Capture the exact URL if the address bar changes between http and https, or between a domain and its www version.
- Test a private browser window, but do not treat that test as proof of a fix.
- Try the canonical administrator address, usually
/wp-admin/. - Check whether the public website loads normally.
- Ask whether the problem started after a specific change.
- Avoid repeated login attempts if a security plugin may rate-limit the account.
If one browser works and another fails, suspect stale cookies, extensions, or local browser policy. If every browser fails, focus on the site configuration, server, plugins, or caching path.
Check WordPress URLs for exact consistency
WordPress uses two important URL values. The WordPress Address identifies where the core files live. The Site Address identifies the public website address. They can differ in some designs, but an accidental mismatch can create redirects and broken cookies.
Compare the values with the address visitors should use. Check all of these details:
httpversushttpswwwversus the bare domain- Uppercase or unusual path characters
- A temporary hosting URL or staging domain
- Trailing paths when WordPress runs in a subdirectory
Use the WordPress dashboard if you can reach it. Otherwise, check the values through the hosting control panel, database tools, or the wp-config.php file. A temporary constant such as WP_HOME or WP_SITEURL can override database values, so inspect both places.
Do not add URL constants blindly. Confirm the intended canonical address first, and record the original configuration before editing it. If a previous URL change caused the problem, use this guide to recovering a WordPress site after an accidental URL change. This check is often the most direct WordPress admin login redirect loop fix when the problem follows a migration or domain change.
Test cookies and browser session behavior
Cookies are small browser values that hold session information. A login loop can occur when the browser rejects them, when the site sets them for the wrong domain, or when HTTPS and HTTP requests receive inconsistent cookie rules.
Run a controlled cookie test:
- Open a private window and visit the exact canonical login URL.
- Accept the site’s necessary cookie prompt if one exists.
- Sign in once, then watch the address bar.
- Close the window and remove cookies for the affected domain.
- Test again without browser extensions.
Inspect browser developer tools only if you are comfortable doing so. In the storage or application area, check whether WordPress creates authentication cookies. In the network area, look for repeated redirects and response headers that set or clear cookies.
Also test another device or network. A corporate browser policy, privacy extension, or proxy can interfere with cookies. However, do not lower security settings across the organization as a permanent workaround. Identify the affected policy and verify the result with the person managing those devices.
Verify HTTPS and reverse-proxy settings
HTTPS encrypts traffic between the browser and website. A reverse proxy or CDN may terminate HTTPS at the edge, then connect to the origin server over HTTP. WordPress must still understand that the original visitor used HTTPS.
When that information is missing or incorrect, one layer may redirect HTTP to HTTPS while another layer believes the request is already secure. The result can be a loop, failed secure cookies, or a login that never persists. Correct HTTPS detection may provide the WordPress admin login redirect loop fix without changing passwords or disabling security controls.
Review these layers together:
- The certificate covers the exact login hostname.
- The hosting panel redirects to the intended HTTPS address.
- WordPress URL values use the same canonical scheme and hostname.
- The CDN or proxy forwards the original protocol correctly.
- Server rewrite rules do not force a conflicting destination.
- Security plugins do not apply a second, different HTTPS policy.
Do not copy a proxy-specific header rule from another server. Header names and trusted-proxy settings depend on the hosting design. Ask the host or administrator to confirm how the origin detects HTTPS. For general certificate and HTTPS reference material, consult Let’s Encrypt documentation.
Isolate plugins without losing recovery access
Plugins can change login redirects, cookie behavior, authentication, URLs, security rules, and cache headers. A recent update is useful evidence, but it does not prove that the updated plugin caused the loop.
Use controlled plugin isolation. If the dashboard remains available in another session, deactivate the suspected plugin first. If you cannot access the dashboard, use a staging copy when possible. Otherwise, use hosting file access or a secure file transfer method to rename the wp-content/plugins directory temporarily.
Renaming the entire directory disables all standard plugins. That is a diagnostic step, not a final repair. If login works afterward, restore the directory name and deactivate plugins in smaller groups. Test after each change. Then identify the single conflict by reactivating compatible plugins one at a time.
Security, redirect, cache, membership, and login-customization plugins deserve early review. Check their settings for forced login pages, domain restrictions, cookie prefixes, login URL changes, and administrator access rules.
Keep a written change log. If the plugin isolation does not help, restore the original directory name before testing another layer. For a broader approach to login protection and recovery planning, see how to secure WordPress login without locking out legitimate administrators.
Clear every caching layer, not just the browser
A cached login response can make a corrected configuration appear broken. WordPress login pages and authenticated administrator responses should not pass through ordinary page caching. Yet several layers may cache or reuse redirect responses.
Check the browser, WordPress cache plugin, hosting cache, CDN, reverse proxy, and web server. Purge only the relevant site cache when possible. Avoid clearing unrelated customer or tenant caches on shared platforms.
Ask the host to verify that these paths bypass page caching:
/wp-login.php/wp-admin/- Requests from authenticated users
- Requests that set or receive WordPress authentication cookies
Review cache rules after purging. Otherwise, the loop may return when the cache repopulates. WordPress provides general guidance on evaluating plugins, caching, and site performance in its performance optimization documentation.
Use recovery access methods carefully
When normal login remains unavailable, recovery access can separate a website problem from an account problem. Use an existing hosting control panel, managed WordPress console, database access, or secure server access only when you are authorized and have a backup.
Prepare a rollback before editing
Record the current URL values, plugin states, rewrite rules, and proxy settings. Take a verified backup or snapshot according to the hosting platform’s process. A backup that has never been restored is not a complete recovery plan.
Use staging for plugin and theme tests. If production requires immediate action, make one reversible change, test it, and document the result. Do not disable all security controls indefinitely or create a new administrator with a shared password.
Separate authentication from redirect behavior
If another administrator can log in, compare roles and account-specific settings. If all accounts loop, investigate site-wide configuration. Review server logs, web application firewall events, and redirect chains when those records are available.
Database edits require extra care. Table prefixes vary, serialized settings can break when edited incorrectly, and a direct change may bypass application validation. Use a qualified administrator when the correct value or rollback path is unclear.
Confirm the repair with a small test plan
A working login on one browser is not enough. Test the canonical URL from a private window, a normal browser session, and a second device. Confirm that the browser remains on HTTPS and that the administrator dashboard loads after a fresh sign-in.
Next, test a second administrator if one exists. Check the public site, media access, plugin screens, and logout behavior. Review redirect responses and cache status if the hosting platform exposes them.
Finally, document the root cause and the change that resolved it. Note whether the issue came from a URL mismatch, cookie rejection, HTTPS detection, plugin conflict, or cache rule. This record can shorten the next incident and reduce risky trial-and-error.
A WordPress admin login redirect loop fix often requires coordination between WordPress, the browser, hosting, HTTPS, and caching layers. If you lack safe file, database, or hosting access, Tech Rescue Ops LLC can help isolate the fault remotely, preserve recovery access, and apply a documented rollback-aware repair.