Redirect Chains: How to Spot Them, Why They Matter, and How to Fix Them

What a Redirect Chain Is—and the Fix in One Sentence

A redirect chain exists when one URL redirects to another URL that redirects again before the browser or crawler reaches the intended destination. For example, URL A → URL B → URL C contains two redirect hops. A direct redirect would send URL A → URL C in one hop.

The safe fix is not simply to delete every intermediate URL. Keep old URLs that still need to work, but update each retained redirect source so that it points directly to the final relevant destination. A chain eventually reaches a page; a redirect loop repeats without reaching one.

Redirect Chain Decision Summary

• Practical target: Use one server-side hop from each old URL to its final destination wherever possible.
• Do not treat a technical maximum as a target: Google’s site-move guidance says Googlebot can follow up to 10 redirect hops, but advises redirecting to the final destination directly. If a chain cannot be avoided, Google gives three or fewer hops as the ideal and fewer than five as a broader ceiling.
• Do not diagnose “lost link juice” by counting hops: Google states that 301 and other permanent redirects do not cause a loss in PageRank. The stronger reasons to shorten a chain are request latency, crawl efficiency, reliability and maintainability.
• Match the status to the intent: Use 301 or 308 for a permanent move and 302 or 307 for a genuinely temporary one.
• Validate the destination first: A one-hop redirect is still wrong if it ends on an irrelevant page, an error, a blocked page or the wrong regional version.

Why Redirect Chains Matter in Practice

Every hop adds another request

Each HTTP redirect response tells the client to request another URL. A same-host redirect may reuse an existing connection, while a redirect to another host can require additional connection work. Either way, the final page cannot begin responding until the earlier redirect steps have completed.

Repeated chains can reduce crawl efficiency

Google specifically warns that long redirect chains can have a negative effect on crawling. For most small websites, ScanMySEO treats this as an efficiency and maintenance issue rather than proof that a fixed “crawl budget” has been exhausted. The practical concern is that search engines and audit tools must spend extra requests reaching pages you already control. At scale—especially after migrations or across site-wide navigation—those requests accumulate.

Site-owned signals can point at the wrong stage

Internal links, XML sitemaps, canonical annotations, hreflang references and structured data should normally use the final preferred URL. Leaving intermediate URLs in those places creates unnecessary hops and makes it harder to audit whether the site is consistently signalling the intended destination.

Chains are fragile

A chain that works today can break when a CMS plugin, CDN rule or server configuration is changed later. One outdated intermediate rule can turn a working route into a loop, an irrelevant redirect or a 404/5xx endpoint. Shorter mappings are easier to test and maintain.

Prioritisation matters: A two-hop chain on a rarely requested legacy URL is usually less urgent than a site-wide chain in navigation, a migration route used by external links, or any chain that ends in an error. Fix the highest-impact patterns first rather than treating every chain as an equal emergency.

Choose the Redirect That Matches the Intent

Google recommends server-side redirects when they are technically possible. Permanent redirects are a canonicalisation signal that helps Google identify the preferred URL; temporary redirects tell Google that the source URL may remain the URL shown in search results.

For an ordinary page requested with GET, 301 is the familiar permanent choice. The distinction becomes more important for forms, application programming interfaces (APIs) and other non-GET requests: the HTTP specification defines 307 and 308 as method-preserving redirects, while some clients may change a POST to GET after 301 or 302. Do not change application redirects without understanding that behaviour.

How to Diagnose and Fix a Redirect Chain Safely

1. Record the complete route before editing it.

   Use a site crawler such as ScanMySEO, server logs or a request-inspection tool to capture the source URL, every status code, every Location value and the final response. Also record which internal pages link to each redirecting URL. Back up the redirect configuration before changing site-wide rules.

2. Confirm that the final destination is correct.

   Check that it is the closest relevant replacement, uses the intended hostname and protocol, and returns the expected final status—commonly 200 for a live page. Confirm that its canonical and indexing settings match its purpose. Do not shorten a chain towards a destination that is already wrong.

3. Find which layer creates each hop.

   A chain can be split across several systems: HTTP-to-HTTPS rules, www/non-www normalisation, trailing-slash rules, a content management system redirect plugin, application routing, a reverse proxy, or a CDN/edge configuration. Identify the owner of every hop so that one layer does not recreate the chain after another is fixed.

4. Point every retained source directly to the final URL.

   If the current route is A → B → C → D, the goal is usually not just A → D. Any old source URL that may still receive visits or links should also resolve directly:

   Before:
   A --301--> B --301--> C --301--> D
   D returns 200 OK
   
   After:
   A --301--> D
   B --301--> D
   C --301--> D
   D returns 200 OK

   This preserves useful old entry points without forcing users and crawlers through the historical sequence.

5. Update references you control.

   Change internal links, navigation, templates, XML sitemaps, canonical annotations, hreflang references, feeds and structured-data URLs so they point directly to the final URL. Redirects are useful for old or external references; they should not be the normal route created by your own current website.

6. Test specific rules before broad catch-all rules.

   Host, protocol and path-normalisation rules can interact. Check representative URLs with and without trailing slashes, parameters, uppercase characters and old hostnames. A broad rule that runs before a specific migration mapping can create a new hop or send the request to the wrong page.

7. Deploy, recrawl and monitor.

   Re-test the known sources immediately after deployment, then run a broader crawl to find routes created by templates or legacy data. Monitor server logs and Search Console for important migrated URLs rather than assuming a successful browser visit proves the whole mapping is correct.

What to Fix First—and What Not to Change Blindly

Fix these first

• Redirect loops or chains that exceed a crawler’s limit.
• Chains ending in 4xx client errors, 5xx server errors, blocked pages, irrelevant pages or unintended regional pages.
• Site-wide chains produced by navigation, templates, canonicals, hreflang or XML sitemaps.
• High-traffic landing pages and migration URLs with valuable external links.
• Protocol and hostname routes such as HTTP → HTTPS → www → final path that can be consolidated at the server or edge.

Review these with the responsible developer

• Login, third-party sign-in, checkout and payment flows where several redirects may be intentional.
• APIs and form submissions where changing between 301/302 and 307/308 may alter the request method or body.
• Temporary experiments, maintenance routes, language selection and geolocation behaviour.
• Low-use legacy URLs where the final destination is correct and changing a fragile old rule carries more risk than the extra hop.

Avoid these common mistakes

• Do not send unrelated deleted URLs to the homepage. Redirect to a close replacement only when one exists; otherwise an honest 404 or 410 may be more appropriate.
• Do not convert every temporary redirect to permanent. The status should describe the business and technical intent, not merely satisfy an audit.
• Do not remove an old source redirect solely because your current site no longer links to it. Bookmarks, campaigns and external websites may still use that URL.
• Do not rely on JavaScript when a server-side redirect is available. A server response is earlier, simpler and independent of page rendering.
• Do not test only one URL. Pattern-based rules can behave differently for paths, parameters, trailing slashes and host variants.

Worked Example: Two Migrations Created One Chain

Suppose an ecommerce category originally lived at /shop/tents. The first redesign moved it to /gear/tents. A later restructuring moved it again to /store/tents. Adding a new rule without revisiting the first one creates this route:

/shop/tents --301--> /gear/tents --301--> /store/tents
/store/tents returns 200 OK

The direct mapping keeps both historical URLs available while removing the chain:

/shop/tents --301--> /store/tents
/gear/tents --301--> /store/tents
/store/tents returns 200 OK

The site owner then updates navigation, category cards, the XML sitemap and the canonical annotation to use /store/tents. The old URLs remain useful entry points, but the current site no longer creates requests to them. A successful verification shows one redirect from either old URL, an expected final response, no loop, and no internal references to the intermediate path.

How to Verify the Fix

Re-crawl the affected URLs

Check the original source URLs and run a site-wide crawl. The report should show the exact hop count, status sequence, final URL and pages that still link to a redirect. A clean source-to-destination route does not prove that internal links or sitemaps have also been updated, so verify both.

Inspect the response headers with cURL

The following command performs a normal GET, follows redirects and prints each response-header block. The cURL manual documents the --location, --max-redirs and output options.

curl -sS -L -D - -o /dev/null --max-redirs 10 "https://example.com/old-url"

In Windows Command Prompt, use:

curl.exe -sS -L -D - -o NUL --max-redirs 10 "https://example.com/old-url"

Read the status line and Location header in each 3xx block. The final block should contain the intended final status. Using a normal GET is safer than assuming a server handles HEAD identically.

Use browser and Google tools for spot checks

In Chrome DevTools’ Network panel, preserve the log, navigate to the old URL and inspect the status and Location values. For important search landing pages, Search Console’s URL Inspection tool can help you review Google’s indexed information and test the live destination. The live test follows a redirect but does not provide a complete chain inventory, so it complements rather than replaces a crawler or header trace.

Pass criteria

• Every retained old source reaches the intended destination in one hop where practical.
• The final URL returns the expected response and is the closest relevant replacement.
• No loop, irrelevant target, cross-environment route or hidden extra hop remains.
• Current internal links and machine-readable references use the final URL directly.
• The redirect status reflects whether the move is permanent or temporary.
• Logs and follow-up crawls do not reveal a second rule recreating the chain.

Redirect Chain Checklist

• Export the full chain before changing any rules.
• Confirm the final page is relevant, available and configured as intended.
• Map each retained old URL directly to the final destination.
• Keep useful legacy redirects; remove the unnecessary intermediate journey.
• Update internal links, navigation, sitemaps, canonicals, hreflang and structured data.
• Use a permanent status only for a permanent move.
• Review method-preserving redirects with a developer for forms and APIs.
• Test host, protocol, slash, parameter and case variants.
• Re-crawl after deployment and monitor important migrated URLs.

A redirect chain is a routing and maintenance problem, not an automatic ranking catastrophe. The most reliable fix is to preserve the old URLs that still matter, send each one directly to the closest relevant final destination, and remove redirected URLs from the links and signals your own site controls.