Counting Every Redirect Chain Hop Between a Post and Your Page

What is a redirect chain?

Two or more HTTP 3xx responses standing between the link a reader taps and the page that finally renders make a redirect chain, and every hop in it costs a DNS lookup, a TCP connection and a TLS handshake before a single byte of your page arrives.

One redirect is not a chain. http://example.com/sale answering 301 with Location: https://example.com/sale is a single hop, and that is the cost of running HTTPS. A chain is what happens when the shortener redirects to the tracker, the tracker redirects to the www version, the www version redirects to the trailing-slash version, and the trailing-slash version finally serves HTML. Four hops, one page.

RFC 9110 defines the 3xx class and lists the codes that carry a Location header: 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect and 308 Permanent Redirect. The spec tells clients to "detect and intervene in cyclical redirections" but sets no maximum, and adds a note that an earlier version of the specification "recommended a maximum of five redirections" and that "some clients might implement such a fixed limitation."

What does each hop in a redirect chain cost?

Each hop costs a full round trip to a server that returns no content, plus a new DNS lookup and TLS handshake whenever the hop crosses to a hostname the browser has not already connected to. A shortener, a link shim and your own site are three different hostnames, so a three-hop chain usually means three handshakes.

Headers get thrown away too. RFC 9110 tells a user agent that automatically follows a redirect to remove "resource-specific header fields, including (but not limited to) Referer, Origin, Authorization, and Cookie." The user agent replaces them with values fit for the new request, so it takes a referrer policy or an HTTPS to HTTP step in the chain for a click to land in direct traffic instead of being credited to the network that sent it.

Crawlers pay a different bill. Google's crawling documentation states that "any content Google receives from the redirecting URL is ignored, and the final target URL's content is processed instead," so every intermediate hop is a fetch that produces nothing indexable and still draws down what Google is willing to crawl from your site.

How many redirects will a browser or a crawler follow?

Browsers stop at 20 and Google's crawlers stop at 10. The numbers come from two different specifications and neither one is a target to aim at.

Google's own advice sits far below its own limit. The site move guidance says to "keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5," because "chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains."

Why do social links add hops you never created?

Platforms insert their own hops before your first one, and on most networks you cannot decline. That is the part of the chain you have to budget around rather than fix.

X is the blunt case. Its help center states that links shared on X "will automatically be processed and shortened to an http://t.co link," and answers the opt-out question directly: "You cannot opt out of link shortening." Every post therefore starts at one hop before your server is contacted at all, and the t.co wrapper always counts as 23 characters no matter how short the original URL was.

Facebook and Pinterest do the same thing with different machinery. Checked on 12 September 2026:

Both of those are hops that happen entirely inside the platform. The Facebook shim does not even redirect to your site on the first response; it redirects to a second Facebook URL, which then redirects onward. Pinterest's short domain hands off to an API host before the destination is resolved. Neither hop is yours to shorten, which is the whole argument for not stacking a bit.ly on top of them.

Then there are the hops you do control: a vanity shortener, a marketing automation click tracker, an affiliate redirector, a http to https upgrade, a www canonicalization and a trailing-slash rule. Stack a shortener and a tracker behind a platform shim and you are at five hops before your CDN sees the request.

What survives the redirect chain from the query string?

The fragment survives by specification and the query string does not. RFC 9110 is explicit that when a Location value has no fragment of its own, "a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the target URI." There is no matching rule for the query, so ?utm_source=linkedin survives a hop only when the server issuing the redirect writes it into Location itself.

Whether it does is a server configuration detail, and the two common web servers behave differently enough to catch people out:

• Apache's mod_alias Redirect carries it. The documentation says that a request for http://example.com/service/foo.pl?q=23&a=42 "will be redirected to http://foo2.example.com/service/foo.pl?q=23&a=42."
• nginx's rewrite carries it unless you stop it. The documentation says that "if a replacement string includes the new request arguments, the previous request arguments are appended after them," and that "putting a question mark at the end of a replacement string avoids having them appended."
• nginx's return is not covered by that rule. The documentation describes argument appending only for rewrite, so return 301 https://example.com/new; sends exactly what you wrote and return 301 https://example.com$request_uri; sends the path and query you received.
• A Location header assembled by hand in application code carries only the parts of the URL your code copies into it.

That single detail explains most broken campaign reporting. Your UTM parameters are attached to the URL you posted, the platform shim forwards them as an opaque blob inside its own u= parameter, and then your own tidy-up redirect rewrites the path and silently discards the query. Analytics records a session with no campaign, and nobody can track social media traffic back to the post that earned it.

Parameters the platform adds behave the same way. Meta appends a click identifier to ad destinations, documented as ClickID: "a Meta-generated parameter that is passed with the URL of an advertiser's website when a user clicks an ad on Facebook and/or Instagram," in the form ?fbclid=IwAR2F4.... A redirect rule that drops the query drops fbclid with it, and the Conversions API loses the join it needed.

How do you find and flatten a redirect chain?

Trace it with one command before you argue about it. curl -sIL -w '%{http_code} %{url_effective}\n' -o /dev/null <url> walks the chain and prints what it found, and curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' <url> shows one hop at a time when you want to see exactly which server hands off to which.

Flattening is mostly bookkeeping. Point every redirect rule at the final URL rather than at the next rule, so an old /blog/post goes straight to https://www.example.com/blog/post/ in one 301 instead of passing through three. Keep the query string in the Location value on every rule that can carry one. Skip your own shortener on networks that already wrap links, since a t.co pointing at a bit.ly pointing at a tracker is three hops that all resolve to the same page.

Frequently asked questions

Is a redirect chain bad for SEO?

Long chains hurt crawling more than ranking. Google's documentation says its crawlers follow up to 10 redirect hops by default and that content from the redirecting URLs is ignored, so hops beyond that are never reached and hops inside it waste crawl capacity. Google's site move guidance asks for no more than three.

How many redirects is too many?

More than three is more than Google recommends. The hard ceilings are 20 hops for browsers implementing the Fetch standard and 10 for Google's crawlers, but the recommendation in Google's site move documentation is "ideally no more than 3 and fewer than 5."

Does a 301 pass more value than a 302 in a chain?

Google treats the two differently as canonicalization signals. Its documentation describes 301 as a strong signal that the redirect target should be canonical and 302 as a weak one, with 308 equivalent to 301 and 307 equivalent to 302. The hop costs the same round trip either way.

Do UTM parameters survive a redirect?

Only when the redirect target includes them. HTTP requires a user agent to inherit the original fragment when Location has none, but it has no such rule for the query string, so a redirect to a bare path throws away every UTM parameter on the incoming URL.

Can I stop X, Facebook or Pinterest from adding a hop?

No. X's help center states plainly that you cannot opt out of t.co link shortening, and the Facebook and Pinterest shims are server-side behavior on their own domains. The only hops you can remove are the ones on your side of the handoff.

What is the difference between a redirect chain and a redirect loop?

A chain ends at a real page and a loop never does. RFC 9110 tells clients to "detect and intervene in cyclical redirections (i.e., 'infinite' redirection loops)," which is why a loop surfaces as a browser error rather than as a slow page.

What counts as one redirect hop in a chain?

One hop is a single HTTP 3xx response carrying a Location header, the kind RFC 9110 lists as 301, 302, 303, 307 and 308. A 301 from http://example.com/sale to https://example.com/sale is one hop, not a chain. A chain starts only once a second 3xx response follows the first.

Does a URL fragment survive a redirect chain?

The fragment does survive, when the Location header carries no fragment of its own. RFC 9110 requires a user agent to inherit the fragment from the original URL in that case. The query string gets no such guarantee, which is why a fragment and a UTM parameter behave differently in the same chain.

Why does traffic from a redirect chain show up as direct in analytics?

Because the referrer can go missing along the way, not because a chain strips it by itself. RFC 9110 has the user agent remove Referer at each hop and replace it with a value fit for the new request, so the header survives a redirect unless something else drops it. A restrictive referrer policy or an HTTPS to HTTP step is what leaves the last request with no referrer, and analytics then records the session as direct instead of crediting the platform that sent the click.

Does nginx's return directive keep the query string?

Not on its own. Nginx documents query-argument appending only for the rewrite directive, so return 301 https://example.com/new; sends exactly what you wrote and drops whatever the visitor's URL carried. Adding $request_uri to the target, as in return 301 https://example.com$request_uri;, is what forwards the path and query.