When a WordPress HTTPS redirect loops, first identify which layer issues each redirect. Adding another redirect plugin can hide the original problem or create a second conflicting rule. CDN settings, reverse proxies, web-server rules, and WordPress can all participate.
A certificate warning is a different failure. Resolve the certificate and host configuration before redirect testing; do not ask customers to bypass a browser security warning.
Inspect One Representative URL
Choose a real public content path, including a harmless query parameter if your campaigns depend on them. Do not test only the homepage. The following examples use a placeholder domain:
curl -sS -I --max-time 15 'http://example.com/contact?utm_source=redirect-test'
curl -sS -L -I --max-time 15 --max-redirs 8 'http://example.com/contact?utm_source=redirect-test'
Record each status and Location header. Some servers treat HEAD differently from GET; if the results contradict the browser, repeat using GET and save headers with curl's -D option. Use no passwords, session tokens, or customer details in test URLs.
Classify the Failure
| Observed pattern |
Likely area to inspect |
What to prove |
| HTTP and HTTPS alternate |
Proxy scheme handling |
Origin recognizes trusted external HTTPS |
| www and apex alternate |
Competing canonical-host rules |
One preferred host at every layer |
| Every path ends at home |
Broad redirect target |
Original path maps to equivalent content |
| Query disappears |
Rule replacement behavior |
Required campaign parameters survive |
These are investigation leads, not diagnoses from headers alone. Compare CDN and origin configuration with the hosting team. Do not blindly trust arbitrary forwarded headers from the public internet; trust boundaries depend on the proxy setup.
Explanatory evidence sheet. Record your own observations.
Remove the Conflict at Its Owner
Choose the intended final scheme and host. Document which layer owns the canonical redirect and make other layers consistent. Export existing rules before changing one. A shared .htaccess snippet is not suitable for every Nginx, managed host, or CDN configuration.
If WordPress is configured with an old HTTP address, review its public URL and installation URL in context. They can legitimately differ on some installations. Use the domain-change checklist when the issue includes a changed host or database URLs.
Verify More Than the First Response
Google documents permanent redirects as a canonicalization signal. Use the appropriate permanent redirect for a permanent move, while avoiding unnecessary chains. The final page should be accessible, contain the intended content, and declare the correct canonical.
Check a post, form, product, account entry point, and static asset. For payment or API POST endpoints, follow the integration's exact URL requirements instead of assuming a browser redirect safely preserves the request.
Retest after the changed layer's cache is refreshed. Record the repaired chain alongside the original evidence. If the loop crosses infrastructure you do not control, send both traces for targeted WordPress troubleshooting rather than disabling HTTPS protections.
Sources checked September 27, 2026. Examples and diagrams are explanatory, not customer measurements.