Security
HTTPS redirect mistakes: loops, chains and host changes that hurt a site
HTTPS redirect mistakes usually come from several layers trying to canonicalize the same request without agreeing about scheme or hostname. A redirect loop, unexpected downgrade, or wrong-host jump is easier to fix when you capture the chain and assign one layer primary ownership of each rule.
Capture every status and Location header
Use curl or browser network tools to follow the redirect chain from HTTP and HTTPS, apex and www, and any legacy hostname. Write down the exact sequence of status codes and Location headers.
Loops often reveal two components alternating between different canonical beliefs.
Account for reverse-proxy scheme headers
When TLS terminates at a load balancer, CDN, or reverse proxy, the origin may see plain HTTP while the visitor used HTTPS. Configure trusted forwarded-protocol handling so the application does not redirect an already-secure request back through the proxy.
Trust proxy headers only from the controlled proxy path.
Remove duplicated redirect ownership
A CDN rule, nginx/Apache rule, WordPress plugin, application framework, and control panel can all enforce HTTPS/www. Pick a clear canonical layer and simplify the others.
Preserve path and query strings intentionally and avoid broad regexes that redirect assets or challenge endpoints incorrectly.
Test permanent status only after behavior is correct
Browsers and search engines can cache permanent redirects. Use temporary responses while debugging, then publish the intended permanent code and verify canonical tags/sitemap match the final URL.
- Capture the whole chain.
- Handle proxy scheme correctly.
- Choose one canonical owner.
- Promote to permanent only after testing.