WordPress Login Page Keeps Redirecting to Itself: Causes and Fixes (2026)

One of the most frustrating issues WordPress site owners and administrators encounter is being stuck in a login redirect loop — you enter your username and password, click Log In, and instead of reaching the dashboard, you are sent right back to the login page again. This can happen suddenly, often after a server migration, PHP upgrade, or a change in Cloudflare or security settings.

This guide covers every known cause of the WordPress login redirect loop and provides exact, tested fixes for each one.

Before You Begin: WP-CLI vs Manual Methods

Many of the fixes in this guide use WP-CLI — the official command-line interface for WordPress. WP-CLI lets you manage WordPress installations directly from your server terminal, without needing to log into the WordPress admin.

If you are comfortable with SSH and server access, WP-CLI is the fastest and most reliable approach. If you are not familiar with WP-CLI or do not have SSH access to your server, do not worry — every fix in this guide also includes a manual alternative using FTP, your hosting file manager, or phpMyAdmin.

To check if WP-CLI is available on your server, run:

wp --info

What Causes the WordPress Login Redirect Loop?

The WordPress login process works by setting an authentication cookie in your browser after you submit your credentials. WordPress then checks for that cookie when you are redirected to the admin dashboard. If the cookie is not set, not readable, or invalidated, WordPress sends you back to the login page — creating an infinite loop.

The root causes fall into five categories:

1. Corrupted or incompatible WordPress secret keys and salts
2. Cloudflare security rules challenging the login page
3. Missing HTTPS server variables behind a proxy
4. Incorrect siteurl or home values in the database
5. Cookie domain misconfiguration in wp-config.php

Cause 1: Corrupted WordPress Secret Keys (Most Common on PHP 8.x)

What Happens

WordPress uses eight secret keys and salts defined in wp-config.php to sign and verify authentication cookies. These keys contain special characters such as $, {, }, |, and !.

On PHP 8.0 and above, PHP introduced stricter handling of array keys. If your secret keys contain certain special characters, PHP throws warnings like:

PHP Warning: Undefined array key "2dYuFyeYF5-]glu$E0..." in wp-includes/pluggable.php on line 2631

This warning indicates that the cookie verification is failing silently, and WordPress cannot confirm your identity — sending you back to the login page every time. This is especially common after migrating a site from an older server, restoring a backup, or upgrading to PHP 8.0, 8.1, 8.2, 8.3, or 8.4.

Fix via WP-CLI

SSH into your server and run these four commands in sequence:

Step 1 — Fetch new salts:

curl -s https://api.wordpress.org/secret-key/1.1/salt/ > /tmp/new-salts.txt

Step 2 — Remove old salts from wp-config.php:

sed -i '/define.*AUTH_KEY/d;/define.*SECURE_AUTH_KEY/d;/define.*LOGGED_IN_KEY/d;/define.*NONCE_KEY/d;/define.*AUTH_SALT/d;/define.*SECURE_AUTH_SALT/d;/define.*LOGGED_IN_SALT/d;/define.*NONCE_SALT/d' /path/to/wp-config.php

Step 3 — Insert new salts:

sed -i '/\$table_prefix/r /tmp/new-salts.txt' /path/to/wp-config.php

Step 4 — Flush cache:

wp cache flush --path=/path/to/wordpress --allow-root

Fix via FTP / File Manager (No WP-CLI)

1. Open https://api.wordpress.org/secret-key/1.1/salt/ in your browser and copy all the generated lines.
2. Connect to your server via FTP or open File Manager in your hosting control panel.
3. Navigate to your WordPress root folder and open wp-config.php for editing.
4. Find the section that starts with define('AUTH_KEY', and ends with define('NONCE_SALT', — select and delete all eight lines.
5. Paste the new salt lines you copied in Step 1 in their place.
6. Save the file.
7. Clear your site cache from your caching plugin dashboard if applicable.

After regenerating salts, all existing sessions will be invalidated and users will need to log in again — but the redirect loop will be resolved.

Cause 2: Cloudflare Security Rules Challenging the Login Page

What Happens

If your site is behind Cloudflare and you have a WAF custom rule, Bot Fight Mode, or a high Security Level applied to wp-login.php, Cloudflare presents an Interactive Challenge or Managed Challenge before the login form is submitted. The challenge interrupts the cookie flow, and WordPress never receives confirmation that you are logged in.

This is identifiable by seeing a “Performing security verification — Verify you are human” screen on or after the login page.

Fix — No WP-CLI Required

This fix is done entirely in the Cloudflare dashboard. No server access needed.

Option 1 — Create a WAF bypass rule for wp-login.php:

Go to Cloudflare Dashboard → your domain → Security → WAF → Custom Rules → Create Rule:

• Name: Allow wp-login no challenge
• Field: URI Path equals /wp-login.php
• Action: Skip — Skip all remaining custom rules AND Skip managed challenges
• Place at: First

Option 2 — Replace the Interactive Challenge with a Rate Limiting rule:

Go to Security → WAF → Rate Limiting Rules → Create Rule:

• URI Path equals /wp-login.php
• Rate: 5 requests per 10 seconds per IP
• Action: Block for 10 minutes

Rate limiting is the better long-term solution — it blocks brute force bots without showing a challenge to legitimate users.

Cause 3: WordPress Not Detecting HTTPS Behind Cloudflare or a Proxy

What Happens

When WordPress is served behind a proxy like Cloudflare, Nginx, or a load balancer, WordPress may not detect that the connection is HTTPS. It then sets cookies without the Secure flag, causing the browser to reject them. The result is that WordPress redirects you to login again.

Fix via WP-CLI

sed -i "/

Fix via FTP / File Manager (No WP-CLI)

1. Open wp-config.php in your FTP client or hosting File Manager.
2. Find the line <?php at the very top of the file.
3. Add these three lines immediately after it:

$_SERVER['HTTPS'] = 'on';
$_SERVER['HTTP_X_FORWARDED_PROTO'] = 'https';
define('FORCE_SSL_ADMIN', true);

4. Save the file and try logging in again.

Cause 4: Mismatched siteurl and home Values

What Happens

If the siteurl or home options in the WordPress database point to the wrong URL — for example after a migration from an old server — WordPress will redirect login to the wrong address, causing a loop.

Fix via WP-CLI

wp option get siteurl
wp option get home
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'
wp cache flush

Fix via phpMyAdmin (No WP-CLI)

1. Log into your hosting control panel and open phpMyAdmin.
2. Select your WordPress database.
3. Open the wp_options table (your prefix may differ, e.g. abc_options).
4. Find the rows where option_name is siteurl and home.
5. Click Edit and update the option_value to your correct URL including https://.
6. Save and clear your cache.

Cause 5: COOKIE_DOMAIN Misconfiguration

What Happens

If COOKIE_DOMAIN is defined in wp-config.php with an incorrect value — such as including www when your site does not use it — browsers will reject the authentication cookie.

Fix via WP-CLI

sed -i "/define('COOKIE_DOMAIN'/d" /path/to/wp-config.php

Fix via FTP / File Manager (No WP-CLI)

1. Open wp-config.php in your FTP client or file manager.
2. Search for COOKIE_DOMAIN.
3. Delete the entire line that defines it.
4. Save the file.

WordPress will automatically detect the correct cookie domain without this line.

Quick Diagnostic Checklist

Run through these checks in order when you encounter the login redirect loop:

Bulk Fix for Multiple WordPress Sites (WP-CLI)

If you manage multiple WordPress installations on the same server, use this script to regenerate secret keys across all sites at once:

for path in \
  /var/www/vhosts/site1.com/httpdocs \
  /var/www/vhosts/site2.com/httpdocs \
  /var/www/vhosts/site3.com/httpdocs; do
  echo "=== Fixing: $path ==="
  curl -s https://api.wordpress.org/secret-key/1.1/salt/ > /tmp/new-salts.txt
  sed -i '/define.*AUTH_KEY/d;/define.*SECURE_AUTH_KEY/d;/define.*LOGGED_IN_KEY/d;/define.*NONCE_KEY/d;/define.*AUTH_SALT/d;/define.*SECURE_AUTH_SALT/d;/define.*LOGGED_IN_SALT/d;/define.*NONCE_SALT/d' $path/wp-config.php
  sed -i '/\$table_prefix/r /tmp/new-salts.txt' $path/wp-config.php
  wp --path=$path --allow-root cache flush 2>/dev/null
  echo "Done: $path"
done

Summary

The WordPress login redirect loop is almost always caused by one of these issues: corrupted secret keys (especially on PHP 8.x), Cloudflare security rules interrupting the login POST, or WordPress not detecting HTTPS behind a proxy. The most common fix in 2026 is regenerating secret keys, which resolves the PHP 8.x array key warning in pluggable.php that silently breaks cookie verification.

If you are behind Cloudflare, ensure no WAF rule is applying a challenge to wp-login.php — use rate limiting instead for bot protection. All fixes in this guide can be done via WP-CLI for speed, or manually via FTP and phpMyAdmin if you do not have server access.

Frequently Asked Questions

Why did this start happening after a PHP upgrade?

PHP 8.0 and above deprecated certain behaviors around array key handling. If your WordPress secret keys contain special characters, PHP 8.x throws warnings during cookie verification that prevent login from completing.

Will regenerating secret keys log out all users?

Yes. All existing sessions across all browsers and devices will be invalidated. Users will need to log in again. This is expected behavior and not harmful.

Does this affect the front-end of my site?

No. The login redirect loop only affects the WordPress admin area. Your front-end visitors are not affected.

Do I need WP-CLI to fix this?

No. Every fix in this guide has a manual alternative using FTP, your hosting file manager, or phpMyAdmin. WP-CLI is faster and recommended for developers, but it is not required.

What if none of these fixes work?

Try deactivating all plugins by renaming the wp-content/plugins folder to wp-content/plugins-disabled via FTP, then attempt to log in. If login succeeds, a plugin is causing the issue. Rename the folder back and deactivate plugins one by one to identify the culprit.