What is actually happening?
A web server can use HTTP responses 301, 302, 303, 307 or 308 to tell the browser to open another URL. If the destination redirects back or the chain becomes too long, the browser stops and displays ERR_TOO_MANY_REDIRECTS.
If you are a visitor
- Refresh the page and confirm the URL is correct.
- Open it in a private window. If it works there, a cookie or login session may be involved.
- Clear data or cookies only for the affected domain and try again. Clearing all browser data is unnecessary.
- Temporarily disable a VPN, proxy or traffic-modifying extension to test whether it affects the request.
- If the same error occurs on other devices and networks, it probably originates at the website.
If you manage the website
First check the server-side redirect chain using the website checker. For a successful chain splet.me displays each HTTP step from → to. For a loop or excessive chain, it can also show the partial sequence observed before stopping.
Most common redirect loops
- HTTP ↔ HTTPS: the application forces HTTP while the CDN or proxy forces HTTPS.
- www ↔ non-www: two rules disagree about the canonical hostname.
- Trailing slash: one rule adds
/and another removes it. - CDN ↔ origin: the proxy and origin disagree about the protocol or hostname.
- Login and cookies: the application redirects an unauthenticated visitor to login, but a broken session or callback sends them back again.
- Language or location: two localization rules conflict.
301, 302, 307 or 308?
The status code alone does not create a loop: the redirect target matters. Google treats 301 and 308 as permanent redirects, and 302 and 307 as temporary ones. For URL migrations Google recommends server-side permanent redirects and keeping chains as short as possible, ideally jumping directly to the final URL.
What can our checker see—and what can't it?
It follows a limited number of server-side HTTP redirects with a Location header. It does not execute JavaScript, simulate a complete browser profile, or guarantee the same results for redirects depending on cookies, login, geolocation or a particular User-Agent. The result is a diagnostic signal, not a complete picture of every possible visitor.
Frequently asked questions
Does clearing cookies always fix ERR_TOO_MANY_REDIRECTS?
No. It helps mainly with loops caused by a broken session or cookie. Server-side misconfiguration must be fixed by the website owner.
Is a 301 redirect itself bad for SEO?
No. A correct permanent redirect is a normal way to move URLs. Problems arise from wrong destinations, loops and unnecessarily long chains.
Can splet.me detect JavaScript redirects?
No. The checker currently follows server-side HTTP redirects with the Location header and does not run JavaScript.