Too many redirects error in WordPress: how to fix it

The “too many redirects” error (also shown as ERR_TOO_MANY_REDIRECTS in Chrome or “The page isn’t redirecting properly” in Firefox) means your browser is caught in an infinite redirect loop. It requests a URL, gets told to go somewhere else, requests that URL, gets told to go somewhere else again, and this repeats until the browser gives up. The site is completely inaccessible – not just slow or broken, but unreachable.

The good news is that redirect loops in WordPress almost always come from a misconfiguration rather than a code defect. Once you understand where redirects originate, the fix is usually a single setting or a few lines in a configuration file.

What the error actually means#

When you visit a WordPress site, several layers have the opportunity to issue HTTP redirects before the page ever renders. Each layer can independently decide that the current URL is wrong and redirect the browser to a different one. A redirect loop happens when two or more of these layers disagree about what the correct URL should be.

Here is the redirect chain for a typical WordPress request:

1. The browser requests  http://example.com/page
2. The web server (Apache or Nginx) checks its configuration and may redirect to HTTPS or add/remove  www
3. A CDN or reverse proxy in front of the server may modify headers or issue its own redirect
4. WordPress loads  wp-config.php  and checks the  siteurl  and  home  values in the database
5. WordPress plugins fire their redirect rules (SEO plugins, caching plugins, security plugins)
6. WordPress core applies its own permalink-based redirects

A redirect loop occurs when step 2 sends the browser to HTTPS, but step 4 sends it back to HTTP. Or when step 5 adds www but step 3 strips it. The browser bounces between the two instructions indefinitely until it hits its redirect limit (typically 20 redirects) and displays the error.

Understanding which layer is causing the loop is the key to fixing it. The causes below are ordered by how frequently they occur in practice.

Cause 1: WordPress Address vs Site Address mismatch#

This is the most common cause. WordPress stores two URL settings in the wp_options table: siteurl (WordPress Address) and home (Site Address). These control how WordPress generates internal links and where it expects to live. If one says https:// and the other says http:// , or one includes www and the other does not, WordPress redirects back and forth trying to reconcile them.

How to diagnose

If you can access the WordPress admin dashboard, go to Settings > General and compare the two URL fields. They should be identical in most setups – same protocol, same domain, same path.

If you cannot access the admin (because the redirect loop prevents login), check the database directly:

wp option get siteurl
wp option get home

Without WP-CLI, query the database:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Look for any mismatch: http vs https , www.example.com vs example.com , or a trailing slash on one but not the other.

How to fix

Update both values to match exactly. If your site uses HTTPS (it should), both should start with https:// . If you use the www subdomain, both should include it.

Using WP-CLI:

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

Using SQL:

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

Using wp-config.php (overrides the database):

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

The wp-config.php method is useful when you cannot access the database or want to ensure the values cannot be changed from the admin dashboard. These constants take priority over the database values.

Cause 2: SSL misconfiguration#

Redirect loops frequently appear right after installing an SSL certificate or enabling HTTPS. The pattern is always the same: something forces HTTP-to-HTTPS redirects, but WordPress thinks it is still on HTTP, so it redirects back to HTTP. The browser bounces between the two.

This happens when the web server is configured to redirect all traffic to HTTPS, but WordPress has not been updated to use HTTPS URLs, or when the SSL certificate is installed but the server is not properly terminating the connection.

How to diagnose

Check whether the redirect loop involves HTTP-to-HTTPS bouncing. Open your browser’s developer tools (Network tab), navigate to the site, and watch the redirect chain. If you see alternating http:// and https:// URLs, SSL misconfiguration is the cause.

You can also test from the command line:

curl -I -L http://example.com 2>&1 | grep -i "location:"

This follows redirects and prints each Location header. If you see the same URLs repeating, you have a loop.

For SSL certificate issues that produce protocol-level errors rather than redirect loops, see ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it. If you need to install or reinstall the certificate itself, How to install an SSL certificate covers the full process.

How to fix

The fix depends on your web server.

For Apache, ensure the HTTPS redirect is in the correct virtual host and that the RewriteRule only fires on HTTP:

<VirtualHost *:80>
    ServerName example.com
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</VirtualHost>

The RewriteCond %{HTTPS} off condition is critical. Without it, the rule fires on HTTPS requests too, creating a loop.

For Nginx, the HTTP-to-HTTPS redirect should be in a separate server block:

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

This only applies to port 80. The HTTPS server block on port 443 should not contain any redirect to HTTPS. For a deeper comparison of how Apache and Nginx handle redirects and other configuration, see Nginx vs Apache: which one is better for WordPress.

Then update WordPress to use HTTPS URLs (see Cause 1 above) so both the server and WordPress agree on the protocol.

Cause 3: CDN or reverse proxy not passing headers correctly#

If your site is behind a CDN like Cloudflare, a reverse proxy, or any edge layer that terminates SSL, WordPress may not know the original request was HTTPS. The CDN handles the HTTPS connection with the visitor and forwards the request to your server over HTTP. WordPress sees an HTTP request, decides the visitor should be on HTTPS, and issues a redirect. The CDN receives the redirect, follows it, and forwards the same HTTP request again. Loop.

How to diagnose

This cause is almost always the culprit when:

• The redirect loop started after adding a CDN or proxy
• The site works fine when you bypass the CDN (by editing your hosts file to point directly at the server)
• The CDN’s SSL mode is set to “Flexible” (meaning CDN-to-origin is HTTP)

Check your CDN’s SSL/TLS settings. In Cloudflare, this is under SSL/TLS > Overview. “Flexible” mode causes redirect loops with any WordPress site that forces HTTPS.

How to fix

Option 1: Set the CDN to Full or Full (Strict) SSL mode. This makes the CDN connect to your origin over HTTPS, so WordPress sees HTTPS requests and does not redirect. This is the correct solution – it encrypts the connection between the CDN and your server, not just between the CDN and the visitor.

Option 2: Tell WordPress to trust the proxy headers. If you cannot use full SSL between the CDN and your server, add this to wp-config.php :

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

This tells WordPress to check the X-Forwarded-Proto header (which the CDN sets) to determine whether the original request was HTTPS. WordPress will then see the request as HTTPS and will not redirect.

Important: Only add this if your server is actually behind a proxy that sets this header. On a server directly exposed to the internet, this header can be spoofed by any client.

Cause 4: Caching plugin serving stale redirects#

Caching plugins store fully rendered pages and serve them to subsequent visitors without running PHP. If WordPress issued a redirect at some point (for example, during a configuration change) and the caching plugin stored that redirect response, it will keep serving the redirect even after you fix the underlying cause.

This is especially frustrating because you fix the problem, test, and the redirect loop persists. The fix is correct – it is just not being used because the cache is serving old responses.

How to diagnose

Test whether caching is the issue by adding a cache-busting parameter to the URL:

https://example.com/?nocache=1

If the site loads with the parameter but loops without it, the cache is serving a stale redirect.

You can also check the response headers:

curl -I https://example.com

Look for cache-related headers like X-Cache: HIT , X-WP-Super-Cache , or X-LiteSpeed-Cache . A cache hit on a redirect response confirms the problem.

How to fix

Purge the cache. The method depends on the caching plugin:

WP Super Cache: Go to Settings > WP Super Cache and click “Delete Cache.”

W3 Total Cache: Go to Performance > Dashboard and click “Empty All Caches.”

LiteSpeed Cache: Go to LiteSpeed Cache > Toolbox and click “Purge All.”

WP-CLI (works with most caching plugins):

wp cache flush

If you are also using a CDN cache (Cloudflare, for example), purge that cache too. The CDN may have cached the redirect response independently from WordPress.

After purging, verify the redirect loop is resolved. If it returns, the cache was not the root cause – go back and check the other causes in this article. For sites on Hostney, the platform handles cache invalidation at the server level. See How Hostney handles WordPress cache purging automatically for how this works.

Cause 5: Conflicting .htaccess redirect rules#

The .htaccess file in your WordPress root directory controls how Apache processes URLs before WordPress even loads. Multiple redirect rules in .htaccess can conflict with each other, or with redirects that WordPress or a plugin is also issuing, creating a loop.

This is common when:

• You manually added an HTTP-to-HTTPS redirect AND a plugin added one too
• A security plugin wrote rules that conflict with existing rules
• Multiple plugins each wrote their own redirect blocks to  .htaccess
• Old rules from a previous hosting setup were carried over during migration

How to diagnose

Open .htaccess in your WordPress root directory and look for RewriteRule directives that issue redirects (identified by [R=301] or [R=302] flags). Count how many separate redirect blocks exist.

cat .htaccess

Pay attention to redirect rules that lack proper conditions. A rule like this will cause a loop:

# BAD - no condition, fires on every request including HTTPS
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

The correct version checks whether the request is already HTTPS before redirecting:

# GOOD - only fires on HTTP requests
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

How to fix

If you are not sure which rules are causing the problem, reset .htaccess to the WordPress default and see if the loop stops:

cp .htaccess .htaccess.backup

Then replace the contents with the default WordPress .htaccess :

# 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

If the redirect loop stops, the problem was in the old .htaccess rules. Add your custom rules back one at a time to identify which one caused the conflict.

Note: If your site runs on Nginx rather than Apache, there is no .htaccess file. Redirect rules live in the Nginx server configuration. The same principle applies – look for conflicting return 301 or rewrite directives – but you need server-level access to edit them.

Cause 6: WordPress behind a load balancer without X-Forwarded-Proto#

This is a specific variant of the proxy problem (Cause 3) that deserves its own section because the fix is different. When WordPress runs behind a load balancer, the load balancer typically terminates SSL and forwards requests to WordPress over HTTP on an internal network. WordPress sees every request as HTTP and tries to redirect to HTTPS. The load balancer receives the redirect, but since it connects to WordPress over HTTP, the cycle repeats.

How to diagnose

This cause applies when:

• Your infrastructure uses a load balancer (AWS ALB/ELB, DigitalOcean Load Balancer, HAProxy, etc.)
• The load balancer handles SSL termination
• WordPress is configured to use HTTPS URLs

Check whether the X-Forwarded-Proto header reaches WordPress:

// Temporarily add to a test file
<?php
echo $_SERVER['HTTP_X_FORWARDED_PROTO'] ?? 'Header not present';

If the header is not present, the load balancer is not forwarding it, or the web server is stripping it.

How to fix

Add the X-Forwarded-Proto check to wp-config.php , above the line that says “That’s all, stop editing!”:

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

If you are behind AWS ALB specifically, the header is X-Forwarded-Proto . Other load balancers may use different headers – check your provider’s documentation.

For Nginx acting as a reverse proxy, make sure the proxy configuration passes the header to PHP:

proxy_set_header X-Forwarded-Proto $scheme;

Without this directive, Nginx strips the header and PHP never sees it, even if the upstream load balancer set it correctly.

Remove any temporary test files after debugging. Leaving PHP info files accessible is a security risk. If you encounter a server-level error while troubleshooting, WordPress 500 internal server error covers the diagnostic process for those.

Cause 7: Plugin creating redirect loops#

WordPress plugins can register their own redirect rules that fire on every page load. SEO plugins, SSL enforcement plugins, URL redirection managers, and even some security plugins all manipulate URLs and can create loops if misconfigured or if they conflict with another plugin or server-level rule.

How to diagnose

The easiest test is to disable all plugins and see if the redirect loop stops. Since you likely cannot access the admin dashboard (the redirect loop prevents it), rename the plugins directory via SSH or SFTP:

cd /path/to/wordpress/wp-content
mv plugins plugins.disabled

This deactivates every plugin at once. If the redirect loop stops, a plugin is the cause. Re-enable them one at a time to identify which one:

mv plugins.disabled plugins
cd plugins
# Disable all except one
ls -d */ | while read dir; do mv "$dir" "${dir}.disabled"; done
# Re-enable one at a time
mv plugin-name.disabled plugin-name

Test the site after re-enabling each plugin.

Using WP-CLI (if the loop only affects the frontend):

wp plugin deactivate --all

Then reactivate one at a time:

wp plugin activate plugin-name

How to fix

Once you identify the plugin causing the loop, the fix depends on the plugin:

SSL enforcement plugins (Really Simple SSL, WP Force SSL, etc.) – these are usually unnecessary if your server already handles HTTP-to-HTTPS redirects. The plugin redirect and the server redirect step on each other. Remove the plugin and let the server handle SSL redirection.

SEO plugins (Yoast, Rank Math, etc.) – check the plugin’s redirect settings for conflicting rules. Yoast’s “Redirect Manager” and Rank Math’s “Redirections” module can both create rules that conflict with server-level redirects or WordPress core redirects.

Redirection plugins – check for rules that create circular references: URL A redirects to URL B, and URL B redirects back to URL A. Also check for overly broad regex patterns that match URLs they should not.

Security plugins (Wordfence, Sucuri, iThemes Security) – these sometimes force HTTPS or modify URL handling. Check their settings for “Force SSL” or “Redirect HTTP to HTTPS” options that duplicate what the server already does.

The general principle: every redirect should exist in exactly one place. If the server handles HTTP-to-HTTPS, no plugin should do the same. If a plugin manages www vs non- www , no .htaccess rule should also manage it.

Quick diagnostic flowchart#

When you see “too many redirects,” work through this sequence:

1. Clear your browser cookies for the site. A corrupted cookie can cause a redirect loop on the client side. This takes ten seconds and rules out the simplest cause.
2. Check the redirect chain. Use  curl -I -L  or browser dev tools to see exactly which URLs are involved. This tells you whether the loop is HTTP/HTTPS, www/non-www, or something else.
3. Check WordPress URLs. Query  siteurl  and  home  from  wp_options . If they mismatch, fix them (Cause 1).
4. Check the server and .htaccess. Look for redirect rules that fire unconditionally (Cause 2, Cause 5).
5. Check CDN/proxy settings. If using Cloudflare or another CDN, verify the SSL mode is Full, not Flexible (Cause 3).
6. Purge all caches. Plugin cache, server cache, CDN cache (Cause 4).
7. Disable all plugins. If nothing above fixed it, a plugin is likely the cause (Cause 7).

Most redirect loops are resolved at step 3 or 4. The URL mismatch and the missing SSL condition account for the vast majority of cases.

How Hostney handles redirects#

Hostney’s architecture eliminates several of the most common causes of redirect loops.

HTTPS is handled at the server level. When you enable SSL for a domain on Hostney, the HTTP-to-HTTPS redirect is configured in Nginx by the platform. There is no .htaccess rule to conflict with, no plugin needed, and no possibility of a double-redirect between the server and WordPress. The redirect exists in exactly one place.

SSL certificates are provisioned and configured automatically. When you add a domain on Hostney, the platform requests and installs a Let’s Encrypt certificate, configures Nginx to serve it, and sets up the redirect. There is no manual step where you might enable the redirect but forget to update WordPress URLs, or install the certificate on the wrong port.

Proxy headers are set correctly by default. Because Hostney uses Nginx as a reverse proxy in front of PHP, the X-Forwarded-Proto header is always passed through correctly. WordPress always knows whether the original request was HTTP or HTTPS, regardless of how many proxy layers sit in front of it.

Server-level caching is cache-aware of redirects. The caching layer does not cache redirect responses by default, which prevents the stale-redirect problem described in Cause 4. When you change a URL setting, you do not need to worry about purging cached redirects – they were never cached in the first place.

The result is that redirect loops on Hostney are almost always caused by plugin conflicts or incorrect WordPress URL settings in the database – things the platform cannot control because they are user-managed configurations. The infrastructure-level causes (SSL misconfiguration, missing proxy headers, conflicting server rules) are handled by the platform.

Summary#

The “too many redirects” error means the browser is stuck in an infinite loop between two or more redirect instructions. The seven causes, in order of likelihood: mismatched WordPress URL settings, SSL misconfiguration, CDN or proxy not passing headers, cached stale redirects, conflicting .htaccess rules, missing X-Forwarded-Proto behind a load balancer, and plugins creating redirect loops.

Start diagnosis by checking the redirect chain with curl -I -L to understand what URLs are involved. Then check the siteurl and home values in the database, because a mismatch there is the single most common cause. If the URLs are correct, work outward through the server configuration, CDN settings, cache, and plugins.

The core principle for preventing redirect loops is simple: every redirect should exist in exactly one place. If the server handles HTTP-to-HTTPS, remove that redirect from plugins and .htaccess . If a CDN handles www canonicalization, do not also do it in WordPress. When two layers issue the same redirect with slightly different logic, loops are inevitable. For a quick reference covering this error alongside other common WordPress issues, see How to fix the most common WordPress errors.