Como migrar um site com mudança de URL minimizando o impacto no tráfego orgânico

Mudar as URLs de um site — de domínio, de HTTP para HTTPS ou de formato de caminho — não precisa derrubar o tráfego orgânico. O caminho é mapear URLs, redirecionar com 301 ou 308 e monitorar por semanas.

A orientação do Google vale para 3 tipos de mudança

A orientação cobre HTTP para HTTPS, troca de nome de domínio (incluindo fusão de domínios ou hostnames) e alteração de caminhos de URL. A base é o documento do Google sobre mudanças de site e migração, atualizado em 20 de agosto de 2026.

Mudanças de infraestrutura sem troca de URL ficam fora do escopo e têm outra orientação. O roteiro vale também para aposentar conteúdo: se páginas antigas não vão para o novo site, elas devem devolver HTTP 404 ou 410 corretamente, e não redirecionar para uma página qualquer.

Antes de começar: mude uma coisa por vez

A recomendação central é não empilhar mudanças: uma mudança por vez. Se a migração envolve domínio novo, troca de CMS e layout novo, faça uma coisa por vez.

Providências que a documentação lista:

• Configurar o CMS e importar o conteúdo, transferindo imagens e downloads (como PDFs) que já podem receber tráfego ou links.
• Em HTTPS, obter e configurar os certificados TLS no servidor.
• Preparar o robots.txt do novo site com as regras corretas. Se o site ficou bloqueado por robots.txt durante o desenvolvimento, prepare o arquivo final. Se usou noindex, tenha pronta a lista de URLs da qual remover as regras no início da migração.
• Verificar no Search Console todas as variantes do site antigo e do novo (com e sem www, HTTP e HTTPS). Confirme se a verificação continuará válida depois da mudança — inclusive o arquivo HTML de verificação, a meta tag e o Google Analytics.
• Revisar configurações herdadas: taxa de rastreamento em "Let Googlebot determine" nas duas propriedades e reenvio do arquivo de links desautorizados na conta do site novo.
• Se o domínio foi comprado recentemente, checar ações manuais por spam do dono anterior e remoções de URL pendentes, inclusive remoções do site inteiro.
• Garantir capacidade de servidor. Depois da migração, o Google rastreia o site novo com mais intensidade, porque os rastreamentos das URLs antigas passam pelos redirecionamentos.

Escolher uma janela de tráfego baixo — quando o tráfego é sazonal ou cai em certos dias da semana — reduz o número de usuários afetados por problemas e libera recursos do servidor para o Googlebot.

O mapa de URLs antigas vem antes do redirecionamento

Sem a lista de URLs antigas não há como redirecionar com precisão. Em migrações simples de domínio, um redirecionamento curinga no servidor pode resolver. Nos demais casos, é preciso montar a lista.

O Google sugere começar pelas URLs importantes, levantadas em:

• sitemaps enviados ao Search Console;
• logs de servidor e analytics, com as de maior tráfego;
• relatório de links para o site;
• e no próprio CMS.

Vale olhar também os logs de um período recente e incluir imagens, vídeos, JavaScript e CSS — todos precisam migrar como o restante do conteúdo.

Com a lista em mãos, defina o destino de cada URL. Esse mapeamento pode ficar em um banco de dados ou em regras de reescrita para padrões comuns.

Depois, ajuste as marcações do site novo. Cada URL deve ter rel="canonical" autorreferente, as anotações hreflang precisam apontar para as novas URLs e os links internos devem ser atualizados. Sobre consolidar e redirecionar, veja tag canônica: como consolidar URLs duplicadas.

Redirecionamentos permanentes e sem cadeias

Use 301 ou 308 no servidor, apontando direto para o destino final. A orientação é configurar redirecionamentos permanentes no .htaccess (em Apache) ou em funções de redirecionamento do CMS; redirecionamentos no lado do cliente são o último recurso.

Os tipos e efeitos de cada código estão em redirecionamentos e SEO e na comparação redirect 301 vs 302 vs canonical.

Evite cadeias. O Googlebot segue até 10 saltos, mas o Google recomenda apontar direto para o destino final. Se não for possível, mantenha no máximo 3 redirecionamentos e, no limite, menos de 5. Cadeias longas aumentam a latência para o usuário e nem todo navegador as suporta.

Sobre o ritmo: sites pequenos e médios devem mover todas as URLs de uma vez, o que ajuda os algoritmos a detectar a migração e atualizar o índice mais rápido. Sites grandes podem migrar por seções, o que facilita monitorar e corrigir problemas.

Uma armadilha citada explicitamente: não redirecionar muitas URLs antigas para um único destino irrelevante, como a home do site novo. Isso confunde o usuário e pode ser tratado como soft 404. A exceção é quando várias páginas foram consolidadas em uma só — aí o redirecionamento para a página consolidada é o correto.

Change of Address: só para domínio ou subdomínio novo

O Change of Address, no Search Console, só é necessário quando a mudança é de domínio ou subdomínio. Envie a ferramenta no site antigo e, em migrações de domínio, para todas as variantes verificadas do domínio antigo, mesmo as que não estão em uso.

A ferramenta não é necessária para HTTP→HTTPS, para troca entre www e não-www no mesmo domínio nem para mudança de caminhos dentro do mesmo domínio.

Com os redirecionamentos ativos, confira as anotações rel="canonical" e as regras noindex do site novo — as que existiam só para evitar indexação prematura precisam sair. Teste os redirecionamentos com a ferramenta de inspeção de URL, para casos individuais, ou com scripts, para grandes volumes.

Mantenha os redirecionamentos por pelo menos um ano, período em que o Google transfere os sinais para as novas URLs e recrawleia links externos antigos. Do ponto de vista do usuário, considere mantê-los indefinidamente. Envie o novo sitemap; o sitemap antigo pode ser removido neste ponto.

Atualize links e monitore as duas versões

Assim que a virada começar, atualize links internos, links de perfis (Facebook, Twitter, LinkedIn) e campanhas de anúncio. Para links externos, contate os sites da lista salva na etapa de mapeamento, priorizando os que geram mais visitas.

No Search Console, mantenha os dois sitemaps enviados: a contagem de páginas indexadas do sitemap antigo deve cair até zero, com alta correspondente no novo. Avisos de que as URLs do sitemap antigo redirecionam são esperados. Acompanhe também o relatório de indexação de páginas e o de consultas.

Fora do Search Console, monitore logs de acesso e erros, procurando rastreamento do Googlebot e códigos de erro inesperados. Use o analytics em tempo real para ver o tráfego migrar do site antigo para o novo.

Espere oscilação temporária de posições. Em sites de médio porte, pode levar algumas semanas ou mais até o Google mostrar as novas URLs; em sites grandes, mais tempo. O prazo depende do número de URLs e da velocidade do servidor. Se a queda demorar a reverter, veja como investigar queda de tráfego orgânico.

Erros comuns que travam a indexação

A documentação lista as falhas mais frequentes:

• Esquecer de remover bloqueios noindex ou de robots.txt criados só para a migração.
• Redirecionar para URLs erradas ou inexistentes no site novo.
• Ignorar o aumento de erros de rastreamento no relatório de indexação.
• Subdimensionar a capacidade do servidor.
• Não atualizar os sitemaps com as novas URLs.

O que fazer agora

1. Escolha a janela de menor tráfego e faça uma mudança por vez.
2. Monte o mapa de URLs antigas → novas, incluindo imagens, vídeos, JavaScript e CSS.
3. Ligue os redirecionamentos 301/308 no servidor, direto ao destino final. Nunca mande tudo para a home.
4. Remova o noindex e os bloqueios de robots.txt criados para o desenvolvimento, e envie o novo sitemap.
5. Envie o Change of Address se houver troca de domínio ou subdomínio.
6. Acompanhe Search Console, logs e analytics nas duas versões. Mantenha os redirecionamentos por ao menos um ano.