WordPress Login Keeps Redirecting Back to the Login Page—How to Fix It

You enter the correct WordPress username and password, the page refreshes, and you land back on the login screen. Sometimes there is no message at all. In other cases, the browser reports too many redirects or the dashboard opens briefly before sending you out again.

This is usually not a password problem. A successful WordPress login depends on the browser accepting an authentication cookie and returning it to the same domain, scheme and path that WordPress expects. A mismatch anywhere in that chain can make valid credentials look as if they failed.

The safest fix is to identify which layer loses the session. Work through the checks below in order instead of changing the database, disabling security controls and deleting files at the same time.

First, identify the exact failure pattern

Before changing anything, repeat the login once in a private browser window and note what happens. This creates a cleaner test because most extensions, old cookies and cached redirects are removed from the path.

• The form simply reloads with no error: suspect a cookie, domain or cache mismatch.

• The address alternates between HTTP and HTTPS: suspect URL or reverse-proxy configuration.

• The browser reports too many redirects: map every redirect before changing WordPress.

• One browser works and another fails: compare cookies, extensions and privacy settings.

• Every administrator is affected: investigate site-wide configuration, plugins, caching and server sessions.

• Only one account fails: check that user, password reset, role and security-plugin rules.

Record the login URL, the final URL, the time of the test and whether the response sets a WordPress authentication cookie. Those details make later server-log checks far more useful.

1. Test whether the browser can keep the WordPress cookie

WordPress uses authentication cookies to recognize logged-in users. Clear cookies only for the affected domain, close the tab, then open the exact canonical login URL directly. Avoid testing through an old bookmark until the canonical address is confirmed.

1. Open a private window with extensions disabled where possible.

2. Visit the final HTTPS hostname, for example https://example.com/wp-login.php.

3. Confirm cookies are allowed for the site.

4. Log in once and inspect the browser’s Application or Storage panel.

5. Check whether a wordpress_sec or wordpress_logged_in cookie is created and survives the redirect.

If the cookie is never created, inspect the login response and security headers. If it is created but disappears or is not returned, compare its domain, path, Secure and SameSite attributes with the URL being requested.

If the problem occurs in only one browser, use Webcurry’s Chrome-versus-Safari troubleshooting workflow to separate browser storage from a site-wide failure.

2. Make the public hostname and protocol consistent

A common loop begins when WordPress thinks the site uses one address while the visitor uses another. Typical mismatches include www versus non-www, HTTP versus HTTPS, a subdirectory versus the domain root, or an old staging hostname left after migration.

Compare WordPress Address and Site Address with WP_SITEURL and WP_HOME in wp-config.php. If constants are defined, they override the corresponding database values while they remain in the file. Use the exact intended scheme, hostname and path, with no accidental trailing slash.

Do not change both values blindly. WordPress Address identifies where the core files live; Site Address identifies the public address visitors use. They are often identical, but a deliberate subdirectory installation can be different.

If this began after a move, also follow the post-migration 404 recovery checks because stale URLs and incomplete search-and-replace operations often appear together.

3. Trace the complete redirect chain

Open the browser Network panel, preserve the log and submit the login form. Follow each 301, 302, 307 or 308 response. Write the chain as a sequence of hostnames and protocols. A loop becomes much easier to diagnose when you can see exactly which layer sends each redirect.

• WordPress or a plugin redirects the login request.

• The web server redirects HTTP to HTTPS.

• The host’s control panel forces a preferred domain.

• A CDN or proxy applies its own HTTPS or hostname rule.

• A security service rewrites wp-login.php or wp-admin.

• A cached redirect survives after the configuration was corrected.

Keep one component responsible for each decision. For example, choose a single canonical-host redirect and a single HTTPS policy. Multiple layers can agree, but they should not translate the request back and forth.

When visitors continue receiving an earlier redirect after the settings change, use the website-cache diagnosis guide to distinguish browser, CDN, server and service-worker caches.

4. Check HTTPS awareness behind a proxy or CDN

A reverse proxy can terminate HTTPS before forwarding the request to the origin over HTTP. If the origin does not receive or trust the forwarded protocol correctly, WordPress may believe the request is insecure and redirect it to HTTPS—even though the visitor is already using HTTPS. The proxy then repeats the process.

Compare the browser request with the headers received by the origin. Confirm that the host or proxy passes the expected forwarded-protocol information and that the server is configured to interpret it safely. Avoid copying generic proxy snippets without checking how your hosting stack handles trusted proxies.

If the browser also reports insecure assets or unexpected certificate behavior, work through the SSL-installed-but-not-secure diagnostic before adding more redirect rules.

5. Isolate plugins without losing their settings

Security, login-customization, membership, caching, multilingual and SSL plugins can all alter authentication or redirects. If the loop started after an update or configuration change, begin with the most likely component rather than disabling everything permanently.

When the dashboard is inaccessible, use the hosting file manager or SFTP to rename one suspected plugin directory. If there is no clear suspect, temporarily rename the plugins directory, test once, restore its original name and reactivate plugins methodically. Renaming preserves the files and normally preserves settings.

Do not leave protection disabled longer than the controlled test requires. If disabling a plugin resolves the loop, reproduce the result, capture its version and relevant settings, then update, reconfigure, replace or escalate that component.

For an evidence-based isolation sequence, follow Webcurry’s plugin-related slowdown workflow; the same one-change-at-a-time discipline prevents false conclusions here.

6. Rule out object cache and server-session failures

A persistent object cache can retain stale options or session-related data after a domain, HTTPS or plugin change. Purge the object cache, page cache and CDN cache through their normal controls, then test with one fresh browser session.

Also check whether the server can write session files, whether disk space or inode limits are exhausted, and whether requests are switching unpredictably between origins with inconsistent configuration. On a multi-server setup, confirm all nodes share the required keys, configuration and cache state.

A slow or unstable dashboard can signal the same underlying resource problem. The slow WordPress admin diagnostic explains how to correlate PHP workers, database delays and background tasks.

7. Verify WordPress security keys only when evidence points there

WordPress salts and authentication keys help sign cookies. Changing them invalidates every active login session. That can be useful after a security incident, but it is not a routine first step for a redirect loop.

Check for inconsistent wp-config.php files across servers, incomplete deployments or recent environment changes. If you intentionally rotate keys, expect every user to log in again and perform the change during a controlled maintenance window.

What not to do

• Do not reinstall WordPress before proving that core files are damaged; login loops are usually configuration or session problems.

• Do not edit serialized database values with a plain text replacement.

• Do not leave the RELOCATE constant enabled after using it for a controlled URL repair.

• Do not stack new redirect rules on top of an uncharted redirect chain.

• Do not disable every security layer and declare success without identifying the responsible rule.

• Do not test through a cached bookmark, old staging URL or different hostname.

If core-file integrity really is in doubt, use the safe WordPress reinstallation guide so content, media and configuration stay protected.

How to confirm the fix

1. Clear site-specific cookies and begin with a new private session.

2. Log in through the canonical HTTPS URL.

3. Confirm the response sets the expected authentication cookies.

4. Verify the redirect finishes at wp-admin without changing hostname or protocol.

5. Open several admin pages and wait long enough to prove the session persists.

6. Repeat the test in a second browser and on another network.

7. Re-enable any temporarily disabled plugin or cache one at a time.

8. Check server, CDN and security logs for fresh redirects or blocked requests.

The fix is complete only when the session survives normal navigation and the underlying mismatch has been removed. A one-time successful login after clearing cookies is evidence, but it is not proof that a proxy, cache or plugin conflict is resolved.

What to send your host or developer

Provide the canonical login URL, redirect chain, timestamps with time zone, affected browsers, recent changes, cookie observations, plugin-isolation result and any request or security-event IDs. Ask them to compare the browser’s HTTPS request with the protocol and hostname seen by the origin.

If you want a structured review rather than more trial-and-error changes, contact Webcurry for a WordPress troubleshooting audit.

The practical takeaway

A WordPress login redirect loop is a broken agreement between the browser, WordPress and the delivery stack. Start with the cookie, align the canonical URL, trace every redirect, verify proxy HTTPS awareness, and isolate plugins and caches one controlled change at a time. That sequence finds the failed layer while protecting the database, content and security configuration.