Cadeias de Redirecionamento: Como Elas Ocorrrem, Quanto Custam, Como Reduzi-las

Uma cadeia de redirecionamento é o defeito técnico raro que se esconde atrás de um sinal verde. Digite o URL, obtenha a página, status 200 — todo teste comum passa, porque todo cliente HTTP comum segue toda a cadeia silenciosamente e relata apenas onde chegou. Os saltos intermediários existem, são cobrados em cada busca, e nada em um navegador diz quantos havia.

Um registro útil de redirecionamento mostra a entrada URL, destinos intermediários e página final. Esse registro permite que a equipe responsável decida qual regra deve enviar a solicitação original diretamente ao destino pretendido. A observação também é fácil de verificar após um reparo: inspecione a sequência novamente e compare com o caminho salvo.

Uma cadeia de 4 saltos se forma a partir de 4 decisões corretas distintas

As cadeias acumulam uma camada de cada vez, e cada camada ganha seu lugar quando chega:

1. TLS chega. Alguém adiciona uma regra de borda enviando http:// para https://. O destino pretendido agora usa HTTPS.
2. Um host canônico é escolhido. A equipe padroniza em www, então o ápice redireciona para ele. O nome de host irmão deve levar ao mesmo destino pretendido.
3. Barra-final é normalizada. Um framework ou padrão CDN adiciona uma regra que acrescenta ou remove a barra final. Links publicados e entradas de sitemap devem usar o estilo pretendido de forma consistente.
4. Internacionalização é enviada. Caminhos raiz começam a rotear para um prefixo de localidade, /blog/ para /en/blog/. Páginas localizadas precisam de URLs estáveis distintas, embora um redirecionamento da raiz seja uma escolha de design do site.

Isso são 4 regras corretas, e agora http://example.com/blog alcança seu destino através de 4 redirecionamentos. Uma migração de CMS que reescreve /blog/* para /articles/* adiciona um 5º sem tocar nenhum dos primeiros 4, porque é implementado na aplicação enquanto os outros vivem na borda, no servidor web e no roteador. As regras disparam na ordem em que a solicitação atravessa a pilha, não na ordem que resolveria o URL mais rápido. Ninguém detém a composição.

Isso também explica por que o resultado http-to-https em nossos próprios dados deve ser lido com cuidado. Entre 23 de maio e 31 de agosto de 2026, a normalização de HTTP-para-HTTPS foi sinalizada em 44% de 171 avaliações, mas apenas 8% de 48 sites distintos. O 8% em nível de site é a figura de prevalência; a figura de avaliação descreve nossas observações, não a web. Uma verificação é avaliada toda vez que uma auditoria é executada, então alguns sites auditados repetidamente enquanto o defeito persistia contribuem com muitas avaliações falhas cada, e eles puxam a taxa de avaliação muito acima da parte de sites afetados. Citar o 44% como "44% de sites" superestaria a prevalência em mais de um fator de 5.

Google segue até 10 saltos e aconselha você a ficar abaixo de 5

O orçamento de salto está documentado, não é folclore. A documentação de rastreamento do Google afirma que, por padrão, seus rastreadores seguem até 10 saltos de redirecionamento, e observa que produtos individuais diferem — as Ferramentas de Inspeção do Google não seguem redirecionamentos de forma alguma. A orientação de migração de site é mais direta: o Googlebot pode seguir até 10 saltos, mas "recomendamos redirecionar diretamente para o destino final. Se isso não for possível, mantenha o número de redirecionamentos na cadeia baixo, idealmente não mais do que 3 e menos do que 5." A documentação do orçamento de rastreamento reduz isso a uma linha: evite cadeias de redirecionamento longas, que têm efeito negativo no rastreamento.

O custo se divide em 3 partes, e elas têm peso desigual:

Eficiência de rastreamento. Cada salto é uma solicitação que o rastreador do Google gasta sem receber conteúdo — a documentação é explícita de que o conteúdo retornado por um URL redirecionador é ignorado e apenas o conteúdo do alvo final é processado. Em um site com algumas centenas de URLs isso é ruído. Em um site onde a cadeia está no padrão URL cada link interno usa, ele se multiplica em todo o rastreamento e compete com o limite de capacidade de rastreamento que o mesmo host já está sujeito.

Latência, em cada busca não em cache. Um salto é uma viagem completa: DNS pode já estar quente, mas a reutilização de conexão termina no momento em que um salto muda de host, o que a etapa example.com a www.example.com faz por definição. Os usuários sentem isso uma vez e depois param de sentir, porque os navegadores armazenam em cache redirecionamentos permanentes. Máquinas que buscam frias, sem cache quente, sentem isso a cada vez.

Consolidação de sinal, onde o folclore vive. A antiga afirmação é que cada salto consome uma porcentagem de equidade de link. Google a contradisse publicamente em julho de 2016, quando Gary Illyes afirmou de forma clara que redirecionamentos 30x não perdem PageRank, esclarecendo o que John Mueller já havia dito sobre movimentos http-to-https no início daquele ano. A versão durável da preocupação é mais estreita e ainda real: um 301 é o sinal de canonização mais forte disponível, e o valor de um redirecionamento é que ele nomeia um destino de forma inequívoca. Uma cadeia ainda nomeia um destino, então o argumento de equidade é o mais fraco dos motivos 3 para achatar. Eficiência de rastreamento e latência sustentam o caso.

Buscadores e agentes de IA lidam com cadeias de forma menos permissiva que os navegadores

Navegadores são os clientes de redirecionamento mais permissivos que um site jamais será testado. Eles seguem cadeias longas sem comentário, armazenam em cache redirecionamentos permanentes agressivamente e apresentam o destino como se fosse o URL solicitado. Clientes programáticos — a camada que assistentes de IA, pipelines de recuperação e agentes realmente buscam — variam de maneiras que um teste de navegador não pode revelar.

curl não segue nada sem -L; uma cadeia retorna um 301 simples e um corpo vazio. Clientes da biblioteca HTTP cada um escolhe seu próprio limite de salto e seu próprio padrão para seguir ou não, e esses padrões são definidos por quem escreveu o código de busca, não pelo site. Clientes compatíveis com a especificação descartam credenciais quando um redirecionamento cruza origens, o que é exatamente o que um salto apex-to-www faz. A semântica do método também muda: 301 e 302 têm uma longa história de reescrever um POST em um GET, enquanto 307 e 308 preservam o método original — uma distinção que importa no momento em que um agente está enviando em vez de ler.

Adicione a restrição de orçamento. Um resumidor ou agente que trabalha em uma página sob um limite de tempo gasta parte disso em saltos que não retornam conteúdo, e uma busca que excede um limite interno de salto parece idêntica a um site que está fora do ar. A cadeia não se relata como uma cadeia; ela se relata como um resultado vazio. Isso é a mesma forma de falha que os conflitos de diretiva em nossos dados de indexabilidade — o site funciona para pessoas e recusa silenciosamente funcionar para máquinas.

Achatar em passos 4: inventário, colapso, relink, manter o mapa

1. Inventar as contagens reais de salto. Medir, não raciocinar sobre a configuração. Para um único URL:

curl -sIL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' http://example.com/blog
curl -sILD - -o /dev/null http://example.com/blog | grep -iE '^(HTTP/|location)'

A primeira linha dá a contagem, a segunda o caminho. Execute-o contra os formulários http:// e https://, apex e www, com e sem barra final, e contra um URL representativo de cada modelo — a cadeia normalmente vive em um padrão, não em uma página. Um audit faz a mesma caminhada na página inicial, o alvo canônico, e o host alternativo em uma única passagem, e relata o caminho traçado como evidência.

2. Colapso cada cadeia em um único 301. Pegue a entrada URL e o destino final do inventário e escreva uma regra que mapeie o primeiro diretamente para o último, na camada mais externa que pode ver ambos — geralmente a borda ou CDN. Em seguida retire as regras intermediárias das quais a cadeia foi composta, em vez de deixá-las no lugar atrás da nova. Use 301 para uma mudança permanente, e 308 quando o método deve sobreviver. O alvo deve ser um 200 que se declara canônico; um redirecionamento que aterrissa em uma página cujo canônico aponta para outro reinicia a ambiguidade em um vocabulário diferente, que é a interação que nossos canonical tags guide funcionam.

3. Direcione os links internos para URLs finais. Uma regra achatada ainda custa um salto em cada link interno que nomeia o antigo URL. Sitemaps, navegação, anotações hreflang, tags canônicas e links no corpo devem todos referenciar o destino diretamente, de modo que o redirecionamento exista apenas para links externos de entrada e favoritos antigos. Esta etapa é o que converte uma correção de configuração em um ganho de eficiência de rastreamento.

4. Mantenha o mapa da cadeia. Registre cada regra aposentada, sua entrada URL, e seu destino final em um arquivo que vive com a configuração da infraestrutura. As cadeias se reconstroem porque a próxima pessoa a adicionar um prefixo de localidade ou migrar um esquema de caminho não tem como ver as 4 regras já no caminho da requisição. O mapa é o que torna a composição visível para quem entrega a camada 5, e é a entrada para o próximo inventário. O tratamento completo verificação a verificação vive em nosso redirecionamentos e URL guia de normalização.

Uma camada de redirecionamento achatada é uma das poucas melhorias técnicas sem dependência de conteúdo, sem atraso de ranking, e uma etapa de verificação que leva um único comando. Ele permanece quebrado em tantos sites porque nenhum teste que alguém faça à mão relata os saltos. Uma vez que uma trilha faz parte da auditoria, a costura entre as decisões corretas das equipes 4 torna-se uma descoberta com um caminho, um status por salto, e uma regra para escrever.