Login Redirect Loop in WordPress

What "login redirect loop" actually means

You enter your username and password at /wp-login.php. Credentials are correct. WordPress sets the auth cookie. Browser tries to navigate to /wp-admin/. WordPress checks the cookie, fails to validate it, redirects back to /wp-login.php.

You enter credentials again. Same outcome. Infinite loop.

The cause is always that WordPress can't read or trust the cookie it just set. This article walks through the six reasons that happens.

Cause 1 — Wrong site URL after migration

You migrated WordPress to a new domain. The database still has the old URL in siteurl or home options.

Diagnose

wp option get siteurl
wp option get home

If these don't match the current domain, you found it.

Fix

wp option update siteurl https://newdomain.com
wp option update home https://newdomain.com

For URLs in post content:

wp search-replace 'http://olddomain.com' 'https://newdomain.com' --all-tables

Cause 2 — Site URL has wrong protocol (http vs https)

Your site is on HTTPS but siteurl says http://. WordPress sends cookie for the HTTPS context, browser presents it back, WordPress checks against HTTP context.

Diagnose

Browser DevTools → Application → Cookies. Look at the wordpress_logged_in_* cookie. Note the domain and "Secure" flag.

If Secure: true but URL is http://, mismatch.

Fix

wp option update siteurl https://yoursite.com
wp option update home https://yoursite.com

Cause 3 — Multiple subdomain or subdirectory installs interfering

You have wordpress.com/site1 and wordpress.com/site2. Cookies from site1 conflict with site2.

Diagnose

wp option get cookie_path
wp option get cookie_domain

If empty and you have multiple installs, conflict possible.

Fix

In wp-config.php:

define('COOKIE_DOMAIN', '.yoursite.com');
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');
define('ADMIN_COOKIE_PATH', '/wp-admin');

Adjust paths to match your install structure.

Cause 4 — Server time wildly wrong

WordPress's auth cookies have expiration timestamps based on server time. If server time is hours off, the cookie can be "expired" the moment it's set.

Diagnose

date

If wildly different from current actual time:

timedatectl

Check timezone and synced status.

Fix

timedatectl set-timezone UTC
timedatectl set-ntp on

Cause 5 — Plugin redirects after login

A plugin (Membership, Course, custom login plugin) has a wp_login hook that redirects users somewhere — but the redirect destination requires login that hasn't completed setting cookies yet.

Diagnose

grep -rE "add_action\s*\(\s*['"]wp_login['"]" wp-content/plugins/
grep -rE "wp_redirect|wp_safe_redirect" wp-content/plugins/ | grep -i login

Look for plugins hooking into wp_login or login_redirect filters.

Fix

Temporarily disable plugins:

# Disable all except WordPress core
mv wp-content/plugins wp-content/plugins-disabled
mkdir wp-content/plugins

# Try login

If login works, plugin conflict confirmed. Re-enable plugins one at a time to identify.

Cause 6 — Cloudflare or proxy stripping cookies

Cloudflare, Cloudflare Access, AWS ALB, or other reverse proxies sometimes strip or modify cookies. If your Cache Level: Cache Everything rule covers /wp-login.php, Cloudflare may serve cached responses without setting cookies.

Diagnose

curl -I https://yoursite.com/wp-login.php

Look for cf-cache-status: HIT on /wp-login.php — that's wrong, login should never be cached.

Fix

In Cloudflare → Cache Rules:

Add bypass rule: when URI Path contains "/wp-login.php" OR URI Path contains "/wp-admin" → Cache Status: Bypass

Or via Page Rule: *yoursite.com/wp-admin/* → Cache Level: Bypass.

The diagnostic flow

1. Open browser DevTools → Application → Cookies
2. Submit login at /wp-login.php
3. Watch which cookies get set, with what domain/path/secure flag
4. Watch the redirect chain in Network tab

If no cookies set: server-side issue (cookie_domain, plugin redirect)
If cookies set but immediately deleted: cookie path/domain mismatch
If cookies set but rejected on next request: cookie value invalid (time, salt mismatch)

Emergency manual login

If you're truly stuck, log in via WP-CLI:

wp user list --role=administrator
wp eval 'wp_set_auth_cookie(1); echo "Logged in as user 1";'

This sets the auth cookie programmatically. But you need command line access.

For a one-time access cookie:

wp eval-file generate-login-cookie.php

Where the file contains:

<?php
$user_id = 1;  // admin user
$secure = is_ssl();
$expiration = time() + 14 * DAY_IN_SECONDS;
$cookie = wp_set_auth_cookie($user_id, true, $secure);
echo $cookie;

Common mistakes during login loop diagnosis

Clearing browser cookies (only) — doesn't fix server-side cause
Reinstalling WordPress — server config issue persists
Editing wp-config.php blindly — adding random COOKIE_* constants without understanding makes it worse
Assuming "the plugin must be the cause" — most often it's a URL or time issue

When to call a specialist

We resolve login redirect loops in 15-45 minutes via the diagnostic flow above. For production WordPress sites where you can't experiment freely, we work surgically.