Migração de Site Sem Custar Seu SEO

Eu vi migrações de cinco dígitos virarem desastres de SEO de seis dígitos porque o time tratou migração como um problema técnico em vez de um problema de continuidade. O padrão é sempre o mesmo. Construa o novo site. Mude a chave. Veja o tráfego orgânico cair quarenta a setenta por cento nas próximas oito semanas. Gaste o próximo trimestre tentando recuperar o que foi perdido no dia da mudança.

O movimento técnico raramente é o que te mata. Mapas de redirecionamento que estão oitenta por cento completos te matam. Tags canônicas apontando para domínios de staging te matam. Links internos que ainda apontam para a estrutura antiga te matam. Mudanças de URL feitas "enquanto estamos nisso" te matam. A construção em si é a parte fácil; o trabalho de continuidade é onde toda migração que shipper em escala que trabalhei vive ou morre.

Cinco coisas, aprendidas da forma difícil em doze mil sites na Seahawk Media. Cada uma é inegociável em toda migração que shippamos.

Primeiro, o mapa de redirecionamentos é construído antes de qualquer código. Cada URL antiga recebe um 301 para seu equivalente novo. Exportamos a lista de URLs de origem do Search Console, Ahrefs e do sitemap existente, depois construímos o mapeamento em uma planilha que se torna a fonte de verdade para a migração. O linter da build falha o deploy se alguma URL anterior à migração estiver faltando no mapa.

Segundo, a estrutura de URL é preservada onde a nova plataforma permite. Toda mudança de URL é um risco de ranking. Mudamos URLs apenas quando há um motivo real de conteúdo — uma duplicata, um typo, uma canonical que estamos consolidando — nunca porque a nova plataforma sugere uma convenção diferente. A tentação de "organizar enquanto estamos nisso" custou mais rankings do que qualquer outra decisão em nossa prática de migração.

Terceiro, sites com mais de dez mil páginas recebem um rollout em fases. Migre o conteúdo de menor tráfego primeiro, valide que os rankings se mantêm, depois expanda. Uma migração em etapas limita o raio de explosão se algo der errado em um template ou tipo de conteúdo específico, e dá ao time uma chance de corrigir o problema antes que as páginas de alto tráfego sejam afetadas.

Quarto, um período de execução paralela. O site antigo continua ao vivo em modo somente leitura por trinta dias após o lançamento. Se o novo site tiver um problema, o tráfego é redirecionado de volta instantaneamente. O custo de rodar dois stacks por um mês é pequeno comparado ao custo de um ciclo de recuperação de tráfego de quatro semanas.

Quinto, noventa dias de monitoramento pós-lançamento. Estatísticas de rastreamento do Search Console, cobertura de indexação, impressões, análise de arquivo de log, validador de schema, dados de campo do Core Web Vitals. Corrija regressões em dias, não trimestres. Até o dia noventa o site está estável e entregamos limpo ou passamos para um plano de suporte contínuo.

Alguns poucos formatos de migração respondem por quase todo o nosso trabalho de projeto. Cada um tem seu próprio playbook e seus próprios modos de falha usuais.

WordPress para Next.js ou Astro é o engajamento mais comum. O briefing é geralmente um site de marketing ou conteúdo que atingiu o teto de performance no WordPress clássico e um time que quer DX moderno de front-end sem perder o wp-admin para o time editorial. WordPress headless com WPGraphQL mais um front-end Next.js ou Astro satisfaz ambos os lados.

Drupal, Sitecore ou Typo3 para WordPress é o segundo padrão. Sair de um CMS empresarial legado sem quebrar os rankings de SEO que o time legado construiu ao longo de uma década. Migrações mais lentas, modelagem de conteúdo mais complexa, mas o playbook é o mesmo — mapa de redirecionamento completo, URLs preservadas onde possível, execução paralela, rollout em fases.

Shopify para comércio headless é o terceiro. Shopify Plus storefront com um front-end Next.js ou Hydrogen, design totalmente customizado, Core Web Vitals mais rápido, engine de comércio mantido. Shopify continua sendo a fonte de verdade para catálogo, inventário e checkout; o front-end vai custom.

Os outros padrões que vemos regularmente são consolidação de domínios (múltiplos domínios legados se unindo em um com estratégia apropriada de canonical e redirect), consolidação de subdomínio para subdiretório (mover blog.example.com para example.com/blog/ para consolidar link equity), e migrações de hospedagem e plataforma (mover WordPress gerenciado entre Kinsta, WP Engine, Pressable, ou para infraestrutura bare-metal).

Sites com menos de mil páginas levam de quatro a oito semanas do início ao fim, incluindo planejamento, mapeamento de redirects, migração de conteúdo, QA e monitoramento pós-lançamento. Sites de dez mil a vinte mil páginas levam de doze a vinte semanas. Migrações enterprise de cinquenta mil páginas ou mais levam no mínimo seis a nove meses, com rollouts em fases e períodos de execução paralela integrados ao cronograma.

A maior variável é a qualidade do conteúdo na origem. Taxonomias confusas, URLs duplicadas e metadados inconsistentes adicionam semanas à fase de planejamento. Diremos honestamente durante o audit se seu site de origem está pronto para migração ou se precisa de uma limpeza de conteúdo antes. Fingir que a origem está limpa quando não está é como migrações escorregam de um trimestre para meio ano.

Faixas honestas de engajamentos recentes reais. Uma migração de pequena empresa com menos de quinhentas páginas custa de quatro mil a doze mil libras. Uma migração de mid-market de uma a dez mil páginas custa de quinze mil a sessenta mil. Uma migração enterprise de dez a cem mil páginas custa de sessenta mil a trezentas mil libras, incluindo suporte SEO contínuo pós-lançamento pelo primeiro trimestre.

Cerca de trinta a quarenta por cento do custo vai para planejamento e QA, não para a construção técnica. Os times que cotam barato são os que pulam o planejamento. Você paga por isso depois em rankings perdidos, e o custo de reconstruir rankings é sempre maior que o custo de preservá-los em primeiro lugar.