Plano de projeto de migração de site: o guia passo a passo para 2026
Por Toy Wen Da, Cofundador · · 10 min de leitura
Traduzido do original em inglês. Ler em inglês
Um plano de projeto de migração de site é o documento que mapeia cada URL, redirecionamento, papel da equipe e ponto de teste antes de você mover um site para um novo domínio, plataforma ou design. O primeiro passo de qualquer projeto de migração de site é auditar e congelar as URLs do site atual, para que você tenha uma lista fixa com a qual trabalhar antes de qualquer mudança.

Antes de escrever uma única linha desse plano, ajuda saber exatamente o que está fraco no site atual. A ferramenta de plano de SEO do SearchBlueprint analisa suas páginas e mostra o que corrigir, o que manter e o que reconstruir antes de mover qualquer arquivo, uma base útil para decidir o que realmente vale a pena levar para o novo site.
Por que um plano escrito importa mais do que você imagina

"Migração" parece uma tarefa técnica: mover os arquivos, apontar o DNS e pronto. Na prática, ela envolve SEO, análise de dados, design, jurídico e comunicação com o cliente ao mesmo tempo. Um plano de migração de site escrito e compartilhado é o que impede que esses cinco grupos atrapalhem uns aos outros.
Os números confirmam isso. Segundo o Bloor Group, mais de 80% dos projetos de migração de dados estouram o orçamento ou perdem o prazo, com atrasos médios de 30% a 41% e estouros de custo de 30% ou mais, em média. A Gartner relatou que 83% dos projetos de migração de dados fracassam ou se desviam de forma significativa das metas originais. Uma pesquisa da McKinsey sobre grandes projetos de TI constatou que eles costumam exceder o orçamento em 45% e o prazo em 7%, entregando 56% menos valor do que o planejado. Uma análise de grandes projetos de TI citada pela Forbes constatou que apenas 36% permanecem dentro do orçamento e do prazo originais.
Esses números vêm de pesquisas sobre migração de dados corporativos, não de estudos específicos sobre sites. Mas o padrão por trás deles, planos que pulam a descoberta, os testes e o planejamento de reversão estouram o orçamento, vale tanto para a mudança de um site quanto para a migração de um banco de dados. Um plano de projeto de migração de site por escrito é a forma de evitar se tornar mais uma dessas estatísticas.
Os tipos de migração de site e por que o plano muda em cada um

Nem toda migração tem o mesmo risco. O escopo do seu plano deve corresponder ao tipo de mudança que você está realmente fazendo.
| Tipo de migração | O que muda | Maior risco para o SEO |
|---|---|---|
| Migração de domínio | Domínio principal alterado ou vários domínios consolidados | Perda de autoridade dos links se os redirecionamentos não forem mapeados 1:1 |
| Migração de plataforma | CMS ou sistema de e-commerce trocado por completo | Metadados, schema e estrutura de URLs quebrados |
| Migração de estrutura de URLs | Permalinks ou arquitetura do site reorganizados | Páginas órfãs e cadeias de redirecionamento |
| Migração de design | Renovação visual, URLs inalteradas | Piora nas Core Web Vitals por causa do maior peso das páginas |
| Migração de conteúdo | Páginas reescritas, movidas ou consolidadas | Conteúdo duplicado ou raso causando queda nos rankings |
| Migração internacional/multilíngue | hreflang e estrutura de idiomas reconstruídos | Páginas no idioma errado ranqueando no país errado |
Uma migração de domínio e de plataforma ao mesmo tempo, por exemplo, sair de WordPress em um domínio para Shopify em outro, carrega o risco combinado de todas as linhas dessa tabela. É nesse cenário que um plano detalhado mostra seu valor.
O plano de projeto de migração de site, passo a passo
Passo 1: audite e congele o site atual
Faça um rastreamento do site existente antes de mexer em qualquer coisa. Registre cada URL indexada, seus rankings atuais, o tráfego orgânico e os backlinks. Isso se torna sua linha de base e o ponto de partida do seu mapa de redirecionamentos. Congele a criação de novas URLs no site antigo assim que essa auditoria for fechada, para que o seu mapa não fique desatualizado no meio do projeto.
Passo 2: defina metas, escopo e um responsável pela decisão de go/no-go
Escreva por que você está migrando: páginas mais rápidas, um novo CMS, uma mudança de marca, a consolidação de domínios. Metas vagas geram aumento descontrolado de escopo. Escolha uma pessoa que tome a decisão final de go/no-go no dia do lançamento, e não um comitê. Envolva SEO, desenvolvimento, conteúdo e jurídico desde cedo; um plano feito por um único departamento sempre deixa passar algo que outro departamento teria percebido.
Passo 3: mapeie cada URL e monte o plano de redirecionamentos
Esta é a etapa de maior risco de todo o plano de projeto de migração de site. Monte uma planilha: URL antiga, URL nova, tipo de redirecionamento e status. Toda URL antiga precisa de um destino, mesmo que seja um redirecionamento para uma categoria pai. A falta de redirecionamentos é a causa mais comum de perda de tráfego após uma migração.
Se você quer ver o processo de SEO mais amplo em que este plano se encaixa, não só a lista de redirecionamentos, mas toda a sequência da descoberta ao lançamento, o framework de SEO passo a passo para 2026 mostra como a migração entra em um plano anual.
Passo 4: construa e teste em staging
Construa o novo site em um ambiente de staging que espelhe a produção. Transfira metadados, dados estruturados e tags canonical exatamente como estão, ajustando apenas as URLs que precisam mudar. Rastreie o site de staging antes do lançamento e corrija todos os erros 4xx ou 5xx que encontrar. Teste cada redirecionamento para identificar loops e cadeias, e não apenas o destino.
Passo 5: checklist do dia do lançamento
Lance em um horário de baixo tráfego. Deixe um plano de reversão pronto: um backup do site antigo, uma pessoa indicada que possa pausar a publicação e um limite claro para decidir quando acionar a reversão. Envie o novo sitemap XML ao Google Search Console e use a ferramenta Mudança de endereço (Change of Address) se o próprio domínio tiver mudado. O Google Search Central documenta esse processo para mudanças de site em developers.google.com/search.
Passo 6: monitore por 30, 60 e 90 dias
A maior parte do dano que uma migração causa aos rankings aparece nas semanas após o lançamento, e não no próprio dia. Acompanhe as estatísticas de rastreamento e o relatório de cobertura do Search Console em busca de erros. Compare o tráfego orgânico e as posições das palavras-chave com a sua linha de base pré-migração. Verifique a integridade dos redirecionamentos com um crawler pelo menos uma vez por semana durante o primeiro mês.
Combine este plano passo a passo com um checklist de migração de site para SEO dedicado, para que nada fique de fora da lista na semana corrida antes do lançamento, e consulte este guia sobre como migrar sem perder rankings no Google para ver as proteções específicas de ranking a incluir em cada fase.

Quanto tempo isso realmente deve levar?

Um site institucional pequeno, com menos de 200 páginas, muitas vezes consegue planejar e executar uma migração em duas a quatro semanas, desde que a equipe seja dedicada e o mapa de redirecionamentos seja simples. Um site de médio porte, com blog, formulários e integrações, costuma precisar de quatro a oito semanas. Um catálogo grande ou um site multirregional, com milhares de páginas de produto, vários idiomas e integrações de terceiros, normalmente precisa de oito a doze semanas de antecedência antes do lançamento, mais toda a janela de monitoramento pós-lançamento.
Apressar qualquer um desses prazos é de onde vêm as estatísticas de estouro citadas acima. Aumentar o cronograma em apenas uma semana extra de testes em staging é mais barato do que corrigir um mapa de redirecionamentos quebrado dois meses após o lançamento.
Faça um benchmark de desempenho antes de mover qualquer coisa
Uma migração também é a oportunidade de verificar se o novo site é realmente mais rápido ou se está discretamente mais lento. Registre sua linha de base das Core Web Vitals antes do lançamento para ter com o que comparar depois.
| Métrica | O que mede | Limite considerado bom |
|---|---|---|
| Largest Contentful Paint (LCP) | A rapidez com que o conteúdo principal carrega | 2,5 segundos ou menos |
| Interaction to Next Paint (INP) | O quanto a página parece responsiva | 200 milissegundos ou menos |
| Cumulative Layout Shift (CLS) | O quanto o layout se mexe durante o carregamento | 0,1 ou menos |
Esses limites vêm da documentação das Core Web Vitals do web.dev. Passe suas páginas atuais e as de staging por um teste gratuito de velocidade do site para registrar esses números antes de decidir que uma página nova está "boa o suficiente" para o lançamento.
Migrações específicas de plataforma trazem suas próprias complicações. Tirar um blog do HubSpot, por exemplo, tem suas particularidades de redirecionamento e RSS; o guia de migração de site do HubSpot mostra o que quebra e como proteger os rankings nessa mudança específica.
Quando as ferramentas do próprio site bastam e quando não bastam
A maioria das plataformas de CMS já vem com gerenciadores básicos de redirecionamento, geradores de sitemap e um ou dois plugins de SEO. Para uma mudança pequena e isolada, isso muitas vezes é realmente suficiente. Para uma migração completa de plataforma ou de domínio, geralmente não é.
| Situação | As ferramentas nativas costumam bastar? | Por quê |
|---|---|---|
| Renomear uma URL e redirecioná-la | Sim | Uma única regra de redirecionamento está bem dentro das ferramentas nativas de qualquer CMS |
| Corrigir um link quebrado isolado | Sim | Uma correção manual e uma verificação rápida com crawler resolvem |
| Mudar toda a sua estrutura de URLs | Não | Centenas de redirecionamentos precisam ser mapeados, testados e auditados em escala |
| Mudar para um novo domínio | Não | Exige mudanças de DNS, uma mudança de endereço no Search Console e verificação completa dos redirecionamentos |
| Trocar de CMS ou de plataforma de e-commerce | Não | Metadados, schema e templates precisam ser reconstruídos manualmente e passar por QA |
| Um padrão recorrente de links quebrados após cada atualização de conteúdo | Não | Indica um problema de processo que exige uma auditoria contínua, não uma correção pontual |
A linha de corte honesta é esta: se o problema é uma URL ou uma única configuração, o painel do seu próprio site resolve. Se o problema envolve centenas de URLs, uma nova plataforma ou uma questão recorrente que continua voltando, você precisa de um plano estruturado e, provavelmente, de ajuda externa para executá-lo sem perder rankings.
Erros comuns que estragam o cronograma de uma migração
- Tratar a migração como tarefa só de desenvolvedores. SEO, conteúdo e jurídico precisam ter lugar à mesa de planejamento, e não receber um aviso depois do lançamento.
- Pular o congelamento de URLs. Páginas novas adicionadas no meio do projeto não entram no mapa de redirecionamentos e acabam silenciosamente em 404 após o lançamento.
- Não ter plano de reversão. Sem um backup e um responsável pela decisão, um lançamento ruim fica no ar por muito mais tempo do que deveria.
- Testar redirecionamentos conferindo só algumas páginas. Cadeias e loops se escondem nas páginas em que ninguém pensa em olhar.
- Lançar durante um pico de tráfego. Uma campanha sazonal ou uma menção na imprensa é a pior semana para também mudar o site.
- Esquecer as tags de análise e o acompanhamento de conversões. Uma migração que quebra o rastreamento faz de cada decisão pós-lançamento um palpite.
Um passo a passo de um projeto real torna esses riscos concretos. Este estudo de caso de migração de site detalha os acertos, as perdas e as correções de uma migração de verdade, incluindo o que a equipe faria de forma diferente.
Perguntas frequentes
Qual é o primeiro passo de qualquer projeto de migração de site?
O primeiro passo é auditar o site atual e congelar a lista de URLs. Você precisa de um inventário completo e fixo das páginas, dos rankings e do tráfego existentes antes de montar um mapa de redirecionamentos preciso ou definir um cronograma realista.
Quanto tempo leva para montar um plano de projeto de migração de site?
Montar o plano em si costuma levar de uma a duas semanas para um site pequeno e de duas a quatro semanas para um site grande ou complexo. Isso é separado da execução da migração, que tem seu próprio cronograma somado a esse.
Preciso de um desenvolvedor para escrever o plano de migração?
Não. O plano em si é um documento de projeto: mapas de URLs, cronogramas, responsáveis e pontos de teste. Um desenvolvedor executa partes dele, mas quem deve redigi-lo são as pessoas de SEO, conteúdo e liderança do projeto.
O que acontece se eu não configurar redirecionamentos durante uma migração?
Toda URL antiga sem redirecionamento retorna um erro 404. Os mecanismos de busca removem essa página do índice, os links que apontam para ela deixam de repassar valor e os visitantes dão de cara com um beco sem saída em vez do seu novo conteúdo.
Em quanto tempo vou saber se a migração prejudicou meus rankings?
A maioria das oscilações de ranking aparece em duas a quatro semanas após o lançamento, embora algumas possam levar mais tempo para se estabilizar por completo. É por isso que a fase de monitoramento de 30 a 90 dias importa tanto quanto o lançamento em si.
Coloque o plano no papel ainda esta semana
Comece pela auditoria e pelo congelamento de URLs: todas as outras fases de um plano de projeto de migração de site dependem de ter essa lista fechada primeiro. Se você quer uma visão clara do que precisa ser corrigido no seu site atual antes de mapear um único redirecionamento, fale com a equipe e receba um relatório de exemplo mostrando exatamente como isso ficaria para o seu site.
Fontes
- Data Migration Plan: How to Build It Step by Step (2026)
- The Definitive Guide on Website Migrations
- The Website Migration Process: What You Need To Know ...
Aviso legal: Este artigo traz informações gerais sobre regras e números que valiam na época em que foi escrito, e não é aconselhamento financeiro, tributário ou de investimento personalizado. Ele não leva em conta sua renda, suas obrigações, sua tolerância a risco nem seus objetivos, e taxas e limites mudam. Verifique a situação atual junto à autoridade competente e converse com um consultor habilitado ou um contador qualificado antes de agir.
Sobre o autor
O SearchBlueprint pesquisou, escreveu e avaliou este artigo com o mesmo pipeline de conteúdo que nossos clientes usam nos próprios sites. A nota que aparece na assinatura é a que nosso mecanismo de conteúdo deu a esta página antes de ela ser publicada. Nada aqui passa por revisão manual, e esse é justamente o ponto: é o resultado do produto, publicado onde qualquer pessoa pode conferir.