Pular para o conteúdo
Plugfy
Desenvolvimento

Migração de site: o checklist para trocar de site sem derrubar o tráfego

Por Equipe Plugfy · 21 de abr de 2026 · 6 min de leitura

O padrão se repete com frequência desconfortável. Site novo no ar, layout melhor, carregamento mais rápido, time satisfeito. Três semanas depois, o tráfego orgânico caiu pela metade e ninguém sabe explicar.

Na quase totalidade dos casos, a causa é a mesma: a migração de site foi tratada como um projeto de design, e não como uma operação técnica com consequências de indexação. As páginas antigas sumiram sem apontar para as novas, e o Google levou junto as posições que levaram anos para ser conquistadas.

A boa notícia é que esse resultado é evitável com um checklist. Nada aqui é sofisticado — é disciplina de execução, feita antes de o site novo entrar no ar.

O que conta como migração de site

Quatro situações diferentes exigem os mesmos cuidados, e as pessoas costumam subestimar as duas últimas.

  • Troca de domínio — o endereço muda, o conteúdo permanece.
  • Redesenho com nova estrutura — o domínio permanece, as URLs mudam.
  • Troca de plataforma — o CMS muda e, junto, o padrão de endereços.
  • Consolidação de sites — dois ou mais domínios viram um.

Em qualquer uma delas, o risco não vem do tamanho da mudança visual. Vem de quantas URLs deixam de existir no formato antigo. Um site redesenhado que mantém todos os endereços tem risco baixo. Um site com o mesmo visual que troca /produtos/nome por /p/12345 tem risco alto.

Passo 1: inventário completo das URLs atuais

Toda migração de site começa aqui, e pular esta etapa é a origem da maior parte dos problemas que aparecem depois. Você precisa da lista do que existe hoje. Ela vem de quatro fontes, e as quatro são necessárias porque nenhuma é completa sozinha.

O sitemap atual dá as páginas que o CMS conhece. O relatório de páginas do Search Console dá as que o Google indexou de fato, incluindo as que ninguém lembrava. O analytics dá as que recebem tráfego. E um rastreamento do site com qualquer crawler dá as que estão linkadas internamente.

Junte tudo em uma planilha, remova duplicatas e ordene por tráfego dos últimos doze meses. Essa ordem define a prioridade de atenção: as cinquenta primeiras linhas respondem pela maior parte do risco.

Vale migrar todas as páginas?

Não necessariamente. Páginas sem tráfego, sem links externos e sem função comercial podem ser descontinuadas — mas de forma consciente, retornando 410 ou redirecionando para a categoria correspondente. O erro é deixá-las simplesmente virar 404 sem ninguém decidir isso.

Passo 2: preservar URLs sempre que possível

A forma mais barata de fazer uma migração de site sem perder tráfego é não mudar os endereços.

Manter a URL elimina redirecionamento, elimina cadeia, elimina perda de sinal e elimina o período de reavaliação. Se a estrutura atual é razoável — legível, sem parâmetros estranhos, com hierarquia clara — mantê-la é quase sempre a decisão certa, mesmo que o site novo seja completamente diferente por dentro.

Só vale alterar quando a estrutura atual atrapalha: endereços com parâmetros, duplicações, hierarquia que não reflete a navegação. Nesses casos, mude tudo de uma vez e faça o mapa completo. O que não funciona é mudar metade por gosto pessoal.

Passo 3: o mapa de redirecionamentos 301

Este é o item central de qualquer migração de site. Cada URL antiga precisa de uma linha na planilha com o destino novo correspondente.

Cinco regras evitam quase todos os problemas:

  • Um para um sempre que houver equivalente. Redirecionar tudo para a home é o erro clássico: o Google trata isso como página inexistente e o sinal se perde.
  • Sem cadeias. Se /a aponta para /b e /b aponta para /c, corrija /a para apontar direto para /c.
  • Código 301, não 302. O 302 indica mudança temporária e não transfere sinal da mesma forma.
  • Preserve os parâmetros que importam e descarte os que geram duplicação.
  • Teste antes de publicar, em ambiente de homologação, com a planilha inteira.

Quando não existe equivalente direto, redirecione para a página mais próxima em tema — a categoria pai, o produto substituto, o artigo mais relacionado. Um destino aproximado é melhor que um 404, desde que não seja a home.

Quantos redirecionamentos são demais?

Não há limite prático que preocupe em sites comuns. O problema não é a quantidade, e sim a cadeia e o tempo de resposta. Redirecionamentos processados no servidor, em uma tabela, custam milissegundos. Redirecionamentos implementados via JavaScript no navegador custam muito mais e devem ser evitados.

Passo 4: manter títulos, conteúdo e links internos

Redirecionar corretamente e esvaziar a página de destino não resolve nada. Se /servico-x apontava para um texto de 900 palavras e passa a apontar para uma página com três parágrafos, a posição cai mesmo com o 301 perfeito.

Preserve três coisas nas páginas que já ranqueavam: o conteúdo em extensão e profundidade equivalentes, os títulos e cabeçalhos que já funcionavam, e a estrutura de links internos que apontava para elas.

O terceiro item é o mais esquecido. Uma página pode manter a URL e o texto, e ainda assim perder força porque o menu novo não a linka mais, ou porque os links do rodapé mudaram. A distribuição interna de autoridade é parte do que sustentava a posição — e é uma das razões pelas quais o mapa de páginas deve ser definido no início, como acontece quando o site nasce já pensado para busca.

Passo 5: o que fazer no dia da virada

Uma sequência curta, na ordem:

  1. Confirmar que nenhuma tag noindex de homologação foi para produção.
  2. Verificar o robots.txt do ambiente novo — o de teste costuma bloquear tudo.
  3. Publicar com os redirecionamentos já ativos, não depois.
  4. Gerar o sitemap XML novo e enviá-lo no Search Console.
  5. Manter o sitemap antigo acessível por algumas semanas, para acelerar a descoberta das URLs que mudaram.
  6. Se houve troca de domínio, usar a ferramenta de alteração de endereço do Search Console.
  7. Confirmar que analytics e tags de conversão estão medindo.

Reserve também o ambiente antigo por algumas semanas, ligado e acessível internamente. Ele é o seu seguro: sem ele, uma migração de site que deu errado não tem para onde voltar.

Os itens 1 e 2 respondem por uma parcela grande dos desastres. Um noindex esquecido remove o site inteiro do índice em dias, e o sintoma demora a ser percebido porque nada quebra visualmente.

Passo 6: monitorar nas primeiras semanas

Depois da virada, quatro relatórios importam.

Cobertura de páginas no Search Console. Acompanhe a curva de indexadas contra não indexadas. Um aumento de erros 404 aponta redirecionamento faltando.

Desempenho por página. Compare as trinta URLs de maior tráfego antes e depois. Quedas isoladas indicam problema específico; queda geral indica problema estrutural.

Log de 404 do servidor. É a fonte mais rápida para descobrir o que ficou de fora do mapa.

Core Web Vitals de campo. Site novo pode ter regressão de performance que só aparece com usuários reais.

Olhe esses quatro por pelo menos oito semanas. Antes disso, oscilação não significa nada.

Quanto tempo até dar para relaxar?

Duas semanas de estabilidade nos quatro relatórios acima costumam indicar que a migração de site foi bem executada. Antes disso, número ruim pode ser apenas rastreamento em andamento.

Os erros que mais derrubam tráfego

  • Redirecionar tudo para a home.
  • Publicar com noindex de homologação.
  • Trocar URLs sem necessidade, junto com o redesenho.
  • Encurtar o conteúdo das páginas que ranqueavam.
  • Esquecer versões alternativas: com e sem www, HTTP e HTTPS, com e sem barra final.
  • Deixar o sitemap antigo apontando para URLs mortas por meses.

O quinto item é traiçoeiro porque o site parece funcionar. Só que cada variação não tratada vira uma URL concorrente da versão correta, e o sinal se divide.

Já caiu: como reverter

Se a queda aconteceu, siga na ordem. Exporte a lista de 404 do Search Console e do servidor e cruze com o inventário original — o que estiver na lista antiga e não na nova precisa de 301. Verifique noindex e robots.txt em produção. Compare o conteúdo das dez páginas que mais perderam com a versão anterior, recuperada do cache ou do backup. Confira as versões alternativas de domínio.

Na maioria dos casos, esses quatro passos explicam a queda inteira. A recuperação não é imediata: o Google precisa rastrear de novo para reavaliar, e isso leva semanas. Se depois das correções o site continuar fora do índice, o problema é outro — vale investigar as causas de um site não aparecer nos resultados antes de mexer em mais alguma coisa.

Quando a queda vem acompanhada de outros sintomas, como páginas lentas ou rastreamento incompleto, o diagnóstico pertence à camada técnica que sustenta a indexação, e não à troca em si.

Uma migração de site bem executada é invisível: o tráfego oscila por duas ou três semanas e volta ao patamar anterior, às vezes acima dele, quando o site novo é mais rápido. Se você está planejando essa troca e quer que ela seja conduzida com esse cuidado, nossa página de desenvolvimento de sites com SEO descreve como tratamos a etapa de redirecionamentos dentro do projeto.

Perguntas frequentes

É normal cair de tráfego depois de trocar de site?
Uma oscilação de poucas semanas é comum, porque o Google precisa rastrear e reavaliar todas as URLs novas. Queda grande e persistente não é normal: indica redirecionamento faltando, conteúdo perdido ou bloqueio de indexação. A diferença aparece nos dados do Search Console.
Quanto tempo leva para o tráfego se estabilizar?
Em sites pequenos, algumas semanas. Em sites grandes, dois a três meses, porque o rastreamento completo é mais lento. O prazo depende de quantas URLs mudaram e da frequência com que o Google visita o domínio.
Preciso mudar as URLs quando troco de plataforma?
Não, e o ideal é não mudar. Manter os mesmos endereços elimina a maior fonte de risco do processo. Só vale alterar quando a estrutura atual é claramente ruim, e nesse caso o mapa de redirecionamentos precisa ser completo.
Dá para reverter se o tráfego cair muito?
Dá, se você preservou o site antigo e o backup do banco. Por isso o ambiente anterior deve ficar disponível por algumas semanas depois do lançamento. Na maioria dos casos, porém, corrigir redirecionamentos resolve mais rápido do que voltar atrás.
Posso aproveitar a troca para reescrever todo o conteúdo?
Pode, mas evite fazer as duas coisas juntas. Se a estrutura e o texto mudam ao mesmo tempo e o tráfego cai, você não consegue identificar a causa. Troque primeiro, estabilize, depois reescreva.
Desenvolvimento

Quer isso aplicado ao seu site?

Conversa gratuita de 30 minutos com três correções priorizadas.