--- title: "How to Find and Fix Redirect Chains Step by Step" author: "Ari Ber" category: "Search & AI Visibility" date: 2026-09-14T14:00:00.958Z canonical: "https://contentagents.dev/blog/how-to-find-and-fix-redirect-chains-step-by-step-ot06" --- # How to Find and Fix Redirect Chains Step by Step ![Finger pressing one point on a looping overlapping ink trail drawn on paper.](https://hsppuvezyxmkpzkgfkho.supabase.co/storage/v1/object/public/media/enrichment/024a6468-4c4c-4195-b8c2-21b4170617d4/92b909ca-aa3b-48f0-83d4-5dd654213a99/c4fff638-5a9a-4628-ad10-94c8315adffb.jpg) Redirect chains slow your site down, confuse crawlers, and are surprisingly easy to miss. This guide walks you through finding every chain on your site, understanding why it exists, and fixing it without breaking anything in the process. This is for founders and technical operators who manage their own site - you don't need to know Apache config by heart, but you should be comfortable opening a terminal or asking a dev team a specific question. Each step tells you exactly what to do and what to hand off. ## Step 1: Audit Your Site for Redirect Chains ![](https://cdn.pixabay.com/photo/2018/01/24/21/42/step-3104846_1280.jpg?w=960&q=75) Photo by [mikecook1](https://pixabay.com/photos/step-industry-steel-3104846/) on [Pixabay](https://pixabay.com) An audit means crawling your site to map every redirect and flag chains - sequences where URL A sends the browser to B, which sends it to C, before the page finally loads. The goal is a complete list of those chains before you touch anything. You can do this with a dedicated crawl tool or by pulling your server logs. Here's what the problem looks like in practice. Someone clicks a link to an old blog post. The browser hits URL A - your original post slug. That fires a redirect to URL B, a renamed slug from a CMS migration. B fires another redirect to URL C, a new URL structure you adopted six months later. C finally returns the page. Three hops. The visitor probably didn't notice, but the browser spent time on each one, and Google may have stopped following after the second. What a redirect chain means for your site: - Two or more hops counts as a chain. A single 301 from an old URL to a new one is fine. The moment you add a second hop, you have a chain. - Google's crawlers [may not follow a redirect chain past the second hop](https://developers.google.com/search/docs/crawling-indexing/301-redirects), which means pages deeper in a chain can go unindexed or lose link equity. - Each hop adds latency. On a slow server, a three-hop chain can add hundreds of milliseconds before the browser even requests the final page. - Chains are invisible to most analytics setups. Your traffic reports show the final destination, not the path taken to get there. - Migrations are the most common cause. Every time you restructure URLs without cleaning up old rules, you risk stacking a new redirect on top of an existing one. ### What this means in practice - Run Screaming Frog in list mode on your domain; filter for 3xx status codes; sort by redirect destination to spot duplicates and chains. The free version handles up to 500 URLs. - If you don't have Screaming Frog, export your sitemap and run it through a redirect checker tool to get status codes for every URL in one pass. - Red flags to prioritise: chains longer than two hops, any chain ending in a 404, and chains that appear to have been created by plugin conflicts or URL structure migrations. - What you can ignore for now: single 301 redirects, redirects on external domains you don't control, and intentional 302 (temporary) redirects where you know the original URL is coming back. ## Step 2: Identify the Root Cause of Each Chain Chains don't happen by accident. They're almost always the result of migrations, plugin conflicts, URL rewrites, or manual redirects layered on top of each other over time. Understanding the cause matters because it tells you where the fix needs to happen - server config, CMS, or plugin settings. A common pattern: a site migrated from old-domain.com to new-domain.com eighteen months ago. A domain-level redirect was set up at the DNS or server level. Then, six months later, the URL structure changed - /blog/post-name became /articles/post-name. A new redirect was added in the CMS for that slug change. Now every request to old-domain.com/blog/post-name goes through two separate redirect systems before landing anywhere. Neither team who set up each redirect knew the other existed. The three most common causes: **Migration leftover.** The old domain or URL structure redirect is still active after the new structure is in place. Look in your server config (.htaccess or web.config) and DNS settings. Ask your dev team if the domain-level redirect from the migration was ever removed. **CMS or plugin auto-redirect.** Some CMS platforms and SEO plugins automatically create redirects when you change a post slug or category. These are invisible unless you check the plugin's redirect log. Look in your plugin settings - Yoast, Rank Math, and Redirection all store these logs. **Manual redirect stacking.** Someone added a redirect manually, then later added another without checking if a rule already existed. Check your .htaccess or redirect management tool for duplicate entries pointing to the same original URL. ### What this means in practice - Check your .htaccess or web.config file for old redirect rules - specifically, look for any Redirect or RewriteRule lines pointing to URLs that have since been redirected again. - Open your CMS plugin's redirect log and filter for the original URLs in your chain list. If an entry exists there and in .htaccess, you have a double-rule problem. - Ask your dev team: "When we migrated to the new URL structure, did we remove the old domain-level redirect, or is it still active?" That one question resolves a large share of migration chain issues. - Check server logs for the specific request path. If you see two 301 responses before the 200, you can trace which server rule fired first. - Tools to check: server access logs, plugin redirect settings, DNS records, and any CDN redirect rules (Cloudflare, for example, has its own redirect layer that can create chains independent of your server config). ## Step 3: Map the Redirect Chain to Its Final Destination ![](https://cdn.pixabay.com/photo/2019/07/14/08/21/stands-4336430_1280.jpg?w=960&q=75) Photo by [dimitrisvetsikas1969](https://pixabay.com/photos/stands-steps-symmetry-theatre-4336430/) on [Pixabay](https://pixabay.com) Before you change anything, you need to know where each chain actually ends - not where you think it ends. The final URL is what matters for both user experience and crawl efficiency. If the final destination is a 404, or the wrong page, you have a different problem to fix first. Take a specific example: you've found a chain - /blog/old-post redirects to /blog/posts/old-post, which redirects to /articles/old-post. The final destination appears to be /articles/old-post. But is that page returning a 200? Does it have the right content? Is it the canonical version of the page, or has it been merged into another URL since? You need to follow the chain to the end and verify the status code, not assume. Use a redirect checker tool or curl in your terminal to follow the chain step by step. In a terminal: curl -IL https://yourdomain.com/blog/old-post - the -I flag returns headers only, and -L tells curl to follow redirects. Each hop will show up as a separate response block with its status code. The final block should be 200. If it's anything else, that's your first fix. ### What this means in practice - Use a redirect checker tool (the Redirect Path Chrome extension is fast for one-off checks) or curl to follow each chain and record the status code at every hop, not just the last one. - If the final destination is a 404 or an unexpected page, fix the destination first before touching the chain. Collapsing a chain that points to the wrong place just makes it faster to land on the wrong page. - Document everything before you fix anything: the full chain (A to B to C), the final destination URL, the final status code, and whether the content at the destination is still relevant and live. - Watch for chains that end on a page that is itself a redirect. Crawl tools sometimes miss this. Verify with curl directly on the final URL to confirm it's a clean 200. ## Step 4: Decide - Keep, Consolidate, or Remove Not every redirect chain needs to be deleted. Some exist for good reasons. Your job is to decide, for each chain, whether to keep it as-is, consolidate it into a single hop, or remove it entirely. The answer depends on whether the original URL still has traffic or backlinks pointing to it. Work through this decision: Does the original URL (A) still receive organic traffic? Is it linked to from external sites? Is the final destination (C) the right page? If traffic or backlinks are present, consolidation is the move - update the redirect so A points directly to C, cutting out B. If the original URL has no traffic and no backlinks, and the final destination is correct, you can remove the redirect entirely and let the URL return a 404. If the final destination is wrong, fix the destination first, then decide. Consolidation is almost always safer than removal. A direct redirect from A to C preserves any link equity passing through the chain and keeps old links functional. Removal is only appropriate when you're confident the original URL has no external value and no one is linking to it. ### What this means in practice - Check Google Search Console (GSC) for clicks or impressions on the original URL. If GSC shows any traffic in the last 90 days, consolidate, don't remove. - Check your backlink tool (Ahrefs, Semrush, or a free alternative like [Ahrefs' free backlink checker](https://ahrefs.com/backlink-checker)) for external links pointing to the original URL. Even one high-quality external link is a reason to keep the redirect. - Decision shortcut: if traffic is above zero or backlinks are above zero, consolidate. If both are zero and the final destination is correct, remove. If the final destination is wrong, fix the destination first, then revisit. - For consolidation: update the redirect rule to point directly from A to C. For removal: delete the redirect rule and confirm the URL returns 404 (or redirect it to a genuinely relevant page if one exists). ## Step 5: Update or Remove Redirects in Your Server or CMS The fix depends entirely on where the redirects live. They might be in .htaccess, web.config, your CMS, a plugin, or a CDN layer. You need to know the source before you touch anything - changing the wrong file fixes nothing and can break other rules in the process. Concrete scenario: you've decided to consolidate a chain. The rule in .htaccess currently reads: Redirect 301 /old-post /intermediate-post. The intermediate-post then redirects to /articles/final-post via a CMS plugin. You need to change the .htaccess rule to Redirect 301 /old-post /articles/final-post and remove or disable the intermediate rule in the plugin. One hop, one rule, one place to maintain. The three most common locations and who handles each: **.htaccess (Apache servers).** This is a plain text file in your site's root directory. Your dev team or a server admin should make changes here. Find the relevant Redirect or RewriteRule line, update the destination, save, and test immediately with curl. Don't edit this file without a backup. **web.config (IIS/Windows servers).** Same principle, different syntax. Find the rewrite rule in the system.webServer section, update the destination URL, and test. Your dev team owns this file. **CMS plugin (WordPress, etc.).** If you're using a plugin like Redirection or Yoast, the redirect rules are stored in the database and managed through a UI. You can usually update these yourself. Find the original URL entry, update the destination, and save. Test before assuming it worked. ### What this means in practice - Before changing anything, take a copy of the current redirect rule - screenshot the plugin entry or paste the .htaccess line into a doc. You'll want this if you need to roll back. - For .htaccess: find the Redirect line, update the destination URL, save the file, and run curl -IL https://yourdomain.com/old-post to confirm one hop and a 200 at the end. - For CMS plugins: update the destination in the plugin UI, clear your site cache, and test with a redirect checker tool. Plugin caches can mask whether the update took effect. - If your CDN (Cloudflare or similar) has its own redirect rules, check there too. CDN-level rules fire before your server rules and can create chains that look like server problems. - Before deploying any change to production, use a redirect checker or curl on a staging environment to confirm the chain collapses to one hop and the final URL returns 200. ## Step 6: Test and Monitor for Broken Redirects After you update or remove redirects, you need to verify nothing broke. A misconfigured redirect can tank traffic on pages that were ranking. Test the old URLs, the new URLs, and the final destinations - in that order, before you close the ticket.