How to Find and Fix Redirect Chains Without Losing Useful Destinations

When a website changes a page’s URL, a redirect sends visitors and search crawlers from the old address to another one. A redirect chain forms when that new address redirects again before the request reaches a final page. For example, /old-page may lead to /renamed-page, which then leads to /current-page.

To fix a chain without discarding a useful destination, trace each step in the redirect path. Confirm that the final page serves the old page’s purpose, then point the old URL directly to the right replacement. Keep the old URL working for people and links that still use it, and update your own links to go straight to the final page.

What a redirect chain tells you

Each redirect tells the browser or crawler to make another request, usually to the address named in the response’s Location header. A chain therefore adds extra requests between the original URL and the page the visitor wants. A loop, such as /page-a redirecting to /page-b and back again, never reaches a final page.

Redirect codes also signal whether a move is intended to last. Google treats 301 and 308 as permanent redirects, and 302 and 307 as temporary ones. Use a permanent redirect when the old URL has moved for good; use a temporary redirect when you expect the original URL to remain the preferred address in search. Google describes redirects as a signal for choosing a canonical URL, meaning the address it considers the main version of a page. That signal does not guarantee that Google will select the destination you intended. See Google’s guidance on redirects and Search and how Google chooses canonical URLs.

A chain report shows how requests currently move. It does not prove that the last URL is the best destination. If an old product page now ends at the homepage, for instance, the redirect path alone cannot tell you whether the product still has a relevant replacement.

Find every hop, including old URLs

Start with both a website crawl and a list of URLs worth checking. A crawler finds redirecting links it can discover on the site, but it will miss old addresses that no current page links to. Add URLs from previous sitemaps, your content management system, server logs or analytics, and Search Console link data. Google recommends using these kinds of records to build a URL map during a site move.

For a quick header check, curl can show the first response or follow the redirect path:

curl -sS -D - -o /dev/null 'https://example.com/old-page'
curl -sS -L -D - -o /dev/null --max-redirs 20 'https://example.com/old-page'

The first command shows the response headers for the requested URL. The second follows redirects and prints the headers at each step, so you can inspect every status and destination. Both commands use a GET request, which asks the server for the page. A HEAD request asks only for the response headers, and the server can handle it differently from a GET request.

For each URL, record the starting address, every redirect status and target, the final response code, and what the final page actually contains. Also check whether your internal links, sitemap, and the destination page’s canonical tag, which tells search engines its preferred URL, all point to the same address. If your crawler reports only a final status, inspect the full path before changing rules.

Google says its general crawlers follow up to 10 redirect hops by default, while specific Google products can behave differently. Google also says long chains negatively affect crawling. That limit describes crawler behavior, not a recommended chain length or a known ranking threshold. A chain report does not establish that a particular URL lost rankings because of its hop count. See Google’s crawler status-code guidance and its advice on crawling errors.

Confirm the destination before shortening the chain

Check whether the final destination’s content serves the old page’s purpose. A relevant replacement should satisfy the same basic need, such as offering the updated version of a guide or the current page for a discontinued product’s successor. If the destination covers a different subject, returning a successful status does not make it a suitable replacement.

When a page has a genuine replacement, redirect the old URL to that page. When the content is gone and no similar replacement exists, Google recommends returning a real 404 or 410 response rather than sending visitors to an unrelated page. Redirecting many unrelated URLs to the homepage can discard the useful destination visitors and crawlers expected to find. Google’s site migration guidance covers mapping old URLs to suitable new ones and handling pages that have no replacement.

A final 200 response only means that the server returned a successful response. It does not prove that the page is useful or eligible for indexing. Google can treat an empty or error-like page as a soft 404, meaning it looks missing or broken, even when the server returns 200. Check the page itself. Also check its preferred URL and the signals that tell search engines whether to index it.

Shorten the path and keep the old entry point

After you confirm the correct destination, set the redirect rule to send the original URL directly to it. For example, replace /old-page → /renamed-page → /current-page with /old-page → /current-page. Keep the original URL’s redirect in place if people or external links still use it.

Then update the site’s own links to point straight to /current-page. Check the destination’s canonical tag and sitemap entry. Also check relevant language or regional references; all three should agree about the preferred URL. Google recommends updating these signals during a site move; its canonicalization documentation explains how it interprets multiple signals.

After changing the rules, request the original URL and confirm that it redirects directly to the intended destination. Check the destination’s response and content. Then crawl the site again to find internal links that still go through an old URL. Search Console can help you review indexing and crawl issues, but a direct request or crawler report is needed to map each redirect hop.

Google advises considering long-term retention of redirects for users who still visit old addresses, while updating links to use the new URLs. It does not set one universal removal date for every redirect. Removing a redirect simply because it is old can break access for people following an old bookmark or external link.

What the cleanup can and cannot establish

A shorter route removes unnecessary requests and gives crawlers a clearer path to the destination. Google states that permanent redirects do not cause a loss of PageRank, but that does not mean every chain has no cost: extra hops can affect crawling and add delay for visitors. The available guidance does not establish a universal number of hops at which rankings fall, or a specific ranking gain from removing one.

A clear redirect path helps a crawler reach the intended page. That alone does not show that search engines will index the page, cite it in an AI search feature, or show it in an answer. The evidence supports fixing access and destination problems, not promising AI-search visibility.

Key Takeaways

• Trace every hop: Record each response code and destination, then inspect the final page rather than relying on the chain report alone.
• Match the destination to the old page’s purpose: Send visitors to a genuine replacement; use a 404 or 410 when no similar page remains.
• Point old URLs directly to the right page: Remove unnecessary hops, update internal links and sitemap signals, and keep useful redirects for people using old addresses.
• Treat hop limits as crawler behavior: Google’s stated limit of up to 10 hops is not a recommended target or proof of a ranking threshold.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com