Migrar a loja para outra plataforma costuma ser uma decisão de produto, de custo ou de operação. O Google não participa dela, mas é quem vai avaliar o resultado. Cada URL antiga que deixa de responder, cada tag noindex esquecida e cada redirecionamento mal mapeado vira, na prática, venda orgânica que não chega.
O ponto de partida deste guia é a documentação do Google Search Central sobre mudanças de site com alteração de URL. Ela afirma que o Google precisa visitar cada URL antiga e nova ao menos uma vez e que a mudança acontece por URL, sem frequência fixa de rastreamento. Ou seja: oscilação é esperada, e o que se controla é o tamanho dela. Um exemplo extremo está na nossa notícia sobre um publisher que perdeu 98% de visibilidade após migrar de domínio.
Abaixo está um checklist de migração de plataforma SEO em três fases (antes, durante e depois), com tabela de riscos, exemplo de planilha de mapeamento com números, erros comuns e FAQ. O foco é e-commerce no Brasil.
Tipos de migração e o risco de cada um
“Migração” abrange situações bem diferentes. O Google separa as que alteram URLs das que não alteram (como troca de hospedagem ou CDN). A regra de ouro da documentação é mudar uma coisa de cada vez, sempre que possível.
| Tipo | O que muda | Risco para SEO | Cuidado principal |
|---|---|---|---|
| Plataforma (ex.: WooCommerce para VTEX) | Código, templates, estrutura de URL, dados estruturados | Alto | Mapeamento 1:1, paridade de conteúdo e metadados |
| Domínio | Hostname inteiro | Alto | 301 para todas as URLs e Mudança de endereço no Search Console |
| Estrutura de URL | Caminhos de categorias e produtos | Médio a alto | Mapa de redirecionamentos e links internos atualizados |
| Design / front-end | Layout, componentes, navegação | Médio | Manter conteúdo, links internos e desempenho |
| HTTP para HTTPS | Protocolo | Baixo a médio | Redirecionar, certificado válido, canonical e sitemap atualizados |
| Hospedagem / CDN | Servidor, sem mudar URLs | Baixo a médio | TTL do DNS, firewall sem bloquear o Googlebot |
As classificações de risco são avaliação da Analytikos, não dado do Google. O que o Google registra é o princípio: quanto mais coisas mudam juntas, mais difícil isolar a causa de uma queda. Uma migração de plataforma quase sempre combina três tipos (plataforma, URL e design), por isso exige mais disciplina.
Fase 1: antes da migração
Benchmark pré-migração
Sem linha de base não há diagnóstico. Registre, ao menos 30 dias antes:
- Rastreamento completo do site atual (status HTTP, canonical, títulos, meta descriptions, H1, profundidade, links internos).
- URLs com mais cliques e impressões no Search Console, e com mais receita orgânica no GA4.
- Posição das 50 a 100 consultas que mais vendem.
- Sitemaps, robots.txt, dados estruturados e relatório de Core Web Vitals.
- Logs do servidor: frequência do Googlebot por tipo de URL.
Exemplo hipotético: uma loja fatura R$ 180.000 por mês em receita orgânica. Se ela perder 20% por um mês, a perda é 180.000 × 0,20 = R$ 36.000. Esse número ajuda a justificar o tempo gasto no mapeamento.
Mapeamento de URLs 1:1
A documentação do Google manda construir o mapa de URLs antigas para novas e sugere levantá-las em sitemaps, relatório de links do Search Console, logs, analytics e no CMS, incluindo imagens, CSS e JavaScript. Para produto, categoria e conteúdo editorial, a meta é uma URL antiga para uma URL nova equivalente. Convém ler também sobre boas práticas de URL antes de redefinir a estrutura.
Exemplo de planilha, com 4.800 URLs antigas indexáveis (números ilustrativos):
| URL antiga | Tipo | Ação | URL nova | Status esperado |
|---|---|---|---|---|
| /tenis-corrida-masculino-x200 | Produto | Redirecionar 1:1 | /tenis-corrida-masculino-x200 | 301 direto para 200 |
| /categoria/calcados/corrida | Categoria | Redirecionar 1:1 | /calcados/corrida | 301 direto para 200 |
| /produto/meia-esportiva-azul | Produto (variação) | Consolidar na pai | /meia-esportiva | 301 direto para 200 |
| /produto/camiseta-2019-descontinuada | Produto sem substituto | Retirar | (nenhuma) | 410 ou 404 |
| /blog/como-escolher-tenis | Conteúdo | Redirecionar 1:1 | /blog/como-escolher-tenis | 301 direto para 200 |
| /?s=tenis | Busca interna | Não migrar | (nenhuma) | noindex mantido |
Resumo do exemplo: 4.100 URLs com redirecionamento 1:1, 450 consolidadas em páginas pai e 250 retiradas, total 4.100 + 450 + 250 = 4.800. A taxa de redirecionamento é (4.100 + 450) / 4.800 = 94,8%, e a de equivalência exata é 4.100 / 4.800 = 85,4%. As 250 retiradas devem ser decisão consciente, não esquecimento.
Dois alertas da documentação do Google: evite mandar muitas páginas para a home, porque isso pode parecer soft 404; e evite cadeias, redirecionando direto ao destino final. O Googlebot segue até 10 saltos, mas o ideal é um único salto até o destino final.
Conteúdo, metadados e canonical
- Preserve títulos, meta descriptions, H1, textos de categoria, FAQs, avaliações e imagens com alt. Plataformas diferentes geram títulos automáticos diferentes, e isso pode derrubar CTR sem aparecer em nenhum erro técnico.
- Cada URL nova deve ter canonical autorreferenciado, conforme a documentação do Google. Se a mudança envolver domínios diferentes, veja canonical entre domínios e duplicatas.
- Reproduza dados estruturados (Product, Offer, BreadcrumbList, Organization) e valide os templates novos.
- Se houver hreflang, atualize as anotações para as URLs novas.
- Links internos: atualize para a URL final, sem depender de redirecionamento. A arquitetura de SEO para e-commerce ajuda a decidir categorias, filtros e paginação.
Robots.txt, noindex e staging
A documentação do Google lista como erro comum esquecer noindex e bloqueios de robots.txt usados na migração. Há uma sutileza: se o robots.txt bloqueia uma URL, o Googlebot nem a busca e nunca vê o noindex, como explica a página sobre bloqueio de indexação. Portanto, o ambiente de testes deve usar autenticação, e o checklist de lançamento precisa incluir a remoção de qualquer Disallow ou noindex herdado do staging.
Performance e Core Web Vitals
Compare LCP, INP e CLS do template novo com os atuais, em páginas de produto e categoria. Para sites que usam navegação por JavaScript, leia sobre soft navigation e Core Web Vitals em SPA. O servidor também precisa suportar mais rastreamento: segundo o Google, o rastreio aumenta após a migração, porque as URLs antigas redirecionam para as novas.
Search Console, GA4 e GTM
- Verifique todas as variantes (www, sem www, HTTP, HTTPS, subdomínios) e confirme que a verificação sobrevive ao novo código.
- Se o domínio muda, o Google exige propriedade dos dois domínios, com a mesma conta, e propriedade de domínio, para usar a ferramenta Mudança de endereço.
- Documente os eventos de e-commerce do GA4. O Google lista eventos recomendados como view_item, add_to_cart, begin_checkout e purchase. No guia de medição de e-commerce, o transaction_id é indicado como obrigatório em compras, e o currency deve acompanhar o value.
- Compare, em homologação, a receita registrada no GA4 com a do back-office. Divergência acima do que a loja já tinha antes da migração é sinal de evento quebrado ou duplicado.
Calendário, congelamento e janela de lançamento
O Google recomenda realizar a mudança em período de menor tráfego, quando possível. Em varejo, o pico é a Black Friday, em 27/11/2026. Em 20/10/2026, faltavam 38 dias (11 dias até 31/10 mais 27 em novembro). Lançar nessa distância deixa pouca margem para corrigir o que aparecer, e o Google leva semanas para processar mudanças de médio porte.
A recomendação da Analytikos: se a migração ainda não passou por homologação completa, adote o congelamento e adie o lançamento para depois do pico, normalmente janeiro. Se for inevitável, congele alterações de catálogo, templates e URLs ao menos 14 dias antes (13/11) e tenha rollback testado. O tema Black Friday tem o seu próprio planejamento de SEO, que complementa este checklist.
Fase 2: durante o lançamento
- Confirme que o novo ambiente responde com 200 e que robots.txt e meta robots estão corretos (sem noindex e sem Disallow de staging).
- Ative os redirecionamentos 301 no servidor. O Google prefere redirecionamentos permanentes no servidor (301 ou 308) e trata meta refresh e JavaScript como alternativas inferiores. Veja a página Redirecionamentos e Pesquisa Google.
- Teste uma amostra: top 100 URLs por receita e uma amostra aleatória do restante, via script (curl ou crawler) e Inspeção de URL.
- Envie o sitemap novo no Search Console. Segundo o Google, avisos de redirecionamento no sitemap antigo são esperados.
- Se houve troca de domínio, use a ferramenta Mudança de endereço depois do redirecionamento, em todas as variantes verificadas do domínio antigo. Ela não serve para HTTP para HTTPS, www para não-www ou mudança de caminhos.
- Valide GA4 e GTM em tempo real: view_item, add_to_cart, begin_checkout e uma compra de teste, com transaction_id, valor e moeda.
- Atualize links internos, perfis sociais, anúncios, feeds de Merchant Center e links externos de alto tráfego para a URL final.
Sobre a plataforma, só há fatos verificáveis quanto à interface de redirecionamento. Na Shopify, a ajuda oficial descreve importação por CSV e limite de 100.000 redirecionamentos por loja, e afirma que só URLs que retornam 404 podem ser redirecionadas. Na Nuvemshop, o passo a passo cobre o cadastro item a item (a página não menciona importação em lote), e o guia de migração cita que a importação automática de dados ainda não existe e que se deve evitar lançar em feriados e fins de semana. Na VTEX, os redirecionamentos ficam em Storefront > Redirects, aceitam importação de CSV com ponto e vírgula como separador e não encaminham parâmetros de query por padrão. Para WooCommerce, a configuração depende de plugin ou de regras no servidor, por isso verifique a documentação da solução escolhida.
Fase 3: depois da migração
| Janela | O que verificar | Onde |
|---|---|---|
| Dia 0 a 3 | Códigos 200/301/404/5xx, robots.txt, canonical, eventos de compra | Crawler, logs, GA4 em tempo real |
| Semana 1 | Relatório de páginas (indexação), soft 404, erros de servidor, sitemap | Search Console |
| Semanas 2 a 4 | Cliques e impressões por URL nova versus antiga, posição de consultas-chave | Search Console, benchmark |
| Mês 2 a 3 | Receita orgânica versus linha de base, páginas sem tráfego, redirecionamentos a corrigir | GA4, logs |
| Mês 12 | Decidir sobre redirecionamentos, mantendo os que ainda recebem tráfego | Logs, Search Console |
Comece pelos logs: eles mostram se o Googlebot recebe 301 e 200 nos lugares certos. Na indexação, a expectativa é que o número de URLs indexadas do site antigo caia e o do novo suba. Um soft 404, segundo o Google, é uma página que responde 2xx mas exibe vazio ou mensagem de erro; já 404 e 410 em URLs retiradas são tratadas como inexistentes e removidas do índice (conforme a página sobre erros HTTP).
Prazos de recuperação
O Google diz que, em sites pequenos e médios, a maior parte das páginas leva algumas semanas para ser movida, e sites maiores levam mais tempo. A documentação não promete retorno ao nível anterior de tráfego, apenas descreve flutuação temporária. Para o contexto geral, veja quanto tempo o Google leva para rastrear, indexar e recuperar. Quando a queda passa de algumas semanas, a causa costuma ser técnica: o plano de ação é buscar redirecionamentos quebrados, canonicals e bloqueios.
Sobre a retenção: o Google recomenda manter os redirecionamentos por pelo menos 1 ano, e a ferramenta de Mudança de endereço mantém sinais por 180 dias. Isso vale como piso, não como prazo de remoção.
Plano de rollback
- Defina antes quem decide, com qual gatilho (por exemplo, queda de pedidos orgânicos acima do limite combinado ou erro de checkout).
- Mantenha a plataforma antiga operando e com backup. O Google só pede para desligar a hospedagem antiga quando o tráfego chegar a zero, no caso de mudança de hosting sem URL nova.
- Em troca de domínio, o Google descreve o cancelamento da mudança de endereço em até 180 dias: remover os 301 do antigo para o novo, adicionar 301 do novo para o antigo e clicar em Cancelar mudança.
- Registre o procedimento por escrito e teste-o em homologação.
Erros comuns
Quase toda perda de tráfego em migração tem origem em um número pequeno de falhas repetidas. Os erros abaixo estão agrupados por natureza: de planejamento, de redirecionamento e indexação, de conteúdo e dados, de mensuração e de operação após o lançamento. Em cada um, a tabela explica por que acontece, qual o efeito e como corrigir.
Erros de planejamento e escopo
| Erro | Por que acontece | Efeito no resultado | Como corrigir |
|---|---|---|---|
| Mudar domínio, URLs, design e conteúdo no mesmo dia | Pressão para entregar tudo em um único projeto | Se o tráfego cair, não há como saber qual mudança causou a queda, e o rollback fica inviável | Separar em etapas sempre que possível. Quando não der, manter a linha de base e um plano de rollback por fase |
| Não registrar o benchmark antes da migração | Falta de tempo na fase 1 | Sem o “antes” não se diferencia queda por migração de sazonalidade ou de atualização do Google | Exportar cliques, impressões, receita orgânica e páginas principais por pelo menos 12 meses, e comparar com o mesmo período do ano anterior |
| Lançar perto de data de pico (Black Friday, Natal, Dia das Mães) | Calendário comercial dita o prazo técnico | Uma queda temporária cai exatamente no período de maior receita, sem janela para corrigir | Congelar alterações antes do pico e lançar com semanas de folga, ou adiar |
| Não envolver o SEO desde o início | A migração é tratada como projeto de TI | Problemas conhecidos (URLs, templates, canonical) só aparecem depois do lançamento | Incluir SEO nos requisitos, na homologação e na decisão de go-live |
Erros de redirecionamento e indexação
Exemplo para dimensionar o problema: uma loja com 12.000 URLs indexadas que redireciona todas para a home perde o mapeamento de cada página. Se 9.000 delas tinham tráfego orgânico individual, esse tráfego passa a depender de a home ranquear para consultas que nunca foram dela. O sinal de relevância de cada página se perde junto com a URL.
| Erro | Por que acontece | Efeito no resultado | Como corrigir |
|---|---|---|---|
| Mandar milhares de URLs antigas para a home | Atalho para “não deixar 404” | O Google tende a tratar o redirecionamento irrelevante como página não encontrada, e o tráfego e os links de cada página se perdem | Mapear 1:1 cada URL antiga para a equivalente mais próxima, e usar 404 ou 410 quando não houver correspondência |
| Cadeias de redirecionamento (HTTP para HTTPS, www, nova URL) | Regras de servidor, CDN e plataforma acumuladas em camadas | Lentidão, desperdício de rastreamento e risco de o robô desistir de seguir a cadeia | Redirecionar em um único salto, da URL antiga direto para a final. Testar uma amostra com rastreador |
| Usar 302 (temporário) em vez de 301 (permanente) | Padrão da plataforma ou do plugin | A migração pode demorar mais para ser reconhecida, e a URL antiga pode continuar indexada | Usar 301 para mudanças permanentes e conferir o código de status nos redirecionamentos em lote |
| Lançar com noindex ou Disallow do ambiente de staging | Configuração do teste vai para produção junto com o código | Páginas saem do índice, o robô é bloqueado e o tráfego orgânico pode cair a quase zero em poucos dias | Checklist de go-live com verificação de robots.txt, meta robots e cabeçalho X-Robots-Tag nos templates principais |
| Canonical apontando para o domínio antigo ou para o staging | Template migrado sem revisar a variável de URL | Os sinais continuam indo para a URL errada e a nova versão não é consolidada | Auditar o canonical autorreferente em todos os templates e rastrear uma amostra por tipo de página |
| Sitemap antigo ou com URLs que redirecionam | Arquivo antigo mantido por esquecimento | O sitemap passa a sugerir URLs que não deveriam ser rastreadas, e o diagnóstico no Search Console fica poluído | Enviar o sitemap novo apenas com URLs finais, com status 200 e indexáveis |
Erros de conteúdo e dados estruturados
| Erro | Por que acontece | Efeito no resultado | Como corrigir |
|---|---|---|---|
| Não migrar títulos, metas e textos de categoria | Foco no layout, não nos campos de SEO | Páginas que ranqueavam perdem relevância e CTR, sobretudo categorias, que dependem do texto | Exportar e importar título, meta, H1, texto e canonical por URL, e comparar antes e depois |
| Perder dados estruturados (Product, Offer, Review, Breadcrumb) | O novo tema não traz o schema do antigo | Perda de elementos nos resultados, como preço e avaliações, e queda de CTR | Validar o schema com o teste de resultados avançados em amostra de produtos, categorias e home |
| Alterar a estrutura de links internos e a navegação | Novo menu simplificado sem análise de links | Páginas importantes ficam mais profundas ou órfãs, com menos rastreamento | Comparar a profundidade de clique e os links internos por página antes e depois |
| Conteúdo renderizado só por JavaScript sem teste | Nova plataforma troca a renderização | O Google pode demorar mais para ver produtos e links, ou não vê-los | Testar a renderização das páginas principais com a inspeção de URL do Search Console |
Erros de mensuração
| Erro | Por que acontece | Efeito no resultado | Como corrigir |
|---|---|---|---|
| Esquecer o transaction_id no evento purchase ou duplicar a compra | Evento disparado em mais de um lugar na nova plataforma | Receita inflada ou duplicada no GA4, o que mascara o efeito real da migração | Validar o evento com um pedido de teste e checar a unicidade do ID da transação |
| Perder tags do GTM ou do GA4 no novo site | A camada de dados muda e as tags deixam de disparar | Buraco nos dados exatamente no período mais crítico, sem como comparar | Testar o disparo de todos os eventos de e-commerce antes do go-live e monitorar nas primeiras horas |
| Comparar o tráfego pós-migração com um período sazonal diferente | Comparação com o mês anterior em vez do mesmo período do ano anterior | Conclusões erradas: ora alarme falso, ora sensação de normalidade | Comparar com o mesmo período do ano anterior e com a tendência do mercado |
Erros de operação após o lançamento
| Erro | Por que acontece | Efeito no resultado | Como corrigir |
|---|---|---|---|
| Desligar a plataforma antiga cedo demais | Corte de custo imediato | Os redirecionamentos deixam de existir, as URLs antigas dão erro e os links externos se perdem | Manter a infraestrutura de redirecionamento ativa. O Google recomenda manter redirecionamentos por longo prazo, em geral ao menos um ano |
| Remover redirecionamentos em poucos meses | Limpeza de regras do servidor | Links externos e favoritos voltam a quebrar, e a autoridade acumulada se perde | Remover só depois de confirmar que o tráfego das URLs antigas é desprezível |
| Não monitorar o Search Console nas primeiras semanas | Considerar a migração “concluída” no go-live | Erros de cobertura, 404 e queda de impressões só são vistos depois de semanas | Monitorar diariamente o relatório de indexação, erros de rastreamento e impressões por seção |
| Não ter plano de rollback | Confiança de que “vai dar certo” | Uma falha crítica (noindex, redirecionamentos quebrados) fica sem como ser revertida rapidamente | Definir antes do lançamento os gatilhos de reversão e quem decide |
Na prática, o conjunto de erros mais caro costuma ser o mesmo: redirecionamentos sem mapeamento 1:1, bloqueios herdados do staging e falta de linha de base. Corrigir esses três antes do go-live elimina a maior parte do risco de queda duradoura.
Checklist consolidado
Antes
- Benchmark: crawl, top URLs, receita orgânica, logs, CWV.
- Mapa de URLs 1:1 aprovado e testado em staging.
- Metadados, conteúdo, dados estruturados e hreflang conferidos.
- Staging fechado por autenticação; robots.txt de produção pronto.
- GA4/GTM validados; propriedades do Search Console verificadas.
- Congelamento definido e rollback testado; data longe do pico.
Durante
- Redirecionamentos 301 ativos, sem cadeias.
- Sem noindex/Disallow indevidos; canonical autorreferenciado.
- Sitemap novo enviado; Mudança de endereço (se houver troca de domínio).
- Compra de teste no GA4 e no back-office.
Depois
- Logs e Search Console diariamente na semana 1.
- 404, soft 404 e 5xx corrigidos.
- Receita orgânica comparada ao benchmark por 90 dias.
- Redirecionamentos mantidos por 12 meses ou mais.
Perguntas frequentes
Migrar de plataforma faz perder tráfego?
O Google diz que flutuações de ranking são esperadas enquanto recoleta e reindexa as URLs. O tamanho da queda depende do mapeamento, da paridade de conteúdo e de erros técnicos. Não há promessa de retorno ao patamar anterior.
Posso usar redirecionamento 302 na migração?
Para mudanças definitivas, o Google recomenda redirecionamentos permanentes (301 ou 308), porque temporários mantêm a URL original como a exibida nos resultados. Use 302 apenas para situações realmente temporárias.
Quando usar a ferramenta Mudança de endereço?
Apenas em troca de domínio ou subdomínio, depois que o site foi movido e redirecionado. Ela não deve ser usada para HTTP para HTTPS, www para não-www ou mudança de caminhos dentro do mesmo site.
Por quanto tempo manter os redirecionamentos?
O Google recomenda manter por pelo menos 1 ano, e a ferramenta de Mudança de endereço pede ao menos 180 dias. Se as URLs antigas ainda recebem tráfego, mantenha por mais tempo.
Devo migrar na Black Friday?
Não é recomendável. O Google sugere realizar a mudança em período de menor tráfego, e a Black Friday de 2026 é em 27/11. Se a data não puder ser adiada, congele alterações e tenha rollback testado.
O que fazer com URLs de produtos descontinuados?
Se houver substituto equivalente, redirecione para ele. Se não houver, retorne 404 ou 410, em vez de enviar para a home, o que pode parecer soft 404.
A migração muda o rastreamento do GA4?
Pode mudar, se os eventos ou o GTM forem recriados na plataforma nova. Valide view_item, add_to_cart, begin_checkout e purchase antes do lançamento, com transaction_id, valor e moeda.
