Skip to content
Website Rescue Rescue

Server Errors

ERR_TOO_MANY_REDIRECTS

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Direct answer

ERR_TOO_MANY_REDIRECTS means the browser is stuck in a redirect loop — usually mismatched HTTP/HTTPS rules, wrong WordPress siteurl/home values, caching/CDN redirects, or a plugin fighting the server — so clear site cookies for the domain, then align URL and proxy settings before deleting random plugins.

A redirect loop never finishes loading the page; Chrome reports ERR_TOO_MANY_REDIRECTS while other browsers show similar “too many redirects” messages. This server-errors guide covers the general case: cookies, HTTPS termination, reverse proxies, and plugin redirect rules. If the loop started only after forcing SSL, also see the SSL-focused peer guide — but start here when the cause is unclear or not limited to certificate activation.

Intermediate

What the error means

Each response sends the browser to another URL (301/302/307/meta refresh). When rules disagree — HTTP→HTTPS at the host while WordPress still forces HTTP, www↔apex fighting each other, or a CDN Flexible SSL mode bouncing against origin redirects — the chain never reaches content. Cookies that store “force SSL” or login state can participate in the loop, which is why clearing site cookies often changes the symptom. This is different from a single intentional HTTPS redirect and different from a site that is merely slow or returning 500. The SSL-category “too many redirects after enabling SSL” guide narrows in on certificate/HTTPS cutover mistakes; here we triage all common ERR_TOO_MANY_REDIRECTS causes on WordPress behind ordinary hosts and proxies.

Common symptoms

  • Browser shows ERR_TOO_MANY_REDIRECTS or “redirected you too many times”
  • DevTools Network lists a long chain of 301/302 responses with no final 200 document
  • Loop alternates between `http://` and `https://`, or `www` and apex, on every request
  • Incognito or another browser behaves differently until cookies sync
  • Problem began after SSL, CDN, migration, or security/redirect plugin changes
  • wp-admin redirects forever while a static file (for example a known CSS URL) still loads
  • Clearing cookies temporarily helps, then the loop returns after login or HTTPS revisit

Most likely causes

  1. 01 WordPress `siteurl` / `home` options disagree with the URL visitors use
  2. 02 Host or `.htaccess` HTTPS redirect fighting a plugin that also forces SSL
  3. 03 CDN/proxy SSL mode (for example Flexible) creating HTTP↔HTTPS ping-pong
  4. 04 www ↔ non-www redirects defined twice in DNS, CDN, and WordPress
  5. 05 Corrupt or aggressive cookies from caching, security, or membership plugins
  6. 06 Reverse proxy headers (`X-Forwarded-Proto`) not trusted, so WordPress keeps “upgrading” the URL
  7. 07 Old migration leaving hardcoded HTTP URLs plus a blanket HTTPS redirect

What changed before the problem started

  • SSL certificate installed or “Force HTTPS” enabled in host, plugin, or CDN
  • Cloudflare or CDN proxy toggled on; SSL/TLS mode changed
  • Site moved between hosts; siteurl/home still show the old scheme or domain
  • Security, redirection, or caching plugin installed or reconfigured
  • Added www canonical rules in two places at once
  • Cookie/plugin experiment on a membership or multilingual site

Troubleshooting steps

  1. 01

    Confirm a redirect loop in DevTools

    Open DevTools → Network, reload, and watch the document requests. Note each Location hop (http/https, www/apex, trailing slash). Success signal: you can write the repeating pair of URLs — that pair is what you must reconcile.

  2. 02

    Clear cookies for the site domain (and try a private window)

    In the browser, remove cookies for your apex and `www` hosts, then retry. Also test a fresh private window. If the loop disappears until you log in again, a plugin cookie or force-SSL cookie is involved. Success signal: logged-out homepage returns 200 after cookie clear.

  3. 03

    Align WordPress Address and Site Address with the public URL

    If you can reach wp-admin on a working URL, set Settings → General so WordPress Address and Site Address both match the canonical HTTPS URL you want. If admin is trapped in the loop, set `WP_HOME` and `WP_SITEURL` in `wp-config.php` to that same HTTPS URL (temporary constants) or update the options via host phpMyAdmin carefully. Success signal: one canonical URL loads without bouncing.

  4. 04

    Simplify HTTPS redirects to a single layer

    Temporarily disable extra Force SSL plugins. Keep either the host’s HTTPS redirect or WordPress’s, not both, while testing. Restore a default WordPress `.htaccess` if custom rewrite rules force scheme changes. Success signal: only one 301 to HTTPS appears, then a 200.

  5. 05

    Check CDN SSL mode and origin scheme

    If Cloudflare (or similar) is proxied, avoid Flexible SSL when origin already redirects HTTP→HTTPS — that pattern commonly loops. Prefer Full or Full (strict) with a valid origin certificate. Success signal: proxied hostname and DNS-only hostname both settle on the same HTTPS URL without a bounce storm.

  6. 06

    Disable redirect/security plugins via SFTP if admin is unreachable

    Rename folders for redirection, SSL, caching, and security plugins under `wp-content/plugins` one at a time. Retest after each rename. Success signal: identifying the plugin that reintroduces the loop when re-enabled.

When to stop troubleshooting

Hand off if you cannot edit wp-config, DNS, or the CDN SSL mode, redirect rules live in a locked host layer you cannot see, loops continue after plugin isolation and URL constants, or ecommerce checkout remains unusable past your window. Provide the redirect chain screenshot and a list of every Force-SSL switch you toggled.

Information to collect before requesting help

  • 01 Browser exact error text (ERR_TOO_MANY_REDIRECTS or equivalent)
  • 02 DevTools redirect chain (schemes and hostnames in order)
  • 03 Whether cookies/private window changed the symptom
  • 04 Current WordPress siteurl/home values (or wp-config URL constants)
  • 05 CDN proxy status and SSL/TLS mode
  • 06 Recent SSL, migration, or redirect-plugin changes
  • 07 Whether wp-admin and front end both loop

How a professional repairs the problem

A technician captures the redirect chain, clears cookie-related false leads, then collapses competing HTTPS/www rules across WordPress options, server config, and CDN SSL mode into one canonical URL. They isolate redirect plugins, fix proxy proto detection when needed, run serialization-safe URL corrections after migrations, and verify a clean 200 with an empty cookie jar on both apex and www.

Frequently asked questions

Will clearing cookies permanently fix the error? +
Only if a bad cookie was the sole cause. If server or WordPress rules still conflict, the loop returns on the next visit. Use cookie clearing to confirm and buy time, then fix the URL/redirect configuration.
How is this different from the SSL “too many redirects” guide? +
That peer guide focuses on loops that appear right after enabling certificates or Force HTTPS. This guide covers the broader ERR_TOO_MANY_REDIRECTS triage — cookies, proxies, plugins, and www rules — including cases unrelated to a fresh SSL install.
Can a caching plugin cause redirect loops? +
Yes. Cached 301s or “HTTPS everywhere” rules stored at the edge can keep looping after you fix WordPress. Purge CDN and plugin caches after each correction.
Why does only wp-admin loop? +
Admin-specific SSL or security plugins often force `FORCE_SSL_ADMIN` while front-end rules disagree. Align admin and public URLs and disable the conflicting admin-SSL plugin temporarily.
Is ERR_TOO_MANY_REDIRECTS a WordPress bug? +
Usually not core itself — it is conflicting configuration around WordPress. Core stores home/siteurl; hosts, CDNs, and plugins add more redirects on top.
Should I disable HTTPS to fix the loop? +
Prefer fixing forward to a single correct HTTPS URL. Falling back to HTTP can break HSTS-pinned browsers and is a last-resort diagnostic, not a destination.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.