Redirect chains tend to grow quietly after a domain move or an HTTPS migration. The launch looks clean, the homepage loads, and a few weeks later old URLs are taking four hops to reach the right page. This article covers how to monitor redirect chains so you find extra hops, loops and broken destinations before users, search engines or payment providers do. It is written for site owners, developers and operations engineers who have just changed a site’s domain or switched it to HTTPS.
Getting this right protects the search equity you built on the old URLs. It also keeps page load times down and stops the “too many redirects” error page from appearing at the worst moment.
Why Migrations Produce Redirect Chains
Most chains come from layers that were each set up correctly but never tested together. A CDN forces HTTPS, the web server adds “www”, the CMS adds a trailing slash, and a migration rule maps the old domain to the new one. Each rule works on its own. Put them together and one request can bounce three or four times.
A typical case is a company moving from http://shop-old.fi to https://www.shop.com. A request for an old product URL can go like this: http://shop-old.fi/product → https://shop-old.fi/product → https://www.shop-old.fi/product → https://www.shop.com/product → https://www.shop.com/product/. That is four redirects before the browser gets any content. On a mobile connection with 100-150 ms round trips, plus a new TLS handshake for each new hostname, the chain can add 500-800 ms before the first byte of the real page.
Googlebot follows up to 10 redirect hops and then gives up on the URL. Chrome stops at 20 and shows ERR_TOO_MANY_REDIRECTS. Those limits sound generous, but a chain usually causes damage well before it reaches either one.
The Myth That a 200 Response Means the Migration Worked
Most basic uptime checks follow redirects by default and report only the final status code. If the last hop returns 200, the dashboard shows green, even if the user went through five hops, a temporary 302 that should have been a 301, and a stop on a hostname whose certificate expires next month.
A green check only tells you that something loaded at the end of the chain. It does not tell you that the right page loaded, by the right route, with the right status codes. If you need a refresher on 301, 302, 307 and 308, see the guide to HTTP status codes. The difference matters here: 307 and 308 keep the request method, while 301 and 302 can quietly turn a POST into a GET.
A second myth is that a 301 passes everything along, so the number of hops doesn’t matter. Google has said 3xx redirects no longer lose PageRank. Even so, every extra hop adds latency and is another point where things can fail, and a long chain increases the chance that a crawler stops early or that one hop points somewhere it shouldn’t.
How to Set Up Redirect Chain Monitoring
An experienced SRE starts with a curl trace before setting up any monitor. Running curl -sIL http://old-domain.fi/some-page lists every hop with its status code and Location header. Reading through 20-30 of these by hand for your most important URLs shows you quickly where the chains are.
Then turn that one-off check into ongoing coverage:
1. Export the 20-50 old URLs with the most traffic or backlinks from Google Search Console or your analytics. The homepage alone is not enough.
2. Write down the expected final URL and the expected maximum number of hops for each. One hop is the target and two is acceptable.
3. Create HTTP checks that do not follow redirects. Check that the first response is a 301 or 308 and that the Location header points to the final destination.
4. Create a separate check on the final URL that expects a 200 and a keyword that only appears on that page.
5. Monitor the certificate on every hostname in the chain, including the old domain, because old domains still terminate TLS for every HTTPS request that hits them.
Step 4 is the one people most often skip. A redirect that ends on a working page can still end on the wrong page. Pairing the destination check with keyword checks that confirm the page content catches the common failure where every old URL quietly sends users to the new homepage.
Run these checks every minute for the first 2-4 weeks after the migration. That is when CDN rule changes, plugin updates and DNS changes are most likely to break something.
Common Mistakes After a Migration
Removing the old domain’s certificate too early. Teams move the certificate to the new domain and let the old one expire, thinking the old domain “only redirects”. An HTTPS request to the old hostname has to finish the TLS handshake before any redirect can happen. With an expired certificate, every bookmarked https:// link gets a full-page browser warning. If the old domain still gets traffic, monitor its certificate as closely as the main one.
Creating a loop with CDN SSL modes. A well-known example is Cloudflare’s “Flexible” SSL mode combined with an HTTP-to-HTTPS redirect on the origin server. Cloudflare connects to the origin over plain HTTP, the origin redirects to HTTPS, Cloudflare requests HTTP again, and the loop never ends. Testing from inside the origin network will not show it. Only an external check that goes through the CDN will.
Trusting what you see in your own browser. If your browser has already received an HSTS header, it upgrades http:// to https:// internally before sending anything, so the HTTP hop never shows up in your testing. A first-time visitor or a monitoring probe goes through the real chain. Always test from a clean client or an external probe.
Edge Cases Where the Standard Advice Changes
Webhook and API endpoints follow different rules. Many webhook senders, Stripe included, treat any non-2xx response as a failed delivery. A 301 on an old callback URL therefore causes silent failures, not a redirect. Update callback URLs at the provider directly, and monitor those endpoints for a 2xx response, not a 3xx.
Sites serving several countries or languages often redirect visitors based on their location or Accept-Language header. A probe in Frankfurt and a probe in Helsinki can see different chains for the same URL, so monitor from at least two regions. On-premises or intranet migrations need internal probes, because an external service cannot reach those hostnames.
Teams with fewer than 10 people usually don’t need a full redirect map in a spreadsheet. Checking the 10 old URLs with the most backlinks catches most problems with far less work.
How Long to Keep Monitoring the Old Domain
Google recommends keeping redirects in place for at least a year after a site move. The safest approach is to keep them indefinitely and keep the old domain registered. Check Search Console after 3, 6 and 12 months to confirm that the old URLs are leaving the index and the new ones are ranking in their place. A drop in rankings that shows up during this time is often caused by a broken redirect, which is why downtime and its effect on SEO rankings is worth reviewing alongside your migration plan.
FAQ
How many redirects in a chain is too many?
Aim for one hop from any old URL to its final destination. Two is acceptable. Three or more should be fixed, both for speed and for crawler reliability.
Should my uptime monitor follow redirects?
Use both kinds of check. Checks that don’t follow redirects confirm the exact status code and Location header. Checks that do follow them, combined with a keyword match, confirm that users end up on the right content.
Is a 302 redirect acceptable after a migration?
Only for changes that really are temporary. A permanent move should use 301 or 308, or search engines may keep the old URLs indexed for much longer.
Summary
Redirect chains after a migration seldom break all at once. They gain extra hops, temporary codes and expiring certificates over time while a basic uptime check stays green. Trace your top URLs with curl, monitor the first hop and the final page as separate checks, and keep certificates valid on every hostname in the chain. Plan for at least a year of monitoring, and give the old domain as much attention as the new one.