Há três anos recebi uma migração que já estava ao vivo. Sem ambiente de staging. Sem mapa de redirecionamentos. Um catálogo de e-commerce com 22 mil páginas que alguém tinha simplesmente apontado para um novo domínio e chamado de "pronto". O tráfego orgânico caiu 74% em seis semanas. O cliente me ligou em leve pânico, e passei praticamente quatro meses desemaranhandotudo.
Ponto-chave: Migrações de site perdem rankings por causa de auditorias de redirecionamento puladas, não por mudanças de plataforma; o checklist é mapa de redirecionamentos, transporte de metadados, continuidade de schema e verificação pós-lançamento.
Essa experiência, por mais dolorosa que tenha sido, é basicamente o motivo pelo qual este checklist existe. Desde então, migrei sites variando de 800 páginas de brochureware a um publisher de 31.000 páginas com subdomínios regionais, e os fundamentos são os mesmos toda vez. Erre a ordem, pule um passo, e o Google te avisa no Search Console da forma mais desagradável possível.
Então aqui está. O checklist real que uso na Seahawk Media, não um framework teórico.
---
1. Comece com um Rastreamento Completo Antes de Tocar em Nada
Óbvio? Sim. Ignorado? O tempo todo.
Antes de um único arquivo se mover, faço a rastreamento completo do site ativo com Screaming Frog SEO Spider. Em um site de 20.000 páginas isso leva um par de horas, geralmente inicio o rastreamento à noite com os dados armazenados em modo de banco de dados para evitar problemas de memória. O que estou capturando:
- Todas as URLs indexáveis (a versão canônica, não ruído de paginação)
- Códigos de resposta em geral, 200s, 301s, 302s, 404s, tudo
- Estrutura de links internos existente
- Tags canônicas, atributos hreflang se aplicável
- Títulos de página e meta descriptions (para verificar se sobrevivem à migração)
Exporto a crawlagem completa para CSV e guardo. Este é meu baseline. É o documento que vou comparar três semanas depois que o novo site entra no ar.
Muita gente pula essa etapa porque "já conhecemos o site." Vocês não conhecem. Pensava que conhecia o site de um cliente de viagens lá em 2021, descobri que eles tinham 4.000 URLs sendo servidas de um subdiretório de CMS legado que ninguém tinha mencionado no briefing. Encontrei no rastreamento. Teria sido um desastre.
Não esqueça dos próprios dados do Google
Puxe tudo do Google Search Console, dados de performance dos últimos 16 meses no mínimo, o relatório de cobertura de índice, qualquer ação manual, todos os sitemaps. E puxe do Google Analytics (GA4 agora, obviamente) para ter seus benchmarks de tráfego orgânico definidos antes de qualquer coisa mudar. Screenshots funcionam bem aqui; também exporto os CSVs brutos.
---
2. Construa o Mapa de Redirecionamentos. Depois Verifique de Novo.
É aqui que as migrações vivem ou morrem. Em sites grandes, o mapa de redirecionamentos é uma planilha de verdade, geralmente compartilhada no Google Sheets com o cliente, o time de dev deles, e qualquer outra pessoa que possa acidentalmente sobrescrever uma fórmula às 23h.
A estrutura é simples:
- Coluna A: URL Antiga (exata, incluindo barra final ou falta dela)
- Coluna B: URL Nova (exata)
- Coluna C: Tipo de redirecionamento (301 em quase todo caso)
- Coluna D: Status (mapeado, verificado, ativo)
- Coluna E: Notas (redirecionamentos catch-all, consolidações de categorias, drops intencionais)
Em um site com 20.000 páginas você obviamente não consegue mapear cada URL individualmente. Aqui está a ordem em que trabalho:
- Mapeie primeiro todas as URLs com melhor desempenho (por tráfego orgânico do GSC, as top 500 geralmente direcionam 80%+ do tráfego)
- Mapeie páginas de categoria e taxonomia
- Mapeie qualquer URL que tenha backlinks significativos (use Ahrefs para isso, filtre por domínios referenciadores, não apenas links brutos)
- Lide com redirecionamentos baseados em padrão para tudo o mais (por exemplo, /product/old-slug/ → /shop/old-slug/)
- Documente 410s intencionais para páginas que você está descontinuando
Redirecionamentos baseados em padrão é a coisa que a maioria dos desenvolvedores juniores erra. Eles vão escrever uma regra com wildcard que é muito ampla e acidentalmente redirecionam URLs que não tinham intenção de redirecionar. Teste cada regra de padrão em staging antes dela chegar perto de produção.
---
3. Staging Não É Opcional
Vou manter isso breve porque não deveria precisar de muita explicação. Toda migração recebe um ambiente de staging. Ponto final.
A Seahawk tinha um cliente do setor fintech em 2022 que questionou isso, queria "só fazer em produção porque o site é pequeno." O site tinha 6.000 páginas. Fizemos em staging. Encontramos um conflito de plugin que estava removendo tags canonical de todas as páginas de produtos. Teria sido invisível até o Google rastrear tudo novamente, e em um domínio de baixa autoridade isso pode levar semanas.
Em staging você está verificando:
- Todos os redirecionamentos funcionam corretamente (uso Screaming Frog novamente, apontado para staging, para verificar o mapa de redirecionamentos em massa)
- Robots.txt está bloqueando o ambiente de staging da indexação (importante, use Disallow: /mas também adicione um header noindex para dupla proteção)
- O novo sitemap é preciso e não contém URLs de staging
- Tags canônicas apontam para as URLs de produção corretas
- Baselines de velocidade de página com PageSpeed Insights, migrações são frequentemente usadas como oportunidades de redesign, e redesigns costumam destruir Core Web Vitals
---
4. A Sequência de Go-Live (A Ordem Importa Mais Do Que Você Pensa)
Esta é a parte onde as pessoas improvisam e causam problemas para si mesmas. Há uma ordem específica. Eu não me desvio dela.
Etapa 1: Pré-lançamento (48 horas antes)
- Reduza o TTL em todos os registros DNS para 300 segundos (5 minutos). Acelera significativamente a propagação.
- Oriente o cliente: nenhuma alteração de conteúdo, nenhuma página nova, nenhuma atualização de plugin durante a janela de migração.
- Notifique as integrações de terceiros (CDNs, plataformas de anúncios, ferramentas de monitoramento) sobre a mudança iminente.
Etapa 2: Janela de lançamento
- Atualize o DNS
- Implante redirects antes que o novo conteúdo esteja totalmente propagado, redirects devem estar ativos no nível do servidor, não apenas no WordPress
- Habilite o novo sitemap, desabilite o antigo
- Verifique se o robots.txt está correto (arquivo de produção, não o do staging)
Etapa 3: Imediatamente após o lançamento
- Rastreie o novo site dentro de duas horas. Screaming Frog apontado para produção, respeitando redirecionamentos. Estou procurando por 404s inesperados, cadeias de redirecionamento com mais de dois saltos, e qualquer página que deveria ser indexável mostrando uma tag noindex.
- Envie o novo sitemap no Search Console
- Busque a homepage através da ferramenta URL Inspection do GSC para avisar ao Googlebot que visite
Uma coisa que sempre sinalizei a clientes: Google não refletirá imediatamente as novas URLs nos resultados de busca. Há atraso na crawl e reprocessamento. Em um site grande, reserve de duas a seis semanas antes de ter uma visão clara. Entrar em pânico no dia quatro porque rankings mudaram é normal, não significa que algo está quebrado.
---
5. Auditoria de Cadeias de Redirecionamento (O Passo Que a Maioria das Agências Cobra Separadamente)
Cadeias de redirecionamento são um sangramento lento. Uma URL que vai A → B → C → D está fazendo o Googlebot fazer trabalho extra, e também está diluindo equity de link ao longo de múltiplos saltos. Em um site que teve múltiplas migrações anteriores ou mudanças de plataforma, cadeias podem ficar surpreendentemente profundas.
Pós-lançamento, exporto o rastreamento completo do Screaming Frog e filtro por cadeias de redirecionamento. Qualquer coisa além de dois saltos é colapsada. Se a URL original estava no mapa de redirecionamento, eu a atualizo para apontar diretamente para o destino final. Se era uma cadeia legada de uma migração que ninguém documentou, eu a adiciono.
Essa etapa sozinha, em um cliente que migramos de Magento para WooCommerce no início de 2023, levou dois dias. Eles tinham tido três migrações ao longo de oito anos. Algumas URLs passavam por cinco redirects antes de chegar na página correta. Consolidei tudo, e as métricas de crawl budget deles no Search Console melhoraram notavelmente dentro de um mês.
---
6. Verificação de Conteúdo em Escala
Você não consegue revisar manualmente 20 mil páginas. Mas pode verificar sistematicamente o que realmente importa.
Aqui está o que verifico nas duas primeiras semanas pós-lançamento:
- Title tags e meta descriptions: Compare uma amostra aleatória de 200 páginas contra a exportação do Screaming Frog pré-migração. Incompatibilidades são sinalizadas imediatamente.
- Dados estruturados: Execute uma amostra de páginas de produtos, páginas de artigos e a homepage pelo Rich Results Test do Google. Migrações quebram markup de schema com mais frequência do que você imaginaria, especialmente se o novo tema usa um plugin diferente.
- Internal linking: Crawl do Screaming Frog, filtre por inlinks. Páginas de alto valor ainda devem ter contagens fortes de links internos. Se uma página de categoria que anteriormente tinha 400 links internos agora tem 12, algo deu errado no template.
- Imagens e alt text: Não é estritamente crítico para SEO, mas imagens quebradas prejudicam sinais de experiência do usuário e são fáceis de perder em sites com templates.
---
7. Monitoramento para os 90 Dias Seguintes
A migração não termina no dia do go-live. Ela segue por no mínimo 90 dias.
Estabeleci cadências de relatório semanais com o cliente durante o primeiro mês, depois quinzenais depois disso. Aqui está o que estou acompanhando:
- GSC Index Coverage: O número de páginas indexadas está se recuperando em direção à contagem pré-migração? Uma queda significativa que persiste além de três semanas precisa de investigação.
- Tráfego orgânico vs. baseline: Segmentado por tipo de landing page (produto, categoria, blog). Quedas de tráfego são frequentemente desiguais, às vezes páginas de categoria desabam enquanto páginas de produto resistem.
- Crawl budget: O relatório de crawl stats do GSC mostra páginas médias rastreadas por dia e tempos de resposta do servidor. Se o Googlebot está encontrando muitos 404s, isso aparece aqui.
- Tracking de posição de ranking: Uso uma combinação de rank tracking do Ahrefs e relatório de desempenho do Google Search Console. Volatilidade de ranking nas primeiras duas ou três semanas é comum e não é necessariamente um problema. Quedas sustentadas além da semana quatro justificam ação.
- Perfil de backlinks: Usando Ahrefs, verifique se backlinks de alto valor apontando para URLs antigas estão já redirecionados corretamente ou marcados para outreach de atualização.
A verdade honesta? A maioria dos problemas de SEO em migração são detectáveis em 30 dias se você estiver observando as métricas certas. Os que pegam as pessoas são aqueles em que ninguém configurou monitoramento e o cliente percebe oito meses depois.
---
8. As Coisas em Que Errei (Para Você Não Errar)
Lá em 2019, perdi uma implementação de hreflang em uma migração para um cliente com subpastas do Reino Unido, Austrália e Canadá. Os canonical tags estavam corretos. Os redirects estavam ok. Mas as anotações hreflang no novo site tinham os códigos de região errados, en-au em vez de en-AU (a capitalização importa, aparentemente, em algumas implementações). Google começou a servir as páginas do Reino Unido para buscadores australianos. Levou seis semanas para descobrirmos por que o tráfego orgânico australiano tinha caído pela metade. Temos tido uma etapa de validação de hreflang em toda migração internacional desde então.
Outra: sitemaps XML que contêm URLs com noindex. Parece uma inconsistência menor, mas envia sinais conflitantes e realmente vale a pena limpar. Screaming Frog consegue auditar seu sitemap e sinalizar qualquer URL nele que retorne uma tag noindex.
E provavelmente a lição mais cara: não ter um plano de rollback. Em uma migração que está dando errado, a capacidade de voltar o DNS para o servidor antigo dentro de uma hora vale ouro. Sempre insisto que o ambiente antigo fica ativo e íntegro por pelo menos 30 dias após a migração. Clientes às vezes reclamam do custo de hospedagem. Explico quanto uma queda de 70% no tráfego custa em receita e eles param de reclamar.
---
FAQ
Quanto tempo realmente leva para planejar uma migração de site com 20 mil páginas?
Realistically? Seis a dez semanas de preparação antes da data de go-live. Apenas o mapa de redirecionamentos em um site desse tamanho pode levar duas a três semanas para ser construído corretamente, especialmente se você está auditando backlinks para cada URL. Apressar a preparação é como você acaba passando meses em recuperação.
Preciso enviar um arquivo disavow após uma migração?
Geralmente não, a menos que o domínio antigo tivesse links tóxicos e você esteja migrando especificamente para escapar deles. Se você está migrando para um novo domínio e quer um perfil de links limpo, faça o disavow na nova propriedade no GSC. Mas para a maioria das migrações de plataforma ou redesign no mesmo domínio, disavow é irrelevante.
Qual é o maior erro que você vê agências cometendo em migrações grandes?
Tratar o mapa de redirect como uma tarefa de dev. Redirects são uma tarefa de SEO que um developer implementa. O time de SEO, ou quem quer que seja dono da estratégia de busca, deve ser dono do mapa, revisar e aprovar. Já vi developers construir regras de redirect tecnicamente corretas que estavam erradas do ponto de vista de SEO porque ninguém lhes disse qual variante de URL era canônica.
A velocidade do site afeta o SEO em migrações?
Sim, mais do que a maioria das pessoas leva em conta. Core Web Vitals são um fator de ranking, e redesigns, que frequentemente acompanham migrações, costumam introduzir JavaScript mais pesado ou imagens não otimizadas. Sempre execute uma comparação PageSpeed Insights entre o site antigo e o novo antes do lançamento. Se o novo site é significativamente mais lento no mobile, corrija antes de ativar a chave.
Como você lida com migrações de sites com muito conteúdo gerado por usuários?
Com cuidado. Páginas UGC são frequentemente de baixa qualidade individualmente, mas coletivamente impulsionam tráfego de cauda longa. Normalmente recomendo uma etapa de crawl-and-analyse: identificar quais URLs de UGC têm algum tráfego orgânico, redirecionar essas especificamente, e retornar 410 para o resto em vez de deixá-las como 404s. Um 410 diz ao Google que a página foi intencionalmente removida; um 404 é ambíguo.
---
Migrações são uma daquelas coisas onde a diferença entre bom e catastrófico é quase inteiramente na preparação. A implementação técnica geralmente é a parte fácil. Acertar o trabalho pré-lançamento, a crawl, o mapa de redirect, a verificação de staging, é onde o trabalho real acontece. E se você nunca receber uma migração que já está ao vivo e já está quebrada, o checklist ainda se aplica. Você está apenas fazendo ao contrário.