A redirect loop means the browser keeps receiving instructions to visit another address without reaching a final page. With Cloudflare and WordPress involved, different layers may be enforcing conflicting versions of HTTPS, www or the login path.
Record the repeating pair before adding another rule. Once you know which addresses send the browser back to each other, you can identify whether WordPress, Cloudflare or the origin server owns each redirect.
Cloudflare, the host and WordPress can each redirect requests. The repair is to align the rule that handles the affected URL with one intended final HTTPS address.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Write down the two addresses in the loop
| Repeating pattern | Inspect | Next check |
|---|---|---|
| HTTP ↔ HTTPS | Edge encryption mode and origin redirects | How the proxy connects to the origin |
| www ↔ bare domain | Preferred hostname at each layer | Active WordPress URL and matching rules |
| Path A ↔ path B | Rule conditions and order | Whether a rule catches its own destination |
| Only old browser session loops | Cached redirect and stored policy | Clean session after live rules are corrected |
| Only login loops after a move | Session and URL configuration | Use the login migration guide |
Write down the repeating addresses
- Open the affected request in the browser Network panel.
- Follow redirect statuses and Location destinations.
- Record the first repeated pair or cycle.
- Classify it as scheme, hostname or path.
- Compare the rules at the layers responsible for those hops.
Inspect the redirect chain for one affected URL. A developer can use the browser’s Network panel to see each response and Location header. Look for the same pair of addresses repeating.
A switch between HTTP and HTTPS suggests a scheme conflict. A switch between www and the bare domain suggests competing hostname preferences. A loop between two paths may come from redirect rules or application routing instead.
Keep the original request and the exact sequence. A vague “Cloudflare broke the site” report gives support less to work with than two clearly conflicting destinations.
Check how the proxy reaches the origin
Cloudflare’s Flexible mode uses HTTP between Cloudflare and the origin. If the origin insists on redirecting those requests to HTTPS, the visitor can be sent around the same cycle repeatedly. The browser’s secure connection and the origin connection are separate.
Configure a valid HTTPS service at the origin and align the encryption mode with that service. A certificate-validating setup is the appropriate goal for a site carrying logins or personal information. Do not treat an unencrypted origin leg as the lasting fix for a loop.
A different conflict occurs when a secure origin request is redirected back to HTTP while the edge insists on HTTPS. The host can identify that origin response and correct the policy that sends the request in the wrong direction.
Choose a consistent final hostname
Decide whether the public site uses www or the bare domain, and compare that choice with WordPress’s active URLs, hosting redirects, and CDN rules. Two systems making opposite choices can create a hostname loop.
Keep the setup’s directory structure in mind. WordPress Address and Site Address are not always identical in a deliberate subdirectory installation. A generic pair of configuration values can produce another problem if copied without checking.
Review hard-coded constants and migration remnants as well as dashboard settings. The value displayed in one screen may be overridden elsewhere, so identify the active source before adding another rule.
Review the rule that matches this request
Keep a small rule inventory: layer, matching condition, destination and order. Test the responsible rule on staging where possible, preserving unrelated behavior. Correcting one conflict is easier to evaluate than pausing every redirect and later guessing which to restore.
CDN redirect rules, host configuration, and plugins can all redirect a URL. Look at their matching conditions and order. A broad rule may catch its own destination, or two individually reasonable rules may send traffic back to each other.
On staging where possible, pause one suspected rule and repeat the same URL test. Keep a backup and restore unrelated behavior. Disabling all rules at once can make the page load while removing redirects or access controls the site still needs.
HSTS adds another consideration because compliant browsers can insist on HTTPS locally. Changing an edge setting does not instantly erase a browser’s stored policy. Have the intended secure configuration reviewed rather than weakening it to suppress the symptom.
Separate a stale redirect from an active loop
After correcting the policy, compare a clean browser session and refresh the affected cache through supported controls. A cached redirect can continue sending visitors to the earlier address even when the origin has changed.
Cache clearing is useful at that point, but it cannot repair two live rules that still disagree. Recheck the chain and confirm that the request reaches a final page instead of simply returning a different first redirect.
Test the site’s important entry points
Open the main domain, the alternate hostname, a normal post, and the login page. Each intended entry should end at the correct public address without repeating hops. Check forms and authenticated access as well.
Keep the responsible rule and final policy in your notes so a later plugin or hosting change does not reintroduce the conflict. Cloudflare’s redirect-loop documentation explains its encryption and edge-rule interactions, while WordPress’s migration guide covers site URL configuration.
Check the important entry points
Test the intended and alternate hostnames, a normal post and login. Each should finish at the planned address without repeated hops. Verify authenticated access and forms, and record the layer that owns each redirect so a future plugin does not introduce an opposite policy.