When WordPress hits ERR_TOO_MANY_REDIRECTS (or “this page isn’t working… redirected you too many times”), the browser and the server keep sending each other to a different URL and never finish. The public site, Admin, or both can fail. This often shows up after a domain change, SSL cutover, CDN add-on, or a www / non-www switch.
Work this checklist in order. Prefer staging when you can reproduce the loop there. Take a backup before editing .htaccess, changing siteurl/home, or disabling security plugins on production. Once the site loads on one clean URL, restore any settings changed only for testing and recheck homepage, login, and HTTPS. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix after you can authorize access.
Define what failed
- Note whether the loop hits the homepage, only
/wp-admin, only HTTP, only HTTPS, or only www versus the apex domain.
- Try a private window with extensions disabled. A stale HSTS or cookie can look like a server loop.
- If nothing on the host responds at all, or you see 403/500/502 instead of a redirect loop, use the site down or 403/500/502 checklist first.
- If Admin alone fails with a login loop (not a browser “too many redirects” error), see admin login not working.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| HTTP ↔ HTTPS bounce forever | SSL / proxy headers | Host or CDN “Flexible SSL” vs Full; WordPress forcing HTTPS while the edge terminates SSL |
www ↔ apex bounce | Canonical host rules | One place owns the redirect: DNS/CDN or WordPress or .htaccess—not all three |
| Public site loops; a direct IP or host temp URL works | siteurl / home | Database or wp-config.php URL constants vs the live hostname |
| Only Admin loops | Admin SSL / cookies | FORCE_SSL_ADMIN, reverse-proxy HTTPS detection, security plugin login redirects |
| Started right after a plugin or CDN change | Plugin or edge rules | Disable the last redirect/SSL/CDN plugin on staging; review CDN page rules |
Safe triage order
- Prove it is a server loop. Retest in a private window and a second browser/network. If a clean profile loads, clear site cookies for that domain and retry before changing the server.
- Capture the redirect chain. From another network, ask your host for help reading the redirect chain, or use a simple request tool that shows each
Location hop. Write down whether the bounce is HTTP↔HTTPS, www↔apex, or trailing-slash only. Do not keep retrying from the same browser until the chain is clear.
- Check WordPress home and site URL. Check that Site Address (home) points to your public site and WordPress Address (siteurl) points to the WordPress installation. Use the intended HTTPS hostname and preserve each correct path; a subdirectory installation may need different paths. After migrations they often still point at the old domain or at
http:// while the edge forces https://. Prefer a host-approved way to update them (Admin when reachable, or host tools). If you must set them in wp-config.php temporarily for recovery, use the correct HTTPS URL for each setting, including any required WordPress subdirectory, and remove temporary overrides once the database values are correct.
- Align SSL termination with WordPress. If a CDN or load balancer terminates HTTPS and talks HTTP to the origin, WordPress must detect HTTPS from the proxy headers your host documents—not by stacking three different “force SSL” plugins. “Flexible” edge SSL that rewrites to HTTP origin while WordPress also forces HTTPS is a classic loop. Ask the host or CDN which mode is correct for WordPress on that plan, then keep a single force-HTTPS path.
- Reduce competing redirect rules. On staging, disable redirect, SSL, and “canonical URL” plugins one at a time and retest. Check CDN page rules and host panel redirects for the same hostname. On Apache, back up
.htaccess before testing; ask the host which rule is looping. Restore the file after the test—it may contain security and rewrite rules beyond WordPress defaults.
- Confirm one canonical hostname. Pick either
www or apex and make DNS, CDN, WordPress URLs, and server redirects agree. Two layers both “fixing” the opposite host create a loop even when each rule looks correct alone.
- Retest the full path. Load the homepage and
/wp-login.php over HTTPS on the chosen hostname, submit a test login on staging if needed, then restore any temporary plugin or rule changes and retest once more.
Common causes
siteurl / home still on HTTP or the old domain after SSL or migration.- CDN “Flexible SSL” (or similar) plus a WordPress or plugin HTTPS redirect.
- Both the host and WordPress redirecting
www ↔ apex in opposite directions.
- Multiple SSL/redirect plugins each adding their own rules.
- Hard-coded redirects in
.htaccess or nginx config that fight the CDN.
- Admin-only loops from
FORCE_SSL_ADMIN behind a proxy that does not pass HTTPS detection correctly.
- Cached 301s at the CDN or browser after you already fixed the origin—purge CDN cache and retest in a private window.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help with one clearly defined redirect-loop issue on one WordPress site. Name the exact browser error, whether HTTP/HTTPS or www/apex is bouncing, when it started, and the last change you made (migration, SSL, CDN, plugin). We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full rebuilds, new custom features, full migrations, account-wide host outages, and multiple unrelated issues are outside this offer. If a plugin update broke redirects along with other features, see also plugin update broke WordPress site.
Related checks
If the checks do not identify the cause, send your host the failing URL, whether the bounce is HTTP/HTTPS or hostname-related, the start time, and any redirect-chain notes. Suspected compromise needs a security investigation as well as restoring a single clean URL.