Redirecionamentos: cadeias, loops e como corrigir

Cadeia de redirecionamento é quando uma URL redireciona para outra que também redireciona: A vai para B, e B vai para C. Loop é quando a sequência volta a uma URL que já passou (A vai para B, e B volta para A) e nunca chega a uma página. A correção é a mesma nos dois casos: cada URL antiga deve apontar direto para o destino final, com redirecionamento permanente (301 ou 308) no servidor, e os links internos do site devem usar a URL final. O Googlebot segue até 10 saltos, mas o Google recomenda redirecionar direto para o destino e, quando isso não for possível, manter a cadeia curta: de preferência até 3 saltos e menos de 5 (Google, mudança de site com alteração de URLs).

Escopo: o comportamento do Google descrito aqui vem da documentação do Google Search Central consultada em outubro de 2026, e a semântica dos códigos HTTP vem da RFC 9110. Para o processo completo de rastreamento e indexação, veja o guia de rastreamento e indexação.

Os tipos de redirecionamento e como o Google trata cada um

Um redirecionamento é a resposta que manda o navegador ou o robô buscar outra URL. Os mais comuns são feitos pelo servidor, com um código 3xx e o cabeçalho Location indicando o destino.

As fontes da tabela são a RFC 9110, seção 15.4, a página do Google sobre redirecionamentos e a Pesquisa Google e a de códigos de status HTTP.

A diferença entre permanente e temporário aparece na busca. Com 301 ou 308, o Google mostra a URL de destino nos resultados. Com 302, 303 ou 307, a URL de origem pode continuar aparecendo. O Google recomenda o redirecionamento permanente no servidor quando há certeza de que ele não vai ser desfeito, e o temporário para mudanças curtas, como um serviço fora do ar por um tempo.

Dois detalhes da RFC pesam na prática. Primeiro, respostas 301 e 308 podem ficar em cache no navegador mesmo sem cabeçalho de cache explícito: um 301 errado continua valendo para quem já visitou, mesmo depois de corrigido no servidor. Por isso vale testar a regra antes de publicar e, nos testes, desligar o cache do navegador. Segundo, o 308 é de 2014 e a própria RFC avisa que nem todo cliente HTTP pode reconhecê-lo. Para páginas comuns, acessadas por GET, o 301 resolve; o 308 faz diferença quando o método da requisição precisa ser preservado.

Meta refresh, JavaScript e redirecionamento "cripto"

O meta refresh é uma tag no HTML:

<meta http-equiv="refresh" content="0; url=https://www.exemplo.com.br/novo">

Com atraso 0, o Google trata como permanente; com atraso maior, como temporário. O redirecionamento por JavaScript só é visto se o Google renderizar a página, e o Google avisa que a renderização pode falhar. A ordem de preferência na documentação é esta: redirecionamento no servidor, meta refresh, JavaScript e, por último, o que o Google chama de redirecionamento "cripto", uma página com link e explicação apontando para o endereço novo, que o Google pode ou não entender como redirecionamento.

O que cadeias e loops causam

No rastreamento

Por padrão, os rastreadores do Google seguem até 10 saltos de redirecionamento. O conteúdo das URLs intermediárias é ignorado; só o destino final é processado (Google, códigos de status HTTP). Quando a cadeia passa do limite, entra em loop, tem uma URL vazia ou inválida ou uma URL acima do tamanho máximo, o relatório Indexação de páginas do Search Console mostra "Erro de redirecionamento" para a URL (ajuda do Search Console).

Mesmo dentro do limite, cadeias custam. O guia de orçamento de rastreamento pede para evitar cadeias longas porque elas prejudicam o rastreamento. A mesma página de status HTTP diz que as ferramentas de inspeção do Google não seguem redirecionamentos, então a URL a inspecionar é a final.

Para quem visita

Cada salto é uma requisição a mais antes de a página começar a carregar. O tempo de redirecionamento entra no TTFB (tempo até o primeiro byte), que o web.dev considera bom até 0,8 segundo (web.dev, Time to First Byte). O TTFB, por sua vez, é a primeira das quatro partes do LCP, como explica o artigo sobre como melhorar o LCP. Um redirecionamento já acrescenta latência; uma cadeia acrescenta mais. O guia de migração do Google lembra ainda que nem todo navegador e agente de usuário aceita cadeias longas.

Redirecionamentos de outra origem, como encurtadores de link e plataformas de campanha, costumam estar fora do seu controle. O web.dev recomenda que a URL entregue a anunciantes e newsletters já seja a final (web.dev, otimizar o TTFB).

http, https, www e barra final: cadeias criadas por regras separadas

Variações de endereço geram cadeias sem que ninguém perceba, porque cada regra foi criada em um momento diferente. Um exemplo:

http://exemplo.com.br/produto
  301 → https://exemplo.com.br/produto
  301 → https://www.exemplo.com.br/produto
  301 → https://www.exemplo.com.br/produto/

São três saltos para chegar a uma página. Cada regra está certa sozinha; o problema é a soma. A correção tem duas partes:

1. Uma regra única que leva qualquer variação direto para a forma canônica (https, com ou sem www e com ou sem barra final, conforme o padrão do site) em um salto só.

2. Links internos, tags canônicas e sitemap escritos já na forma final, para que o navegador nem precise do redirecionamento.

O web.dev aponta o redirecionamento de http para https como uma fonte importante de tempo de redirecionamento. O cabeçalho HSTS resolve parte disso: depois de receber o cabeçalho por https, o navegador troca sozinho http por https nas visitas seguintes, sem passar pelo redirecionamento. Na primeira visita o redirecionamento ainda acontece; a lista de pré-carregamento do HSTS cobre esse caso (MDN, Strict-Transport-Security). O artigo sobre cabeçalhos HTTP de segurança trata da configuração. Por que o HTTPS vem primeiro está em segurança básica de um site.

Como mapear e corrigir depois de uma migração

Os passos abaixo seguem o guia do Google para mudança de site com alteração de URLs, com um passo a mais para cadeias herdadas de migrações anteriores.

1. Liste as URLs antigas. O Google sugere juntar sitemaps, logs do servidor, dados de analytics e o próprio CMS, incluindo imagens, vídeos, CSS e JavaScript.

2. Monte o mapa de cada URL antiga para a nova equivalente. Conteúdo que não vai para o site novo deve responder 404 ou 410.

3. Configure redirecionamentos permanentes (301 ou 308) no servidor, cada um apontando direto para o destino final.

4. Achate as cadeias herdadas. Se o site já passou por outras migrações, regras antigas podem apontar para URLs que agora também redirecionam. Troque o destino dessas regras pela URL final.

5. Atualize o que está sob seu controle: links internos, rel="canonical" (cada URL nova com canônica apontando para ela mesma), anotações hreflang e sitemap com as URLs novas. Inclua as URLs que aparecem nos dados estruturados, como os itens do BreadcrumbList. O Google lembra que redirecionamentos são lentos para quem visita, e links atualizados evitam o salto.

6. Em mudança de domínio, envie a mudança de endereço no Search Console para todas as variantes verificadas do domínio antigo, incluindo subdomínios, www e sem www, mesmo as que você não usa.

7. Teste antes e depois de publicar (próxima seção) e acompanhe o relatório Indexação de páginas, os logs e o analytics. O esperado é o tráfego cair no endereço antigo e subir no novo.

Como testar redirecionamentos

Na linha de comando, o curl mostra cada salto:

curl -sIL https://exemplo.com.br/produto

-I pede só os cabeçalhos, -L segue os redirecionamentos e -s esconde a barra de progresso. Cada bloco da saída é um salto, com o código de status e o cabeçalho location do próximo destino. Alguns servidores respondem de forma diferente a HEAD, que é o que o -I envia, e a GET. Para conferir uma lista de URLs com GET, uma por linha num arquivo:

while read -r url; do
  curl -s -o /dev/null -L --max-redirs 10 \
    -w "%{http_code} %{num_redirects} $url %{url_effective}\n" "$url"
done < urls.txt

A saída mostra o status final, o número de saltos, a URL testada e o destino. Qualquer linha com mais de um salto é uma cadeia a achatar. Num loop, o curl para no limite de --max-redirs e termina com o código de saída 47 (excesso de redirecionamentos).

No navegador, a aba Rede das ferramentas do desenvolvedor mostra a sequência quando você marca a opção de preservar o registro e desativa o cache, por causa do cache de 301 e 308. Para o site inteiro, um rastreador de SEO lista os links internos que apontam para URLs com redirecionamento; cada um pode ser trocado pela URL final. Para URLs individuais, o Google sugere a Inspeção de URL do Search Console, lembrando que ela não segue o redirecionamento: mostra que a URL redireciona, e o destino precisa ser inspecionado à parte.

Como verificar o seu site

O verificador de redirecionamentos do WebVyze, uma das ferramentas grátis, confere os saltos de uma URL sem precisar do terminal. Para o que o Google efetivamente registrou, a referência continua sendo o relatório Indexação de páginas do Search Console.