WordPress keeps returning to login: fix the loop and blocked cookies

Recognize a login loop

You enter your credentials, the form reloads, and the dashboard does not open. Sometimes WordPress displays a cookie message; sometimes the browser reports too many redirects. These symptoms can block access even with a correct password. Repeating the same entry ten times does not distinguish their causes and may trigger an attempt limit.

Note the address shown before and after submitting the form. Check whether the domain, scheme, or path changes. Repeatedly switching between two addresses is a different clue from a form that simply stays at the same address. Keep the exact message and the time of the test.

If WordPress explicitly reports an incorrect password, follow account recovery first. If a one-time code is requested, you are at the two-factor authentication step. A page denying access because of permissions is another case. This guide mainly concerns a session that does not complete or is not retained.

Before touching cookies or configuration, preserve unsaved content in other tabs. A session still open on another device may also let you inspect settings: keep it available during diagnosis rather than immediately logging out every device.

Choose your troubleshooting path

Start with the browser if you are the only person affected and no site change preceded the problem. Compare another profile or browser, then clear only the necessary data. This quickly provides a clue without modifying production.

Move to URLs and HTTPS if the problem follows a migration, domain change, certificate installation, or addition of a proxy. Verify the intended arrangement before editing values. Different URLs can be intentional in some installations.

Finally, examine caching and components if the issue affects several accounts, follows an update, or depends on a custom form. Prepare a backup and, if possible, a test copy. From the moment it is created, this copy must use a separate database, with email, payments, and live integrations disabled before its first opening. Make one change at a time and repeat the same test so you can attribute the result to that change.

These three paths can overlap. For example, an address change corrected on the server may leave old cookies in the browser. Finish each correction with a clean login, without simultaneously accumulating changes to files, accounts, and security rules.

Approach 1: start with a clean browser context for this site

Open the site’s usual address in another browser profile, without using an old recovery link. For an independent installation, /wp-admin/ normally redirects to login when you are not logged in. If a custom login address was deliberately configured, use the one provided by the site administrator.

Try logging in once with your account. If it works in this new context, the site can at least create a session under these conditions. Return to the original browser and examine its data and extensions. The test does not prove that all other users have the same cause.

In Chrome, open the privacy and security settings, then look for data stored for the domain. Open Third-party cookies, then See all site data and permissions. Search for the affected domain, verify the entry, and remove its data after preserving your work. This action may log you out and erase local preferences.

Close old login tabs, reopen the official address, and try again. There is no need to erase every site’s data or saved passwords. If the domain recently changed, also examine the old domain, without indiscriminately deleting all your browser data.

Distinguish site cookies from third-party cookies

WordPress uses cookies to recognize a login between page loads. A test cookie also checks that the browser can receive the expected information. A visitor consent banner is not, by itself, the setting that determines whether the administrative session works.

For an independent installation opened directly on its domain, first check that the browser allows this site to store data. You do not need to allow all third-party cookies across the Web for this check. A company-managed rule may require intervention by its IT administrator.

Integrated services and some WordPress.com features can involve multiple domains. In that case, third-party cookie restrictions may play a part. An exception limited to the necessary sites may be appropriate if diagnosis confirms it. A private window is not definitive evidence: it may apply different restrictions and block third-party cookies by default.

If a browser extension affects login, compare its effect on this site alone. Keep the original setting and restore it after the test. The goal is to identify a specific block, not to leave all protections disabled because a test worked once.

Inspect cookies when the message remains unclear

For a more precise diagnosis, open the browser developer tools and Application → Storage → Cookies. Select the site’s domain. Look at names, domains, paths, and warning icons. If a cookie is missing, also check Network → the already recorded login request → Cookies: the warning may explain its rejection. Do not use Replay request for this inspection. You can record these characteristics without copying cookie values.

A cookie restricted to an unsuitable domain or path may not accompany the next request. A cookie reserved for a secure connection should not be treated as a way to maintain login over HTTP. If the browser explains why it rejects a cookie, send that reason to support along with the relevant address.

Do not change values to fabricate a session. WordPress verifies them, and they contain authentication information that must remain private. Do not post a complete browser export on a forum either. A cookie name, its attributes, and a sanitized screenshot are often enough to begin the analysis.

If cookies are present but login disappears immediately, continue on the server side. Their presence shows only that they were stored; it does not guarantee that WordPress accepts them or that they are sent to the correct address.

Approach 2: check the domain and both WordPress URLs

If another administrator still has a session, go to Settings, then General. Compare the WordPress Address and Site Address with the intended installation. Look for an old domain, test subdomain, or HTTP/HTTPS difference that no longer matches the hosting setup.

These two addresses are not necessarily identical. WordPress core may be in a subdirectory while the public site is served at the root. Removing that subdirectory to make the fields match can break a correct installation. Confirm the file layout and migration history before deciding which value to change.

If the dashboard is inaccessible, you can inspect configuration through hosting access. Identify the correct directory and keep a private copy of wp-config.php. When defined, the WP_HOME and WP_SITEURL constants can override the addresses WordPress uses. Do not add them a second time without reading existing definitions.

In a managed installation, these values may come from environment variables or a provider-supplied file. Correct the source actually in use. Changing the database while a constant still imposes the old address can make a correction appear to have been ignored.

Read and correct URLs with WP-CLI

With authorized SSH access and WP-CLI available, change to the correct installation directory. The commands below read the values WordPress obtains. Compare the result with the expected domain and the configuration constants. A value imposed by a filter or constant may differ from the one stored directly in the database.

Do not make a broad correction before establishing which value is wrong. Keep a database backup and the old addresses. If a constant or filter imposes a value, ask the host also to record home and siteurl from the affected site’s options table in a read-only check. The filtered WP-CLI output does not replace this evidence of the stored values for rollback. On multisite, have someone who knows the network explicitly select the target site: a command run without the correct context may affect another site.

wp option get home
wp option get siteurl

Apply a targeted, reversible URL correction

Once an incorrect stored value is confirmed, wp option update can change the affected option. The example below corrects only home; replace the example address with the one verified for your site. It does not instruct you to change siteurl automatically. If a constant imposes the value, have that constant corrected in its configuration rather than multiplying changes.

After the correction, open login at the expected address and try again with clean cookies for that domain. If the change worsens the issue, run the same command with its new URL replaced by the stored value recorded before the intervention, then reexamine the site’s arrangement. Do not restore the entire database to undo this one option. A targeted change should remain understandable and easy to reverse.

A full domain change may also require migrating links and serialized data. Do not replace every occurrence using an improvised SQL query. That operation goes beyond correcting two options and requires a migration method with a backup and a preview of replacements.

wp option update home 'https://votre-domaine.example'

Check HTTPS and server redirects

If the browser continually switches from HTTP to HTTPS, from www to a non-www address, or from one domain to another, record that path. The developer tools’ Network panel can show redirect responses and destinations. Share only necessary addresses, without parameters containing login tokens.

Have the host, proxy, and WordPress rules compared. Two layers may enforce conflicting destinations. The aim is a consistent final address with a valid certificate, then verification that the form and dashboard use it. Do not delete all server rules to remove a single misconfigured redirect.

With a proxy that terminates HTTPS, WordPress needs reliable information about the protocol used by the visitor. Incorrect forwarding can produce a loop. The correction depends on the actual server chain: have the provider configure headers, and do not trust a header arbitrarily supplied by a visitor.

Disabling HTTPS for the dashboard is not a login solution. If a certificate warning appears, do not bypass it or enter credentials before it is fixed. Keep credentials and cookies protected, then correct protocol detection and redirects. Afterwards, test access from the site’s normal address and from an old link users still use.

Record what the proxy and WordPress see

Open a private window and request the known HTTPS login address. In developer tools, preserve the Network log during loading. Record the status and Location header for the first hops. If the response repeatedly redirects to the same HTTPS address, also note whether the browser reaches the form. Two correct WordPress addresses are not enough to explain the protocol PHP receives.

When the proxy terminates TLS and connects to WordPress over HTTP, the browser sees an HTTPS connection, but the origin server must receive the external protocol from a reliable source. Check the canonical domain, home, and siteurl separately, then ask the maintainer what WordPress receives for a request from the proxy. If the addresses are already correct, compare the status with the value of is_ssl() on the test copy. Avoid replacing database URLs while the discrepancy concerns the request protocol.

The trusted proxy must overwrite the header received from the browser with the value it knows. The origin must also restrict access to the proxy or interpret that header only for the expected relay. A visitor-supplied https value does not demonstrate that the connection was encrypted.

Compare responses before and after HTTPS recognition

Diagnostic example to reproduce on a copy: home and siteurl use HTTPS, but a proxy terminates TLS and sends an HTTP request to PHP. If WordPress does not receive a reliable indication of the external protocol, it may request HTTPS again and create a loop. Compare the configured addresses, the result of is_ssl(), and the redirects actually observed. This scenario is a working hypothesis, not the result of a test of your infrastructure.

After correcting the trust chain, compare the same link and its statuses without changing the WordPress addresses at the same time. Also verify that a visitor cannot impose the protocol simply by sending their own header. The proxy must replace incoming information, and the origin must accept it only from the intended relay. The return of a form proves access to that page; login and session persistence still need separate verification.

To inspect a response without following its redirect, run the command below with the authorized public HTTPS address. On Windows, use curl.exe and replace /dev/null with NUL. Record the status and Location, then repeat only for a trusted destination. The command uses a GET request without cookies. It tests the login entry point, not session persistence. Keep full headers private because they may contain a cookie.

curl -q -sS --max-time 15 -D - -o /dev/null "https://recette.example.test/wp-login.php"

Correct the rule at the layer that knows the external protocol

With proxy access, first confirm which component terminates TLS. If Nginx receives encrypted traffic directly, proxy_set_header X-Forwarded-Proto $scheme; forwards its own protocol to the origin. With the maintainer, insert or correct this directive in the configuration already used for this site. Preserve the other headers in that block. When Nginx itself is behind another TLS relay, its $scheme variable may be http. In that case, have the protocol forwarded through the actual intended trust chain, starting with the first relay that knows the external scheme. Request a configuration check and retain the previous value before reloading the rule.

On a copy whose origin is reachable only through the expected proxy, the maintainer can enable HTTPS recognition in wp-config.php before WordPress loads. The snippet below assumes that the proxy replaces the header with a single value and that PHP sees the relay’s real address in REMOTE_ADDR. Replace the example address with the one verified on this copy. If the server rewrites REMOTE_ADDR to the visitor’s address, use the host’s trust mechanism instead of this snippet. Do not use a loopback address simply because it appears in a lab example: use the relay identity actually observed.

$trusted_proxies = ['192.0.2.10'];
if (in_array($_SERVER['REMOTE_ADDR'] ?? '', $trusted_proxies, true)
    && ($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '') === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Verify recovery and return to the previous setting

Repeat an HTTP request and an HTTPS request from a fresh session. The expected result is an HTTP redirect to the intended HTTPS URL, followed by the form without a return to HTTP. Then confirm login and dashboard loading in your own acceptance test. If this result is not achieved or another access path is disrupted, remove only the snippet or restore the saved proxy rule. Keep recovery access to the files before making the change.

Check cookie constants and multisite specifics

Look in the configuration for any definitions of COOKIE_DOMAIN, COOKIEPATH, SITECOOKIEPATH, and ADMIN_COOKIE_PATH. A value added for an old domain or layout may no longer be suitable. Their absence is not an anomaly: WordPress defines values itself when no override is supplied.

Do not automatically copy a cookie domain found in a tutorial. Sharing across subdomains, a multisite network, and several independent sites on one account are different situations. An overly broad rule may create interactions between installations that should not share login.

On multisite, have the network administrator check the domain associated with the site, the administrative path, and network settings. Part of the network may fail while the main site works. The correction must preserve other sites and account for the intended login mechanism.

If you remove or correct an override that is no longer useful, keep its previous value and reason for existing. Then repeat the test after removing the domain’s old browser data. Keeping cookies created before the correction can confuse interpretation of the result.

Approach 3: examine caching and login components

A cache intended for public pages must not indiscriminately serve a login or dashboard response to every visitor. Have the exclusions for the login page, administrative path, and authenticated sessions checked. A purge may remove an old response, but it does not fix a rule that will immediately cache it again.

Reconstruct recent changes: a login plugin, single sign-on, administrative URL change, role-based redirect, or security setting. Start with the component associated with the symptom. If the site uses an identity provider, also check the return to the correct address after login at that provider.

On a staging copy, deactivate the suspected component normally, test, then reactivate it before trying another. The copy must use its own database and a login configuration appropriate to its domain. A misconfigured copy may reproduce a different failure and lead to a wrong conclusion.

In production, deactivating an authentication component must be prepared with backup administrative access and a maintenance window. Do not disable single sign-on or two-factor authentication without knowing how users will log in. The repair must retain the intended level of protection once diagnosis is complete.

If you have lost all dashboard access

This procedure applies to an independent WordPress installation, an ordinary component identified through recent changes or logs, and authorized file manager or SFTP access. Back up files and the database, record the initial directory name, and plan a single login attempt. Do not try several directories at random.

If the component protects login or provides two-factor authentication or single sign-on, first prepare authorized local backup access and continued protection at hosting level. Without a planned alternative, perform the test on an isolated copy with its own database and external effects disabled. Do not create a public administrator account or a general exception to gain entry.

The expected result is a clue attributable to one component, with its directory preserved and its state documented. Reactivating the faulty component may close access again: it requires a verified correction and the same backup access. Must-use components, hosting cache, and network code use other locations; do not delete them to extend this test. On multisite, involve the network administrator to avoid affecting other sites.

1. In the file manager, select the correct domain and its WordPress root, then open the plugins directory, normally wp-content/plugins. If WP_CONTENT_DIR or WP_PLUGIN_DIR customizes this path, have the provider confirm its location. Do not assume that all account domains use the same public_html.
2. Rename only the suspected directory: for example, mon-extension becomes mon-extension.pause. This is an illustrative name to replace with the exact directory. Do not change the entire plugins directory or delete any files.
3. Try logging in at the official address. If access returns, open Plugins → Installed Plugins while the directory remains renamed: WordPress can detect its absence and deactivate the invalid entry.
4. In the file manager, restore the exact initial name. Return to Installed Plugins and check the component’s status before reactivating it; putting the directory back does not prove its previous activation has been restored.
5. If login still fails, undo the rename and continue diagnosis. If it works only without this component, leave the component deactivated while fixing its cause on a copy. Restore the intended protections before reopening normal access.

Read PHP errors and check session consistency

A message stating that headers have already been sent may indicate text output too early in processing. This output can interfere with cookies or redirects. The named file and line help locate a warning, code change, or accidentally added content.

Check the provider’s private logs at the time of the test. If temporary debugging is necessary, keep errors off public pages and protect the log file. Avoid modifying WordPress core to hide the message: fix the component or file producing the output, then verify the result.

On infrastructure distributed across multiple servers, a session that is accepted and then rejected may require checking configuration, authentication-key, and system-clock consistency. Have the infrastructure administrator perform this check. Simply changing WordPress’s display time zone does not correct the server’s time.

WordPress checks, among other things, the validity and expiration of authentication information. A visible cookie is therefore not proof of valid access. Do not artificially extend all sessions to hide immediate logouts, and never share their values on a forum or with an unauthorized contact.

Validate a lasting login after the correction

Open a new session, log in, and navigate between several dashboard screens. Save a small change to a draft and reopen it. Seeing the dashboard once is not enough if the next request already sends you back to the form.

Log out normally and check that the dashboard requires login again. Then log back in with the usual protections, including two-factor authentication where used. A successful test must not depend on a security exception left active solely for troubleshooting.

If multiple roles or network sites were affected, have representative paths verified using authorized accounts. Also compare the original browser after cleanup with the one used for diagnosis. Restore necessary components and remove temporary settings no longer needed by the correction.

Finally, record the identified cause and corrected value: an obsolete cookie domain, wrong address, cache rule, or conflicting redirect, for example. This record will be more useful at the next migration than a list of random deletions. The right outcome is a normal session, maintained during work and properly closed at logout.