How to Fix Redirect Chains and Loops

Your audit groups seven distinct redirect problems under one umbrella because they share a root cause: a request for a URL doesn't resolve cleanly to a final destination in a single hop. Each has its own signature.

A redirect chain is A to B to C: the browser or crawler has to follow two or more hops before landing on the real page. A redirect loop is worse, A to B back to A (or a longer cycle that eventually revisits a URL already seen), so the request never resolves at all. temporary_redirect flags a 302 or 307 used on a URL that has actually moved for good, where a 301 is the correct code. redirect_internal_link means one of your own links, in navigation, a footer, body copy, or the sitemap, points at a URL that itself redirects instead of the final address. javascript_redirect means the jump happens via window.location or a client-side router rather than an HTTP status code, so it only fires for crawlers that execute JavaScript. external_redirect flags an internal-looking link that, after following redirects, ends up on a different domain entirely. http_to_http_redirect means a redirect exists but keeps the request on plain http instead of upgrading it to https.

Severity varies a lot within this one bundle. A true redirect loop is close to a broken page: browsers give up and show a connection error, and crawlers abandon a URL that keeps redirecting without ever reaching a final page. A single 302 that should be a 301 is, by comparison, a minor cleanup item. This guide treats all seven together because the remedy looks the same in every case: find the real endpoint, point everything at it directly, and use one correctly-typed server-side hop if a redirect is still required at all.

Every extra hop costs something. For crawlers, each redirect is a separate HTTP request that has to be fetched and followed before the real page is reached, so chains eat into the crawl budget search engines allocate to a site, which matters most on large sites where thousands of URLs compete for the same allowance. For users, each hop adds round-trip latency; a three-hop chain on a slow mobile connection is a visibly slower click, and it directly hurts Core Web Vitals like Largest Contentful Paint, since the browser can't even start requesting the real page's resources until the chain finishes resolving.

Redirect loops are the most serious item in this group because they're a dead end, not just a slow path. A looping URL returns nothing useful to a user or a crawler. Browsers cap how many hops they'll follow and then show an error, and any traffic or link equity aimed at that URL is wasted until the loop is broken.

Using 302 or 307 for a permanent move is a smaller but real issue. Google has gotten better over the years at inferring a redirect is effectively permanent if it's left in place long enough, but that inference isn't guaranteed or instant, and other systems, analytics tools, link-sharing platforms, Bing, don't necessarily draw the same conclusion. If a move is permanent, say so with a 301 rather than relying on an algorithm to guess your intent correctly.

The JavaScript-redirect and AI-crawler angle deserves its own callout, since this tool is built around exactly that gap. Googlebot does eventually execute JavaScript, but on a second, separate rendering pass after its initial crawl, so a JS-only redirect can leave a stale or empty page representing you in search results for a period before rendering catches up. Many AI crawlers, including bots associated with ChatGPT, Perplexity, and similar answer engines, fetch raw HTML and are far less likely to execute your JavaScript at all. A redirect that only fires through a script may be functionally invisible to them: they see whatever sits on the old URL, not your destination content. If a redirect needs to be followed by every kind of bot, it has to be a real HTTP status code, not a script.