Fixing Redirect Loops and ERR_TOO_MANY_REDIRECTS
A redirect loop happens when following a page's redirects eventually leads back to an address already visited, so the browser keeps going round until it gives up. Chrome shows ERR_TOO_MANY_REDIRECTS, Firefox says the page is not redirecting properly, and Safari reports too many redirects. Visitors see an error instead of your page, and search engines cannot reach it at all.
Almost every loop comes from two rules that disagree. This guide shows how to read the loop to work out which two rules are involved, fix the common pairings, and clear the cached redirects that can keep a loop alive after the fix.
Read the loop before you touch anything
The fastest way to a fix is to look at the addresses in the loop, because the part that changes tells
you which rules are fighting. Capture the hops with the Redirect Checker, which records every Location
header and flags the loop, or with curl limited to a few hops:
curl -sIL --max-redirs 6 https://www.example.co.uk/about/ | grep -iE "^HTTP|^location"
HTTP/2 301
location: https://example.co.uk/about/
HTTP/2 301
location: https://www.example.co.uk/about/
HTTP/2 301
location: https://example.co.uk/about/
curl: (47) Maximum (6) redirects followedHere only the host flips, so one rule adds www and another removes it. Use the table below to match your own pattern:
| Pattern in the hops | Usual pairing of rules |
|---|---|
| The same https address redirects to itself | A proxy or CDN talks to your server over HTTP; the server keeps "upgrading" a request that already arrived as HTTPS. |
Flips between http:// and https:// | One layer forces HTTPS while another sends visitors back to HTTP, often an old site address stored in the CMS. |
Flips between www and no www | Server or CDN prefers one host, the CMS or a panel setting prefers the other. |
Flips between /page and /page/ | One rule adds a trailing slash, another strips it. |
The address grows each time, such as /new/new/new/page | A rewrite pattern that also matches its own target. |
Bounces between a page and /login or a consent page | A cookie is not being set or read, so the check that sends visitors away never passes. |
| Bounces between two language or country versions | Location-based and cookie-based redirects contradict each other. |
-b "name=value".The common loops and how each is broken
A proxy connects to the origin over plain HTTP
This is the classic loop on sites behind a CDN. The visitor connects securely to the CDN, but the CDN fetches the page from your server over HTTP, for example because the CDN's encryption mode is set to a flexible option that only encrypts the visitor side. Your server has a "force HTTPS" rule, sees an insecure request, and redirects. The redirect goes back to the visitor, who asks the CDN again, and the CDN fetches over HTTP again. Break it by making the CDN connect to the origin over HTTPS with a valid certificate, which on Cloudflare means a full, strict mode, or by making the origin trust the forwarded scheme header. The CDN and origin conflicts guide covers the layering in detail.
The CMS disagrees with the server
WordPress, and many other CMSs, store the site's own address and redirect any request that does not
match it. If that stored address says http://example.co.uk while the server forces https://www.example.co.uk,
each side keeps correcting the other. Make the stored address exactly match the address your server rule
sends visitors to: scheme, host and all.
Two rules disagree about the trailing slash
A framework that adds slashes and a server rule that removes them, or a CDN rule and a plugin, loop on every page that is not a file. Pick one style and remove the opposing rule. The trailing-slash guide covers choosing a style.
A rewrite rule matches its own result
A rule such as "send everything under / to /shop/" also matches /shop/,
so it redirects there again. Add a condition that excludes the target, or anchor the pattern so it only
matches the old paths.
# Loops: /shop/ also matches ^(.*)$
RewriteRule ^(.*)$ /shop/$1 [R=301,L]
# Fixed: skip requests already under /shop/
RewriteCond %{REQUEST_URI} !^/shop/
RewriteRule ^(.*)$ /shop/$1 [R=301,L]Login, consent and cookie loops
A members area sends visitors without a session cookie to /login, and the login page
sends visitors with a session back. If the cookie is set for the wrong domain or path, marked Secure
while the site is served over HTTP, or blocked by a browser privacy setting, the check never passes.
Check the Set-Cookie header in developer tools and make its Domain, Path
and Secure attributes match the address visitors actually use.
The fix, step by step
Step 1
Capture the loop outside your browser
Run
the Redirect Checker on the failing URL, or use curl with -sIL --max-redirs 6 so it stops
after a few hops. Save the output, including every status code and Location header. Do not
start changing settings yet. Browsers cache 301s and may hide what the server is doing now, so a clean
capture of the live behaviour is the only reliable starting point and gives you something to compare
against later.
Step 2
Read which part of the address flips
Compare the addresses in the loop and note which part changes between hops: the scheme, the host, the trailing slash, a path segment that repeats, a query string, or a jump to a login or language page. If the same address redirects to itself, suspect a proxy talking to the origin over HTTP. Match the pattern against the table on this page to get the likely pair of rules before you start searching.
Step 3
Find the two rules that disagree
Loops
need two rules pulling in opposite directions, so list every place that could redirect: CDN rules and
encryption mode, hosting panel settings, server config and .htaccess, the CMS site address
and its redirect plugins, and application code. For each, note what it does to the part of the address
that flips. The response headers help too: a cf-ray header means Cloudflare answered, and
x-redirect-by often names the WordPress component responsible.
Step 4
Remove or narrow one of the rules
Decide which rule reflects the address you want and remove or change the other. For HTTPS loops behind a CDN, set the CDN to connect to the origin over HTTPS and keep one upgrade rule. For host or slash loops, align the CMS setting with the server rule. For self-matching rewrites, add a condition that excludes the target. Change one thing at a time and retest, so you know which change broke the loop.
Step 5
Purge every cache that stored a redirect
A redirect can be stored by the CDN, a caching plugin, a server cache such as Varnish, and every browser that received a 301. Purge the CDN cache for the affected URLs, clear the CMS page cache and any object cache, and restart or flush the server cache if you run one. Otherwise the loop can appear to survive the fix, or come back briefly when an old cached copy is served to someone.
Step 6
Retest from a clean start
Re-run
the Redirect Checker and curl on the failing URL, then on the same URL with and without www,
over http, and with and without a trailing slash. Each should end in a 200 within one hop. Test in a
private window and on a phone using mobile data. For your own browser, clear the site's data so its cached
301s are dropped, then check the admin area and login pages as well.
Where to look on common platforms
| Platform | Settings most often involved |
|---|---|
| WordPress | The WordPress Address and Site Address in Settings, any WP_HOME
and WP_SITEURL lines in wp-config.php, redirect and SSL plugins, and the server's
rules. Behind a proxy, WordPress may need to be told the request was secure. See the WordPress
redirects guide. |
| Cloudflare | The SSL/TLS encryption mode, the "always use HTTPS" setting, redirect rules and legacy page rules. See the Cloudflare guide. |
| Plesk and cPanel | Panel options that force HTTPS or choose the preferred domain, added
on top of rules in .htaccess or nginx directives. |
| Shopify and hosted builders | Loops usually involve a custom domain set up at a CDN or DNS provider that also redirects, or an app that adds its own redirects. |
| Frameworks and single-page apps | Trailing-slash and locale middleware, authentication middleware, and platform-level redirect files on the host. |
If you are locked out of the WordPress admin by a loop, you can set the addresses in wp-config.php
by adding define('WP_HOME', 'https://www.example.co.uk'); and define('WP_SITEURL', 'https://www.example.co.uk');,
which override the database values. Remove them later if you prefer to manage the setting from the dashboard.
Loops that only some people see
Some loops are real but intermittent, which makes them confusing to report:
- Only logged-in users. The loop depends on a session or role, such as an admin redirect that fights an SSL setting. Test with the same cookies using curl.
- Only on some pages. A pattern rule matches only certain paths, or only paths that are not real files or folders.
- Only in one country or language. Geolocation redirects send visitors to a local version, and a cookie or header check sends them back.
- Only for some browsers. One browser has a cached 301 or an HSTS entry from an old configuration. Clearing site data fixes it for that browser; it does not need a server change.
- Only for search engine crawlers. A rule based on user agent, or a bot-protection challenge that redirects, loops for crawlers that cannot run scripts or keep cookies. Search Console's URL Inspection tool will show a redirect error.
Stopping loops from coming back
- One owner per concern. Decide which single layer handles HTTPS, which handles the host and which handles slashes, and write it down.
- Change one layer at a time. When you switch on a CDN, a new SSL plugin or a hosting panel option, check whether it overlaps an existing rule before enabling it.
- Test before caching. Try new redirect rules with a 302 first, confirm there is no loop, then switch to 301, so a mistake is not cached by browsers.
- Keep a smoke test. After each deployment, run the Redirect Checker on your homepage, a deep page, the login page and the four scheme and host variations.
- Watch Search Console. Redirect errors in the page indexing report are often the first sign that a loop is affecting crawlers.
1. What does ERR_TOO_MANY_REDIRECTS mean?
It means the browser followed a series of redirects that never reached a normal page, and gave up. In nearly every case the redirects form a loop, where one rule sends the visitor to an address that another rule sends straight back. Firefox and Safari show the same problem with different wording. The page itself may be fine; the fault is in how two redirect rules, often in different parts of the setup, disagree about the correct address.
2. Why does clearing cookies fix a redirect loop for me but not for others?
Clearing site data removes cookies and, in most browsers, cached redirects for that site. If that fixes it, either an old cached 301 was sending your browser to a bad address, or a cookie was triggering the loop. Other visitors may have their own stale cookies or cached redirects, or they may be hitting a server-side loop that your browser no longer triggers. Test with curl to see what the server itself is doing now.
3. How do I fix a redirect loop caused by Cloudflare?
The usual cause is an encryption mode where Cloudflare connects to your server over plain HTTP while your server forces HTTPS. Install a valid certificate on the server, even a free one, and set the encryption mode to the full and strict option so Cloudflare connects securely. Then keep only one HTTPS rule, either at Cloudflare or on the server. Also check redirect rules at Cloudflare that might contradict your server host or slash rules.
4. How do I fix a WordPress redirect loop when I cannot log in?
Add WP_HOME and WP_SITEURL definitions to wp-config.php with the exact address your server sends visitors to, including https and the correct www choice. These override the stored settings and usually end loops caused by a mismatch. If the loop continues, rename the plugins folder over FTP or the file manager to disable all plugins, test again, then restore them one by one to find the one responsible. Check the server rules and CDN settings too.
5. Can a redirect loop affect my search rankings?
A page stuck in a loop cannot be crawled, so it cannot be indexed or refreshed. If the loop lasts, search engines will report a redirect error and may drop the page from results. A short loop that you fix quickly usually has no lasting effect, because the page is crawled again and returns to normal. The damage comes from loops left in place, especially on the homepage or on sections linked from everywhere.
6. Why does my redirect loop only happen on some pages?
Because one of the rules involved only matches certain addresses. Trailing-slash rules often skip real files, rewrite patterns may match one folder, language rules may apply only to pages with a translation, and login checks only cover protected sections. Test a failing page and a working page side by side, compare which rules match each, and the rule that applies only to the failing page is usually one half of the loop.
The Redirect Checker follows each URL through its full chain, recording every status code, Location header and hop time, and flags loops alongside long chains, 302s that should be 301s, HTTPS gaps and mixed content.
Open Redirect Fixes →