A visitor opens the HTTPS address without www. The CDN sends the request to www, WordPress sends it back, and the browser eventually reports too many redirects. An administrator may still see the site because logged-in traffic bypasses one cached hop.
The useful question is not which redirect switch to try next. It is which component emitted each response and which two rules disagree about the canonical host, protocol, path, language, or login state.
What it means
A redirect loop is a cycle in which one response points to a URL or state that eventually returns to an earlier point. The browser never reaches a final page. A two-hop loop is common, but cached rules and authentication conditions can create longer or intermittent cycles.
The participants may include a CDN, reverse proxy, web server, WordPress URLs, HTTPS detection, a language or login rule, and a plugin. Clearing cookies can change the symptoms, but it does not reveal the conflicting owners.
A realistic WordPress example
In this case, the CDN enforces wwwwhile WordPress uses the bare domain as its canonical address. Recording the status and Locationheader for each response produces a simple cycle between those two URLs.
The team keeps a recovery session open, aligns the CDN with the WordPress address, and tests again without administrator cookies. The loop disappears without changing unrelated HTTPS, language, or login behavior.
Why it matters and when to use it
Redirect loops block users and crawlers and can make login, checkout, callbacks, and API routes unusable. They should be corrected as soon as the repeated hop is reproducible.
Preserve the evidence before clearing caches. Start with one clean request and record every status code, destination, host, scheme, cookie state, serving layer, and cache result until the first URL repeats.
A straightforward route for beginners
- Save the current WordPress URLs and the relevant CDN, server, and plugin redirect settings.
- Request the failing URL without cookies and list each status and
Locationvalue in order. - Assign each hop to the CDN, proxy, web server, WordPress, or plugin that produced it.
- Choose one canonical host and protocol, then disable or align only the rule that contradicts that choice.
- Retest anonymous and logged-in traffic,
wp-admin, login and logout, localized pages, queries, and callbacks.
The advanced route
Compare edge and direct-origin responses, HTTP and HTTPS, both host variants, and different serving nodes. Check the trust boundary for forwarded-protocol headers, multisite domain mapping, trailing-slash normalization, language negotiation, login redirects, HSTS, and cached redirect keys.
For an intermittent loop, annotate each hop with its node, cookie state, and cache hit. Remove one proven edge in staging and predict the next route before testing. If the observed path differs, another redirect owner is still missing from the map.
Risks, common mistakes, backup, and rollback
Blind changes to homeor siteurlcan make recovery harder. Purging every cache or deleting all cookies before recording the chain destroys useful evidence. Adding exceptions around an overbroad rule often turns a short loop into a longer one.
Restore the last working rule set if wp-adminbecomes unreachable, host or protocol continues to flip, a POST changes destination, or different nodes disagree. Keep a recovery path that does not depend on the rule being changed.
How AIOWS helps:
AIOWS Redirect Manager
AIOWS Redirect Manager shows the supported WordPress redirect rules with their source, destination, status, and scope. That inventory helps determine whether one of its rules forms part of the repeated hop or whether the response is produced earlier by the CDN or server.
Disable only a rule that the recorded chain proves is involved. Then rebuild the route for anonymous and authenticated requests and verify login, administration, localized pages, query strings, and callback paths.
The module cannot change DNS, CDN policy, proxy headers, or web-server rules. Those layers must be corrected by their owners. AIOWS is relevant here because it makes the WordPress rule layer explicit and reversible instead of adding another hidden exception.
Related AIOWS articles
- 301 Redirect in WordPress: Safe Setup and Testing
- How to Find and Fix Redirect Chains in WordPress
- WordPress Trailing Slash Redirect Problems
Conclusion and recommended route
Capture the complete redirect chain, assign every hop to its owner, and correct the single rule that conflicts with the intended canonical route. Accept the result only when anonymous and authenticated requests reach a stable destination and the recovery path still works.
