WordPress Too Many Redirects: Trace the Loop Before Changing Settings

A WordPress redirect loop means the browser keeps receiving instructions to visit another address without reaching the requested content. Before changing settings, capture the addresses involved. A short trace can distinguish a protocol conflict from competing hostname rules or a login-specific problem.

The Core Anatomy of a Redirection Loop

A redirection loop occurs when a client requests a resource, and the server returns a 301 (Moved Permanently) or 302 (Found) response header pointing to a new destination, which subsequently redirects back to the original request or through a circular chain of intermediaries. Because web browsers have safety mechanisms to prevent infinite resource consumption, they abort the process after reaching their redirect limit and display an error.

Unlike simple domain updates, such as when you need to fix WordPress redirects to an old domain after migration, an active loop typically involves two systems disagreeing on the correct representation of a canonical URL. These disagreements most commonly stem from mismatched protocol expectations (HTTP versus HTTPS), differing interpretations of hostname canonicalization (www versus non-www), or trailing slash enforcement between server software and WordPress internal routing.

Capturing the Exact Chain with Browser Developer Tools

Before modifying any configuration files, you must gather empirical evidence showing where the loop occurs. You do not need proprietary scanning software; modern desktop browsers include built-in tools capable of capturing the full transaction chain.

To capture the redirect hops cleanly, open a new, private or guest browser profile. A fresh profile helps separate site behaviour from existing cookies and browser cache; it does not bypass server or CDN caches. Next, open Developer Tools and navigate to the Network panel. Ensure that the Preserve Log checkbox is enabled. If this setting is unchecked, the browser will clear previous network requests each time a new location loads, wiping out the redirect history before you can inspect it.

With the log preserved, enter your site URL. Observe the status codes in the list. You will likely see multiple lines returning 301, 302, or 307 status codes followed by the final failure. Click on the first redirected request and look at the Response Headers panel. Specifically, locate the Location header. Note the protocol, hostname, and path specified. Compare it to the original request URL, and repeat this check across every step in the chain until the repetition pattern becomes obvious.

Understanding Edge-to-Origin Protocol Mismatches

A frequent source of redirection loops is an edge reverse proxy communicating with an origin server under conflicting encryption rules. According to the Cloudflare SSL troubleshooting documentation, using Flexible encryption causes the proxy to connect to the origin server over unencrypted HTTP; if that origin server is configured to force incoming visitors to HTTPS, an endless redirect loop occurs. Conversely, when edge encryption is set to Full or Full (Strict), the proxy connects using HTTPS; if the origin server redirects HTTPS connections back down to HTTP, a reverse loop is triggered.

The documentation highlights that addressing these loops requires installing valid TLS certificates directly on the origin server and coordinating routing expectations with your web hosting provider. Under no circumstances should you disable TLS encryption or turn off HTTP Strict Transport Security (HSTS) headers as a shortcut. Lowering security postures weakens user protection without fixing the architectural discrepancy. Your edge proxy and origin server must align on which protocol is being served and terminated.

Inspecting Reverse Proxy Headers and Canonical Definitions

A reverse proxy can accept HTTPS from visitors while forwarding requests differently to the application. Ask the host to check how the original protocol reaches WordPress and whether the application trusts only the intended proxy. Avoid copying a generic forwarding-header snippet: trusting headers supplied by arbitrary visitors creates a separate problem. Record the proxy settings and the WordPress address configuration before making changes.

A Worked Example of a Canonical Host Conflict

To see how these conflicts operate in practice, consider a hypothetical scenario involving an eCommerce site using an NGINX origin server behind a caching layer.

In this scenario, the site administrator wants all traffic consolidated on the non-www secure address: https://example.com. However, during a recent plugin installation, an SEO rewrite tool placed a rule instructing all incoming traffic to resolve to https://www.example.com. Simultaneously, the WordPress general settings define the home and siteurl options as https://example.com.

When an unauthenticated visitor enters the root domain, the network trace shows the following hops:

• Request 1: GET https://example.com -> Server returns 301 redirecting to Location: https://www.example.com (driven by the SEO rewrite rule).
• Request 2: GET https://www.example.com -> WordPress core evaluates the incoming hostname against the home option, finds a mismatch, and returns 301 redirecting to Location: https://example.com.
• Request 3: GET https://example.com -> The cycle repeats indefinitely until the browser throws a redirect limit exception.

The trace identifies the conflicting destinations, but a Location header alone does not identify which software issued it. The administrator compares that trace with the configured rules and host logs to locate each redirect. The solution is not to run search-and-replace queries across the database, but simply to align the rewrite rule so that both the web server and the database point to the identical non-www canonical URL.

Safe Remediation Practices

When attempting to resolve redirection conflicts, avoid destructive shortcuts. Do not delete your .htaccess file completely, and do not execute bulk search-and-replace scripts across your database while the site is unstable. Deleting server configuration files removes essential rewrite rules for permalinks, while global database edits can easily corrupt serialized strings.

Follow disciplined troubleshooting hygiene: always create a full backup of any configuration file before modifying it. Test one hypothesis at a time. If you update a web server directive or proxy setting, test the behaviour using a private browser session or an isolated command-line utility. If the change does not resolve the loop, revert that specific modification immediately before testing the next variable.

Next Steps for Restoration

To systematically bring your site back online, execute the following sequence:

• Document the exact redirect chain by preserving logs within an incognito or guest browser profile.
• Review the configured WordPress and site addresses with the host. Their paths may legitimately differ when WordPress is installed in a subdirectory.
• Check with your web hosting provider to ensure your origin server has an active, valid TLS certificate installed.
• Review proxy encryption settings to guarantee that protocol expectations between the edge and the origin are identical.
• Audit root configuration files (.htaccess or nginx.conf) to eliminate competing rewrite rules that conflict with WordPress canonical settings.