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.Site migrations lose rankings through skipped redirect audits, not platform changes; the checklist is redirect map, metadata transport, schema continuity, and post-launch verification.
Essa experiência -- por mais dolorosa que tenha sido -- é basicamente por que esse checklist existe. Desde então migrei sites variando de brochureware com 800 páginas até uma publisher com 31.000 páginas e subdomínios regionais, e os fundamentos são os mesmos toda vez. Acerte a ordem errada, pule um passo, e o Google vai te informar sobre isso 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.Seahawk Media, not a theoretical framework.
---
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 varredura de todo o site ao vivo com Screaming Frog SEO Spider. Em um site de 20.000 páginas isso leva um par de horas -- geralmente inicio a varredura à noite com a saída armazenada em modo de banco de dados para que a memória não vire um problema. O que estou capturando:Screaming Frog SEO Spider. On a 20,000-page site this takes a couple of hours -- I usually kick it off overnight with the crawl stored to database mode so memory doesn't become an issue. What I'm capturing:
- Todas as URLs indexáveis (a versão canônica, não ruído de paginação)
- Códigos de resposta em toda a extensão -- 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 esse passo porque "já conhecemos o site." Vocês não conhecem. Achei que conhecia um site de cliente de viagens em 2021 -- descobriu-se que eles tinham 4.000 URLs sendo servidas de um subdiretório de CMS legado que ninguém tinha mencionado no briefing. Encontrei na varredura. Teria sido um desastre.
Não esqueça dos próprios dados do Google
Puxe tudo do Google Search Console -- dados de desempenho 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 que você tenha seus benchmarks de tráfego orgânico travados antes de qualquer coisa mudar. Screenshots funcionam bem aqui; também exporto os CSVs brutos.Google Search Console -- performance data for the last 16 months minimum, the index coverage report, any manual actions, all sitemaps. And pull from Google Analytics (GA4 now, obviously) so you have your organic traffic benchmarks locked down before anything changes. Screenshots work fine here; I also export the raw CSVs.
---
2. Construa o Mapa de Redirecionamentos. Depois Verifique de Novo.
É aqui que 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 desenvolvimento deles, e qualquer outra pessoa que pudesse 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 todos os URLs com melhor desempenho primeiro (por tráfego orgânico do GSC -- os top 500 geralmente dirigem 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)Ahrefs for this -- filter by referring domains, not just raw links)
- Lide com redirecionamentos baseados em padrão para tudo o mais (por exemplo, /product/old-slug/ → /shop/old-slug/)
/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 teve um cliente de fintech em 2022 que contestou isso -- queria "fazer direto no ar porque o site é pequeno". O site tinha 6.000 páginas. Fizemos em staging. Encontramos um conflito de plugin que estava removendo canonical tags de todas as páginas de produto. Teria sido invisível até o Google rastrear tudo novamente, o que em um domínio de baixa autoridade 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)
- O Robots.txt está bloqueando o ambiente de staging de ser indexado (importante -- use Disallow: /mas também adicione um header noindex para proteção dupla)
Disallow: /but also add a noindex header for double protection) - 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 frequentemente destroem Core Web VitalsPageSpeed Insights -- migrations are often used as redesign opportunities, and redesigns frequently destroy 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
- Deploy de redirects antes do novo conteúdo estar totalmente propagado -- redirects devem estar ativos no nível do servidor, não apenas no WordPressWordPress
- 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 aviso aos clientes: o Google não refletirá imediatamente as novas URLs nos resultados de busca. Há um atraso de rastreamento e reprocessamento. Em um site grande, reserve de duas a seis semanas antes de ter uma visão clara. Entrar em pânico no quarto dia 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.
Só este passo -- em um cliente que migramos de Magento para WooCommerce no início de 2023 -- levou dois dias. Eles tiveram três migrações em oito anos. Algumas URLs passavam por cinco redirects antes de chegar na página correta. Consolidamos tudo, e as métricas de crawl budget deles no Search Console melhoraram notavelmente em 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.: Compare a random 200-page sample against the pre-migration Screaming Frog export. Mismatches get flagged immediately.
- 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.: Run a sample of product pages, article pages, and the homepage through Google's Rich Results Test. Migrations break schema markup more often than you'd think, especially if the new theme uses a different plugin.
- 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.: Screaming Frog crawl, filter for inlinks. High-value pages should still have strong internal link counts. If a category page that previously had 400 internal links now has 12, something went wrong in the 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.: Not strictly SEO-critical, but broken images hurt user experience signals and they're easy to miss on templated sites.
---
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.: Is the number of indexed pages recovering toward the pre-migration count? A significant drop that persists beyond three weeks needs investigation.
- Tráfego orgânico vs. baseline: Segmentado por tipo de página de destino (produto, categoria, blog). Quedas de tráfego geralmente são desiguais -- às vezes páginas de categoria desabam enquanto páginas de produto se mantêm.: Segmented by landing page type (product, category, blog). Traffic drops are often uneven -- sometimes category pages tank while product pages hold.
- 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.: GSC's crawl stats report shows average pages crawled per day and server response times. If Googlebot is hitting a lot of 404s, it shows here.
- 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.: I use a combination of Ahrefs rank tracking and Google Search Console's performance report. Ranking volatility in the first two to three weeks is common and not necessarily a problem. Sustained drops beyond week four warrant action.
- 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.: Using Ahrefs, verify that high-value backlinks pointing to old URLs are either already redirected correctly or flagged for outreach to update.
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 funcionando. Mas as anotações hreflang no novo site tinham os códigos de região errados -- en-au em vez de en-AU (maiúsculas importam, aparentemente, em algumas implementações). Google começou a servir 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 um passo de validação de hreflang em cada migração internacional desde então.en-au instead of en-AU(case matters, apparently, in some implementations). Google started serving the UK pages to Australian searchers. Took us six weeks to figure out why Australian organic traffic had halved. We've had a hreflang validation step in every international migration since.
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 redirects como uma tarefa dev. Redirects são uma tarefa de SEO que um developer implementa. O time de SEO -- ou quem quer que seja responsável pela estratégia de busca -- deve ser o dono do mapa, revisar e aprová-lo. Vi developers construindo regras de redirect tecnicamente corretas que eram SEO-erradas porque ninguém os informou 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 contabiliza. Core Web Vitals são um fator de ranking, e redesigns -- que frequentemente acompanham migrações -- frequentemente introduzem 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 em mobile, corrija antes de fazer a mudança.
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 -- o crawl, o mapa de redirecionamentos, a verificação em staging -- é onde o trabalho real acontece. E se você receber uma migração que já está ao vivo e já está quebrada, o checklist ainda se aplica. Você apenas está fazendo isso de trás para frente.