How to Fix Redirect Chains (and Check They're Gone)

Short answer: a redirect chain is a URL that reaches its final page only after two or more redirects (A → B → C). Fix it by pointing the first URL straight at the final destination, update every internal link and sitemap entry to that final URL, then re-test to confirm it is one hop ending in a 200.

What a redirect chain is, in plain terms

A redirect tells browsers and search engines that a URL has moved. One redirect is normal. A chain happens when the destination is itself a redirect:

http://example.com/old-page
  -> 301 -> https://example.com/old-page
  -> 301 -> https://www.example.com/old-page
  -> 301 -> https://www.example.com/new-page/
  -> 200 OK

Three hops to reach one page. Nobody planned it. Each redirect was added at a different time by a different person: an HTTPS switch, a www decision, a trailing-slash rule, a page rename. Each rule works on its own. Stacked together, they form a chain.

Does it matter?

Be precise here, because a lot of articles are not.

• Google follows long chains. Google's crawler documentation says its crawlers follow up to 10 redirect hops by default. Some third-party posts quote 5 hops; treat that as folklore unless you can point to Google's own page.
• Google does not document a ranking penalty for chains. We will not tell you a chain "kills your rankings". Nobody can promise that, and Google does not say it.
• There are still real reasons to fix them. Every hop is an extra request, so pages load more slowly for people. Every hop is another rule that can break, conflict or loop. And a chain that mixes 301 and 302 sends mixed signals: Google treats a permanent redirect as a strong signal that the target should be canonical, and a temporary one as a weak signal.

So the honest case for fixing chains is: fewer requests, fewer places to fail, and a clean redirect map you can trust after a migration.

How to find redirect chains

Manually, one URL at a time

With curl, follow the redirects and print each status line and Location header:

curl -sIL https://example.com/old-page | grep -iE "^(HTTP|location)"

Every HTTP/ line after the first is a hop. To get just the count and the final URL:

curl -sIL -o /dev/null -w "%{num_redirects} hops -> %{url_effective} (%{http_code})\n" https://example.com/old-page

In Chrome, open DevTools, go to the Network tab, tick Preserve log and load the URL. Each redirect shows as its own 301, 302, 307 or 308 row.

Don't rely on Search Console's URL Inspection to see the full path: Google's documentation says its inspection tools don't follow redirects.

In Search Console

The Page indexing report lists URLs that are not indexed and why. Look for redirect-related statuses such as Page with redirect and Redirect error. Open Redirect error first: it can point to a loop, a chain that is too long, or a redirect to a bad URL.

With a crawler

Manual checks do not scale past a handful of URLs. A crawler follows your internal links, so it finds the chains your visitors and bots actually hit. SiteOptima does this: it crawls your pages (up to 50 per audit on Starter, up to 100 on Pro and Agency), records each redirect hop, flags redirect chains and shows the evidence for each affected URL. It does not change your redirects; you or your developer do that.

Common causes

• Stacked protocol, host and slash rules. HTTP → HTTPS, then non-www → www, then add a trailing slash, each as a separate redirect.
• Migrations layered on migrations. Old URL → 2022 URL → 2024 URL → today's URL. Nobody updated the first rule when the second was added.
• CMS or plugin redirects plus server redirects. A plugin rewrites the path, then the server redirects the result.
• Internal links that still point to old URLs. The redirect works, but every click goes through it.
• Sitemaps listing old URLs. Same effect: crawlers are sent through a redirect to reach each page.
• Redirect loops. A → B → A. These never resolve and end in a redirect error.

How to fix redirect chains

The rule is always the same: the first URL redirects directly to the final URL.

1. Map each chain. Write down the start URL, every hop with its status code, and the final URL. Confirm the final URL returns 200, not a 404.
2. Pick the right redirect type. If the move is permanent, use a 301 or 308. Google's redirect documentation separates permanent redirects (the target is shown in search results) from temporary ones (the source stays in search results).
3. Rewrite the first rule. Examples below.
4. Update internal links. Change links in navigation, content, canonical tags and hreflang annotations to the final URL. A redirect should be a safety net, not the route people take.
5. Update the sitemap. List final URLs only.
6. Remove dead rules. Once nothing points at an interim URL, delete rules that no longer serve a purpose. Keep the ones that protect old URLs that still have links or traffic.

Apache (mod_alias):

# Before: two rules, a chain
Redirect 301 /old-page /interim-page
Redirect 301 /interim-page /new-page

# After: both old URLs go straight to the final page
Redirect 301 /old-page /new-page
Redirect 301 /interim-page /new-page

nginx:

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

For protocol and host, send every variant to the final version in one rule, not one rule per variable. Back up the configuration before you edit it, and test on staging if you have one.

How to check it is fixed

Most guides stop at "update the redirect". This is the part that tells you whether it worked.

1. Re-run the curl command on every URL from your map. Expected result: 1 hop, final status 200.
2. Test the variants that created the chain: http and https, www and non-www, with and without the trailing slash.
3. Re-crawl the site. Chains can hide in URLs you did not map. Run the audit again and compare which redirect findings are gone and which are still there.
4. Check Search Console later. The Page indexing report can show whether the redirect-related statuses shrink. Google decides when it recrawls, so this takes time.

SiteOptima is built around that re-crawl step: you run an audit, apply the fixes outside the tool, then audit again and see which findings were resolved and which remain open.

Checklist

• Chain mapped: start URL, each hop and status code, final URL
• Final URL returns 200
• Permanent moves use 301 or 308
• First URL redirects straight to the final URL (1 hop)
• Protocol, host and slash variants all reach the final URL in one hop
• Internal links, canonicals and hreflang point to final URLs
• Sitemap lists final URLs only
• No redirect loops
• Obsolete rules removed, useful ones kept
• Site re-crawled and the before/after compared

FAQ

How many redirects in a chain is too many?

Google's documentation says its crawlers follow up to 10 hops by default. That is a ceiling, not a target. Aim for one.

Do redirect chains hurt SEO?

Google does not document a penalty. Chains add requests and failure points, and long ones or loops can end in a redirect error. Fix them for those reasons.

Is a 301 or a 302 better inside a chain?

Use the type that matches the move. Permanent move: 301 or 308. Temporary: 302 or 307. Google reads a permanent redirect as a strong signal and a temporary one as a weak signal that the target should be canonical.

What is the difference between a chain and a loop?

A chain ends at a page. A loop sends the request back to a URL it already visited, so it never ends.

Can I fix redirect chains without a developer?

On WordPress or another CMS with a redirect plugin, often yes. On server configuration (Apache, nginx, CDN rules), edit carefully and keep a backup.

Sources

• Google Search Central: Redirects and Google Search
• Google crawling documentation: How HTTP status codes affect Google's crawlers