WordPress "Too Many Redirects" (ERR_TOO_MANY_REDIRECTS): How to Fix It

"This page isn't working: example.com redirected you too many times" (Chrome's ERR_TOO_MANY_REDIRECTS) means the browser followed a chain of redirects until it gave up, because the chain never ends. Something keeps answering "go to URL B" and then B answers "go to URL A". Browsers stop after about 20 redirects.

On WordPress the loop almost always comes from two systems disagreeing about the correct URL: WordPress itself, a plugin, the web server, or a CDN. Fix it by finding which two disagree. Clear your cookies first, since a bad cookie can also cause a loop, then follow the steps below.

Step 1: See the loop instead of guessing

Browsers hide the chain. Use a tool that prints every hop. The रीडायरेक्ट चेकर lists each URL and status code, and the रीडायरेक्ट डिबगर helps explain where each hop came from. From the command line:

curl -sIL --max-redirs 10 https://example.com/ | grep -iE "^(HTTP|location|server|cf-ray|x-redirect-by)"

Look at the pattern:

• http://example.com to https://example.com and back to http://: an HTTPS loop (most common).
• example.com to www.example.com and back: a www versus non-www conflict.
• /page to /page/ and back: a trailing-slash conflict.
• A loop only on /wp-admin/ or /wp-login.php: usually wrong cookie domain or a security plugin or force-SSL constant.

The X-Redirect-By: WordPress header, when present, identifies redirects issued by WordPress itself. A redirect issued by a CDN or the web server will lack it, and the Server and cf-ray headers tell you who answered. The HTTP Header Checker shows the same headers for a single URL. For background on redirect types, see HTTP redirects 301 and 302 explained.

Step 2: Check siteurl and home

WordPress stores its address in two options, siteurl (WordPress Address) and home (Site Address). If they point at a different scheme or host than the one you actually serve, WordPress redirects to its "canonical" address, and if your server then redirects back, you have a loop.

Check with WP-CLI:

wp option get siteurl
wp option get home

Fix with:

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

No WP-CLI? Define both in wp-config.php, which overrides the database values:

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

Or run SQL (replace the wp_ prefix with yours):

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name IN ('siteurl','home');

If you recently moved the site, changed domain or switched to HTTPS, also run a full search-replace; see WordPress SSL and HTTPS migration.

Step 3: The HTTPS loop behind a proxy or load balancer

This is the classic loop on sites behind Cloudflare, a load balancer or a reverse proxy. The visitor connects over HTTPS to the proxy, but the proxy talks to your server over plain HTTP. WordPress sees an HTTP request, decides it must force HTTPS, and redirects. The proxy repeats the same thing forever.

The fix is to tell WordPress that the original request was secure. Add this to wp-config.php before the "stop editing" line:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

Only do this when you trust the proxy that sets the header, and make sure the origin is not reachable directly by clients who could forge it. In nginx, pass the header along:

location / {
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host;
    proxy_pass http://127.0.0.1:8080;
}

If the proxy is Cloudflare, see the next section.

Step 4: Cloudflare Flexible SSL

With Cloudflare's Flexible SSL mode, the browser to Cloudflare leg is HTTPS, but Cloudflare to your origin is plain HTTP. If your origin (or a WordPress plugin) redirects every HTTP request to HTTPS, Cloudflare asks over HTTP, gets a redirect to HTTPS, asks over HTTP again, and so on. Cloudflare documents this as a common cause of redirect loops.

The correct fix is to install a valid certificate on your origin and change the SSL/TLS encryption mode to Full (strict), or at least Full if the certificate is self-signed. A free Let's Encrypt certificate or a Cloudflare Origin CA certificate works on the origin. After switching, the origin sees HTTPS and no loop remains. If you can only use Flexible for now, remove the HTTP to HTTPS redirects at the origin and let Cloudflare's "Always Use HTTPS" do the redirect. Flexible leaves the back end unencrypted, so treat it as temporary. See Cloudflare setup, DNS and SSL modes and the more general Cloudflare too many redirects fix. The Cloudflare एरर चेकर can help identify the layer involved.

Step 5: HTTPS and redirect plugins

Several plugins force HTTPS or change URLs: SSL plugins, security plugins, caching plugins, redirect managers, and multilingual plugins. If two of them each try to enforce a redirect, or one enforces HTTPS while the server config forces HTTP, you get a loop. To test, deactivate them:

wp plugin deactivate --all --skip-plugins --skip-themes
# or one at a time:
wp plugin deactivate really-simple-ssl --skip-plugins

Without WP-CLI, rename wp-content/plugins to plugins.off, test the site, then rename it back. If the loop disappears, reactivate plugins one by one; the plugin conflict troubleshooting guide describes a safe method. Pick one place to enforce HTTPS (ideally the web server or CDN) and turn the others off.

Also check for the FORCE_SSL_ADMIN constant in wp-config.php. It redirects admin and login pages to HTTPS, and if the site cannot actually serve HTTPS the loop only affects /wp-admin/.

Step 6: .htaccess and nginx rules

A bad rewrite rule in .htaccess (Apache) or a server block (nginx) can loop. Suspect this if the redirects have Server: Apache or nginx without the WordPress header.

The default WordPress .htaccess is:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Back up your file, rename it to .htaccess.bak, and test. If the site loads, regenerate with wp rewrite flush --hard or Settings, Permalinks, Save. A correct HTTPS redirect that does not loop behind a proxy needs to check the forwarded header:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

For nginx, check for an unconditional return 301 https://... inside the same server block that already listens on 443, and for try_files rules that redirect to a path they then redirect again:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Keep the HTTP server block separate from the HTTPS block. Run sudo nginx -t && sudo systemctl reload nginx after changes.

Step 7: www versus non-www and trailing slashes

If WordPress is set to https://example.com while the server or host panel forces https://www.example.com, each side redirects to the other. Choose one canonical host, set it in WordPress (home and siteurl), set the same redirect in the server or CDN, and remove the opposite rule. Check DNS and hosting redirects in the control panel too, since some hosts add a "force www" option.

Step 8: Caches and cookies

After you fix the cause, the loop may continue because a 301 redirect is cached by the browser for a long time, by the page cache plugin, or by the CDN. Clear them all:

• Test in a private window, or clear the site's cookies and cache.
• Purge the page cache plugin and the CDN cache.
• Flush the object cache: wp cache flush.

A loop only in the browser but not in curl suggests cookies or a cached redirect. For wp-login.php loops, delete cookies for the domain, check that COOKIE_DOMAIN is not defined to a wrong host, and confirm the server clock is correct.

Step 9: Verify and prevent a repeat

Run the URL through the रीडायरेक्ट चेकर for all four variants: http://example.com, http://www.example.com, https://example.com and https://www.example.com. Each should reach a single final HTTPS URL in one hop, and that final URL should return a 200. Also confirm the certificate with the SSL Checker.

Prevent a repeat by changing one layer at a time, documenting where HTTPS and www are enforced, and monitoring the final URL. The uptime monitor flags a loop quickly, since the check will fail when it cannot reach a 200.

अगले कदम

• Trace the chain with the रीडायरेक्ट चेकर और रीडायरेक्ट डिबगर.
• Confirm the final status with the HTTP स्टेटस चेकर.
• Review WordPress SSL and HTTPS migration.
• Fix mixed content after the redirect loop is solved.
• Read Cloudflare too many redirects fix if you use that CDN.

सामान्य प्रश्न

Why does the site work in an incognito window but not in my normal browser?

A cached 301 redirect or a stale cookie in the normal profile is the likely cause. Clear cookies and cached data for the site, and the loop should stop, assuming the server side is correct.

Can a plugin cause a redirect loop that I cannot see in the dashboard?

Yes. If the loop blocks access to wp-admin, deactivate plugins via WP-CLI or by renaming wp-content/plugins. Security, SSL, redirect and caching plugins are the usual suspects.

How do I stop a loop on wp-admin only?

Check FORCE_SSL_ADMIN, the siteurl value, cookie settings and any proxy header issue. A mismatch between the HTTPS the browser uses and what WordPress thinks it received commonly breaks login redirects.

Is Flexible SSL on Cloudflare safe to keep?

It encrypts only the visitor-to-Cloudflare leg, so traffic between Cloudflare and your server is unencrypted. Install a certificate on your origin and use Full (strict) when you can.

Will redirect loops hurt my search rankings?

Pages that never resolve cannot be crawled or indexed, so a sustained loop can remove pages from results. Fix it quickly and read website downtime SEO impact.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.