Migre sua base de conhecimento sem perder tráfego orgânico

Em muitos produtos, a central de ajuda é a propriedade com mais tráfego depois da própria home. Anos de artigos do tipo “como conecto o X” e “por que o Y não está funcionando” rankeiam em silêncio para milhares de buscas de cauda longa, evitam tickets 24 horas por dia e trazem compradores que começaram procurando a solução de um problema. Uma migração de base de conhecimento que ignora isso queima um valor composto que levou anos para ser construído — e o prejuízo só aparece semanas depois, exatamente quando fica mais difícil reverter.

A boa notícia: os buscadores lidam muito bem com mudanças de endereço quando você segue uma lista curta de itens inegociáveis. A lista é esta.

Primeiro, meça o que você está prestes a mover

Não dá para proteger um tráfego que você nunca mediu. Antes que um único artigo saia do lugar:

• Puxe os últimos 12 meses do Google Search Console: páginas, consultas, cliques e impressões. Exporte tudo — esse arquivo é a sua linha de base e a sua apólice de seguro.
• Rastreie a central de ajuda antiga para ter a lista completa de URLs, incluindo páginas de categoria, redirecionamentos que já existem e artigos que ninguém lembra de ter publicado.
• Marque as páginas que dão dinheiro: os 20 artigos com mais cliques costumam concentrar a maior parte do tráfego orgânico. São eles que você confere na mão em cada etapa seguinte.
• Anote quais URLs já redirecionam — cadeias de redirecionamento são uma das formas clássicas de vazar autoridade de links durante uma mudança.

Defina a história das URLs antes de mover qualquer coisa

Cada artigo precisa de uma resposta deliberada para a pergunta “qual é o seu novo endereço?” — registrada em uma tabela de mapeamento com URL antiga, URL nova e status.

• Mantenha os slugs idênticos sempre que possível. Se o artigo antigo morava em /hc/articles/12345-connect-your-inbox e o sistema novo aceita /help/connect-your-inbox, leve a parte legível por humanos sem mudar uma letra.
• Se a central de ajuda muda de domínio ou de subdomínio (de support.example.com para example.com/help, digamos), trate a operação como mudança de site: o mapa de redirecionamentos pesa ainda mais, e vale verificar as duas propriedades no Search Console.
• O mapeamento um-para-um é a regra. Cada URL antiga aponta para o seu equivalente direto. Redirecionar tudo para a home da central de ajuda nova é a maneira mais comum de um time destruir o próprio rankeamento — os buscadores tratam redirecionamento em massa para a home como soft 404.
• Os artigos que você vai aposentar de propósito ganham um redirecionamento para o artigo sobrevivente mais próximo, ou um 410 honesto quando nada cobre aquele tema. Decida artigo a artigo, nunca por política geral.

Redirecionamentos: os itens inegociáveis

• 301, permanente. Não 302, não redirecionamento por JavaScript, não meta refresh. É o 301 que manda o buscador transferir os sinais de rankeamento.
• No máximo um salto. Da URL antiga direto para a URL final. Se a central antiga já tinha redirecionamentos, achate essas cadeias dentro do seu mapa.
• Mantenha o domínio ou o caminho antigo servindo redirecionamentos por pelo menos um ano. Os buscadores voltam devagar; a autoridade dos links se transfere ao longo de meses, não de dias. Cancelar o subdomínio antigo na semana seguinte à virada corta essa transferência no meio do caminho.
• Teste o mapa de forma programática. Um script que pede cada URL antiga e verifica se ela devolve 301 para o destino esperado leva uma hora para escrever e pega os erros de digitação que custariam posições em silêncio.

Slugs, títulos e canonical

• Todo artigo migrado carrega uma tag canonical apontando para si mesmo na URL nova.
• Em qualquer período de operação paralela com as duas centrais no ar, os artigos antigos não podem competir: ou os redirecionamentos entram no ar já na virada, ou você aponta o canonical de cada artigo antigo para o novo. Duas cópias vivas do mesmo artigo dividem os sinais de rankeamento entre si.
• Mantenha títulos e H1s estáveis durante a mudança. Migração é a hora errada de reescrever: mexa em uma variável de cada vez e deixe a troca de URL assentar antes de editar o conteúdo.
• Gere e envie o sitemap XML das URLs novas já no primeiro dia, e deixe o sitemap antigo disponível por um tempo curto para que os rastreadores descubram os redirecionamentos mais rápido.

Higienize o HTML na entrada

Centrais de ajuda antigas acumulam dívida de marcação, e a importação copia tudo com fidelidade:

• Remova estilos inline e classes específicas do fornecedor — eles brigam com o tema novo e vez ou outra quebram a renderização no celular, que por si só é fator de rankeamento.
• Reescreva as referências de imagem para os arquivos que você re-hospedou; links diretos para o CDN do fornecedor antigo morrem no dia em que a conta é encerrada. Já que você está ali, aproveite e escreva o texto alternativo — a maioria das imagens de uma base de conhecimento legada não tem nenhum.
• Corrija as hierarquias de títulos: os editores antigos adoravam pular de H1 para H4. Uma estrutura limpa ajuda quem lê e ajuda seus melhores artigos a seguirem elegíveis aos trechos em destaque da SERP.
• Elimine os widgets incorporados mortos — lançadores de chat antigos, formulários de feedback e scripts que apontam para o sistema que você está deixando.

Os links internos fazem parte da migração

Os links de artigo para artigo dentro da base de conhecimento devem ser reescritos para as URLs novas já no momento da importação — apoiar a navegação interna nos redirecionamentos até funciona, mas desperdiça orçamento de rastreamento e deixa tudo mais lento. E os links fora da base pesam tanto quanto: ajuda dentro do produto, e-mails de onboarding, macros e respostas salvas apontam todos para algum lugar. Faça uma varredura atrás do domínio antigo da central de ajuda em cada superfície que você controla e atualize na origem.

Ensaie a mudança em uma cópia de staging

Tudo o que está acima pode ser testado antes que um único visitante seja afetado. Importe os artigos para a central nova sem publicar (ou atrás de um domínio de staging), rode o seu rastreador contra ela e compare: a contagem de artigos bate com a origem, os títulos sobreviveram, as imagens carregam do host novo e os links internos apontam para as URLs novas, não para as antigas. Depois faça um ensaio do mapa de redirecionamentos contra o host de staging, com o mesmo script de teste que você vai usar no dia do lançamento. Os times que ensaiam encontram os erros de digitação da tabela de mapeamento numa terça à tarde; os que não ensaiam encontram no log de 404, já com tráfego de busca em cima. O ensaio costuma levar meia jornada e transforma o dia do lançamento de um evento em um checklist.

Depois do lançamento: acompanhe os painéis certos

• Log de 404, diariamente, nas duas primeiras semanas. Todo 404 que chega de uma busca é um bug da tabela de mapeamento que dá para consertar no mesmo dia.
• Cobertura no Search Console: acompanhe as URLs novas entrando na indexação e as antigas passando para “redirecionada”. Devagar é normal; erro não é.
• Posições das páginas que dão dinheiro, contra a exportação da sua linha de base. Uma oscilação moderada de duas a seis semanas é o padrão de uma mudança bem executada; uma queda vertical em uma página específica quer dizer que o redirecionamento ou o canonical dela está errado — comece por aí.
• Conte com a estabilização completa em um a três meses. Julgue a migração nesse momento, contra a linha de base que você guardou, e não na primeira semana barulhenta.

Onde o MoveDesk entra

A importação de base de conhecimento do MoveDesk foi construída com essa lista em mente: os artigos chegam com a estrutura e os sinalizadores de visibilidade preservados, as imagens re-hospedadas e um HTML limpo, que se encaixa no tema novo. E como a sua base de conhecimento também é a fonte que alimenta o agente de IA do MoveDesk, a mesma faxina rende duas vezes — artigos organizados rankeiam melhor e atendem o cliente com mais precisão. A migração assistida cuida da importação; o mapa de redirecionamentos fica na sua mão, porque ele mora no seu domínio.

Antes de migrar um único artigo, exporte a linha de base do seu Search Console. Todo o resto desta lista dá para consertar depois da virada — uma linha de base que não existe, não.