All posts
Platform migrations

Redirect Chains and Loops: How to Find and Fix Them After a Migration

Redirect chains and loops quietly waste crawl budget after a migration. A crawl-based workflow to find them, flatten them to one hop and stop them coming back.

By Mehdi Hassan8 min read

The short answer

Redirect chains hurt SEO because every extra hop slows the page, wastes crawl effort and adds a chance for the chain to break. To fix them after a migration, crawl the old URLs, list every redirect with more than one hop, and point each old URL straight at its final live destination in a single 301.

Key takeaways

  • The rule is one hop: every old URL should 301 straight to a live 200 page, never to another redirect.
  • Migrations stack new redirects on top of old ones, so chains appear even when every rule looks correct.
  • Crawl your old URL list, not just the new site, or you'll miss the chains that matter most.
  • A loop is a chain that points back at itself; it breaks the page completely, so fix loops first.
  • Update internal links to the final URL, so the site itself never relies on a redirect.

Part of Website Migration SEO Checklist: Keep Your Rankings When You Switch Platforms

What are redirect chains and redirect loops?

A redirect chain is any path where one URL redirects to a second URL that redirects again before the visitor reaches a real page. A redirect loop is a chain that never ends because it points back to a URL earlier in the chain, so the browser gives up and shows an error.

A typical chain after a migration looks like this: /blog/old-post redirects to /resources/old-post, which redirects to /blog/new-post, which then adds a trailing slash. That's three hops for one click. Each rule made sense when someone wrote it. Together they make a slow, fragile path. Chains are one of the most common problems we catch in the post-launch checks of our website migration SEO checklist, and they're cheap to fix once you can see them.

Why do redirect chains hurt SEO?

Redirect chains hurt SEO in three ways: they slow the page, they waste the attention search engines give your site, and they raise the odds that a signal gets lost. Google's documentation on redirects recommends pointing straight at the final destination and warns that crawlers stop following long chains, so a URL deep in a chain may never be reached at all.

  • Speed. Each hop is another round trip before the page starts loading. On mobile networks that delay is easy to feel.
  • Crawl effort. A crawler that spends requests walking chains spends fewer on your real pages. On small sites this is minor; on large CMS-driven sites it adds up.
  • Fragility. Every hop is a rule that can be deleted, edited or broken by the next platform change. One broken link in the middle turns the whole chain into a 404.
  • Messy signals. When old URLs, internal links and sitemaps all point at different steps of the same chain, it's harder for search engines to settle on one canonical page.

A single 301 from old URL to new URL is normal and fine. The problem is the second, third and fourth hop.

Why do migrations create so many redirect chains?

Migrations create chains because new redirects get layered on top of old ones instead of replacing them. If your site has moved before, the old platform already holds redirects from the move before that. When you add a fresh map pointing the previous URLs to new ones, the oldest URLs now pass through two maps.

The other common causes are quieter. A platform may add or remove trailing slashes, force lowercase, or redirect http to https and non-www to www as separate steps. A domain change adds yet another layer, which is why domain change SEO needs its own plan. And internal links copied from the old site keep pointing at old URLs, so even your own navigation sends visitors through redirects.

How do you find redirect chains with a redirect chain checker?

You find redirect chains by crawling a list of old URLs in list mode and reporting every URL that takes more than one hop to reach a 200 page. A one-off redirect chain checker in the browser is fine for spot checks, but a migration needs a crawler that runs your full URL list at once.

Desktop crawlers like Screaming Frog and the site audit tools in Ahrefs and Semrush all report chains and loops. The source list matters more than the tool. Build it from four places: the old sitemap, a crawl of the old site before launch, your top landing pages in analytics, and the pages with the most backlinks. Combine them, remove duplicates and keep it as the master test list for the migration.

Source of URLs

Why it matters

Where to get it

Old sitemap

The pages you knew about

Saved copy of sitemap.xml from before launch

Old site crawl

Pages missing from the sitemap

A crawler run on the old site before cutover

Top landing pages

Where real traffic arrives

Analytics and Search Console performance reports

Backlinked URLs

Where authority comes from

The top pages report in your backlink tool

Old redirect rules

Earlier migrations still in play

Export from the old platform or server config

How do you fix redirect chains after a migration?

You fix a redirect chain by rewriting the first rule so it points directly at the final live URL, then removing or updating the hops in between. This is the one-hop rule: every old URL should resolve to a 200 page in exactly one 301.

  1. Export the chain report

    From your crawl, export every URL with two or more hops, including each hop and the final status code.

  2. Find the true destination

    For each chain, note the last URL. If it ends in a 200, that's the target. If it ends in a 404, pick the closest live page instead.

  3. Rewrite the first hop

    Change the redirect for the original URL so it points straight at the destination. Do this for every URL in the chain, not just the first one, because each may have its own backlinks.

  4. Fold old maps into one

    Merge redirects from earlier migrations into your current 301 redirect map, so one sheet holds every rule and none point at another redirect.

  5. Normalize URL format once

    Make the destination already match your preferred protocol, host, case and trailing slash, so the platform doesn't add hops of its own.

  6. Update internal links

    Replace links in navigation, footers, CMS content and sitemaps with the final URLs, so your own site never triggers a redirect.

  7. Recrawl and confirm

    Run the master list again. The target is zero chains, zero loops and every old URL ending in a 200 after one hop.

Hypothetical example: flattening a three-hop chain

For example, suppose a SaaS site moved its blog from /resources/ to /blog/ two years ago, and is now moving platforms and renaming several posts. The URL /resources/pricing-guide currently redirects to /blog/pricing-guide, and the new map redirects /blog/pricing-guide to /blog/saas-pricing-guide, and the new platform adds a trailing slash.

The fix is two rules, both pointing at the final URL with its trailing slash: /resources/pricing-guide goes straight to /blog/saas-pricing-guide/, and /blog/pricing-guide goes straight to /blog/saas-pricing-guide/. The middle rule is replaced, not stacked.

How do you fix redirect loops?

You fix a redirect loop by finding the rule that points back to an earlier URL in the chain and deleting or retargeting it. Loops break the page completely, so fix them before chains. They usually come from two rules that undo each other, such as one adding a trailing slash and another removing it, or a wildcard rule that also catches its own destination.

Wildcard and pattern rules are the usual suspects. A rule that sends everything under /blog/ to /articles/ is fine until someone adds a second rule sending /articles/ back to /blog/ for a different reason. Each platform handles patterns differently, so check how your setup orders rules in Webflow 301 redirects, Framer redirects or Next.js redirects. In Next.js, loops also appear when middleware and config redirects both act on the same path.

How do you keep redirect chains from coming back?

You keep chains from coming back by treating the redirect map as a living document, owned by one person, and checking it every time a URL changes. Chains return when people add redirects in the platform panel without looking at what already points at the old URL.

  • Keep one master redirect sheet for the life of the site, and add every new rule there before adding it to the platform.
  • Before creating a redirect, search the sheet for the old URL as a destination. If something already points at it, update that rule too.
  • Rerun the master URL list after every launch, rename or restructure, and once a quarter otherwise.
  • Watch Search Console for pages flagged with redirect errors, and read any traffic drop after a website migration as a reason to check chains first.
  • Clean up related debt, like soft 404s and broken links, at the same time. Our guide on fixing broken links and redirect chains covers the wider audit.

When we take on a migration, we include redirects and SEO checks in the work, and the master URL list is the first file we build. If you want a second opinion on a site that's already live, a free 30-minute call is enough to tell you whether chains are part of the problem.

Frequently asked questions

How many redirects in a row are too many for SEO?
Aim for one. A single 301 from an old URL to its new home is normal and passes signals well. Two hops are usually tolerated but add delay and risk. Beyond that, search engines may stop following the chain. There's no benefit to extra hops, so the practical rule is to flatten every chain to a single redirect whenever you find one.
Do redirect chains lose link equity?
Google has said that 301 redirects don't lose PageRank on their own, but chains create risk that a single redirect doesn't. A broken hop turns the whole chain into a 404, and crawlers may not follow very long chains to the end. The safe approach is to point every backlinked URL directly at its final destination, so there's nothing in between to break.
Should I remove old redirects after a migration?
Keep redirects for any URL that has backlinks or still gets traffic, ideally for good. Removing them turns earned links into 404s. What you should remove are the intermediate hops: rewrite old rules to point straight at final URLs, then the middle rules are no longer needed. Review the sheet once a year and drop only rules for URLs nobody links to or visits.
Is a 302 redirect in a chain a problem?
Yes, if the move is permanent. A 302 tells search engines the change is temporary, so they may keep the old URL indexed. In a migration, almost every redirect should be a 301 or 308. Check your crawl for 302s, which often come from platform defaults, login walls or marketing tools, and change them to permanent redirects where the old URL isn't coming back.
Can redirect chains cause a traffic drop?
They can contribute to one. A chain that ends in a 404 loses the page completely, and chains through http, non-www and trailing-slash variants slow pages and confuse canonical signals. After a migration, a traffic drop usually has several causes, so check redirect chains alongside missing redirects, changed content, lost internal links and noindex tags left on from staging.

· CEO & Design Director

Copywriter, designer and developer, and founder of Designify Studio. Over five years, 60+ projects across 14+ industries, for startups that have raised $300M+.

Want this done for you? Website, $8,000.

A multi-page marketing site, designed by us, developed in Next.js and animated. $8,000, one-time, up to 6 pages. Book a free 30-minute call to see if it fits.

Schedule Call