A single link rarely takes you straight to its destination. Click a shortened URL, a marketing link, or a search result, and your browser often passes through several intermediate hops before the final page loads. That sequence of hops is a redirect chain. Understanding how these chains work—and how to inspect them—matters for security analysts tracking down malicious links and for engineers diagnosing performance and SEO problems.
What Is a Redirect Chain?
A redirect chain is a series of two or more HTTP redirects that occur between the URL a user requests and the resource that finally serves content. For example, bit.ly/example might redirect to tracking.example.com, which redirects to www.example.com, which redirects again to https://www.example.com/landing. Each arrow in that sequence is a separate request/response round trip.
A single redirect (one hop) is normal and often necessary—forcing HTTPS, for instance. A chain is when those hops stack up, and that is where both risk and cost accumulate. See our URL redirection glossary entry for a deeper definition.
Types of Redirects
Redirects fall into two broad groups: server-side redirects driven by HTTP status codes, and client-side redirects executed by the browser after a page partially loads.
Server-side (HTTP status codes)
- 301 Moved Permanently — The resource has permanently moved. Browsers and search engines cache the new location and pass along link equity. Use this for permanent URL changes.
- 302 Found — A temporary redirect. The original URL should still be treated as canonical, so the destination is not cached long-term. Historically, many clients changed the request method to GET on a 302.
- 307 Temporary Redirect — Like 302 but strictly preserves the original HTTP method and body (a POST stays a POST). Introduced to remove the method-changing ambiguity of 302.
- 308 Permanent Redirect — The permanent counterpart of 307: it preserves the method and body while signaling a permanent move, much like 301.
Client-side
- Meta refresh — An HTML tag (
<meta http-equiv="refresh" content="0;url=...">) that tells the browser to load another URL after a delay. It is slower and weaker for SEO than a server redirect. - JavaScript redirects — Code such as
window.location = '...'runs only after the page loads and scripts execute. Crawlers and simple HTTP clients may never follow these, which is exactly why they are popular for cloaking.
How to Inspect a Redirect Chain
The fastest command-line approach is curl. The -I flag requests headers only and -L follows redirects, so you can watch each hop:
# Follow and print the response headers for every hop in the chain
curl -ILs https://bit.ly/example | grep -iE '^(HTTP|location)'
# Or show a clean status + final-URL summary for each redirect
curl -Ls -o /dev/null \
-w 'HTTP %{http_code} -> %{url_effective}\n' \
https://bit.ly/example
Each HTTP/... line plus its Location: header reveals one hop and the status code that triggered it. In the browser, open DevTools, go to the Network tab, enable "Preserve log," and load the URL—each redirect appears as its own request with a 3xx status. For untrusted links, avoid loading them in a real browser at all and use a dedicated URL expander instead.
Why Chains Matter for Security
Redirect chains are a favorite tool of attackers because they obscure the final destination:
- Cloaking phishing and malware — A friendly-looking shortened link can mask a credential-harvesting page or drive-by download at the end of the chain. See phishing.
- Evasion — Attackers mix server and JavaScript redirects so that automated scanners following only HTTP redirects see a benign endpoint, while real browsers land on the malicious one.
- Tracking and fingerprinting — Each intermediate hop can set cookies, log identifiers, or fingerprint the visitor before forwarding them on.
- Open redirects — A trusted domain that blindly forwards to any
?url=parameter lets attackers borrow its reputation to launch their own redirect chains.
Expanding a link before clicking lets you see the true endpoint and decide whether it is safe.
Why Chains Matter for SEO and Performance
- Latency — Every hop is a full round trip: DNS, TCP, TLS, and a response. On high-latency mobile networks the delay is especially noticeable, hurting load times and conversions.
- Link-equity dilution — Search engines pass ranking signals through 301s, but each additional hop is friction and a chance for value to leak. A single 301 to the final URL is cleaner than a chain of them.
- Crawl budget — Crawlers spend requests resolving chains instead of indexing real content.
- Redirect loops — A misconfiguration where A points to B and B points back to A produces an endless loop; browsers abort with
ERR_TOO_MANY_REDIRECTSand the page never loads.
Best Practices
- Minimize hops—aim for zero or one redirect to reach the final URL.
- Redirect straight to the final destination instead of chaining through intermediaries.
- Use 301/308 for permanent moves and 302/307 only when the move is genuinely temporary.
- Update internal links and sitemaps to point at canonical URLs so redirects are not needed at all.
- Enforce HTTPS at every hop—never downgrade to HTTP mid-chain.
- Audit redirects regularly and watch for loops after migrations or CMS changes.
- Validate any user-supplied redirect target to prevent open-redirect abuse.
Tools
To trace and analyze chains safely, use the URL Expander to reveal the final destination of a shortened or suspicious link, the Redirect Chain Checker to inspect every hop and its response headers, and the HTTP Status Codes reference to interpret what each code means. All processing happens in your browser, so you can examine untrusted links without visiting them directly.
Conclusion
Redirect chains are unavoidable on the modern web, but unmanaged ones cost you speed, search rankings, and security. Inspect chains with curl or DevTools, keep them as short as possible, choose the correct status code for the situation, and always expand unfamiliar links before you trust them.