Como verificar redirecionamentos: verificador de redirect 301, curl e DevTools
Para verificar redirecionamentos, solicite a URL e siga cada salto até que uma página responda 200: você precisa do código de status de cada etapa, do número de etapas e do endereço final. A forma mais rápida é o verificador de redirecionamentos online gratuito: cole uma URL e ele mostra toda a cadeia 301/302/307/308; em um terminal, curl -sIL faz o mesmo. Abaixo estão três formas de verificar redirecionamentos em um site, um teste rápido para saber se um redirecionamento 301 está funcionando e como corrigir cadeias e loops no nginx, no Apache e no WordPress.
Como verificar redirecionamentos online
A forma mais rápida é o verificador de redirecionamentos gratuito. Ele solicita a URL, segue sozinho cada cabeçalho Location (até 15 etapas) e mostra o caminho completo.
- Cole o endereço completo, incluindo o protocolo:
http://example.comehttps://example.comcostumam se comportar de forma diferente, então verifique os dois. - Leia o resumo: número de redirecionamentos, status final, tempo total e se a cadeia termina no mesmo domínio ou em outro.
- Percorra a cadeia etapa por etapa. Cada etapa mostra a URL e o código: 301 ou 308 aparecem como permanentes, 302 ou 307 como temporários.
- Confira as recomendações abaixo da cadeia. A ferramenta sinaliza cadeias com mais de uma etapa, redirecionamentos temporários que talvez devam ser 301 e redirecionamentos para outro domínio, além de confirmar um redirecionamento HTTP → HTTPS correto.
Duas limitações a ter em mente: o verificador segue apenas redirecionamentos HTTP do lado do servidor (não meta refresh nem JavaScript, veja abaixo) e solicita a página com seu próprio user agent, então redirecionamentos que dependem do país, do dispositivo ou dos cookies do visitante podem parecer diferentes para usuários reais.
Como verificar um redirecionamento 301 com curl
Em um terminal, o curl mostra os cabeçalhos brutos da resposta, sem o cache do navegador:
curl -sIL http://example.com/old-page \
| grep -iE "^HTTP|^location"
-I solicita apenas os cabeçalhos, -L segue os redirecionamentos e grep mantém só as linhas de status e os destinos. Um resultado correto fica assim:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page/
HTTP/2 200
Alguns servidores respondem às requisições HEAD de forma diferente das normais. Se o resultado parecer estranho, repita com uma requisição GET real: curl -sL -o /dev/null -D - URL.
Verificando redirecionamentos no Chrome DevTools
- Abra o DevTools (F12) → Network.
- Marque Preserve log, caso contrário as etapas do redirecionamento desaparecem quando a página muda, e Disable cache.
- Carregue a URL antiga. Cada etapa aparece como uma linha separada com seu status; o cabeçalho Location está nos cabeçalhos da resposta.
Os navegadores armazenam respostas 301 em cache de forma agressiva. Se você alterou um redirecionamento e o navegador ainda segue o antigo, teste em uma janela anônima ou com curl antes de concluir que o servidor está errado.
Meu redirecionamento 301 está funcionando? Verificação em quatro pontos
- A primeira resposta é 301 ou 308. Um 302 ou 307 em uma mudança permanente é o erro mais comum: a URL antiga pode continuar no índice.
- O Location aponta direto para a URL final. Um salto, não dois ou três: sem desvio por
http://,wwwou pela falta da barra final. - O endereço final responde 200 e é a página que você pretendia, não a home nem um 404.
- Todas as variantes se comportam da mesma forma. Verifique
http://ehttps://, com e semwww: cada uma deve chegar à URL final em um único redirecionamento.
301 vs 302 vs 307 vs 308
| Código | Tipo | Método da requisição | Como o Google trata | Use para |
|---|---|---|---|---|
| 301 | Permanente | Pode mudar POST para GET | Sinal forte de que o destino se torna canônico | URLs alteradas, HTTPS, www/sem www, mudanças de domínio |
| 308 | Permanente | Preservado | Igual ao 301 | Mudanças permanentes em formulários e APIs |
| 302 | Temporário | Pode mudar POST para GET | Sinal fraco; a origem geralmente continua no índice | Promoções curtas, testes A/B, manutenção |
| 307 | Temporário | Preservado | Igual ao 302 | Mudanças temporárias em que o método importa |
| Meta refresh / JS | Nível de página | — | Meta refresh instantâneo é lido como permanente; JS só após a renderização | Somente quando redirecionamentos no servidor são impossíveis |
Um 307 também pode aparecer no DevTools sem que seu servidor o tenha enviado: trata-se do redirecionamento interno do navegador para HTTPS em sites que estão na lista HSTS. O curl e o verificador online mostrarão a resposta real do servidor.
Cadeias e Loops de Redirecionamento
Uma cadeia é uma sequência de vários redirecionamentos: http://example.com/page → https://example.com/page → https://www.example.com/page → https://www.example.com/page/. Cada etapa adiciona uma ida e volta para o usuário. O Googlebot segue até 10 saltos, mas o Google recomenda manter as cadeias curtas, e cada etapa extra é mais um ponto em que algo pode quebrar na próxima migração. O ideal é um único redirecionamento de qualquer endereço antigo para o final.
Um loop é uma cadeia que volta a um endereço já visitado, e por isso nunca termina. Os navegadores mostram ERR_TOO_MANY_REDIRECTS e a página não pode ser indexada. No verificador, um loop aparece como uma cadeia que atinge o limite de 15 etapas com os mesmos endereços se repetindo. Causas típicas: um redirecionamento HTTPS no servidor somado à configuração "Flexible SSL" na CDN, ou regras de www conflitantes em dois lugares (configuração do servidor e CMS).
Como Verificar Redirecionamentos em um Site Inteiro
URLs individuais servem para verificações pontuais. Para encontrar todas as cadeias de um site, você precisa de um crawler que siga os links internos e registre cada redirecionamento. O SEO Audit faz isso e relata cadeias e loops de redirecionamento como problemas separados, junto com links quebrados, para que você veja quais links internos ainda apontam para endereços antigos.
Como Corrigir Redirecionamentos
nginx
Combine esquema e host em uma única etapa em vez de duas:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
location = /old-page/ {
return 301 /new-page/;
}
}
Adicione um bloco listen 443 separado para www.example.com que também retorne 301 para https://example.com$request_uri. Depois de editar, execute nginx -t e recarregue.
Apache (.htaccess)
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]
Redirect 301 /old-page/ https://example.com/new-page/
O gerador de .htaccess cria essas regras sem erros de digitação.
WordPress
- Verifique se em Configurações → Geral a URL final (https e a versão correta de www) está nos dois campos de endereço; uma divergência com a regra do servidor é uma causa clássica de loops.
- Para páginas individuais, use um plugin de redirecionamento (por exemplo, Redirection) ou o gerenciador de redirecionamentos do seu plugin de SEO, e evite definir o mesmo redirecionamento em um plugin e na configuração do servidor.
- Depois de alterar os links permanentes, teste algumas URLs antigas: o WordPress deduz sozinho alguns slugs antigos, mas não todos.
Seja qual for o servidor, atualize os links internos, as tags canonical e o sitemap para apontarem diretamente para as URLs finais, de modo que os redirecionamentos sejam necessários apenas para links externos e favoritos antigos.
Por Que Isso Importa para a Promoção de Links
Os links apontam para um endereço específico. Com um redirecionamento permanente, o valor deles ainda chega à página final, mas é melhor promover diretamente o endereço final. Se uma página promovida mudou de endereço após o lançamento, configure um 301 a partir do endereço antigo: as publicações não precisam ser refeitas, veja "Posso Excluir ou Alterar uma Publicação".