No ano passado, migramos um site de e-commerce com 34.000 páginas de uma instalação WordPress monolítica para uma arquitetura headless usando Next.js e um CMS headless. O tráfego orgânico do cliente representava 72% da receita. Sem pressão, certo?

A migração levou 14 semanas de planejamento e 6 semanas de execução. Quando mudamos, o tráfego orgânico caiu 3,2% na primeira semana, se recuperou na terceira semana e subiu 11% no segundo mês. Isso não é sorte -- é processo.

Já vi migrações darem terrivelmente errado. Um concorrente do mesmo cliente havia migrado seis meses antes e perdeu 40% do tráfego orgânico da noite para o dia. Oito meses depois, ainda não haviam se recuperado. A diferença entre uma migração bem-sucedida em larga escala e um desastre é planejamento, gerenciamento de redirecionamentos e ter um plano de reversão em que você realmente confia.

Este artigo percorre tudo o que fazemos ao migrar sites com dezenas de milhares de páginas. É o mesmo processo se você está movendo de WordPress para Next.js, Drupal para Astro, ou qualquer outra mudança de plataforma.

Table of Contents

Como Migrar um Site de 30.000 Páginas Sem Perder SEO

Por Que as Migrações em Larga Escala Falham

A maioria das falhas de migração compartilha as mesmas causas raiz. Entendê-las antecipadamente evita que você se junte ao cemitério de lançamentos fracassados.

O Problema do Redirecionamento

Em um site de 500 páginas, você pode mapear manualmente cada URL. Em um site de 30.000 páginas, você não consegue. As equipes acabam escrevendo regras de redirecionamento baseadas em regex que cobrem 90% das URLs e assumem que os 10% restantes se resolvem sozinhos. Esses 10% restantes? São 3.000 páginas. Muitas das quais são seu conteúdo com melhor desempenho.

Um estudo de 2025 da Ahrefs descobriu que sites que perderam mais de 15% de suas páginas indexadas durante a migração experimentaram um declínio médio de tráfego orgânico de 34%. E a recuperação levou 4-8 meses em média.

O Problema da Paridade

O Google não se importa apenas com conteúdo -- se importa com estrutura. Padrões de links internos, hierarquias de títulos, dados estruturados, tags canônicas, manipulação de paginação, navegação facetada. Mude muitos destes simultaneamente e Google essencialmente tem que reavaliar seu site inteiro do zero.

O Problema do Tempo

Já vi equipes gastarem meses aperfeiçoando o novo site e depois apressarem a migração real porque a liderança está impaciente. Você não migra um site de 30.000 páginas numa sexta-feira à tarde. Você não migra durante seu pico de tráfego. E definitivamente não migra sem um plano de reversão testado.

Fase 1: Auditoria Pré-Migração e Crawl

Antes de tocar em qualquer coisa, você precisa de uma visão completa do que existe hoje. Este é seu baseline e você vai referenciar constantemente durante a migração.

Crawl Completo do Site

Execute um crawl completo usando Screaming Frog, Sitebulb, ou um crawler baseado em nuvem como Lumar (antigo Deepcrawl). Para 30.000+ páginas, você vai querer a opção baseada em nuvem -- crawlers desktop não conseguem lidar com sites deste tamanho, e você precisa que os dados do crawl sejam compartilháveis pela sua equipe.

Capture tudo:

  • Cada URL e seu código de status HTTP
  • Title tags e meta descriptions
  • Tags H1
  • Tags canônicas
  • Tags hreflang (se aplicável)
  • Links internos (tanto entrada quanto saída por página)
  • Tipos de dados estruturados presentes
  • Tempos de carregamento de página
  • Contagem de palavras por página
  • Imagens e texto alternativo

Baseline de Análise

Exporte os últimos 12 meses de dados do Google Analytics e do Google Search Console. Você precisa de:

  • Top 1.000 landing pages por sessões orgânicas
  • Top 5.000 queries por cliques e impressões
  • Estatísticas de crawl (páginas rastreadas por dia, tempos de resposta)
  • Pontuações de Core Web Vitals
  • Relatório de cobertura de índice (indexadas, excluídas, erros)

Marque suas 500 principais landing pages orgânicas. Estas são as páginas que não podem quebrar. Período. Cada uma delas é verificada individualmente durante e depois da migração.

Puxe dados de backlinks de Ahrefs, Semrush e Google Search Console. Faça referência cruzada para encontrar cada URL que tem links externos apontando para ela. Estas URLs precisam de redirecionamentos 301 perfeitos -- perder equity de backlink em páginas de alta autoridade é uma das formas mais rápidas de derrubar rankings.

# Exemplo: Exportar e desduplicar URLs com backlinks
ahrefs-export.csv + semrush-export.csv + gsc-export.csv
| sort -u 
| awk -F',' '{print $1}' 
> unique_backlinked_urls.txt

wc -l unique_backlinked_urls.txt
# Output: 8,247 unique URLs with backlinks

Fase 2: Mapeamento de URL e Estratégia de Redirecionamento

Este é o ponto em que migrações são ganhas ou perdidas. Em um site de 30.000 páginas, você precisa de uma abordagem sistemática que combine mapeamento automatizado com verificação manual para páginas críticas.

Construindo o Mapa de Redirecionamento

Comece categorizando suas URLs em padrões. A maioria dos sites grandes tem um número relativamente pequeno de padrões de URL que representam a maioria das páginas:

Padrão de URL Exemplo Contagem de Páginas Estratégia
Páginas de produto /products/blue-widget-123 18.000 Regex + mapeamento de ID
Páginas de categoria /category/widgets 450 Mapeamento manual
Posts de blog /blog/2024/03/post-title 3.200 Preservação de slug
Páginas de tag/filtro /products?color=blue 6.500 Avaliar: redirecionar ou noindex
Páginas estáticas /about, /contact 85 Mapeamento manual
Páginas paginadas /category/widgets/page/3 1.800 Mapear para nova paginação

A Abordagem de Três Camadas

Camada 1: Mapeamento manual (top 500 páginas) Suas páginas com maior tráfego e maior receita recebem mapeamento individual. Um humano verifica cada redirecionamento. Sem exceções.

Camada 2: Mapeamento baseado em padrões (~25.000 páginas) Escreva regras de transformação que convertem padrões de URL antigos em novos. Teste estas regras contra sua lista completa de URLs antes do deployment.

# Exemplo de geração de regra de redirecionamento
import csv
import re

def generate_redirect(old_url):
    # Páginas de produto: /products/blue-widget-123 -> /shop/blue-widget
    product_match = re.match(r'/products/([a-z-]+)-(\d+)$', old_url)
    if product_match:
        slug = product_match.group(1)
        return f'/shop/{slug}', 301
    
    # Posts de blog: /blog/2024/03/post-title -> /blog/post-title
    blog_match = re.match(r'/blog/\d{4}/\d{2}/(.+)$', old_url)
    if blog_match:
        slug = blog_match.group(1)
        return f'/blog/{slug}', 301
    
    return None, None

# Processar todas as URLs
with open('all_urls.csv') as f:
    reader = csv.reader(f)
    unmapped = []
    for row in reader:
        old_url = row[0]
        new_url, status = generate_redirect(old_url)
        if new_url is None:
            unmapped.append(old_url)
    
    print(f"Unmapped URLs: {len(unmapped)}")

Camada 3: Páginas não mapeadas restantes (~4.500 páginas) Estas são seus edge cases. Percorra-as manualmente. Algumas serão páginas que você está intencionalmente encerrando (redirecionar para a página mais relevante). Algumas serão URLs que você perdeu na análise de padrões. Não deixe nenhum 404 para páginas que tinham tráfego ou backlinks.

Cadeias de Redirecionamento e Loops

Se o site antigo já tem redirecionamentos em lugar, seus novos redirecionamentos podem criar cadeias (A → B → C). Resolva-as antes do lançamento. Cada redirecionamento deve ir diretamente da URL antiga para o destino final em um único salto. Cadeias de redirecionamento perdem PageRank -- John Mueller do Google confirmou múltiplas vezes que embora sigam cadeias, um redirecionamento direto é sempre preferível.

Como Migrar um Site de 30.000 Páginas Sem Perder SEO - arquitetura

Fase 3: Checklist de Paridade Técnica de SEO

O novo site precisa manter paridade de SEO técnico com o site antigo -- e idealmente melhorá-lo. Aqui está o que verificamos:

Itens Críticos de Paridade

  • Title tags: Iguais ou melhoradas. Nunca as deixe em branco durante migração.
  • Meta descriptions: Carregue-as, mesmo que planeje reescrever depois.
  • Estrutura H1: Um H1 por página, correspondendo ao direcionamento de palavras-chave do site antigo.
  • Tags canônicas: Canônicas auto-referenciais em cada página. Se o site antigo tinha canônicas cross-domain, preserve-as.
  • Robots.txt: Não bloqueie acidentalmente Googlebot no lançamento. Já vi isto acontecer mais vezes do que gostaria.
  • Sitemaps XML: Gere novos sitemaps com todas as URLs novas. Envie dentro de horas do lançamento.
  • Dados estruturados: Migre toda a marcação schema. Schema de produto, schema de FAQ, schema de breadcrumb -- tudo.
  • Links internos: O gráfico de links internos do novo site deve espelhar de perto o do site antigo.

Requisitos de Desempenho

Os Core Web Vitals do Google são fatores de ranking. Seu novo site deve atender ou superar o desempenho do site antigo:

Métrica Limite Bom Alvo
LCP (Largest Contentful Paint) ≤ 2,5s ≤ 2,0s
INP (Interaction to Next Paint) ≤ 200ms ≤ 150ms
CLS (Cumulative Layout Shift) ≤ 0,1 ≤ 0,05
TTFB (Time to First Byte) ≤ 800ms ≤ 400ms

Esta é uma área onde migrar para uma stack moderna como Next.js ou Astro realmente lhe dá uma vantagem. Geração estática e renderização na borda podem melhorar dramaticamente TTFB. Vimos TTFB cair de 1,2s para menos de 200ms ao passar de WordPress tradicional para Next.js com ISR ou Astro com saída estática.

Fase 4: Migração e Validação de Conteúdo

Extração Automatizada de Conteúdo

Para 30.000 páginas, você precisa de extração de conteúdo automatizada. Normalmente construímos scrapers personalizados ou usamos as APIs de exportação do CMS para puxar conteúdo para um formato estruturado (geralmente JSON ou CSV) antes de importar para o novo CMS headless.

Validações chave após importação:

  • Codificação de caracteres (observe caracteres especiais quebrados)
  • Referências de imagem (todas as imagens são resolvidas?)
  • Links internos (são atualizados para novos padrões de URL?)
  • Mídia incorporada (vídeos, iframes, widgets)
  • Formatação de tabela
  • Blocos de código

Teste de Diff de Conteúdo

Executamos comparações automatizadas entre páginas antigas e novas para nossas 500 principais URLs. O script busca ambas as versões, remove HTML e compara o conteúdo de texto. Qualquer página com menos de 95% de similaridade de texto é marcada para revisão manual.

// Comparação de conteúdo simplificada
const { diff } = require('fast-diff');
const cheerio = require('cheerio');

async function comparePages(oldUrl, newUrl) {
  const oldHtml = await fetch(oldUrl).then(r => r.text());
  const newHtml = await fetch(newUrl).then(r => r.text());
  
  const oldText = cheerio.load(oldHtml)('main').text().trim();
  const newText = cheerio.load(newHtml)('main').text().trim();
  
  const changes = diff(oldText, newText);
  const unchanged = changes
    .filter(([type]) => type === 0)
    .reduce((sum, [, text]) => sum + text.length, 0);
  
  const similarity = unchanged / Math.max(oldText.length, newText.length);
  
  return {
    similarity: Math.round(similarity * 100),
    oldLength: oldText.length,
    newLength: newText.length,
    needsReview: similarity < 0.95
  };
}

Fase 5: Testes em Ambiente de Staging

Nunca lance uma migração sem testes abrangentes de staging. Aqui está o que validamos:

Teste de Redirecionamento

Teste cada redirecionamento. Sim, todos os 30.000. Use um script que segue a cadeia de redirecionamento e valida o destino final:

# Testar redirecionamentos do arquivo de mapeamento
while IFS=, read -r old_url new_url; do
  response=$(curl -s -o /dev/null -w "%{http_code} %{redirect_url}" "$old_url")
  status=$(echo $response | cut -d' ' -f1)
  redirect=$(echo $response | cut -d' ' -f2)
  if [ "$status" != "301" ] || [ "$redirect" != "$new_url" ]; then
    echo "FAIL: $old_url -> $status $redirect (expected 301 $new_url)"
  fi
done < redirect_map.csv

Validação de Renderização

Se você estiver usando renderização no cliente (CSR) ou abordagens pesadas em hidratação, verifique que Googlebot pode realmente ver seu conteúdo. Use o Rich Results Test do Google ou a ferramenta URL Inspection no Search Console para verificar a saída renderizada.

Este é um problema particularmente comum com frameworks baseados em React. Se seu conteúdo requer JavaScript para renderizar e você não implementou adequadamente SSR ou SSG, Google pode ver uma página em branco. Sempre usamos renderização no servidor ou geração estática para páginas críticas de SEO.

Fase 6: Execução no Dia do Lançamento

Checklist de Lançamento

  1. DNS TTL: Reduza TTL de DNS para 300 segundos pelo menos 48 horas antes da migração
  2. Deploy de redirecionamentos: Coloque todos os redirecionamentos 301 ao vivo no servidor/CDN antigo
  3. Trocar DNS: Aponte domínio para nova infraestrutura
  4. Verificar redirecionamentos: Execute testes de redirecionamento automatizados contra produção
  5. Enviar sitemaps: Envie novos sitemaps XML no Google Search Console
  6. Solicitar indexação: Use a ferramenta URL Inspection para solicitar indexação de suas 50 principais páginas
  7. Monitorar: Observe análise em tempo real para anomalias
  8. Verificar robots.txt: Confirme que Googlebot não está bloqueado
  9. Verificar CDN/caching: Garanta que headers de redirecionamento não estão sendo cacheados incorretamente

Tempo

Lance numa terça ou quarta-feira de manhã. Nunca sexta-feira. Você quer pelo menos 3 dias úteis completos para monitorar e corrigir problemas antes do fim de semana. Evite lançar durante períodos de tráfego alto ou eventos de compra importantes.

Também nos certificamos de que alguém está monitorando a noite toda após o lançamento. Google frequentemente rastreia mais agressivamente durante horas fora do pico, e se seus redirecionamentos tiverem problemas, você quer capturá-los rapidamente.

Plano de Reversão

Tenha um plano de reversão testado que pode ser executado em menos de 15 minutos. Isto geralmente significa manter a infraestrutura antiga rodando em paralelo por pelo menos 2 semanas pós-migração. O custo de manter dois ambientes temporariamente é nada comparado ao custo de uma migração fracassada.

Fase 7: Monitoramento Pós-Migração

Monitoramento Diário (Semanas 1-2)

  • Erros de crawl: Verifique Google Search Console diariamente para novos 404s e erros de servidor
  • Cobertura de índice: Monitore o relatório de cobertura de índice para quedas
  • Tráfego orgânico: Compare sessões orgânicas diárias com seu baseline
  • Rankings: Rastreie suas 200 principais palavras-chave diariamente
  • Logs do servidor: Analise padrões de rastreamento de Googlebot no novo site
  • Core Web Vitals: Verifique dados de campo à medida que começam a chegar

Monitoramento Semanal (Semanas 3-8)

  • Compare tráfego orgânico semana a semana
  • Monitore volatilidade de ranking
  • Verifique novos problemas de crawl
  • Verifique se cadeias de redirecionamento não foram acidentalmente criadas
  • Monitore perfil de backlink para links perdidos

Padrões de Tráfego Esperados

Uma migração bem executada normalmente mostra:

  • Semana 1: Queda de 5-15% (Google está processando as mudanças)
  • Semana 2-3: Recuperação para níveis pré-migração
  • Semana 4-8: Se o novo site é tecnicamente superior, muitas vezes você verá um aumento de tráfego

Se você vê uma queda de 30%+ que não se recupera até a semana 3, algo deu errado com seus redirecionamentos ou implementação técnica. Escave no Search Console imediatamente.

Implementação de Redirecionamento em Escala

Onde você implementa redirecionamentos importa. Para 30.000+ redirecionamentos, não coloque tudo num arquivo .htaccess ou num array de configuração redirects do Next.js -- isso mata o desempenho.

Abordagens Recomendadas

Redirecionamentos no nível da borda (melhor para desempenho) Implemente redirecionamentos no nível do CDN/borda usando Cloudflare Workers, Vercel Edge Middleware, ou arquivo _redirects do Netlify. Redirecionamentos na borda executam antes do código da sua aplicação, então são extremamente rápidos.

// Exemplo Vercel Edge Middleware
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

// Carregar mapa de redirecionamento (pré-construído no tempo de deploy)
import redirectMap from './redirects.json';

export function middleware(request: NextRequest) {
  const path = request.nextUrl.pathname;
  const redirect = redirectMap[path];
  
  if (redirect) {
    return NextResponse.redirect(
      new URL(redirect.destination, request.url),
      redirect.permanent ? 301 : 302
    );
  }
  
  return NextResponse.next();
}

Redirecionamentos com suporte de banco de dados (melhor para flexibilidade) Armazene redirecionamentos num banco de dados e busque-os no tempo de requisição. Isto permite adicionar, modificar e auditar redirecionamentos sem reimplementar. Adicione cache agressivo (Redis ou similar) para que a busca de banco de dados não adicione latência.

Abordagem híbrida (o que geralmente fazemos) Redirecionamentos baseados em padrões na borda, redirecionamentos individuais num banco de dados. O melhor dos dois mundos.

Tratamento de Sites Internacionais e Multilíngues

Se seu site de 30.000 páginas inclui múltiplos idiomas ou regiões, a complexidade se multiplica. Cada versão de idioma precisa de seu próprio mapa de redirecionamento. Tags hreflang precisam ser atualizadas para referenciar novas URLs. E você precisa verificar que o direcionamento de idioma/região no Search Console ainda funciona corretamente.

Armadilhas comuns:

  • Esquecer de atualizar anotações hreflang em todas as versões de idioma simultaneamente
  • Quebrar o requisito recíproco de hreflang (se a página A aponta para página B, página B deve apontar de volta para A)
  • Perder estruturas de URL específicas de idioma que Google usa como sinais

Erros Comuns que Matam Rankings

  1. Usar 302 em vez de 301: Redirecionamentos temporários não passam equity de link completo. Verifique triplo seus códigos de status de redirecionamento.
  2. Bloquear o site de staging e esquecer de desbloquear: Seu robots.txt em staging diz Disallow: /. Você faz deploy de staging para produção. Googlebot não consegue rastrear nada.
  3. Mudar conteúdo e URLs simultaneamente: Google vê uma nova URL com conteúdo diferente. É uma nova página? Uma página movida? Reduza ambiguidade -- migre URLs primeiro, mude conteúdo depois.
  4. Redirecionar tudo para a home: Implementações de redirecionamento preguiçosas que enviam todas as URLs antigas para a homepage destroem seus rankings de cauda longa instantaneamente.
  5. Ignorar renderização JavaScript: Seu novo aplicativo React parece ótimo em Chrome. Googlebot vê um <div id="root"></div> vazio.
  6. Não lidar com trailing slashes consistentemente: /products/widget e /products/widget/ são URLs diferentes. Escolha um e redirecione o outro.
  7. Remover páginas sem redirecionamentos: Se uma página tinha tráfego, precisa de um redirecionamento. Mesmo que você esteja encerrando esse conteúdo, redirecione para a página mais relevante próxima.

Ferramentas e Stack que Usamos

Ferramenta Propósito Custo (2026)
Screaming Frog Crawling desktop $259/ano
Lumar (Deepcrawl) Crawling em nuvem para sites grandes Preço customizado
Ahrefs Análise de backlink, rastreamento de ranking A partir de $129/mês
Google Search Console Monitoramento de índice, estatísticas de crawl Grátis
Redirectchecker.com Teste de redirecionamento em massa Nível gratuito disponível
ContentKing Monitoramento de SEO em tempo real A partir de $99/mês
Scripts Python/Node personalizados Mapeamento de redirecionamento, diffing de conteúdo Seu tempo

Para a construção real do site, típicamente usamos Next.js ou Astro dependendo das necessidades do projeto, junto com um CMS headless como Sanity, Contentful ou Storyblok. Se você está planejando uma migração e quer discutir arquitetura, confira nosso preço ou entre em contato.

FAQ

Quanto tempo leva para migrar um site de 30.000 páginas?

Espere 12-20 semanas total. A fase de planejamento e mapeamento de URL leva o mais tempo -- geralmente 8-14 semanas. A migração técnica real e lançamento é tipicamente 4-6 semanas. Apressar a fase de planejamento é o preditor único maior de falha de migração.

Vou definitivamente perder algum tráfego de SEO durante a migração?

Uma queda temporária de 5-15% é normal e esperada, mesmo com uma migração perfeita. Google precisa de tempo para processar dezenas de milhares de redirecionamentos e rastrear novamente seu novo site. A queda tipicamente se resolve dentro de 2-3 semanas. Se você vê uma queda maior ou não se recupera, investigue seus redirecionamentos e implementação técnica imediatamente.

Devo mudar minha estrutura de URL durante a migração?

Apenas se houver uma razão forte para fazer isso. Cada mudança de URL adiciona risco. Se sua estrutura de URL atual é funcional e descritiva, mantenha-a. Se é genuinamente ruim (por exemplo, URLs com query parameters em vez de caminhos limpos), a migração é uma boa oportunidade para corrigi-la -- mas planeje seu mapa de redirecionamento de acordo.

Posso migrar meu site em fases em vez de tudo de uma vez?

Sim, e para sites muito grandes muitas vezes é a abordagem mais segura. Você pode migrar seção por seção -- blog primeiro, depois páginas de produto, depois páginas de categoria. Isto reduz risco mas aumenta complexidade porque você está rodando duas plataformas simultaneamente, geralmente atrás de um proxy reverso. Fizemos isso com sucesso várias vezes, mas requer configuração de roteamento cuidadosa.

O que acontece com meus Google Ads durante a migração?

Atualize as URLs da página de destino de seus anúncios para as novas URLs antes ou imediatamente após a migração. Se você tem redirecionamentos em lugar, seus anúncios ainda funcionarão, mas o redirecionamento adiciona latência e pontuações de qualidade de Google Ads podem ser negativamente afetadas por cadeias de redirecionamento. Atualizar as URLs diretamente é sempre melhor.

Como lido com páginas que quero remover durante a migração?

Se a página tinha tráfego orgânico ou backlinks, redirecione-a para a página existente mais relevante no novo site. Se não tinha nenhum dos dois, você pode deixá-la retornar um status 404 ou 410 (Gone). Não redirecione páginas irrelevantes para sua homepage -- Google trata redirecionamentos de massa para homepage como soft 404s.

Devo usar redirecionamentos 301 ou 308?

Use 301 para a maioria dos casos. Ambos são redirecionamentos permanentes, mas 301 é universalmente entendido por todos bots e navegadores. 308 preserva o método HTTP (POST continua POST), que importa para endpoints de API mas não para redirecionamentos de página focados em SEO.

Quando devo remover os redirecionamentos antigos?

Mantenha-os por pelo menos um ano, preferencialmente indefinidamente. Redirecionamentos são baratos de manter, e removê-los significa que qualquer bookmark antigo, link externo ou resultado de busca em cache vai acertar 404s. Quase nunca há uma boa razão para remover redirecionamentos 301 que funcionam.