Redirecionamento 301 vs 302: compreender as diferenças, o impacto SEO e realizar uma migração de domínio bem-sucedida

Q: Como verificar que um redirecionamento funciona corretamente?

Vários métodos. Na linha de comando, use curl -I URL para mostrar os cabeçalhos de resposta HTTP e verificar o código de estado (301 ou 302) e o cabeçalho Location . Em um navegador, abra as ferramentas de desenvolvimento (aba Rede) e observe a cadeia de requisições. Você também pode usar o Page Crawl Checker para verificar os redirecionamentos e detectar as cadeias.

Por CaptainDNS
Publicado em 16 Meurzh 2026

Esquema comparativo dos redirecionamentos 301 e 302 com impacto SEO, transferência de PageRank e checklist de migração de domínio

TL;DR

301 = redirecionamento permanente, transfere 100 % do ranking SEO para o destino
302 = redirecionamento temporário, o Google continua indexando o URL de origem
Uma migração de domínio requer 301 em cada URL, não apenas na raiz
Os códigos 307 e 308 existem para preservar o método HTTP (POST, PUT)
CaptainDNS Redirect Hosting gerencia os 301/302 com HTTPS automático

Mudar de nome de domínio, fundir dois sites, passar de HTTP para HTTPS: todas estas operações dependem dos redirecionamentos HTTP. Mal configurados, provocam uma perda de 30 a 50 % do tráfego orgânico nas semanas seguintes à migração. Bem configurados, transmitem a totalidade da sua autoridade SEO para o novo destino.

A pergunta "devo usar um 301 ou um 302?" surge constantemente nos fóruns SEO e nas discussões entre desenvolvedores. A resposta depende do contexto, mas as consequências de uma má escolha são reais: o Google indexa o URL errado, o PageRank se dilui, os backlinks perdem o seu valor. Segundo um estudo da Moz realizado sobre 30 000 domínios, 12 % das migrações de domínio utilizam redirecionamentos 302 em vez de 301, causando uma perda média de tráfego orgânico duas vezes superior às migrações corretamente configuradas.

Este guia cobre os 4 códigos de redirecionamento HTTP, explica em detalhe o impacto SEO de cada um e fornece uma checklist completa para realizar uma migração de domínio bem-sucedida. Quer você esteja gerenciando um site institucional ou um portal de 50 000 páginas, os princípios são os mesmos.

Última precisão: este guia trata dos redirecionamentos do lado do servidor (códigos de estado HTTP). Os redirecionamentos JavaScript ou as tags meta refresh não são abordados aqui porque apresentam problemas fundamentais para o rastreamento e a indexação. Para os casos de uso de marketing (vanity URLs, link tracking, códigos QR), um guia complementar está disponível na seção "Guias relacionados" no final do artigo.

Configure seus redirecionamentos agora

Criar um redirecionamento Testar propagação DNS

Os 4 códigos de redirecionamento HTTP

O protocolo HTTP define quatro códigos de redirecionamento principais. Cada um comunica uma intenção diferente ao navegador e aos mecanismos de busca.

301 Moved Permanently

O código 301 significa que o recurso foi movido de forma permanente para um novo URL. O servidor responde com um cabeçalho Location contendo o destino.

HTTP/1.1 301 Moved Permanently
Location: https://captaindns.com/br/tools

Comportamento do navegador: o navegador armazena em cache o redirecionamento e redireciona automaticamente as futuras requisições para o destino, sem passar novamente pelo servidor de origem. Esse cache persiste mesmo depois de fechar o navegador.

Definido na RFC 7231, seção 6.4.2, o código 301 permite aos clientes HTTP transformar uma requisição POST em GET durante o redirecionamento. Este comportamento, herdado das primeiras implementações HTTP, é a razão pela qual o código 308 foi criado.

302 Found

O código 302 significa que o recurso está temporariamente disponível em outra URL. O servidor responde da mesma forma:

HTTP/1.1 302 Found
Location: https://captaindns.com/br/maintenance

Comportamento do navegador: o navegador não armazena em cache o redirecionamento. Cada requisição passa novamente pelo servidor de origem, que pode retornar um destino diferente ou deixar de redirecionar.

Definido na RFC 7231, seção 6.4.3, o código 302 tem uma história complicada. Em HTTP/1.0, significava "Moved Temporarily". Os navegadores transformavam historicamente as requisições POST em GET durante um 302, o que não correspondia à especificação. O código 303 (See Other) foi criado para formalizar este comportamento, e o código 307 para preservar o método HTTP.

307 Temporary Redirect

O código 307 é o equivalente estrito do 302, mas com uma garantia: o método HTTP é preservado. Se o cliente envia um POST, o redirecionamento reenvia um POST para o destino.

HTTP/1.1 307 Temporary Redirect
Location: https://captaindns.com/api/v2/submit

Este código está definido na RFC 7231, seção 6.4.7. É utilizado principalmente para formulários e API REST onde a preservação do método é crítica. Para os redirecionamentos de páginas web clássicas (GET), a diferença entre 302 e 307 é nula.

308 Permanent Redirect

O código 308 é o equivalente estrito do 301, mas com a mesma garantia que o 307: o método HTTP é preservado.

HTTP/1.1 308 Permanent Redirect
Location: https://captaindns.com/api/v2/submit

Definido na RFC 7238, o código 308 é a escolha correta para os redirecionamentos permanentes de API onde o método HTTP deve ser conservado. Para os redirecionamentos de páginas web (GET), 301 e 308 são funcionalmente idênticos.

Tabela comparativa dos 4 códigos

Código	Tipo	Método HTTP preservado?	Cache do navegador?	Transferência SEO?
301	Permanente	Não (POST pode virar GET)	Sim	Sim (100 %)
302	Temporário	Não (POST pode virar GET)	Não	Parcial (Google indexa a origem)
307	Temporário	Sim	Não	Parcial (mesmo comportamento que 302)
308	Permanente	Sim	Sim	Sim (mesmo comportamento que 301)

Na prática, para os redirecionamentos de páginas web (requisições GET), apenas os códigos 301 e 302 são pertinentes. Os códigos 307 e 308 estão reservados para contextos técnicos onde a preservação do método HTTP é necessária.

Tabela comparativa dos 4 códigos de redirecionamento HTTP (301, 302, 307, 308) mostrando as diferenças de tipo, método HTTP, cache e transferência SEO

Redirecionamentos do lado do servidor vs JavaScript

Os códigos 301, 302, 307 e 308 são redirecionamentos do lado do servidor: o servidor envia um cabeçalho HTTP Location e o navegador o segue imediatamente. Mas também existem redirecionamentos do lado do cliente, implementados em JavaScript ou através de uma tag meta refresh.

Redirecionamentos do lado do servidor (HTTP): o Google os detecta e os segue imediatamente durante o rastreamento. A transferência de sinais SEO é confiável e rápida. É o método recomendado pelo Google Search Central para qualquer mudança de URL.

Redirecionamentos JavaScript (window.location, window.location.replace): o Google deve primeiro baixar a página HTML, executar o JavaScript no seu motor de renderização (baseado em Chromium), e depois descobrir o redirecionamento. Este processo adiciona um atraso significativo. O Google classifica este método como último recurso, a utilizar apenas quando o redirecionamento do lado do servidor é impossível.

Redirecionamentos meta refresh (<meta http-equiv="refresh" content="0;url=...">): o Google pode segui-los, mas os desaconselha formalmente. O comportamento é semelhante a um redirecionamento JavaScript: a página deve ser baixada e analisada antes de o redirecionamento ser detectado.

Método	Detecção pelo Google	Transferência SEO	Caso de uso
Do lado do servidor (301/302)	Imediata	Completa (301) ou parcial (302)	Migrações, mudanças de URL
JavaScript	Após a renderização	Incerta, frequentemente parcial	SPA (Single Page Applications)
Meta refresh	Após o download	Desaconselhada pelo Google	Nenhum caso recomendado

O risco principal dos redirecionamentos JavaScript: se a renderização da página falhar (erro JS, timeout, recurso bloqueado), o Google simplesmente não vê o redirecionamento. A página de origem permanece indexada, o destino é ignorado. Para as Single Page Applications (SPA) onde o redirecionamento do lado do servidor é tecnicamente impossível, o JavaScript é o único recurso, mas então é necessário verificar regularmente que o Googlebot detecta corretamente o redirecionamento (através da ferramenta de inspeção de URL na Search Console).

Como tratam os navegadores os redirecionamentos?

Quando um navegador recebe um código de redirecionamento, faz automaticamente uma nova requisição para o URL indicado no cabeçalho Location. Este processo é transparente para o usuário: nota apenas um ligeiro atraso de carregamento.

Para os redirecionamentos 301, o navegador armazena a correspondência em um cache local. As visitas seguintes ao antigo URL são redirecionadas diretamente pelo navegador, sem contatar o servidor de origem. Esse cache é persistente: sobrevive ao fechamento do navegador e só é esvaziado por uma limpeza manual do cache ou pela expiração definida pelos cabeçalhos Cache-Control.

Para os redirecionamentos 302, o navegador não armazena em cache a correspondência. Cada visita ao antigo URL dispara uma requisição ao servidor de origem, que pode responder de forma diferente a cada vez. Este comportamento é o que torna o 302 adequado para redirecionamentos dinâmicos (geolocalização, testes A/B, campanhas temporárias).

Esta diferença de cache tem um impacto direto no desempenho. Um 301 economiza uma requisição de rede a cada visita posterior. Um 302 adiciona sistematicamente a latência de uma ida e volta HTTP adicional.

Outros códigos de estado HTTP que você deve conhecer

Três códigos HTTP são por vezes confundidos com os redirecionamentos:

200 OK: a página existe e retorna conteúdo. Não há redirecionamento. Se a página mostra "Você vai ser redirecionado...", trata-se de um redirecionamento do lado do cliente (JavaScript ou meta refresh), não de um redirecionamento HTTP.
404 Not Found: a página não existe. Se você excluir uma página sem configurar um redirecionamento, os visitantes e o Googlebot recebem um 404. Os backlinks para essa página perdem todo o seu valor.
410 Gone: a página foi excluída definitivamente e não será substituída. O Google trata o 410 como um sinal forte para remover a página do índice. Use o 410 quando não existe uma página de destino pertinente para um redirecionamento.

301 vs 302: impacto SEO detalhado

Esta é a seção mais importante deste guia. A diferença técnica entre 301 e 302 parece menor (permanente vs temporário), mas as consequências SEO são significativas. Compreender estas diferenças é essencial antes de configurar qualquer redirecionamento.

Transferência de PageRank e autoridade

O PageRank é a pontuação de autoridade que o Google atribui a cada página em função dos links de entrada. Quando um site A faz um link para a sua página, transmite a ela uma fração do seu próprio PageRank.

Com um 301: o Google transfere 100 % do PageRank do antigo URL para o novo. Nem sempre foi assim. Antes de 2016, o Google aplicava uma penalização de 15 % sobre o PageRank transmitido através de um 301. Desde uma atualização confirmada por Gary Illyes da equipe Google Search, esta penalização foi eliminada. Um 301 transfere agora a totalidade da autoridade.

Com um 302: o Google não transfere o PageRank para o destino. A lógica é simples: se o redirecionamento é temporário, o URL de origem deve voltar. O Google conserva portanto a autoridade no URL de origem. O problema surge quando um 302 permanece ativo durante meses ou anos. O Google acaba tratando-o como um 301 de fato, mas o prazo é imprevisível e o período de transição causa uma perda de posicionamento.

Indexação e canonicalização

A escolha 301 vs 302 determina qual URL o Google mostra nos seus resultados:

Com um 301: o Google remove o antigo URL do seu índice e indexa o destino. Os resultados de pesquisa mostram o novo URL. Este processo demora geralmente de alguns dias a algumas semanas conforme a frequência de rastreamento.

Com um 302: o Google continua indexando o URL de origem e o exibe nos seus resultados. O destino é conhecido pelo Google, mas não é considerado como a versão canônica. Resultado: os seus visitantes veem o antigo URL no Google, clicam, são redirecionados para a nova página, mas os sinais SEO (backlinks, antiguidade, autoridade) permanecem associados ao antigo URL.

Cache do navegador e contagem de visitas

O 301 é armazenado em cache pelo navegador. Após a primeira visita, o navegador redireciona diretamente para o destino sem contatar o servidor de origem. Consequência: você não pode rastrear o número de redirecionamentos, pois as visitas seguintes não passam mais pelo seu servidor.

O 302 não é armazenado em cache. Cada visita passa pelo servidor de origem, que pode contar as requisições, registrar as informações do visitante e até mudar o destino em tempo real. Por isso as vanity URLs e os links de tracking usam 302.

Cadeias de redirecionamento: a perda silenciosa

Uma cadeia de redirecionamento ocorre quando um URL redireciona para um segundo URL, que por sua vez redireciona para um terceiro, e assim por diante. Cada salto na cadeia consome uma requisição de rastreamento e adiciona latência.

O Google segue as cadeias de redirecionamento, mas com limites. John Mueller confirmou que o Googlebot segue geralmente 5 redirecionamentos antes de desistir. Acima desse limite, a página final não é rastreada nem indexada.

Mesmo abaixo de 5 saltos, cada redirecionamento intermediário dilui potencialmente o sinal SEO. A recomendação é limitar qualquer cadeia a 2 saltos no máximo: a origem redireciona para o destino final, ponto.

Você pode verificar a presença de cadeias de redirecionamento nas suas páginas com o Page Crawl Checker.

Mitos vs realidade

Mito: o 302 penaliza o SEO. Realidade: o 302 não penaliza diretamente o SEO. Simplesmente não foi concebido para transferir a autoridade. O Google não aplica sanção, mas indexa o URL errado e conserva a autoridade no lugar errado. O resultado parece uma penalização, mas é um problema de configuração.

Mito: um 301 faz perder PageRank. Realidade: desde 2016, um 301 transfere 100 % do PageRank. Esta informação foi confirmada pelo Google em múltiplas ocasiões. A antiga penalização de 15 % não existe mais.

Mito: o Google trata os 302 de longa duração como 301. Realidade: é parcialmente verdade. O Google pode, após um longo período, decidir tratar um 302 como um 301. Mas o prazo é imprevisível (semanas, meses) e durante a transição, o seu SEO sofre. Não conte com este comportamento. Use o código correto desde o início.

Mito: os redirecionamentos do lado do cliente (JavaScript, meta refresh) são equivalentes. Realidade: não. O Google pode seguir os redirecionamentos JavaScript, mas com um atraso adicional (a renderização da página deve ser efetuada pelo motor de renderização). Os meta refresh são desaconselhados pelo Google. Apenas os redirecionamentos do lado do servidor (301, 302, 307, 308) são processados de forma imediata e confiável.

Mito: os 301 são instantâneos para o SEO. Realidade: não. Após configurar um 301, o Google precisa rastrear novamente o antigo URL, descobrir o redirecionamento e depois atualizar o seu índice. Este processo demora de alguns dias a várias semanas conforme a frequência de rastreamento do seu site. As páginas com muito tráfego e muitos backlinks são rastreadas mais rapidamente do que as páginas profundas com poucas visitas.

HTTPS e redirecionamentos: um pré-requisito indispensável

O servidor que hospeda os redirecionamentos deve obrigatoriamente suportar HTTPS. Se um backlink aponta para https://antigo.captaindns.com/page e o servidor de redirecionamento só suporta HTTP, o navegador mostrará um erro de certificado em vez do redirecionamento.

Com o CaptainDNS Redirect Hosting, o certificado TLS é gerado e renovado automaticamente via Let's Encrypt. Não é necessária nenhuma configuração manual. O servidor de redirecionamento responde em HTTPS em todos os domínios configurados.

Para as configurações manuais no seu próprio servidor (Nginx, Apache, Caddy), certifique-se de que:

O certificado TLS cubra todos os domínios de origem (antigo domínio, variantes www, subdomínios).
A renovação do certificado esteja automatizada (Let's Encrypt com certbot ou acme.sh).
Os redirecionamentos HTTP para HTTPS estejam configurados além dos redirecionamentos de domínio.

301, canonical ou ambos? Escolher a abordagem correta

Os redirecionamentos 301 e as tags rel=canonical são duas ferramentas que servem um objetivo semelhante: indicar ao Google qual URL é a versão preferida. Mas funcionam de forma muito diferente e não se utilizam nas mesmas situações.

Quando usar um 301 em vez de um canonical tag?

A distinção é simples: o 301 redireciona fisicamente o visitante, o canonical não.

Um redirecionamento 301 remove o acesso ao URL de origem. O visitante que digita o antigo URL é enviado automaticamente para o destino. A antiga página não fica mais acessível. É a escolha correta quando o URL de origem não tem mais razão de existir.

Um canonical tag (rel=canonical) deixa ambos os URLs acessíveis. O visitante ainda pode acessar o URL de origem e ver o seu conteúdo. O canonical é uma indicação ao Google: entre estas duas páginas com conteúdo idêntico ou semelhante, esta é a que você deve indexar. O Google pode seguir esta indicação ou ignorá-la.

Critério	Redirecionamento 301	Canonical tag
O visitante é redirecionado?	Sim	Não, ambas as páginas são acessíveis
Sinal para o Google	Diretiva forte (obrigatória)	Indicação (sugestão, pode ser ignorada)
Ambos os URLs existem?	Não, apenas o destino é acessível	Sim, ambos permanecem online
Transferência de PageRank	100 % para o destino	O Google consolida os sinais no URL canônico
Caso de uso principal	URL excluído, migração, mudança definitiva	Conteúdo duplicado, parâmetros de URL, versões paginadas

Em resumo: se o antigo URL não serve mais, use um 301. Se o antigo URL tem uma razão de existir (versão para impressão, página com parâmetros de ordenação, variante regional), use um canonical.

Combinar 301 e canonical

Após uma migração de domínio, o Google recomenda usar ambos os sinais juntos quando possível. O 301 redireciona fisicamente os visitantes e os bots. O canonical tag na página de destino reforça o sinal confirmando que este URL é a versão preferida.

Concretamente, após configurar os seus redirecionamentos 301 do antigo domínio para o novo, adicione em cada página de destino um canonical tag que aponte para ela mesma:

<link rel="canonical" href="https://captaindns.com/br/tools" />

Este duplo sinal é particularmente útil quando o seu conteúdo é acessível através de múltiplos caminhos (antigo domínio redirecionado, variante www, versão HTTP). O Google recebe uma mensagem coerente de todas as fontes: o destino é efetivamente o URL canônico.

A combinação 301 + canonical não é obrigatória, mas acelera a convergência no índice do Google e reduz o risco de o Google escolher o URL errado como versão canônica durante o período de transição.

Quando usar um 301?

O 301 é a escolha padrão para todo redirecionamento definitivo. Estes são os casos de uso mais frequentes.

Migração de domínio definitiva

Você muda de nome de domínio. O antigo domínio não será mais usado para conteúdo. Cada URL do antigo domínio deve ser redirecionado com 301 para o seu equivalente no novo domínio.

antigo-site.captaindns.com/blog/article-1
→ 301 → captaindns.com/br/blog/article-1

Consolidação de vários domínios

Você possui vários domínios (variantes ortográficas, extensões de país, domínios de marketing) e quer concentrar a autoridade SEO em um só.

captaindns.fr → 301 → captaindns.com
captaindns.de → 301 → captaindns.com

Mudança de URL permanente

Redesenho do site, mudança de CMS, nova arquitetura de URLs. Os antigos URLs não existem mais e não voltarão.

captaindns.com/products/dns-check
→ 301 → captaindns.com/br/tools/dns/test-propagation

Passagem de HTTP para HTTPS

A passagem de HTTP para HTTPS é permanente. Todos os URLs HTTP devem ser redirecionados com 301 para o seu equivalente HTTPS.

http://captaindns.com/br/tools
→ 301 → https://captaindns.com/br/tools

Naked domain para www (ou vice-versa)

Você escolhe uma versão canônica do seu domínio. A outra versão redireciona com 301.

www.captaindns.com → 301 → captaindns.com

ou vice-versa:

captaindns.com → 301 → www.captaindns.com

Tabela recapitulativa: casos de uso 301

Situação	Exemplo	Por que 301?
Migração de domínio	antigo.captaindns.com para captaindns.com	O domínio de origem não servirá mais conteúdo
Consolidação multi-domínio	captaindns.fr para captaindns.com	Concentrar a autoridade SEO em um único domínio
Mudança de URL (redesenho)	/products/ para /br/tools/	A antiga estrutura de URL é abandonada
HTTP para HTTPS	http:// para https://	A passagem para HTTPS é definitiva
www vs sem www	www.captaindns.com para captaindns.com	Uma única versão canônica do domínio

Quando usar um 302?

O 302 é a escolha correta quando o redirecionamento é temporário: você planeja restaurar o URL de origem ao seu estado original.

Campanhas de marketing temporárias

Você cria uma vanity URL para uma campanha limitada no tempo. O redirecionamento será desativado no final da campanha.

promo.captaindns.com → 302 → captaindns.com/br/pricing
(durante a campanha de março 2026)

Testes A/B

Você redireciona uma fração do tráfego para uma variante de página, para testar um novo design ou um novo conteúdo. O redirecionamento será retirado após o teste terminar.

Manutenção planejada

O seu site está em manutenção. Você redireciona temporariamente o tráfego para uma página de informação. O site voltará ao seu estado normal após a manutenção.

captaindns.com/br/tools → 302 → captaindns.com/br/maintenance

Geolocalização e detecção de idioma

Você redireciona os visitantes para uma versão localizada do seu site em função do endereço IP deles ou do idioma do navegador. O redirecionamento é condicional e não deve ser armazenado em cache, pois o mesmo usuário pode visitar de outro país.

captaindns.com → 302 → captaindns.com/br/ (visitante brasileiro)
captaindns.com → 302 → captaindns.com/en/ (visitante inglês)

Redirecionamentos condicionais (móvel/desktop)

Você redireciona os visitantes móveis para uma versão dedicada. Essa prática é cada vez menos comum (o design responsivo a substituiu em grande parte), mas ainda existe em alguns sites.

Tabela recapitulativa: casos de uso 302

Situação	Exemplo	Por que 302?
Campanha de marketing	promo.captaindns.com para landing page	Redirecionamento temporário, será desativado
Teste A/B	50 % do tráfego para variante B	Teste limitado no tempo
Manutenção	Site para página de manutenção	O site voltará
Geolocalização	Raiz para versão local	Condicional, não deve ser armazenado em cache
Redirecionamento móvel	Site para versão móvel	Condicional conforme o dispositivo

Migração de domínio: a checklist completa

Checklist de migração de domínio em 5 etapas: auditoria de URLs, configuração de redirecionamentos 301, apontamento DNS, Search Console e monitoramento durante 90 dias

A migração de domínio é a operação mais arriscada em SEO. Esta é a checklist completa para minimizar as perdas.

Antes da migração: auditoria e inventário

1. Listar todos os URLs indexados

Exporte a lista completa dos URLs indexados a partir do Google Search Console (relatório "Páginas"). Complemente com um rastreamento completo do seu site (Screaming Frog, Sitebulb ou qualquer outro crawler).

O objetivo: ter um inventário exaustivo de cada URL que recebe tráfego ou backlinks.

2. Identificar as páginas de alto valor

Classifique os seus URLs por tráfego orgânico (Google Analytics) e por número de backlinks (Ahrefs, Moz, Semrush). Os 20 % de páginas que geram 80 % do tráfego são a sua prioridade absoluta. Qualquer erro de redirecionamento nestas páginas terá um impacto imediato e visível.

3. Criar o plano de redirecionamento 1:1

Cada URL do antigo domínio deve corresponder a um URL no novo domínio. Sem redirecionamento genérico para a homepage. Uma tabela simples é suficiente:

URL de origem	URL de destino	Estado
antigo.captaindns.com/	captaindns.com/br/	A configurar
antigo.captaindns.com/blog/article-1	captaindns.com/br/blog/article-1	A configurar
antigo.captaindns.com/contact	captaindns.com/br/contact	A configurar

Se algumas páginas não tiverem equivalente no novo domínio, redirecione-as para a página mais pertinente (não a homepage por padrão).

4. Verificar o conteúdo do novo domínio

Antes de ativar os redirecionamentos, certifique-se de que cada página de destino existe e funciona. Um redirecionamento 301 para uma página 404 é pior do que não ter redirecionamento: o Google vê uma página de erro e desclassifica o URL.

5. Fazer backup dos dados existentes

Antes de qualquer modificação, exporte uma cópia completa:

Export CSV de todos os URLs indexados a partir da Search Console
Export das posições de pesquisa (Semrush, Ahrefs ou outra ferramenta de acompanhamento)
Export dos backlinks do antigo domínio
Captura de tela das estatísticas de tráfego orgânico dos últimos 90 dias

Estes dados servirão de referência para medir o impacto da migração e detectar anomalias após a mudança.

Configurar os redirecionamentos 301

6. Implementar os redirecionamentos em cada URL

A regra fundamental: cada URL deve ser redirecionado individualmente. Redirecionar apenas a raiz (antigo.captaindns.com para captaindns.com) não é suficiente. As páginas profundas, os artigos do blog, as fichas de produto devem ter cada uma o seu próprio redirecionamento.

Se o seu novo site conserva a mesma estrutura de URL, você pode usar uma regra de path forwarding. O caminho do antigo URL é automaticamente adicionado ao destino:

antigo.captaindns.com/* → 301 → captaindns.com/*

Com o CaptainDNS Redirect Hosting, ative a opção "Path forwarding" para transmitir automaticamente o caminho do URL de origem para o destino.

7. Gerenciar as 4 variantes de cada URL

Cada URL existe potencialmente em 4 versões:

http://antigo.captaindns.com/page
https://antigo.captaindns.com/page
http://www.antigo.captaindns.com/page
https://www.antigo.captaindns.com/page

As 4 versões devem chegar ao mesmo destino. Esquecer uma variante significa deixar backlinks sem redirecionamento.

Verificar o DNS

8. Configurar os registros DNS

Para que os redirecionamentos funcionem, o domínio de origem deve resolver para o servidor de redirecionamento. Se você usa o CaptainDNS Redirect Hosting, crie um registro CNAME ou A/AAAA apontando para o serviço de redirecionamento.

9. Verificar a propagação DNS

Após modificar os registros DNS, verifique que a propagação é efetiva em todas as regiões com o teste de propagação DNS. A propagação completa pode demorar de alguns minutos a 48 horas conforme o TTL anterior.

Google Search Console: ferramenta Change of Address

10. Declarar a mudança no Google Search Console

O Google fornece uma ferramenta dedicada na Search Console: "Change of Address" (Configurações > Mudança de endereço). Esta ferramenta:

Verifica que os redirecionamentos 301 estão corretamente configurados
Acelera a atualização do índice do Google
Transfere os sinais do antigo domínio para o novo

Pré-requisito: ambos os domínios (antigo e novo) devem estar verificados no Google Search Console.

11. Enviar o novo sitemap

Envie o sitemap XML do novo domínio no Google Search Console. Verifique que todos os URLs do sitemap retornam um código 200. Remova o sitemap do antigo domínio depois que a migração estiver concluída e o índice atualizado.

Monitoramento pós-migração

12. Supervisionar o tráfego orgânico (30/60/90 dias)

Uma queda temporária do tráfego orgânico (10 a 20 %) é normal nas 2 a 4 semanas após uma migração. Acima desse valor, há um problema. Supervisione:

Semana 1-2: o Google começa a rastrear o novo domínio. O tráfego pode cair de 10 a 30 %.
Semana 3-4: o tráfego deverá estabilizar e começar a subir.
Mês 2-3: o tráfego deverá voltar ao nível pré-migração, ou até ultrapassá-lo se o novo site for de melhor qualidade.

13. Verificar os erros na Search Console

Consulte o relatório "Páginas" no Google Search Console para identificar erros 404, erros de redirecionamento e problemas de indexação. Corrija imediatamente os URLs que retornam erros.

14. Monitorar os backlinks

Verifique que os backlinks do antigo domínio são corretamente redirecionados para o novo. Use o Ahrefs ou uma ferramenta semelhante para identificar os backlinks que retornam um erro 404 em vez de um redirecionamento 301.

15. Verificar as posições de pesquisa

Acompanhe as suas palavras-chave estratégicas em uma ferramenta de acompanhamento de posições (Semrush, Ahrefs, Sistrix). Compare as posições antes e depois da migração. Uma palavra-chave que cai mais de 10 posições após 4 semanas indica provavelmente um erro de redirecionamento na página correspondente.

Crie uma tabela de acompanhamento com as suas 50 palavras-chave mais importantes:

Palavra-chave	Posição antes	Posição D+7	Posição D+30	Posição D+90
redirecionamento dns	5	8	6	4
teste propagação dns	3	7	4	3
verificação email spf	12	18	14	11

Uma subida progressiva é sinal de que a migração está correndo bem. Uma estagnação em D+30 requer investigação (redirecionamentos ausentes, conteúdo modificado, problemas técnicos).

Duração de manutenção dos redirecionamentos

16. Durante quanto tempo manter os redirecionamentos?

O Google recomenda manter os redirecionamentos 301 de forma permanente se possível. Na prática:

Mínimo 6 meses: abaixo disso, o Google não teve tempo de rastrear novamente todas as suas páginas e atualizar o seu índice.
Recomendado 1 ano: a grande maioria dos sinais SEO terá sido transferida.
Ideal: permanente: enquanto o antigo domínio estiver ativo, os redirecionamentos devem funcionar. Os backlinks em sites de terceiros continuarão apontando para o antigo domínio durante anos.

Se você deixar o antigo domínio expirar, os redirecionamentos obviamente deixam de funcionar. Os backlinks que apontavam para o antigo domínio retornam um erro DNS. Por isso é recomendável conservar o antigo domínio e renovar o seu registro o maior tempo possível.

Um risco adicional existe: se o seu antigo domínio expirar e um terceiro o comprar, pode recuperar os backlinks que ainda apontavam para o antigo domínio. No melhor dos casos, mostra conteúdo sem relação. No pior, explora a reputação dos seus antigos backlinks para hospedar conteúdo malicioso ou spam. Renove o registro do seu antigo domínio durante pelo menos 3 anos após a migração.

Planejamento semana a semana

Uma migração de domínio é preparada com várias semanas de antecedência. Veja um calendário tipo para estruturar as etapas e evitar esquecimentos.

Semana	Ação	Verificação
S-4	Auditoria completa dos URLs, inventário de backlinks	Lista exaustiva exportada
S-3	Configurar os redirecionamentos 301 no servidor	Testar cada redirecionamento com curl
S-2	Declarar o novo domínio na Search Console	Verificação de propriedade validada
S-1	Últimos testes, backup do sitemap do antigo domínio	Todos os redirecionamentos funcionam
D-0	Ativar os redirecionamentos, enviar o Change of Address	Verificar as primeiras horas em tempo real
S+1	Monitorar a indexação e o tráfego diariamente	Search Console e Analytics consultados todos os dias
S+4	Primeiro balanço aos 30 dias	Comparação do tráfego antes e após a migração
S+8	Segundo balanço aos 60 dias	Estabilização esperada do tráfego orgânico
S+12	Balanço final aos 90 dias	Decisão: conservar ou ajustar os redirecionamentos

Este calendário é indicativo. Para os sites volumosos (vários milhares de páginas), preveja uma semana adicional para a auditoria e o mapeamento dos URLs.

Caso real: migração HTTP para HTTPS

A passagem de HTTP para HTTPS é a migração mais frequente. O Google considera HTTP e HTTPS como dois sites distintos. Cada URL HTTP deve ser redirecionado com 301 para o seu equivalente HTTPS.

O processo é idêntico a uma mudança de domínio clássica:

Obter um certificado TLS para o seu domínio (Let's Encrypt, ou qualquer outro fornecedor)
Configurar o servidor para responder em HTTPS
Redirecionar cada URL HTTP com 301 para HTTPS (não apenas a homepage)
Atualizar os links internos para apontar para os URLs HTTPS
Declarar a versão HTTPS no Google Search Console
Enviar o sitemap com os URLs HTTPS

Erro comum: redirecionar apenas a homepage HTTP para HTTPS e esquecer as páginas internas. Resultado: as páginas profundas permanecem acessíveis em HTTP, o Google considera-as como duplicados, e a autoridade SEO é fragmentada entre as duas versões.

Ponto importante: o Google Search Console trata HTTP e HTTPS como propriedades distintas. Você deve enviar ambas as versões (propriedade HTTP e propriedade HTTPS) para ter uma vista completa da indexação durante a transição. Use a ferramenta Change of Address para acelerar o processo.

Impacto no crawl budget e nos Core Web Vitals

Os redirecionamentos não afetam apenas a indexação e a transferência de autoridade. Também tem um impacto mensurável em dois aspectos técnicos do SEO: o orçamento de rastreamento e o desempenho de carregamento.

Crawl budget e redirecionamentos

O Googlebot dispõe de um orçamento de rastreamento limitado para cada site: um número de páginas que pode explorar em um intervalo de tempo determinado. Este orçamento depende do tamanho do site, da sua popularidade e da capacidade do servidor para responder rapidamente.

Cada redirecionamento consome uma unidade deste orçamento. Quando o Googlebot encontra um 301, conta uma requisição para o URL de origem (que retorna o redirecionamento) e depois uma segunda requisição para o destino. Uma cadeia de 3 redirecionamentos consome portanto 4 requisições para uma única página de conteúdo.

Para os sites pequenos (algumas centenas de páginas), o impacto é negligenciável. Para os sites volumosos com milhares de redirecionamentos ativos, o consumo de orçamento de rastreamento pode se tornar significativo. O Googlebot gasta tempo a seguir redirecionamentos em vez de rastrear conteúdo novo.

Recomendações:

Minimize o número de redirecionamentos nas páginas de alto tráfego e alto valor SEO
Elimine as cadeias de redirecionamentos apontando diretamente para o destino final
Após uma migração, uma vez atualizado o índice (6 a 12 meses), os redirecionamentos consomem menos orçamento de rastreamento pois o Googlebot aprende progressivamente os novos URLs

Impacto nos Core Web Vitals

Os Core Web Vitals são as métricas de desempenho do usuário medidas pelo Google: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift). Estas métricas influenciam o posicionamento desde 2021.

Cada redirecionamento adiciona uma ida e volta na rede (RTT) entre o navegador e o servidor. Na prática, isto representa de 100 a 300 ms adicionais por salto, conforme a latência de rede e a localização geográfica do visitante.

Impacto por métrica:

LCP: diretamente afetado. O tempo de carregamento do conteúdo principal aumenta de 100 a 300 ms por redirecionamento. Em móvel com uma conexão lenta, o impacto pode ultrapassar os 500 ms por salto.
CLS: nenhum impacto. Os redirecionamentos ocorrem antes da exibição da página, não causam deslocamentos visuais.
INP: nenhum impacto. Os redirecionamentos não afetam a reatividade da página uma vez carregada.

Boa notícia: os redirecionamentos 301 armazenados em cache pelo navegador não tem nenhum impacto nos Core Web Vitals após a primeira visita. O navegador redireciona localmente, sem ida e volta na rede. E um argumento adicional a favor dos 301 face aos 302 para os redirecionamentos permanentes.

Para medir o impacto real dos redirecionamentos nos seus Core Web Vitals, use o Chrome DevTools (aba Performance) ou os dados de campo no Google Search Console (relatório Core Web Vitals).

Erros comuns que destroem o SEO

Usar 302 em vez de 301 para uma migração

É o erro mais frequente. Um desenvolvedor configura redirecionamentos 302 "temporários" para uma migração definitiva. Resultado: o Google continua indexando o antigo domínio, o PageRank não é transferido e o novo domínio parte do zero em termos de autoridade.

A correção é simples: mude todos os redirecionamentos 302 para 301. O efeito não é imediato (o Google precisa rastrear os URLs novamente), mas a transferência de autoridade acabará acontecendo.

Redirecionar todos os URLs para a homepage

Você redireciona antigo.captaindns.com/blog/article-1, antigo.captaindns.com/blog/article-2 e antigo.captaindns.com/contact para captaindns.com. O Google considera esses redirecionamentos como soft 404: o conteúdo da página de destino não corresponde ao que o antigo URL prometia.

Resultado: o Google ignora estes redirecionamentos e desclassifica os URLs. Os backlinks que apontavam para os seus artigos do blog perdem o seu valor, pois redirecionam para uma página sem relação.

A solução: um redirecionamento 1:1. Cada antigo URL redireciona para a página equivalente no novo domínio. Se uma página não tiver equivalente exato, redirecione-a para a página tematicamente mais próxima. Por exemplo, um artigo de blog excluído pode ser redirecionado para um artigo relacionado que trate o mesmo tema, ou para a página de categoria correspondente.

Cadeias de redirecionamentos

Situação típica: durante uma primeira migração, site-v1.captaindns.com foi redirecionado para site-v2.captaindns.com. Durante uma segunda migração, site-v2.captaindns.com foi redirecionado para captaindns.com. Resultado: uma cadeia de 3 saltos.

site-v1.captaindns.com → 301 → site-v2.captaindns.com → 301 → captaindns.com

Cada salto adiciona latência e consome uma requisição de rastreamento. Acima de 5 saltos, o Googlebot desiste. Mesmo com 3 saltos, o sinal SEO se dilui.

Corrija atualizando os antigos redirecionamentos para apontar diretamente para o destino final:

site-v1.captaindns.com → 301 → captaindns.com
site-v2.captaindns.com → 301 → captaindns.com

Ciclos de redirecionamento

Um ciclo de redirecionamento ocorre quando o URL A redireciona para o URL B, que redireciona para o URL A. O navegador mostra o erro ERR_TOO_MANY_REDIRECTS. O crawler do Google desiste imediatamente.

Os ciclos são frequentemente causados por conflitos entre regras de redirecionamento. Exemplos clássicos:

O servidor redireciona http para https, e um plugin redireciona https para http.
O servidor redireciona www para sem www, e o CDN redireciona sem www para www.
Duas regras de redirecionamento se sobrepõem no arquivo .htaccess ou na configuração do Nginx.

A solução: teste cada URL em um navegador em modo anônimo e verifique os cabeçalhos de resposta com curl -I ou o Page Crawl Checker.

Esquecer as variantes www, sem www, HTTP, HTTPS

Um site acessível através de 4 URLs diferentes (http://, https://, http://www., https://www.) deve redirecionar as 3 variantes não canônicas para a versão escolhida.

Esquecer uma variante significa que os backlinks que apontam para essa versão não são redirecionados. Devolvem um erro ou uma página não canônica que o Google pode indexar como duplicado.

Verifique sistematicamente as 4 combinações para cada domínio implicado na migração.

Veja um exemplo concreto de teste para um domínio:

curl -I http://captaindns.com/br/tools       → deve retornar 301 para https://captaindns.com/br/tools
curl -I http://www.captaindns.com/br/tools    → deve retornar 301 para https://captaindns.com/br/tools
curl -I https://www.captaindns.com/br/tools   → deve retornar 301 para https://captaindns.com/br/tools
curl -I https://captaindns.com/br/tools       → deve retornar 200 (URL canônico)

Excluir os redirecionamentos muito cedo

Algumas equipes excluem os redirecionamentos 301 após algumas semanas, pensando que o Google teve tempo de atualizar o seu índice. Na realidade, o Google não rastreia novamente todas as páginas no mesmo ritmo. As páginas profundas com poucos backlinks podem não ser rastreadas de novo antes de vários meses.

Além disso, os backlinks em sites de terceiros estão fora do seu controle. Um artigo de blog publicado em 2020 que faz um link para o seu antigo domínio continuará gerando cliques durante anos. Se o redirecionamento for excluído, esses visitantes chegam a um erro 404 ou, pior, a um domínio comprado por um terceiro.

Não monitorar após a migração

A migração está implementada, os redirecionamentos funcionam, o sitemap foi enviado. Trabalho terminado? Não. Sem monitoramento, você não vai detectar os problemas que aparecem nas semanas seguintes:

Páginas 404 no novo domínio (conteúdo excluído ou URL mal configurado)
Redirecionamentos quebrados (certificado expirado, servidor de redirecionamento fora do ar)
Indexação bloqueada (robots.txt muito restritivo no novo domínio)
Queda anormal do tráfego em certas seções do site

Consulte o Google Search Console todas as semanas durante os 3 primeiros meses. Configure alertas sobre quedas significativas de tráfego no Google Analytics.

Ignorar os emails e newsletters que contêm links para o antigo domínio

Os seus emails de marketing, as newsletters arquivadas e os documentos PDF contêm links para o antigo domínio. Esses links continuarão sendo clicados durante meses, até anos. Se os redirecionamentos não estiverem implementados, os seus assinantes chegam a erros.

Faça o inventário de todos os canais que difundem links para o seu domínio: assinaturas de email, templates de newsletters, folhetos PDF, apresentações PowerPoint, perfis de redes sociais. Atualize os links quando possível, mas conte com os redirecionamentos para tudo o que você não pode modificar (emails já enviados, PDF já baixados).

Não se esqueça dos links nas aplicações móveis, nas integrações com parceiros e nos widgets incorporados em sites de terceiros. Essas fontes são frequentemente invisíveis nas auditorias de backlinks mas geram um tráfego significativo.

Usar redirecionamentos JavaScript em vez de redirecionamentos do servidor

Algumas equipes implementam redirecionamentos através de meta refresh ou window.location em vez de configurar redirecionamentos do lado do servidor. Esta escolha é problemática para o SEO.

Os redirecionamentos JavaScript requerem que o mecanismo de busca baixe a página HTML, execute o JavaScript e depois descubra o redirecionamento. O Google pode fazê-lo (o seu crawler utiliza um motor de renderização baseado em Chromium), mas com um atraso significativo. Os outros mecanismos de busca (Bing, Yandex) nem sempre seguem os redirecionamentos JavaScript.

Resultado concreto: durante o período de transição, a indexação é mais lenta, a transferência de sinais SEO é incerta e alguns bots simplesmente não veem o redirecionamento. Se você tem acesso à configuração do servidor (Nginx, Apache, Caddy, CDN), use sempre redirecionamentos HTTP do lado do servidor. Reserve o JavaScript para os casos em que o redirecionamento do servidor é tecnicamente impossível, como as Single Page Applications hospedadas em um CDN estático.

Não informar o Google via Search Console

A ferramenta Change of Address no Google Search Console foi concebida especificamente para acelerar as migrações de domínio no índice do Google. No entanto, muitas migrações são feitas sem usar essa ferramenta.

Sem o Change of Address, o Google precisa descobrir a migração sozinho, rastreando o antigo domínio e seguindo os redirecionamentos. Este processo pode demorar várias semanas, até vários meses para os sites volumosos. Entretanto, o antigo domínio permanece no índice e o novo domínio ainda não herda toda a autoridade.

Com o Change of Address, o Google recebe um sinal explícito: o antigo domínio migrou para o novo. O Google verifica que os redirecionamentos 301 estão implementados e depois acelera a atualização do seu índice. A ferramenta está disponível no Search Console, seção Configurações, depois Mudança de endereço. Ambos os domínios (antigo e novo) devem estar verificados na Search Console.

Casos de uso concretos com CaptainDNS

Migração de subdomínio para o domínio principal

Você hospeda o seu blog em blog.captaindns.com e decide transferi-lo para captaindns.com/br/blog para consolidar a autoridade SEO.

Configuração:

Crie um redirecionamento 301 com path forwarding em blog.captaindns.com
Destino: captaindns.com/br/blog
Ative a transferência de caminho para que blog.captaindns.com/article-1 redirecione para captaindns.com/br/blog/article-1

Resultado: os backlinks para o blog, que reforçavam unicamente o subdomínio, beneficiam agora o domínio principal. A autoridade de domínio se concentra em uma única entidade em vez de estar dispersa.

Pontos de atenção:

Atualize os links internos do site principal para apontar para os novos URLs (/br/blog/...) e não para o antigo subdomínio.
Atualize o sitemap para incluir os URLs do blog sob o domínio principal.
Se o blog tinha o seu próprio perfil na Search Console, declare a mudança de endereço.

Consolidação de vários subdomínios

Você possui shop.captaindns.com, docs.captaindns.com e status.captaindns.com, e decide reagrupar tudo sob captaindns.com.

Configuração:

Subdomínio	Destino	Path forwarding
shop.captaindns.com	captaindns.com/br/pricing	Sim
docs.captaindns.com	captaindns.com/br/docs	Sim
status.captaindns.com	captaindns.com/br/status	Não (página única)

Cada subdomínio é configurado em 301 com o CaptainDNS Redirect Hosting. O path forwarding preserva a estrutura de URL para os dois primeiros subdomínios.

Benefício SEO: em vez de repartir a autoridade de domínio por 4 entidades distintas (domínio principal + 3 subdomínios), toda a autoridade é consolidada no domínio principal. Os backlinks adquiridos pela documentação ou pela loja reforçam agora todo o site.

Armadilha a evitar: se os seus subdomínios tinham certificados TLS distintos, certifique-se de que o certificado do domínio principal cobre também os caminhos de destino. Um certificado wildcard (*.captaindns.com) simplifica o gerenciamento.

Redesenho com mudança de estrutura de URLs

Você passa de uma estrutura plana (captaindns.com/dns-check) para uma estrutura hierárquica (captaindns.com/br/tools/dns/test-propagation).

Este caso requer um plano de redirecionamento 1:1, pois a estrutura muda completamente. O path forwarding não é suficiente.

Antigo URL	Novo URL
captaindns.com/dns-check	captaindns.com/br/tools/dns/test-propagation
captaindns.com/spf-check	captaindns.com/br/tools/email-authentication/spf-check
captaindns.com/dkim-check	captaindns.com/br/tools/email-authentication/dkim-check

Crie um redirecionamento 301 individual para cada URL. Não há atalho possível.

Mudança de CMS com novos URLs

Você migra do WordPress (captaindns.com/2025/03/mon-article) para um CMS headless com URLs limpos (captaindns.com/br/blog/mon-article).

A mudança de CMS modifica frequentemente a estrutura dos URLs do blog. Os permalinks do WordPress incluem a data, o novo CMS usa um slug simples. Cada antigo URL do WordPress deve ser redirecionado com 301 para o novo URL.

captaindns.com/2025/03/mon-article → 301 → captaindns.com/br/blog/mon-article
captaindns.com/2025/04/autre-article → 301 → captaindns.com/br/blog/autre-article

Exporte a lista completa dos permalinks do WordPress e mapeie cada um para o novo URL antes de desativar o antigo CMS.

Dica: se o seu novo CMS usa os mesmos slugs que o WordPress (o título do artigo em minúsculas com hífens), você pode criar uma regra de reescrita que remove o prefixo de data e adiciona o prefixo /br/blog/. Isso reduz consideravelmente o trabalho de mapeamento para os sites com centenas de artigos.

Internacionalização e redirecionamento por idioma

Você lança versões localizadas do seu site. O URL /tools/dns-check passa a ser /br/tools/dns-check, /en/tools/dns-check, /de/tools/dns-check, etc.

Para os antigos URLs sem prefixo de idioma, duas abordagens:

Abordagem 1: redirecionamento 301 para o locale padrão

Redirecione os antigos URLs para a versão do idioma principal:

captaindns.com/tools/dns-check → 301 → captaindns.com/br/tools/dns-check

Fácil de configurar, mas os visitantes anglófonos que tinham um backlink para /tools/dns-check chegam à versão em português.

Abordagem 2: redirecionamento 302 com detecção de idioma

Redirecione os antigos URLs para a versão localizada em função do cabeçalho Accept-Language do navegador. Use um 302 porque o redirecionamento é condicional:

captaindns.com/tools/dns-check → 302 → captaindns.com/br/tools/dns-check (visitante BR)
captaindns.com/tools/dns-check → 302 → captaindns.com/en/tools/dns-check (visitante EN)

Mais complexo de configurar, mas oferece uma melhor experiência de usuário. Certifique-se de implementar as tags hreflang nas páginas de destino para ajudar o Google a compreender a estrutura multilíngue.

Plano de ação recomendado

Auditar os seus URLs existentes: exporte a lista de páginas indexadas a partir do Google Search Console e identifique as páginas de alto valor (tráfego, backlinks).
Escolher o código de redirecionamento correto: migração permanente = 301. Campanha temporária = 302. Em caso de dúvida, faça a pergunta: o antigo URL voltará algum dia? Se não, use um 301.
Criar o plano de redirecionamento 1:1: cada antigo URL deve corresponder a um URL de destino. Sem redirecionamento genérico para a homepage.
Configurar os redirecionamentos: use o Redirect Hosting CaptainDNS para criar os redirecionamentos 301/302 com HTTPS automático e transferência de caminho.
Verificar a propagação DNS: confirme que os registros DNS apontam para o servidor de redirecionamento com o teste de propagação DNS.
Declarar a mudança no Google Search Console: use a ferramenta "Change of Address" e envie o novo sitemap.
Monitorar durante 90 dias: acompanhe o tráfego orgânico, os erros de rastreamento e as posições na Search Console. Corrija imediatamente os problemas detectados.

Configure os seus redirecionamentos agora: use o Redirect Hosting CaptainDNS para criar redirecionamentos 301/302 com HTTPS automático e transferência de caminho.

FAQ

Qual é a diferença entre um redirecionamento 301 e 302?

O 301 é um redirecionamento permanente: indica aos navegadores e aos mecanismos de busca que o URL mudou definitivamente. O 302 é um redirecionamento temporário: indica que o URL atual está temporariamente acessível em outro endereço. A diferença principal para o SEO é que o 301 transfere a autoridade (PageRank) para o destino, enquanto o 302 conserva a autoridade no URL de origem.

Um redirecionamento 302 penaliza o SEO?

Não, o 302 não penaliza o SEO em sentido estrito. O Google não aplica sanção. O problema é que o Google continua indexando o URL de origem e não transfere a autoridade. Se você usar um 302 para uma migração permanente, o Google indexa o URL errado e o seu novo domínio não se beneficia dos backlinks. Não é uma penalização, mas o resultado é semelhante: perda de tráfego orgânico.

Durante quanto tempo é preciso manter os redirecionamentos após uma migração?

Mínimo 6 meses, recomendado 1 ano, ideal permanente. O Google precisa de tempo para rastrear novamente todas as suas páginas e atualizar o seu índice. Os backlinks em sites de terceiros continuarão apontando para o antigo domínio durante anos. Enquanto o antigo domínio estiver registrado, os redirecionamentos devem permanecer ativos.

O que acontece se usar um 302 em vez de um 301?

O Google continua indexando o antigo URL e não transfere o PageRank para o destino. O seu novo domínio não se beneficia da autoridade acumulada pelo antigo. Com o tempo, o Google pode acabar tratando o 302 como um 301, mas o prazo é imprevisível. A correção é substituir todos os 302 por 301. O Google rastreará os URLs novamente e atualizará o seu índice.

As cadeias de redirecionamento afetam o SEO?

Sim. Cada salto em uma cadeia de redirecionamento consome uma requisição de rastreamento e adiciona latência. O Googlebot segue geralmente até 5 redirecionamentos antes de desistir. Acima desse limite, a página final não é rastreada nem indexada. Mesmo abaixo de 5 saltos, o sinal SEO pode se diluir. Limite qualquer cadeia a 2 saltos no máximo e corrija os antigos redirecionamentos para apontar diretamente para o destino final.

Como verificar que um redirecionamento funciona corretamente?

Vários métodos. Na linha de comando, use curl -I URL para mostrar os cabeçalhos de resposta HTTP e verificar o código de estado (301 ou 302) e o cabeçalho Location. Em um navegador, abra as ferramentas de desenvolvimento (aba Rede) e observe a cadeia de requisições. Você também pode usar o Page Crawl Checker para verificar os redirecionamentos e detectar as cadeias.

É preciso redirecionar cada URL individualmente?

Sim, idealmente. Cada antigo URL deve redirecionar para a página equivalente no novo domínio (redirecionamento 1:1). Se a estrutura de URL for conservada, o path forwarding simplifica a configuração: o caminho do antigo URL é transmitido automaticamente para o destino. Se a estrutura mudar, você deve mapear cada URL manualmente.

O Google segue os redirecionamentos JavaScript?

O Google pode seguir os redirecionamentos JavaScript, mas com limitações. O conteúdo da página deve primeiro ser renderizado pelo motor de renderização do Google, o que adiciona um atraso. Além disso, nem todos os redirecionamentos JavaScript são detectados de forma confiável. O Google recomenda usar redirecionamentos do lado do servidor (301, 302) para as mudanças de URL importantes.

Qual é a diferença entre 301 e 308?

Ambos são redirecionamentos permanentes com transferência completa do SEO. A diferença é técnica: o 301 permite ao navegador transformar uma requisição POST em GET durante o redirecionamento, enquanto o 308 preserva o método HTTP original (um POST permanece um POST). Para as páginas web clássicas (requisições GET), 301 e 308 são funcionalmente idênticos. O código 308 é utilizado principalmente para APIs.

Quantos redirecionamentos segue o Google antes de desistir?

O Google segue geralmente até 5 redirecionamentos em uma cadeia antes de desistir. John Mueller do Google confirmou este comportamento. Se a página final não for alcançada em 5 saltos, não é rastreada nem indexada. A recomendação e nunca ultrapassar os 2 saltos para garantir uma transferência ótima do sinal SEO.

Pode-se anular um redirecionamento 301?

Tecnicamente sim, basta excluir a regra de redirecionamento no servidor. Mas na prática, os navegadores que armazenaram em cache o 301 continuarão redirecionando automaticamente até a expiração da sua cache. O Google também precisa rastrear o URL novamente para constatar que o redirecionamento não existe mais. O prazo de retorno à normalidade pode ser de várias semanas.

Como gerenciar uma migração com milhares de URLs?

Exporte a lista completa dos URLs indexados a partir do Google Search Console. Use uma folha de cálculo para criar o mapeamento 1:1. Se a estrutura for conservada, uma única regra de redirecionamento com path forwarding é suficiente. Se a estrutura mudar, agrupe os URLs por padrão e crie regras de reescrita (regex) no seu servidor ou CDN. Teste uma amostra antes de implementar o conjunto.

Qual é a diferença entre um redirecionamento 301 e um canonical tag?

O 301 redireciona fisicamente o visitante para um novo URL: a antiga página não fica mais acessível. O canonical tag (rel=canonical) deixa ambas as páginas acessíveis mas indica ao Google qual indexar de preferência. Use um 301 quando o URL de origem não tem mais razão de existir. Use um canonical quando ambos os URLs devem permanecer online (conteúdo duplicado, parâmetros de URL, versões paginadas).

Um redirecionamento torna o meu site mais lento?

Sim. Cada redirecionamento adiciona uma ida e volta na rede (100 a 300 ms por salto). O impacto se concentra no LCP (Largest Contentful Paint), a métrica de velocidade de carregamento. Os redirecionamentos 301 armazenados em cache pelo navegador não têm mais impacto após a primeira visita, pois o navegador redireciona localmente sem contatar o servidor.

O Google segue os redirecionamentos meta refresh?

Sim, o Google pode seguir os redirecionamentos meta refresh, mas com um atraso. A página HTML deve ser baixada e analisada antes de o Google detectar o redirecionamento. O Google desaconselha este método e recomenda os redirecionamentos do lado do servidor (301, 302). Os meta refresh também colocam um problema para os outros mecanismos de busca, que nem sempre os seguem.

Glossário

Redirecionamento 301: redirecionamento HTTP permanente. Indica que o URL mudou definitivamente e transfere a autoridade SEO para o destino.
Redirecionamento 302: redirecionamento HTTP temporário. Indica que o URL está temporariamente acessível em outro endereço. A autoridade SEO permanece no URL de origem.
Redirecionamento 307: redirecionamento temporário que preserva o método HTTP. Equivalente estrito do 302 sem transformação POST para GET.
Redirecionamento 308: redirecionamento permanente que preserva o método HTTP. Equivalente estrito do 301 sem transformação POST para GET.
PageRank: algoritmo do Google que mede a importância de uma página web em função da quantidade e qualidade dos links de entrada.
Canonical tag: tag HTML rel=canonical que indica ao Google qual versão de um URL é a preferida entre várias páginas com conteúdo idêntico ou semelhante.
Canonicalização: processo pelo qual o Google escolhe o URL preferido entre vários URLs que acessam o mesmo conteúdo.
Cadeia de redirecionamento: sequência de redirecionamentos sucessivos onde um URL redireciona para um segundo, que redireciona para um terceiro, etc.
Ciclo de redirecionamento: situação onde dois URLs se redirecionam mutuamente, criando um ciclo infinito.
Path forwarding: mecanismo que transmite o caminho do URL de origem para o destino durante um redirecionamento.
Soft 404: página que retorna um código HTTP 200 mas cujo conteúdo indica uma página de erro. O Google trata-a como um 404 para a indexação.
Change of Address: ferramenta do Google Search Console que permite declarar oficialmente uma mudança de domínio e acelerar a migração no índice do Google.
Crawl budget: número de páginas que o Googlebot pode explorar em um site em um tempo determinado. Os redirecionamentos consomem crawl budget, em particular as cadeias de redirecionamentos.
Core Web Vitals: conjunto de métricas do Google (LCP, INP, CLS) que medem o desempenho do usuário de uma página web. Os redirecionamentos impactam principalmente o LCP adicionando latência de rede.
CNAME: tipo de registro DNS que cria um alias de um domínio para outro. Utilizado para apontar um domínio para um servidor de redirecionamento.