ERR_TOO_MANY_REDIRECTS: Fix WordPress and Cloudflare Loops

By Rahul S., SEO Strategist at SearchCounselCo. Updated October 7, 2026.

30-second diagnosis: match the symptom before you change anything

Use the behavior you can observe to choose the first place to investigate. These are starting points, not proof of the cause; confirm the redirect sequence before changing production configuration.

What ERR_TOO_MANY_REDIRECTS actually means

ERR_TOO_MANY_REDIRECTS appears when a browser cannot reach a final page because it keeps receiving redirects. A true redirect loop is the most common pattern: URL A sends the request to URL B, and another rule sends it back to URL A. A long non-repeating redirect chain can also hit a client limit, so the error message by itself does not prove which setting is wrong.

Chrome may show “redirected you too many times,” while Firefox may describe the page as not redirecting properly. Those messages describe the symptom, not the responsible layer. The conflict can live in the browser session, CDN, web server, reverse proxy, CMS, authentication flow, or a combination of them.

If you are visiting the site: rule out stored browser data

If you do not control the website, avoid server-side troubleshooting. Try the affected address in another browser first. If it loads there, remove stored data for the affected site in your normal browser and retry. Google documents how to delete cookies and site data in Chrome. Removing site data can sign you out of that website.

1. Copy the exact failing URL so you can retest the same address.
2. Try it in another browser or a clean browser profile.
3. If the second browser works, clear cookies/site data for the affected domain in the failing browser.
4. Retry the original URL.
5. If multiple browsers fail, report the URL and approximate time to the website owner. The problem is likely server-side or account/session-specific.

A private window is useful for comparison, but it is not a perfect control. It can have different authentication and cookie behavior. If you own the website, confirm a public-page failure with a fresh HTTP request as well.

If you own the site: trace the redirect loop before changing settings

Open browser developer tools, select the Network panel, preserve the log, and reload the page. Inspect the document requests and record the request URL, response status, and Location header for every redirect. Remove cookies, tokens, private query values, and other sensitive information before sharing the capture.

For a public URL, a developer can also follow redirects from a terminal:

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

This follows redirects up to a finite limit and prints response headers. Reaching the limit alone does not prove a loop. Look for a repeated URL, a hostname that flips back and forth, an HTTP/HTTPS reversal, or a path that keeps expanding. A command-line request also will not reproduce JavaScript navigation or an authenticated browser session, so compare the two when their results differ.

Read the redirect pattern before choosing a fix

For broader URL planning, see our guide to 301 vs 302 redirects, chains, and URL structure.

What changed right before ERR_TOO_MANY_REDIRECTS appeared?

The last relevant change is often the fastest lead to investigate, but timing alone does not prove causation. Use it to narrow the search, then confirm the responsible hop in the redirect sequence.

How to fix Cloudflare ERR_TOO_MANY_REDIRECTS

Cloudflare documents several redirect-loop patterns caused by a mismatch between its edge settings and the origin server. The correct fix depends on what the origin actually supports; do not change SSL mode blindly.

Cloudflare says Flexible mode uses HTTP to the origin and can loop when the origin automatically redirects HTTP to HTTPS. Its documentation recommends Full or higher when the origin is configured for SSL, and Full (strict) when the origin can present a suitable certificate. Review Cloudflare’s current ERR_TOO_MANY_REDIRECTS troubleshooting guidance before changing production settings.

Also check Cloudflare Redirect Rules, Page Rules that still exist in older configurations, Always Use HTTPS, and HSTS interactions. HSTS is not something to toggle casually: fix the protocol conflict first. For the wider migration and certificate context, see our HTTPS and site security guide.

How to fix too many redirects in WordPress

WordPress can participate in a loop through its site URLs, proxy HTTPS detection, a plugin, or web-server rewrite rules. Work from the captured redirect pattern instead of changing unrelated settings.

1. Confirm WordPress Address and Site Address

In Settings → General, compare the WordPress Address and Site Address with the installation you actually use. Check protocol, hostname, and path. Do not assume the two fields must always be textually identical: WordPress officially supports installations where core files live in a subdirectory while the public site uses a different path. Match the values to the intended architecture.

If the dashboard is inaccessible, WordPress supports defining site URLs outside the dashboard, but those overrides can make the stored settings appear uneditable. Use the exact intended addresses and keep a recovery copy before changing configuration.

2. Check HTTPS detection behind a CDN or reverse proxy

If TLS terminates at Cloudflare, a load balancer, or another reverse proxy, WordPress must correctly understand whether the original visitor request was HTTPS. WordPress documents reverse-proxy HTTPS handling in its HTTPS administration guidance. Ask the host or platform owner how the original scheme is passed to PHP before adding a header workaround from a random tutorial.

3. Isolate redirect, SSL, cache, or login plugins

If the loop began after a plugin update or configuration change, save the current configuration and test the most likely component first. A redirect plugin, SSL helper, caching layer, security plugin, membership plugin, or login redirect can create a reverse rule. Disable only the suspected component when possible, then retest the same URL. Re-enable it if the redirect chain is unchanged.

If you are locked out of WordPress, use your host’s supported recovery method rather than deleting plugin files. The objective is to identify the component that changes the redirect sequence, not to leave the site without security or authentication controls.

4. Check .htaccess on Apache or LiteSpeed

A bad rewrite rule in .htaccess can create a loop. Save a copy before changing it. On Apache or LiteSpeed, a controlled troubleshooting step is to rename the existing file, retest, and—if that removes the loop—regenerate WordPress’s normal permalink rules from Settings → Permalinks → Save Changes. Then restore any required custom directives one by one.

This is not an Nginx fix: Nginx does not use WordPress .htaccess rules. If the site runs on Nginx or the host manages server-level redirects, inspect the server configuration or ask the host to identify the rule that produced the relevant Location header.

5. Check only the rule that conflicts with the intended destination

A working redirect can be part of the final setup. If /old-page/ correctly redirects to /new-page/, do not remove that rule merely because a second rule sends /new-page/ back to /old-page/. Remove or correct the reverse rule and keep the permanent move.

Still looping after the common fixes? Escalate with evidence

If browser data, WordPress URLs, plugins, Cloudflare settings, and obvious server rules do not explain the loop, stop making broad changes. Use the captured sequence to move deeper into the stack.

When escalating to a host or developer, provide the exact failing URL, approximate time, full redirect sequence with sensitive values removed, the first returning hop, recent configuration changes, and the destination the request should reach. That turns “too many redirects” into a reproducible routing issue instead of a vague support ticket.

Other causes to check when the obvious fixes do not match the evidence

• Authentication or SSO callbacks: a login page sends the user to an application route that immediately returns them to login because the session is not recognized.
• Domain migration rules: the old domain redirects to the new domain while an application, CDN, or server rule still points selected requests back to the old hostname.
• Localization rules: country, language, or trailing-slash redirects can conflict when more than one system normalizes the same URL differently.
• Cached redirects: a CDN or browser may continue serving an old response after the configuration is corrected. Purge the relevant cache only after fixing the underlying rule, then retest.
• Application route logic: a framework or custom middleware can redirect based on path, host, authentication state, or query values that a simple server rule does not see.

Recorded local example: one reverse 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, while a direct request returned 200 with the body “Current page is reachable.”

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

This example shows why “remove all redirects” is the wrong goal. The 301 represented the intended move; the reverse 302 created the cycle.

Redirect incident record: capture this before and after the fix

Keep a compact incident record so the repair can be reproduced, reviewed, or rolled back. Do not include authentication tokens, private cookies, or sensitive query values.

Verify the repair and the SEO implications

Retest the original failing URL after making the smallest supported change. A 200 response on the wrong page is not a successful repair. Confirm the final address, response status, visible content, and any business-critical journey that previously failed.

• Public entry points: test the HTTP/HTTPS and www/non-www variants your site supports. They should settle on one intended HTTPS hostname without cycling.
• Original affected page: test the exact path and any relevant query string involved in the incident.
• Authentication: if login or account pages were involved, test the intended signed-in and signed-out flows without weakening access control.
• Content: verify that the final page is the correct destination, not merely a technically successful 200.
• Caches: after the underlying rule is fixed, clear the relevant application/CDN cache and retest from a clean browser session.
• Change record: save the before/after sequence, the changed rule, system owner, time of repair, and rollback version.

Google Search Console’s Page indexing report can show redirect errors for loops, overly long chains, or bad destinations. A normal redirect can instead be reported as “Page with redirect,” which is a different condition. After the repair, inspect the intended destination with URL Inspection and compare that result with the HTTP sequence you captured.

A successful live request does not guarantee immediate indexing or ranking recovery. If Google still cannot crawl the destination, use our crawl error troubleshooting guide. If the page is accessible but excluded, use our separate indexing diagnosis. Update internal links and sitemap entries to the final URL where appropriate as part of your technical SEO maintenance.

ERR_TOO_MANY_REDIRECTS FAQ

Will clearing cookies fix too many redirects?

It can fix a browser- or session-specific problem. If fresh public requests still cycle between URLs, clearing cookies does not repair the website-side rule. Trace the redirects and correct the conflicting configuration.

What is the most common Cloudflare cause?

A classic Cloudflare pattern is Flexible SSL combined with an origin server that forces HTTP requests to HTTPS. Cloudflare documents that this can loop because its connection to the origin remains HTTP in Flexible mode. Verify that the origin supports HTTPS before changing encryption mode.

Can a WordPress plugin cause ERR_TOO_MANY_REDIRECTS?

Yes. Redirect, SSL, cache, security, membership, and login-related plugins can participate in redirect logic. Use the captured chain and recent change history to isolate the most likely component instead of disabling every plugin without evidence.

Should I delete my .htaccess file?

Do not delete it blindly. On Apache or LiteSpeed, first save a copy, then temporarily rename it for a controlled test. If the loop disappears, regenerate WordPress’s standard permalink rules and restore required custom directives carefully. Nginx does not use .htaccess.

Does a canonical tag stop a redirect loop?

No. A canonical link element does not cancel an HTTP redirect. Fix the routing conflict first, then verify the canonical configuration on the final page.

Will rankings recover immediately after the loop is fixed?

Not necessarily. Fixing the loop restores access, but crawling, indexing, and ranking are separate processes. Record the repair date and monitor the affected URL and queries in Search Console over comparable periods.

The one thing to do next

Capture the first request that sends the visitor back to an earlier URL. That single hop usually tells you which layer to investigate. Give the redirect sequence, the recent configuration change, and the intended final destination to the person responsible for the CDN, server, CMS, or application.