How to Fix a WooCommerce Admin Login or Redirect Loop

If signing in returns you to the login screen, first clear cookies for the site and try a private browser window. If the WordPress Dashboard opens but specific WooCommerce pages keep redirecting or reloading, skip to the plugin and theme conflict checks. A core login loop and a redirect limited to WooCommerce admin screens can have different causes.

Before changing plugins, themes, or URLs, take a database backup and record which plugins and theme are active. Run conflict tests on a staging site when possible, especially if the store is accepting orders.

Identify where the loop starts

Open the login page directly:

https://example.com/wp-login.php

Then note what happens:

• The login page reloads after you submit credentials: Check cookies, caches, WordPress URLs, and HTTPS configuration.
• WordPress Dashboard opens, but WooCommerce pages loop: Check WooCommerce extensions, other plugins, the active theme, and cached admin requests.
• The browser reports too many redirects: Look for conflicting redirects at the hosting, CDN, security plugin, and web-server levels.
• Only one browser is affected: Stored cookies, browser cache, or an extension may be involved.

An incorrect-password message points to an authentication problem. Returning to the login screen without that message can instead involve cookies, caching, URL configuration, or redirects, but it does not prove that the password was accepted.

Clear cookies and every cache layer

Delete cookies for the affected domain, close the browser, and sign in again through the direct wp-login.php URL. A private window is a quick way to check whether stored browser data is involved.

Next, purge any cache provided by:

• A WordPress caching or optimization plugin
• Your hosting control panel
• A reverse proxy or CDN
• A persistent object-cache service such as Redis

Do not cache /wp-admin/ or /wp-login.php. If your CDN or host has custom cache rules, temporarily bypass caching for those paths.

If WP-CLI is available, you can flush the WordPress object cache:

wp cache flush

This command only clears the object cache. It does not purge a CDN, hosting page cache, or browser cache. On multisite, it may affect the object cache for every site, as noted in the wp cache flush documentation.

Check the WordPress URLs

Inconsistent WordPress Address and Site Address values can contribute to login and redirect problems. Common issues include:

• One URL uses http:// and the other uses https://
• One URL contains www and the other does not
• The domain still points to a staging or previous address
• A subdirectory is missing or incorrect

Check both values with WP-CLI:

wp option get home
wp option get siteurl

For a standard installation at the domain root, the values normally match exactly:

https://example.com

The official WordPress URL guidance explains what each setting controls. Both values should include the URL scheme and omit the trailing slash.

If either value is wrong, back up the database and correct it:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Replace the example address with the store's real canonical URL. These commands change database settings, so verify the domain and HTTPS status before running them.

Also inspect wp-config.php for hard-coded values:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Constants in wp-config.php override the database values. Correct or remove them if they contain an old or inconsistent address.

Check HTTPS and proxy redirects

A loop can occur when WordPress believes a request is HTTP while a proxy, load balancer, or CDN keeps redirecting it to HTTPS.

Confirm that:

• The SSL certificate is valid for the active domain.
• WordPress, the host, and the CDN all agree on the canonical HTTPS URL.
• Only one layer is responsible for redirecting HTTP to HTTPS.
• A security or redirect plugin is not sending /wp-admin/ to another hostname.
• The CDN's SSL mode is compatible with HTTPS between the CDN and origin server.

Do not disable HTTPS on a live store as a troubleshooting shortcut. It can expose login credentials and create mixed-content or cookie problems. Ask the host to inspect forwarded HTTPS headers when the site runs behind a proxy.

Test for a plugin conflict

If the loop started after an update or only affects WooCommerce screens, temporarily deactivate plugins added or updated around the same time. Start with security, redirect, caching, membership, multilingual, and WooCommerce extension plugins.

With WP-CLI:

wp plugin deactivate plugin-slug

Test the same login or WooCommerce page after each change. The wp plugin deactivate command does not uninstall the plugin or delete its files.

If checking plugins individually does not reveal the cause, perform a controlled conflict test:

1. Keep WooCommerce active.
2. Deactivate other plugins.
3. Test the affected admin page.
4. Reactivate plugins one at a time until the loop returns.

WooCommerce recommends this isolation process in its plugin and theme conflict testing guide. On a live store, use staging or schedule maintenance because deactivating payment, shipping, subscription, or membership extensions can interrupt store functions.

Once the conflicting plugin is identified, leave it deactivated, restore the others, and check for an update or contact its developer.

Test the active theme

A theme or bundled framework can alter authentication, account redirects, or WooCommerce admin behavior. Temporarily switch to an installed default WordPress theme:

wp theme activate twentytwentyfive

Use the slug of a default theme that is actually installed. The WP-CLI theme command changes the active theme immediately.

If the loop stops, restore the original theme after testing and check its redirect code, WooCommerce overrides, and available updates. Send the theme developer the exact URL that loops and the steps needed to trigger it.

Capture the error behind the redirect

When the loop persists with other plugins disabled and a default theme active, you can enable file logging temporarily in wp-config.php.

Before editing the file, make a backup and search for existing WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY definitions. Record their original values. Do not add duplicate definitions; update the existing lines instead.

If those constants are not already present, add them above the line that says /* That's all, stop editing! Happy publishing. */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Trigger the loop once, then inspect wp-content/debug.log for a fatal error or warning tied to a plugin, theme, or custom code. WordPress documents these settings in its debugging guide.

When finished, restore the original debug definitions exactly as you found them. If you added new definitions solely for troubleshooting, remove those lines rather than adding another WP_DEBUG definition.

Do not publish the debug log or leave it publicly accessible. It may contain private server, plugin, or request information.

Restore the store carefully

After finding the cause, restore the original theme and reactivate required plugins one at a time. Clear the relevant caches again, then verify:

• WordPress login and logout
• WooCommerce Home and Analytics
• Order editing
• Cart and checkout
• Customer account login
• Scheduled or subscription features used by the store

If a plugin or theme update introduced the loop, restore the previous known-good version from your backup rather than replacing individual files manually. Keep the conflicting component disabled until an update or documented fix is available.