O link em que você clica muitas vezes não é a página que você recebe. No meio do caminho pode haver uma mudança para HTTPS, uma troca de host, um serviço de rastreamento de cliques, um encurtador de links e uma regra do CMS que acrescenta a barra final, e cada um deles é uma requisição separada que o navegador faz sem avisar você.

Este guia mostra como enxergar essas etapas com o TrueURL, o curl e o DevTools do navegador, o que significa cada parte de uma cadeia de redirecionamentos e como corrigir os problemas mais comuns.

O que é uma cadeia de redirecionamentos

Um redirecionamento acontece quando o servidor responde com um código de status 3xx e um cabeçalho Location que aponta para outra URL. O cliente, seja um navegador ou um rastreador, faz então a requisição dessa URL e repete o processo até receber uma resposta que não seja um redirecionamento.

Cada requisição e sua resposta formam um salto. A sequência completa, da primeira URL até a resposta final, é a cadeia de redirecionamentos:

#  URL                              Status  Location
1  http://example.com/Shoes         301     https://example.com/Shoes
2  https://example.com/Shoes        301     https://www.example.com/Shoes
3  https://www.example.com/Shoes    302     /shoes/
4  https://www.example.com/shoes/   200

São três redirecionamentos e quatro requisições para chegar a uma única página. O Location do salto 3 é relativo: os clientes o resolvem em relação à URL que acabaram de requisitar, como especifica a RFC 9110, então ele equivale a https://www.example.com/shoes/. O ideal seria que cada um desses endereços chegasse à URL final em um único salto.

Uma página também pode redirecionar depois de responder 200 OK, com uma tag <meta http-equiv="refresh"> ou com JavaScript. Esses redirecionamentos do lado do cliente também fazem parte da cadeia, mas ferramentas que só leem os cabeçalhos HTTP, como o curl, param nessa página.

Por que verificar redirecionamentos é importante

SEO: sinais de URL canônica e crawl budget

Os mecanismos de busca interpretam um redirecionamento como uma indicação de qual URL indexar. O Google trata redirecionamentos permanentes (301 e 308) como um sinal forte de que o destino deve ser a URL canônica, e os temporários (302, 303 e 307) como um sinal fraco. Por isso, uma página que mudou de endereço de vez, mas está atrás de um 302, pode continuar aparecendo nos resultados de busca com a URL antiga.

O comprimento da cadeia também conta. O Googlebot segue até 10 saltos de redirecionamento; se até lá não tiver recebido conteúdo, o Search Console informa um erro de redirecionamento. O guia do Google sobre crawl budget (orçamento de rastreamento) também recomenda evitar cadeias de redirecionamentos longas, que, segundo o próprio Google, têm efeito negativo no rastreamento.

Velocidade da página

A página final só começa a carregar depois que o último redirecionamento é respondido. Cada salto custa uma ida e volta na rede, e um salto para outro host ainda exige uma consulta DNS, uma nova conexão e, no caso de HTTPS, um handshake TLS. Em conexões móveis, três ou quatro redirecionamentos podem somar várias centenas de milissegundos antes do primeiro byte da página de verdade. O Teste de latência de redirecionamento mostra quanto custa cada salto.

Links encurtados e muitos links de rastreamento em e-mails escondem o destino. Campanhas de phishing também exploram redirecionamentos abertos (open redirects) em domínios conhecidos, de modo que um link que começa em um site confiável pode terminar em um lugar completamente diferente. O Desencurtador de links revela cada domínio do caminho, e se algum salto cai de HTTPS para HTTP simples, antes de você clicar.

Links de marketing costumam passar por vários serviços antes da landing page, e cada um precisa repassar a query string; caso contrário, parâmetros UTM, IDs de clique e tags de afiliado se perdem sem nenhum aviso. A URL final mostra se eles sobreviveram e se o link ainda chega à página pretendida.

Migrações, HTTPS e o host canônico

Depois de uma reformulação do site, de uma troca de domínio ou da migração para HTTPS, cada URL antiga deve chegar à nova equivalente com um único redirecionamento permanente. As quatro variantes básicas de um site (http:// e https://, com e sem www) devem levar todas a um único endereço canônico. Essas regras quebram em silêncio: uma nova regra na CDN, a atualização de um plugin ou a troca de servidor podem acrescentar um salto ou um loop sem que ninguém perceba.

Como verificar um redirecionamento com o TrueURL

O TrueURL faz todas as verificações na rede de borda (edge) da Cloudflare, então você pode inspecionar links em que não confia sem abri-los no navegador. O Verificador de redirecionamento de URL da página inicial verifica uma URL por vez; o Verificador de cadeia de redirecionamentos e as outras ferramentas especializadas usam o mesmo motor de verificação.

Passo 1: informe a URL

Cole a URL e inicie a verificação. Se você não informar o protocolo, o verificador usa https://; digite http:// para testar HTTP simples.

Passo 2: ajuste as Configurações avançadas, se necessário

Por padrão, o verificador envia uma requisição GET com o User-Agent de uma versão atual do Chrome para desktop, sem cookies e com limite de 20 redirecionamentos. Em Configurações avançadas, você pode mudar isso:

  • Método HTTP: GET, HEAD ou POST. HEAD é mais leve, mas alguns servidores respondem a ele de outro jeito e, sem corpo, não dá para detectar redirecionamentos do lado do cliente. POST envia o corpo da requisição que você informar, para formulários e APIs. Os saltos seguintes obedecem às regras dos navegadores: depois de um POST, um 301 ou 302 continua como GET, um 303 continua como GET em qualquer caso, e 307 e 308 mantêm o método e o corpo.
  • Máximo de saltos: o número de redirecionamentos a seguir, de 1 a 50. O padrão de 20 é o limite definido no Fetch Standard e usado pelo Chrome e pelo Firefox. Defina 10 para ver se uma cadeia cabe no limite do Googlebot.
  • User-Agent personalizado: vazio significa Chrome para desktop. As opções predefinidas incluem Safari no iPhone, Chrome no Android, Googlebot (smartphone e desktop), Bingbot, os robôs de pré-visualização de links do Facebook e do X, e curl.
  • Cabeçalhos de requisição personalizados: cabeçalhos extras enviados em cada salto, por exemplo Accept-Language: fr-FR para acionar um redirecionamento por idioma.
  • Cookies: informe name=value; other=value para reproduzir um estado de login, de consentimento ou de região. Os cookies definidos ao longo da cadeia são mantidos nos saltos seguintes, como em um navegador.
  • Redirecionamentos do lado do cliente: escolha se o verificador segue tags meta refresh e redirecionamentos JavaScript simples ou apenas os informa no resultado.
  • Ignorar erros de SSL: a rede de borda da Cloudflare sempre valida os certificados, então esta opção não consegue pular um certificado com problema. Um erro de TLS é informado no salto em que aconteceu.

Passo 3: leia o resultado

O resultado começa pela URL final e pelo código de status dela. Logo abaixo, a cadeia tem uma linha por salto, com:

  • a URL requisitada e o método HTTP usado;
  • o código de status e a frase de motivo, ou reason phrase (a referência de códigos de status explica cada um);
  • o tempo de resposta, do envio da requisição até a chegada dos cabeçalhos, incluindo a consulta DNS e a abertura da conexão, quando houver;
  • o Location para o qual o salto aponta;
  • os cabeçalhos de resposta e os nomes dos cookies que o salto definiu.

Cada redirecionamento traz um rótulo que indica como ele aconteceu: código de status HTTP, meta refresh (com o atraso em segundos) ou JavaScript. Redirecionamentos do lado do cliente encontrados, mas não seguidos, também são informados. Tão importante quanto isso é saber como a verificação terminou:

Desfecho O que significa
Resposta final A cadeia chegou a uma resposta que não é um redirecionamento, como 200 OK ou 404 Not Found.
Loop de redirecionamento A próxima requisição repetiria uma anterior: mesma URL, mesmo método e mesmos cookies. O resultado mostra qual salto fecha o loop.
Limite de saltos atingido A cadeia ainda estava redirecionando quando chegou ao limite. O próximo destino é exibido, mas não é requisitado.
Erro Um salto falhou (DNS, conexão, TLS ou tempo esgotado) ou o destino do redirecionamento não era uma URL válida ou permitida.

Os avisos apontam um redirecionamento temporário na cadeia, um rebaixamento de HTTPS para HTTP, mais de três redirecionamentos, uma URL final em outro domínio, redirecionamentos do lado do cliente e requisições HEAD que não conseguiram ler o corpo da página.

Um dos avisos exige atenção. Alguns sites mostram ao tráfego automatizado ou vindo de data centers uma verificação antibot (página de desafio), como a página “Just a moment...” da Cloudflare. O TrueURL marca as respostas que parecem ser uma dessas páginas, porque nesse caso a verificação chegou à camada de proteção do site, e não ao destino. Um visitante real pode acabar em outro lugar.

Como verificar redirecionamentos pela linha de comando

O curl já vem instalado no macOS, no Windows 10 e 11 e na maioria das distribuições Linux, e mostra exatamente o que o servidor envia, sem nenhum cache de navegador no meio. Os exemplos usam um shell Unix; no Windows PowerShell 5.1, digite curl.exe, porque ali curl é um alias de Invoke-WebRequest, e use NUL no lugar de /dev/null.

Veja um único salto

Bash
curl -I https://example.com/old-page

-I envia uma requisição HEAD e imprime os cabeçalhos de resposta, incluindo a linha de status e o Location, se houver. O curl não segue redirecionamentos, a menos que você peça. Como alguns servidores tratam HEAD de forma diferente, repita a verificação com GET quando o resultado parecer estranho; -o /dev/null descarta o corpo e -D - imprime os cabeçalhos:

Bash
curl -sS -o /dev/null -D - https://example.com/old-page

Siga a cadeia inteira

-L segue os redirecionamentos e, com -I ou -D -, o curl imprime os cabeçalhos de cada salto. Um filtro com grep deixa a saída compacta:

Bash
curl -sIL http://example.com/Shoes | grep -iE '^(HTTP/|location:)'
HTTP/1.1 301 Moved Permanently
Location: https://example.com/Shoes
HTTP/2 301
location: https://www.example.com/Shoes
HTTP/2 302
location: /shoes/
HTTP/2 200

Por padrão, o curl segue até 50 redirecionamentos; --max-redirs 10 aplica o limite do Googlebot.

Mostre só a URL final

A opção -w (write-out) imprime detalhes depois da transferência e transforma o curl em um expansor de URL compacto:

Bash
curl -sSL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/go

%{url_effective} é a última URL buscada; %{num_redirects}, o número de redirecionamentos seguidos; e %{http_code}, o status final. %{time_redirect} informa os segundos gastos com redirecionamentos antes da requisição final. Sem -L, %{redirect_url} mostra para onde o primeiro redirecionamento levaria.

Teste requisições POST

-d envia um corpo e transforma a requisição em POST. Ao seguir redirecionamentos, o curl age então como um navegador: muda para GET depois de um 301, 302 ou 303 e reenvia o POST com o corpo depois de um 307 ou 308.

Bash
curl -sSL -o /dev/null -D - -d 'email=test%40example.com' https://example.com/subscribe

Evite combinar -X POST com -L. -X força o método em todas as requisições, então o curl continua enviando POST depois de um 301, 302 ou 303, quando um navegador mudaria para GET, e você acaba testando uma cadeia que nenhum cliente real produz.

Altere o User-Agent, os cabeçalhos e os cookies

Bash
# User-Agent de smartphone
curl -sIL -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1' https://example.com/

# Cabeçalho de requisição extra
curl -sIL -H 'Accept-Language: de-DE,de;q=0.9' https://example.com/

# Envia um cookie e guarda os cookies definidos ao longo da cadeia
curl -sSL -o /dev/null -D - -b 'consent=yes' -c cookies.txt https://example.com/

-A define o User-Agent, -H acrescenta um cabeçalho e -b envia cookies. -c salva os cookies recebidos em um arquivo e ativa o mecanismo de cookies do curl, de modo que um cookie definido em um salto é enviado no seguinte.

O curl não executa JavaScript nem obedece a tags meta refresh. Se a última resposta dele for uma página HTML 200 OK, mas o seu navegador terminar em outro lugar, o redirecionamento acontece do lado do cliente.

Como verificar redirecionamentos no DevTools do navegador

O DevTools mostra a cadeia como o seu próprio navegador a vê, com seus cookies, extensões e localização:

  1. Abra o DevTools (F12, ou Cmd+Option+I no Mac) e selecione a guia Network (Rede).
  2. Ative Preserve log no Chrome e no Edge, ou Persist Logs no menu de configurações de rede do Firefox. Sem isso, a lista é apagada a cada carregamento de página, e os redirecionamentos do lado do cliente somem de vista.
  3. Ative Disable cache, para que um redirecionamento guardado em cache não esconda o que o servidor envia hoje.
  4. Digite a URL na barra de endereços.

Cada salto aparece em uma linha própria, com seu status 3xx; selecione a linha e abra Headers para ver o cabeçalho de resposta location. No Chrome, “(disk cache)” ou “(memory cache)” na coluna Size significa que o redirecionamento veio do cache, e não do servidor.

Às vezes o Chrome lista um 307 Internal Redirect de http:// para https://. O servidor nunca o enviou: foi o próprio navegador que mudou a requisição para HTTPS, normalmente porque tem uma política HSTS armazenada para o site. Para ver o que o servidor faz com HTTP simples, use o curl ou o TrueURL.

Problemas comuns de redirecionamento e como corrigi-los

Cadeias com mais de um salto

As cadeias crescem em camadas: uma regra de uma migração antiga aponta para uma URL que uma migração posterior redirecionou de novo. Aponte cada regra direto para o destino final e atualize links internos, tags canonical, anotações hreflang e sitemaps, para que o seu próprio site nunca dispare um redirecionamento. O Verificador de redirecionamento em massa mostra quais URLs antigas ainda precisam de mais de um salto.

Loops de redirecionamento

O Chrome informa um loop com a mensagem “redirecionou você muitas vezes” (ERR_TOO_MANY_REDIRECTS); o Firefox diz “A página não está redirecionando corretamente”. Causas comuns:

  • HTTPS atrás de um proxy ou CDN. O servidor de origem redireciona HTTP para HTTPS, mas o proxy se conecta a ele por HTTP simples, então a origem nunca vê HTTPS e redireciona sem parar. Na Cloudflare, esse é o resultado clássico do modo SSL/TLS Flexible; use Full (strict) ou faça a origem verificar X-Forwarded-Proto.
  • Duas camadas em conflito, como uma regra da CDN que remove o www enquanto o servidor o acrescenta, ou um framework que adiciona a barra final que a CDN tira.
  • Redirecionamentos que dependem de cookies. Uma página de login ou de consentimento manda o visitante de volta à URL original, que o redireciona de novo para o login porque o cookie não foi armazenado.

O Detector de loop de redirecionamento mostra qual salto fecha o loop. Depois, deixe uma única camada responsável por cada regra.

301 e 302 misturados na mesma cadeia

Uma cadeia com 301, depois 302 e depois 200 é uma mudança permanente com uma etapa temporária no meio. Muitas vezes isso vem de um valor padrão: res.redirect() do Express e header('Location: ...') do PHP enviam 302, a menos que você indique outro código. Use um código permanente em todos os saltos e confirme com o Verificador de redirecionamento 301. Nosso guia sobre códigos de status HTTP de redirecionamento explica quando usar cada código.

Salto duplo de HTTP para HTTPS e depois para www

Uma cadeia muito comum é http://example.com → https://example.com → https://www.example.com: dois saltos onde um bastaria. Redirecione cada variante não canônica direto para a URL HTTPS final e depois teste as quatro com o Verificador de redirecionamento HTTPS.

Existe uma exceção intencional. Se o seu host canônico é o www e você inclui o domínio na lista de HSTS preload, o hstspreload.org exige que http://example.com redirecione primeiro para https://example.com, para que os navegadores registrem a política HSTS do domínio raiz.

Inconsistências na barra final (trailing slash)

/pricing e /pricing/ são URLs diferentes. Se as duas retornam 200 OK, você tem conteúdo duplicado; se duas camadas redirecionam uma para a outra, você tem um loop. Escolha uma forma, redirecione a outra para ela com um único 301 e use sempre a mesma forma nos links. O Verificador de barra final testa as duas formas de uma vez.

Redirecionamentos só no mobile

Sites mobile separados, convites para instalar o app e detecção de dispositivo às vezes mandam os celulares para outro lugar, muitas vezes para a página inicial da versão mobile em vez da página equivalente. Com a indexação mobile-first, o Google rastreia principalmente com o rastreador para smartphones, então a cadeia mobile é a que mais pesa na indexação. Compare as duas com a ferramenta Redirecionamento mobile vs. desktop.

Redirecionamentos em sitemaps

Um sitemap deve listar as URLs canônicas que você quer nos resultados de busca, e essas URLs retornam 200 OK. Entradas que redirecionam desperdiçam requisições de rastreamento e enviam sinais de canonicalização contraditórios. Rode o Verificador de redirecionamentos do sitemap depois de cada migração e substitua cada entrada que redireciona pela URL final.

Redirecionamentos JavaScript e meta refresh

O Google trata um meta refresh instantâneo como redirecionamento permanente e um meta refresh com atraso como temporário. Redirecionamentos JavaScript ele só enxerga depois de renderizar a página, uma etapa que vem depois do rastreamento e pode falhar. Muitos outros rastreadores, robôs de pré-visualização de links e ferramentas de linha de comando nem executam JavaScript, e alguns também ignoram o meta refresh. Use redirecionamentos do lado do servidor sempre que controlar o servidor e encontre os do lado do cliente com o Verificador de meta refresh.

Checklist de redirecionamentos

Repasse esta lista depois de uma migração, de uma mudança na CDN ou antes de lançar uma campanha:

  1. Cada URL antiga chega ao destino final em um único salto.
  2. Mudanças permanentes usam 301 ou 308 em todos os saltos.
  3. As quatro variantes de protocolo e host terminam na URL HTTPS canônica.
  4. Nenhum salto passa de HTTPS para HTTP.
  5. As query strings, incluindo parâmetros UTM e IDs de afiliado, sobrevivem à cadeia.
  6. Cada URL tem uma única forma de barra final, e a outra forma redireciona para ela.
  7. Requisições de desktop, de smartphone e do Googlebot terminam em páginas equivalentes.
  8. Redirecionamentos do lado do servidor substituem meta refresh e JavaScript sempre que possível.
  9. Links internos, tags canonical, hreflang e sitemaps apontam para as URLs finais.
  10. Páginas removidas sem substituta retornam 404 ou 410 em vez de redirecionar para a página inicial.
  11. Os redirecionamentos de uma mudança de site continuam ativos; o Google recomenda mantê-los por pelo menos um ano.