Conte cada salto da cadeia de redirecionamentos até sua página

O que é uma cadeia de redirecionamentos?

Duas ou mais respostas HTTP 3xx entre o link que o leitor toca e a página que enfim carrega formam uma cadeia de redirecionamentos, e cada salto custa uma consulta DNS, uma conexão TCP e um handshake TLS antes que um único byte da sua página chegue.

Um redirecionamento sozinho não é uma cadeia. Quando http://example.com/sale responde 301 com Location: https://example.com/sale, isso é um salto único, e esse é o custo de rodar HTTPS. A cadeia aparece quando o encurtador redireciona para o rastreador, o rastreador redireciona para a versão www, a versão www redireciona para a versão com barra final e essa última enfim entrega o HTML. Quatro saltos, uma página.

A RFC 9110 define a classe 3xx e lista os códigos que carregam um cabeçalho Location: 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect e 308 Permanent Redirect. A especificação manda os clientes "detect and intervene in cyclical redirections", mas não fixa máximo nenhum, e acrescenta uma nota de que uma versão anterior da especificação "recommended a maximum of five redirections" e de que "some clients might implement such a fixed limitation."

Quanto custa cada salto de uma cadeia de redirecionamentos?

Cada salto custa uma ida e volta completa até um servidor que não devolve conteúdo, mais uma consulta DNS e um handshake TLS novos sempre que o salto muda para um nome de host ao qual o navegador ainda não se conectou. Um encurtador, um shim de link e o seu próprio site são três nomes de host diferentes, então uma cadeia de três saltos costuma significar três handshakes.

Cabeçalhos também são jogados fora. A RFC 9110 manda um agente de usuário que segue um redirecionamento automaticamente remover "resource-specific header fields, including (but not limited to) Referer, Origin, Authorization, and Cookie." O agente de usuário os substitui por valores adequados à nova requisição, então é preciso uma política de referrer ou um passo de HTTPS para HTTP na cadeia para um clique cair no tráfego direto em vez de ser creditado à rede que o mandou.

Rastreadores pagam outra conta. A documentação de rastreamento do Google afirma que "any content Google receives from the redirecting URL is ignored, and the final target URL's content is processed instead", então cada salto intermediário é uma busca que não produz nada indexável e ainda consome o que o Google está disposto a rastrear no seu site.

Quantos redirecionamentos um navegador ou um rastreador segue?

Navegadores param em 20 e os rastreadores do Google param em 10. Os números vêm de duas especificações diferentes e nenhum deles é uma meta a perseguir.

O próprio conselho do Google fica bem abaixo do próprio limite. O guia de mudança de site diz para "keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5", porque "chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains."

Por que links sociais somam saltos que você nunca criou?

As plataformas inserem saltos próprios antes do seu primeiro, e na maioria das redes não dá para recusar. Essa é a parte da cadeia que você orça em vez de consertar.

O X é o caso mais direto. A central de ajuda registra que links compartilhados no X "will automatically be processed and shortened to an http://t.co link", e responde à pergunta sobre desativar sem rodeios: "You cannot opt out of link shortening." Todo post começa, portanto, em um salto antes mesmo de o seu servidor ser contatado, e o embrulho t.co sempre conta como 23 caracteres, por mais curta que fosse a URL original.

Facebook e Pinterest fazem o mesmo com outra engenharia. Conferido em 12 de setembro de 2026:

Os dois são saltos que acontecem inteiramente dentro da plataforma. O shim do Facebook nem redireciona para o seu site na primeira resposta: ele redireciona para uma segunda URL do Facebook, que aí redireciona adiante. O domínio curto do Pinterest entrega a bola para um host de API antes de o destino ser resolvido. Nenhum desses saltos é seu para encurtar, e esse é todo o argumento para não empilhar um bit.ly em cima deles.

Depois vêm os saltos que você controla: um encurtador de marca, um rastreador de cliques de automação de marketing, um redirecionador de afiliados, um salto de http para https, uma canonicalização de www e uma regra de barra final. Empilhe um encurtador e um rastreador atrás do shim de uma plataforma e você chega a cinco saltos antes de o seu CDN ver a requisição.

O que sobrevive da query string à cadeia de redirecionamentos?

O fragmento sobrevive por especificação e a query string não. A RFC 9110 é explícita: quando um valor de Location não tem fragmento próprio, "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." Não existe regra equivalente para a query, então ?utm_source=linkedin só sobrevive a um salto quando o servidor que emite o redirecionamento a escreve no Location.

Se ele faz isso ou não é detalhe de configuração de servidor, e os dois servidores web mais comuns se comportam de forma diferente o bastante para pegar gente de surpresa:

• O Redirect do mod_alias do Apache leva a query junto. A documentação diz que uma requisição para 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."
• O rewrite do nginx leva junto, a menos que você impeça. A documentação diz que "if a replacement string includes the new request arguments, the previous request arguments are appended after them", e que "putting a question mark at the end of a replacement string avoids having them appended."
• O return do nginx não entra nessa regra. A documentação descreve o acréscimo de argumentos só para o rewrite, então return 301 https://example.com/new; manda exatamente o que você escreveu e return 301 https://example.com$request_uri; manda o caminho e a query que chegaram.
• Um cabeçalho Location montado à mão no código da aplicação carrega só as partes da URL que o seu código copia para dentro dele.

Esse detalhe sozinho explica a maior parte dos relatórios de campanha quebrados. Seus parâmetros UTM estão colados na URL que você publicou, o shim da plataforma os repassa como um bloco opaco dentro do próprio parâmetro u=, e aí o seu redirecionamento de arrumação reescreve o caminho e descarta a query em silêncio. O analytics registra uma sessão sem campanha, e ninguém consegue rastrear o tráfego de redes sociais de volta até o post que o conquistou.

Parâmetros que a plataforma adiciona se comportam igual. A Meta acrescenta um identificador de clique aos destinos de anúncio, documentado como 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", no formato ?fbclid=IwAR2F4.... Uma regra de redirecionamento que derruba a query derruba o fbclid junto, e a Conversions API perde a ligação de que precisava.

Como encontrar e achatar uma cadeia de redirecionamentos?

Trace com um comando antes de discutir. curl -sIL -w '%{http_code} %{url_effective}\n' -o /dev/null <url> percorre a cadeia e imprime o que encontrou, e curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' <url> mostra um salto por vez quando você quer ver exatamente qual servidor entrega para qual.

Achatar é quase só contabilidade. Aponte cada regra de redirecionamento para a URL final em vez da regra seguinte, para que um /blog/post antigo vá direto para https://www.example.com/blog/post/ em um único 301 em vez de passar por três. Mantenha a query string no valor de Location em toda regra capaz de carregar uma. Pule o seu próprio encurtador nas redes que já embrulham links, já que um t.co apontando para um bit.ly apontando para um rastreador são três saltos que resolvem para a mesma página.

Perguntas frequentes

Uma cadeia de redirecionamentos é ruim para SEO?

Cadeias longas prejudicam o rastreamento mais do que o ranqueamento. A documentação do Google diz que seus rastreadores seguem até 10 saltos de redirecionamento por padrão e que o conteúdo das URLs que redirecionam é ignorado, então saltos além disso nunca são alcançados e os de dentro desperdiçam capacidade de rastreamento. O guia de mudança de site do Google pede no máximo três.

Quantos redirecionamentos são demais?

Mais de três é mais do que o Google recomenda. Os tetos rígidos são 20 saltos para navegadores que implementam o Fetch Standard e 10 para os rastreadores do Google, mas a recomendação na documentação de mudança de site do Google é "ideally no more than 3 and fewer than 5."

Um 301 passa mais valor do que um 302 dentro de uma cadeia?

O Google trata os dois de forma diferente como sinais de canonicalização. A documentação descreve o 301 como sinal forte de que o destino do redirecionamento deveria ser o canônico e o 302 como sinal fraco, com o 308 equivalendo ao 301 e o 307 equivalendo ao 302. O salto custa a mesma ida e volta nos dois casos.

Os parâmetros UTM sobrevivem a um redirecionamento?

Só quando o destino do redirecionamento os inclui. O HTTP exige que o agente de usuário herde o fragmento original quando o Location não tem nenhum, mas não tem regra parecida para a query string, então um redirecionamento para um caminho pelado joga fora todo parâmetro UTM da URL que chegou.

Dá para impedir que X, Facebook ou Pinterest adicionem um salto?

Não. A central de ajuda do X afirma sem rodeios que não dá para desativar o encurtamento de links t.co, e os shims do Facebook e do Pinterest são comportamento de servidor nos domínios deles. Os únicos saltos que você pode remover são os do seu lado da entrega.

Qual é a diferença entre uma cadeia de redirecionamentos e um loop de redirecionamento?

Uma cadeia termina em uma página real e um loop nunca termina. A RFC 9110 manda os clientes "detect and intervene in cyclical redirections (i.e., 'infinite' redirection loops)", que é o motivo de um loop aparecer como erro do navegador e não como página lenta.

O que conta como um salto em uma cadeia de redirecionamentos?

Um salto é uma única resposta HTTP 3xx com um cabeçalho Location, do tipo que a RFC 9110 lista como 301, 302, 303, 307 e 308. Um 301 de http://example.com/sale para https://example.com/sale é um salto, não uma cadeia. Uma cadeia só começa quando uma segunda resposta 3xx segue a primeira.

Um fragmento de URL sobrevive a uma cadeia de redirecionamentos?

O fragmento sobrevive quando o cabeçalho Location não traz um fragmento próprio. A RFC 9110 exige que o user agent herde nesse caso o fragmento da URL original. A query string não tem essa garantia, por isso o fragmento e um parâmetro UTM se comportam de forma diferente na mesma cadeia.

Por que o tráfego de uma cadeia de redirecionamentos aparece como direto na análise?

Porque o referrer pode se perder no caminho, não porque uma cadeia por si só o remova. A RFC 9110 manda o user agent remover Referer em cada salto e substituí-lo por um valor adequado à nova requisição, então o cabeçalho sobrevive a um redirecionamento a menos que outra coisa o descarte. Uma política de referrer restritiva ou um passo de HTTPS para HTTP é o que deixa a última requisição sem referrer, e a análise então registra a sessão como direta em vez de atribuí-la à plataforma que enviou o clique.

A diretiva return do nginx mantém a query string?

Não sozinha. O nginx documenta o acréscimo de parâmetros de consulta só para a diretiva rewrite, então return 301 https://example.com/new; envia exatamente o que foi escrito e descarta o que a URL do visitante trazia. Acrescentar $request_uri ao destino, como em return 301 https://example.com$request_uri;, é o que repassa o caminho e a query.