Written from live project work
Too Many Redirects WordPress Error? Find the Loop (Tested)

The too many redirects WordPress error means two redirect rules are sending the browser back and forth, or one rule keeps sending it to the URL it just asked for, until the browser gives up. Chrome shows it as “This page isn’t working. example.com redirected you too many times.” with the code ERR_TOO_MANY_REDIRECTS. Run curl -sIL --max-redirs 10 https://yoursite.com/, read which URLs it bounces between and who sends each redirect, then fix that one layer.
I rebuilt three real loops on a local WordPress 7.1.2 site to check every step below: a “force www” rule fighting the WordPress address, a redirect plugin fighting core over a trailing slash, and the Cloudflare Flexible SSL pattern. Each left a different signature in the headers, and each fix brought back HTTP 200.
What does “redirected you too many times” mean?
It means the browser followed redirect after redirect and never reached a page. To a visitor, the too many redirects WordPress error is just that error screen; the cause stays hidden until you read the chain. Chromium stops after 20 redirects (the kMaxRedirects constant in its network code) and shows “This page isn’t working” with “redirected you too many times” and the error code ERR_TOO_MANY_REDIRECTS. Firefox words the same failure as “The page isn’t redirecting properly”. curl stops at 50 unless you set --max-redirs.
A loop is not the same as a site that sends visitors to another domain. If yours keeps redirecting to a spam or pharmacy site, that is almost always injected code, so work through my guide to fixing a hacked WordPress site instead.
How do you find which layer is causing a WordPress redirect loop?
Read the chain before you change anything. From any terminal with curl installed:
curl -sIL --max-redirs 10 https://example.com/
-I asks for headers only and -L follows redirects. Each hop prints a block of headers: read the status code, Location: and X-Redirect-By:. Since WordPress 5.1, wp_redirect() sends that last header, “WordPress” by default, and a plugin calling it can use its own name. A hop without it usually came from an .htaccess or Nginx rule, the host’s control panel, a CDN, or a plugin writing raw headers.
In a browser, open developer tools, tick “Preserve log” on the Network tab, reload, and click each 301 or 302 row to read its headers. curl output is easier to share with a host.
| What the chain shows | Likely layer |
|---|---|
| http to https, then https back to http | CDN SSL mode disagreeing with the server’s own redirect |
| The same https URL redirecting to itself, only on wp-login.php or wp-admin | WordPress cannot tell the visitor is on HTTPS (proxy or Cloudflare Flexible mode) |
www to non-www, then back, with X-Redirect-By: WordPress on one side |
Site Address in WordPress disagrees with a server or host www rule |
Slash added, then removed, two different X-Redirect-By values |
A redirect or SEO plugin rule fighting WordPress permalinks |
| Loop in one browser only, fine in curl or a private window | A cached 301 or old site data in that browser |
What causes the too many redirects WordPress error?
Something outside WordPress wants one URL, and WordPress wants another. To read your chain you need to know what WordPress itself redirects, which is less than most guides assume. I read the 7.1.2 source:
- On the front end, core only changes the host between www and non-www.
redirect_canonical()compares host, path, port and query with your Site Address, and its code comment says “Only redirect no-www <=> yes-www”. The scheme is not compared, so core never redirects a front-end page just to switch http to https. - Login and admin enforce HTTPS. If the WordPress Address starts with https, core sets
FORCE_SSL_ADMINto true, andwp-login.phpand wp-admin redirect any requestis_ssl()sees as http to the https version of the same URL. is_ssl()only trusts the server. It checks$_SERVER['HTTPS']and port 443, notX-Forwarded-Proto, the header proxies and CDNs use to say the visitor connected over HTTPS.
Add hosts, CDNs and plugins, and these are the usual causes:
| Cause | Where it loops | Fix |
|---|---|---|
| Site Address without www, host or server rule forcing www (or the reverse) | Every front-end page; wp-login.php may still load | Make WordPress and the rule agree on one hostname |
| Cloudflare Flexible SSL with https site URLs | wp-login.php and wp-admin; the whole site if the server also forces https | Use Full or Full (strict), or tell WordPress about the proxy |
| Cloudflare Full mode, origin redirecting https to http | Every page | Remove the http redirect on the server |
Server rule RewriteCond %{HTTPS} off behind a proxy |
Every page, the server always sees http | Check X-Forwarded-Proto instead, or move the rule to the CDN |
| Redirect, SEO or SSL plugin rule fighting core or the server | Specific URLs, often trailing slashes or http/https | Fix or delete the rule; deactivate the plugin to confirm |
| Cached 301 or old site data in one browser | One browser or device only | Test in a private window, clear that site’s data |
| Multisite domain mismatch | One subsite | Correct the site’s domain in the network tables |
How do I fix too many redirects WordPress errors layer by layer?
Fix a too many redirects WordPress error in this order, cheapest check first, and run curl after every change so you know which one fixed it.
1. Rule out your own browser
Open the site in a private window or with curl. If it loads there, your browser kept an old redirect: the HTTP standard (RFC 9110) says a 301 response “is heuristically cacheable”. Clear that site’s cookies and cached data. If curl loops too, the problem is on the server side.
2. Make the site URLs agree
In Settings > General, WordPress Address and Site Address should use the scheme and hostname you want visitors on. Without the dashboard, check wp-config.php first: WP_HOME and WP_SITEURL constants win over the database. With WP-CLI:
wp option get home
wp option get siteurl
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'
Watch for the trap I hit in testing: with WP_HOME defined, wp option update home printed “Success: Updated ‘home’ option.” while wp option get home kept returning the constant and the site did not change. Putting the old value back then reported “Value passed for ‘home’ option is unchanged.” and left the new value in the database. Edit the constants, or remove them and fix the database, but do not mix the two.
If you just moved the site to a new domain or to HTTPS, start here: mismatched site URLs after a move are the most likely source of a too many redirects WordPress error. My WordPress migration service handles those moves.
3. Fix HTTPS behind Cloudflare or another proxy
Cloudflare’s documentation is direct about the classic case: in Flexible mode “Cloudflare sends unencrypted requests to your origin server over HTTP”, and “Redirect loops will occur if your origin server automatically redirects all HTTP requests to HTTPS.” Its fix is to remove those origin redirects or set the encryption mode to Full or higher, which needs a certificate on your server. Cloudflare also recommends Full or Full (strict) for sites with user logins, which every WordPress site has.
Behind a proxy that talks plain http to your server, the WordPress handbook warns that forced HTTPS admin “will initially send any requests into an infinite redirect loop” and shows how to read HTTP_X_FORWARDED_PROTO. I add an isset() check, because on PHP 8.2 the handbook’s version raised a warning and a deprecation notice when the header was missing. Put this in wp-config.php above “That’s all, stop editing!”:
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
&& false !== strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) ) {
$_SERVER['HTTPS'] = 'on';
}
Only use it when every request really comes through your proxy, since any visitor can send that header.
4. Check .htaccess and server rules
On Apache, open .htaccess and read everything above # BEGIN WordPress: www rules, HTTPS rules, old domain redirects. Apache’s %{HTTPS} is “on” only “if the connection is using SSL/TLS”, so behind a proxy a RewriteCond %{HTTPS} off rule fires on every request. Back up the file, rename it and reload; if the loop stops, re-add rules one at a time, and Settings > Permalinks > Save writes a clean WordPress block. On Nginx check the server block; on managed hosts, the “force HTTPS” or primary domain setting.
5. Find the plugin with X-Redirect-By
Redirect managers, SEO plugins and SSL plugins all add redirects. If the chain names a plugin in X-Redirect-By, fix or delete that rule. Without wp-admin, rename the plugin’s folder in wp-content/plugins over SFTP and WordPress deactivates it.
6. Multisite: check the network tables
On a network, the handbook says you “will need to manually edit your database”: check wp_blogs, wp_site, and home and siteurl in each site’s options table. With WP-CLI, pass --url= with the subsite’s address to choose the site.
What happened when I built three redirect loops on purpose
I ran these tests on 2026-10-14 on a local WordPress 7.1.2 site (PHP 8.2.12) on PHP’s built-in server, reading every chain with curl 8.17.0, and restored the backed-up config and database afterwards (checksums matched). Temporary must-use plugins played the host rule and the redirect plugin. In the Cloudflare test I played the proxy by hand, sending each Location back to the server over plain http, as Flexible mode does.
| Test | Broken | After the fix |
|---|---|---|
| “Force www” rule, Site Address without www | 11 redirect responses, all 301, alternating www and non-www; curl gave up with “Maximum (10) redirects followed” | Rule removed: 200. Site Address set to www instead: one 301, then 200 |
| Plugin rule stripping the trailing slash | 11 redirect responses, X-Redirect-By alternating “my-redirect-plugin” and “WordPress” |
Rule removed: 200 |
| https site URLs, server reached over plain http (Flexible pattern) | Home page 200; wp-login.php 302 to the same URL on https, 10 out of 10 times | X-Forwarded-Proto snippet: wp-login.php 200 |
The X-Redirect-By header named both sides. In the www test every second response carried X-Redirect-By: WordPress and the others carried nothing, which points at a rule outside WordPress. In the plugin test the header alternated between “my-redirect-plugin” and “WordPress”, which tells you which settings screen to open.
A too many redirects WordPress error can hit only part of the site. During the www loop, /wp-admin/ still reached the login page, because the canonical redirect does not run on wp-login.php. In the Flexible test the home page returned 200 while wp-login.php redirected to itself. “The site works but I cannot log in” points at HTTPS detection; “the login page works but the site loops” points at the hostname.
Forcing HTTPS detection on is not a loop by itself. With $_SERVER['HTTPS'] set to “on” and http site URLs, the home and login pages returned 200. The loop needs a second layer, such as a server rule, CDN setting or plugin.
How do I stop a website from constantly redirecting again?
Most too many redirects WordPress errors start on the day something changes: a domain move, switching to HTTPS, adding Cloudflare, or a new redirect or SSL plugin. A few habits prevent them:
- Pick one canonical URL (https, with or without www) and set it in WordPress, the server and the CDN at the same time.
- Force HTTPS in one place. Use the CDN or server rule, or a plugin, not all three.
- Use Cloudflare Full (strict) with a certificate on your server instead of Flexible.
- Run
curl -sILafter every change to URLs, SSL or redirects, and back up wp-config.php and .htaccess before editing them.
For the other “site is down” problems, see the WordPress white screen of death and WordPress stuck in maintenance mode. HTTPS done properly is also part of securing a WordPress site, and monthly checks of redirects, SSL and updates are part of my WordPress maintenance service.
Frequently asked questions
How do I fix a too many redirects WordPress error?
Start with a private window. If it loads, clear that site’s cookies and cache. If it still loops, run curl -sIL on the URL to see which two URLs it bounces between, then make WordPress, the server and your CDN agree on one address.
How do I fix a redirect error in WordPress without wp-admin access?
Use SFTP or your host’s file manager. Check WP_HOME and WP_SITEURL in wp-config.php, rename .htaccess to test the server rules, and rename a suspect redirect or SSL plugin’s folder in wp-content/plugins to deactivate it. With SSH, WP-CLI’s wp option get home and wp option get siteurl show the URLs WordPress actually uses, constants included.
Why does my WordPress website keep redirecting to another website?
If visitors land on an unrelated domain, such as a spam, pharmacy or prize page, the site is very likely hacked: injected code in a plugin, theme, .htaccess or the database is sending them there. That is not a redirect loop, and changing settings will not fix it. Clean the malware, change every password and update everything instead.
Is ERR_TOO_MANY_REDIRECTS a WordPress problem or a Cloudflare problem?
It can be either, and the headers tell you. Cloudflare documents loops from its SSL mode, Always Use HTTPS, HSTS and conflicting redirect rules. WordPress adds an X-Redirect-By header to every redirect it sends through wp_redirect(). If one side of the loop says WordPress and the other has no such header, the conflict is between WordPress and the server or CDN.
Can clearing cookies fix a WordPress redirect loop?
Only when the loop exists in your browser alone. Browsers can cache a 301 redirect, so an old loop can outlive the fix. If the site loads in a private window or with curl, clearing that site’s data in your browser fixes it. If curl also loops, the cause is on the server, so keep looking.
Sources
- ERR_TOO_MANY_REDIRECTS, Cloudflare SSL/TLS docs, developers.cloudflare.com, retrieved 2026-10-14.
- Flexible encryption mode, Cloudflare SSL/TLS docs, developers.cloudflare.com, retrieved 2026-10-14.
- HTTPS (Administration over HTTPS, Using a Reverse Proxy), WordPress Advanced Administration Handbook, developer.wordpress.org, retrieved 2026-10-14.
- Migrating WordPress (Changing the Site URL, multisite notes, WP-CLI), WordPress Advanced Administration Handbook, developer.wordpress.org, retrieved 2026-10-14.
- wp_redirect(), WordPress Code Reference, developer.wordpress.org, retrieved 2026-10-14.
- WordPress 7.1.2 source: wp-includes/canonical.php, load.php, pluggable.php, default-constants.php and wp-login.php, read locally 2026-10-14.
- mod_rewrite, Apache HTTP Server 2.4 documentation, httpd.apache.org, retrieved 2026-10-14.
- curl man page (–max-redirs), curl.se, retrieved 2026-10-14.
- RFC 9110 HTTP Semantics, section 15.4.2 (301 Moved Permanently), rfc-editor.org, retrieved 2026-10-14.
- Chromium source, net/url_request/url_request.h (kMaxRedirects) and components/error_page_strings.grdp, github.com/chromium/chromium, retrieved 2026-10-14.
- Tests on a local WordPress 7.1.2 install with PHP 8.2.12, WP-CLI 2.12.0 and curl 8.17.0, by Mohammad Humza, 2026-10-14.
Share this article


