WordPress Errors

WordPress ERR_TOO_MANY_REDIRECTS

Critical Updated: July 7, 2026

What Is This Error?

When you see ERR_TOO_MANY_REDIRECTS, your WordPress site has fallen into an infinite redirect loop. It keeps bouncing between URLs — say, from HTTP to HTTPS and back again — without ever settling on one. Your browser follows redirects up to a limit (usually around 20), then throws up its hands and shows this error instead of your site.

Think of it like two people at a doorway, each insisting the other go first. Nothing moves. Your visitors see a blank error screen, your admin panel is unreachable, and no amount of refreshing helps.

The good news: this error almost always traces back to one of a handful of specific causes, and most of them can be fixed by editing two lines in a config file. You don’t need to be a developer to sort this out.

Get free WordPress & AI tips

Join 500+ readers. No spam, unsubscribe anytime.

Why Does This Happen?

  • WordPress URL mismatch: If your WordPress Address and Site Address in Settings → General don’t match — for example, one is HTTP and the other is HTTPS — WordPress redirects back and forth trying to reconcile them indefinitely.
  • Server-level HTTPS forced while WordPress URL is still HTTP: Your host or CDN is pushing all traffic to HTTPS, but your database or wp-config.php still stores an HTTP URL, creating a ping-pong redirect between the two.
  • Corrupted or conflicting .htaccess rules: Duplicate or contradictory RewriteRule entries in your .htaccess file can fire against each other, looping traffic between rules that each point somewhere different.
  • Plugin conflicts: SSL, caching, or SEO plugins that each manage their own redirect logic can issue contradictory instructions that stack into a loop — especially after an HTTP-to-HTTPS migration.
  • Reverse proxy not forwarding HTTPS headers correctly: If your site sits behind Cloudflare or a load balancer, WordPress may not detect that the incoming connection is already secure and keep trying to redirect to HTTPS on its own.

How to Fix It — Step by Step

  1. Clear your browser cache and test in a private window. Sometimes the redirect loop is cached in the browser itself. Open an incognito or private window, or clear all cookies and cached files for your domain before changing anything on the server.

    You should see: Either the site loads normally (browser cache was the culprit) or the same error in a clean window, confirming it is a server-side issue worth digging into.

  2. Set your WordPress URLs directly in wp-config.php. Open wp-config.php in your site’s root directory via FTP or your host’s file manager. Add or update these two lines just above the line that reads /* That's all, stop editing! */:
    define('WP_HOME', 'https://yourdomain.com');
    define('WP_SITEURL', 'https://yourdomain.com');

    Replace the URL with your actual domain, using the correct HTTP or HTTPS prefix.

    You should see: The site loads without a redirect error, or you can reach the WordPress admin panel again.

  3. Reset your .htaccess file. Via FTP, rename your current .htaccess to .htaccess_old, then create a fresh .htaccess file in the same root directory with this default WordPress content:
    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress

    You should see: The site or admin panel loads after saving the new file, indicating the old .htaccess had conflicting redirect rules.

  4. Disable all plugins via FTP. Navigate to wp-content/plugins/ and rename the entire folder to plugins_disabled. This deactivates every plugin at once without needing access to the admin panel.

    You should see: The site loads, confirming a plugin is responsible. Rename the folder back to plugins, then reactivate plugins one at a time — testing after each — until the loop returns, identifying the problem plugin.

  5. Add the HTTPS detection constant for reverse proxies. If your site is behind Cloudflare, a CDN, or a load balancer, add this line to wp-config.php so WordPress correctly identifies incoming connections as secure:
    $_SERVER['HTTPS'] = 'on';

    You should see: The redirect loop stops because WordPress no longer attempts its own HTTPS redirect on top of the one already happening at the proxy level.

  6. Correct the URLs directly in the database. Log into phpMyAdmin, open your WordPress database, and find the wp_options table. Locate the rows where option_name equals siteurl and home. Click Edit on each and update the option_value to your correct full URL — making sure both use the same HTTP or HTTPS scheme.

    You should see: The site loads correctly after updating both rows and hard-refreshing the browser.

Common Mistakes When Fixing This

  • Updating only one of the two URL values in the database: Changing siteurl but leaving home on HTTP (or the reverse) keeps the loop alive — both values must match exactly, including the protocol.
  • Reactivating all plugins at once after the folder-rename test: Bulk-reactivating means you lose the ability to identify which plugin caused the problem; reactivate them one at a time and test the site after each one.
  • Adding the HTTPS server constant without a valid SSL certificate: Forcing WordPress to treat connections as HTTPS when the certificate is expired or misconfigured just trades one error for another — confirm your certificate is active and valid first.
  • Editing wp-config.php without a local backup: A single syntax error in that file causes a fatal error or white screen on top of your original problem. Download a copy before making any edits so you can restore it if something goes wrong.

Frequently Asked Questions

Can ERR_TOO_MANY_REDIRECTS affect only specific pages instead of the whole site?

Yes, it can. If the loop is triggered by a plugin rule or .htaccess condition tied to specific URL patterns — like the login page or a custom post type — only those URLs will loop while the rest of the site loads fine. In that case, focus on plugin settings and .htaccess rules that reference the affected URL pattern specifically.

I just migrated from HTTP to HTTPS — is that why this started?

Almost certainly. HTTP-to-HTTPS migrations are the single most common trigger for this error. If you installed an SSL certificate but did not update the WordPress Address and Site Address to use HTTPS, or if your host is now forcing HTTPS while WordPress still references HTTP URLs in the database, the redirect loop is a direct result of that incomplete migration.

Will fixing this affect my Google rankings or SEO?

Once the loop is resolved and redirects work correctly, your SEO should be unaffected going forward. However, if the loop was live long enough to prevent Googlebot from crawling your site, you may see a temporary dip in indexed pages. After fixing it, open Google Search Console, check the Coverage report for redirect errors, and request a recrawl of affected URLs.

What if none of these steps solve the problem?

At that point, the cause is likely living outside WordPress entirely — in your server configuration. Check with your hosting provider for Apache VirtualHost or Nginx server block rules that may be creating a redirect on top of WordPress’s own rules. Also verify your Cloudflare SSL mode: if it is set to Flexible instead of Full or Full (Strict), Cloudflare sends HTTPS to the browser but HTTP to your server, which causes WordPress to redirect back to HTTPS in an endless loop.

This site contains affiliate links. If you make a purchase through one of these links, we may earn a small commission at no extra cost to you. Learn more.