Migração de site: como não perder tráfego orgânico

Toda migração de site carrega um medo específico: acordar na semana seguinte e ver o tráfego orgânico despencar. Esse medo é razoável, mas a causa quase nunca é o ato de migrar em si — é o que fica de fora do planejamento. Trocar de domínio, sair do HTTP para o HTTPS, reestruturar URLs, trocar de plataforma, redesenhar o site nas mesmas URLs ou fundir dois sites em um: cada uma dessas mudanças é tratada por muita gente como se fosse a mesma tarefa, com o mesmo risco. Não é.

Este artigo trata a migração como o que ela é: um projeto com sequência específica, não um deploy qualquer. O centro do trabalho não é o redirecionamento — é o inventário e o mapeamento que vêm antes dele, porque um redirecionamento correto aplicado sobre um mapeamento incompleto ainda perde valor. A seguir, o roteiro: os tipos de migração e o risco de cada um, como levantar cada URL que importa, como mapear a antiga para a nova uma a uma, o que precisa viajar junto com a URL, staging, checklist de lançamento, monitoramento das primeiras semanas e como ler a curva de recuperação sem confundir uma queda normal com um problema real.

Os tipos de migração — e por que cada um tem um risco diferente

"Migração de site" é um guarda-chuva para pelo menos seis mudanças distintas, e tratá-las como uma coisa só é o primeiro erro. Cada tipo desloca uma parte diferente do que o Google usa para entender e classificar o site.

Troca de domínio é a mais radical: cada sinal de autoridade associado ao endereço antigo — backlinks, histórico, confiança acumulada — precisa ser reconectado ao novo via redirecionamento, um a um. É o tipo de maior risco porque afeta 100% das URLs de uma vez. Migração de HTTP para HTTPS parece menor, mas troca o protocolo em cada URL; sem tratar certificado, redirecionamento e conteúdo misto (recursos ainda em HTTP) juntos, o site acaba servindo duas versões concorrentes da mesma página.

Reestruturação de URLs — mudar de /categoria/produto para /produto, por exemplo — troca o endereço sem trocar domínio nem plataforma. O erro comum é subestimar o volume: quem mapeia as páginas de produto esquece as de filtro, os arquivos de tag e os documentos indexados como PDF. Troca de plataforma ou CMS costuma mudar estrutura de URLs, geração de HTML e metadados padrão ao mesmo tempo — e o time frequentemente aproveita para "limpar" textos antigos. Quando várias mudanças chegam juntas, fica difícil isolar qual delas causou um problema.

Redesign nas mesmas URLs é o tipo mais seguro em teoria, já que o endereço de cada página não muda. O risco aqui é outro: perder, na troca de layout ou builder, conteúdo indexável que virou imagem, texto que só carrega por interação do usuário, ou títulos e cabeçalhos que a nova template não reproduz. Consolidação ou divisão de sites — juntar dois domínios em um, ou separar um site em vários — é o tipo mais fácil de subestimar: exige decidir, página por página, qual conteúdo sobrevive quando duas URLs concorrentes cobrem o mesmo assunto.

Por que a perda de tráfego quase sempre é evitável

É tentador tratar a queda de tráfego pós-migração como custo inevitável, algo que "sempre acontece" quando um site muda de endereço. Na prática, a maioria das perdas graves tem causa identificável: URLs não mapeadas que não redirecionam para lugar nenhum; redirecionamentos que apontam todos para a home em vez do destino equivalente; conteúdo que mudou junto com o endereço, deixando a página nova sem o que fazia a antiga rankear; ou uma verificação que faltou antes do lançamento e só foi notada depois que o rastreador já visitou o site com o problema no ar.

A migração em si — a troca de endereço — não é o que derruba posições. O Google lida com troca de domínio e de estrutura o tempo todo; existe um mecanismo desenhado exatamente para isso, o redirecionamento 301, que sinaliza que o valor de uma URL deve ser transferido para outra. O problema aparece quando esse mecanismo é usado de forma incompleta, ou quando o trabalho que precisa acontecer antes dele — descobrir todas as URLs, decidir o destino de cada uma — é pulado por pressa de lançamento.

O inventário de URLs: a etapa que decide o resultado

Antes de qualquer redirecionamento, título novo ou linha de código, existe uma pergunta que precisa de resposta completa: quais URLs do site atual importam? Não é uma pergunta retórica — é um levantamento que precisa combinar mais de uma fonte, porque nenhuma fonte isolada é completa.

Um rastreamento (crawl) do site atual encontra as URLs linkadas e navegáveis hoje, mas não enxerga páginas que perderam o link interno e continuam recebendo tráfego ou backlinks. O Search Console mostra o que o Google efetivamente indexou e o que gera cliques, incluindo variações que o crawl não alcança. O analytics revela quais URLs realmente trazem visitas, conversões ou receita — a lista que traduz risco técnico em risco de negócio. O sitemap XML lista o que o site declara como relevante, o que às vezes diverge do que está de fato online. E os logs de servidor mostram o que o rastreador visitou de fato nas últimas semanas, incluindo URLs antigas que ainda geram hits sem estarem mais linkadas em lugar nenhum.

Cruzar essas cinco fontes produz uma lista mais longa e mais correta do que qualquer uma sozinha. É comum essa etapa revelar centenas de URLs esquecidas: páginas de campanha antigas, versões com parâmetro, páginas de busca interna, arquivos que acumularam links externos ao longo dos anos. Cada uma, se tiver tráfego, backlink ou posição associada, é um risco se ficar de fora do mapeamento.

• Rastreamento (crawl) do site: o que está navegável e linkado hoje
• Google Search Console: o que está indexado e o que gera cliques
• Analytics: o que realmente traz visitas e conversões
• Sitemap XML atual: o que o site declara como relevante
• Logs de servidor: o que o rastreador do Google visitou de fato, incluindo URLs sem link interno

O mapeamento: cada URL antiga aponta para um destino específico

Com o inventário pronto, o passo seguinte é a planilha de mapeamento: uma linha por URL antiga, com a URL nova correspondente ao lado. O objetivo é um mapeamento um para um sempre que existir equivalente — produto antigo para produto novo, não para a categoria; artigo antigo para o artigo que o substitui, não para o blog inteiro.

Quando não existe equivalente direto, a decisão certa raramente é redirecionar para a home: é apontar para a página de categoria mais próxima em conteúdo, ou, quando nem isso existir, deixar a URL retornar 404 (ou 410, se a remoção for definitiva) em vez de forçar um redirecionamento sem relação real, que não preserva valor — só transfere o problema de lugar.

Esse mapeamento também é o momento de decidir, numa consolidação de sites, qual das duas URLs concorrentes vira a definitiva quando dois domínios cobrem o mesmo assunto — resolvido na planilha, antes do redirecionamento entrar no ar, não depois.

Redirecionamentos que preservam o valor acumulado

Com o mapeamento pronto, o redirecionamento em si segue três regras simples de errar na prática, mesmo sendo simples de enunciar.

A primeira é usar 301, não 302. Um 302 comunica que a mudança é temporária, e o rastreador tende a manter a URL antiga como a canônica em vez de transferir sinais para a nova — o efeito prático é o site ficar meses num estado ambíguo, sem o novo endereço acumular o que o antigo tinha. Se a mudança é permanente, o código precisa dizer isso.

A segunda é evitar cadeias de redirecionamento: uma URL que já migrou uma vez não deveria acumular uma segunda regra por cima da primeira — A para B, depois B para C — em vez de atualizar a regra para A apontar direto para C. Cada salto adiciona latência, e cadeias longas acabam abandonadas pelo rastreador antes do destino final.

A terceira, e a que mais destrói valor quando ignorada, é nunca usar a home como destino padrão para o que não tem mapeamento óbvio. Um redirecionamento em massa para a home devolve, a cada visitante e rastreador, uma página sem relação com o que foi buscado — reconhecido como sinal de baixa qualidade, na prática equivalente a não ter redirecionado. O valor de ranking de uma página específica não se transfere para a home só porque o redirecionamento aponta para lá; ele se perde, porque não existe correspondência real de conteúdo entre origem e destino.

O que precisa viajar junto com a URL

O redirecionamento move o endereço, mas não move sozinho o que fazia a página funcionar. Vários elementos precisam ser recriados deliberadamente no destino, não herdados por acidente.

Título e metadados da página antiga devem ser replicados (ou melhorados intencionalmente) na nova, porque uma plataforma nova costuma gerar título e meta description automáticos que substituem o que foi trabalhado manualmente por anos. Dados estruturados — schema de produto, artigo, FAQ, o que estiver implementado — precisam existir no template novo; é comum uma migração de CMS remover o markup porque o plugin que o gerava não tem equivalente na plataforma nova.

Links internos são o ponto mais negligenciado: depois da migração, o site deveria linkar direto para os destinos finais, não através da cadeia de redirecionamento. Milhares de links apontando para URLs antigas que redirecionam funcionam, mas desperdiçam o orçamento de rastreamento com saltos desnecessários. Tags canônicas precisam apontar para a nova URL, nunca para a antiga, e para sites com versões em outros idiomas as anotações de hreflang precisam mudar junto: se a versão em português migra e as outras versões continuam com hreflang apontando para o endereço antigo, o Google recebe instruções conflitantes sobre qual URL é a correspondente daquele idioma.

• Título e meta description replicados ou melhorados deliberadamente
• Dados estruturados (schema) recriados no template novo
• Links internos apontando direto ao destino final, sem passar por redirecionamento
• Tags canônicas atualizadas para a nova URL
• Anotações de hreflang atualizadas em todas as versões de idioma, se existirem

Staging, lançamento e as primeiras semanas de monitoramento

O ambiente de staging é onde o site novo fica disponível para teste antes de ir ao ar. O acidente mais comum aqui é o staging ficar acessível a rastreadores e ser indexado como se fosse o site real, criando conteúdo duplicado num endereço que não deveria existir para o público. Bloquear o staging por autenticação — não só por robots.txt, que um crawler mal-comportado pode ignorar — e confirmar que nenhuma página dele apareceu no índice antes do lançamento evita o problema por completo.

No dia do lançamento, a sequência que evita a maior parte dos incidentes é: confirmar que todos os redirecionamentos do mapeamento estão ativos e retornando 301, testados por script e não por amostragem manual; confirmar que o sitemap novo reflete as URLs novas e foi reenviado; confirmar que a produção não carrega nenhuma diretiva de "noindex" herdada do staging; e verificar que o robots.txt não está bloqueando seções inteiras por engano — comum quando a configuração do staging é copiada às pressas para produção.

Nas semanas seguintes, o acompanhamento não deveria ser só "o tráfego caiu ou não". Vale checar, no Search Console, se o número de páginas indexadas converge para o esperado, se erros de rastreamento aparecem em volume anormal, e se as páginas de maior valor recuperam posição na velocidade esperada, mesmo que o agregado do site ainda esteja em ajuste.

A curva de recuperação normal — e o que fazer se o tráfego não voltar

Mesmo numa migração bem executada, é comum passar por uma janela de reprocessamento: o Google precisa rastrear as URLs novas, associá-las às antigas via redirecionamento e transferir os sinais de ranking, o que não acontece de um dia para o outro em nenhum site com mais que um punhado de páginas. Um recuo temporário nas primeiras semanas, seguido de recuperação gradual conforme o rastreamento avança, é o padrão esperado e não deveria, sozinho, ser lido como sinal de que algo deu errado.

O que diferencia um recuo normal de um problema real é a trajetória, não o fato de ter caído. Uma curva que se estabiliza e volta a subir, ainda que devagar, está no caminho esperado. Uma curva que segue achatada ou caindo além do período inicial de reprocessamento é o sinal de que algo no inventário, no mapeamento ou nos redirecionamentos ficou incompleto — e vale voltar direto para essas etapas, não para ajustes cosméticos no site novo.

Quando o tráfego não volta depois de um tempo razoável, o diagnóstico correto é reabrir o inventário original e comparar, URL por URL, o que tinha tráfego antes contra o que está indexado e recebendo visitas agora. Quase sempre aparece um subconjunto específico — uma seção, um tipo de página, um cluster de conteúdo — que ficou fora do mapeamento ou perdeu, na migração, o que fazia aquelas páginas rankearem. Corrigir esse subconjunto pontualmente costuma resolver mais do que qualquer ajuste genérico no site inteiro.