Trocar a plataforma de um portal grande — um site de notícias, um portal corporativo, uma base de conhecimento com anos de conteúdo — é um dos projetos com maior potencial de dar errado de forma visível. Feito sem método, derruba o tráfego orgânico, quebra links compartilhados por anos e gera meses de retrabalho para recuperar posições. Feito com planejamento, a migração passa quase despercebida pelos usuários e pelos mecanismos de busca.

A diferença está quase toda na preparação. Este roteiro cobre as etapas que não podem faltar, na ordem em que costumam ser executadas.

1. Inventário de conteúdo e de URLs

O primeiro passo é saber exatamente o que existe. Isso significa levantar todas as URLs do site atual — não as que você acha que existem, mas as que os mecanismos de busca conhecem e as que recebem acessos. As fontes:

  • O rastreamento completo do site com uma ferramenta de auditoria (Screaming Frog, Sitebulb ou similar).
  • O relatório de páginas do Search Console, com impressões e cliques dos últimos 12 meses.
  • Os logs do servidor, que mostram o que realmente é acessado, inclusive por URLs antigas que não estão mais linkadas.
  • A analítica, para entender quais páginas trazem tráfego e conversão.
  • O relatório de backlinks, para identificar páginas que recebem links externos e não podem sumir.

Com esse inventário, cada URL entra em uma de três categorias: migrar como está, migrar com novo endereço ou aposentar. Páginas sem tráfego, sem links e sem valor editorial podem ser descontinuadas — mas de forma consciente, não por acidente.

2. Arquitetura de informação e padrão de URLs

A migração é a oportunidade de corrigir uma estrutura de navegação que cresceu de forma desordenada. Defina as seções, as categorias, as páginas de tópico e a hierarquia antes de pensar em layout. Uma arquitetura clara ajuda o usuário a encontrar conteúdo e ajuda o buscador a entender a cobertura do portal.

Sobre as URLs, a regra é: preserve sempre que possível. Cada URL que muda é um redirecionamento a mais para manter, um ponto a mais de risco e uma pequena perda de autoridade. Quando a mudança for inevitável — porque o padrão antigo era ruim ou porque a estrutura mudou —, o novo padrão deve ser estável, legível e sem parâmetros desnecessários.

3. Mapa de redirecionamentos 301

Para cada URL que muda de endereço, é preciso um redirecionamento 301 (permanente) da antiga para a nova. Esse mapa é o coração da migração e merece atenção obsessiva.

  • Um redirecionamento direto: da URL antiga para a URL nova final, nunca para uma página intermediária.
  • Nada de cadeias: A não deve redirecionar para B que redireciona para C. Cadeias desperdiçam autoridade e tempo de rastreamento.
  • Nada de redirecionar tudo para a home: uma página de artigo que sumiu deve ir para o conteúdo equivalente mais próximo ou retornar 404/410 de forma limpa.
  • Para conteúdo realmente removido sem substituto, um 404 com página útil (busca, links para seções principais) ou um 410 se a remoção é definitiva.

O mapa deve ser testado antes da virada: uma amostra grande de URLs antigas, verificada uma a uma para confirmar que chega ao destino certo com o código de status certo.

4. Migração de dados e mídia

O conteúdo em si — textos, imagens, documentos, metadados, datas de publicação, autoria — precisa ser transferido preservando o que importa para SEO e para o histórico. Pontos de atenção:

  • Datas de publicação e de atualização originais, não a data da migração.
  • Textos alternativos das imagens e legendas.
  • Títulos e meta descriptions já otimizados, quando existirem.
  • Tags e categorias, remapeadas para a nova taxonomia.
  • Comentários, se forem relevantes para o engajamento.
  • Mídia servida de um caminho estável, com redirecionamento se o caminho mudar.

5. SEO técnico da nova plataforma

Antes de publicar, a nova plataforma precisa estar tecnicamente pronta:

  • Sitemap XML completo e atualizado, pronto para ser reenviado.
  • Tags canônicas corretas em todas as páginas.
  • Dados estruturados equivalentes aos do site antigo (artigo, breadcrumb, organização).
  • Robots.txt liberando o que deve ser rastreado e bloqueando o que não deve.
  • Performance dentro dos alvos de Core Web Vitals.
  • Ambiente de homologação bloqueado para rastreamento, para não gerar conteúdo duplicado indexado.

6. Publicação

A virada deve acontecer em janela de baixo tráfego, com a equipe disponível para monitorar. A sequência típica: publicar a nova plataforma, ativar os redirecionamentos, verificar uma amostra de URLs em produção, reenviar o sitemap no Search Console e solicitar a reindexação das páginas mais importantes.

Não faça a migração às vésperas de um evento importante para o negócio, nem na sexta à tarde. Reserve os dias seguintes para acompanhamento intensivo.

7. Monitoramento pós-migração

Nas primeiras semanas, acompanhe de perto:

  • Erros de rastreamento e páginas não encontradas no Search Console.
  • Cobertura de indexação: quantas páginas foram indexadas versus o esperado.
  • Posições das palavras-chave mais importantes.
  • Tráfego orgânico por seção, comparado com o período anterior.
  • Logs do servidor, para ver o que os robôs estão rastreando e onde encontram erro.

É normal uma oscilação nas primeiras semanas enquanto o buscador reprocessa o site. O que não é normal é uma queda que não se recupera — nesse caso, quase sempre há redirecionamento faltando, cadeia de redirecionamento ou bloqueio de rastreamento indevido.

Conteúdo duplicado e canibalização

Migrações grandes costumam revelar que o site antigo tinha várias páginas competindo pelo mesmo assunto — artigos parecidos publicados em anos diferentes, uma página de serviço e um post de blog sobre o mesmo tema, versões que nunca foram consolidadas. Isso divide a autoridade e confunde o buscador sobre qual página mostrar.

A migração é o momento de resolver: consolidar os conteúdos redundantes em uma página forte, redirecionar as demais para ela e revisar os links internos para apontar todos para a versão canônica. O resultado costuma ser um ganho de posição para o tema, não uma perda.

O papel dos links internos

Os links internos distribuem autoridade pelo site e ajudam o buscador a entender a importância relativa das páginas. Numa migração, é comum que a nova estrutura de navegação mude esses links sem que ninguém perceba: uma página que era linkada de todo o rodapé passa a ser acessível só por um menu de terceiro nível.

Antes de publicar, verifique se as páginas mais importantes continuam recebendo links internos de peso — da home, das páginas de seção, de conteúdo relacionado. Uma página órfã, sem links internos, tende a perder posição mesmo com o redirecionamento correto.

Comunicação com quem depende do site

Uma migração afeta mais gente do que o time técnico. A equipe de conteúdo precisa saber que o fluxo de publicação vai mudar. O marketing precisa revisar as URLs em campanhas ativas, e-mails automáticos e materiais impressos com QR code. Parceiros que linkam para o site podem precisar ser avisados. Ferramentas integradas — automação de marketing, CRM, painéis — podem ter URLs fixas que quebram.

Um levantamento dessas dependências antes da virada evita que, no dia seguinte, uma campanha em andamento aponte para o lugar errado.

Cronograma realista

Uma migração de portal grande não é um projeto de duas semanas. As fases de inventário, arquitetura e mapa de redirecionamentos costumam consumir tanto tempo quanto o desenvolvimento da nova plataforma. Um cronograma típico reserva:

  • Semanas iniciais para inventário, auditoria e definição de arquitetura.
  • O grosso do tempo para desenvolvimento, migração de dados e construção do mapa de redirecionamentos em paralelo.
  • Uma fase de homologação com testes de amostra de URLs, performance e SEO técnico.
  • A virada em janela de baixo tráfego.
  • De quatro a oito semanas de monitoramento intensivo pós-publicação.

Comprimir demais qualquer uma dessas fases é onde os problemas nascem.

Erros que mais causam queda de tráfego

  • Redirecionar todas as URLs antigas para a home em vez do conteúdo equivalente.
  • Esquecer de remover o bloqueio de rastreamento que existia no ambiente de teste.
  • Cadeias longas de redirecionamento.
  • Mudar o padrão de URLs sem necessidade.
  • Não migrar as datas originais de publicação.
  • Publicar sem ter testado o mapa de redirecionamentos.
  • Deixar páginas importantes sem links internos na nova estrutura.
  • Fazer a virada numa sexta-feira ou perto de uma data crítica para o negócio.

Rollback: o plano B

Toda migração precisa de um plano para o caso de algo dar muito errado nas primeiras horas. Isso significa manter o site antigo intacto e acessível internamente durante alguns dias, ter um procedimento documentado para reverter o DNS e os redirecionamentos, e definir de antemão quais indicadores dispariam a decisão de voltar atrás — uma queda abrupta de tráfego, erros em massa, funcionalidades críticas quebradas.

Na prática, um rollback completo raramente é necessário se a homologação foi bem feita. Mas ter o plano reduz a pressão da equipe no dia da virada e evita decisões ruins tomadas no susto.

O que fazer com o domínio de teste

Durante o desenvolvimento, a nova plataforma vive em um endereço de homologação. Dois cuidados: esse ambiente precisa estar bloqueado para rastreamento e para acesso público, senão o Google pode indexá-lo e gerar conteúdo duplicado; e, no dia da virada, o bloqueio de rastreamento precisa ser removido do ambiente que vira produção — esquecer isso é um dos erros mais comuns e mais difíceis de perceber, porque o site parece funcionar normalmente enquanto some da busca.

Como a Jumps conduz migrações

A Jumps já conduziu a migração e a unificação de portais de grande porte, incluindo casos com vários sites e blogs consolidados em uma única plataforma. O processo segue exatamente as etapas acima, com o mapa de redirecionamentos tratado como entregável crítico e o monitoramento pós-virada acompanhado de perto.

Se você tem um portal para migrar e não quer arriscar o tráfego construído ao longo de anos, fale com a Jumps. Veja também sites e portais.