Short answer: a redirect loop after an HTTPS migration almost always means two layers are fighting over the scheme. WordPress, a plugin or .htaccess forces HTTPS, while a proxy, CDN or load balancer talks to the server over plain HTTP and hides that the visitor is already on HTTPS. The server sees HTTP, redirects to HTTPS, and the cycle repeats. Find which layer redirects, tell WordPress the truth about the connection, and remove the duplicate rule.
Why does an HTTPS move cause a redirect loop?
The browser asks for https://example.com/. The request passes through Cloudflare or a host proxy, which forwards it to the origin as plain HTTP. WordPress or the server rules see HTTP and answer with a 301 to the HTTPS address. The browser asks again, gets the same answer, and gives up with ERR_TOO_MANY_REDIRECTS.
It also happens without a proxy. If the Site Address in Settings is still http:// while a plugin or server rule forces https://, WordPress can redirect the canonical URL back to HTTP. Two rules, one pointing each way, make a loop.
How do you see where the loop is?
Do not guess in the browser, because it caches 301s. Use curl and read the chain:
curl -sIL --max-redirs 6 https://example.com/ | grep -iE "^(HTTP|location|server|cf-)"
A loop looks like this, with the same location repeating until curl stops at the limit:
HTTP/2 301 location: https://example.com/ server: cloudflare HTTP/2 301 location: https://example.com/ server: cloudflare
A 301 pointing at the exact URL you requested tells you the origin is redirecting even though the visitor is already on HTTPS. The server and cf- headers tell you whether a CDN sits in front. Then compare with a request straight to the origin if you can reach it.
Which layer is causing it?
| Symptom | Likely cause | Fix |
|---|---|---|
| Loop only behind Cloudflare | SSL mode set to Flexible while the origin also forces HTTPS | Install a certificate on the origin and set SSL/TLS mode to Full (strict) |
| Loop behind a host proxy or load balancer | WordPress does not see the forwarded HTTPS header | Set $_SERVER['HTTPS'] = 'on' in wp-config.php when X-Forwarded-Proto is https |
| Loop on every URL, no proxy | Home or Site Address still http while a rule forces https | Set both addresses to https, remove the conflicting rule |
| Loop only on some URLs | A redirect plugin or old migration rule with a stale pattern | Disable it, test, then rebuild the rule once |
What are the exact fix steps?
- Test with curl as above and note which layer answers each hop.
- Put the site back in a working state first. If you cannot log in, set
WP_HOMEandWP_SITEURLinwp-config.phpto the https address. - If you use Cloudflare, switch SSL/TLS to Full (strict) and confirm the origin has a valid certificate. Flexible mode with an origin redirect is the classic cause.
- If a proxy terminates TLS, add this above the line that says to stop editing in
wp-config.php:if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; } - Keep one redirect to HTTPS only. Pick the server rule, the CDN rule, or the plugin, and remove the others.
- Clear the page cache, the CDN cache and your browser cache, then rerun curl. You want one 301 at most, then a 200.
Can the loop hurt search visibility?
Yes. Googlebot follows a limited number of redirect hops and then treats the URL as an error, so a looping page cannot be crawled or kept fresh in the index. If the loop sits unnoticed for days after a launch, pages can drop out of search. Google's guidance for moving a site is to redirect each old URL to its new equivalent with a permanent redirect and to keep that mapping clean.
After you fix the loop, confirm the pages still return 200 and are not carrying a leftover noindex from staging. The free noindex checker reads the meta tag, the X-Robots-Tag header and robots.txt for a URL in one go. Then check the sitemap and Search Console for crawl errors on both the http and https properties.
What do you tell the client?
Keep it short and factual. Something like: "After the move to HTTPS, two settings were both redirecting visitors, so the page kept bouncing. I removed the duplicate, tested every key page, and checked that Google can still read the site. Rankings should not be affected, and I will check Search Console again in a week." Do not promise that nothing was lost unless you checked.
How does quietwatch catch this?
quietwatch fetches each client site every day and flags redirect problems, error statuses, noindex tags and robots blocks, so a loop introduced by a migration shows up the next morning rather than at the next client call. The free tool above is the place to start, and what quietwatch checks every day lists the daily checks.