logo
GeekFormat

Verificador de Cadeia de Redirecionamento

Verificação de cadeia de redirecionamentos

Verifica salto por salto 301/302/307/308, identifica loops, redirecionamentos cross-domain e problemas de downgrade HTTPS.

Quando você digita um endereço no navegador, uma série de saltos invisíveis pode ocorrer nos bastidores: HTTP→HTTPS, não-www→www, domínio antigo→domínio novo, link curto→link longo... Cada salto de redirecionamento consome tempo, afeta o ranking SEO e pode até mesmo rebaixar silenciosamente HTTPS para HTTP. O Verificador de Cadeia de Redirecionamento rastreia o caminho completo de redirecionamento da URL da perspectiva do servidor, exibindo o código de status (301/302/303/307/308), cabeçalho Location e endereço de destino de cada salto. Detecta automaticamente problemas como saltos em loop, saltos entre domínios, downgrade HTTPS e truncamento de cadeia, ajudando você a descobrir riscos ocultos de redirecionamento durante migração de domínios, implantação HTTPS e otimização SEO.

Sugestões Relacionadas

Analisador de HSTS

Verificador de Certificados SSL

Consulta de códigos de status HTTP

Verificador de HTTP Headers

Analisador de URL

Auditoria de Rede do Site

Casos de uso

  • Validação de migração de domínio: após trocar o site do domínio antigo para o novo, confira salto por salto se as URLs antigas são redirecionadas permanentemente com 301 para os novos endereços, evitando perda de tráfego causada por saltos encadeados e códigos de status incorretos
  • Verificação de implantação HTTPS: confira se a cadeia de redirecionamento HTTP→HTTPS é um salto único 301, verifique se há loop de downgrade HTTP→HTTPS→HTTP e valide se a configuração HSTS está ativa
  • Detecção de página de destino de link curto: rastreie o caminho completo de redirecionamento de links curtos (t.cn/bit.ly etc.), links de marketing UTM ou links de compartilhamento social, confira se a página final é o endereço esperado e investigue se saltos intermediários inserem parâmetros de rastreamento ou redirecionamentos maliciosos
  • Canonicalização www vs não-www: verifique se o domínio www e o domínio raiz se redirecionam corretamente com 301 para a versão canônica, evitando problemas de conteúdo duplicado causados por operação em duas vias
  • Investigação de redirecionamento em loop: quando o navegador reporta erro ERR_TOO_MANY_REDIRECTS, use a ferramenta para localizar precisamente o nó onde o loop ocorre, distinguindo se é erro de configuração Nginx/Apache, conflito de regras CDN ou causado por plugin WordPress
  • Depuração de CDN e proxy reverso: investigue conflitos de redirecionamento em arquiteturas multicamada como Cloudflare, CDN da Alibaba Cloud e proxy reverso Nginx, identifique problemas de saltos mútuos entre regras CDN e regras do servidor de origem
  • Auditoria de saúde SEO: verifique periodicamente o comprimento da cadeia de redirecionamento das páginas principais do site, avalie o impacto de saltos múltiplos na eficiência de transmissão de PageRank e otimize cadeias de redirecionamento muito longas
  • Avaliação de risco de salto entre domínios: detecte cenários de redirecionamento entre domínios como saltos de login, callbacks OAuth e saltos de pagamento, confira se Cookie e Sessão são transmitidos corretamente durante o processo entre domínios
  • Balanceamento de carga e validação multi-ativo: verifique a estratégia de redirecionamento em cenários de data centers multi-ativos e balanceamento de carga global GSLB, confira se usuários de diferentes regiões são redirecionados corretamente para o nó disponível mais próximo
  • Depuração de cache de redirecionamento: valide as configurações de cabeçalho Cache-Control e Expires para redirecionamento permanente 301 e temporário 302, investigue acessos anômalos causados por cache do navegador de regras antigas de redirecionamento

Recursos

  • Rastreamento completo salto por salto: segue cada redirecionamento da perspectiva do servidor, exibindo sequencialmente a URL original, código de status de cada salto, texto de status, cabeçalho de resposta Location e caminho completo de redirecionamento, sem omitir nenhum nó intermediário
  • Suporte a todos os códigos de status: cobre cinco códigos de status de redirecionamento padrão — 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 308 Permanent Redirect — e marca as diferenças semânticas de cada um
  • Detecção de loop de redirecionamento: identifica automaticamente padrões de salto em ciclo como A→B→A, marca a posição específica do nó onde o loop ocorre e o comprimento do ciclo, localizando com precisão a causa raiz do erro ERR_TOO_MANY_REDIRECTS
  • Identificação de salto entre domínios: detecta alterações de Host/Domínio em cada salto, marca os nós de salto entre domínios e alerta sobre risco de perda de Cookie e problemas de pré-verificação CORS
  • Alerta de downgrade HTTPS: conta o número de nós HTTP (não HTTPS) na cadeia de redirecionamento, marca saltos de downgrade HTTPS→HTTP e alerta sobre riscos de segurança e impacto negativo no SEO
  • Proteção contra truncamento de cadeia: define um limite máximo de profundidade de salto (20 saltos). Quando a cadeia é muito longa, ela é automaticamente truncada e marcada, evitando tempo limite de solicitação causado por rastreamento infinito
  • Resumo estatístico de redirecionamento: fornece visão geral de métricas chave como número total de saltos, URL final de destino, se foi detectado loop, se há salto entre domínios, número de nós HTTP e se a cadeia foi truncada
  • Avaliação de impacto SEO: avalia automaticamente o nível de impacto na transmissão de PageRank e no Core Web Vitals com base no número de saltos, tipo de código de status e cobertura HTTPS
  • URLs de teste predefinidas: inclui endereços de teste comuns como geekformat.com, github.com, httpbin.org/redirect e serviços de link curto, preenchimento com um clique para experiência rápida
  • Histórico de consultas recentes: salva automaticamente os últimos 8 registros de consulta (armazenados localmente no navegador), suporta repetição de detecção com um clique, facilitando a comparação de resultados antes e depois da correção
  • Cartão de sugestões de diagnóstico: para problemas detectados como salto em loop, salto entre domínios, downgrade HTTP e cadeia muito longa, fornece sugestões de correção específicas e orientações de melhores práticas
  • Visualização dupla: detalhes e resumo. Por padrão, exibe o cartão de resumo da cadeia; ao expandir, pode ver a URL de solicitação completa de cada salto, status da resposta, destino Location e marcação HTTPS

Como Usar

  1. Insira a URL a ser detectada na caixa de entrada (deve incluir o prefixo de protocolo http:// ou https://), ou clique no botão de URL predefinida (geekformat.com/github.com/httpbin.org/redirect etc.) para preencher rapidamente o endereço de teste
  2. Clique no botão「Rastrear Cadeia de Redirecionamento」. A ferramenta fará uma solicitação do lado do servidor e seguirá o cabeçalho de resposta Location salto por salto para registrar informações completas de cada salto
  3. Verifique o cartão de resumo de saltos no topo: número total de saltos, URL final de destino, se foi detectado loop, se há saltos entre domínios, número de nós HTTP e se a cadeia foi truncada por excesso de saltos
  4. Veja informações detalhadas de cada salto na área de visualização da cadeia: número de sequência, URL de solicitação, código de status da resposta e texto descritivo, URL de destino no cabeçalho de resposta Location, marcação de segurança HTTPS
  5. Preste atenção aos cartões de aviso de diagnóstico: se forem detectados saltos em loop (vermelho), downgrade HTTPS (laranja), saltos entre domínios (amarelo) ou cadeia muito longa (amarelo), a ferramenta destacará e marcará nas posições correspondentes e fornecerá explicações do problema
  6. Use a área de avaliação de impacto SEO para ver o nível de impacto da cadeia de redirecionamento atual na eficiência de transmissão de PageRank, velocidade de carregamento da página e Core Web Vitals, além de sugestões de otimização
  7. Após a detecção, você pode clicar em qualquer registro no histórico de consultas recentes para repetir a detecção rapidamente e comparar as mudanças na cadeia de redirecionamento antes e depois da correção; também pode fazer captura de tela dos resultados ou copiar o texto para comunicação em equipe e registro de chamados

Perguntas frequentes

Quantos saltos de cadeia de redirecionamento são considerados excessivos? Qual o impacto no SEO?

O Google recomenda oficialmente manter a cadeia de redirecionamento em um único salto, no máximo não excedendo 3 saltos. De acordo com a documentação do Google Search Central, o Googlebot geralmente segue até 5 redirecionamentos antes de parar de rastrear — mas isso não significa que 5 saltos sejam seguros. Cada salto de redirecionamento aumenta o atraso no carregamento da página (100-300ms/salto), desperdiça orçamento de rastreamento e pode causar atenuação na transmissão de PageRank. 1 salto quase não tem impacto SEO; 2 saltos são aceitáveis mas recomendam otimização; acima de 3 saltos começam a afetar o LCP e a eficiência de rastreamento; acima de 5 saltos há risco de a página não ser indexada. Use esta ferramenta para detectar as cadeias de redirecionamento de suas páginas principais, garantindo que URLs críticas (página inicial, páginas de produtos principais, páginas internas de alto tráfego) sejam alcançadas diretamente em um único salto.

O redirecionamento 301 prejudica o SEO? O PageRank é transmitido integralmente?

O redirecionamento permanente 301 usado corretamente não prejudica o SEO. Gary Illyes e John Mueller, do Google, confirmaram várias vezes que para redirecionamento 301 de migração de domínio HTTP para HTTPS, e também para migração permanente de página dentro do mesmo domínio, a transmissão de PageRank é de 100%, sem perdas. Mas é preciso observar: 1) o redirecionamento temporário 302 não transmite PageRank (ou a eficiência de transmissão é extremamente baixa); 2) se houver noindex, bloqueio por robots.txt ou erros 4xx/5xx na cadeia de redirecionamento, a transmissão de autoridade será interrompida; 3) após migração 301 entre domínios, é necessário enviar uma notificação de alteração de domínio no Google Search Console para acelerar a migração do índice; 4) o 301 é armazenado em cache de longo prazo pelo navegador; na fase de teste, recomenda-se primeiro validar com 302 antes de mudar para 301.

Por que meu site salta automaticamente para HTTP em vez de HTTPS? Como corrigir?

O salto de downgrade HTTPS→HTTP geralmente é causado por: 1) proxy reverso/CDN retorna à origem por HTTP, e o Nginx/Apache do servidor de origem obtém http em vez de https ao usar a variável $scheme para obter o protocolo; 2) código da camada de aplicativo codifica fixamente URLs com prefixo http://; 3) Home URL ou Site URL de CMS como WordPress configurado como http; 4) regras HTTP antigas residuais no .htaccess; 5) configuração SSL/TLS de serviço terceirizado (CDN/WAF) definida como modo「flexível」em vez de「rigoroso」. Etapas de correção: primeiro use esta ferramenta para determinar em qual salto ocorre o downgrade; defina o SSL da CDN para o modo「Full (strict)」; no Nginx, processe corretamente o cabeçalho X-Forwarded-Proto; no WordPress, adicione $_SERVER['HTTPS']='on'; no wp-config.php; implante o cabeçalho de resposta HSTS para evitar downgrade no nível do navegador; verifique todas as regras de redirecionamento garantindo que o destino seja https://.

Como corrigir loop de redirecionamento no Nginx (ERR_TOO_MANY_REDIRECTS)?

Mais de 90% dos loops de redirecionamento no Nginx são causados pelo processamento incorreto do cabeçalho X-Forwarded-Proto em cenários de proxy reverso/CDN. Métodos de correção: 1) garanta que a CDN/balanceador de carga envie o cabeçalho X-Forwarded-Proto para o backend: proxy_set_header X-Forwarded-Proto $scheme; 2) no Nginx, use X-Forwarded-Proto em vez de $scheme para decidir se salta para HTTPS. Recomenda usar bloco map: map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) evite escrever regras rewrite no bloco server que correspondam infinitamente a si mesmas; 4) para redirecionamento www e não-www, configure apenas salto unidirecional em um bloco server, não configure bidirecionalmente.

Como corrigir loop de redirecionamento no Apache .htaccess?

Loops no .htaccess do Apache geralmente são causados por conflito de regras RewriteRule. Etapas de correção: 1) garanta que RewriteEngine On apareça apenas uma vez; 2) coloque a regra de salto HTTP→HTTPS na frente de todas as regras, usando: RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]; 3) coloque as regras www/não-www após o salto HTTPS, e faça apenas salto unidirecional (não-www→www ou vice-versa); 4) observe que o sinalizador [L] significa「last」, mas se a regra modificar a URL, ela começará a corresponder novamente desde a primeira regra, podendo causar loop — para regras complexas, considere usar o sinalizador [END] (Apache 2.3.9+); 5) verifique se há múltiplos arquivos .htaccess (o .htaccess em subdiretórios também entra em vigor); 6) temporariamente mude R=301 para R=302 para teste, evitando interferência de cache do navegador.

Como corrigir loop de redirecionamento causado pelo Cloudflare?

A causa mais comum de loops no Cloudflare é configuração incorreta do modo de criptografia SSL/TLS ou conflito de regras de página: 1) mude o modo SSL/TLS do Cloudflare de「Flexible」para「Full」ou「Full (strict)」— no modo Flexible, o Cloudflare usa HTTP para o servidor de origem, e se o servidor de origem tiver configuração de força HTTPS, haverá loop; 2) verifique se「Always Use HTTPS」em「Edge Certificates」do Cloudflare está ativado, não configure repetidamente o salto HTTPS tanto no servidor de origem quanto no Cloudflare; 3) verifique se há regras de encaminhamento conflitantes nas Page Rules; 4) se usar o plugin Cloudflare WordPress, não configure redirecionamento HTTPS tanto no plugin quanto no Cloudflare simultaneamente; 5) verifique se as regras de Forwarding URL apontam para endereços que são novamente redirecionados pelo Cloudflare.

Qual a diferença entre redirecionamentos 301, 302, 307 e 308? Qual devo escolher?

A diferença central está em duas dimensões:「se é permanente」e「se retém o método de solicitação」. Guia rápido de escolha: para solicitações GET de páginas comuns (usuário acessando página) — use 301 para migração permanente (migração de domínio, troca HTTPS, alteração permanente de URL), use 302 para salto temporário (teste A/B, manutenção temporária, salto de login); para solicitações POST/PUT/DELETE (chamadas API, envio de formulário) — use 308 para migração permanente, use 307 para salto temporário, garantindo que o método de solicitação e o corpo da solicitação não sejam perdidos; o 303 é usado especificamente para saltar para página de resultado após envio de formulário POST (força GET, evita envio duplicado). Memória simples: 301=permanente seguro para GET, 302=temporário seguro para GET, 307=temporário todos os métodos, 308=permanente todos os métodos, 303=pular para página de resultado após POST.

O navegador armazena em cache permanentemente o redirecionamento 301? Como limpar o cache 301?

O redirecionamento permanente 301 é armazenado em cache pelo navegador por padrão, mas o tempo de cache depende das configurações de Cache-Control e Expires no cabeçalho de resposta. Se não houver cabeçalhos de cache explicitamente especificados, o comportamento de cache padrão varia entre os navegadores: o Chrome geralmente armazena redirecionamentos 301 em cache por semanas a meses (podendo permanecer em cache mesmo após reiniciar o navegador); o Firefox armazena 301 em cache por padrão mas pode revalidar após reiniciar o navegador; a estratégia de cache do Safari é relativamente conservadora. Métodos para limpar o cache 301: 1) Chrome: Configurações→Privacidade e segurança→Limpar dados de navegação→intervalo de tempo selecione「Todo o período」→marque「Imagens e arquivos em cache」→Limpar dados; 2) quando as ferramentas de desenvolvedor (F12) estiverem abertas, marque「Disable cache」no painel Network; 3) adicione um parâmetro de consulta sem sentido após a URL (?nocache=1) para contornar o cache; 4) desenvolvedores Chrome podem dar Flush sockets em chrome://net-internals/#sockets, ou limpar o cache de host em chrome://net-internals/#dns; 5) na fase de teste, use redirecionamento temporário 302 em vez de 301, e mude para 301 após confirmar que está correto.

Qual a diferença entre Meta Refresh e redirecionamento HTTP? Qual é melhor?

Meta Refresh é um redirecionamento implementado pela tag <meta> no documento HTML (como <meta http-equiv="refresh" content="0;url=https://example.com/new">), que executa o salto após o navegador analisar o HTML. Já o redirecionamento HTTP é instruído diretamente pelo servidor no nível do protocolo HTTP por meio de código de status 3xx. Comparação das diferenças: 1) velocidade: o redirecionamento HTTP começa a saltar ao receber o cabeçalho de resposta, enquanto o Meta Refresh precisa esperar o HTML ser baixado e analisado antes de saltar, sendo mais lento; 2) SEO: o Google geralmente consegue reconhecer o Meta Refresh e transmitir autoridade (se delay=0), mas oficialmente recomenda usar redirecionamento HTTP 301/302, pois o Meta Refresh é um salto do lado do cliente e o sinal não é tão claro quanto o redirecionamento do lado do servidor; 3) atraso: o Meta Refresh pode definir tempo de atraso (como content="5;url=..." significa saltar após 5 segundos), mas o redirecionamento HTTP não tem essa função; 4) acessibilidade: o W3C não recomenda usar Meta Refresh, pois tecnologias assistivas como leitores de tela têm mau processamento e também podem confundir o usuário; 5) botão voltar: o Meta Refresh pode prejudicar o comportamento do botão voltar em certos navegadores. Conclusão: sempre priorize usar redirecionamento HTTP 301/302/307/308, evite usar Meta Refresh, a menos que você não possa controlar a configuração do servidor (como hospedagem em plataforma de páginas estáticas sem possibilidade de configurar regras do lado do servidor).

O redirecionamento afeta o LCP no Core Web Vitals?

Afeta, e o impacto é muito grande. O redirecionamento ocorre antes do navegador obter o documento HTML, o que significa que cada salto de redirecionamento atrasa o início do download do documento HTML. O ponto de partida do cálculo do LCP (Largest Contentful Paint, Maior Renderização de Conteúdo) é o tempo de início da navegação, e o navegador só pode começar a analisar o DOM, carregar CSS e renderizar o elemento LCP após obter o HTML final. Assumindo que cada salto de redirecionamento adiciona 150ms de latência de rede (DNS+TCP+TLS+solicitação-resposta), 3 saltos de redirecionamento farão o LCP aumentar pelo menos 450ms — o suficiente para empurrar o LCP de「bom」(≤2,5s) para o intervalo de「precisa de melhorias」(2,5-4s). A documentação do Core Web Vitals do Google lista explicitamente「evitar múltiplos redirecionamentos」como uma das sugestões chave para otimizar o LCP. Melhor prática: garanta que as páginas principais tenham zero redirecionamento (links diretos para a URL final), e redirecionamentos necessários como HTTP→HTTPS e canonicalização www sejam controlados em um único salto.

Como verificar para onde um link curto salta finalmente?

Links curtos (t.cn, bit.ly, dwz.cn, url.cn etc.) geralmente chegam à URL final por 1-3 saltos de redirecionamento, podendo incluir parâmetros de rastreamento UTM, saltos de detecção de dispositivo, saltos geográficos etc. no meio. Usando esta ferramenta você pode: 1) inserir a URL do link curto (incluindo http:// ou https://); 2) clicar em rastrear para ver o caminho completo de cada salto; 3) ver a URL final de destino, número de saltos, tipo de código de status; 4) verificar se há downgrade HTTP ou cross-domain anormal nos saltos intermediários. Observação: alguns links curtos retornam destinos finais diferentes com base no User-Agent ou na região do IP. Esta ferramenta usa IP de servidor para solicitar, podendo ter pequenas diferenças em relação aos resultados que você vê acessando diretamente pelo navegador (especialmente para serviços de links curtos no exterior). Para links curtos url.cn do WeChat/QQ, pode ser necessário estar dentro do ambiente do WeChat para saltar corretamente para a página de destino.

Para redirecionamento forçado HTTPS, devo usar 301 ou 302? Preciso adicionar HSTS?

O redirecionamento forçado HTTPS deve usar redirecionamento permanente 301, pois a mudança de HTTP para HTTPS é permanente, não temporária. Após configurar o 301, você também deve implantar o cabeçalho de resposta HSTS. O esquema completo de força HTTPS divide-se em três fases: 1) Fase 1 (período de teste): primeiro configure o redirecionamento 301 HTTP→HTTPS, não habilite o HSTS, observe por 1-2 semanas confirmando que todos os recursos e subdomínios funcionam normalmente; 2) Fase 2 (período estável): adicione o cabeçalho de resposta Strict-Transport-Security, inicialmente defina max-age com tempo mais curto (como max-age=300, ou seja, 5 minutos), aumentando gradualmente até max-age=31536000 (1 ano); 3) Fase 3 (Preload): após confirmar que todos os subdomínios suportam HTTPS, adicione as diretivas includeSubDomains e preload, depois envie para a HSTS Preload List (hstspreload.org), fazendo com que o navegador tenha a política HSTS do seu domínio embutida, eliminando a janela HTTP do primeiro acesso. Observe que uma vez que o HSTS é armazenado em cache no navegador, não pode ser revogado pelo lado do servidor antes do vencimento do max-age, portanto teste exaustivamente.

Qual a diferença entre salto window.location do JavaScript e redirecionamento HTTP?

O salto por JavaScript (como window.location.href='https://example.com') tem diferenças essenciais em relação ao redirecionamento HTTP 3xx: 1) nível de execução: o redirecionamento HTTP é no nível do protocolo, o servidor retorna o código de status, e o navegador salta imediatamente ao receber o cabeçalho de resposta; o salto JS precisa que o HTML seja baixado e o JS seja analisado e executado antes de saltar, sendo mais lento; 2) SEO: os rastreadores de mecanismos de busca reconhecem e seguem corretamente redirecionamentos HTTP 301/302 transmitindo autoridade, mas o efeito SEO do salto JS depende de se o rastreador executa JS e do momento da execução, com sinal fraco e instável; 3) etapa intermediária: antes do salto JS, a página já começou a carregar (podendo aparecer tela branca ou piscada de parte do conteúdo), enquanto no redirecionamento HTTP o usuário chega diretamente à página de destino, com experiência mais fluida; 4) confiabilidade: o JS pode ser bloqueado pelo navegador, por plugins ou por Content Security Policy, enquanto o redirecionamento HTTP é processado pelo núcleo do navegador, com maior confiabilidade. Conclusão: quando precisar redirecionar URLs de forma permanente/temporária, sempre use redirecionamento HTTP 301/302 do lado do servidor; o salto JS serve apenas para navegação de página na lógica interativa (como salto após validação de formulário, salto por clique em botão etc.).

A cadeia de redirecionamento pode causar resultados imprecisos em testes A/B?

Sim, a cadeia de redirecionamento tem impactos múltiplos nos testes A/B: 1) se o teste A/B for implementado por redirecionamento (50% dos usuários 302 para versão A, 50% para versão B), o atraso do redirecionamento fará com que a velocidade de carregamento da página das duas versões seja diferente, e a velocidade por si só pode afetar a taxa de conversão (a versão mais rápida tem naturalmente taxa de conversão mais alta), causando desvio no teste; 2) parâmetros UTM ou marcadores de origem podem ser perdidos durante o redirecionamento, causando imprecisão nos dados de atribuição; 3) se o redirecionamento 302 durar muito tempo, o Google pode julgar por conta própria que é 301 e transmitir autoridade, afetando o SEO das páginas de teste; 4) se um dos saltos no redirecionamento múltiplo definir Cookie, pode afetar a lógica de agrupamento de usuários. Recomenda-se que testes A/B usem distribuição por renderização do lado do servidor ou distribuição por JS do cliente (como Google Optimize, Optimizely), evitando distribuição por redirecionamento. Se for obrigatório usar redirecionamento (como testar caminhos de URL completamente diferentes), use 302 (não 301) e garanta que seja um salto único direto; após o término do teste, remova o redirecionamento prontamente.

Como verificar em lote a cadeia de redirecionamento de todo o site?

Verificar em lote a cadeia de redirecionamento do site requer combinar ferramentas de rastreamento: 1) use ferramentas de rastreamento como Screaming Frog SEO Spider para rastrear todo o site e veja todas as URLs de redirecionamento e comprimento da cadeia no relatório Redirect Chains; 2) use a função de auditoria de site de ferramentas SEO como Ahrefs, Semrush ou Sitebulb — elas detectam automaticamente cadeias de redirecionamento e loops; 3) para listas de páginas principais, você pode escrever scripts para chamar a API backend desta ferramenta para detecção em lote; 4) no relatório「Indexação de páginas」do Google Search Console, veja as dicas de「erros de redirecionamento」e「cadeia de redirecionamento muito longa」; 5) use a auditoria Lighthouse do Chrome DevTools — a seção Performance marcará problemas de redirecionamento. Recomenda priorizar a verificação: página inicial, principais páginas de navegação, páginas de destino de alto tráfego, páginas recentemente migradas/reformuladas, todas as URLs HTTP após a troca HTTPS, todas as URLs sob o domínio antigo.

术语表

Redirecionamento (Redirect)
Mecanismo pelo qual o servidor instrui o cliente a acessar automaticamente outra URL, retornando um código de status 3xx e o cabeçalho de resposta Location. O redirecionamento geralmente é transparente para o usuário, e o navegador segue automaticamente os saltos.
301 Moved Permanently
Código de status de redirecionamento permanente. Indica que o recurso foi movido permanentemente para um novo local. Os mecanismos de busca transferem o PageRank da URL antiga para a nova URL, e o navegador armazena esse redirecionamento em cache por longo prazo. Recomendado para cenários de solicitação GET como migração de domínio e troca HTTPS.
302 Found
Código de status de redirecionamento temporário (anteriormente chamado Moved Temporarily). Indica que o recurso está temporariamente em outro local. Os mecanismos de busca não transferem autoridade, e o navegador não armazena em cache por longo prazo. Observação: após receber 302 em uma solicitação POST, a maioria dos navegadores converte para solicitação GET de redirecionamento, podendo perder o corpo da solicitação.
303 See Other
Código de status de ver outro local. Geralmente usado para salto para página de resultado após envio de formulário POST, exigindo explicitamente que o cliente solicite a nova URL por meio de GET para evitar envio duplicado de formulário. Respostas 303 não devem ser armazenadas em cache.
307 Temporary Redirect
Código de status de redirecionamento temporário (introduzido no HTTP/1.1). Semântica igual à do 302, mas exige estritamente a retenção do método de solicitação e do corpo da solicitação — uma solicitação POST que recebe 307 deve continuar solicitando a nova URL como POST, sem perder dados do formulário. Aplicável a saltos temporários em cenários de API e formulários.
308 Permanent Redirect
Código de status de redirecionamento permanente (definido na RFC 7538). Semântica igual à do 301, mas exige estritamente a retenção do método de solicitação e do corpo da solicitação — uma solicitação POST que recebe 308 continua redirecionando como POST. É a versão「segura em método」do 301, totalmente suportada em navegadores modernos.
Cabeçalho Location
Campo de cabeçalho de resposta HTTP usado para especificar a URL de destino em respostas de redirecionamento 3xx. Pode ser URL absoluta (recomendada) ou URL relativa. O cliente, ao recebê-lo, faz automaticamente uma nova solicitação para essa URL. Caracteres não ASCII no cabeçalho Location devem ser codificados em URL.
Cadeia de Redirecionamento (Redirect Chain)
Série de redirecionamentos consecutivos entre a URL inicial e a URL final de destino. Por exemplo, A→B→C→D forma uma cadeia de redirecionamento de 3 saltos. Cadeias de redirecionamento muito longas atrasam a velocidade de carregamento e dissipam a autoridade SEO. Recomenda-se manter em um único salto, no máximo não excedendo 3 saltos.
Loop de Redirecionamento (Redirect Loop)
Ocorre quando uma URL na cadeia de redirecionamento aparece repetidamente, formando um ciclo infinito de saltos (como A→B→A). O navegador exibe o erro ERR_TOO_MANY_REDIRECTS após atingir o número máximo de saltos (geralmente 20 vezes). Causas comuns incluem saltos mútuos HTTP↔HTTPS, saltos mútuos www↔não-www e perda de protocolo de proxy reverso.
Migração de Domínio (Domain Migration)
Processo pelo qual um site troca permanentemente de um domínio para outro, como troca de domínio por marca ou aquisição e fusão de empresas. Durante a migração, todas as URLs do domínio antigo precisam ser redirecionadas permanentemente com 301 para as páginas correspondentes do novo domínio, e uma notificação de alteração de domínio precisa ser enviada no Google Search Console.
Canonicalização de URL (URL Canonicalization)
Processo de unificar múltiplas variantes de URL de um mesmo conteúdo (www/não-www, com/sem barra final, HTTP/HTTPS, diferenças de maiúsculas/minúsculas) em uma URL canônica única, geralmente implementado por meio de redirecionamento 301. A canonicalização evita problemas de conteúdo duplicado e concentra a autoridade SEO.
Redirecionamento Forçado HTTPS
Configuração que redireciona todas as solicitações HTTP (porta 80) para HTTPS (porta 443) por meio de 301. É uma etapa necessária após a implantação de certificado SSL/TLS. Geralmente usado em conjunto com o cabeçalho de resposta HSTS para eliminar a janela de texto claro HTTP no primeiro acesso.
HSTS
HTTP Strict Transport Security (Segurança de Transporte Rigorosa). Por meio do cabeçalho de resposta Strict-Transport-Security, diz ao navegador que só pode acessar esse domínio por HTTPS dentro do tempo especificado. O navegador atualiza automaticamente internamente HTTP para HTTPS, sem precisar de redirecionamento do servidor. Defende efetivamente contra ataques de desvio SSL.
Link Curto (Short URL)
Serviço que converte URLs longas em URLs curtas (como bit.ly, t.cn). Ao acessar, salta para a URL original por meio de redirecionamento 301/302. Atrás de links curtos, frequentemente se escondem cadeias de redirecionamento de múltiplos saltos, podendo conter parâmetros de rastreamento ou saltar para destinos diferentes sob condições específicas.
PageRank
Algoritmo de ranking de páginas inventado pelos fundadores do Google, Larry Page e Sergey Brin, que avalia a autoridade da página por meio de relações de links. O redirecionamento permanente 301 transmite o PageRank da URL antiga para a nova URL, enquanto o redirecionamento temporário 302 geralmente não transmite ou transmite muito pouco.
Core Web Vitals
Principais indicadores de experiência de página definidos pelo Google, incluindo LCP (Maior Renderização de Conteúdo, mede desempenho de carregamento, padrão bom ≤2,5s), FID/INP (capacidade de resposta interativa, padrão bom ≤100ms/200ms) e CLS (estabilidade visual, padrão bom ≤0,1). Cadeias de redirecionamento atrasam o download do HTML e deterioram diretamente o indicador LCP.
Redirecionamento Entre Domínios (Cross-origin Redirect)
Ocorre quando a URL de destino do redirecionamento tem domínio diferente da URL original (incluindo domínios completamente diferentes ou subdomínios diferentes). O redirecionamento entre domínios é restrito pela política de mesma origem, podendo causar problemas como não envio de Cookie, bloqueio de Cookie de terceiro e falha de pré-verificação CORS.
Truncamento de Cadeia (Chain Truncation)
Quando o número de saltos da cadeia de redirecionamento excede o limite máximo de profundidade definido pela ferramenta ou navegador (esta ferramenta é 20 saltos, Chrome é 20 saltos), o rastreador para de seguir redirecionamentos subsequentes e marca a cadeia como truncada. O truncamento de cadeia geralmente sugere existência de loop infinito ou configuração de redirecionamento anormalmente complexa.

Tabela completa de comparação de códigos de status de redirecionamento HTTP

301Moved PermanentlySim (permanente)Pode alterar (POST→GET)Migração de domínio, troca HTTPS, canonicalização www/não-www, alteração permanente de URL
302FoundNão (temporário)Pode alterar (POST→GET)Página de manutenção temporária, salto de login, teste A/B, página de campanha de curto prazo
303See OtherNão (temporário)Sim (força GET)Salto para página de resultado após envio de formulário POST, evita envio duplicado
307Temporary RedirectNão (temporário)Não (mantém estritamente o método original)Redirecionamento temporário de API, saltos temporários que precisam reter dados POST
308Permanent RedirectSim (permanente)Não (mantém estritamente o método original)Migração permanente de API RESTful, redirecionamento permanente que precisa reter métodos PUT/DELETE

Tabela de comparação de impacto da cadeia de redirecionamento no SEO

0 saltos (acesso direto)Sem impacto, estado idealSem atraso adicionalMantenha o status atual, links internos apontam diretamente para a URL final
1 saltoTransmissão normal de PageRank, impacto SEO desprezívelAdiciona cerca de 100-300ms de atraso (uma ida e volta)Aceitável, número comum de saltos para HTTP→HTTPS e canonicalização de domínio
2 saltosPode haver leve atenuação na transmissão de autoridade, rastreador segue normalmenteAdiciona cerca de 200-600ms de atrasoRecomenda otimizar para um único salto, verifique se links internos apontam para URLs de redirecionamento intermediário
3 saltosEficiência de transmissão de autoridade diminui, alguns rastreadores podem desistir de seguirAdiciona cerca de 300-900ms de atraso, LCP pode ser afetadoDeve ser otimizado, mescle regras de redirecionamento diretamente para a URL final
4-5 saltosAtenuação óbvia de PageRank, indexação pode ser afetada, desperdício de orçamento de rastreamentoAdiciona 500ms-1,5s de atraso, LCP provavelmente excede o padrãoCorreção urgente, verifique sobreposição de redirecionamentos multicamada CDN/servidor de origem/aplicativo
6 saltos ou maisRisco grave, mecanismos de busca podem parar de seguir e causar desindexação da páginaAtraso superior a 1 segundo, experiência do usuário muito ruimInvestigue imediatamente loops ou erros de configuração, reestruture as regras de redirecionamento
Loop (ERR_TOO_MANY_REDIRECTS)Página completamente inacessível, mecanismos de busca a removem do índicePágina não carrega, navegador exibe erroCorreção de maior prioridade, use esta ferramenta para localizar os nós do loop

Erros comuns de configuração de redirecionamento e soluções de correção

Erro de loop ERR_TOO_MANY_REDIRECTS, saltos repetidos HTTP↔HTTPSCDN/balanceador de carga retorna à origem por HTTP, servidor de origem não processa corretamente o cabeçalho X-Forwarded-Proto e sempre redireciona para HTTPSAdicione na configuração Nginx: set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } ou use a variável $scheme em conjunto com a configuração proxy_set_header X-Forwarded-Proto
www e não-www saltam entre si formando loopCamada CDN configura salto www→não-www, Nginx do servidor de origem configura salto não-www→www, regras conflitamEscolha uma versão canônica (recomendado não-www ou www, mantenha consistente), configure o redirecionamento em apenas uma camada (CDN ou servidor de origem), exclua as regras correspondentes das outras camadas
Cadeia de redirecionamento passa por 4-5 saltos antes de chegar à página finalSalto HTTP→HTTPS → salto não-www→www → salto de adição de barra final → salto de caminho antigo para caminho novo, sobreposição de regras multicamadaMescle as regras de redirecionamento, salte diretamente da URL inicial para a URL final em um passo. No Nginx, use a diretiva return para saltar de uma vez para o endereço final completo
Nós HTTP aparecem na cadeia de redirecionamento de site HTTPS (downgrade)Configuração do servidor codificou fixamente o destino de redirecionamento com prefixo http://, ou o aplicativo não reconhece que está em HTTPS ao gerar a URL de redirecionamentoConfigure o aplicativo para confiar no proxy reverso e ler corretamente o X-Forwarded-Proto; no Nginx, use URL absoluta https:// ou variável $scheme (desde que o proxy tenha configurado corretamente o scheme); implante HSTS
Após modificar o redirecionamento 301, o navegador ainda salta para o endereço antigoNavegador armazena em cache de longo prazo as regras de redirecionamento permanente 301, atualização F5 não funcionaNa fase de teste, use redirecionamento temporário 302 para confirmar antes de mudar para 301; limpe o cache do navegador (Chrome: Configurações→Privacidade→Limpar dados de navegação→imagens e arquivos em cache); use a opção Disable cache do DevTools
Dados do formulário são perdidos após redirecionamento de solicitação POSTUsou redirecionamento 301 ou 302, navegador converte automaticamente POST em GET de redirecionamento, corpo da solicitação é descartadoPara solicitações não-GET como POST/PUT/DELETE, mude para redirecionamento 307 (temporário) ou 308 (permanente), retendo estritamente o método de solicitação e o corpo da solicitação
Caracteres de codificação dupla como %2520 aparecem na URL após redirecionamentoParâmetros de URL já passaram por uma codificação URL, e o servidor fez uma segunda codificação ao redirecionarVerifique a lógica de redirecionamento, garanta que a URL seja codificada apenas uma vez; no Nginx, use $request_uri (URI original, não decodificada) em vez de $uri (já decodificada)
Solicitação AJAX/fetch reporta erro CORS após redirecionamento entre domíniosServidor de destino do redirecionamento entre domínios não configurou cabeçalhos de resposta CORS (Access-Control-Allow-Origin etc.)Garanta que os servidores de cada salto na cadeia de redirecionamento tenham cabeçalhos CORS configurados corretamente; ou evite usar redirecionamento entre domínios em solicitações AJAX, mude para o frontend obter a URL de destino e solicitar diretamente

Troubleshooting