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

Por CaptainDNS
Publicado em 16 de março de 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 temporario, o Google continua a indexar 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 gere 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 foruns SEO e nas discussoes entre desenvolvedores. A resposta depende do contexto, mas as consequências de uma ma escolha são reais: o Google indexa o URL errado, o PageRank dilui-se, os backlinks perdem o seu valor. Segundo um estudo da Moz realizado sobre 30 000 domínios, 12 % das migrações de domínio útilizam redirecionamentos 302 em vez de 301, causando uma perda media de tráfego orgânico duas vezes superior as 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 estejá a gerir um site institucional ou um portal de 50 000 páginas, os principios 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 rastreio e a indexação. Para os casos de usó de marketing (vanity URLs, link tracking, códigos QR), um guia complementar esta disponível na secção "Guias relacionados" no final do artigo.

Os 4 códigos de redirecionamento HTTP

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

301 Moved Permanently

O código 301 significa que o recursó 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/pt/tools

Comportamento do navegador: o navegador armazena em cache o redirecionamento e redireciona automáticamente os futuros pedidos para o destino, sem voltar a passar pelo servidor de origem. Esta cache persiste mesmo após fechar o navegador.

Definido na RFC 7231, secção 6.4.2, o código 301 permite aos clientes HTTP transformar um pedido 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 recursó esta temporariamente disponível noutro URL. O servidor responde da mesma forma:

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

Comportamento do navegador: o navegador não armazena em cache o redirecionamento. Cada pedido volta a passar pelo servidor de origem, que pode devolver um destino diferente ou deixar de redirecionar.

Definido na RFC 7231, secção 6.4.3, o código 302 tem uma historia complicada. Em HTTP/1.0, significava "Moved Temporarily". Os navegadores transformavam históricamente os pedidos POST em GET durante um 302, o que não correspondia a específicaçã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 e o equivalente estrito do 302, mas com uma garantia: o método HTTP e 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 esta definido na RFC 7231, secção 6.4.7. E útilizado principalmente para formularios e API REST onde a preservação do método e crítica. Para os redirecionamentos de páginas web clássicas (GET), a diferença entre 302 e 307 e nula.

308 Permanent Redirect

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

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

Definido na RFC 7238, o código 308 e 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?	Transferencia SEO?
301	Permanente	Não (POST pode tornar-se GET)	Sim	Sim (100 %)
302	Temporario	Não (POST pode tornar-se GET)	Não	Parcial (Google indexa a origem)
307	Temporario	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 (pedidos 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 e necessaria.

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 segue-o imediatamente. Mas também existem redirecionamentos do lado do cliente, implementados em JavaScript ou atraves de uma tag meta refresh.

Redirecionamentos do lado do servidor (HTTP): o Google deteta-os e segue-os imediatamente durante o rastreio. A transferência de sinais SEO e fiavel e rápida. E o método recomendado pelo Google Search Central para qualquer mudanca de URL.

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

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

Método	Detecao pelo Google	Transferencia SEO	Casó de usó
Do lado do servidor (301/302)	Imediata	Completa (301) ou parcial (302)	Migrações, mudancas 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 casó recomendado

O risco principal dos redirecionamentos JavaScript: se a renderização da página falhar (erro JS, timeout, recursó bloqueado), o Google simplesmente não ve o redirecionamento. A página de origem permanece indexada, o destino e ignorado. Para as Single Page Applications (SPA) onde o redirecionamento do lado do servidor e técnicamente impossível, o JavaScript e o único recursó, mas então e necessario verificar regularmente que o Googlebot deteta corretamente o redirecionamento (atraves 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, efetua automáticamente um novo pedido para o URL indicado no cabeçalho Location. Este processó e transparente para o útilizador: nota apenas um ligeiro atrasó de carregamento.

Para os redirecionamentos 301, o navegador armazena a correspondencia numa cache local. As visitas seguintes ao antigo URL são redirecionadas diretamente pelo navegador, sem contactar o servidor de origem. Esta cache e persistente: sobrevive ao fecho do navegador e só e esvaziada por uma limpeza manual da cache ou pela expiração definida pelos cabeçalhos Cache-Control.

Para os redirecionamentos 302, o navegador não armazena em cache a correspondencia. Cada visita ao antigo URL desencadeia um pedido ao servidor de origem, que pode responder de forma diferente a cada vez. Este comportamento e o que torna o 302 adequado para redirecionamentos dinamicos (geolocalização, testes A/B, campanhas temporarias).

Esta diferença de cache tem um impacto direto no desempenho. Um 301 poupa um pedido de rede em cada visita posterior. Um 302 adiciona sistematicamente a latencia de uma ida e volta HTTP adicional.

Outros códigos de estado HTTP que deve conhecer

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

200 OK: à página existe e devolve conteúdo. Não ha redirecionamento. Se à 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: à página não existe. Se eliminar 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: à página foi eliminada definitivamente e não será substituida. O Google trata o 410 como um sinal forte para remover à 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 e a secção mais importante deste guia. A diferença técnica entre 301 e 302 parece menor (permanente vs temporario), mas as consequências SEO são significativas. Compreender estas diferenças e essencial antes de configurar qualquer redirecionamento.

Transferencia de PageRank e autoridade

O PageRank e 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-lhe uma fração do seu proprio 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 atraves de um 301. Desde uma atualização confirmada por Gary Illyes da equipa 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 e simples: se o redirecionamento e temporario, 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 por trata-lo como um 301 de facto, mas o prazo e 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 processó demora geralmente de alguns dias a algumas semanas conforme a frequência de rastreio.

Com um 302: o Google continua a indexar o URL de origem e mostra-o nos seus resultados. O destino e conhecido pelo Google, mas não e considerado como a versão canonica. 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 e armazenado em cache pelo navegador. Após a primeira visita, o navegador redireciona diretamente para o destino sem contactar o servidor de origem. Consequencia: não pode rastrear o número de redirecionamentos, pois as visitas seguintes já não passam pelo seu servidor.

O 302 não e armazenado em cache. Cada visita passa pelo servidor de origem, que pode contar os pedidos, registar as informações do visitante e até mudar o destino em tempo real. Por issó 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 um pedido de rastreio e adiciona latencia.

O Google segue as cadeias de redirecionamento, mas com limites. John Mueller confirmou que o Googlebot segue geralmente 5 redirecionamentos antes de desistir. Além dissó, à página final não e rastreada nem indexada.

Mesmo abaixo de 5 saltos, cada redirecionamento intermedio dilui potêncialmente o sinal SEO. A recomendação e limitar qualquer cadeia a 2 saltos no maximo: a origem redireciona para o destino final, ponto.

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 sancao, mas indexa o URL errado e conserva a autoridade no lugar errado. O resultado parece uma penalização, mas e 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 multiplas ocasioes. A antiga penalização de 15 % já não existe.

Mito: o Google trata os 302 de longa duração como 301. Realidade: e parcialmente verdade. O Google pode, após um longo período, decidir tratar um 302 como um 301. Mas o prazo e 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 inicio.

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 atrasó 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 fiavel.

Mito: os 301 são instantaneos para o SEO. Realidade: não. Após configurar um 301, o Google deve voltar a rastrear o antigo URL, descobrir o redirecionamento e depois atualizar o seu índice. Este processó demora de alguns dias a varias semanas conforme a frequência de rastreio do seu site. As páginas com muito tráfego e muitos backlinks são rastreadas mais rápidamente do que as páginas profundas com poucas visitas.

HTTPS e redirecionamentos: um pre-requisito indispensavel

O servidor que alojá 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 mostrara um erro de certificado em vez do redirecionamento.

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

Para as configurações manuais no seu proprio 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 estejá 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 e a versão preferida. Mas funcionam de forma muito diferente e não se útilizam nas mesmas situações.

Quando usar um 301 em vez de um canonical tag?

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

Um redirecionamento 301 suprime o acessó ao URL de origem. O visitante que digita o antigo URL e enviado automáticamente para o destino. A antiga página já não e acessível. E a escolha correta quando o URL de origem já não tem razão de existir.

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

Criterio	Redirecionamento 301	Canonical tag
O visitante e redirecionado?	Sim	Nao, ambas as páginas são acessiveis
Sinal para o Google	Diretiva forte (obrigatoria)	Indicação (sugestão, pode ser ignorada)
Ambos os URLs existem?	Nao, apenas o destino e acessível	Sim, ambos permanecem online
Transferencia de PageRank	100 % para o destino	O Google consolida os sinais no URL canonico
Casó de usó principal	URL eliminado, migração, mudanca definitiva	Conteúdo duplicado, parametros de URL, versoes páginadas

Em resumo: se o antigo URL já não serve, use um 301. Se o antigo URL tem uma razão de existir (versão para impressao, página com parametros 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 e 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 si proprio:

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

Este duplo sinal e particularmente útil quando o seu conteúdo e acessível atraves de multiplos caminhos (antigo domínio redirecionado, variante www, versão HTTP). O Google recebe uma mensagem coerente de todas as fontes: o destino e efetivamente o URL canonico.

A combinação 301 + canonical não e obrigatoria, mas acelera a convergencia no índice do Google e reduz o risco de o Google escolher o URL errado como versão canonica durante o período de transição.

Quando usar um 301?

O 301 e a escolha predefinida para todo redirecionamento definitivo. Eis os casos de usó mais frequentes.

Migração de domínio definitiva

Muda de nome de domínio. O antigo domínio já não será 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/pt/blog/article-1

Consolidação de varios domínios

Possui varios domínios (variantes ortograficas, extensoes de pais, domínios de marketing) e desejá concentrar a autoridade SEO num único.

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

Mudanca de URL permanente

Redesenho do site, mudanca de CMS, nova arquitetura de URLs. Os antigos URLs já não existem e não voltarao.

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

Passagem de HTTP para HTTPS

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

http://captaindns.com/pt/tools
  301  https://captaindns.com/pt/tools

Naked domain para www (ou vice-versa)

Escolhe uma versão canonica 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 usó 301

Situação	Exemplo	Porque 301?
Migração de domínio	antigo.captaindns.com para captaindns.com	O domínio de origem já não servira conteúdo
Consolidação multi-domínio	captaindns.fr para captaindns.com	Concentrar a autoridade SEO num único domínio
Mudanca de URL (redesenho)	/products/ para /pt/tools/	A antiga estrutura de URL e abandonada
HTTP para HTTPS	http:// para https://	A passagem para HTTPS e definitiva
www vs sem www	www.captaindns.com para captaindns.com	Uma única versão canonica do domínio

Quando usar um 302?

O 302 e a escolha correta quando o redirecionamento e temporario: preve restabelecer o URL de origem ao seu estado original.

Campanhas de marketing temporarias

Cria um vanity URL para uma campanha limitada no tempo. O redirecionamento será desativado no final da campanha.

promo.captaindns.com  302  captaindns.com/pt/pricing
(durante a campanha de marco 2026)

Testes A/B

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

Manutencao planeada

O seu site esta em manutenção. Redireciona temporariamente o tráfego para uma página de informação. O site voltara ao seu estado normal após a manutenção.

captaindns.com/pt/tools  302  captaindns.com/pt/maintenance

Geolocalização e detecao de idioma

Redireciona os visitantes para uma versão localizada do seu site em função do seu endereço IP ou do idioma do navegador. O redirecionamento e condicional e não deve ser armazenado em cache, pois o mesmo útilizador pode visitar de outro pais.

captaindns.com  302  captaindns.com/pt/ (visitante portugues)
captaindns.com  302  captaindns.com/en/ (visitante ingles)

Redirecionamentos condicionais (movel/desktop)

Redireciona os visitantes moveis para uma versão dedicada. Esta prática e cada vez menos comum (o design responsivo substituiu-a em grande parte), mas ainda existe em alguns sites.

Tabela recapitulativa: casos de usó 302

Situação	Exemplo	Porque 302?
Campanha de marketing	promo.captaindns.com para landing page	Redirecionamento temporario, será desativado
Teste A/B	50 % do tráfego para variante B	Teste limitado no tempo
Manutencao	Site para página de manutenção	O site voltara
Geolocalização	Raiz para versão local	Condicional, não deve ser armazenado em cache
Redirecionamento movel	Site para versão movel	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 monitorização durante 90 dias

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

Antes da migração: auditoria e inventario

1. Listar todos os URLs indexados

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

O objetivo: ter um inventario 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 generico para a homepage. Uma tabela simples e suficiente:

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

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

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 e pior do que não ter redirecionamento: o Google ve uma página de erro e desclassifica o URL.

5. Fazer backup dos dados existentes

Antes de qualquer modificação, exporte uma copia completa:

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

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

Configurar os redirecionamentos 301

5. 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 e suficiente. As páginas profundas, os artigos do blog, as fichas de produto devem ter cada uma o seu proprio redirecionamento.

Se o seu novo site conserva a mesma estrutura de URL, pode usar uma regra de path forwarding. O caminho do antigo URL e automáticamente adicionado ao destino:

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

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

6. Gerir as 4 variantes de cada URL

Cada URL existe potêncialmente em 4 versoes:

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

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

Verificar o DNS

7. Configurar os registos DNS

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

8. Verificar a propagação DNS

Após modificar os registos DNS, verifique que a propagação e efetiva em todas as regioes 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

9. Declarar a mudanca no Google Search Console

O Google fornece uma ferramenta dedicada na Search Console: "Change of Address" (Definicoes > Mudanca 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

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

10. Enviar o novo sitemap

Envie o sitemap XML do novo domínio no Google Search Console. Verifique que todos os URLs do sitemap devolvem um código 200. Remova o sitemap do antigo domínio após à migração estar concluida e o índice atualizado.

Monitorização pos-migração

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

Uma descida temporaria do tráfego orgânico (10 a 20 %) e normal nas 2 a 4 semanas após uma migração. Além dissó, ha um problema. Supervisione:

Semana 1-2: o Google comeca a rastrear o novo domínio. O tráfego pode descer de 10 a 30 %.
Semana 3-4: o tráfego deverá estabilizar e comecar a subir.
Mes 2-3: o tráfego deverá voltar ao nivel pre-migração, ou até ultrapassa-lo se o novo site e de melhor qualidade.

12. Verificar os erros na Search Console

Consulte o relatorio "Páginas" no Google Search Console para identificar erros 404, erros de redirecionamento e problemas de indexação. Corrijá imediatamente os URLs que devolvem erros.

13. Monitorizar 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 devolvem um erro 404 em vez de um redirecionamento 301.

14. Verificar as posicoes de pesquisa

Acompanhe as suas palavras-chave estrategicas numa ferramenta de acompanhamento de posicoes (Semrush, Ahrefs, Sistrix). Compare as posicoes antes e depois da migração. Uma palavra-chave que cai mais de 10 posicoes 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	Posicao antes	Posicao D+7	Posicao D+30	Posicao 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 e sinal de que à migração se desenrola corretamente. Uma estagnação em D+30 requer investigação (redirecionamentos em falta, conteúdo modificado, problemas técnicos).

Duração de manutenção dos redirecionamentos

14. Durante quanto tempo manter os redirecionamentos?

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

Minimo 6 meses: abaixo dissó, o Google não teve tempo de voltar a rastrear 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 a apontar para o antigo domínio durante anos.

Se deixar expirar o antigo domínio, os redirecionamentos obviamente deixam de funcionar. Os backlinks que apontavam para o antigo domínio devolvem um erro DNS. Por issó recomenda-se conservar o antigo domínio e renovar o seu registo 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 alojar conteúdo maliciosó ou spam. Renove o registo do seu antigo domínio durante pelo menos 3 anos após à migração.

Planeamento semana a semana

Uma migração de domínio prepara-se com varias semanas de antecedencia. Eis um calendario tipo para estruturar as etapas e evitar esquecimentos.

Semana	Acao	Verificação
S-4	Auditoria completa dos URLs, inventario 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 válidada
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	Monitorizar a indexação e o tráfego diariamente	Search Console e Analytics consultados todos os dias
S+4	Primeiro balanco aos 30 dias	Comparação do tráfego antes e após à migração
S+8	Segundo balanco aos 60 dias	Estabilização esperada do tráfego orgânico
S+12	Balanco final aos 90 dias	Decisao: conservar ou ajustar os redirecionamentos

Este calendario e indicativo. Para os sites volumosos (varios milhares de páginas), prevejá uma semana adicional para a auditoria e o mapeamento dos URLs.

Casó real: migração HTTP para HTTPS

A passagem de HTTP para HTTPS e à 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 processó e idêntico a uma mudanca 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 acessiveis em HTTP, o Google considera-as como duplicados, e a autoridade SEO e fragmentada entre as duas versoes.

Ponto importante: o Google Search Console trata HTTP e HTTPS como propriedades distintas. Deve enviar ambas as versoes (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 processó.

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 mensuravel em dois aspetos técnicos do SEO: o orcamento de rastreio e o desempenho de carregamento.

Crawl budget e redirecionamentos

O Googlebot dispoe de um orcamento de rastreio limitado para cada site: um número de páginas que pode explorar num intervalo de tempo dado. Este orcamento depende do tamanho do site, da sua popularidade e da capacidade do servidor para responder rápidamente.

Cada redirecionamento consome uma unidade deste orcamento. Quando o Googlebot encontra um 301, conta um pedido para o URL de origem (que devolve o redirecionamento) e depois um segundo pedido para o destino. Uma cadeia de 3 redirecionamentos consome portanto 4 pedidos para uma única página de conteúdo.

Para os sites pequenos (algumas centenas de páginas), o impacto e negligenciavel. Para os sites volumosos com milhares de redirecionamentos ativos, o consumo de orcamento de rastreio pode tornar-se 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 orcamento de rastreio pois o Googlebot aprende progressivamente os novos URLs

Impacto nos Core Web Vitals

Os Core Web Vitals são as metricas de desempenho do útilizador medidas pelo Google: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift). Estas metricas influênciam 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 latencia de rede e a localização geografica do visitante.

Impacto por metrica:

LCP: diretamente afetado. O tempo de carregamento do conteúdo principal aumenta de 100 a 300 ms por redirecionamento. Em movel com uma conexão lenta, o impacto pode ultrapassar os 500 ms por salto.
CLS: nenhum impacto. Os redirecionamentos ocorrem antes da exibicao 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 noticia: 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 (separador Performance) ou os dados de campo no Google Search Console (relatorio Core Web Vitals).

Erros comuns que destroem o SEO

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

E o erro mais frequente. Um desenvolvedor configura redirecionamentos 302 "temporarios" para uma migração definitiva. Resultado: o Google continua a indexar o antigo domínio, o PageRank não e transferido e o novo domínio parte do zero em termos de autoridade.

A correcao e simples: mude todos os redirecionamentos 302 para 301. O efeito não e imediato (o Google deve voltar a rastrear os URLs), mas a transferência de autoridade acabara por se efetuar.

Redirecionar todos os URLs para a homepage

Redireciona antigo.captaindns.com/blog/article-1, antigo.captaindns.com/blog/article-2 e antigo.captaindns.com/contact para captaindns.com. O Google considera estes 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 à página equivalente no novo domínio. Se uma página não tem equivalente exato, redirecione-a para à página tematicamente mais proxima. Por exemplo, um artigo de blog eliminado pode ser redirecionado para um artigo relacionado que traté o mesmo tema, ou para à 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 latencia e consome um pedido de rastreio. Além de 5 saltos, o Googlebot desiste. Mesmo com 3 saltos, o sinal SEO dilui-se.

Corrijá 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 sobrepoe-se no ficheiro .htaccess ou na configuração do Nginx.

A solução: teste cada URL num navegador em modo incognito 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 atraves de 4 URLs diferentes (http://, https://, http://www., https://www.) deve redirecionar as 3 variantes não canonicas 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 canonica que o Google pode indexar como duplicado.

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

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

curl -I http://captaindns.com/pt/tools       deve devolver 301 para https://captaindns.com/pt/tools
curl -I http://www.captaindns.com/pt/tools    deve devolver 301 para https://captaindns.com/pt/tools
curl -I https://www.captaindns.com/pt/tools   deve devolver 301 para https://captaindns.com/pt/tools
curl -I https://captaindns.com/pt/tools       deve devolver 200 (URL canonico)

Eliminar os redirecionamentos demasiado cedo

Algumas equipas eliminam os redirecionamentos 301 após algumas semanas, pensando que o Google teve tempo de atualizar o seu índice. Na realidade, o Google não volta a rastrear todas as páginas ao mesmo ritmo. As páginas profundas com poucos backlinks podem não ser rastreadas de novo antes de varios meses.

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

Não monitorizar após à migração

A migração esta implementada, os redirecionamentos funcionam, o sitemap foi enviado. Trabalho terminado? Nao. Sem monitorização, não detetara os problemas que aparecem nas semanas seguintes:

Páginas 404 no novo domínio (conteúdo eliminado ou URL mal configurado)
Redirecionamentos partidos (certificado expirado, servidor de redirecionamento em baixo)
Indexação bloqueada (robots.txt demasiado restritivo no novo domínio)
Descida anormal do tráfego em certas secções do site

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

Ignorar os emails e newsletters que contem links para o antigo domínio

Os seus emails de marketing, as newsletters arquivadas e os documentos PDF contem links para o antigo domínio. Estes links continuaráo a ser clicados durante meses, até anos. Se os redirecionamentos não estiverem implementados, os seus subscritores chegam a erros.

Faca o inventario 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 não pode modificar (emails já enviados, PDF já descarregados).

Não se esqueca dos links nas aplicações moveis, nas integrações com parceiros e nos widgets incorporados em sites de terceiros. Estas fontes são frequentemente invisiveis nas auditorias de backlinks mas geram um tráfego significativo.

Usar redirecionamentos JavaScript em vez de redirecionamentos do servidor

Algumas equipas implementam redirecionamentos atraves de meta refresh ou window.location em vez de configurar redirecionamentos do lado do servidor. Esta escolha e problematica para o SEO.

Os redirecionamentos JavaScript requerem que o motor de busca descarregue à página HTML, execute o JavaScript e depois descubra o redirecionamento. O Google pode faze-lo (o seu crawler útiliza um motor de renderização baseado em Chromium), mas com um atrasó significativo. Os outros motores de busca (Bing, Yandex) nem sempre seguem os redirecionamentos JavaScript.

Resultado concreto: durante o período de transição, a indexação e mais lenta, a transferência de sinais SEO e incerta e alguns bots simplesmente não veem o redirecionamento. Se tem acessó à 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 e técnicamente impossível, como as Single Page Applications alojadas num CDN estatico.

Não informar o Google via Search Console

A ferramenta Change of Address no Google Search Console foi concebida específicamente para acelerar as migrações de domínio no índice do Google. Contudo, muitas migrações são efetuadas sem usar esta ferramenta.

Sem o Change of Address, o Google deve descobrir à migração por si proprio rastreando o antigo domínio e seguindo os redirecionamentos. Este processó pode demorar varias semanas, até varios 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 explicito: 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 esta disponível na Search Console, secção Definicoes, depois Mudanca de endereço. Ambos os domínios (antigo e novo) devem estar verificados na Search Console.

Casos de usó concretos com CaptainDNS

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

Alojá o seu blog em blog.captaindns.com e decide transferi-lo para captaindns.com/pt/blog para consolidar a autoridade SEO.

Configuração:

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

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

Pontos de atenção:

Atualize os links internos do site principal para apontar para os novos URLs (/pt/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 proprio perfil na Search Console, declare a mudanca de endereço.

Consolidação de varios subdomínios

Possui shop.captaindns.com, docs.captaindns.com e status.captaindns.com. Decide reagrupar tudo sob captaindns.com.

Configuração:

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

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

Beneficio SEO: em vez de repartir a autoridade de domínio por 4 entidades distintas (domínio principal + 3 subdomínios), toda a autoridade e consolidada no domínio principal. Os backlinks adquiridos pela documentação ou pela lojá 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 a gestão.

Redesenho com mudanca de estrutura de URLs

Passa de uma estrutura plana (captaindns.com/dns-check) para uma estrutura hierarquica (captaindns.com/pt/tools/dns/test-propagation).

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

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

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

Mudanca de CMS com novos URLs

Migra do WordPress (captaindns.com/2025/03/mon-article) para um CMS headless com URLs limpos (captaindns.com/pt/blog/mon-article).

A mudanca 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/pt/blog/mon-article
captaindns.com/2025/04/autre-article  301  captaindns.com/pt/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 útiliza os mesmos slugs que o WordPress (o titulo do artigo em minusculas com hifens), pode criar uma regra de reescrita que remove o prefixo de data e adiciona o prefixo /pt/blog/. Isto reduz consideravelmente o trabalho de mapeamento para os sites com centenas de artigos.

Internacionalização e redirecionamento por idioma

Lanca versoes localizadas do seu site. O URL /tools/dns-check torna-se /pt/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 predefinido

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

captaindns.com/tools/dns-check  301  captaindns.com/pt/tools/dns-check

Facil de configurar, mas os visitantes anglofonos que tinham um backlink para /tools/dns-check chegam a versão em portugues.

Abordagem 2: redirecionamento 302 com detecao 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 e condicional:

captaindns.com/tools/dns-check  302  captaindns.com/pt/tools/dns-check (visitante PT)
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 útilizador. Certifique-se de implementar as tags hreflang nas páginas de destino para ajudar o Google a compreender a estrutura multilingue.

🎯 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 temporaria = 302. Em casó de duvida, coloque a questão: o antigo URL voltara 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 generico 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 registos DNS apontam para o servidor de redirecionamento com o teste de propagação DNS.
Declarar a mudanca no Google Search Console: use a ferramenta "Change of Address" e envie o novo sitemap.
Monitorizar durante 90 dias: acompanhe o tráfego orgânico, os erros de rastreio e as posicoes na Search Console. Corrijá imediatamente os problemas detetados.

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 e a diferença entre um redirecionamento 301 e 302?

O 301 e um redirecionamento permanente: indica aos navegadores e aos motores de busca que o URL mudou definitivamente. O 302 e um redirecionamento temporario: indica que o URL atual esta temporariamente acessível noutro endereço. A diferença principal para o SEO e 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?

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

Durante quanto tempo e precisó manter os redirecionamentos após uma migração?

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

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

O Google continua a indexar o antigo URL e não transfere o PageRank para o destino. O seu novo domínio não beneficia da autoridade acumulada pelo antigo. Com o tempo, o Google pode acabar por tratar o 302 como um 301, mas o prazo e imprevisível. A correcao e substituir todos os 302 por 301. O Google voltara a rastrear os URLs e atualizara o seu índice.

As cadeias de redirecionamento afetam o SEO?

Sim. Cada salto numa cadeia de redirecionamento consome um pedido de rastreio e adiciona latencia. O Googlebot segue geralmente até 5 redirecionamentos antes de desistir. Além dissó, à página final não e rastreada nem indexada. Mesmo abaixo de 5 saltos, o sinal SEO pode diluir-se. Limite qualquer cadeia a 2 saltos no maximo e corrijá os antigos redirecionamentos para apontar diretamente para o destino final.

Como verificar que um redirecionamento funciona corretamente?

Varios métodos. Na linha de comandos, 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. Num navegador, abra as ferramentas de desenvolvimento (separador Rede) e observe a cadeia de pedidos. Também pode usar o Page Crawl Checker para verificar os redirecionamentos e detetar as cadeias.

E precisó redirecionar cada URL individualmente?

Sim, idealmente. Cada antigo URL deve redirecionar para à página equivalente no novo domínio (redirecionamento 1:1). Se a estrutura de URL for conservada, o path forwarding simplifica à configuração: o caminho do antigo URL e transmitido automáticamente para o destino. Se a estrutura mudar, 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 atrasó. Além dissó, nem todos os redirecionamentos JavaScript são detetados de forma fiavel. O Google recomenda usar redirecionamentos do lado do servidor (301, 302) para as mudancas de URL importantes.

Qual e a diferença entre 301 e 308?

Ambos são redirecionamentos permanentes com transferência completa do SEO. A diferença e técnica: o 301 permite ao navegador transformar um pedido 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 (pedidos GET), 301 e 308 são funcionalmente idênticos. O código 308 e útilizado principalmente para APIs.

Quantos redirecionamentos segue o Google antes de desistir?

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

Pode-se anular um redirecionamento 301?

Tecnicamente sim, basta eliminar a regra de redirecionamento no servidor. Mas na prática, os navegadores que armazenaram em cache o 301 continuaráo a redirecionar automáticamente até a expiração da sua cache. O Google também precisa de voltar a rastrear o URL para constatar que o redirecionamento já não existe. O prazo de retorno a normalidade pode ser de varias semanas.

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

Exporte a lista completa dos URLs indexados a partir do Google Search Console. Use uma folha de calculo para criar o mapeamento 1:1. Se a estrutura for conservada, uma única regra de redirecionamento com path forwarding e 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 e 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 já não e acessível. O canonical tag (rel=canonical) deixa ambas as páginas acessiveis mas indica ao Google qual indexar de preferência. Use um 301 quando o URL de origem já não tem razão de existir. Use um canonical quando ambos os URLs devem permanecer online (conteúdo duplicado, parametros de URL, versoes páginadas).

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 concentra-se no LCP (Largest Contentful Paint), a metrica de velocidade de carregamento. Os redirecionamentos 301 armazenados em cache pelo navegador já não tem impacto após a primeira visita, pois o navegador redireciona localmente sem contactar o servidor.

O Google segue os redirecionamentos meta refresh?

Sim, o Google pode seguir os redirecionamentos meta refresh, mas com um atrasó. A página HTML deve ser descarregada e analisada antes de o Google detetar 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 motores de busca, que nem sempre os seguem.

📖 Glossario

Redirecionamento 301: redirecionamento HTTP permanente. Indica que o URL mudou definitivamente e transfere a autoridade SEO para o destino.
Redirecionamento 302: redirecionamento HTTP temporario. Indica que o URL esta temporariamente acessível noutro endereço. A autoridade SEO permanece no URL de origem.
Redirecionamento 307: redirecionamento temporario 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 importancia 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 e a preferida entre varias páginas com conteúdo idêntico ou semelhante.
Canonicalização: processó pelo qual o Google escolhe o URL preferido entre varios URLs que acedem ao mesmo conteúdo.
Cadeia de redirecionamento: sequencia 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 devolve 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 mudanca de domínio e acelerar à migração no índice do Google.
Crawl budget: número de páginas que o Googlebot pode explorar num site num tempo dado. Os redirecionamentos consomem crawl budget, em particular as cadeias de redirecionamentos.
Core Web Vitals: conjunto de metricas do Google (LCP, INP, CLS) que medem o desempenho do útilizador de uma página web. Os redirecionamentos impactam principalmente o LCP adicionando latencia de rede.
CNAME: tipo de registo DNS que cria um alias de um domínio para outro. Utilizado para apontar um domínio para um servidor de redirecionamento.