🔀

Verificador de redirecionamentos: para onde vai qualquer URL ou link

Um verificador de redirecionamentos segue uma URL de salto em salto e informa o status HTTP de cada salto até o fim da cadeia. Digite http://github.com e ele registra dois saltos: o salto 1 responde 301 Moved Permanently e aponta para https://github.com/, que responde 200 OK. É um único redirecionamento, o que é saudável; cada redirecionamento a mais acrescenta outra viagem de ida e volta. Este verificador segue respostas 301, 302, 303, 307 e 308, além de tags meta refresh no HTML, sinaliza loops e cadeias longas e pode enviar a requisição como Googlebot ou como um celular.

Uma URL por linha, até 10. Cada URL é rastreada separadamente e depois todo o lote pode ser exportado.

Incorporar esta ferramenta no seu site

× px

                        

💡 Dica de integração

Copie o código de incorporação e cole no HTML do seu site. A versão responsiva se adapta automaticamente a todos os tamanhos de tela.

2 avaliações
✓

Ferramentas populares

Não há mais ferramentas
Explorar todas as ferramentas

O que significam 301, 302, 303, 307 e 308?

Todos os cinco são respostas 3xx definidas na seção 15.4 da RFC 9110. Eles diferem em duas coisas que importam para um navegador: se o método da requisição sobrevive ao redirecionamento e se a resposta pode ser armazenada em cache e reutilizada. A coluna de SEO mostra como a Pesquisa Google trata o sinal.

Comparação dos códigos de status de redirecionamento HTTP: método, cache e tratamento pelos mecanismos de busca.
Código Nome Método após o redirecionamento Cacheável por padrão Sinal para buscadores Quando usar
301 Moved Permanently POST pode ser trocado por GET Sim Sinal canônico forte; a nova URL substitui a antiga Mudanças permanentes, HTTP para HTTPS, sem www para www
302 Found (temporário) POST pode ser trocado por GET Não, a menos que os cabeçalhos indiquem A URL antiga costuma continuar indexada Testes A/B, páginas de manutenção, divisão por região
303 See Other Sempre muda para GET Não Tratado como temporário Post/Redirect/Get após o envio de um formulário
307 Temporary Redirect Preservado, inclusive o corpo Não Tratado como temporário Mudanças temporárias de APIs e endpoints de formulário que precisam manter o método e o corpo
308 Permanent Redirect Preservado, inclusive o corpo Sim Mesmo peso de um 301 Mudanças permanentes que precisam manter POST, PUT e DELETE

Dois códigos costumam ser confundidos com redirecionamentos, mas não são: o 304 Not Modified é uma resposta de validação de cache, sem cabeçalho Location, e o 300 Multiple Choices oferece uma lista de opções em vez de um único destino. A tag meta refresh também não é um redirecionamento HTTP, mas os navegadores a seguem, então o verificador a mostra como um salto próprio, marcado como meta refresh; já uma mudança de location feita em JavaScript nunca aparece, porque nada na página é executado. Também não aparece o “307 Internal Redirect” que o Chrome exibe quando o HSTS troca http:// por https://: o navegador inventa essa linha antes que qualquer requisição saia da máquina, então nenhum servidor pode enviá-la e um rastreamento feito no servidor nunca a vê.

Como verificar se um redirecionamento está funcionando?

Digite o endereço antigo, não o novo, e comece pelo protocolo exato que os visitantes usam: na maioria dos servidores, http:// e https:// são regras separadas. Um redirecionamento que funciona devolve um 3xx com cabeçalho Location no salto 1 e um 200 no último salto, com o caminho e a query string intactos. Se o último salto for 404, 403 ou 405, a regra foi acionada, mas aponta para algo inútil; e se o salto 1 já retornar 200, o redirecionamento nem chegou a ser acionado.

  • O salto 1 retorna 301, 302, 307 ou 308, e não 200.
  • O último salto retorna 200, e não 404, 403 ou 500.
  • A URL final é o destino exato, com o caminho, a barra final e qualquer query string que você enviou.
  • A cadeia contém um único redirecionamento: o salto 1 responde 3xx e o salto 2 responde 200. Mais redirecionamentos do que isso indicam regras se acumulando.

Para ler todos os cabeçalhos que um salto devolve, como Location, Cache-Control e Strict-Transport-Security, inspecione essa URL com o verificador de cabeçalhos HTTP.

Um salto que falha com erro de certificado em vez de um código de status também barra os navegadores: confira esse host no verificador de certificado SSL.

Como corrigir uma cadeia ou um loop de redirecionamentos?

Um loop acontece quando duas regras discordam: a CDN força https://example.com enquanto a origem força http://www.example.com, então cada salto desfaz o outro e o navegador desiste com ERR_TOO_MANY_REDIRECTS. Este verificador para depois de 10 saltos; quando uma URL volta a aparecer, ele aponta o salto que redirecionou de volta para a cadeia e, quando a cadeia é apenas longa demais, mostra a última URL alcançada. Para corrigir, escolha uma única forma canônica (protocolo, host e barra final), aplique-a em exatamente uma camada e reescreva as outras regras para que apontem direto para a URL final, e não umas para as outras.

  1. Escolha uma forma canônica: https, um só host e uma única convenção de barra final.
  2. Aplique-a em um único lugar, geralmente a CDN ou o servidor web, nunca nos dois e, ainda por cima, na aplicação.
  3. Encurte as cadeias: altere a primeira regra para apontar para a URL final, de modo que A vá direto para C, em vez de passar de A para B e de B para C.
  4. Rode o verificador novamente na URL antiga e confirme um único redirecionamento terminando em 200.

Vai corrigir isso no Apache? O gerador .htaccess escreve as regras 301 para você, incluindo os redirecionamentos de http para https e de www, para que cada URL antiga precise de um único salto.

É seguro usar um verificador de redirecionamentos?

Mais seguro do que clicar no link por conta própria. O rastreamento roda no nosso servidor, não no seu navegador: nenhum cookie do seu navegador é enviado, nenhum JavaScript é executado e, de uma página comum, só os primeiros 64 KB são lidos, para procurar uma tag meta refresh. Você vê o host de destino antes de decidir visitá-lo, exatamente o que você precisa diante de um link encurtado do t.co, bit.ly ou lnkd.in. Requisições para localhost, faixas privadas como 192.168.0.0/16 e endpoints de metadados de nuvem são recusadas, um redirecionamento que tente entrar nessas faixas é interrompido nesse mesmo salto e toda verificação termina após 10 saltos ou 20 segundos.

Sobre Verificador de redirecionamentos

Este verificador de redirecionamentos rastreia o que realmente acontece entre a URL que você digita e a página que finalmente carrega. A partir do nosso servidor, ele envia uma requisição GET por salto, sem cookies, registra o código de status, o cabeçalho Location e o tempo de cada salto, e passa para a próxima URL até chegar a uma resposta que não seja um redirecionamento — ou até completar 10 saltos, o que já equivale à profundidade máxima dos rastreadores do Google e a cerca de metade dos aproximadamente 20 saltos que um navegador permite antes de desistir com ERR_TOO_MANY_REDIRECTS.

Quando um salto responde 200 com uma página HTML, o verificador lê no máximo os primeiros 64 KB em busca de uma tag meta refresh, porque esse tipo de redirecionamento fica na página, e não nos cabeçalhos. Nada na página é executado, e é também por isso que os redirecionamentos em JavaScript ficam fora de alcance: eles só passam a existir quando um navegador executa os scripts da página.

O resultado é deliberadamente literal. O salto 1 é a URL que você digitou, e cada linha seguinte é a URL exata para a qual o salto anterior levou você, incluindo a troca de protocolo, o www adicionado ou removido, a barra final e a query string; um salto alcançado por meta refresh é marcado como tal, com o respectivo tempo de espera. É isso que torna a ferramenta útil em migrações: uma regra que parece correta na configuração do nginx muitas vezes se comporta de outro jeito quando o HSTS, uma regra na borda da CDN e um redirecionamento canônico no nível da aplicação entram em jogo ao mesmo tempo, e a única forma honesta de ver o resultado é segui-lo de fora.

Como alguns sites mandam celulares, rastreadores e navegadores de desktop para lugares diferentes, a requisição pode sair como o nosso próprio rastreador, como Chrome no Windows, como Safari em um iPhone, como Googlebot (smartphone ou computador) ou como Bingbot.

O modo em lote aceita até dez URLs de uma vez, rastreia uma após a outra e gera uma tabela com o número de redirecionamentos, o status final, a URL final e o tempo total, que você pode exportar como CSV ou colar direto em uma planilha ou em um ticket. O botão de variantes monta as quatro combinações de http e https, com e sem www, para o endereço informado e rastreia todas de uma só vez, o jeito mais rápido de confirmar que todas as portas de entrada convergem para uma única URL canônica.

Dúvidas típicas que ele resolve em segundos: se a URL antiga do produto ainda chega à nova com um único 301, se a regra de HTTP para HTTPS sobreviveu ao último deploy, se um link de afiliado mantém a query string até o fim e onde exatamente um link encurtado vai parar. Endereços privados, localhost e endpoints de metadados de nuvem são recusados, e cada verificação é interrompida após 20 segundos, então o verificador não pode ser usado para sondar uma rede interna.

Casos de uso

Validar uma migração de site: cole no modo em lote as suas dez URLs antigas com mais tráfego e confirme que cada uma retorna um único 301 direto para o novo endereço, e não um 302 ou um desvio pela página inicial.
Auditar a migração de HTTP para HTTPS: http://github.com deve responder 301 e chegar a https://github.com/ com um único redirecionamento. Três redirecionamentos geralmente significam que a regra de HSTS, a regra de www e a aplicação estão redirecionando uma após a outra.
Expandir um link encurtado antes de clicar nele: links do t.co, bit.ly e lnkd.in são resolvidos no servidor, então você vê o host de destino sem carregar a página nem rodar os scripts dela no seu navegador.
Depurar o rastreamento de campanhas: verifique se ?utm_source e ?gclid sobrevivem a cada salto, porque um redirecionamento que descarta a query string destrói silenciosamente a atribuição daquele clique.
Diagnosticar um ERR_TOO_MANY_REDIRECTS relatado por um cliente: quando uma URL aparece pela segunda vez, o rastreamento para ali mesmo e aponta o salto que redirecionou de volta para a cadeia — quase sempre uma CDN forçando HTTPS enquanto a origem força HTTP; já uma cadeia que nunca se repete, mas não termina, para no limite de 10 saltos e mostra a última URL alcançada.

Como verificar para onde uma URL redireciona

1

Cole a URL ou o link que você quer testar, por exemplo http://github.com, ou clique em um dos exemplos logo abaixo do campo.

2

Se quiser, escolha quem faz a requisição: nosso rastreador padrão, o Chrome, um iPhone, o Googlebot ou o Bingbot. Sites que tratam celulares ou bots de outra maneira vão mostrar uma cadeia diferente.

3

Pressione Enter ou clique em Verificar redirecionamentos. Cada salto é requisitado pelo nosso servidor, que segue respostas 301, 302, 303, 307 e 308 e tags meta refresh por até 10 saltos.

4

Leia o resumo: quantos redirecionamentos foram encontrados, o status HTTP final, o tempo total e a URL final. Um aviso aparece quando a URL entra em loop ou passa por mais de um redirecionamento.

5

Acompanhe a cadeia numerada para ver cada salto com a sua URL, o selo de status (como 301 Moved Permanently), se foi um meta refresh e quanto tempo aquele salto levou.

6

Para testar vários endereços, mude para o modo em lote (até 10 URLs) ou clique no botão de variantes para rastrear de uma só vez as versões http, https, com www e sem www; depois, exporte os resultados como CSV.

Dicas Pro

  • O ideal é um único 301 direto para a URL final. Cada salto extra custa uma viagem de ida e volta completa, um salto que muda para HTTPS acrescenta um handshake TLS e um salto que troca de host soma ainda uma consulta DNS — somados, normalmente de 100 a 300 ms em uma conexão móvel antes que qualquer coisa seja renderizada.
  • Use 308 em vez de 301 quando a requisição redirecionada puder ser um POST. O 301 e o 302 permitem que os clientes troquem o método para GET; o 307 e o 308 precisam preservar o método e o corpo.
  • Teste as versões http:// e www, além da https://; o botão de variantes testa as quatro de uma vez. Muitos sites redirecionam corretamente no HTTPS enquanto uma regra antiga do HTTP puro ainda aponta para um host desativado.
  • Confira o status do último salto, não só o número de redirecionamentos. Uma cadeia que termina em 404 ou 405 está quebrada, mesmo que todos os redirecionamentos pelo caminho tenham sido 301 impecáveis.
  • Depois de uma migração, passe as suas principais URLs do Search Console pelo modo em lote, baixe o CSV e compare-o com a mesma lista uma semana depois para flagrar regras que um deploy reverteu sem ninguém perceber.

Solução de problemas

Problema:

A verificação retorna 403 quando escolho o Googlebot.

Solução:

Muitos sites grandes confirmam se um visitante que diz ser o Googlebot vem mesmo da rede do Google e recusam todos os outros, incluindo este verificador. Compare com o agente padrão ou com o Chrome; para ver o que o próprio Google recebeu, use a ferramenta de inspeção de URL do Search Console.

Problema:

A cadeia termina em 403, 405 ou 503, mas a página abre no meu navegador.

Solução:

Provavelmente o site está filtrando clientes: uma proteção antibot ou um desafio da CDN que exige cookies e JavaScript, ou um bloqueio de faixas de IP de servidores. Tente o agente Chrome ou iPhone; se a resposta não mudar, o filtro atua na rede ou no comportamento, e uma verificação feita no servidor não consegue passar por ele.

Problema:

Meu navegador mostra ERR_TOO_MANY_REDIRECTS, mas o verificador mostra uma cadeia normal.

Solução:

O loop provavelmente depende de algo que este verificador não envia: um cookie, uma sessão autenticada ou a entrada HSTS que o seu navegador guarda. Limpe os cookies do site ou abra uma janela anônima e depois compare as versões http:// e https:// com o botão de variantes para encontrar a regra que manda os visitantes de volta.

Problema:

Um salto falha com um erro de certificado SSL em vez de um código de status.

Solução:

O certificado desse host está expirado, é autoassinado ou foi emitido para outro nome, então a conexão é recusada antes que qualquer redirecionamento possa ser lido. Os navegadores param no mesmo ponto. Renove ou corrija o certificado, ou aponte o salto anterior para um host com um certificado válido.

Perguntas frequentes

Ele mostra para onde uma URL realmente envia visitantes e mecanismos de busca. Você vê cada salto entre o endereço digitado e a página que finalmente responde, com o código de status e o tempo de cada um. Isso responde a três perguntas de uma vez: se o redirecionamento está sendo acionado, se ele aponta para o destino certo e quantos saltos são desperdiçados no caminho. Também é a forma segura de ver para onde leva um link encurtado ou de afiliado antes de clicar nele.

Um 301 diz que a mudança é permanente: os navegadores o armazenam em cache, e o Google consolida os sinais de ranqueamento da URL antiga no novo endereço e mantém a antiga apenas como nome alternativo; por isso, ela costuma deixar de aparecer nos resultados, mas ainda pode surgir quando uma consulta sugere que os usuários confiam nela. Um 302 diz que a mudança é temporária, então a URL original normalmente continua indexada e a resposta não é armazenada em cache, a menos que os cabeçalhos permitam. Use 301 em migrações e na adoção do HTTPS, e 302 apenas em testes A/B e páginas de manutenção.

Um é o ideal, dois são toleráveis e, a partir de três, é hora de encurtar a cadeia. Os navegadores desistem depois de cerca de 20 saltos, e os rastreadores do Google seguem até 10 saltos de redirecionamento antes de tratar a URL como erro. Cada salto extra custa uma viagem de ida e volta, um salto que troca de protocolo acrescenta um handshake TLS e um salto que muda de host soma ainda uma consulta DNS; assim, uma cadeia de três redirecionamentos pode somar várias centenas de milissegundos em conexões móveis antes que chegue o primeiro byte de conteúdo real.

Digite o seu domínio e clique no botão de variantes. Ele rastreia http://, https://, http://www. e https://www. para o mesmo caminho em um único lote. Em uma configuração saudável, as quatro versões terminam na mesma URL final com um 200: a versão canônica não mostra nenhum redirecionamento, e cada uma das outras três, um único 301 ou 308. Dois redirecionamentos na versão http://www. geralmente indicam que o protocolo e o host são corrigidos por regras separadas, que podem ser unificadas em uma só.

Sim. Escolha o user agent antes de executar a verificação: Chrome no Windows, Safari em um iPhone, Googlebot para smartphone ou para computador, ou Bingbot. Sites que mandam quem acessa pelo celular para um subdomínio m. ou que tratam rastreadores de outra maneira vão mostrar uma cadeia diferente para cada agente. Uma ressalva: muitos sites grandes verificam se um visitante que diz ser o Googlebot vem mesmo da rede do Google e, caso contrário, respondem 403; por isso, um 403 com o agente Googlebot muitas vezes significa exatamente isso. Para ver com precisão o que o Google recebeu, use a ferramenta de inspeção de URL do Search Console.

Meta refresh, sim. Quando um salto responde 200 com uma página HTML, o verificador lê os primeiros 64 KB, encontra uma tag meta refresh que contenha uma URL e a segue como o próximo salto, marcado como meta refresh e com o tempo de espera em segundos. Redirecionamentos em JavaScript, não: eles só acontecem depois que um navegador executa os scripts da página, e este verificador nunca executa nada. Se o último salto for um 200, mas o seu navegador acabar em outro lugar, a causa provável é um script; a aba Rede do DevTools mostra isso como uma navegação iniciada por script.

Há quatro causas comuns. O seu navegador tem o site no cache HSTS, então troca http:// por https:// antes que qualquer requisição saia da máquina. O site varia a resposta conforme o cookie, o cabeçalho de idioma ou o país, e o nosso servidor não tem o mesmo perfil que você. O site manda celulares e computadores para lugares diferentes, o que você pode reproduzir trocando o user agent. Ou um redirecionamento em JavaScript conclui o trajeto depois que a página carrega, algo que um rastreamento feito no servidor nunca vê.

Sim. Mude para o modo em lote e cole até dez URLs, uma por linha. Cada uma é rastreada separadamente, e os resultados vão para uma única tabela com o número de redirecionamentos, o status final, a URL final e o tempo total. Baixe essa tabela como CSV ou copie-a como texto separado por tabulações, que pode ser colado direto no Sheets, no Excel ou em um ticket do Jira sem nenhuma reformatação. O botão de variantes preenche a mesma tabela com as quatro versões de um endereço: http/https, com e sem www.

Abra o DevTools com F12, vá até a aba Rede (Network), marque Preservar registro e carregue a URL. Cada salto aparece em sua própria linha, com status 301 ou 302; clique em um deles e leia o cabeçalho Location em Cabeçalhos de resposta. O problema é que o DevTools mostra o que o seu navegador fez, com direito aos seus cookies, ao cache HSTS e às extensões, então um colega em outra máquina pode ver uma cadeia diferente.

Um único 301 ou 308 transmite os sinais de ranqueamento e não é problema. Já as cadeias são um problema, por dois motivos: os rastreadores do Google seguem até 10 saltos de redirecionamento e reportam qualquer cadeia mais longa como erro de redirecionamento, e cada salto atrasa o primeiro byte, o que pesa diretamente nas Core Web Vitals. Loops são piores, porque a página nunca pode ser alcançada e sai do índice por completo. Encurte as cadeias para que a primeira URL aponte direto para a última.

Fontes e leitura complementar

FreeWebTools AI
Powered by free AI models · Full chat →