A WordPress login redirect loop happens when you enter valid credentials but WordPress keeps sending you back to the login screen, redirects between addresses, or briefly loads wp-admin before returning to wp-login.php. It is frustrating because the visible symptom is simple, while the underlying cause can sit in browser cookies, site URLs, HTTPS handling, caching, a plugin, or server configuration.
Start with the smallest, reversible checks. If access is blocked on a live site or the issue involves a custom setup, WordPress bug fixing can help trace the actual cause without applying random changes across production.
What a WordPress login redirect loop usually means
WordPress needs to set and read authentication cookies after a successful login. It also needs to agree on the correct address for the site and admin area. If the browser receives a cookie for one host or protocol, but the next request goes to another, WordPress may treat you as not logged in and send you back to the login page.
For example, a site may appear to work at both http://example.com and https://www.example.com, while WordPress is configured for only one canonical version. A redirect layer, CDN, hosting proxy, or security plugin can then move requests between versions. The login cookie may not follow the visitor to the final address.
A loop does not automatically mean that your password is wrong or that WordPress itself is damaged. It means the login state is not being retained or the destination URL is being redirected in a way that prevents a stable authenticated request.
Common signs of this problem
- You submit the login form and immediately return to the same login page.
- The browser address changes between HTTP and HTTPS, with or without www.
- You can log in briefly, but visiting the Dashboard returns you to wp-login.php.
- The problem affects one browser or device but not another.
- The front end works normally while wp-admin remains inaccessible.
- A redirect message appears, such as “too many redirects.”
The scope is useful evidence. If only one person is affected, local browser data or an extension is more likely. If every administrator has the same problem, look more closely at site URLs, caching, SSL, plugins, or server-level redirects.
Check the login URL and site address first
Use one consistent URL when testing. Choose the version the site is meant to use, such as https://example.com/wp-login.php, and avoid switching manually between HTTP and HTTPS or between www and non-www forms.
If you can access WordPress settings through another administrator account, confirm that the WordPress Address (URL) and Site Address (URL) use the intended canonical domain and protocol. These values should normally align with the public address visitors use.
Do not change these settings casually on a live site if you are uncertain about the expected domain, a staging environment, or a reverse-proxy setup. An incorrect URL can make both the front end and admin area harder to reach. Record the current values before changing anything.
Clear the right browser data
Old or conflicting cookies are one of the least risky explanations for a WordPress login redirect loop. A standard browser cache clear may not remove the relevant authentication cookies, so test deliberately:
- Open a private or incognito browser window.
- Visit the canonical HTTPS login URL directly.
- Try logging in once without browser extensions that modify privacy, cookies, redirects, or scripts.
- If the private-window test works, clear cookies for the affected domain in the usual browser profile.
Do not repeatedly submit the form while testing different URLs. That can make it difficult to tell whether a change helped, and it may trigger rate-limiting rules on sites with login security controls.
Look for HTTP, HTTPS, and domain mismatches
Login loops often originate from competing redirects. Common examples include:
- The host forces HTTPS while WordPress still believes the site uses HTTP.
- A CDN or proxy handles HTTPS externally, but the origin server sees requests as HTTP.
- A redirect rule adds www while WordPress is configured without it, or the reverse.
- A migration left old domain values in configuration, the database, or a caching layer.
In a correctly configured setup, a request should settle on one public URL before the login cookie is created. If the request bounces between variants, resolve the canonical URL and proxy behavior before trying unrelated plugin changes.
Sites behind a load balancer, CDN, or managed hosting proxy may need the server to pass the original HTTPS status correctly to WordPress. This is a technical configuration detail, and changing proxy-related code without understanding the hosting environment can create broader redirect problems.
Temporarily rule out cache and optimization interference
Login and admin requests should not be served as public cached pages. A cache layer that stores or alters redirect responses can cause confusing behavior, especially after a configuration change.
Check whether a page cache, CDN, host cache, or optimization tool is active. Purge relevant caches, then test in a private window. Ensure that wp-login.php, wp-admin, and authenticated users are excluded from public caching according to the tool’s documentation.
Be careful not to disable every performance feature at once. Make one controlled change, test the login flow, and note the outcome. That creates a useful trail if the issue needs deeper investigation.
Security, login customisation, membership, multilingual, redirection, cookie-consent, and caching plugins can all influence authentication requests. A plugin may not be defective on its own; it may conflict with another layer or with a server rule.
If you have safe file access and a backup, a controlled test can help isolate a plugin. Rather than deleting anything, temporarily deactivate the suspected plugin through the normal admin interface when possible. If wp-admin is unavailable, an experienced administrator may rename the specific plugin directory over SFTP or through the hosting file manager, then retest. Rename it back immediately if the result is unchanged.
Avoid disabling all plugins on an active store, membership site, or lead-generation site without considering the business impact. Payment, security, forms, and integrations may rely on those plugins. A targeted test is safer and more informative.
Review custom login and redirect code
Custom code can change where users land after logging in, restrict dashboard access by role, or redirect users based on session data. A faulty rule in a theme, a must-use plugin, a snippets plugin, or custom server configuration can create a loop even when WordPress authentication succeeds.
Useful clues include a loop that affects only a particular user role, starts after a custom change, or occurs only on a specific admin page. Review recent additions involving login hooks, redirect filters, URL rewriting, cookie domains, or access restrictions. If there is a staging environment, reproduce the behavior there before editing production code.
A safe troubleshooting sequence
- Capture the symptom: note the exact login URL, final URL, browser message, affected accounts, and when the loop began.
- Test privately: use an incognito window and the canonical HTTPS address.
- Confirm scope: test a second browser or administrator account if appropriate.
- Check URL consistency: compare WordPress URL settings, public redirects, and the intended domain.
- Purge caches: clear the relevant cache layers and confirm login routes are excluded.
- Isolate one variable: test the most likely login, security, cache, or redirect plugin without deleting it.
- Review environment changes: include CDN settings, SSL renewals, DNS changes, hosting migrations, and custom code deployments.
This sequence is designed to preserve evidence. The goal is not to make the loop disappear temporarily; it is to identify why authentication fails to persist so the fix remains stable.
When to get technical help
Seek help promptly when all administrators are locked out, the loop affects a live sales or membership workflow, the site redirects between domains, or you are unsure how hosting, SSL, and a proxy interact. It is also sensible to stop and investigate when a workaround appears to help but the underlying redirects remain inconsistent.
Provide the site URL, the exact path that loops, when it started, recent changes, screenshots of the browser behavior, and details of any CDN, cache, security, or login plugins. Clear information reduces guesswork and helps isolate the responsible layer faster.
Need help with a WordPress bug?
A login loop can look like a minor access issue, but it can involve several systems at once. If the safe checks above do not resolve it, professional troubleshooting can verify the redirect chain, cookie behavior, WordPress configuration, plugin interactions, and server response before applying a focused fix.
FAQ
Can incorrect login details cause a redirect loop?
Incorrect credentials usually produce a login error rather than a redirect loop. A loop after apparently successful submission more often points to cookies, URL mismatches, cache behavior, redirects, or code that changes the destination.
Why does the WordPress login redirect loop happen in only one browser?
Browser-specific cookies, extensions, privacy settings, or cached redirect data may be involved. A private-window test is a quick way to separate a local browser issue from a site-wide problem.
Should I change my WordPress site URL in the database?
Only if you have confirmed the correct intended URL and understand the recovery process. Direct database edits can help in specific cases, but an incorrect value can worsen access problems. Check configuration and hosting redirects first.
Can a CDN cause a WordPress login loop?
Yes. A CDN or proxy can contribute if it caches login-related responses, redirects traffic inconsistently, or does not communicate the original HTTPS request correctly to the origin server.