Redirect chains rarely get built on purpose. They accumulate: an HTTP-to-HTTPS rule from one migration, a non-www-to-www rule from another, a CMS swap that added its own layer on top, none of them aware the others existed. TechySEO follows every redirect path to its actual end and shows you exactly which hops are pure waste.
It happens in layers. Someone adds an HTTP-to-HTTPS rule. A year later, a www-consolidation rule goes in on top of it, unaware the first rule exists. Then a CMS migration adds its own redirect from old slugs to new ones. None of these were wrong in isolation, but stacked together, a single old URL now bounces through three or four hops before landing anywhere, and each hop adds latency, spends a sliver of crawl budget, and historically bleeds off some amount of the link equity in transit.
Loops are the more dramatic failure mode: URL A points to B, B points back to A, and both browsers and Googlebot give up following it after enough hops. Every URL caught in that cycle is functionally dead, inaccessible to a user and a waste of crawl attention on every single visit.
A 302 used for what's actually a permanent move creates a quieter version of the same problem: search engines keep the old URL in the index instead of consolidating signals onto the new one, sometimes for years, because nothing ever told them the move was final.
Not just "this URL redirects." The full path, every intermediate stop, and whether any of it was necessary.
Trace every chain to its real endpoint and find the loops, the leftover 302s, and the hops left over from migrations nobody cleaned up after.
