Verificar redirecionamento 301: veja a cadeia inteira

Um verificador de redirecionamento mostra o que acontece de verdade entre clicar em um link e chegar a uma página. Cada URL que você digita é acessada a partir do servidor do Marqly com os redirecionamentos automáticos desligados, então cada resposta fica registrada separadamente: o código de status, o cabeçalho Location para onde ela aponta, quanto tempo levou e os cabeçalhos que importam para SEO. Depois a ferramenta segue esse endereço e repete, até 10 redirecionamentos, o mesmo limite que os rastreadores do Google usam por padrão. Você recebe a cadeia de redirecionamentos completa, a URL e o status finais e alertas em linguagem simples sobre loops, redirecionamentos temporários, saltos lentos, parâmetros de rastreamento perdidos e cadeias que vale a pena encurtar.

Como verificar um redirecionamento

1. Cole uma URL na caixa. Para uma verificação em lote, cole até 10 URLs, uma por linha.
2. Escolha um user agent se precisar. O padrão se identifica como o verificador do Marqly; você também pode enviar o user agent do Chrome, do Safari no iPhone, do Googlebot para smartphones ou do Googlebot para computador para pegar regras que tratam navegadores, celulares e rastreadores de jeitos diferentes.
3. Marque Verificar também as versões http/https e com/sem www para testar as quatro formas do mesmo endereço de uma vez. É o jeito mais rápido de confirmar que um site tem um único nome de host canônico e que todas as variantes chegam a ele em um único salto.
4. Clique em Verificar redirecionamentos. Cada URL ganha um card próprio com o veredito, os alertas e a cadeia salto a salto.
5. Use Copiar resultados para ter um relatório em texto, Baixar CSV para uma planilha com uma linha por salto, ou Copiar link para compartilhar para mandar um link que roda a mesma verificação de novo.

Como ler os resultados

Cada card começa com o código de status final, a URL que você digitou, o número de redirecionamentos, o tempo total e a URL final. Abaixo, os alertas apontam o que merece atenção: desde erros (loops, cadeias acima do limite, uma cadeia que termina em 404) até avisos (redirecionamentos temporários, meta refresh, uma troca de https para http, parâmetros de consulta perdidos, um X-Robots-Tag: noindex na página final) e observações neutras (mudanças de barra final ou de www, uma mudança para outro domínio, saltos lentos).

A tabela da cadeia lista cada pedido em ordem. Status é o código de status HTTP que o servidor devolveu. URL é o que foi acessado e, logo abaixo, para onde aquele salto manda o cliente, já convertido em endereço absoluto quando o servidor envia uma Location relativa.Tempo é quanto o servidor levou para devolver os cabeçalhos daquele salto. AbraCabeçalhos em qualquer linha para ver Location, Cache-Control,Content-Type, X-Robots-Tag, Link (onde uma canônica pode ser declarada), Strict-Transport-Security, X-Redirect-By (o WordPress e alguns plugins se identificam aqui) e Server. Os valores dos cookies nunca aparecem, só quantos foram definidos.

301, 302, 307 e 308: o que cada código de redirecionamento significa

O HTTP define os códigos de status de redirecionamento naRFC 9110, seção 15.4. Duas perguntas separam um do outro: a mudança é permanente? E o cliente pode trocar o método do pedido (por exemplo, transformar um POST de formulário em GET) ao seguir o redirecionamento? Adocumentação do Google sobre códigos de status HTTPexplica como os rastreadores e a indexação tratam cada um.

Para páginas comuns, use 301 quando o conteúdo mudou de vez: um slug renomeado, um artigo mesclado, uma migração de domínio, a mudança para HTTPS. Use 302 ou 307quando a URL original vai voltar, como uma página de manutenção, uma campanha curta ou um teste. Prefira o308 quando o método importa, por exemplo em um endpoint de API ou em um formulário que recebe pedidos POST, porque a RFC 9110 deixa os clientes transformarem um POST redirecionado em GET com 301 e 302, mas proíbe isso com 307 e 308.

Meta refresh e redirecionamentos em JavaScript

O guia do Google sobre redirecionamentosrecomenda um redirecionamento permanente do lado do servidor sempre que possível. Ele trata um meta refresh instantâneo como redirecionamento permanente e um com atraso como temporário, e só indica redirecionamentos em JavaScript quando não dá para usar nem o redirecionamento do servidor nem o meta refresh, porque a renderização pode falhar. Este verificador segue as tags meta refresh e o cabeçalho Refresh e marca esses saltos, mas não executa JavaScript.

O que é uma cadeia de redirecionamentos e por que ela atrapalha?

Uma cadeia de redirecionamentos é qualquer caminho com mais de um salto: http://example.com/page →https://example.com/page → https://www.example.com/page →https://www.example.com/page/. Cadeias quase nunca nascem de propósito. Elas se acumulam quando um site muda para HTTPS, escolhe usar ou não o www, troca de CMS, renomeia seções e redireciona redirecionamentos antigos em vez de reescrevê-los. Cada camada funciona sozinha; juntas, elas se somam.

• Velocidade. Cada salto é mais um pedido completo antes de a página começar a carregar, e um salto para um novo nome de host acrescenta uma consulta DNS e um handshake TLS. A coluna de tempo mostra quanto cada salto custa.
• Rastreamento. O Google diz que os rastreadores dele seguem até 10 saltos de redirecionamento por padrão, e o relatório de indexação de páginas lista uma cadeia de redirecionamentos longa demais, um loop de redirecionamento e uma URL inválida ou vazia na cadeia entre oserros de redirecionamento. O guia do Google para mudar um site de endereçorecomenda redirecionar direto para o destino final, observando que encadear acrescenta latência e que nem todos os user agents e navegadores aceitam cadeias longas.
• Outros clientes. A RFC 9110 lembra que uma especificação HTTP anterior recomendava no máximo cinco redirecionamentos e que alguns clientes ainda podem aplicar um limite fixo assim, então uma cadeia que o Googlebot tolera ainda pode quebrar em outro software.
• Fragilidade e dados perdidos. Cada salto é mais uma regra que pode ser editada, apagada ou encoberta por outra. Um salto que remonta a URL pode descartar a query string sem avisar, e é assim que as tags UTM somem antes de o analytics chegar a vê-las; o verificador avisa quando um parâmetro da sua URL original não está na URL final.

Como corrigir uma cadeia de redirecionamentos

1. Encontre a URL final. Passe a URL antiga pelo verificador e copie a última URL da cadeia.
2. Aponte o primeiro redirecionamento para a URL final. Se A redireciona para B e B redireciona para C, mude a regra de A para ir direto para C e mantenha B → C para quem ainda tem B. Em um mapa de redirecionamentos ou em um plugin, procure regras cujo destino é, ao mesmo tempo, a origem de outra regra.
3. Junte as regras de protocolo e de nome de host. A cadeia mais comum é http → https seguida de sem www → com www. Escreva uma única regra que mande todas as variantes para a forma canônica em um passo só, como neste exemplo de nginx:

# Um único salto de cada variante para https://www.example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # linhas ssl_certificate omitidas
    return 301 https://www.example.com$request_uri;
}

4. Atualize os links na origem. Troque links internos, tags canônicas, anotações hreflang e sitemaps XML pelas URLs finais; o guia do Google para mudança de site pede que os links internos sejam atualizados para as novas URLs. Os redirecionamentos devem pegar links antigos vindos de fora, não sustentar a sua própria navegação.
5. Mantenha os redirecionamentos. O Google sugere mantê-los pelo maior tempo possível, em geral por pelo menos um ano. Encurtar uma cadeia significa mudar o destino dela, não apagar as regras antigas.
6. Teste de novo. Rode as mesmas URLs outra vez, de preferência com a opção de variantes marcada, e confirme que cada uma chega a uma página 200 em um salto só.

Como corrigir um loop de redirecionamento

Um loop é uma cadeia que volta para uma URL que já visitou, então nunca termina; os navegadores mostram um erro de redirecionamentos demais. As causas comuns são duas camadas que discordam: uma CDN que fala com o servidor de origem por HTTP enquanto a origem força HTTPS, uma regra de barra final no servidor web brigando com a regra oposta na aplicação, ou regras de www configuradas ao mesmo tempo no encaminhamento do DNS e no próprio site. Olhe o salto em que a URL volta atrás; os cabeçalhos Server eX-Redirect-By dele costumam dizer qual camada o enviou. Alguns loops só acontecem sem cookies (redirecionamentos de consentimento ou de login) e não afetam quem já tem esses cookies; o verificador não envia cookies, então também revela esses casos.

Verificar redirecionamentos em lote

Cole até 10 URLs, uma por linha, para verificar todas em uma única execução; duplicadas são removidas e cada URL recebe o próprio resultado. A exportação em CSV tem uma linha por salto, com a URL de entrada repetida, então dá para filtrar por status, ordenar pelo número de saltos ou passar o arquivo para quem cuida das regras de redirecionamento. Se você quer revisar links antigos salvos no navegador, primeiro exporte seus favoritos do Chrome para um arquivo HTML e copie dali as URLs que interessam. Para um site inteiro, use um rastreador ou os logs do servidor para achar as URLs redirecionadas e depois confira aqui as mais importantes com o user agent do Googlebot.

HTTPS, www e barra final

A maioria dos sites deveria responder em uma única combinação de protocolo e nome de host, com todas as outras formas redirecionando para ela de forma permanente e em um salto só. A opção de variantes verificahttp://example.com, https://example.com, http://www.example.com ehttps://www.example.com com o mesmo caminho e mostra se as quatro terminam na mesma URL e quantos saltos cada uma precisa. Os alertas apontam uma mudança para HTTPS que acontece tarde na cadeia, uma cadeia que alterna entre www e sem www mais de uma vez, e saltos que só acrescentam ou tiram uma barra final ou mudam maiúsculas e minúsculas, fáceis de incorporar ao primeiro redirecionamento.

Por que os resultados podem ser diferentes no seu navegador

Se o seu navegador chega a outro lugar, normalmente é porque ele está lembrando de alguma coisa. A RFC 9110 permite guardar um 301 em cache, então um navegador pode pular um redirecionamento antigo, ou continuar seguindo um que você já tirou. Depois que um navegador viu o cabeçalho HSTS de um site (ou o site está na lista de pré-carregamento do HSTS), ele troca http:// por https:// internamente antes de qualquer pedido sair do seu computador. Cookies, idioma e localização podem disparar redirecionamentos próprios. O verificador começa limpo toda vez e mostra o que o servidor envia, que é a visão que importa para os rastreadores e para quem visita o site pela primeira vez.

Como o verificador funciona

Cada salto é um pedido GET feito pelo servidor do Marqly na Cloudflare com os redirecionamentos em modo manual, então nada é seguido antes de o verificador registrar. Cada nome de host é resolvido e precisa apontar para um endereço público; redes privadas, localhost e endereços de metadados de nuvem são recusados, inclusive quando um redirecionamento aponta para um deles no meio da cadeia. Cada salto tem tempo limite de 6 segundos, uma cadeia inteira para depois de 20 segundos ou de 10 redirecionamentos, e o conteúdo das páginas é descartado, com exceção dos primeiros 64 KB de uma página HTML final, que são analisados em busca de um meta refresh. Nada é salvo: os resultados existem só na aba do seu navegador.

Se você monta links de campanha, o gerador de UTM cria esses links e este verificador confirma que os parâmetros sobrevivem a cada salto. Para equipes que publicam e migram páginas com frequência, o Marqly também funciona como arquivo de referência: veja como ele ajudadesenvolvedores a guardar documentação e equipes demarketing a juntar landing pages, campanhas e concorrentes em um só lugar.