The redirect chain loops

HighConfirmedhttp.redirects.loop

What this check looks for

The site sends visitors in a circle: one address redirects to another, which redirects back. Browsers give up and show an error instead of the page.

Why it matters

Nobody can load the affected pages. Browsers show 'too many redirects' and search engines drop the URL from the index entirely.

When the check passes, your report says: “The redirect chain ends at a page rather than going in a circle”.

What it costs your score

When this check fails it removes 40 points from your HTTP score, before the status, confidence and repeat multipliers are applied. HTTP carries a weight of 7 in the overall score.

It shares the http.redirects family ceiling of 45 points: however many findings that family produces, together they cannot remove more than that from HTTP. One underlying problem showing up in several places is still one problem.

Severity: high
Default confidence: confirmed
Status when triggered: fail
Deduction: 40 points
Family cap: http.redirects · 45
Category: HTTP
Module: Http redirects
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Find the two rules that point at each other and keep one.

A loop makes the affected URLs unreachable for every visitor.

Trace it: curl -sIL --max-redirs 10 https://‹host›/ shows every hop.
If a proxy terminates TLS, make the origin trust X-Forwarded-Proto instead of testing the connection's own scheme.
Check for a canonical redirect in the application as well as in the server — two layers each enforcing their own preference is the common case.

How to confirm it worked

curl -sIL --max-redirs 10 https://‹host›/ — expect a 200 at the end

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

# One hop, straight to the canonical origin. Not http -> https -> www -> path.
server {
	listen 80;
	listen 443 ssl;
	server_name ‹host›;
	return 301 https://www.‹host›$request_uri;
}

Apache

<VirtualHost *:80 *:443>
	ServerName ‹host›
	RedirectMatch 301 ^/(.*)$ https://www.‹host›/$1
</VirtualHost>

Caddy

‹host› {
	redir https://www.‹host›{uri} permanent
}

Cloudflare

Rules → Overview → Create rule → Redirect Rule (path as at 2026-09) → single rule: When hostname equals ‹host›, Static/Dynamic redirect to https://www.‹host›/${http.request.uri.path}, status 301, preserve query string.

Collapse the chain into a single redirect per source host rather than chaining them.
Shown because the response identified Apache. Prefer the virtual host over .htaccess: .htaccess is re-read on every request and its rules run after the virtual host's, which is how these chains get long in the first place.
Cloudflare Redirect Rules run at the edge and apply only to requests that arrive through it. An origin reachable directly — by IP, or through a DNS record that is not proxied — still produces the chain measured here. Fix the origin's own configuration as well.

Technical detail

‹detail›

The usual causes are a proxy that terminates TLS and forwards to the origin as plain HTTP while the origin redirects to HTTPS — the classic infinite loop when X-Forwarded-Proto is not honoured — a www rule and a non-www rule that each redirect to the other, or an application-level canonical redirect fighting a server-level one.