Redirect Errors, Chains & Loops: How to Find and Fix Them

A redirect sends a browser or crawler from one URL to another. Get the status code wrong, or stack too many redirects between a starting URL and its final destination, and the result is slower page loads, wasted crawl activity, and in bad cases, a page that never resolves at all. This guide covers the whole lifecycle of that problem: choosing the right status code, implementing it correctly, and finding and fixing the chains and loops that build up over time, because a chain is really just several single-hop mistakes stacked on top of each other. It doesn’t cover 404 handling (a redirect pointed at a genuinely dead page is this post’s problem; deciding whether a gone page should be a 404 or a redirect in the first place belongs to that topic), and it only points to, rather than re-explains, Search Console’s redirect-related exclusion reasons.

Redirect Status Codes: 301, 302, 307, 308

Four status codes cover the vast majority of real-world redirect decisions, and they split along two independent lines: permanent vs. temporary, and method-preserving vs. not.

Code	Meaning	Method preserved?	When to use
301	Moved Permanently	No (historically may convert POST to GET)	The old URL is never coming back: page moved, domain migrated, URL structure changed permanently
302	Found (temporary)	No (historically may convert POST to GET)	A short-term redirect where the original URL will return, and where method-preservation doesn't matter
307	Temporary Redirect	Yes	A short-term redirect where the request method (especially POST) must be preserved exactly
308	Permanent Redirect	Yes	Same permanence as 301, but the HTTP method must be preserved

For most standard SEO scenarios, the meaningful decision is 301 vs. 302, and it comes down to one question: is this change permanent? A 301 tells search engines to transfer indexing and ranking signals to the new URL and to update their records accordingly. A 302 tells them the change is temporary, so the original URL should stay the one that’s indexed and credited. Using a 302 for a permanent move, a very common mistake during rushed migrations, delays that signal transfer and can leave the old URL competing with the new one in the index for longer than necessary.

Server-Side vs. Meta-Refresh vs. JavaScript Redirects

A redirect can be implemented three ways, and they are not equivalent for SEO purposes.

Server-side redirects (an HTTP response with a 3xx status code and a Location header, configured at the server or CDN level) are the correct default. They’re fast, since the redirect happens before any page content loads, and they communicate the status code directly to crawlers without requiring page rendering.

Meta refresh (<meta http-equiv="refresh" content="0;url=...">) happens inside the HTML itself, requires the page to load first, and doesn’t send an HTTP status code at all, which makes the intent (permanent vs. temporary) ambiguous to search engines.

JavaScript redirects happen even later, after the page loads and executes script, which means a crawler has to render the page before discovering the redirect at all, adding a dependency on the rendering pass covered in Googlebot’s crawling behavior.

On the underlying mechanism, Google is direct: ranking signals from links pointing at the old URL, including PageRank, “will be passed appropriately across 301 redirects” (Google Search Central, “Redirects and Google Search”). Server-side 301s and 308s are the implementation that makes that transfer as fast and unambiguous as possible; meta-refresh and JavaScript redirects still generally work, but add latency and, in the JavaScript case, a rendering dependency that server-side redirects don’t have.

Implementing a Server-Side Redirect

The exact syntax depends on the server, but two environments cover the majority of real-world sites. On Apache, a single-URL redirect goes in .htaccess:

Redirect 301 /old-page/ https://example.com/new-page/

For pattern-based redirects (an entire old directory structure moving to a new one), mod_rewrite handles it:

RewriteEngine On
RewriteRule ^old-category/(.*)$ /new-category/$1 [R=301,L]

On Nginx, the equivalent single-URL redirect is configured in the server block:

location = /old-page/ {
    return 301 https://example.com/new-page/;
}

And a pattern-based redirect:

rewrite ^/old-category/(.*)$ /new-category/$1 permanent;

Both platforms cover the vast majority of standard hosting setups; a site running on a different stack (Node.js, a managed CMS, a CDN’s edge-redirect rules) will have its own equivalent syntax, but the underlying logic, matching a request path and returning a 301 with the correct Location header, is the same regardless of platform.

Common Single-Hop Errors

Most redirect problems aren’t chains at all, they’re a single redirect pointed at the wrong place. The recurring patterns:

• Redirecting to an irrelevant page. Sending every dead or moved URL to the homepage “just to be safe” throws away the specific relevance signal a targeted redirect would have preserved, and is a pattern search engines have flagged as a weak practice when done at scale.
• Mixed content after an HTTPS migration. A redirect from http:// to https:// that works but still references old http:// resource URLs (images, scripts) inside the destination page creates browser security warnings and can leave assets unencrypted.
• Redirect mapping mistakes during migrations. Bulk redirect maps generated by matching old and new URL lists programmatically frequently contain mismatches, especially when the two lists aren’t the same length or aren’t sorted consistently. Spot-checking a sample of the generated map against the live destination pages before going live catches most of these before they ship.

What Redirect Chains and Loops Are, and Why They Cost You

A redirect chain is a sequence of redirects where the first URL redirects to a second, which redirects to a third, and so on, before finally landing on a page that returns a 200 status. A redirect loop is a chain that never terminates: URL A redirects to B, and B redirects back to A (or into a longer cycle), so no version of the page ever actually loads.

Chains cost real, if usually marginal, things: each hop adds a full round-trip request before the browser or crawler reaches content, slowing the experience for real users, and each additional hop is one more chance for a crawler to give up before reaching the final page, which can leave that final page under-crawled relative to a direct single-hop redirect. Loops are worse: they simply fail, returning no usable page to either users or search engines.

Detecting Chains and Loops

Two practical approaches cover most detection needs:

1. Crawler tools (Screaming Frog and similar site crawlers) that follow redirects and report the full chain for any URL, including how many hops it took and where it ultimately landed.
2. Search Console’s Page Indexing report, which surfaces two relevant, real exclusion-reason categories: “Redirect error,” covering chains that are too long, loops, or malformed redirect targets, and “Page with redirect,” which flags non-canonical URLs that redirect elsewhere. Neither report re-explains the mechanics beyond flagging the affected URLs; a crawler tool is still needed to see the actual chain.

Fixing Chains: Consolidate to a Single Hop

The fix for any chain is the same regardless of how many hops it has: point the original URL directly at the final destination, skipping every intermediate hop. This is a mechanical cleanup task, best run periodically (after migrations especially, since that’s when chains most often form as new redirects get layered on top of old, unremoved ones) rather than treated as a one-time project.

A typical chain forms in stages, not all at once. A page moves from /old-url/ to /new-url/ during one site update, correctly redirected with a 301. A year later, a second reorganization moves /new-url/ to /newest-url/, and a new redirect rule gets added for that hop, but the original /old-url/ to /new-url/ rule never gets updated to point straight at /newest-url/. Anyone who still has /old-url/ bookmarked, or any external site still linking to it, now goes through two hops instead of one. Multiply that pattern across a few reorganizations over several years and three or four-hop chains accumulate quietly across a site’s oldest URLs, invisible until a crawl audit surfaces them. The fix in this example is straightforward: update the original /old-url/ rule to point directly at /newest-url/, and remove the now-unnecessary intermediate hop entirely.

The Hop-Limit Question, Answered Honestly

A specific number for “how many redirect hops will Google follow” gets stated confidently and inconsistently across SEO content, sometimes as 5, sometimes as 10. Google has not published a single authoritative maximum in its own documentation. The most concrete, attributable guidance comes from Google’s John Mueller, who told a site owner on Reddit to keep redirect chains under 5 hops for URLs that are crawled frequently, and indicated that Google will generally not continue following a chain past around 5 hops in a single crawl attempt (reported by Search Engine Journal, “Google’s John Mueller Recommends Less Than 5 Hops Per Redirect Chain”).

The honest summary: treat “1 to 2 hops maximum” as the practical target for anything that matters, because even a technically-followed chain adds latency and dilutes crawl efficiency well before it hits any hard ceiling. Treat “5 hops” as Mueller’s stated practical warning line, not a Google-guaranteed technical limit. And treat any claim of an exact, official maximum (5 or 10) presented as settled Google policy with skepticism, since Google itself hasn’t published one.

When Redirects Meet Migrations

Site migrations are where redirect problems compound fastest: a full URL structure change means hundreds or thousands of new redirect rules created at once, frequently layered on top of redirects that already existed from a previous migration, which is exactly how long chains form without anyone intending to create them. Auditing the full redirect map for chains before a migration goes live, not just spot-checking a handful of high-traffic URLs, is the difference between a clean cutover and months of slowly-discovered chain problems afterward.