How to Find and Fix Redirect Chains After Changing Website URLs
A redirect chain happens when a URL redirects to a second URL that redirects again, sometimes several times, before the visitor reaches a real page. You find chains by tracing each old URL hop by hop, and you fix them by pointing every old address straight at its final destination with a single permanent (301 or 308) redirect.
Chains build up quietly. A site moves from HTTP to HTTPS, later drops “www”, then restructures its blog, and each change stacks a new rule on top of the last. Nobody notices because the page still loads eventually. A redirect checker exposes every step, the status code returned at each one and where the journey ends.
Why a few extra hops matter
Each hop is a separate request and response. On a mobile connection, every one adds a round trip before the browser can even begin loading the page, which delays everything a website speed test measures, from Time to First Byte to Largest Contentful Paint.
Search engines have limits too. Google’s documentation states that its crawlers follow up to 10 redirect hops by default, and that some product-specific crawlers may have different limits. A chain well short of that will still be followed, but every unnecessary hop spends crawl effort, slows the discovery of your new URLs and increases the chance that something in the middle breaks later. Other crawlers, social media preview bots and email link scanners can give up sooner than Google does.
There is also a maintenance risk. Long chains often contain a temporary redirect someone forgot to make permanent, or a hop that loops back on itself after the next migration.
Permanent or temporary: choosing the right status code
| Code | Meaning | How Google treats it | Use it for |
|---|---|---|---|
| 301 | Moved permanently | Treated as a strong signal that the target should be shown in search | URL changes, domain moves, HTTPS and www consolidation |
| 308 | Permanent redirect, request method preserved | Treated the same as 301 | Permanent moves where forms or APIs must keep the POST method |
| 302 | Found (temporary) | Followed, but the original URL tends to stay in results | Short promotions, maintenance pages, A/B tests |
| 307 | Temporary redirect, request method preserved | Treated as temporary | Temporary moves that must keep the request method |
If you are changing URLs for good, use 301 or 308. A 302 left in place after a migration is one of the most common reasons old URLs linger in search results long after the new ones have gone live.
Worked example: tracing one old URL through a sample chain
A US garden supplies retailer moved its blog from /blog/ to /guides/. Months later, a backlink from a gardening forum still points to the original, pre-HTTPS address. Here is a sample redirect check on that link.
| Hop | Requested URL | Status | Time | Redirects to |
|---|---|---|---|---|
| 1 | http://example-garden.com/blog/tomato-guide | 301 | 120 ms | https://example-garden.com/blog/tomato-guide |
| 2 | https://example-garden.com/blog/tomato-guide | 301 | 140 ms | https://www.example-garden.com/blog/tomato-guide |
| 3 | https://www.example-garden.com/blog/tomato-guide | 302 | 110 ms | https://www.example-garden.com/guides/tomato-guide |
| 4 | https://www.example-garden.com/guides/tomato-guide | 200 | 180 ms | Final page |
Hop 1 upgrades HTTP to HTTPS. This is correct in itself, but it keeps the bare domain, so another hop is needed.
Hop 2 adds “www”. The HTTPS rule and the www rule were written at different times and run one after the other instead of together.
Hop 3 is the real problem: the blog-to-guides rule returns a 302. That tells search engines the move is temporary, so the old blog URL may continue to be treated as the canonical address.
Hop 4 finally returns 200 OK, the live page.
The visitor waited through three redirects totalling 370 ms before the real page even started to load, 550 ms in all including the final response. Collapsing the chain into one 301 removes two hops, about 260 ms in this sample, and it sends a clear permanent signal.
On an Apache server, a corrected rule set might look like this, sending any old blog URL directly to the final address:
| RewriteEngine On |
| RewriteRule ^blog/(.*)$ https://www.example-garden.com/guides/$1 [R=301,L] |
| RewriteCond %{HTTPS} off [OR] |
| RewriteCond %{HTTP_HOST} !^www\. [NC] |
| RewriteRule ^(.*)$ https://www.example-garden.com/$1 [R=301,L] |
The order matters: the specific path rule comes first, so a request for the old blog goes straight to its final destination, and the general HTTPS-plus-www rule handles everything else in a single step.
Trace your own old URLs: paste any former address, backlink or campaign link into the free redirect chain checker to see every hop, its status code and response time, and confirm it now lands on the final page in one step.
A clean-up routine after any URL change
1. Build a list of old URLs worth checking
Export old URLs from your analytics, your previous XML sitemap and any backlink report you have. Prioritise pages that earned traffic or links; those are where chains cost the most.
2. Map each old URL to its final destination
Write the mapping as old URL to final URL, never old URL to an intermediate. Where a page no longer has an equivalent, choose the closest relevant page rather than sending everything to the home page, which search engines may treat as a soft 404.
3. Merge overlapping rules
Combine protocol, hostname and trailing-slash rules so they resolve together. Check CMS plugins, server configuration and any CDN or hosting dashboard, because rules in different layers can stack on top of each other.
4. Update the links you control
Redirects are a safety net, not a substitute for correct links. Update internal links, navigation menus, canonical tags and your sitemap to use final URLs directly. A broken link checker can crawl your pages and flag internal links that redirect or fail.
5. Retest after every deployment
New plugins, theme changes and hosting moves can reintroduce hops. Keep a short list of key old URLs and re-run them whenever the site changes.
Frequently asked questions
How many redirects is too many?
Aim for one. Google says its crawlers follow up to 10 hops by default, but that is a ceiling rather than a target. Each extra hop slows visitors, wastes crawling and adds a point of failure. If a check shows two or more redirects before a 200 response, collapse them into a single direct redirect.
Do redirect chains hurt SEO?
A short chain of permanent redirects is usually followed without lasting damage, but it slows discovery of new URLs and the page itself. Chains that include a temporary 302, a loop or a dead end cause real problems: the wrong URL may stay indexed, or the content may not be reached at all.
How long should I keep redirects after changing URLs?
Keep them for as long as practical, ideally indefinitely. Old links in emails, bookmarks and other websites continue to send visitors for years. Removing a redirect turns every one of those into a 404 error, so the small cost of maintaining the rule is almost always worth it.
What is a redirect loop?
A loop occurs when URL A redirects to B and B redirects back to A, directly or through other steps. Browsers stop and show an error such as “too many redirects”. Loops usually come from conflicting rules, such as one layer forcing a trailing slash while another removes it.
Every URL change leaves a trail behind it. Tracing that trail and shortening it to a single hop protects your speed, your search visibility and the links other sites have given you. Make the TechBullion HTTP redirect checker the last step of every migration, and the first place you look when an old link starts behaving oddly.
Comment