Check your redirect chains now

SiteCurl counts the number of redirects between the requested URL and the final page. Zero or one redirect is fine. Two is acceptable. Three or more is flagged as a warning because each hop adds a full network round trip to the load time.

Common redirect chains happen when HTTP redirects to HTTPS, then the bare domain redirects to www, then the old URL redirects to the new one. Each step is reasonable on its own, but together they add up to three round trips before the page even starts loading.

SiteCurl reports the total redirect count for each page. On a full scan of 50 pages, you can see which pages have clean direct paths and which ones are bouncing visitors through multiple hops.

A redirect is an instruction from the server: 'this page is not here, go look over there.' The browser follows the instruction, sends a new request to the target URL, and waits for a response. If that response is another redirect, the browser follows it again. Each hop costs 50 to 300ms depending on server speed and network conditions.

Redirect chains build up over time. A common pattern: the site moved from HTTP to HTTPS (one redirect). Then it switched from bare domain to www (second redirect). Then the URL structure changed during a redesign (third redirect). Nobody cleaned up the earlier redirects because each one still 'worked.' But stacked together, the visitor waits for three server round trips before seeing any content.

Search engine crawlers also follow redirect chains, but they have limits. Google gives each site a crawl budget. Every redirect uses part of that budget on a hop instead of on indexing real content. Long chains can also cause crawlers to give up and stop following the chain entirely.

The fix is usually simple: point the first URL directly to the final destination. Instead of A to B to C, make A go straight to C. This requires updating your server config, but it is a one-time change that speeds up every future visit.

Each redirect adds latency. Two extra redirects can add 200 to 600ms to page load time. On mobile connections, the delay is even larger because each round trip takes longer on slower networks.

Search engines allocate a crawl budget to your site. Redirects consume that budget without indexing any content. A site with many redirect chains gets crawled less efficiently, which can delay how quickly new or updated pages appear in search results.

Redirect chains also create maintenance problems. When URLs change again in the future, the chain gets longer. What started as one redirect becomes four. Cleaning up chains now prevents them from growing worse with each site update.

Sites that have been through multiple redesigns accumulate the most redirect chains. Each redesign changed URL structures, and each time the old URLs were redirected to the new ones. But the redirects from the previous redesign were never updated, so they now point to the intermediate URLs which themselves redirect.

E-commerce sites with seasonal products often redirect old product URLs to category pages. If the category page also moved, the chain grows. Multiply this across hundreds of products and the crawl budget impact is real.

Multi-domain setups (separate domains for blog, store, and marketing site) frequently have redirect chains at the domain boundaries. A link from the blog to the store may go through two or three redirects before reaching the final page.

Step 1: Map your redirect chains. Run a SiteCurl scan to see which pages have three or more redirects. For each one, note the starting URL and the final destination URL. The goal is to skip every step in between.

Step 2: Update server redirects. In your server config, change the redirect rule so the original URL points directly to the final destination. In Nginx, update the return 301 rule. In Apache, update the RedirectPermanent rule in .htaccess. In Cloudflare, update the redirect rule.

Step 3: Fix internal links. Update any internal links that point to URLs that redirect. If your navigation links to /old-page and that redirects to /new-page, update the link to point to /new-page directly. This eliminates the redirect for every visitor who clicks that link.

Step 4: Consolidate HTTP and HTTPS redirects. If your site redirects HTTP to HTTPS and also redirects the bare domain to www (or vice versa), combine these into a single rule. Redirect http://example.com straight to https://www.example.com in one step.

Mistake 1. Stacking new redirects on top of old ones. When a URL changes, update the existing redirect rule instead of adding a new one. If /old points to /middle, and /middle now points to /new, update /old to point straight to /new.

Mistake 2. Using 302 redirects for permanent moves. A 302 tells search engines the move is temporary. They keep the old URL indexed and follow the chain on every crawl. Use 301 for permanent changes so search engines update their records and stop following the old path.

Mistake 3. Forgetting about external links. You can fix internal links, but links from other sites will still hit the old URL. Make sure your server redirect goes straight to the final destination so external visitors do not get stuck in a chain.

After updating your redirect rules, run another SiteCurl scan. The redirect count for affected pages should drop to two or fewer. You can also test individual URLs with curl -sIL https://yoursite.com/old-page to see each step in the redirect chain. Each line starting with HTTP/ is a hop.

Check that the final destination returns a 200 status code. If it returns another redirect, you have more chain links to clean up.

Redirect chains are invisible to most site owners but add real delay for every visitor. Find pages with three or more hops, update the rules to skip the middle steps, and fix internal links to point to the final URL directly. One cleanup pass prevents the chains from growing worse over time.