SEO Técnico

Guia de migração SEO sem perder tráfego

Cinco fases com gate entre cada uma, do inventário à estabilização pós-cutover. O que fazer T-30, T-14, T-7, T-0 e T+30, os sete erros que derrubam tráfego e as ferramentas que de fato ajudam.

· 13 min de leitura

Toda migração SEO começa com alguém dizendo "é só subir o site novo e colocar os redirects". Toda migração SEO ruim termina com um report de queda de 40% de tráfego orgânico três meses depois. A distância entre as duas frases é planejamento.

Este guia descreve o que eu faço em migração de domínio (com ou sem mudança de CMS), com a ressalva de que nenhum passo é opcional. Cada fase tem um gate, e saltar um gate é o que transforma migração técnica em incidente de negócio. Se você está lendo isso porque tem uma migração agendada, a regra de ouro é começar 30 dias antes do cutover. Se começou ontem pra amanhã, adie.

Por que migração mata tráfego

Três causas, em ordem de frequência:

  1. Redirect mapping incompleto. URLs com tráfego sumiram sem redirect 1:1. Google chega, bate 404, remove do índice.
  2. Mudança de estrutura sem preservação de sinais. URLs novas, mas canonical, schema, internal linking ou hreflang quebrados. Google re-indexa mas perde o contexto que fazia aquela URL rankear.
  3. Performance pior que a anterior. Site novo com CWV ruim, JS bloqueante, imagens não otimizadas. O Google mede isso e demora pra reestabilizar o ranking.

As três são previsíveis e todas mitigáveis com o plano abaixo.

O plano em cinco fases

Plano de migração SEO em cinco fases Linha do tempo de uma migração SEO com cinco fases numeradas, inventário em T menos 30, mapeamento em T menos 14, staging em T menos 7, cutover no dia zero e monitoramento em T mais 30. Cada fase lista o artefato de saída e o critério de passagem pra próxima. MIGRAÇÃO SEO · LINHA DO TEMPO · 5 FASES COM GATE ENTRE CADA UMA FASE 01 · T-30 Inventário lista completa de URLs ordenada por tráfego + logs de 30 dias gate, 100% coberto por GA/GSC/logs FASE 02 · T-14 Mapeamento 1:1 por regra clara 301 / 410 / consolidar schema e canonical gate, zero URL órfã diff homologado FASE 03 · T-7 Staging crawl full no staging compare com prod valida redirects gate, diff aprovado por SEO + eng FASE 04 · T-0 Cutover deploy em low traffic sitemap + GSC change smoke test 50 URLs gate, 200 em 95% amostra do top tráfego FASE 05 · T+30 Monitorar log + GSC + rank 404 → novo redirect diff tráfego por URL fix loop semanal até estabilizar

Lê da esquerda pra direita. Cada fase tem um artefato de saída e um gate de passagem. Sem gate cumprido, não avança. Esse é o único disciplinamento que salva projeto.

Fase 01, T-30, inventário que previne 90% dos problemas

O erro mais comum é começar pelo redirect mapping. Errado. Comece pelo inventário completo de URLs com tráfego. Isso significa juntar três fontes:

  • Google Analytics / GA4. Pages com cliques no último ano, não só no último mês. URL sazonal pode valer.
  • Google Search Console. Pages com impressão e clique, mesmo as que você nem sabe que existem (tag archives antigas, URLs de parâmetro, paginação).
  • Logs do servidor. O acesso real do Googlebot. Nem tudo aparece em GSC (especialmente URLs canibalizadas ou não indexadas). 30 dias de log mostra o crawl budget efetivo.

Une as três em uma planilha, deduplica, ordena por tráfego decrescente. Essa é sua lista mestra. Marque também os top 20% que representam 80% do tráfego (Pareto) e trate eles com especial cuidado nas próximas fases.

Gate de passagem, 100% das URLs com >10 cliques/mês cobertas pelo inventário.

Fase 02, T-14, mapeamento 1:1 por regra clara

Cada URL antiga do inventário recebe uma das quatro saídas abaixo. A decisão é a parte que demanda o maior esforço humano do projeto e não pode ser delegada pra script.

Árvore de decisão para redirects em migração SEO Árvore de decisão que mapeia cada URL antiga para uma das quatro saídas possíveis, 301 para equivalente direto, 301 para página-pai quando só a estrutura muda, 301 para canônico quando há consolidação, ou 410 quando o conteúdo foi removido. Regra lateral destaca que nunca se usa 302 em migração permanente. REDIRECTS EM MIGRAÇÃO · ÁRVORE DE DECISÃO POR URL ENTRADA URL antiga vinda do inventário A página ainda existe no site novo? SIM, 1:1 direto 301 pra URL equivalente com canonical = destino SIM, mas consolidada 301 pro canônico várias URLs antigas viram uma nova SIM, só muda estrutura 301 pro pai página-filho sumiu redirect pra categoria NÃO, conteúdo removido 410 Gone não redirecione pra home 410 limpa o índice mais rápido REGRAS FIXAS Nunca use 302 em migração permanente · Nunca redirecione 404 em massa pra home Evite chains (A→B→C), sempre resolva direto pro destino final · Preserve parâmetros relevantes (UTM, gclid)

As quatro saídas:

  • 301 pra URL equivalente direta. O caso mais comum, conteúdo continua existindo no novo site. Redirect 1:1 com canonical apontando pro destino.
  • 301 pro canônico consolidado. Várias URLs antigas viram uma nova (típico em reestruturação de categoria). Todas as antigas redirecionam pra canônica, e essa canônica vira o ponto de convergência de link equity.
  • 301 pra página-pai. Quando a página-filho some (por exemplo, uma landing de produto descontinuado), redirecione pra categoria-pai, não pra home. Perder contexto é ruim, mas redirect pra home é pior.
  • 410 Gone. Conteúdo removido de propósito. 410 sinaliza ao Google que a URL não volta. Limpa o índice em semanas; redirect pra home deixaria o Google tentando entender por meses.

Três regras fixas que valem em qualquer migração:

  1. Nunca use 302 em migração permanente. 302 passa menos link equity e confunde o Google sobre qual URL é canônica.
  2. Evite chains. A → B → C é pior que A → C. Sempre resolva direto pro destino final, mesmo que isso signifique reescrever regras antigas.
  3. Preserve parâmetros relevantes. UTM, gclid, fbclid precisam atravessar o redirect. Em nginx, rewrite ^/old /new$is_args$args permanent;. Em Next.js, garanta via middleware.

Gate de passagem, zero URL órfã no diff e mapeamento aprovado por SEO + engenharia.

Fase 03, T-7, staging com crawl + diff

O site novo precisa estar em staging acessível pro time (com basic auth pra não indexar). Aqui rodamos dois passos técnicos:

  1. Crawl completo no staging. Screaming Frog ou Sitebulb. Objetivo, capturar title, description, H1, canonical, hreflang, status code, schema e internal links de cada URL. Export em CSV.
  2. Diff com produção. Rodar o mesmo crawl no site atual e comparar CSV contra CSV. Colunas que importam, title, description, canonical, status, schema. Onde o diff aparece, investiga. Onde o diff é intencional (reestruturação), documenta.

Além do crawl, teste os redirects direto via curl. Um shell script que lê a planilha de mapeamento e bate curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" <url_antiga>. Cada linha que volta com código diferente de 301 ou com redirect_url errado é bug bloqueante.

Gate de passagem, diff aprovado + 100% dos redirects retornando 301 pro destino correto.

Fase 04, T-0, cutover em janela de baixa demanda

Deploy em janela de baixa demanda (madrugada, fim de semana), nunca em horário comercial. Checklist do próprio dia:

  • Subir o novo site com DNS apontado.
  • Aplicar as regras de redirect no servidor/edge.
  • Atualizar sitemap.xml com as URLs novas, submeter no GSC.
  • Usar a ferramenta Change of Address do GSC se for mudança de domínio.
  • Atualizar robots.txt se havia regra específica.
  • Smoke test em 50 URLs do top tráfego, manual, no browser. Cada uma tem que abrir em 200 com conteúdo esperado e canonical apontando pra ela mesma.

Gate de passagem, 95% da amostra de smoke test retorna 200 com conteúdo correto. Se 5% ou mais falhou, rollback e recomeço na próxima janela.

Fase 05, T+30, monitoramento e fix loop

Aqui mora o trabalho ingrato. Nas 4 semanas pós-cutover, três coisas precisam ser olhadas diariamente nos 7 primeiros dias e semanalmente depois:

  1. Logs do servidor. Qualquer 404 ou 500 vindo do Googlebot vira ticket imediato. Normalmente é um redirect faltando ou uma regex mal formada.
  2. GSC, relatório de cobertura. Páginas com status "Duplicado, Google escolheu canônica diferente" são sinal de que você não preservou canonical. "Descobriu, atualmente não indexado" pode ser crawl budget comido por URLs velhas ainda na fila.
  3. Rank tracking por URL. Compare o rank médio das top 100 URLs antes e depois. Queda brusca (mais de 5 posições em mais de 20% delas) é bandeira vermelha, investiga individual.

O fix loop é semanal. Toda segunda: pega os 404s do Googlebot da semana anterior, cria os redirects faltantes, deploya. Em 4 semanas o número de 404s semanais cai pra zero e você pode declarar estabilização.

Os sete erros que mais derrubam tráfego

  1. Redirecionar tudo pra home. O clássico. Google vê N-mil URLs convergindo pra raiz e reclassifica como soft 404.
  2. Chains de redirect. A → B → C. Perda de link equity a cada hop. Resolve direto.
  3. Mudar URLs "por estética" sem necessidade. Se a URL antiga funciona, deixa. Reestruturar sem motivo claro é queimar capital SEO.
  4. Esquecer do hreflang. Sites multi-idioma, tags de hreflang novas precisam estar no novo site apontando pras URLs canônicas corretas.
  5. Lançar com schema quebrado. Valida tudo em validator.schema.org e Rich Results Test antes do cutover.
  6. Subir com CWV pior. Se LCP sobe, rank cai. Meça CWV no staging e só vai pra produção se estiver igual ou melhor.
  7. Não avisar o GSC. Submeter novo sitemap e usar Change of Address acelera a re-indexação em semanas.

Ferramentas que de fato ajudam

  • Screaming Frog pra crawl e diff. Paga porque vale.
  • GoAccess ou Matomo pra parsear logs do servidor. Se o servidor é Apache/nginx, vem dos logs mesmo, não precisa de nada fancy.
  • Semrush ou Ahrefs pra rank tracking por URL. GSC serve pra impressão e clique, mas pra rank médio histórico você precisa de uma dessas.
  • Sheets pra planilha de mapeamento. Não inventa ferramenta de "redirect manager", planilha resolve e é auditável.
  • curl + bash pro shell de validação dos redirects. Simples, ninguém quebra.

O que medir no fim

Trinta dias depois do cutover, três métricas de sucesso:

  1. Tráfego orgânico total. Dentro de ±10% do pré-migração é sucesso. Queda maior que 20% é incidente.
  2. Impressões no GSC. Curva de impressão acompanhando ou superando a curva pré-cutover.
  3. Rank médio das top 100 URLs. Diferença menor que 2 posições no agregado.

Se as três estão estáveis ou melhores, a migração cumpriu o objetivo. Se alguma está negativa, volte pro fix loop da fase 05 e investigue URL por URL.

Migração bem feita é invisível. Usuário não percebe, Google reindexa em silêncio, e o gráfico do GSC continua subindo sem degrau. O trabalho não aparece, e é exatamente esse o sinal de que foi bem feito.

Continuar lendo