Migração de Site sem Perder SEO: checklist completo para 2026

Migrar um site é um dos momentos de maior risco em SEO. Um erro — um redirect esquecido, uma URL que muda, uma mudança de servidor mal preparada — pode derrubar posições, tráfego e receita da noite para o dia. Estima-se que 80% dos casos de tráfego orgânico perdido após migrações vêm de erros previsíveis que poderiam ter sido evitados com planejamento.

Este guia entrega um checklist completo de migração: como mapear seu site atual, preparar a nova versão, executar a troca e monitorar tudo nos 60 dias seguintes — para que você migre de tecnologia, design ou servidor sem sacrificar o SEO conquistado.

Por que migrações destroem SEO (e por que não deveriam)

A migração em si não é o problema. O problema é a soma de mudanças simultâneas: URLs novas, estrutura de conteúdo alterada, servidor mais lento, conteúdo reduzido, metas tags perdidas. O Google re-rastreia e re-indexa tudo, e qualquer inconsistência vira perda de autoridade.

As causas mais comuns de perda:

• URLs mudaram sem redirects: cada link externo que apontava para a URL antiga agora dá 404 — a autoridade (PageRank) se dissipa.
• Redirects mal feitos: 302 no lugar de 301, correntes de redirect, redirects para páginas erradas.
• Conteúdo empobrecido: a nova versão corta texto, imagens ou páginas valiosas.
• Perda de sinais técnicos: sitemap esquecido, robots.txt bloqueando, canonical errado, SSL quebrado.
• Velocidade pior: a migração para o novo stack deixa o site mais lento, e velocidade é fator de ranqueamento.
• Nenhum monitoramento: o problema só é descoberto semanas depois, quando o tráfego já caiu.

Regra de ouro: uma migração bem-sucedida é uma migração invisível — o usuário não percebe, o Google não perde, e o único que muda é você.

Fase 1: Mapeamento completo do site atual (antes de tocar em qualquer coisa)

Antes de escrever uma linha da nova versão, documente o estado atual:

1. Capture o inventário de URLs

# Extraia todas as URLs do site atual
# Opção 1: sitemap.xml
# Opção 2: crawler (Screaming Frog, Sitebulb)
# Opção 3: Google Search Console → Páginas → Todas as URLs indexadas

2. Identifique o que não pode morrer

Para cada URL, classifique o valor:

URL antiga                    → URL nova
/ (home)                     → / (home)
/produtos                    → /produtos
/produtos/tenis-corrida      → /calcados/tenis-corrida
/sobre-nos                   → /sobre
/blog/10-dicas-de-seo        → /blog/10-dicas-de-seo  (mantém)
/blog/artigo-antigo          → /blog/artigo-antigo    (redirect 301)

Boas práticas: alterar URLs com SEO forte só é justificável se o ganho estrutural superar o risco. Migrar tecnologia não exige mudar URLs — um Next.js pode manter exatamente as mesmas rotas do WordPress.

2. Preserve o conteúdo valioso

A migração é a desculpa perfeita para "enxugar" — mas enxugar no lugar errado custa caro:

3. Prepare o novo ambiente técnico

O mito de que "migrar tecnologia é sempre arriscado"

É comum ouvir que migrar um WordPress ranqueado para Next.js é "pedir para perder posições". A verdade é mais sutil: o risco não está na tecnologia, está na execução. Migrações bem conduzidas preservam (e frequentemente melhoram) o SEO, porque:

• As URLs podem permanecer idênticas (rotas do Next.js replicam as do WordPress)
• O conteúdo migrado integralmente não perde relevância
• A performance geralmente melhora (o que ajuda o ranqueamento)
• O controle técnico aumenta (SEO técnico nativo, sitemap, schema)

O que de fato derruba sites em migração é o que este checklist previne: redirects esquecidos, conteúdo cortado, schema perdido e monitoramento ausente. Trate a migração como um projeto técnico de precisão — não como uma "troca de casa" — e os riscos caem drasticamente.

Quem precisa estar na mesa da migração

Migração não é tarefa de um desenvolvedor sozinho. Para um resultado completo, alinhe:

• Desenvolvedor/agência: executa a nova versão, redirects e deploy
• Responsável de conteúdo: garante que textos, imagens e páginas migram integralmente
• Responsável de SEO: valida a estrutura, o mapa de redirects e monitora a indexação
• Responsável de marketing: comunica a mudança, atualiza links em campanhas e redes sociais
• Responsável de e-commerce (se aplicável): valida checkout, pagamento e integrações

Uma migração sem esse alinhamento é uma corrida de bastões em que cada um acha que o outro segura a ponta. O resultado: algo que escapa — geralmente, os redirects.

Fase 3: Execução da migração

1. Configuração dos redirects 301

O 301 informa permanentemente que a URL mudou, transferindo a autoridade. Nunca use 302 (temporário) para migrações permanentes.

# Nginx: exemplos de redirects 301
server {
  listen 443 ssl;
  server_name www.seusite.com.br;

  # Domínio www → sem www (ou o contrário — escolha um e seja consistente)
  return 301 https://seusite.com.br$request_uri;
}

server {
  listen 443 ssl;
  server_name seusite.com.br;

  # Página específica antiga → nova
  location = /produtos/tenis-corrida {
    return 301 https://seusite.com.br/calcados/tenis-corrida;
  }
}

# Apache (.htaccess): redirects 301
Redirect 301 /produtos/tenis-corrida https://seusite.com.br/calcados/tenis-corrida

// Next.js (next.config.js): redirects declarativos
module.exports = {
  async redirects() {
    return [
      {
        source: "/produtos/tenis-corrida",
        destination: "/calcados/tenis-corrida",
        permanent: true, // = 301
      },
      // Redirect curinga para conteúdo movido em bloco
      {
        source: "/blog/:slug",
        destination: "/insights/:slug",
        permanent: true,
      },
    ];
  },
};

Regras de ouro dos redirects:

• Sempre 301 (permanente) — transfere autoridade
• Redirect direto, sem cadeias (A → B, e não A → C → B)
• Redirect específico > redirect genérico (para a página certa, não para a home)
• Sem redirect para a home em massa — para a página mais próxima do conteúdo original
• Testar cada redirect após a implementação

2. Sequência segura de migração

A ordem ideal evita o período de "site novo, sem indexação, com o antigo ainda no ar":

1. [ ] Build e testes completos da nova versão em ambiente de staging
2. [ ] Sitemap novo gerado e validado
3. [ ] Troca de DNS/hospedagem no horário de menor tráfego
4. [ ] Redirects 301 ativos desde o primeiro segundo
5. [ ] Instalação de analytics e tags na nova versão
6. [ ] Validação rápida (formulários, e-commerce, contato) — antes de anunciar
7. [ ] Enviar sitemap novo no Search Console
8. [ ] Manter a infraestrutura antiga ativa por 7–14 dias (para capturar qualquer acesso residual)

# Validação de redirects em lote (exemplo com PowerShell)
# Extraia o código HTTP de cada URL para garantir que tudo é 301
$urls = @("https://seusite.com.br/", "https://seusite.com.br/produtos/tenis-corrida")
foreach ($url in $urls) {
  try {
    $r = Invoke-WebRequest -Uri $url -MaximumRedirection 0 -ErrorAction Stop
    Write-Host "$url -> $($r.StatusCode)"
  } catch {
    $code = $_.Exception.Response.StatusCode.value__
    Write-Host "$url -> $code (verificar!)"
  }
}

Fase 4: Monitoramento pós-migração (60 dias críticos)

A migração termina quando o Google re-indexa tudo e o tráfego estabiliza. Isso não acontece em uma semana.

Checklist de monitoramento

Métricas para comparar (baseline vs. pós)