Migração de site sem perder tráfego: o guia de SEO

Migração de site é onde o tráfego orgânico vai morrer — quando feita errado. Trocar de domínio, refazer a plataforma, mudar a estrutura de URLs ou simplesmente "modernizar o site" são operações que, sem o cuidado de SEO certo, jogam fora anos de autoridade acumulada da noite para o dia. E o pior: a queda muitas vezes só aparece semanas depois, quando já é difícil descobrir o que quebrou.

A boa notícia é que migração bem planejada preserva o tráfego — e às vezes até melhora, porque é a oportunidade de corrigir problemas técnicos antigos. Este é o guia que seguimos, do planejamento ao monitoramento pós-lançamento.

O que conta como migração

Muita gente associa "migração" só a troca de domínio, mas o conceito é mais amplo — e qualquer um destes casos exige o mesmo cuidado de SEO:

Troca de domínio (empresa.com.br → novamarca.com.br).
Mudança de plataforma (de WordPress para Next.js, por exemplo).
Mudança na estrutura de URLs (de ?id=42 para /produto/nome, ou reorganização de categorias).
Redesign que altera URLs, conteúdo ou arquitetura de informação.
HTTP → HTTPS ou www → sem-www (sim, isso é uma migração).
Consolidação de vários sites em um só.

Se as URLs ou o HTML que o Google indexou vão mudar, é uma migração — e o risco existe.

O coração de tudo: o mapa de redirects

A peça mais crítica de qualquer migração é o mapa de redirecionamentos: uma correspondência de cada URL antiga para a sua nova URL equivalente, servida com um redirect 301 (permanente). É o 301 que transfere a autoridade (os "sinais de ranking") da página antiga para a nova.

Regras inegociáveis:

1 para 1, sempre que possível. Cada URL antiga deve apontar para a página nova mais equivalente em conteúdo — não para a home. Redirecionar tudo para a home é o erro clássico que destrói o tráfego: o Google trata isso como "soft 404" e perde os sinais.
301, não 302. O 302 é temporário e não transfere autoridade de forma confiável. Use 301 para mudanças permanentes.
Sem cadeias de redirect. URL antiga → nova, direto. Evite A → B → C; cada salto perde força e adiciona latência.
Cubra tudo. Exporte a lista completa de URLs indexadas (do sitemap antigo, do Search Console, dos logs do servidor e de uma ferramenta de crawl) antes de migrar. URL esquecida vira 404 e tráfego perdido.

O que preservar

Além dos redirects, vários elementos precisam sobreviver à migração:

Conteúdo. Não é hora de "enxugar" textos. Páginas que ranqueiam ranqueiam por causa do conteúdo — cortá-lo na migração derruba as posições. Mude o design, preserve a substância.
Estrutura de URLs, quando der. Se a plataforma nova permite manter os mesmos caminhos, mantenha. A migração mais segura é a que muda o mínimo de URLs.
Metadados. Títulos, descriptions, canonicals e Open Graph precisam ser recriados na plataforma nova. É comum perdê-los numa troca de CMS.
Dados estruturados. O JSON-LD (Organization, Article, BreadcrumbList, etc.) precisa ser reimplementado, ou você perde os rich results.
Linking interno. Atualize os links internos para apontar direto para as URLs novas — não para as antigas que redirecionam. Links internos para URLs com redirect desperdiçam força.
hreflang e canonical. Em sites multi-idioma, as anotações de hreflang e os canonical precisam ser recriados e validados na estrutura nova — com reciprocidade.

Checklist de pré-lançamento

Antes de virar a chave, em um ambiente de staging:

Crawl completo do site antigo para inventariar todas as URLs, títulos, metadados e status.
Mapa de redirects pronto e revisado, cobrindo 100% das URLs indexadas.
Conteúdo e metadados migrados e conferidos página a página nas mais importantes.
Staging bloqueado para indexação (noindex ou autenticação) — para o Google não indexar o ambiente de teste por engano. E não esqueça de remover esse bloqueio no lançamento (é o erro fatal mais comum).
Sitemap novo gerado, com as URLs novas e absolutas.
Validação técnica: Core Web Vitals, renderização (conteúdo no HTML inicial), dados estruturados no Rich Results Test.

Lançamento

No dia da virada:

Publique os 301s junto com o site novo, no mesmo momento. As URLs antigas precisam redirecionar a partir do segundo zero.
Remova o bloqueio de indexação do site novo (o noindex de staging).
Atualize o robots.txt e confirme que o sitemap aponta para as URLs novas.
Envie o sitemap novo no Search Console. Em troca de domínio, use a ferramenta de Mudança de Endereço do Search Console — ela avisa o Google formalmente.
Mantenha o domínio antigo (e os redirects) no ar por bastante tempo — meses, idealmente. Desligar cedo demais mata os redirects e o tráfego que ainda chega por eles.

Monitoramento pós-lançamento

A migração não termina no deploy. Nas semanas seguintes:

Cobertura de indexação no Search Console: acompanhe as URLs novas sendo indexadas e as antigas saindo. Vigie picos de 404 e de "soft 404".
Erros de rastreamento e redirects: confirme que não surgiram cadeias ou loops de redirect.
Posições e tráfego orgânico: uma oscilação nas primeiras semanas é normal (o Google reprocessa o site). Uma queda que não se recupera em 4–6 semanas é sinal de problema — geralmente um redirect faltando ou conteúdo perdido.
Core Web Vitals: valide que a plataforma nova não regrediu a performance.

Tipos de redirect: qual usar em cada caso

Nem todo redirect é igual, e usar o tipo errado custa autoridade:

301 (movido permanentemente). O padrão de toda migração. Sinaliza que a mudança é definitiva e transfere os sinais de ranking para a URL nova. Use-o para todas as URLs antigas → novas.
308 (redirecionamento permanente). Equivalente ao 301 para SEO, com a diferença técnica de preservar o método HTTP (POST continua POST). O Google trata os dois da mesma forma.
302 (encontrado / temporário). Sinaliza que a mudança é temporária e que a URL antiga voltará. Não transfere autoridade de forma confiável. Usar 302 numa migração permanente é um dos erros mais comuns — o Google pode continuar indexando a URL antiga indefinidamente.
Meta refresh e redirect via JavaScript. Evite. São lentos, mal interpretados pelos crawlers e prejudicam a experiência. Redirect de servidor (301/308) é sempre superior.

A regra prática é simples: migração definitiva = 301 (ou 308). Qualquer outra coisa é exceção que precisa de justificativa.

Quanto tempo leva para o tráfego se estabilizar

Essa é a pergunta que mais gera ansiedade — e onde mais se toma decisão errada por pânico. Depois de uma migração bem-feita, o normal é:

Primeiros dias: o Google começa a rastrear as URLs novas e a processar os redirects. Pode haver oscilação nas posições.
2 a 4 semanas: a maior parte do índice é atualizada. Em troca de domínio, a ferramenta de Mudança de Endereço acelera esse processo.
4 a 8 semanas: o tráfego se estabiliza no novo patamar. Uma migração bem-executada recupera o nível anterior; uma com problemas mostra uma queda que não se recupera.

O erro clássico é entrar em pânico na segunda semana, ver a oscilação normal e começar a "consertar" coisas que não estavam quebradas — mudando redirects, alterando conteúdo, criando ainda mais instabilidade. A disciplina aqui é: planeje bem antes, monitore com calma depois, e só intervenha com base em dados (404s reais, redirects faltando, conteúdo perdido), não em medo.

Se passadas 6–8 semanas o tráfego não voltou, aí sim há algo a investigar — e quase sempre é uma das causas da próxima seção.

Os erros que mais derrubam tráfego

Redirecionar tudo para a home em vez de mapear 1 para 1.
Esquecer URLs que não estavam no sitemap mas tinham tráfego e backlinks.
Deixar o noindex de staging vazar para produção no lançamento.
Desligar o domínio/redirects antigos cedo demais.
Cortar conteúdo das páginas que ranqueavam, em nome do "site mais limpo".
Cadeias de redirect acumuladas de migrações anteriores.

A maioria desses erros é invisível no dia do lançamento — o estrago só aparece nas semanas seguintes, quando a recuperação é mais difícil. Por isso a migração é tão arriscada sem um plano e um monitoramento dedicados.

Um cronograma realista

Migrações dão errado quando são tratadas como um evento de um dia. Na prática, um cronograma saudável se parece com isto:

Semanas -4 a -3 (preparação). Crawl completo do site atual, inventário de URLs com tráfego e backlinks, e construção do mapa de redirects 1 para 1. É a fase mais demorada e a que mais previne desastre.
Semanas -2 a -1 (staging). Site novo montado em ambiente bloqueado para indexação, com conteúdo, metadados, dados estruturados e hreflang migrados e conferidos. Validação técnica (renderização, Core Web Vitals, Rich Results Test) e teste dos redirects em staging.
Dia 0 (lançamento). Virada com os 301s ativos no mesmo momento, remoção do bloqueio de indexação, sitemap novo enviado e — em troca de domínio — a Mudança de Endereço acionada no Search Console. Idealmente fora do pico de tráfego, com a equipe disponível para reagir.
Semanas +1 a +8 (monitoramento). Acompanhamento diário no início, depois semanal: cobertura de indexação, 404s, redirects, posições e Core Web Vitals. Intervenção só com base em dados.

Migrações grandes (e-commerce com milhares de URLs, consolidação de sites) merecem ainda uma fase piloto: migrar uma seção pequena primeiro, validar que o tráfego se comporta como esperado, e só então mover o resto.

Ferramentas que ajudam

Você não precisa fazer isso no escuro. O kit mínimo:

Um crawler (Screaming Frog, Sitebulb ou similar) para inventariar URLs, status, títulos, metadados e links internos — antes e depois.
Google Search Console para a lista de URLs indexadas, a ferramenta de Mudança de Endereço, o relatório de cobertura e os Core Web Vitals de campo.
Logs do servidor para ver quais URLs o Googlebot realmente visita — fonte de URLs que não aparecem em mais lugar nenhum.
Uma ferramenta de backlinks para identificar quais páginas antigas têm links externos (essas são prioridade máxima no mapa de redirects — é a autoridade que você não pode perder).
Um verificador de redirects em lote para confirmar, depois do lançamento, que cada URL antiga responde com 301 para a nova certa, sem cadeias.

A combinação dessas fontes é o que garante que o mapa de redirects cubra 100% das URLs que importam — não só as que estavam no sitemap.

Conclusão

Migrar não precisa custar tráfego. O segredo está no básico bem-feito: um mapa de redirects 301 completo e 1 para 1, a preservação de conteúdo, metadados, dados estruturados e linking interno, um lançamento sincronizado e um monitoramento atento nas semanas seguintes. Feita assim, a migração não só preserva a autoridade como vira a chance de corrigir a dívida técnica que vinha segurando o site.

Pronto para o respawn?

Se você está planejando uma migração — ou já fez uma e o tráfego caiu —, dá para mapear o que preservar e o que recuperar. Peça uma auditoria gratuita — em até 7 dias você recebe um diagnóstico priorizado por impacto e esforço, sem compromisso.