Reduce too many redirects: cut chains to one hop

What's happening

A redirect chain happens when example.com → http://example.com → www.example.com → https://www.example.com → /home each return a 301 or 302 instead of resolving to the canonical URL in one hop. Each redirect costs a full RTT plus DNS, TLS, and origin processing — typically 200-500ms on 4G mobile per hop. Lighthouse flags this with the "Avoid multiple page redirects" audit.

Chrome DevTools' Network panel shows redirects as a chain of 301/302 responses leading to the final 200. The Status column shows the chain. WebPageTest visualizes redirects in the waterfall, making it easy to count hops and total time.

The bigger issue is search engines. Googlebot follows up to 5 redirect hops before giving up. Long redirect chains waste crawl budget, dilute PageRank, and slow indexing. The combination of slow-for-users and bad-for-SEO makes redirect cleanup a high-leverage fix.

Why it matters

Redirects directly inflate TTFB by adding round trips before the actual page response. A two-hop chain on 4G adds 400-800ms before LCP can even start. Pages with redirect chains routinely fail Core Web Vitals at the 75th percentile.

Search ranking is the secondary impact. Each redirect hop loses a small amount of link equity (generally accepted to be 0-15%). Long chains compound the loss, and Googlebot may stop following past 5 hops, leaving deeply-redirected pages unindexed.

Common causes

• Multiple redirect rules layered without consolidation (HTTP→HTTPS, then non-www→www, then trailing-slash).
• Old vanity URLs redirected to new vanity URLs that further redirect.
• Internal links pointing to non-canonical URLs that redirect.
• URL rewrite rules in nginx/Apache that loop or chain unnecessarily.
• Server-side framework default behavior (Rails trailing slash, Django www) layered on infra redirects.
• Marketing tracking parameters stripped via redirect instead of being canonicalized.

Detect this on your site

Run a quick scan with the Redirect Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Map your current redirect chains

   Run curl -ILv https://yoursite.com to see every Location header and status code. A redirect checker that follows the chain (CheckFast's /redirects tool, redirect-checker.org) gives you the same visualization in a UI. Document every chain longer than one hop.

2. 2

   Consolidate to a single redirect

   Combine HTTP→HTTPS, non-www→www, and trailing-slash normalization into one 301. nginx: a single redirect block in the HTTP server checks all three conditions and emits one Location header with the final URL.

3. 3

   Update internal links to canonical URLs

   Search the codebase for hardcoded URLs and update them to the final canonical form (https://www.example.com/page, no trailing slash if your canonical is no-slash). Internal links shouldn't trigger redirects.

4. 4

   Use 301 not 302 for permanent moves

   301 Moved Permanently signals a permanent change; browsers and search engines cache it aggressively. 302 Found is a temporary redirect — repeated unnecessarily, it forces re-resolution every visit. Use 301 for site moves, www/HTTPS canonicalization, and old URL→new URL.

5. 5

   Cache redirects at the CDN edge

   Cloudflare, Fastly, and Vercel all let you cache 301/302 responses at the edge. The redirect resolves at the POP closest to the user, saving the round trip to your origin. Set Cache-Control: public, max-age=86400 on permanent redirects.

6. 6

   Avoid client-side redirects with meta refresh or JS

   and window.location =... redirects happen after the page loads, doubling the TTFB cost. Always prefer server-side 301/302. Reserve client-side redirects for cases where server-side isn't possible.

7. 7

   Audit XML sitemap and canonical tags

   Sitemap URLs should be the final canonical URLs, never URLs that redirect. tags should match the actual page URL. Mismatch confuses search engines and triggers "submitted URL has soft 404" issues in Search Console.

Example

# Bad: multiple chained redirects
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

# Good: one redirect to the final URL
server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;

    if ($scheme != "https") {
        return 301 https://www.example.com$request_uri;
    }
    if ($host = "example.com") {
        return 301 https://www.example.com$request_uri;
    }
    # ... actual app config below
}

Consolidate HTTP→HTTPS and non-www→www into a single 301 hop.

Related fixes