Too Many Redirects on a SaaS Site: How to Fix the Error

If your SaaS pages keep showing ERR_TOO_MANY_REDIRECTS, the browser is stuck in a loop and the page will never load. The fix is to find the rule that sends the request back to itself, correct it, and then confirm the loop is gone.

Say you run a SaaS product called SyncHub with 45 employees, serving teams that need project‑management integrations. Your site uses a CDN, enforces HTTPS, redirects non‑www to www, and has custom auth middleware that sends unauthenticated users to a login page. One of those rules has started sending a request right back to the original URL, creating the loop you see in Chrome.

Follow these steps to break the loop:

1. Map the redirect chain – Open the page that shows the error in Chrome, open DevTools → Network, and reload the page. Note each URL that appears in the “Location” header. If the same URL shows up twice, you have a loop. Where to do it: Chrome DevTools on any workstation. How to know it worked: The list ends with a 200 OK response instead of repeating a URL.

2. Check CDN edge settings – Log into your CDN provider and review any “Page Rule” or “Redirect” you have set. Look for patterns like “/* → https://example.com/*” that might overlap with your origin server redirects. Where to do it: CDN console (e.g., Cloudflare page rules). How to know it worked: After disabling the rule, repeat step 1 and see one fewer redirect.

3. Validate HTTPS and www canonical rules – In your web server or load balancer configuration, confirm you have a single source of truth for protocol and domain. A common mistake is having both a server‑level redirect from HTTP to HTTPS and a CDN rule that does the same, causing a ping‑pong. Where to do it: Server config files or the “Redirect HTTP to HTTPS without losing rankings” guide. How to know it worked: The request should go directly from HTTP to HTTPS once, then stop.

4. Inspect auth middleware – Many SaaS apps redirect unauthenticated users to a login endpoint. If the login page itself redirects back to the original URL after a failed token check, you get a loop. Review the code that handles the 401 response and ensure it does not append the original URL again. Where to do it: Application code repository, typically in the authentication module. How to know it worked: After fixing, unauthenticated requests should end on the login page, not bounce back.

5. Test with a clean browser profile – Clear cookies or use an incognito window and revisit the page. A stale cookie can force a redirect that the server no longer expects. Where to do it: Any browser, incognito mode. How to know it worked: The page loads without the error and the network tab shows a single 200 response.

Common signs that a redirect rule is still wrong

• The browser still shows ERR_TOO_MANY_REDIRECTS after you think the loop is fixed.
• The network panel displays a chain of three or more redirects ending with the same URL.
• Authenticated users can access the page, but guests are bounced repeatedly.

If you see any of these, return to the step where the rule was edited and verify that the condition matches only the intended URLs. A mismatched wildcard (e.g., /*) often catches more paths than you intend.

When the fix doesn’t work

1. Mixed‑content warnings – If a page loads over HTTPS but still references HTTP assets, the browser may trigger a redirect to fetch the secure version, adding an extra hop. Ensure all internal links use protocol‑relative URLs or HTTPS.
2. Multiple CDNs – Some SaaS sites use a primary CDN for static assets and a secondary one for dynamic pages. Both may have overlapping redirects. Disable one at a time to isolate the culprit.
3. Cache persistence – After changing rules, CDN or browser caches can still serve the old redirect chain. Purge the CDN cache and ask users to clear their caches or wait for the TTL to expire.

If after exhausting these checks the error persists, consider a full audit of your redirect strategy using a tool that crawls your live site and records every redirect. This will surface hidden loops that manual testing can miss.

Want to turn this into an actual organic growth system? See how we do it

1. Map the redirect chain – extended techniques Use the browser and curl side‑by‑side. After you capture the URLs in DevTools, copy the first “Location” header into a terminal and run curl -I -L . The -L flag follows redirects, and each HTTP/1.1 30x line shows the next hop. Compare the curl output to the network panel; any deviation signals a rule that is applied only to browser‑initiated requests (for example, a cookie‑based rule).

Record the chain in a spreadsheet. Create three columns: Step Number, URL Returned, Status Code. When a URL repeats, highlight the row. This visual helps you see whether the loop occurs after two hops (a classic “http → https → http” ping‑pong) or after a longer series of CDN‑to‑origin redirects.

Where to do it. Any workstation with Chrome and curl installed.

How to know it worked. Both tools stop at a 200 OK line and the spreadsheet shows no repeated URL.

2. Check CDN edge settings – deeper dive Audit page‑rule order. Many CDNs evaluate rules in the order they are listed. A rule that matches “example.com/” will fire before a more specific “example.com/login”. If the generic rule forces a protocol change and the specific rule forces a domain change, the request can bounce between the two. Reorder so the most specific rule runs first, then the catch‑all.

Validate custom error pages. Some CDNs serve a custom 404 page that itself redirects to the home page. If the home page redirects back to the missing URL (for example, by preserving the original path), the loop reappears. Disable the custom 404 redirect while you test.

Where to do it. CDN console – look for “Page Rules”, “Redirects”, or “Edge Workers” sections.

How to know it worked. After saving the new order, repeat step 1. The chain should be one hop shorter, and the final status should be 200 OK.

3. Validate HTTPS and www canonical rules – extra safeguards Single source of truth. Choose either the CDN or the origin server to enforce the canonical host. If the CDN redirects http://example.com → https://example.com and the origin server redirects https://example.com → https://www.example.com, the request cycles: http → https → www → http (because the CDN sees the non‑www host again). Consolidate the logic: either keep the CDN rule only or keep the server rule only.

HSTS header. Add the Strict‑Transport‑Security header on the final HTTPS response. Browsers that receive HSTS will never attempt the insecure http version again, breaking the loop before it starts.

Where to do it. Web server configuration (nginx, Apache, or load‑balancer settings).

How to know it worked. The network panel shows a single 301 from http to https (or none at all) and then a 200 OK; the HSTS header appears in the response headers.

4. Inspect auth middleware – concrete code check

• Typical redirect pattern – Pseudocode often looks like:

if not request.user.is_authenticated:
    return redirect(f"{LOGIN_URL}?next={request.path}")

If the login view, after a failed authentication, runs the same snippet, it will send the user back to the original URL, creating a loop.

• Break the cycle – Ensure the login view only redirects to the original URL after a successful login. On failure, render the login template with an error message instead of issuing another redirect.
• Where to do it: Authentication module in the code repository (e.g., auth/middleware.py).
• How to know it worked: After deploying the change, an unauthenticated request lands on the login page and stays there; the network tab shows a single 302 to the login endpoint and then a 200 OK for the login HTML.

5. Test with a clean browser profile – broaden the scope Cross‑device verification. Test on a mobile device and a different desktop browser. Some CDNs serve different edge nodes based on User‑Agent; a rule that only affects desktop traffic might still cause loops on mobile.

Disable extensions. Browser extensions (especially ad‑blockers or security plugins) can rewrite URLs or inject redirects. Turn them off before retesting.

Where to do it. Any device with a web browser.

How to know it worked. The page loads without the error on every device and every browser profile you try.

Common signs that a redirect rule is still wrong – expanded checklist

• Repeated 301/302 status codes – Look for a pattern like 301 → 302 → 301. A mix of permanent and temporary redirects often means two rules are fighting each other.
• Server‑log entries – Check the access log for the problematic URL. If the same request appears multiple times within a few milliseconds, the server is issuing redirects back‑to‑back.
• AI citation impact – Search engines that provide AI answers crawl your pages. A redirect loop prevents the crawler from reaching the content, so the page will never appear in AI citations. If you notice a drop in AI‑search visibility for a page, verify that the redirect chain is clean.

Comppound’s system includes automated checks for redirect chains, but the judgment to adjust rules still comes from a human. See how we do it.