Skip to content
Website Rescue Rescue

SSL and HTTPS Problems

Too many redirects after enabling SSL

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

Too many redirects after enabling SSL usually means HTTPS and HTTP rules are fighting—often Cloudflare Flexible SSL plus a force-HTTPS plugin, or mismatched www/non-www and WordPress site URLs. Align WordPress to https, set Cloudflare to Full or Full (Strict) with a valid origin cert, and remove duplicate force-SSL redirects.

Browsers show ERR_TOO_MANY_REDIRECTS when each response bounces the client to another URL until the limit is hit. Right after an SSL cutover, the loop is almost always caused by proxy SSL mode, plugin redirects, and siteurl/home disagreeing about http vs https or www. This guide is the SSL-era playbook; the general server-errors too-many-redirects article covers non-SSL redirect loops.

Intermediate

What the error means

A redirect loop happens when URL A sends you to B and B sends you back to A (or around a longer cycle). After SSL is enabled, WordPress may redirect to https while the edge proxy reconnects to the origin on http and the origin redirects to https again—classic with Cloudflare Flexible SSL. Force-HTTPS plugins, Really Simple SSL–style fixes, host panel “HTTPS redirect,” and www/non-www canonical rules can stack on top of WordPress siteurl/home values. The browser never reaches stable content; DevTools shows a long 301/302 chain. This ssl-errors guide assumes the loop started with certificate or HTTPS enforcement changes, not an unrelated plugin redirect fight on plain HTTP.

Common symptoms

  • Browser error ERR_TOO_MANY_REDIRECTS or “too many redirects” right after forcing HTTPS
  • DevTools Network shows alternating http↔https or www↔non-www 301/302 chains
  • Site works briefly with Cloudflare paused or Flexible mode changed to Full
  • wp-admin login loops while some cached front-end pages still load
  • Problem began when SSL was enabled, Really Simple SSL (or similar) was installed, or Cloudflare was connected
  • Incognito fails the same way, ruling out a single stale cookie alone—though cookies can worsen admin loops
  • Origin loads on a temporary URL or direct IP test while the public hostname loops

Most likely causes

  1. 01 Cloudflare Flexible SSL terminating HTTPS at the edge while origin redirects to HTTPS
  2. 02 Force-HTTPS plugins plus host or Cloudflare Always Use HTTPS all rewriting the same requests
  3. 03 WordPress siteurl/home still set to http:// while edge rules force https://
  4. 04 www and non-www redirects stacked with HTTP→HTTPS rules in the wrong order
  5. 05 Load balancer or reverse proxy HTTPS detection misread so WordPress keeps redirecting
  6. 06 Mixed page-cache entries storing redirect responses for the wrong scheme
  7. 07 Incorrect FORWARD/HTTPS detection when multiple security plugins fight over wp-config constants

What changed before the problem started

  • SSL certificate installed or “force HTTPS” enabled in the host panel
  • Cloudflare proxy enabled or SSL/TLS mode set to Flexible
  • Really Simple SSL or another HTTPS fixer activated
  • WordPress Address / Site Address edited or search-replaced during migration
  • www canonical redirect added on top of existing HTTPS redirects
  • CDN or page cache left holding old redirect responses

Troubleshooting steps

  1. 01

    Confirm a redirect loop in DevTools

    Open Network, reload, and look for a repeating chain of 301/302 between two or more URLs (http/https or www/apex). Note every Location hop before changing production settings.

  2. 02

    Set WordPress URLs to https explicitly

    In wp-config.php or Settings → General (when reachable), set WordPress Address and Site Address to the https:// canonical host you want—including the correct www or non-www choice. Matching scheme and host is the foundation; plugins cannot paper over a permanent http siteurl behind HTTPS enforcement.

  3. 03

    Fix Cloudflare SSL mode before chasing plugins

    If Cloudflare proxies the domain, switch SSL/TLS mode from Flexible to Full or Full (Strict) once the origin has a valid certificate. Flexible + origin HTTPS redirects is a common instant loop. Pause Cloudflare briefly only as a diagnostic, not a permanent fix.

  4. 04

    Disable duplicate force-HTTPS plugins and rules

    Turn off extra SSL-forcing plugins one at a time, and temporarily disable host “force HTTPS” or Cloudflare “Always Use HTTPS” while testing—leave a single enforcement layer once stable. Multiple enforcers create loops even when each rule looks correct alone.

  5. 05

    Pick one canonical host (www or apex) and stick to it

    Ensure DNS, WordPress URLs, and redirect rules all agree on either www or non-www. A www redirect that lands on http, plus an HTTPS redirect back to www, will loop forever.

  6. 06

    Purge caches and retest in a fresh session

    Purge Cloudflare and WordPress page caches, then test in a clean Incognito window. Stale redirect responses and old cookies can make a fixed loop appear broken for minutes.

When to stop troubleshooting

Escalate if you cannot reach wp-admin even via hosts-file or origin URL tricks, Cloudflare and host panels disagree on SSL mode, or checkout/login stay looping through revenue hours. Bring the DevTools redirect chain, Cloudflare SSL mode, WordPress siteurl/home values, and a list of HTTPS-forcing plugins.

Information to collect before requesting help

  • 01 Full redirect chain from DevTools (every Location URL)
  • 02 Whether Cloudflare (or another proxy) sits in front of the origin
  • 03 Cloudflare SSL/TLS mode if applicable (Flexible, Full, Full Strict)
  • 04 WordPress siteurl and home values (http vs https, www vs apex)
  • 05 Force-HTTPS plugins and host-level HTTPS redirect settings
  • 06 When SSL was enabled and what else changed in that window
  • 07 Whether pausing the proxy or disabling one SSL plugin breaks the loop

How a professional repairs the problem

We map the redirect chain, align WordPress https URLs with a single canonical host, correct proxy SSL mode (Full/Strict with a valid origin cert), and collapse duplicate force-HTTPS layers. Caches are purged and login/checkout retested so the cutover stays stable—not Flexible-SSL dependent.

Frequently asked questions

Why did enabling SSL suddenly cause a redirect loop? +
Something still believes the site is http while something else forces https—often Flexible SSL at the edge plus a plugin or WordPress redirect to https. Align scheme everywhere and use Full/Strict with an origin certificate.
Is this the same as server-errors/too-many-redirects? +
Same browser symptom, different usual cause. That general guide covers non-SSL redirect fights. Use this ssl-errors guide when the loop started with HTTPS, certificates, or Cloudflare SSL mode changes.
Is Cloudflare Flexible SSL safe for WordPress? +
It is a common source of loops and mixed trust. Prefer Full or Full (Strict) with a valid certificate on the origin, especially for login and checkout.
Will clearing cookies fix too many redirects? +
Sometimes for admin cookie loops, but if DevTools shows an http/https bounce, cookies alone will not fix the server configuration. Repair SSL mode and site URLs first.
Can www redirects cause this after SSL? +
Yes. Stacking www↔apex redirects with HTTP→HTTPS rules in conflicting directions is a frequent post-SSL failure. Choose one hostname and one scheme, then redirect everything toward that pair once.
Should I install another force-SSL plugin to fix the loop? +
No. Extra enforcers usually deepen the loop. Remove duplicates, set correct https URLs, and keep a single redirect layer.

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.