ERR_TOO_MANY_REDIRECTS means the redirect layers on your site are pointing at each other, most often a CDN or proxy terminating SSL while WordPress or the server forces HTTPS. The browser gives up and nobody can reach the site. We trace the loop hop by hop and fix the layer that is wrong for $49-$99, usually in about 36 minutes.
A redirect is one server telling the browser "go to this other address instead." A redirect loop happens when rules from different layers of your stack point at each other: WordPress redirecting visitors to the address stored in its settings, the web server enforcing www or HTTPS, a plugin forcing SSL, and a CDN like Cloudflare converting protocols in front of everything. Each layer sees only its own rule and believes it is doing the right thing. As the MDN documentation notes, a loop spread across several servers is invisible to each server individually, so it is the browser that finally detects it, gives up, and shows ERR_TOO_MANY_REDIRECTS. On WordPress the overwhelming majority of these loops are HTTPS-related: something in front of the site terminates SSL while something behind it insists on redirecting to HTTPS, and the request bounces between the two forever. The site is completely unreachable for every visitor and for Googlebot until the loop is broken, but the fix is configuration, not damage, and your content is untouched.
Fix This Error Now →WordPress Too Many Redirects can be caused by several issues. Here are the most common.
The classic. In Flexible mode Cloudflare talks to your origin over plain HTTP, per Cloudflare's own documentation. If WordPress or the server then redirects that HTTP request back to HTTPS, the cycle repeats forever: visitor asks for HTTPS, origin sees HTTP, origin redirects to HTTPS. The durable fix is Full Strict mode with a real certificate on the origin.
When a load balancer or CDN terminates SSL, the connection reaching WordPress is plain HTTP, so WordPress concludes the visitor is not on HTTPS and redirects them there, forever. The WordPress documentation warns FORCE_SSL_ADMIN loops in this setup and prescribes the fix: honor the X-Forwarded-Proto header in wp-config.php so WordPress trusts the proxy's protocol.
WordPress canonical-redirects visitors to the exact address in its siteurl and home settings. If those still say http after an SSL setup, or the bare domain while the server enforces www, WordPress redirects one way and the server redirects straight back. Two rules, each correct alone, looping together.
Years of migrations leave layered rules: an old non-www to www rule, a newer HTTPS rule, a domain-change rule from two redesigns ago. When a later rule undoes what an earlier one did, requests circle. Loops here are visible in the redirect chain because the same URLs alternate.
Plugins like Really Simple SSL add their own HTTPS redirect from inside WordPress. That is fine when nothing else redirects, but combined with a server rule or a CDN setting doing the same job with a slightly different idea of the canonical URL, the layers disagree and the browser pays for it.
Redirect managers with hundreds of imported rules can quietly contain a circle: A sends visitors to B, and some later rule sends B back to A. Everything works until a visitor hits the poisoned path. These loops affect specific URLs rather than the whole site, which is itself a diagnostic clue.
Cloudflare's Always Use HTTPS and HSTS settings redirect visitors to HTTPS at the edge. Per Cloudflare's troubleshooting docs, they loop when the origin server redirects HTTPS back to HTTP, or when the SSL mode is off while HSTS forces the protocol up. Redirect rules and Page Rules can add further contradictions on top.
Browsers and CDNs remember redirects, so a loop can appear fixed on one device and alive on another, or persist after the configuration is already correct. If the loop was real yesterday, today's test must use a purged CDN cache and a clean browser profile before concluding anything.
Trace the loop instead of guessing: follow the redirect chain hop by hop with a tracer, reading each Location header to see exactly which URLs alternate and which layer issued each redirect
Map every layer that is allowed to redirect on your stack: the CDN's SSL and redirect settings, the server's rewrite rules, WordPress's own canonical redirect, and any SSL or redirect plugin
Check the Cloudflare SSL mode first when Cloudflare is in front. If it is Flexible, we install a proper certificate on the origin and move to Full Strict, which removes the structural cause rather than patching around it
Correct the siteurl and home values directly in the database, or pin them with WP_HOME and WP_SITEURL in wp-config.php, so WordPress and the server agree on one canonical address
Add the X-Forwarded-Proto handling from the WordPress documentation to wp-config.php when SSL terminates at a proxy or load balancer, so WordPress stops redirecting visitors it wrongly believes are on HTTP
Consolidate the server's redirect rules so exactly one layer owns the HTTP to HTTPS and www decisions, in a single hop, and retire the legacy rules that contradict it
Disable duplicate force-SSL plugin redirects once the server or CDN handles the job, keeping the plugin's content rewriting if it is still useful
Audit redirect-manager rules for circles when the loop affects specific URLs rather than the whole site
Purge the CDN cache and every site cache, then verify in a clean browser profile so a remembered redirect cannot fake a still-broken site
Confirm the final redirect chain is one hop to the canonical HTTPS address from every entry point: http, https, www, and bare domain
Fixed in 2 hours or your money back. We do not waste time.
No hourly billing. You know the price before we start.
Cannot fix it? You do not pay. Zero risk to you.
Our Broken Pages & Error Repair team has fixed thousands of sites with this exact issue. 2-hour turnaround, guaranteed.
The browser followed redirect after redirect, realized the chain was never going to end, and gave up. Chrome shows ERR_TOO_MANY_REDIRECTS with the message that the page redirected you too many times; Firefox says the server is redirecting in a way that will never terminate. The loop is real and server-side: two or more layers of your site's stack are each redirecting to a URL the other one redirects away from, and no server can see the whole picture. Only the browser, and a redirect tracer, can.
Something in the stack changed even if you did not touch WordPress. The most common triggers we see: the host enabled or renewed SSL and added an HTTPS redirect at the server level, someone flipped a Cloudflare setting like Always Use HTTPS or the SSL mode, a security or SSL plugin updated and re-enabled its own redirect, or a migration copied old redirect rules onto a new server. The loop begins the moment two layers disagree, and neither layer alone looks wrong.
Because Flexible mode structurally guarantees a loop the moment your origin forces HTTPS. In Flexible mode Cloudflare serves visitors over HTTPS but fetches your origin over plain HTTP, per Cloudflare's documentation. WordPress sees an HTTP request, redirects it to HTTPS, Cloudflare fetches over HTTP again, and the cycle never ends. The clean fix is a certificate on your origin and Full Strict mode. Free origin certificates make Flexible mode obsolete for almost everyone.
Redirects get remembered. Your browser may have cached a working redirect while another visitor's browser cached the looping one, or a CDN edge location is still serving the old redirect after the fix. This is why we always purge the CDN and test in a clean browser profile before declaring victory, and why you should not conclude the site is fixed or broken from one device's behavior.
That is a different problem with a different fix. A sitewide redirect loop lives in the HTTPS and canonical URL layers. A loop that only affects wp-login.php, where you log in successfully and bounce straight back to the form, is usually an authentication cookie failing to survive the redirect. We cover that mechanism separately on our WordPress login redirect loop page, and it is one of our most common quick fixes.
The loop blocks the browser, not the site's files or database. Everything we need is reachable underneath: siteurl and home can be corrected in the database through phpMyAdmin, WP_HOME and WP_SITEURL can be pinned in wp-config.php over FTP, server redirect rules live in .htaccess or the server config, and CDN settings live in the CDN dashboard. No working wp-admin is required at any step, which is exactly how we repair these.
Your content is untouched: a redirect loop is pure configuration, and nothing is written to or removed from your database. SEO is time-sensitive though. While the loop runs, Googlebot cannot reach any page, and an outage that stretches to days starts costing crawl frequency and rankings. Fixed within hours, the SEO impact is negligible. That urgency is the main reason not to spend a week trial-and-erroring it.
Most redirect loop fixes cost $49-$79. Correcting site URL values, an SSL mode, or a duplicated force-HTTPS rule sits at the low end. Untangling years of stacked rewrite rules across a CDN, server config, and multiple plugins costs $79-$99 because we map and consolidate the whole redirect ownership rather than patching one symptom. Firm quote before we start, and if we cannot fix it, you pay nothing.
Our average redirect loop fix takes about 36 minutes. Tracing the chain takes minutes and immediately shows which layers are fighting. Most of the remaining time goes into fixing the structural cause, such as installing an origin certificate to leave Flexible mode, and then purging caches and verifying from a clean profile that every entry point resolves in a single hop.
Give exactly one layer ownership of each redirect decision. Let the server or CDN handle HTTP to HTTPS in one place, keep WordPress's site URLs set to the final canonical HTTPS address, and remove plugin redirects that duplicate the job. If you use Cloudflare, run Full Strict with a valid origin certificate rather than Flexible. After any migration or SSL change, run a one-hop check: every variant of your domain should reach the canonical URL in a single redirect.
Every technical claim on this page traces back to primary documentation and the named vendor references below.
Plugin, theme, critical error, PHP, and update fixes in one place.
Visit the WordPress Repair hub →Get wordpress too many redirects fixed today. Expert engineers. 2-hour guarantee.
Fix My Error Now →