Trocar o domínio do site sem perder tráfego: o procedimento oficial do Google, passo a passo

Última verificação: 9 de setembro de 2026. Todo procedimento desta página foi conferido nas duas páginas oficiais do Google em português — a Ajuda do Search Console e a Central da Pesquisa — com citação literal e link. Onde há relato de terceiro, e não documentação, está marcado como relato.

Quem pesquisa “mudar de domínio sem perder tráfego” encontra a mesma resposta repetida em toda a primeira página: faça um 301 de cada página antiga para a nova. Está certo — e está incompleto. A documentação do Google em português traz cinco pontos que praticamente nenhum desses guias menciona, e é neles que as migrações costumam falhar.

O que quase todo guia erra: a Alteração de Endereço é por variante, não por site

A ferramenta Alteração de Endereço, no Search Console, é o aviso formal ao Google de que o site mudou de endereço. A parte que quase ninguém publica é que ela não é enviada uma vez para “o site” — ela é enviada para cada variante do domínio antigo. A Central da Pesquisa é explícita:

“Envie uma Alteração de endereço para todos os subdomínios e as variantes www e não www do nome do domínio antigo (…), mesmo que você não esteja usando essas variantes ativamente. Verifique se todas essas variantes estão confirmadas no Search Console.”

— Central da Pesquisa Google, “Mover um site com mudanças de URL”, consultada em 09/09/2026.

“Mesmo que você não esteja usando essas variantes ativamente” é a frase que muda o trabalho. Antes de enviar qualquer coisa, faça a lista das propriedades a verificar:

• Domínio raiz — exemplo.com.br.
• Com www — www.exemplo.com.br, mesmo que ele só redirecione para a raiz.
• Subdomínios em uso — blog., loja., ajuda., painel..
• Subdomínios que você já usou e abandonou — se houve conteúdo indexado ali algum dia, entra na lista.
• Variantes por idioma, se existirem — en., es..

Cada uma dessas precisa estar verificada no Search Console antes, porque a ferramenta só aceita origem e destino que você comprove que administra. Quem envia só a propriedade principal deixa metade da migração sem aviso — e depois atribui a queda ao “Google demorando”.

Quando NÃO usar a ferramenta Alteração de Endereço

A Ajuda do Search Console mantém uma lista de casos em que a ferramenta não deve ser usada — e o mais comum de todos está nela. Enviar a solicitação nesses cenários não acelera nada; no melhor caso é inócuo, no pior descreve ao Google uma mudança que não aconteceu.

Duas restrições adicionais da mesma página valem para quem migra em etapas: não encadear mudanças (enviada uma Alteração de Endereço de A→B, não dá para emendar B→C em seguida) e evitar mover A, B e C ao mesmo tempo para o mesmo destino D — a documentação avisa que isso pode causar confusão e perda de tráfego. Consolidação de vários sites num só pede etapas separadas no tempo.

O mapa de URLs: a etapa que decide se o tráfego sobrevive

O 301 é a parte fácil: são três linhas de configuração. O que dá trabalho — e o que separa migração tranquila de desastre — é decidir para onde cada URL antiga aponta. Esse é o mapa de URLs, e ele se faz antes de tocar em qualquer servidor.

• Levante todas as URLs que existem hoje. Três fontes se complementam: o relatório de páginas do Search Console (o que o Google conhece), o sitemap atual (o que você declara) e o log de acesso do servidor (o que realmente recebe visita, inclusive o que não está em sitemap nenhum).
• Mapeie 1:1 sempre que possível. Cada página antiga vai para a página equivalente — mesmo assunto, mesma intenção. Redirecionar em massa para a home é o atalho que a documentação desaconselha por escrito (veja o próximo bloco).
• Decida o que morre. Página que não tem equivalente e não tem tráfego pode simplesmente retornar 410 ou 404. Forçar um destino ruim é pior do que assumir a remoção.
• rel="canonical" autorreferente em cada URL de destino, e hreflang atualizado se houver versões por idioma — apontando para as URLs novas, não para as antigas.
• Atualize os links internos para as URLs novas. Não deixe o 301 fazer esse trabalho: link interno apontando para o domínio antigo cria um salto extra em cada clique e é a origem mais silenciosa de cadeia de redirecionamento.
• Avise quem aponta para você quando der: parceiros, diretórios, perfis de redes sociais, assinatura de e-mail. O 301 cobre esses links, mas atualizar os principais reduz a dependência dele.

301, cadeia de redirecionamento e o mito do “PageRank perdido”

O medo que a primeira página inteira vende — “vou perder autoridade” — não vem da documentação. Ela diz o contrário, com todas as letras:

“Não se preocupe com o crédito do link. 301 e outros redirecionamentos permanentes não causam perda de PageRank.”

— Central da Pesquisa Google, consultada em 09/09/2026.

Se não é o 301 que custa tráfego, o que custa? A mesma página responde, e com números que os guias costumam omitir:

• Redirecionar muitas URLs antigas para a home vira soft 404. Literalmente: “Não redirecione muitos URLs antigos para um destino irrelevante, como a página inicial do novo site. Isso pode confundir os usuários e ser tratado como um erro soft 404”. Não é “perder um pouco de autoridade”: é o destino não valer como resposta.
• Cadeia de redirecionamento tem limite prático. O Googlebot “possa acompanhar até 10 saltos”, mas a recomendação é apontar para o destino final e, quando não der, manter a cadeia em “não mais do que três, mas no máximo cinco”.
• 301 e 308 valem os dois. A documentação recomenda “o uso de redirecionamentos HTTP permanentes, como 301 e 308, sempre que possível” — e coloca o redirecionamento pelo lado do cliente (JavaScript, meta refresh) como último recurso, só quando nenhuma configuração de servidor for possível.
• Rastreamento não tem prazo fixo. O Googlebot precisa visitar cada URL antiga e cada URL nova pelo menos uma vez, e não há frequência garantida. Site grande demora mais — o que explica por que “já faz duas semanas” não é sintoma de erro.
• Mudar conteúdo e URL ao mesmo tempo tira de você a capacidade de diagnosticar: se o tráfego cair, não dá para saber se foi o endereço novo ou o texto novo. Migre primeiro, reescreva depois.

180 dias ou um ano? Os três prazos do Google, e o que cada um mede

Esta é a pergunta que a primeira página responde de forma desencontrada — uns dizem seis meses, outros um ano — e a explicação é mais simples do que parece: os dois números estão na documentação oficial, em páginas diferentes, medindo coisas diferentes. São três prazos, não um.

180 dias — a janela da ferramenta

É o prazo do Search Console, não do seu servidor. A Ajuda descreve o que a ferramenta faz nesse período e o que acontece depois:

“O Search Console também encaminha vários sinais do site antigo para o novo (…). Essas ações continuam por 180 dias após o início da migração no Search Console.”

“Após o período de 180 dias, o Google não reconhecerá qualquer relação entre o site antigo e o novo e tratará o antigo como não relacionado, se ele ainda existir e puder ser rastreado.”

— Ajuda do Search Console, “Ferramenta Alteração de Endereço”, consultada em 09/09/2026.

É daqui que vem o “seis meses” que circula na internet. Não é um número errado — é outro número, de outra coisa. A mesma página, aliás, recomenda manter os redirecionamentos por “pelo menos 180 dias (ou mais, se você ainda receber tráfego da Pesquisa Google)”, o que já aponta para o segundo prazo.

Pelo menos um ano — o redirecionamento no servidor

Esse é o prazo que sustenta o tráfego de verdade, porque não depende de ferramenta nenhuma: enquanto o 301 estiver no ar, quem chegar pela URL antiga chega ao lugar certo.

“Mantenha os redirecionamentos pelo maior tempo possível. Geralmente, esse período é de pelo menos um ano. (…) Da perspectiva do usuário, considere manter os redirecionamentos indefinidamente.”

— Central da Pesquisa Google, consultada em 09/09/2026.

Um ano não é superstição: o Googlebot precisa visitar cada URL, sem frequência garantida, e ainda reatribuir os links de terceiros que continuam apontando para os endereços antigos — links em artigos, diretórios e perfis que ninguém vai atualizar por você.

Pelo menos um ano de registro pago — e o motivo não é SEO

“Recomendamos continuar pagando pelo domínio antigo por pelo menos um ano para impedir que outras pessoas o comprem e usem para fins maliciosos.”

— Ajuda do Search Console, consultada em 09/09/2026.

Domínio abandonado com histórico é mercadoria: alguém compra, sobe conteúdo de qualidade duvidosa e herda os links que apontavam para a sua marca. É um risco de segurança e reputação, não de posição no Google — e ele explica por que “já migrei, posso soltar o domínio velho” é uma economia cara.

A recomendação prática que sai dos três: mantenha o 301 no servidor por no mínimo um ano, sabendo que o encaminhamento de sinais da ferramenta acaba no 180º dia. E mantenha o registro pago pelo mesmo período, por segurança.

O erro que não está na documentação: trocar de domínio direto em produção

A documentação descreve o procedimento correto; ela não descreve como as empresas erram. Esse pedaço veio de um episódio do podcast Café & Tech de 19/10/2023, sobre estrutura de IPTV, num trecho que não é sobre vídeo: um dos apresentadores conta o caso de um conhecido que trocou o domínio do site sem ambiente de teste, direto no site vivo. O tráfego, segundo o relato, despencou para um décimo do que era.

O que um ambiente de homologação teria pego antes de o site sair do ar:

• Mapa de URLs incompleto — páginas antigas sem destino, descobertas só quando o visitante encontra o 404.
• Redirecionamento em loop — a regra do domínio antigo mandando para o novo e uma regra esquecida mandando de volta.
• noindex de homologação vazando para produção — o caso clássico: o site novo sobe com a tag que impedia o ambiente de teste de ser indexado, e ninguém remove.
• Sitemap apontando para as URLs erradas — publicado com o domínio antigo, ou com as duas versões misturadas.
• Links internos absolutos ainda escritos com o domínio velho, criando um salto extra a cada clique.

O checklist mínimo de ambiente, para migração de qualquer tamanho: produção separada de teste, deploy versionado (Git, não arquivo copiado por FTP), rollback pronto antes do cutover e validação do mapa de redirecionamento no ambiente de teste — URL a URL, na amostra que representa o site.

Como ligar o 301 na prática, por stack

Chega da teoria. O que segue é o redirecionamento de domínio inteiro preservando o caminho da URL — que é o que você quer em 90% das migrações: dominioantigo.com.br/pagina vai para dominionovo.com.br/pagina, não para a home. Teste no ambiente de homologação antes de aplicar em produção.

Apache — .htaccess

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?dominioantigo\.com\.br$ [NC]
RewriteRule ^(.*)$ https://dominionovo.com.br/$1 [R=301,L]

O $1 é o que preserva o caminho. Evite a forma curta Redirect 301 / https://dominionovo.com.br/ aplicada à raiz sem cuidado: dependendo de como o restante do arquivo está escrito, ela é justamente o caminho mais rápido para jogar o site inteiro na home — o cenário de soft 404 descrito acima.

Nginx

server {
    listen 443 ssl;
    server_name dominioantigo.com.br www.dominioantigo.com.br;
    return 301 https://dominionovo.com.br$request_uri;
}

O $request_uri carrega caminho e query string. Duas observações que economizam suporte: o domínio antigo precisa continuar com certificado SSL válido, senão o visitante bate num aviso de segurança antes do redirecionamento; e o bloco do domínio antigo tem que existir enquanto o 301 for necessário — ou seja, por pelo menos um ano.

WordPress

No WordPress o redirecionamento é a parte menor. A ordem que funciona:

• Atualize WP_HOME e WP_SITEURL (em wp-config.php ou nas configurações) para o domínio novo.
• Trate as URLs absolutas gravadas no banco — conteúdo, imagens, campos personalizados e opções serializadas guardam o domínio antigo por escrito. Uma substituição feita com um SQL cru quebra os campos serializados; use uma ferramenta de search-replace que respeite a serialização, e faça backup do banco antes.
• Deixe o 301 no servidor (Apache/Nginx, como acima), não só num plugin de redirecionamento: plugin depende do WordPress carregar, e você quer o redirecionamento respondendo mesmo com o site velho já desligado.

Cloudflare / CDN

Na borda, o redirecionamento é uma regra de redirect do domínio antigo para o novo preservando o caminho. O cuidado específico é a cadeia: borda → origem → destino final são três saltos, e basta uma regra antiga de http→https no meio para virar quatro. Antes de publicar, siga a cadeia inteira de uma URL de amostra e confirme que ela termina em um salto sempre que possível — a recomendação da documentação é apontar direto para o destino final.

Ordem de execução (checklist do cutover)

1. Prepare o site novo em ambiente de teste, com noindex — e anote em algum lugar visível que ele precisa ser removido na publicação.
2. Valide o mapa de URLs em homologação: cada URL antiga da amostra levando à equivalente, sem loop e sem cadeia longa.
3. Verifique todas as variantes do domínio antigo e do novo no Search Console (raiz, www, subdomínios).
4. Publique o site novo — e confirme que o noindex saiu.
5. Ligue os 301 no domínio antigo, preservando o caminho.
6. Teste uma amostra de URLs pela Inspeção de URL do Search Console e pelos cabeçalhos HTTP.
7. Envie a Alteração de Endereço para cada variante do domínio antigo.
8. Envie o novo sitemap na propriedade do domínio novo, e mantenha o sitemap antigo acessível por um tempo para o Google reprocessar as URLs velhas.
9. Acompanhe cobertura e desempenho nas duas propriedades por algumas semanas — a antiga caindo e a nova subindo é o comportamento esperado.
10. Mantenha os 301 por pelo menos um ano, e o registro do domínio antigo pago pelo mesmo período.

Uma ressalva honesta para fechar: a documentação do Google fala em flutuação durante a migração. Prometer “zero perda de tráfego” seria vender o que ninguém controla. O que o procedimento acima entrega é o oposto do improviso — e é por isso que ele cabe num checklist.

Ver também

• Copiaram o conteúdo do meu site — o que fazer: o que a documentação do Google permite fazer quando o conteúdo aparece em outro domínio.
• Banner de cookies é obrigatório? O que a LGPD exige: outro caso em que a fonte primária desmonta o que “todo mundo diz”.
• Scripts para hospedagem de sites: o que roda no servidor por trás do site.

Assista ao episódio completo do Café & Tech no YouTube: “Melhor Estrutura para IPTV em 2023 Completa — Ep 02”. O episódio é sobre estrutura de IPTV; o trecho citado nesta página está em 33:47.