ERR_TOO_MANY_REDIRECTS: Fix WordPress and Cloudflare Loops

By Rahul S., SEO Strategist at SearchCounselCo. Updated September 2026.

First, separate a browser problem from a website problem

The error means the browser stopped following redirects. A loop is a common cause; a long sequence can also exhaust a client’s redirect limit. The message alone does not identify a broken plugin or setting.

If you are visiting someone else’s website, try the same address in another browser. If it works, remove stored data for that website and retry. Chrome supports deleting data for an individual site. This can sign you out. If the problem persists across browsers, report the affected address and time to the owner.

If you own the website, compare the homepage, one affected inner page, and the login page. A private window is a comparison, not a perfect control: its authentication state and cookie behavior can differ. Confirm public-page failures in another browser or with a fresh HTTP request. Note the last relevant change: a domain move, HTTPS setting, redirect rule, or authentication update. Treat that timing as a lead to investigate. It does not prove the cause.

Trace the redirects before changing settings

Open your browser’s developer tools, select Network, enable Preserve log, and reload the affected page. Inspect the document requests. Record each request URL, response status, and Location header. Remove cookies, tokens, and private query values before sharing a capture.

For a public page, a developer can also use this GET request in a macOS or Linux terminal. Replace the example URL with the affected address:

curl --silent --show-error --location --max-redirs 10 --max-time 30 --dump-header - --output /dev/null 'https://example.com/affected-page/'

This prints response headers while following redirects, with a finite limit. See the curl option reference. Reaching the command’s ten-redirect limit does not by itself prove a loop: a long, non-repeating chain can also hit the cap. Look for a repeated URL or a rule that continually expands the path. It does not execute JavaScript or reproduce a signed-in browser session. If the command succeeds but the browser fails, compare cookies, authentication, and client-side navigation.

If the exact same HTTPS URL redirects to itself, include proxy HTTPS detection in the investigation. The origin-facing HTTP connection is not necessarily visible as a separate browser hop. These patterns narrow the investigation. A Location header shows the destination, but may not reveal which layer generated it. Match the sequence to configuration and logs before changing a rule. Our guide to redirect types and chains covers the broader URL planning decisions.

Check Cloudflare and origin HTTPS together

Cloudflare’s redirect troubleshooting documentation describes a specific conflict: Flexible mode connects to the origin over HTTP, while the origin redirects those requests to HTTPS. That can repeat even though the visitor started with HTTPS.

Check the origin certificate and HTTPS support before changing the encryption mode. Cloudflare recommends Full (strict) when possible. The origin must accept HTTPS and present an unexpired, trusted certificate matching the hostname. An unsuitable certificate can produce a different error.

Also inspect any rule that sends HTTPS back to HTTP, or reverses your preferred hostname. If HSTS is involved, investigate the conflicting downgrade rule and HTTPS configuration; disabling HSTS is not a universal repair. A certificate validation failure is a separate failure mode and does not, by itself, prove a redirect loop. Preserve a working HTTPS path while correcting the conflict. For the wider migration checks, see our HTTPS and site security guide.

Check WordPress without removing unrelated settings

Confirm the intended site addresses

Review WordPress Address and Site Address in Settings, General. Check their protocol, hostname, and installation path against the actual setup. A subdirectory installation can legitimately use different paths: WordPress documents this arrangement.

Check HTTPS detection behind a proxy

WordPress documents a reverse-proxy HTTPS configuration for cases where TLS ends before the application. Ask your host to verify how the original request scheme reaches WordPress. The proxy must set the relevant header correctly; do not add an unexplained header workaround to every installation.

Find the conflicting rule

Save the current configuration first. Inspect the recently changed redirect, SSL, caching, or login component. Disable only the suspected rule for a controlled check where possible, then retest. On Apache, compare the relevant .htaccess directives with your host’s configuration. On Nginx, ask the administrator to inspect the server configuration. Replacing an entire file can remove unrelated routing or access rules.

A recorded local example: one rule caused the loop

This controlled HTTP demonstration was executed on September 15, 2026. It used two paths on a local Python server. It was not a WordPress deployment, Cloudflare test, or client incident, and it measured no search traffic.

The correction removed the rule sending /current/ back to /legacy/. The useful permanent redirect remained. A second request sequence reached the current page after one redirect; a direct request returned 200 with the body “Current page is reachable.”

Test method: the local client made GET requests, recorded status and Location, and stopped when the next URL repeated. The server returned 301 for /legacy/ and initially returned 302 for /current/. After changing only the second handler, the same client reached a terminal 200 response. No browser redirect limit was measured.

This demonstrates why the repair should follow the intended destination. The 301 was valid. The reverse rule created the cycle.

Verify the repair and check the SEO implications

Retest the original failing URL. Confirm the final address, status, and visible content. HTTP 200 on the wrong page is not a successful repair. Clear an affected cache after fixing its underlying rule, then check again.

• Public entry points: test HTTP/HTTPS and www/non-www variants that your site supports. Confirm they settle on the intended HTTPS hostname without a cycle.
• Content: check the original inner page and its direct destination, including a relevant query string if one was involved.
• Business journey: check the affected login, contact, or checkout flow in its intended session state.
• Change record: save the before/after sequence, changed rule, responsible system, and rollback version. If a critical journey regresses, restore the saved configuration and investigate.

Do not disable an intentional authentication requirement just to make a protected URL return 200.

Google Search Console’s Redirect error status includes loops, excessively long chains, and invalid redirect destinations. A functioning redirect can instead appear as Page with redirect. Those labels require different actions.

Check the destination with URL Inspection and use the recorded HTTP sequence alongside it. A successful live test does not guarantee indexing. If the page still has a crawl problem, use our crawl error troubleshooting guide; if it is accessible but excluded, follow the separate indexing diagnosis.

Update internal links and sitemap entries to the intended final URL where appropriate. Keep the incident date in your change log so later traffic comparisons can distinguish the outage, repair, and subsequent search behavior. This is part of a broader technical SEO maintenance process.

FAQ

The one thing to do next

Capture the first request that sends a visitor back to an earlier URL. Give that evidence, the recent change, and the intended destination to the person responsible for the rule. If the conflict crosses your CMS, CDN, and host, a technical SEO audit can help define the repair and verification work.