Plano de migração de site: como refazer o site sem perder o que já ranqueia no Google

**Refazer o site é migração, não lançamento.** Um **plano de migração de site** é o mapa de URL antiga para URL nova, escrito antes do go-live — não depois da queda. O redesign visual é a parte fácil; o que o Google já conhece são os endereços.

— O plano tem duas peças obrigatórias, ambas escritas antes de publicar: o inventário das URLs que hoje recebem busca e o mapa de redirecionamento 301 de cada uma para a equivalente nova.

— Página sem equivalente vai para o tema mais próximo, nunca toda para a home.

— Layout, tipografia e imagem são livres. Title, description e H1 das páginas que já ranqueiam não se reescrevem por gosto.

— Oscilação enquanto o índice reprocessa é esperada; erro real tem assinatura técnica — 404 em URL com tráfego, corrente de redirecionamento ou canonical errado.

— Se o site não recebe tráfego orgânico relevante, o plano inteiro é overhead: publique e mantenha só o sitemap correto.

**Migração e lançamento são projetos diferentes — e a diferença aparece no tráfego**

Lançamento publica endereços que ninguém conhece. Migração troca endereços que o buscador já indexou e por onde já entra gente.

**Índice** é a cópia das suas páginas que o buscador consulta para decidir o que mostrar na busca. **URL** é o endereço completo de cada página — `/servicos/landing-page/`, não apenas o domínio.

Trocar o layout não muda URL; trocar a estrutura do site muda. O erro que derruba tráfego quase nunca é estético: é publicar o site novo com endereços novos e deixar os antigos devolvendo **erro 404**, a resposta do servidor para "página não encontrada".

**Inventário: quais URLs recebem busca hoje**

Sem inventário não existe plano. Levante o que o site tem hoje e, desse total, o que recebe visita vinda de busca — são coisas diferentes.

— **Relatório de desempenho do Google Search Console**, a ferramenta gratuita que mostra por quais buscas o site aparece e quantos cliques cada página recebe.

— **O sitemap atual** — arquivo XML que lista as páginas para o buscador encontrar, em `/sitemap.xml`. Diz o que você declarou que existe.

— **Uma varredura do site**, que lista o que existe de fato, inclusive páginas fora do menu e do sitemap.

O resultado é uma planilha de quatro colunas: URL antiga, cliques, impressões e o assunto da página — a pergunta que ela responde, em uma frase.

Ordenar por tráfego separa o que exige cuidado cirúrgico do que pode ir em lote. Inclua URLs que recebem link de outros sites mesmo sem tráfego direto: elas carregam parte da reputação do domínio.

**O mapa de redirecionamento 301: uma linha por endereço antigo**

**Redirecionamento 301** é a resposta do servidor dizendo que o endereço mudou em definitivo e que o buscador deve tratar o novo como substituto do antigo, transferindo os sinais acumulados.

Resposta: 301 · O que significa: Mudou em definitivo · Quando usar na migração: Padrão para URL antiga com equivalente nova

Resposta: 302 · O que significa: Mudou temporariamente · Quando usar na migração: Fora de migração: mantém a antiga como oficial

Resposta: 404 · O que significa: Não encontrada · Quando usar na migração: Nunca em URL que tinha tráfego

Resposta: 410 · O que significa: Removida em definitivo · Quando usar na migração: Saiu do ar de propósito, sem equivalente

Cada URL antiga aponta para a nova equivalente **em conteúdo**, não para a mais parecida no nome. Endereço parecido com resposta diferente é pior que redirecionamento ausente: esconde o problema.

Evite corrente de redirecionamento — A que vai para B que vai para C. Refaça o mapa para A ir direto em C: corrente atrasa o carregamento e o reprocessamento.

Num servidor VPS, o redirecionamento vive na camada de servidor e é versionado junto com o projeto, não escondido em plugin — parte de [manter o projeto no seu nome e transferível](/blog/titularidade-de-dominio-e-codigo-em-projeto-de-software/). Teste o mapa inteiro em [ambiente de teste antes do go-live](/blog/da-descoberta-ao-deploy-com-fabrica-de-software/), nunca no dia.

**Páginas sem equivalente: tema mais próximo, não a home**

Mandar tudo para a home parece seguro e entrega o pior resultado: quem chega numa página genérica sai, e o buscador tende a tratar redirecionamento em massa para a home como **soft 404** — como se a página tivesse deixado de existir.

Na ordem, o destino: categoria que cobre o tema, artigo relacionado, página de serviço próxima.

Quando nada responde, há duas escolhas legítimas: reescrever o conteúdo dentro da estrutura nova — pode virar artigo, decisão de [escopo, que se escreve antes](/blog/escopo-de-projeto-de-software/) — ou deixar a página devolver **410**, em vez de fingir equivalência.

**Quando manter a URL antiga vale mais que a nova**

URL bonita é preferência interna; URL com histórico é ativo. O 301 funciona, mas não é gratuito: há reprocessamento e link externo apontando para o endereço antigo.

Se a URL antiga concentra parte relevante do tráfego e não atrapalha a navegação, mantê-la é a escolha barata. Trocar compensa em estrutura sem lógica, parâmetros confusos, endereços duplicados, domínio sem HTTPS. Trocar tudo de uma vez multiplica o risco.

**Title, description e H1 das páginas que já ranqueiam**

**Title** é o texto clicável do resultado de busca; **description**, o resumo abaixo; **H1**, o título principal da página. Title e H1 são sinais de conteúdo; a description influencia o clique. Páginas com histórico já provaram que os seus funcionam, e reescrever por gosto joga fora informação que custou meses.

Pede cautela apagar seções de texto que respondem exatamente à busca que traz a visita: tráfego depois do redesign costuma cair porque a página nova diz menos, não porque ficou feia. Regra prática: mudança visual em todas as páginas; mudança de texto só nas que não têm histórico — o mesmo critério de [conteúdo que atende busca real](/blog/seo-de-conteudo-para-marcas-de-tecnologia-e-servicos/).

**Canonical e sitemap: dizer qual versão é a oficial**

**Canonical** é a marcação no HTML que declara o endereço oficial de uma página, quando o mesmo conteúdo pode ser alcançado por mais de um endereço. É um dos sinais que mais sai errado no go-live.

— Canonical apontando para o domínio de teste: o site inteiro declara que o original está em outro lugar.

— Canonical em `http` quando o site serve `https`.

— Canonical apontando para a home em todas as páginas, efeito de template mal configurado.

O sitemap novo contém só as URLs novas e válidas. Deixar as antigas redirecionadas ali atrasa o reprocessamento: o buscador gasta rastreio em endereço que já mudou.

Submeta o sitemap no Search Console no go-live e confira o `robots.txt`: a permissão de rastreio do ambiente de teste, que bloqueia tudo, não pode subir junto.

Em SPA React, canonical e title precisam existir no HTML entregue pelo servidor, não só depois que o JavaScript roda — o caminho está em [SEO para SPAs React sem Next](/blog/seo-para-spas-react-sem-next/).

**O dia seguinte ao go-live: checklist e como separar oscilação de erro**

1. Testar as URLs antigas de maior tráfego: respondem 301 para o destino certo?

2. Confirmar que as páginas principais devolvem 200 — resposta de sucesso.

3. Checar canonical e title em cada template, não em uma página só.

4. Confirmar sitemap submetido e certificado HTTPS válido.

5. Verificar no Search Console: erros de rastreio, páginas excluídas e cobertura do sitemap.

Oscilação esperada é variação de posição enquanto o buscador reprocessa, com as páginas ainda indexadas e os redirecionamentos respondendo certo. Incomoda, e não é defeito.

Erro real tem assinatura técnica: 404 em URL com tráfego, redirecionamento em corrente, canonical errado, queda concentrada em um único template.

Recuperação não tem [prazo cravado](/blog/prazo-entrega-software/) — e desconfie de quem crava. Sem erro técnico aberto, o índice reprocessa. Monitorar é [medir com instrumento](/blog/devops-observabilidade-e-confianca-entre-times-e-clientes/), não atualizar o relatório todo dia.

Guarde o inventário e o mapa: o comparativo antes/depois é o que permite diagnosticar semanas depois, quando ninguém mais lembra o que mudou.

**Quando o plano de migração de site é overhead e o certo é só publicar**

Site sem tráfego orgânico relevante não tem o que preservar. O plano inteiro vira custo sem contrapartida, e insistir nele [encarece o projeto por precaução contra um risco que não existe](/blog/como-escolher-fabrica-de-software-alinhada-a-seu-produto/).

A verificação leva minutos no Search Console. Se quase todo o acesso vem de link direto, anúncio ou indicação, a sua migração é um lançamento e deve ser tratada como tal — inclusive [no orçamento](/blog/quanto-custa-criar-um-site-em-2026/). Mesmo aí, dois itens sobrevivem porque custam pouco: sitemap correto e nenhuma URL já divulgada devolvendo 404.

A tese é essa: o que protege o tráfego é o inventário e o mapa escritos antes, não a correção depois. Refazer o site sem perder o que ranqueia não depende de sorte nem de ferramenta cara — depende de um documento de duas colunas escrito antes do go-live.

Na Projask, site refeito sai com mapa de redirecionamento versionado junto do projeto e SEO técnico de base — canonical, sitemap e HTML servido pronto. Sem promessa de posição, porque posição ninguém entrega. Se você está planejando refazer um site que já recebe busca, a conversa é pelo WhatsApp.

**Como não perder tráfego no Google ao refazer o site?**

O plano de migração é o documento que mapeia cada URL antiga para a equivalente nova. Precisa ser escrito antes do go-live, não depois. Tem duas peças obrigatórias: o inventário das URLs que recebem busca hoje e o mapa de redirecionamento 301 para cada uma. Além disso, mantenha os títulos, descriptions e H1 das páginas que já ranqueiam — são sinais de conteúdo que custaram meses para ser produzidos. Deixe o canonical correto e submeta o sitemap novo no Search Console no dia do go-live.

**O que é redirecionamento 301 e como implementar na migração de um site?**

Redirecionamento 301 é a resposta do servidor que diz o endereço mudou em definitivo e que o buscador deve tratar a nova URL como substituto da antiga, transferindo os sinais acumulados. É o núcleo do plano de migração. Na prática, cada URL antiga aponta para a nova equivalente em conteúdo, não para a mais parecida no nome. Evite corrente de redirecionamento (A → B → C); refaça o mapa para A ir direto em C. Em entrega própria em VPS, o redirecionamento vive na camada de servidor e deve ser versionado junto com o projeto, testado em ambiente de teste antes do go-live.

**O que fazer com páginas antigas que não têm equivalente no site novo?**

O critério é único: o destino tem de responder à mesma pergunta que trazia a visita. Na ordem de preferência: categoria que cobre o tema, artigo relacionado, página de serviço próxima. Nunca mande tudo para a home — quem clicou procurando uma resposta específica cai numa página genérica, sai, e o buscador trata isso como soft 404. Quando nada responde, há duas escolhas legítimas: reescrever aquele conteúdo dentro da estrutura nova ou deixar a página devolver 410 (removida em definitivo), em vez de fingir equivalência.

**Preciso manter os títulos e descriptions das páginas que já ranqueiam?**

Sim. Title, description e H1 são sinais de conteúdo, e páginas com histórico já provaram que os seus funcionam. Se a página ranqueia para um termo, o texto atual é evidência — reescrever por gosto joga fora informação que custou meses para ser produzida. Dá para mexer sem risco em layout, tipografia, imagens, ordem dos blocos e botão de contato. Tráfego depois do redesign costuma cair porque a página nova diz menos, não porque ficou feia. A regra prática é: mudança visual em todas as páginas; mudança de texto só nas que não têm histórico, ou com um motivo escrito ao lado.

**Como saber se a queda de tráfego depois do go-live é normal ou é erro?**

Oscilação esperada é variação de posição enquanto o buscador reprocessa, com as páginas ainda indexadas e os redirecionamentos respondendo certo. Incomoda, mas não é defeito. Erro real tem assinatura técnica: 404 em URL com tráfego, redirecionamento em corrente (A → B → C), canonical apontando para o lugar errado, queda concentrada em um único template. O checklist do dia seguinte: testar URLs antigas de maior tráfego, confirmar que páginas principais devolvem 200, checar canonical e title em cada template, verificar sitemap e certificado HTTPS, e conferir no Search Console erros de rastreio e cobertura.