Migrar o site sem perder SEO: o plano de antes, durante e depois

Trocar de plataforma ou refazer o site não derruba posição por si só. O que derruba é o que se perde no caminho: endereços que passam a dar 404, um bloqueio do ambiente de teste que vai junto para o ar, o texto da categoria que morava num campo do tema antigo e ficou para trás. Este guia trata da mudança feita no mesmo domínio: sair do WordPress para a Shopify, da Tray para a Nuvemshop, de um site feito à mão para o Wix, ou redesenhar o site e reorganizar os endereços. Se o domínio também vai mudar, some ao plano abaixo os passos da troca de domínio e a ferramenta Alteração de endereço.

O que uma migração mexe que o Google percebe?

Três coisas: o endereço de cada página, o modelo que monta a página e o HTML que o servidor entrega. A troca de plataforma costuma mexer nas três de uma vez. Cada plataforma monta o caminho de produtos e categorias do seu jeito, então quase todo endereço de loja muda. O tema novo decide onde ficam o title, o H1, o texto e os dados estruturados. E o servidor novo pode entregar mais ou menos conteúdo antes de o JavaScript rodar.

O redesenho sem troca de plataforma mexe no modelo e, às vezes, nos endereços. A troca só de hospedagem, com a mesma plataforma e os mesmos endereços, é o caso mais leve: para o Google, é o mesmo site em outro servidor.

As orientações do Google para quem vai mudar o site pedem as alterações uma depois da outra, e não todas ao mesmo tempo. Traduzindo para o dia a dia de uma loja: se a troca de plataforma está marcada para novembro, deixe a reescrita das descrições e a nova árvore de categorias para quando o tráfego assentar. Se a curva cair, você vai saber de onde veio a queda.

Como fazer o inventário das URLs antes da troca?

Junte numa planilha todos os endereços que existem hoje e marque os que trazem visita ou recebem links de fora. O Google sugere várias fontes, e cada uma pega o que a outra deixa escapar:

• O sitemap atual. É a lista que o próprio site declara. Baixe o arquivo antes da troca, porque a plataforma nova vai gerar outro no mesmo endereço e o antigo some.
• O Search Console. Em Desempenho, a aba Páginas mostra quais endereços tiveram cliques; escolha o período mais longo e use o botão Exportar. Em Links, a tabela Principais páginas vinculadas mostra as páginas que outros sites apontam. A Ajuda avisa que essas tabelas param em mil linhas e não trazem todos os links.
• O Analytics ou os logs do servidor. Mostram as páginas de entrada com mais visitas, inclusive as que recebem gente de campanha, e-mail ou do QR code impresso na embalagem, tráfego que o Search Console não enxerga.
• Um rastreamento. Uma ferramenta que segue os links do site acha páginas que ficaram fora do sitemap.
• O painel da plataforma. A exportação de produtos e páginas traz o que existe no cadastro, mesmo o que não aparece no menu.

Inclua imagens e PDFs. Se a foto do produto aparece na busca de imagens ou o catálogo em PDF circula em grupo de WhatsApp, esses arquivos também mudam de endereço na troca. A documentação do Google lembra de levar imagens e arquivos para download junto com as páginas.

Uma loja com 300 produtos chega fácil a mil linhas, somando categorias, filtros e páginas institucionais. Não dá para tratar todas com o mesmo cuidado, nem precisa. Ordene pela soma de cliques e links e trabalhe de cima para baixo. A exportação do Desempenho mostra quanto do tráfego cabe em poucas páginas, e essas são conferidas uma a uma.

O que registrar de cada página antes de desligar o site antigo?

Para as páginas do topo da planilha, guarde um retrato do que o robô lê hoje. Depois da troca, é esse retrato que mostra o que ficou para trás. No mínimo:

Quem sai do WordPress precisa de atenção redobrada aqui. Título e descrição escritos no Yoast ou no Rank Math ficam guardados no banco do WordPress, separados do produto, e só chegam à loja nova se a ferramenta de importação souber ler esses campos. Abra três produtos importados e confira antes de dar a importação por encerrada.

Para a parte técnica do retrato, rode agora a análise do site no validador, ainda na plataforma antiga. Ela lê cada página sem executar JavaScript, como um robô, e registra title, canonical, noindex, dados estruturados, robots.txt, sitemap e redirecionamentos. Com uma conta grátis, depois da troca você clica em Analisar de novo no mesmo domínio, e a tela de evolução do site separa o que foi corrigido do que piorou ou surgiu desde a primeira análise. Uma regra que passava e passou a falhar é a pista mais rápida de algo que a migração levou embora.

Para olhar o JSON-LD de uma página por vez, a ferramenta que lista os dados estruturados de um endereço mostra os tipos encontrados. Rode antes e depois nas mesmas três páginas: a inicial, uma categoria e um produto.

Como montar o mapa de redirecionamentos?

Ao lado de cada URL antiga, escreva o endereço novo equivalente e a decisão: 301 para o equivalente ou 404/410 quando a página acabou de vez. Três cuidados evitam a maior parte dos problemas:

1. Equivalente de verdade. Produto vai para o mesmo produto; categoria, para a mesma categoria. Mandar as sobras para a página inicial é o atalho que o Google pode tratar como soft 404.
2. Um salto só. Se o site já passou por outra mudança, ainda existem redirecionamentos velhos apontando para endereços que agora vão mudar de novo. Reescreva essas regras para levar direto ao destino final. Sem isso, a loja ganha uma cadeia: o endereço de 2019 leva ao de 2022, que leva ao de agora.
3. Regra por padrão, quando o servidor aceita. Se todos os produtos saem de /produto/nome para /produtos/nome, uma regra com curinga cobre o catálogo inteiro. A lista linha a linha fica para o que não segue padrão. Algumas plataformas só aceitam pares exatos de origem e destino; aí a planilha vira o arquivo de importação.

Onde e como cadastrar cada regra muda de um ambiente para outro, e o guia de redirecionamento tem o caminho do 301 no servidor e no painel de cada plataforma. O que vale aqui é a ordem: o mapa fica pronto e testado antes do dia da virada, e não "ao final da configuração", como alguns roteiros de migração sugerem.

Como testar o site novo sem que o Google ache antes da hora?

Proteja o ambiente de teste com senha. É o bloqueio que a documentação do Google indica para conteúdo que não deve aparecer na busca, e tem uma vantagem sobre os outros: não vai junto para o ar sem ninguém ver, porque uma loja que pede senha a cada visitante chama atenção no primeiro minuto.

O noindex e o Disallow: / no robots.txt também seguram o robô, mas são invisíveis para quem navega. O site novo abre normal, os pedidos entram, e o Google recebe a ordem de não indexar ou de não ler nada. A documentação de migração do Google põe exatamente esses dois bloqueios esquecidos na lista de problemas comuns e pede para retirá-los no lançamento. O robots.txt tem ainda um defeito como proteção de teste: ele impede a leitura, não a indexação, como explica o guia sobre o que o robots.txt bloqueia de fato e o que deixa passar.

Esse tipo de marcação fica no lugar sem que ninguém perceba. Na semana em que o Nota do Site estreou, em outubro de 2026, a gente leu 302 páginas de 53 sites .br, e 12 delas pediam noindex, espalhadas por 6 sites. Não temos como saber quantas vieram de um ambiente de teste, mas nenhuma delas dava sinal para quem abria a página no navegador.

O ambiente de teste deixa outros rastros além do bloqueio. Procure o nome do endereço provisório no código-fonte das páginas novas: ele costuma sobrar no canonical, no sitemap, na imagem de compartilhamento e em links internos escritos com o endereço completo.

Antes da virada, rode um rastreamento no ambiente protegido (as ferramentas de rastreamento aceitam login) e compare com o retrato do site antigo. Teste também, ainda no ambiente de teste, uma amostra do mapa de redirecionamentos.

O que conferir no dia da virada?

Assim que o domínio passar a apontar para a plataforma nova, abra o site como um robô abriria. A ordem abaixo vai do erro que derruba tudo ao que tira pontos aos poucos:

1. robots.txt. Abra /robots.txt no domínio final. Nada de Disallow: / para todos os robôs, e a linha Sitemap: apontando para o sitemap novo. O testador de robots.txt diz se um endereço específico está liberado.
2. noindex. Veja o código-fonte da inicial, de uma categoria e de um produto e procure noindex. O cabeçalho X-Robots-Tag não aparece no código-fonte; para ele, use curl -I no endereço.
3. Canonical. Cada página aponta para si mesma, com https e no domínio final. No levantamento de outubro, 41 das 302 páginas (14%) tinham canonical para outro endereço. Às vezes é de propósito; numa migração, é onde o endereço de teste ou a URL antiga costumam se esconder.
4. Redirecionamentos. Rode curl -sIL nas vinte URLs do topo da planilha: a primeira resposta tem de ser 301 e a cadeia tem de terminar numa página 200 depois de um único salto. Teste também o domínio sem www (ou com www, se o principal for o curto), porque a troca de plataforma mexe no DNS dos dois. Em 7 de 52 sites do levantamento (13%), a versão secundária abria como site separado, e em 5 ela redirecionava com código temporário.
5. Sitemap. Só com os endereços novos, enviado em Indexação > Sitemaps. Segundo o Google, o sitemap antigo pode sair, porque o novo passa a valer. No levantamento, 9 dos 53 sites não tinham sitemap nenhum.
6. Texto sem JavaScript. Alguns temas montam a descrição do produto no navegador, e quem não executa JavaScript recebe a página sem ela. Das 302 páginas, 18 chegavam com zero palavras no HTML. Se o seu tema faz isso, veja como conferir se o conteúdo chega ao robô antes do JavaScript.
7. Retrato. Compare title, H1, texto, canonical e dados estruturados das páginas do topo com o que você anotou.
8. Medição. Confira a tag do Analytics e a verificação do Search Console. A propriedade de domínio, verificada por um registro TXT no DNS, continua valendo enquanto o registro estiver lá; se a troca mudar o provedor de DNS, recrie o TXT no novo. A verificação por arquivo HTML ou meta tag sai junto com o tema antigo.
9. Endereço provisório. Veja se a loja antiga continua abrindo no subdomínio que a plataforma antiga dava, e se o endereço provisório da nova redireciona para o domínio. Qualquer um dos dois aberto, com o mesmo conteúdo, é uma cópia do seu site no ar.

Quanto tempo acompanhar, e o que é oscilação normal?

Acompanhe de perto até a maior parte das páginas trocar de endereço no índice, o que leva algumas semanas num site de porte médio e mais num site grande, pela estimativa do Google. Os redirecionamentos ficam no ar pelo maior tempo possível, e o Google fala em pelo menos um ano.

Um calendário que funciona para loja e para site de empresa:

• Primeiras 48 horas. Inspeção de URL nas dez páginas que mais traziam visita, com o teste ao vivo. Relatório de robots.txt nas configurações do Search Console. Tempo real do Analytics para ver se as visitas continuam sendo contadas.
• Primeira semana. Indexação > Páginas e o status do sitemap novo. Na troca de servidor, o Google avisa que o rastreamento pode cair logo depois do lançamento e subir nos dias seguintes, às vezes acima do nível de antes.
• Da segunda à sexta semana. Desempenho, aba Páginas, comparando com o mesmo intervalo antes da troca.
• Terceiro mês. Analise o site de novo no validador e abra os relatórios de Compras e Melhorias do Search Console, que mostram se o Google continua achando a marcação de produto e de navegação.

Para separar o susto do problema:

Se a queda continuar depois do prazo que o Google estima, ou pegar o site inteiro, siga o roteiro para achar a causa de uma queda no Google antes de mexer em conteúdo.

E se for só um redesenho, sem trocar de plataforma?

O plano encolhe, mas o retrato continua valendo. Com os mesmos endereços, não há mapa de redirecionamento, e é a comparação página a página que pega as perdas típicas de um layout novo: o H1 virou imagem, o texto da categoria foi para uma aba que só carrega com clique, o menu deixou de linkar as subcategorias, duas páginas institucionais viraram uma. Se algum endereço mudar no redesenho, ele entra no mapa como numa troca de plataforma.

Se a mudança for só de hospedagem, o Google tem um roteiro mais curto: baixar o TTL do DNS para algumas horas pelo menos uma semana antes, confirmar com a Inspeção de URL que o Googlebot consegue acessar o servidor novo, tirar os bloqueios de teste e só então trocar o DNS. A hospedagem antiga é desligada quando os logs dela mostrarem que ninguém, nem o robô, chega mais por lá.

Qual a primeira tarefa se a data da migração já está marcada?

Hoje, enquanto o site antigo ainda está no ar: exporte Desempenho e Links do Search Console, baixe o sitemap e rode a primeira análise no validador com uma conta, para que a comparação do depois tenha com o que comparar. Depois, ponha na agenda quatro datas: o dia da virada, com a lista de nove itens acima; o fim da primeira semana; a sexta semana; e o terceiro mês, quando você clica em Analisar de novo e lê o que piorou.