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.
Export the chain report
From your crawl, export every URL with two or more hops, including each hop and the final status code.
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.
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.
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.
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.
Update internal links
Replace links in navigation, footers, CMS content and sitemaps with the final URLs, so your own site never triggers a redirect.
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.
