ERR_TOO_MANY_REDIRECTS
The browser followed redirect after redirect and stopped. Two things disagree about where this URL should live, and each is confident.
ERR_TOO_MANY_REDIRECTS
Follow the chain from the command line and look at where it repeats. The loop is almost always WordPress and something in front of it - a proxy, a plugin, or a server rule - each rewriting the other's answer.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| siteurl and home disagree | The two options differ by www, by scheme, or by a trailing slash. WordPress redirects to whichever it considers canonical, forever. | Set both to the same address, including scheme. This is the first thing to check after a migration. |
| A proxy terminating HTTPS without saying so | The chain alternates between http and https. WordPress sees a plain request, redirects to HTTPS, the proxy hands it back as plain. | Trust the forwarded protocol header so WordPress knows the original request was already secure. |
| Two redirect sources fighting | A rule in a plugin sends /a to /b while a server rule sends /b back to /a. Neither is wrong on its own. | Remove one of them. Redirects belong in one layer, and the one closest to the edge is usually the right home. |
| A cached redirect | The loop persists after the rule is removed, and a private window or a different browser behaves differently. | Clear the page cache and any 301s the browser has stored. Permanent redirects are cached aggressively and by design. |
| A login loop from a cookie mismatch | Only wp-admin loops, and only after signing in. The cookie domain does not match the address being browsed. | Align the cookie domain with the site URL, and make sure sign-in happens on the same host the visitor stays on. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
Follow the chain and watch where it repeats
The repeating pair is the answer. Everything before it is scenery.
curl -sIL https://example.com | grep -Ei '^(HTTP|location)'
Compare what WordPress thinks its address is
These two options are the most common source of a loop after any move.
wp option get siteurl wp option get home
If a proxy terminates TLS, tell WordPress
Without this WordPress believes every request arrived unencrypted, and redirects accordingly.
wp config set FORCE_SSL_ADMIN true --raw
Take plugin redirects out of the picture
Deactivating the redirect plugin is faster than reading its rules.
wp plugin deactivate redirection
Clear the caches before you judge whether it worked
A cached 301 will happily reproduce a loop you have already fixed.
wp cache flush
What the platform takes off the list.
Redirects are held in one layer and applied at the edge before WordPress loads, so there is no second set of rules quietly disagreeing with the first. HTTPS terminates in front and the forwarded protocol is passed through, which removes the http/https version of this loop entirely, and moving a domain updates siteurl and home together rather than leaving one behind.
Questions, answered.
Why does it work in one browser and not another?
It started right after I moved to HTTPS.
Only the login page loops. Why just that one?
How do I fix it if I cannot log in at all?
If that was not it.
These fail in ways that look similar from the browser.