Redirect loops are one of the more disorienting errors you can run into. The page keeps bouncing, the browser gives up, and nothing you click seems to help. If your server config looks clean and your CDN rules check out, the culprit is often sitting much closer to home: your browser cookies or cached data.

This guide covers exactly how cookies and cache trigger redirect errors, how to clear them correctly at every layer, and how to make sure the problem stays fixed.

What Is a Cookie Redirect Loop and Why Does It Happen?

When you visit a website, your browser stores small pieces of data called cookies. These hold things like your login state, preferences, and session information. They help the site recognize you on your next visit and route you to the right page.

The problem is that cookies can become corrupted, outdated, or mismatched, particularly after a site migration, an HTTP to HTTPS switch, or a domain change. When that happens, the cookie instructs your browser to follow a redirect path that no longer exists or points back to itself, creating a loop the browser cannot escape.

Cache works similarly. Your browser, your server, and your CDN all store copies of pages to serve them faster. If a broken redirect response gets cached at any of these layers, it keeps getting served even after the underlying issue has been fixed.

The key thing to understand: a redirect loop caused by cookies or cache is often a local issue. You might be stuck in a loop while everyone else on the same site loads it just fine.

Step 1: Test the Redirect in a Private Window

Before clearing anything, open the problem URL in an incognito or private browser window. This bypasses both your stored cookies and your local browser cache in one move.

• If the page loads fine in incognito: the issue is local. Your cookies or browser cache are the cause.
• If the page still loops in a private window: the problem is probably not limited to cookies or cache stored in your normal browser profile. Test another browser or device and then inspect the site’s application, redirect, CDN, and server configuration.

This single test tells you exactly where to focus and saves a lot of time.

Pro Tip: Test in a completely different browser too (e.g., if you normally use Chrome, try Firefox). If it loads there, Chrome’s stored data is definitely the issue.

Step 2: Clear Cookies for the Specific Site

The fastest first fix is deleting cookies for just the problem domain, not your entire browser history. This resets your session with that site without disrupting anything else.

Google Chrome:

1. Go to Settings > Privacy and security > Third-party cookies.
2. Scroll to See all site data and permissions.
3. Search for the domain, click the trash icon.

Mozilla Firefox:

1. Settings > Privacy & Security
2. Under Cookies and Site Data, click Manage Data.
3. Find the domain, select it, and click Remove Selected.

Safari:

1. Safari > Settings > Privacy.
2. Click Manage Website Data, find the site, and click Remove.

After clearing, do a hard refresh with Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (Mac) and test the URL again.

Step 3: Clear the Browser Cache

If clearing site-specific cookies didn’t resolve the loop, the next step is your full browser cache. Cache and cookies are different things: cookies store session and identity data, while cache stores page assets like HTML, images, and scripts. A previously cached HTTP redirect response or other stale browser data can continue sending the browser to the wrong URL even after the site’s configuration has changed.

• Chrome: Settings > Privacy and security > Delete browsing data > check Cached images and files > set time range to All time > Delete data.
• Firefox: Options > Privacy & Security > Clear Data > uncheck cookies, leave cached files checked > Clear.
• Safari: Develop menu (enable it under Advanced settings) > Empty Caches.

Pro Tip: You can also force a cache-bypass refresh without clearing everything. Use Ctrl+F5 on Windows or Cmd+Shift+R on Mac to reload the page while skipping the local cache.

Step 4: Clear Your WordPress or CMS Cache

If you manage a WordPress site and the error is affecting visitors or you cannot access the admin dashboard, the issue may be a stale cached redirect response baked into your caching plugin.

Common plugin steps:

• WP Super Cache: Settings > WP Super Cache > Delete Cache
• W3 Total Cache: Performance > Purge All Caches
• WP Rocket: WP Rocket toolbar > Clear Cache
• LiteSpeed Cache: LiteSpeed Cache > Purge All

If the redirect loop has locked you out of the WordPress dashboard entirely, most hosting providers offer a one-click cache purge directly in the control panel. On HostArmada, for example, you can purge the cache from your hosting dashboard without needing admin access to WordPress at all.

Step 5: Purge the Server or CDN Page Cache

Browser and plugin cache are user-facing. The web server itself can also cache redirect responses, and if a broken 301 or 302 got cached at this layer, it overrides everything else.

(Warning: Do not run broad cache-deletion commands on a production server unless you understand exactly what data they remove. Object caches such as Redis may contain application data that is unrelated to HTTP redirects.)

If the redirect loop also appears in a private window, check the caching layer that can actually store HTTP responses, such as LiteSpeed, NGINX FastCGI cache, Varnish, or your CDN. Purge the relevant page or reverse-proxy cache using your hosting control panel or provider-specific tools. PHP OPcache and Redis object cache are different systems and should not be cleared as generic redirect-loop fixes.

After clearing server cache, visit key pages on the site and trace through the main redirect paths to confirm the loop is gone.

How WordPress Authentication Cookies Cause Login Redirect Loops

There’s a specific variation of this error worth calling out: the WordPress admin login loop. This is when you enter your credentials correctly, get redirected back to the login screen, and the cycle repeats.

WordPress uses several authentication cookies. wordpress_[hash] is used for authentication in non-HTTPS contexts, wordpress_sec_[hash] is used for secure HTTPS authentication, and wordpress_logged_in_[hash] identifies the logged-in user on the front end. If these cookies become invalid, typically after a URL change, a migration, or an SSL switch, WordPress cannot verify your session and keeps bouncing you back to the login page.

The most common fix is to make sure WP_HOME and WP_SITEURL in wp-config.php match the current live URL exactly:

php

define(‘WP_HOME’, ‘https://yourdomain.com’);

define(‘WP_SITEURL’, ‘https://yourdomain.com’);

Also verify that WordPress is not being forced to one URL format while the web server or CDN redirects visitors to another, because competing canonicalization rules can create a loop even when the WordPress values themselves are correct.

A mismatch here (like one being HTTP and the other HTTPS, or one having www and the other not) means cookies set under one URL are not recognized under the other, triggering the loop.

After updating wp-config.php, clear your browser cookies for the site and try logging in again.

Pro Tip: If you specifically need to invalidate all existing WordPress authentication cookies, regenerating the site’s security keys and salts will force existing sessions to become invalid. A domain change by itself does not normally require rotating the salts. You can generate new ones at api.wordpress.org/secret-key/1.1/salt and replace the corresponding lines in wp-config.php.

How PHP Sessions Can Interfere With WordPress Caching

This is a less visible but frustratingly common issue in WordPress environments. Some plugins and themes use PHP sessions (via session_start()) rather than WordPress’s native cookie-based authentication. When a PHP session starts, PHP typically uses a session identifier such as PHPSESSID. Once the browser has a valid session cookie, that identifier normally persists across subsequent requests rather than being regenerated on every request.

PHP session cookies can complicate full-page caching because many caching configurations bypass cached pages when a session cookie is present. Whether this creates a problem depends on the plugin and caching configuration.

To check if a plugin is the culprit:

1. Deactivate all plugins via the WordPress dashboard (or rename the /wp-content/plugins/ folder via FTP if you’re locked out).
2. Test whether the redirect loop clears.
3. If it does, reactivate plugins one by one until the loop returns.

The offending plugin is the one that triggers the error when reactivated. Either find an alternative or contact the developer.

Pro Tip: If you’re a developer building plugins, avoid session_start() entirely. For WordPress development, avoid introducing PHP sessions unless they are genuinely necessary. Use the WordPress storage mechanism appropriate to the data, such as user metadata, transients, or a purpose-built custom table.

Cookie Domain Mismatches Across Subdomains and www URLs

Cookie scope depends on the Domain attribute. If no Domain attribute is specified, the cookie is host-only and is returned only to the host that created it. If Domain=example.com is specified, the cookie can also be sent to subdomains such as www.example.com and app.example.com. Redirecting between hosts with incompatible cookie scopes can break authentication and contribute to redirect loops.

The same applies to subdomains. A session cookie set on app.example.com will not be sent to www.example.com unless the cookie domain is explicitly set to cover all subdomains.

Fix in PHP configuration:

php

ini_set(‘session.cookie_domain’, ‘example.com’); // Note the leading dot

session_start();

For WordPress specifically, ensure your siteurl and home options in the database match exactly, including the www or non-www format you’ve committed to. A mismatch at this level creates a permanent redirect between the two versions, and if cookies are set on one but not the other, the loop never ends.

SameSite Cookie Attribute and External Redirect Loops

If users only hit the redirect loop when arriving from an external link, a social share, or an OAuth/SSO login flow, the SameSite cookie attribute may be blocking the session cookie from being sent.

When SameSite is set to Strict, the browser will not send the cookie on any request that originates from a different domain, including redirects from external sites. This means the session is never established, and the site keeps trying to re-authenticate in a loop.

Setting it to Lax resolves this in most cases:

php

ini_set(‘session.cookie_samesite’, ‘Lax’);

session_start();

Lax allows the cookie to be sent on top-level navigation (clicking a link, following a redirect) from external sites, while still blocking it on cross-site subresource requests.

Do not change SameSite settings blindly. Some authentication flows that require cookies on cross-site requests may need SameSite=None; Secure, while many normal top-level GET navigations work correctly with Lax. Confirm the requirements of the authentication provider before changing this attribute.

Quick Diagnosis: Is the Loop Local or Global?

Before spending time on server-side fixes, confirm how widespread the issue actually is.

Use a redirect chain tracer (tools like httpstatus.io or the Redirect Path Chrome extension) to visualize the full redirect path and pinpoint exactly where the loop occurs.

Tip: If the problem affects more than one browser or device, inspect the redirect chain before clearing additional caches. Look for repeated transitions between HTTP and HTTPS, www and non-www URLs, login and account pages, or two different redirect rules that point at each other. A redirect trace can distinguish a browser-side issue from an application or server configuration problem.

Preventing Cookie and Cache Redirect Loops

A few habits prevent most of these issues from ever surfacing:

Commit to One URL Format

Pick www or non-www, HTTP or HTTPS, and configure everything (WordPress settings, server redirects, cookies) around that one canonical form. Mixing formats is the most common cause of cookie scope errors.

Purge Cache After Every Redirect Rule Change

Any change to .htaccess, Nginx config, or plugin redirect settings should be followed immediately by a full cache purge at browser, plugin, and server level.

Test With a Clean Session

After making changes, always test in incognito with cookies cleared so you’re seeing the live state of the site, not a cached version.

Avoid PHP Sessions in WordPress Plugins

If you’re evaluating plugins or building your own, flag any use of session_start() as a potential caching conflict.

Use Short TTLs on Redirect Responses

Setting a short cache expiry (or Cache-Control: no-store) on 301/302 responses means stale redirect instructions expire quickly if something changes.

FAQs