Too many redirects error on WordPress: how to actually trace the loop
TL;DR: A redirect loop happens when two or more layers in your request chain, WordPress itself, a plugin, .htaccess, a CDN, each independently believe a redirect is needed, and their redirects point at each other rather than converging on a final destination. The most common single cause is a mismatch between what WordPress's site URL setting expects (HTTP or HTTPS) and what a CDN or proxy layer in front of it is actually enforcing, but tracing the exact loop, rather than guessing at the general category, is what actually gets it fixed quickly.
Why this happens: two layers disagreeing
A single, correctly configured redirect is straightforward: something says "go to X instead," the browser goes to X, and X does not send it anywhere else. A redirect loop specifically means the chain never terminates, because at some point in the sequence, a request ends up back at a URL it has already visited, and the same redirect logic fires again, indefinitely, until the browser gives up and shows the error rather than looping forever.
This structurally requires at least two independent points in your stack each making a redirect decision, since a single layer redirecting consistently to the same final destination would simply arrive there and stop. The practical troubleshooting question is therefore not "why is there a redirect" but "which two (or more) layers are each redirecting, and why do their decisions point back at each other rather than agreeing on a shared final state."
Step 1: trace the actual redirect chain
Before guessing at causes, see the actual sequence of redirects happening, since this immediately tells you which layers are involved rather than requiring you to check every possible cause exhaustively. Browser developer tools' Network tab, with "preserve log" enabled, shows each redirect hop in sequence when you load the affected URL, including the specific redirect type (301, 302, 307) and, often, response headers indicating which system issued each one (a CDN's own headers, an .htaccess-driven Apache redirect, or a WordPress/plugin-issued redirect often looks distinguishable by header patterns and response characteristics).
Alternatively, a command-line tool (curl -IL https://yourdomain.com) shows each redirect response and its target URL in sequence without needing browser devtools, which is often faster and clearer for seeing the exact loop pattern (typically alternating between two URLs, or a short repeating cycle of three or four).
Cause 1: HTTP/HTTPS mismatch with a CDN or proxy
This is the most common cause, especially after adding a CDN or a security/proxy layer in front of an existing WordPress site. If the CDN is configured to redirect all HTTP traffic to HTTPS (a common and generally correct setting), but the connection from the CDN to your actual origin server is itself over plain HTTP (common with a CDN SSL mode misconfigured as "Flexible" rather than "Full"), and WordPress's own site URL setting expects HTTPS, WordPress can detect the incoming connection (from the CDN's perspective, arriving as HTTP) and issue its own redirect back to HTTPS, which the CDN then redirects again, creating an alternating loop between the two layers that never resolves.
The fix here is ensuring SSL/TLS mode consistency end to end: if WordPress expects HTTPS, the CDN-to-origin connection must also genuinely be HTTPS (a CDN SSL mode of "Full" or "Full (strict)" rather than "Flexible"), not just the browser-to-CDN leg.
Cause 2: WordPress site URL doesn't match actual access method
WordPress's own siteurl and home options (Settings → General in the dashboard, or set directly in wp-config.php) specify the canonical URL, including protocol, WordPress expects to be accessed at. If this is set to https:// while the server is not actually properly configured to serve HTTPS (a certificate issue, or TLS not correctly terminated, covered in our SSL error guides), or vice versa (set to http:// while a separate mechanism is forcing HTTPS), WordPress's own internal redirect logic (which enforces the configured URL) can conflict with whatever else in the chain is also making protocol decisions, producing the same alternating-redirect pattern as Cause 1 but originating from a mismatch entirely within your own WordPress configuration rather than involving an external CDN.
Cause 3: a redirect or SEO plugin conflicting with server-level rules
Many SEO plugins include their own redirect management features (canonical URL enforcement, automatic HTTPS redirection, trailing slash normalization), and if a similar rule already exists at the server level (.htaccess) or in a separate dedicated redirect plugin, having two independent systems both attempting to enforce a similar but not identical rule (one redirecting non-www to www, another simultaneously redirecting www to non-www, for example, added by different plugins or configurations at different points in the site's history) produces exactly this kind of loop.
Checking for redundant or overlapping redirect configuration across your SEO plugin's settings, any dedicated redirect plugin, and your site's .htaccess file is the direct way to identify a Cause 3 conflict, and it is particularly worth checking after installing a new SEO or security plugin on a site that already had redirect rules configured elsewhere.
Cause 4: www vs non-www redirect conflict
Similar in mechanism to Cause 3 but specific to the www/non-www decision rather than the HTTP/HTTPS decision: if WordPress's site URL is configured for one variant (say, www.yourdomain.com) while a separate .htaccess rule, a DNS-level redirect at your registrar, or a CDN setting is simultaneously trying to redirect toward the other variant (yourdomain.com), the same alternating pattern results. This is particularly common after a domain or hosting migration where the www/non-www preference was set differently in the old and new environments, with leftover configuration from the previous setup still active alongside the new one.
A diagnostic table
| Redirect pattern observed | Likely cause |
|---|---|
| Alternates between http:// and https:// of the same URL | Cause 1 or 2: HTTP/HTTPS mismatch between WordPress and CDN/proxy |
| Alternates between www and non-www of the same URL | Cause 4: www/non-www conflict between two systems |
| Loops through several different URL variations, not just two | Cause 3: multiple overlapping redirect rules from different plugins/config |
| Only happens on specific pages, not site-wide | A plugin-specific canonical or redirect rule limited to certain content |
| Started immediately after adding a CDN or security proxy | Cause 1, check CDN SSL mode first |
Fixing it without creating a new loop
Once you have identified which two layers are conflicting via the traced redirect chain, fix the mismatch at its actual source rather than adding a third redirect rule on top to try to override the other two, which frequently just adds a new loop variant rather than resolving the underlying conflict. If it is a CDN/origin SSL mode mismatch, fix the CDN's SSL mode setting directly. If it is a WordPress site URL mismatch, correct the siteurl/home values to match what is actually correctly configured and working at the server level, rather than working around a mismatch with additional redirect logic. If it is overlapping plugin rules, remove the redundant one rather than trying to make both coexist, since the coexistence itself is the problem.
FAQs
Does clearing my browser cache fix a redirect loop?
Rarely as a permanent fix, though it is worth trying first since a browser can sometimes cache an old redirect response and continue applying it even after the actual server-side issue has been corrected; if the loop persists after a hard refresh and cache clear, the underlying server-side conflict is still present and needs to be traced and fixed directly.
I fixed my CDN's SSL mode and the loop is gone, but why did it happen in the first place?
This typically happens when a CDN is added to an existing WordPress site without also updating the CDN's SSL/TLS mode to match how the origin server actually handles HTTPS, a configuration step that is easy to overlook since the CDN's default setting is not always the correct one for every origin setup, and the mismatch is invisible until it actually creates a redirect conflict.
Can a security plugin cause a redirect loop unrelated to HTTPS or www?
Yes, some security plugins include their own redirect-based protections (redirecting suspicious requests, enforcing specific access patterns) that can conflict with other redirect logic elsewhere in the stack in less common but real ways beyond the HTTP/HTTPS and www patterns covered above; if the loop pattern does not match either of those common categories, checking a recently added security plugin's own redirect-related settings is worth doing directly.
Does this only happen with a CDN, or can it happen on a simple single-server setup too?
It can happen without any CDN involved, purely from a conflict between WordPress's own site URL setting and a separate .htaccess-level redirect rule, or between two plugins each managing redirects independently; a CDN or proxy layer is a common contributing factor but not a strict requirement for this type of loop to occur.
How do I check my CDN's current SSL mode?
This is typically found in the CDN provider's dashboard under an SSL/TLS or security settings section, usually offering options like "Flexible," "Full," and "Full (strict)"; the correct setting for a WordPress site with a properly installed origin SSL certificate is "Full" or "Full (strict)," not "Flexible," which assumes the origin does not have working HTTPS at all.
Will this affect my SEO if it isn't fixed quickly?
Yes, a redirect loop makes the affected URL completely inaccessible to both visitors and search engine crawlers, meaning the page cannot be indexed or re-crawled while the loop persists, and an existing indexed page experiencing this can lose its ranking and cached content over time if the issue is not resolved promptly.
Is there a way to see the loop without technical tools, just using a browser?
Most modern browsers show at least a basic indication in their address bar or error page when this specific error occurs, but seeing the actual sequence of redirect hops requires developer tools' Network tab (with "preserve log" enabled before triggering the error) or a command-line tool; without seeing the actual sequence, you are limited to checking each possible cause one at a time rather than identifying the specific conflict directly.
Conclusion
A redirect loop always involves at least two systems each making an independent, conflicting redirect decision, and the fastest path to a fix is tracing the actual sequence of redirects rather than guessing at the general category of cause. HTTP/HTTPS mismatches between WordPress and a CDN or proxy layer are the most common single cause, particularly after adding a CDN to an existing site without also aligning its SSL mode with the origin's actual configuration.
Once the specific conflicting pair is identified from the traced chain, fix the mismatch at its actual source, correcting the CDN setting, the WordPress site URL, or removing a redundant plugin rule, rather than layering another redirect rule on top, which usually just creates a different loop instead of resolving the original one.
HostCloud's hosting includes properly configured SSL termination out of the box, and our support team can help trace a specific redirect loop across your CDN, WordPress, and server configuration rather than leaving you to guess at each layer independently. Plans start at ₹99 a month at https://hostcloud.in.