Redirect detector

A healthy permanent move is one hop: a single 301 from the old address straight to the final one, then a 200. Anything longer is worth a look, and anything that repeats an address is a bug.

Two patterns account for most of what shows up here. The first is a chain built from reasonable decisions made years apart — an HTTP-to-HTTPS rule, then a restructure, then a rename — where each rule points at the next rule instead of at the end. The second is a 302 sitting inside what was meant to be a permanent migration, which tells Google to keep the old URL indexed and leaves the new one unable to rank.

Redirects pass full link equity, so hop count is not costing you ranking directly. What it costs is a round trip per hop on a slow connection, crawl budget, and a longer path in which any single broken link kills the whole route from the original backlink.

That is a loop, and the browser reports it as ERR_TOO_MANY_REDIRECTS after roughly twenty hops. It means two rules are each certain they are right and are undoing each other. The trace stops as soon as it detects the repeat rather than following it forever.

The usual pair is a protocol rule against a host rule: HTTP goes to HTTPS, and HTTPS goes back to the non-www host, which is served over HTTP. Or a CMS is configured for one canonical host while the server rewrites to the other.

Cloudflare SSL/TLS set to Flexible. Cloudflare fetches the origin over plain HTTP, the origin redirects to HTTPS, and Cloudflare hands that redirect back to the browser. Set the mode to Full or Full (Strict) and the loop disappears. This is the single most common cause of a loop that only appears once a site is proxied.

WordPress home and siteurl disagreeing with the server. If the options table says the site lives at the non-www host while the server rewrites everything to www, the two fight on every request. The fix is to make both agree, editing the options table directly if the admin screen is unreachable because of the loop itself.

A reverse proxy that does not forward the Host header. The backend receives an IP address, decides that is not its canonical hostname, and redirects to the name it expects — which arrives back through the proxy unchanged. Setting the Host header on the proxied request stops it.

SSL terminated twice. If the proxy already terminates TLS and the origin still has its own HTTPS-forcing server block, the origin keeps trying to upgrade a connection the proxy has already handled. Remove the redundant block on the origin.

Both hostnames serving the same pages, with no redirect between them and no canonical tag tying them together, is the version of this problem that produces no error at all. Nothing breaks; the site is simply available at two addresses and search engines have to pick one.

A 2026 study of 2,165 small business sites posted to r/TechSEO found around one in twenty doing exactly this, with a third of those concentrated on a single host. It is common precisely because nothing visibly fails.

Trace both forms. One should redirect to the other in a single hop, and the survivor should return 200 with a canonical pointing at itself.