Blog

Blog

Redirecionamento 301, 302, 307 e 308: qual usar em cada caso

Um redirecionamento avisa navegadores e buscadores de que uma página mudou de endereço. Para o Google, a escolha não é entre 301 e 302, e sim entre permanente e temporário. Um redirecionamento permanente faz o buscador mostrar o novo URL nos resultados, e um temporário mantém o URL antigo. Redirecionamentos permanentes não causam perda de PageRank, então a escolha define apenas em qual endereço os sinais de ranqueamento vão ficar.

O que é um redirecionamento e quando usar um

Um redirecionamento resolve um URL existente para um endereço diferente, encaminhando quem acessa e informando o Google de que o conteúdo tem uma nova localização. A documentação do Google lista quatro situações em que ele é a ferramenta certa:

Redirecionamento e rel=canonical resolvem problemas parecidos por caminhos diferentes. O redirecionamento é obrigatório, quem pede o endereço antigo é levado ao novo, sem escolha. A tag canonical é uma sugestão de qual versão deve ser indexada, e o conteúdo continua acessível nos dois endereços. Use redirecionamento quando o conteúdo antigo deve sumir, e canonical quando as duas versões precisam continuar no ar.

Nem toda mudança pede redirecionamento. Se a página foi removida sem substituída, o correto é devolver 404 ou 410, não empurrar o visitante para outro lugar qualquer.

301 ou 302, o que muda para o Google e para o navegador

O 301 diz que a mudança é definitiva e o 302 diz que é provisória, e o Google trata cada um de forma oposta nos resultados. Com um redirecionamento permanente, o Googlebot segue o caminho e o pipeline de indexação usa o destino como sinal de que ele deve ser a URL canônica. Com um temporário, o Googlebot também segue, mas não usa o destino como sinal de canonicalização, o que ajuda a manter o URL de origem nos resultados de busca.

Essa inversão é o que torna o 302 útil. A documentação cita o seguinte exemplo: se um serviço do seu site ficou indisponível por um período, você pode redirecionar temporariamente para uma página que explica o que aconteceu sem comprometer o URL original na busca. Quando o serviço voltar, o endereço que sempre ranqueou continua lá.

A diferença também existe no navegador do visitante, e esse detalhe costuma passar despercebido. Com um 302, o navegador refaz a requisição ao endereço antigo toda vez que alguém digita o URL, clica num favorito ou segue um link. Com um 301, o navegador salva em cache que a mudança é permanente e passa a nem requisitar o endereço original, indo direto ao destino. Por isso que reverter um 301 que foi publicado por engano é trabalhoso, pois o redirecionamento fica em salvo no navegador de quem já passou por ele.

O redirecionemento 301 e os demais redirecionamentos permanentes não causam perda de PageRank. O que a escolha determina é se os sinais ficam no URL antigo ou vão para o novo, e essa é uma decisão de quem administra o site. Em uma migração de HTTP para HTTPS, por exemplo, o 301 é sempre a escolha certa, porque não existe cenário em que você pretende voltar ao endereço inseguro.

Todos os tipos de redirecionamento que o Google entende

Existem dois eixos independentes na escolha de um redirecionamento. O primeiro eixo é a duração (permanente ou temporário) e é o único que o Google usa para decidir qual URL mostrar nos resultados. O segundo é o que acontece com o método da requisição HTTP, e é ele que separa 301 de 308 e 302 de 307.

CódigoInterpretação do GoogleMétodo da requisiçãoCaso de uso típico
301 Moved PermanentlyPermanentePode ser trocado de POST para GET pelo clienteMudança definitiva de páginas: novo domínio, nova estrutura de URL, HTTP para HTTPS
308 Permanent RedirectPermanentePreservado, junto com o corpo da requisiçãoMudança definitiva de endereços que recebem POST, PUT ou DELETE
302 FoundTemporárioPode ser trocado de POST para GET pelo clienteIndisponibilidade temporária, teste A/B, redirecionamento m-dot
307 Temporary RedirectTemporárioPreservado, junto com o corpo da requisiçãoDesvio temporário de um endereço que recebe POST
303 See OtherTemporárioSempre trocado para GETLevar a uma página de confirmação depois do envio de um formulário

Fonte: documentação de redirecionamentos do Google Search Central (atualizada em abril de 2026) e referência de códigos de status da MDN.

Dentro de cada par, a duração é idêntica e só o método muda. O 301 e o 302 foram definidos numa época em que os clientes rotineiramente rebaixavam um POST para GET ao seguir o redirecionamento, e a especificação acabou aceitando esse comportamento como realidade. O 308 e o 307 foram criados depois justamente para garantir que o método e o corpo da requisição cheguem intactos ao destino. Para requisições GET, 301 e 308 se comportam de forma idêntica, assim como 302 e 307.

Na prática, esse segundo eixo quase nunca importa para SEO. O Googlebot rastreia páginas com GET, então, para um URL que você quer indexado, a coluna do método é irrelevante e só a coluna da interpretação decide alguma coisa. É por isso que o 308 funciona exatamente como o 301 para indexação e transferência de sinais, e o 307 mantém o endereço antigo nos resultados exatamente como o 302.

O erro comum é o mapeamento invertido: tratar 307 e 308 como um par e escolher o 307 para uma mudança definitiva, apenas por ser "mais moderno". Nesse caso você estará pedindo ao Google para continuar mostrando o endereço antigo. Se a dúvida for só entre 301 e 308 numa página comum, use 301, é o mais compatível com clientes antigos e todo rastreador entende. Reserve o 308 para endereços que recebem POST, como endpoints de API e URLs de envio de formulário, que de qualquer forma não são conteúdo para indexar.

O Google reconhece ainda quatro métodos que não usam código de status, e os interpreta assim:

MétodoInterpretação do Google
meta refresh instantâneo (0 segundos) e cabeçalho Refresh de 0 segundosPermanente
meta refresh com atraso e cabeçalho Refresh acima de 0 segundosTemporário
location de JavaScriptPermanente
Crypto redirect (link com aviso de mudança)Permanente, quando reconhecido

Fonte: documentação de redirecionamentos do Google Search Central (atualizada em abril de 2026) e referência de códigos de status da MDN.

A ordem em que o Google apresenta esses métodos também carrega informação. Eles são listados por probabilidade de interpretação correta, e o redirecionamento no servidor está no topo. Se o seu ambiente permite configurar .htaccess no Apache, regras no NGINX ou cabeçalhos via linguagem de backend, essa é a implementação a escolher.

meta refresh e cabeçalho Refresh

O tempo configurado no meta refresh decide como o Google interpreta o redirecionamento. Um meta refresh instantâneo, com content="0", é lido como redirecionamento permanente. Um meta refresh com atraso, com qualquer número de segundos acima de zero, é lido como temporário. A tag vai dentro do <head>, e o mesmo comportamento vale para o cabeçalho HTTP Refresh injetado pelo servidor.

Vale usar esses métodos apenas quando o redirecionamento no servidor não for possível na sua plataforma. Além de serem menos confiáveis para o Google, os redirecionamentos com atraso são ruins para acessibilidade, tendo em vista que a pessoa fica numa página que parece estável e, alguns segundos depois, é levada para outro lugar sem ter pedido.

Redirecionamento por JavaScript

O Google segue redirecionamentos feitos com window.location porque interpreta e executa JavaScript no Web Rendering Service depois de concluir o rastreamento do URL. Ele conta como permanente, mas há o risco de a renderização falhar por vários motivos, e nesse caso o Google simplesmente nunca verá o redirecionamento que você configurou. A recomendação oficial é usar JavaScript apenas quando servidor e meta refresh não forem opções. Se quiser entender por que a renderização pode falhar, veja como o Google renderiza uma página.

Crypto redirect

Quando nenhum dos métodos anteriores é viável, resta avisar o visitante com um link para o novo endereço acompanhado de uma explicação curta. O Google chama isso de crypto redirect e pode interpretá-lo como um redirecionamento, mas a própria documentação faz a ressalva de que a existência dele é discutível, comparando o caso ao monstro do Lago Ness, e de que nem todo buscador reconhece esse pseudo-redirecionamento. Não confie nele para comunicar uma mudança de endereço a menos que não exista alternativa.

Mudança de domínio e de estrutura de URL

Numa mudança de domínio, redirecione tudo, de preferência com mapeamento de um URL antigo para um novo. Não aponte muitos URLs antigos para um destino único e irrelevante, como a home do site novo, porque isso confunde o visitante e pode ser tratado como erro soft 404. Evite cadeias de redirecionamento. O Googlebot segue até dez saltos, mas a recomendação é apontar direto ao destino final e, quando não der, ficar em no máximo três. Mantenha os redirecionamentos no ar por pelo menos um ano, tempo necessário para o Google transferir todos os sinais e reprocessar os links de terceiros. E envie uma solicitação de Mudança de Endereço no Search Console para o site antigo, incluindo subdomínios e as variantes com e sem www (o que não é necessário quando a migração é apenas de HTTP para HTTPS).

Fusões e divisões de domínio são um caso à parte, porque não existe mapeamento limpo (quem fica com a home?) e o Google precisa reavaliar a importância relativa de cada página. Flutuações de médio prazo são o resultado esperado, e não há recurso de SEO que as evite. Se a sua mudança é só de estrutura de URL dentro do mesmo domínio, o post sobre URL amigável trata de como desenhar os novos endereços antes de configurar os redirecionamentos.

Os redirecionamentos que atrapalham o SEO

Alguns redirecionamentos funcionam perfeitamente para pessoas e quebram para o Googlebot. São quatro padrões recorrentes.

Redirecionamento forçado por país. Por padrão, os endereços IP do Googlebot aparentam estar nos Estados Unidos, e o rastreador envia requisições sem definir o cabeçalho Accept-Language. Se o seu site responde a um visitante norte-americano com "este produto não está disponível na sua região", há uma boa chance de ser exatamente isso que o Google vê e indexa. O Google também rastreia com IPs de fora dos Estados Unidos em configurações de rastreamento geodistribuído, mas quem aciona essas configurações são os sistemas dele, não você, e a recomendação oficial continua sendo usar URLs separadas por localidade com anotações hreflang em vez de trocar o conteúdo no mesmo endereço.

Interstitial de idade ou de país implementado como redirecionamento. Quando a verificação leva o visitante a uma página separada e o traz de volta depois do formulário, o Googlebot cai no formulário e não sabe o que fazer. Na prática, você bloqueou o rastreador e não o adolescente que clica em "sim, tenho 18 anos". Se a exigência é legal e inegociável, implemente como uma div sobre o conteúdo, o Google renderiza o que está embaixo e usa aquilo para indexar.

Proteção contra bots com desafio e retorno. É o mesmo mecanismo: o visitante é redirecionado para um captcha e devolvido depois da validação. O Googlebot é um bot e não avança para o site. Se a intenção é aparecer na busca, a proteção precisa reconhecer os rastreadores legítimos, tema que o post sobre como o Google rastreia seu site detalha.

Redirecionamento entre versão mobile e desktop. Sites com domínio m-dot separado costumam detectar o viewport e mandar o visitante para m.exemplo.com. Esse tipo de implementação deve usar 302, porque na próxima visita não dá para saber qual versão a pessoa quer e o redirecionamento deve ser feito nos dois sentidos. Redirecionar só o tráfego mobile para a versão reduzida, sem levar o desktop para a versão completa, leva o Google a assumir que todo o conteúdo do site está na versão mobile. Como a indexação mobile first já é o padrão, o que faltar lá simplesmente não existe para a busca.

Como testar e diagnosticar redirecionamentos

Use a Inspeção de URL do Search Console para testar endereços individuais, e não se assuste quando ela mostrar 200 num URL que você sabe que redireciona. A ferramenta exibe a página que o Google usaria para indexar, ou seja, o destino final, não a resposta da origem. O mesmo vale para redirecionamentos por JavaScript, que a ferramenta segue durante a renderização. Ainda não há um aviso explícito na interface indicando que um redirecionamento foi seguido no caminho, o que é uma fonte conhecida de confusão para quem está depurando.

Durante uma migração, os relatórios do Search Console contam a história em duas curvas. o número de URLs indexados cai no site antigo e sobe no novo. Avisos no relatório de Sitemaps sobre URLs antigos que redirecionam são normais e podem ser ignorados, porque você está mesmo migrando. O que merece atenção é um pico de erros "Página não encontrada", sinal frequente de redirecionamentos apontando para endereços que não existem no site novo. O post sobre como funciona a indexação ajuda a interpretar o que o Google faz depois de seguir o redirecionamento.

Perguntas frequentes sobre redirecionamentos

Redirecionamento 301 perde PageRank?

Não. A documentação do Google afirma que o 301 e os demais redirecionamentos permanentes não causam perda de PageRank. O que a escolha do tipo de redirecionamento define é em qual URL os sinais ficam concentrados, o antigo ou o novo, e essa decisão é de quem administra o site.

Qual a diferença entre 307 e 308?

O 308 é um redirecionamento permanente e o 307 é temporário. Apesar de os dois repassarem requisições POST, o Google os classifica em grupos opostos: o 308 fica ao lado do 301 e faz o destino virar candidato a canônica, enquanto o 307 fica ao lado do 302 e mantém o endereço de origem nos resultados.

Por quanto tempo devo manter um redirecionamento no ar?

Pelo menos um ano, segundo a recomendação do Google. Esse prazo dá tempo de o buscador transferir todos os sinais para os novos endereços, o que inclui rastrear de novo e reatribuir os links que outros sites apontam para os URLs antigos. Do ponto de vista de quem navega, vale manter os redirecionamentos por tempo indeterminado.

Redirecionamento por JavaScript funciona para SEO?

Funciona, e o Google o interpreta como permanente, mas só deve ser usado quando redirecionamento no servidor e meta refresh não forem possíveis. O motivo é que o Google só executa o JavaScript na etapa de renderização, e a renderização pode falhar. Se falhar, o redirecionamento nunca é visto.

Posso redirecionar todas as páginas antigas para a home do site novo?

Não é recomendado. Apontar muitos URLs antigos para um destino único e irrelevante confunde quem clica e pode ser tratado pelo Google como erro soft 404. A exceção é quando você realmente consolidou o conteúdo de várias páginas em uma só: nesse caso, redirecionar as antigas para a página consolidada é o comportamento correto.

Por que a Inspeção de URL mostra 200 num URL que redireciona?

Porque a ferramenta mostra a página que o Google usaria para indexar, que é o destino final do redirecionamento, e não a resposta HTTP do endereço de origem. Não é um erro de diagnóstico. Para conferir o código de status da origem, use uma ferramenta de linha de comando ou um rastreador que exiba a cadeia completa.

Próximos passos

O erro mais caro em redirecionamento raramente é o código escolhido, é o redirecionamento que existe para pessoas mas não funciona para o Googlebot: o bloqueio por país, o interstitial que vira desvio ou o m-dot em mão única. Antes de mexer em qualquer regra, levante quais URLs do seu site já redirecionam hoje e para onde, porque cadeias acumuladas ao longo de anos são mais comuns do que parecem. Com o mapa na mão, a decisão entre permanente e temporário fica trivial.

Continue lendo

SEO Técnico O que é SEO técnico 13 min de leitura SEO Técnico Como o Google rastreia seu site: Crawlers, Googlebot e crawl budget 11 min de leitura