Migração de site sem perder ranking: como migrar sem perder no SEO.

Uma migração de site só preserva o ranking quando cada URL antiga tem um destino definido antes da virada. O resto (servidor novo, CMS novo, design novo) é consequência. Quando uma empresa perde tráfego orgânico depois de migrar, quase sempre a causa é a mesma: endereços que existiam, geravam acesso e simplesmente deixaram de responder, sem ninguém dizer ao Google para onde eles foram.

A documentação de migrações de site do Google Search Central é explícita nesse ponto: em mudanças que alteram URLs, a orientação é redirecionar cada endereço antigo para o novo correspondente, porque é esse sinal que transfere o histórico acumulado.

Nas auditorias pós-migração que conduzimos na Verticis, a ausência ou o uso incorreto desses redirecionamentos é o achado que mais se repete.

Este guia trata a migração como um processo técnico de preservação de SEO, válido para qualquer tipo de troca: hospedagem, servidor, sistema de gestão de conteúdo, domínio ou estrutura de URLs. Se a sua mudança envolve sair de uma plataforma fechada para um sistema próprio, vale ler também o material sobre migração de plataforma, que trata do lado estratégico da decisão. Aqui o foco é a execução: o que mapear antes, o que configurar durante e o que monitorar depois.

Por que toda migração de site é um risco silencioso para o SEO

O risco é silencioso porque o site continua no ar.

Ele abre, as páginas principais funcionam, o time comemora e ninguém percebe que trinta ou quatrocentas URLs internas pararam de existir. A queda aparece três semanas depois, quando o Google já reprocessou boa parte do site e removeu do índice o que passou a responder com erro.

O que o Google tem hoje sobre o seu domínio é um histórico acumulado: endereços conhecidos, autoridade distribuída entre eles, sinais de comportamento, links externos apontando para páginas específicas. Esse histórico está atrelado à URL, não ao conteúdo.

Se o texto continua igual mas o endereço mudou sem redirecionamento, o buscador entende que a página sumiu e que apareceu uma nova, sem passado.

Há ainda o fator infraestrutura. Trocar de servidor altera tempo de resposta, configuração de cache, versão de PHP, certificado SSL e cabeçalhos HTTP. Tudo isso entra na avaliação técnica do site. Uma migração que resolve o SEO de URLs mas entrega um servidor mais lento troca um problema por outro, especialmente em métricas de experiência como o INP.

O que acontece com o ranking quando a migração é mal planejada

A perda não é instantânea e isso atrapalha o diagnóstico. O Google precisa rastrear novamente cada endereço para constatar que ele mudou de status, e a frequência desse rastreamento varia conforme a relevância da página. Páginas fortes são revisitadas rápido; páginas de cauda longa podem levar semanas.

Na prática, o padrão que vemos em auditorias pós-migração costuma seguir esta sequência:

• Primeiros dias: oscilação nas impressões, queda discreta em páginas secundárias, aumento de erros no relatório de cobertura.
• Segunda e terceira semana: páginas de cauda longa saem do índice, o tráfego de busca cai de forma mais visível e as conversões orgânicas acompanham.
• Mês seguinte: o site estabiliza em um patamar mais baixo, e recuperar exige retrabalho maior do que teria custado planejar a migração direito.

O ponto central é que a recuperação depois de uma migração mal feita raramente é automática. Corrigir redirecionamentos um mês depois funciona, mas o site passa por um novo ciclo de reprocessamento, e parte da autoridade que estava consolidada demora a voltar.

Antes de migrar: checklist técnico de preparação

A maior parte do trabalho de uma migração acontece antes de qualquer arquivo ser copiado. Esta é a fase que determina se você vai monitorar métricas ou apagar incêndio.

Mapeamento completo de URLs

Levante todos os endereços que o site tem hoje, não apenas os que estão no menu. Use um rastreador como o Screaming Frog para varrer o site inteiro, exporte as URLs com tráfego do Google Analytics e do Search Console dos últimos doze meses e cruze com o sitemap atual. Páginas antigas que ninguém lembra costumam ser justamente as que recebem backlinks.

O resultado precisa ser uma planilha com colunas definidas: URL antiga, status HTTP atual, título da página, tráfego orgânico nos últimos meses, URL de destino na estrutura nova e observação. Essa planilha vira o contrato da migração. Nenhuma linha pode ficar sem destino.

Inclua no mapeamento imagens e arquivos. PDFs de catálogo, manuais e materiais ricos também são indexados e também recebem links. Se o caminho da pasta de uploads mudar, esses arquivos quebram junto.

Plano de redirecionamentos 301

Para cada URL antiga que não vai existir no site novo, defina o endereço equivalente mais próximo. A regra prática é redirecionar para a página que entrega o mesmo conteúdo ou a mesma intenção de busca, nunca para a home por padrão.

Redirecionar tudo para a página inicial é o atalho mais comum e um dos mais caros. O Google interpreta redirecionamentos em massa para a home como soft 404, o que significa que ele desconsidera o sinal e trata as páginas antigas como removidas. A autoridade acumulada se perde no caminho.

Quando não existe equivalente real (um produto descontinuado, um serviço encerrado), três caminhos são legítimos: redirecionar para a categoria correspondente, criar uma página nova que atenda a mesma busca ou manter o 410 Gone de forma consciente, aceitando a desindexação daquele endereço.

Atualização do sitemap e do robots.txt

O sitemap novo deve conter apenas as URLs finais, com status 200 e sem redirecionamento no meio. Um erro recorrente é publicar o sitemap antigo no ambiente novo, enviando ao Google uma lista de endereços que agora respondem com 301 ou 404.

Uma técnica útil nas primeiras semanas é manter dois sitemaps enviados ao Search Console: o novo, com a estrutura final, e um temporário com as URLs antigas que foram redirecionadas. Isso acelera o rastreamento dos 301 e ajuda o buscador a reconhecer as substituições mais rápido. Depois de alguns meses, o sitemap temporário é removido.

O robots.txt merece atenção redobrada. Ambientes de homologação costumam bloquear todo o rastreamento, e migrar esse arquivo junto com o resto é um acidente clássico. Confira a primeira linha depois da virada: um Disallow: / esquecido tira o site inteiro do índice em poucos dias.

Backup e ambiente de homologação

Backup completo e testado, incluindo arquivos e banco de dados, antes de encostar em qualquer coisa. Testado significa que você já restaurou essa cópia em outro ambiente e confirmou que ela funciona, não apenas que o arquivo existe.

O ambiente de homologação permite validar a migração com o site antigo ainda no ar. Monte o site novo em um subdomínio bloqueado por senha, rode o rastreador nele, teste formulários, integrações, checkout e áreas logadas. Qualquer coisa que der errado ali é um problema que você evitou em produção.

Como migrar site WordPress para outro servidor (ou para a Hostinger) sem perder SEO

A migração de um site WordPress entre servidores tem uma sequência bem definida. Cenários como migrar site para a Hostinger, para a Kinsta ou para um VPS próprio seguem a mesma lógica: o que muda é a ferramenta, não o método.

Fase 1: preparação do ambiente de destino

Antes de copiar qualquer coisa, configure o servidor novo com a mesma versão de PHP ou superior, os mesmos limites de memória e upload, e o certificado SSL emitido para o domínio. Divergência de versão de PHP é a causa número um de telas brancas logo depois da virada.

Verifique também o módulo de reescrita de URLs (mod_rewrite no Apache ou as regras equivalentes no Nginx). Sem ele, os permalinks do WordPress quebram e o site inteiro passa a responder 404, mesmo com todos os arquivos no lugar.

Fase 2: cópia de arquivos e banco de dados

Painéis como o da Hostinger oferecem ferramentas automáticas de migração, e elas funcionam bem para sites padrão. Para projetos com customizações, plugins pesados ou bancos grandes, o processo manual dá mais controle: exporte o banco pelo phpMyAdmin ou por linha de comando, transfira a pasta wp-content via SSH ou FTP e recrie o wp-config.php com as novas credenciais.

Se o domínio permanecer o mesmo, não há substituição de URLs no banco. Se houver troca de domínio ou saída de HTTP para HTTPS, use uma ferramenta de search and replace serializada, como o WP-CLI ou o Better Search Replace. Rodar um UPDATE simples no SQL corrompe dados serializados de temas e plugins.

Fase 3: testes antes de apontar o DNS

Edite o arquivo hosts da sua máquina para acessar o domínio no servidor novo enquanto o público continua no antigo. Com isso você testa o site real, com o domínio real, sem expor nada.

Nessa etapa, confira páginas internas, não só a home. Rode o rastreador, valide status HTTP, teste os redirecionamentos do plano, envie um formulário, faça uma compra de teste se houver loja e confirme que as tags de analytics e de conversão estão disparando.

Fase 4: virada de DNS e propagação

Reduza o TTL do DNS para 300 segundos com 24 a 48 horas de antecedência. Isso faz a propagação acontecer em minutos em vez de horas. Mantenha o servidor antigo ativo por pelo menos uma semana depois da virada, porque visitantes e robôs com cache de DNS antigo ainda podem cair nele.

Faça a virada em um horário de baixo tráfego e com alguém disponível para acompanhar. As primeiras duas horas são quando aparecem os problemas de certificado, mixed content e cache mal configurado.

Redirecionamentos 301, erros 404 e sitemap: os pontos que mais derrubam tráfego

Três elementos concentram a maior parte das perdas de tráfego em migrações de sites. Eles são simples de configurar e igualmente simples de esquecer.

Qual redirecionamento usar em cada situação

Cadeias e loops de redirecionamento

Uma cadeia acontece quando a URL A redireciona para B, que redireciona para C. Cada salto adiciona latência e dilui o sinal. Em migrações que acumulam mudanças ao longo dos anos, é comum encontrar cadeias de quatro ou cinco saltos.

A solução é apontar sempre para o destino final. Se o site já tinha redirecionamentos antigos, atualize-os para o novo endereço em vez de empilhar uma camada nova por cima. O loop, em que A aponta para B e B aponta para A, deixa a página inacessível e aparece como erro de rastreamento.

Erros 404 que ninguém viu

Páginas 404 geradas por URLs não redirecionadas são a causa mais frequente de queda de tráfego pós-migração. Elas não aparecem em nenhum relatório de negócio, porque o usuário que cai nelas simplesmente volta para o Google.

Monitore o relatório de páginas não encontradas no Search Console diariamente na primeira semana e semanalmente no primeiro mês. Toda URL que aparecer ali com histórico de tráfego ou de links precisa de um 301. Se precisar aprofundar o diagnóstico, o guia sobre como resolver erro 404 detalha o tratamento caso a caso.

Depois de migrar: monitoramento de indexação e correção de problemas

A migração não termina quando o site entra no ar. Termina quando os indicadores de busca voltam ao patamar anterior, o que leva semanas.

Primeiras 48 horas

Confirme que o robots.txt não está bloqueando o rastreamento e que nenhuma página carrega a meta tag noindex herdada do ambiente de testes. Em WordPress, verifique também a opção “Sugerir aos motores de busca que não indexem este site” nas configurações de leitura, que vem marcada por padrão em instalações novas.

Envie o sitemap atualizado ao Google Search Console, use a inspeção de URL nas páginas mais importantes e solicite indexação manualmente para elas. Valide se o certificado SSL cobre o domínio com e sem www e se não há conteúdo misto carregando por HTTP.

Primeiras semanas

Acompanhe quatro indicadores em paralelo: páginas indexadas, impressões, cliques e posição média por consulta. Oscilação é esperada; tendência de queda contínua por mais de dez dias indica problema estrutural, não ajuste natural.

Rode um rastreamento completo do site novo e compare com a planilha de mapeamento. Toda URL antiga com tráfego precisa responder 301 e levar a uma página 200. O material sobre como melhorar a indexação do seu site ajuda a interpretar os relatórios de cobertura quando o volume de páginas é grande.

Sugestão de imagem (troque pela imagem ou apague antes de publicar): gráfico de linha do Google Search Console mostrando queda de cliques após uma migração e recuperação gradual ao longo de oito semanas

Erros mais comuns que comprometem o SEO em migrações de sites

Os problemas se repetem com frequência suficiente para formar uma lista previsível:

• Redirecionar tudo para a home. O Google trata como soft 404 e descarta o sinal de transferência de autoridade.
• Sitemap desatualizado enviado ao Search Console. Lista URLs que já não existem e consome orçamento de rastreamento em endereços mortos.
• Noindex ou Disallow herdados do ambiente de testes. Tiram o site do índice sem que ninguém perceba de imediato.
• Perda de meta tags e dados estruturados. Troca de tema ou de plugin de SEO pode apagar títulos e descrições customizados que levaram meses para serem escritos.
• Mudança de estrutura de URLs sem necessidade. Se não há ganho claro, mantenha os endereços. Cada URL alterada é um risco assumido.
• Imagens e PDFs esquecidos. Arquivos com link externo que deixam de responder perdem a autoridade que traziam.
• Servidor novo mais lento que o antigo. A migração resolve o SEO técnico de URLs e cria um problema de performance.
• Desligar o servidor antigo cedo demais. Com cache de DNS ainda ativo, parte dos acessos cai no vazio.

Esses pontos valem tanto para troca de hospedagem quanto para reformulações maiores. Se o seu caso envolve reconstruir o projeto, vale alinhar expectativas com o conteúdo sobre refazer site, que trata do momento certo e do escopo dessa decisão.

Quanto tempo o Google leva para reconhecer a nova estrutura

O Google não publica um prazo fixo para reprocessar uma migração, e a própria documentação de migrações de site evita cravar números. Sem prazo documentado publicamente, o que resta é a observação em projetos reais. O que determina a velocidade é a frequência com que o buscador já rastreia o seu domínio, o volume de páginas envolvidas e a qualidade da sinalização que você deixou pronta.

Nos projetos de migração acompanhados pela nossa equipe, o padrão observado é este: páginas principais costumam ser reprocessadas em poucos dias, o grosso do site em algumas semanas e as páginas de cauda longa podem levar meses. Sites com muitas URLs e rastreamento pouco frequente ficam na faixa mais longa.

Enquanto esse processo acontece, resista ao impulso de mudar outras coisas. Alterar estrutura de conteúdo, publicar redesenho de páginas ou mexer em taxonomias durante a reindexação mistura variáveis e impede diagnosticar o que causou o quê. Migração e redesign no mesmo deploy são dois riscos somados.

Como estruturar um plano de migração sem comprometer a performance

Um plano de migração funcional cabe em um documento de poucas páginas, com responsáveis, datas e critérios de aceite. A estrutura que usamos em projetos segue cinco blocos.

• Diagnóstico. Inventário completo de URLs, status, tráfego e backlinks. Linha de base das métricas de SEO e de performance registrada antes de qualquer mudança, para comparação posterior.
• Arquitetura de destino. Definição da estrutura de URLs final, mapa de redirecionamentos linha a linha e especificação do ambiente de servidor, incluindo versão de PHP, cache e CDN.
• Homologação. Site novo montado em ambiente fechado, rastreado, testado e aprovado. Nenhuma virada acontece sem validação prévia de formulários, integrações e tags de medição.
• Virada. Janela definida em horário de baixo tráfego, TTL reduzido com antecedência, equipe disponível e plano de rollback documentado. Se algo der errado nas primeiras horas, deve existir um caminho de volta claro.
• Estabilização. Monitoramento diário na primeira semana, correção de 404 conforme aparecem e comparação com a linha de base até os indicadores voltarem ao patamar anterior.
• Projetos que envolvem arquiteturas mais modernas, como separar o front-end do gerenciador de conteúdo, exigem um nível a mais de planejamento. O conteúdo sobre Headless WordPress mostra o que muda na parte técnica quando essa é a direção escolhida.

Case Verticis: migração e otimização dos sites da Adventist Health Brasil

A Verticis foi responsável por conduzir melhorias técnicas e estratégias de SEO durante a reestruturação dos ambientes digitais da Adventist Health Brasil, incluindo os sites do CEVISA, CVS, Hospital Adventista São Paulo (HASP) e o novo Hub de Notícias.

O projeto envolveu a migração de sites, o mapeamento de URLs antigas, a implementação de redirecionamentos 301, a reorganização dos conteúdos e a configuração de elementos essenciais de SEO, como sitemaps, links internos e regras de indexação.

Um dos principais desafios foi a centralização das notícias em um único ambiente, preservando o acesso aos conteúdos anteriormente publicados em outros domínios.

Com essas ações, a Verticis contribuiu para uma migração mais segura, reduzindo erros de navegação, preservando os caminhos de acesso existentes e minimizando os riscos de perda de visibilidade orgânica. O projeto demonstra como o planejamento técnico e a execução de SEO são fundamentais para modernizar a presença digital de uma organização sem comprometer o trabalho de posicionamento construído ao longo dos anos.

Perguntas frequentes.

Migração de site sempre faz perder ranking?

Não. Uma migração bem executada preserva o posicionamento, com oscilação pequena e temporária durante o reprocessamento. A perda acontece quando URLs ficam sem redirecionamento, quando o sitemap não é atualizado ou quando o site novo entra no ar com bloqueios de indexação herdados do ambiente de testes.

Preciso mudar as URLs quando troco de servidor?

Não. Troca de servidor ou de hospedagem não exige alteração de endereços. Se o domínio e a estrutura permanecem, o Google nem percebe a mudança além da variação de tempo de resposta. Mantenha as URLs sempre que possível, porque cada alteração adiciona risco sem ganho garantido.

Por quanto tempo devo manter os redirecionamentos 301?

No mínimo um ano, e de preferência de forma permanente. Links externos antigos continuam apontando para os endereços originais por anos, e remover os redirecionamentos transforma esse tráfego em erro 404. O custo de manter as regras ativas é baixo perto do que se perde ao desligá-las.

Posso migrar o site e refazer o design ao mesmo tempo?

É possível, mas não é recomendável. Juntar as duas mudanças impede identificar a origem de qualquer queda de tráfego. O caminho mais seguro é migrar a infraestrutura primeiro, estabilizar os indicadores e só depois trabalhar o redesign, com nova medição.

Como saber se a migração de site deu certo?

Compare os indicadores com a linha de base registrada antes da virada: páginas indexadas, impressões, cliques, posição média e tempo de carregamento. Além disso, o relatório de cobertura do Search Console não deve apresentar crescimento sustentado de erros, e nenhuma URL com histórico de tráfego pode estar respondendo 404.

Planejando sua migração de site com segurança.

Migrar um site é uma operação técnica com consequências comerciais diretas. O que separa uma troca tranquila de uma queda de tráfego é o trabalho feito antes da virada: mapear, planejar redirecionamentos, testar em ambiente fechado e definir como o resultado será medido.

Se você planeja migrar seu site e quer evitar perda de tráfego orgânico, fale com nossa equipe técnica e receba uma avaliação de SEO antes de qualquer mudança de plataforma, servidor ou domínio.