---
type: blog
title: "Too Many Redirects? Find the Loop Before Changing DNS"
description: "Find the cause of a storefront redirect loop, separate browser state from conflicting URL rules, and check the customer journey after the fix."
date: "2026-10-15"
lastModified: "2026-10-15"
authors: "Runner AI Team"
tags: ["Store Operations", "Domains", "Troubleshooting"]
featured: false
readTime: "6 min read"
thumbnail: "https://storage.googleapis.com/runner-blog/blog/too-many-redirects/cover"
thumbnailAlt: "Two ivory browser-shaped cards are joined by terracotta arrows in a circular loop beside a small kraft parcel on a cream tabletop."
seo:
  title: "Too Many Redirects: Diagnose and Fix a Storefront Loop"
  description: "Fix too many redirects by tracing conflicting URL rules, separating browser state from server problems, and checking your storefront before sharing it again."
---

Too many redirects means your browser followed more redirects than it allows without reaching a page. A common cause is a loop: one address sends the browser to another, which sends it back. For an online store, first identify the repeating addresses and whether the failure depends on browser state. Then correct the conflicting rule, rather than changing DNS or weakening HTTPS by guesswork.

Disclosure: Runner AI publishes this guide. The Runner routing example below comes from source code, not a claim about a customer's incident or the version running on every deployment.

## What causes too many redirects?

A redirect tells the browser to request a different URL. One redirect can be intentional, such as sending an old product link to its replacement. Several redirects can also finish successfully. A loop is different: the instructions keep returning the browser to an earlier destination, or otherwise prevent it from reaching content.

Consider an illustrative pair of rules. Your hosting platform sends `example.com` to `www.example.com`, while another service sends `www.example.com` back to `example.com`. Each rule can look reasonable alone. Together, they prevent either address from loading. The same conflict can involve HTTP and HTTPS, a trailing slash, a language prefix, or a login state.

[Cloudflare's redirect-loop documentation](https://developers.cloudflare.com/ssl/troubleshooting/too-many-redirects/) describes conflicts between its encryption mode, origin server, and redirect rules. A browser cookie can also affect which route an application chooses. That is why a fresh browser session is a useful comparison, but not proof that the browser caused the bug.

Keep three symptoms separate. A DNS lookup failure means the name could not be resolved. A certificate warning concerns the secure connection. A redirect error means the browser could not finish following the navigation instructions. If you changed domain records recently, our [DNS propagation guide](./dns-propagation-time) helps decide whether waiting is justified; waiting alone does not correct opposing redirect rules.

## Find the repeating URLs before you change settings

Record the exact failing address, including `www`, the path, and any language prefix. Note whether the problem starts on the homepage, a product link, or only after signing in. Do not repeatedly submit checkout or payment forms while investigating.

Start with comparisons that do not change your store:

1. Open the same public URL in a private window. Compare signed-out browsing with the failing session.
2. Try a second browser or device. If possible, compare a second network too.
3. If only the usual browser profile fails, clear that site's data after noting the result. This can sign you out and reset local preferences or cart state.
4. If the failure persists, collect the redirect sequence before editing hosting or application settings.

A private window changes more than cookies. It can change extensions, login state, and stored preferences. Success there narrows the investigation to a state-dependent path; the application may still mishandle that state. Avoid instructions that require every shopper to clear their browser as the permanent fix.

### Read a redirect trace

In browser developer tools, open **Network**, enable **Preserve log**, then navigate to the failing public page. Inspect the document requests. Record each request URL, response status, and the `Location` response header for HTTP redirects. Our [guide to inspecting a web page](./how-to-inspect-element) explains how developer tools differ from editing the live site.

A technical colleague can also trace a public page with an HTTP client such as curl. Ask them to use a GET request, print response headers, and set finite redirect and time limits. A request without your browser's login cookies may not reproduce an account-specific loop. JavaScript navigation and browser-enforced HTTPS upgrades may also differ from that trace.

Look for a destination that repeats. If a trace reaches its redirect limit without a repeated URL, you may have an unnecessarily long chain rather than a simple two-address loop. Before sharing any trace, remove cookies, authorization values, customer details, and private query parameters. Do not send password-reset, checkout-session, or signed URLs to a public redirect checker.

## Fix the rule that sends visitors back

Choose the intended final URL first. Then identify which system owns the instruction that moves away from it. The owner might be the domain-forwarding service, hosting platform, content delivery network, application, or login provider. Save the current configuration before changing it, and test one correction at a time.

- **Root domain and `www` alternate.** Check opposing hostname or forwarding rules. Both entry addresses should converge on one intended host.
- **HTTP and HTTPS alternate, or HTTPS repeats through a proxy.** Check origin redirects and proxy encryption settings. The proxy and origin must agree on secure transport.
- **A path gains and loses its final slash.** Check hosting and application slash rules. One path form should be accepted without a return redirect.
- **A language prefix appears and disappears.** Check language selection, stored preference, and URL normalization. The selected language route should remain stable.
- **Login and account pages alternate.** Check session recognition, cookie scope, and callback settings. A valid session should reach the intended page.

These patterns identify places to investigate, not a diagnosis for every site. For example, Cloudflare documents a specific failure in **Flexible** mode: it connects to the origin over HTTP, while the origin redirects that request to HTTPS. The browser can keep receiving a redirect to the same HTTPS address. Ask the host to align the origin certificate and encryption configuration using the provider's instructions. Do not disable HTTPS or certificate validation as a shortcut. Our [SSL certificate explainer](./ssl-certificate-meaning) covers the separate certificate check.

Runner's own web routing source illustrates another conflict. Its language redirect constructs the chosen localized URL in the same trailing-slash form that the server accepts. Otherwise, a language rule could add a slash that a normalization rule immediately removes. The server also skips language selection when the URL already has a supported language prefix. These are application routing decisions; changing a DNS record would not change either rule.

That example is not a promise that Runner automatically repairs redirects in every storefront. It shows why the useful question is specific: **which instruction sends this request back, and where is that instruction configured?** Give the trace to the person who controls that layer. Keep unrelated DNS records, payment settings, and working security controls unchanged.

## Verify the storefront, not just the homepage

After the correction, repeat the exact failing URL in the original browser and a fresh session. Check both the final address and the page content. A response that stops redirecting but lands on an error page, login screen, or unrelated homepage is not the intended recovery.

Use a small acceptance checklist before sending customers back:

- Open both the root domain and `www` if both are intended entry points. Confirm they reach the chosen address with working HTTPS.
- Open a direct product link, including a previously shared campaign link with harmless test parameters.
- Check the language route and signed-in state that originally failed, if either mattered.
- Add a product to the cart and follow the checkout path. Stop before payment unless you have an authorized transaction test.
- Recheck any old URL whose redirect you changed. It should reach the relevant replacement without returning to the old address.

In Runner, use the [custom-domain guide](https://www.runnerai.com/docs/en/guides/storefront-and-publishing/custom-domains) to distinguish attaching an address from verifying its routing and ownership. A connected-domain status does not establish that every application route or checkout step works. Follow the [live-store and checkout guide](https://www.runnerai.com/docs/en/guides/storefront-and-publishing/live-store-and-checkout) for that separate check.

If you are evaluating domain support rather than repairing an incident, see [connecting a domain to a Runner website](https://www.runnerai.com/features/how-to-connect-domain-to-website). For support, send the failing URL with sensitive parameters removed, the redirect sequence, the time of the check, and the browser-state comparison. Those details let someone investigate the conflicting decision instead of guessing from an error screenshot.

## Related questions

### Will clearing cookies fix too many redirects?

It can help when stored session or preference data triggers the failing route. Clear data for the affected site rather than every website, and expect to sign in again. If a fresh session works but the normal customer flow fails again after login or language selection, the application still needs investigation. Clearing cookies does not repair conflicting server rules.

### Is this the same as DNS propagation?

No. DNS determines where a hostname resolves; redirects tell a browser which URL to request next. A recent DNS change can send visitors to an old server that has different redirect rules, so both can matter during a move. Compare the resolved destination and redirect sequence separately. A repeated URL pattern is a reason to inspect routing, not simply wait longer.

### Does a 301 or 302 response mean the site is broken?

No. These response codes can represent intentional redirects. The important checks are the destination and whether navigation finishes at the intended content. Other redirect codes, including 307 and 308, can also appear. Do not change every redirect to a different status code merely to suppress the error; a different code can still point to the same loop.

### What if I do not own the website?

Compare a private window and another browser, then contact the site's support team if the failure continues. Include the public address and error wording without sharing login tokens or private links. You cannot correct the site's server configuration from your browser. Keep browser security protections enabled rather than weakening them to work around too many redirects.