Analise as mudanças de links em migrações de site

Construa o mapa de redirecionamento antes do lançamento

O mapa de redirecionamento é a parte de uma migração que as pessoas subestimam. Os destinos são o mais importante. Antes de analisar os dados de links de site após uma migração, as URLs antigas precisam de um destino claro, pois esses são os endereços para os quais seus links já apontam.

Um-para-um é melhor que despejar na página inicial

Enviar centenas de URLs antigas não relacionadas para a página inicial diz muito pouco aos mecanismos de busca e visitantes. A relevância é o teste. Mapeie cada URL antiga de alto valor para sua página nova mais próxima e envie o restante para uma seção que ainda corresponda ao seu tópico.

Exporte as URLs antigas com seus códigos de status primeiro. Mantenha esse arquivo seguro. Esse arquivo é o checklist e mostra quais páginas ganharam links.

Quando uma página não tem uma correspondência próxima, indique isso no mapa e envie para a seção mais próxima, com uma nota. Células em branco escondem escolhas. Uma célula em branco na tabela é uma decisão que ninguém tomou.

Aplaste as cadeias antes do lançamento

Um redirecionamento que passa por duas regras anteriores antes de chegar à página nova adiciona atraso e risco. Cadeias são fáceis de criar quando uma segunda migração é aplicada sobre a primeira, então revise o mapa antes de cada troca em vez de assumir que ainda está limpo. Cada salto extra tem um custo. Solicite cada URL antiga uma vez após a troca e confirme que ela responde com um único salto.

Corrija cedo. Corrija cadeias no próprio mapa, não uma por uma após o lançamento, para que a lista permaneça curta.

Mantenha os caminhos que ainda funcionam

Alterar a estrutura de URL em um redesign é a perda mais evitável. Cada alteração em um caminho é também uma alteração em cada link que aponta para ele, e esses links estão fora do seu controle. Mantenha o que funciona. Se um caminho ainda funciona, mantenha-o e altere apenas o que a mudança forçar você a alterar.

Menos redirecionamentos, menos erros. Cada caminho que você mantém é um link que nunca precisou de redirecionamento.

Um caminho mantido significa que as linhas antigas de anchor continuam apontando para algum lugar útil, o que é uma coisa a menos para reconstruir na planilha. Menos reconstrução depois.

O que esperar depois

Eles fazem o trabalho pesado, e um 301 de URL antiga para nova permite que os links antigos continuem funcionando. Manter um redirecionamento por URL antiga, sem cadeia no meio, é a maneira mais simples de manter o valor de cada link intacto. Redirecionamentos. Cadeias de três ou quatro saltos desaceleram os crawlers e devem ser aplastadas.

O anchor text não muda quando uma URL se move, porque o texto vive na página que linka. O que muda é a contagem de destinos: sua tabela de páginas principais mostrará o host antigo desaparecendo e o novo subindo ao longo de algumas atualizações mensais. Os destinos mudam lentamente.

Uma surpresa comum é excluir a plataforma antiga muito cedo. Não faça isso. Squarespace, Wix e hosts similares frequentemente mantêm as regras de redirecionamento, então cancelar o plano pode removê-las, e os links então apontam para um beco sem saída até que você reconstrua as regras em outro lugar.

Hreflang e canonicals também merecem uma olhada. Incompatibilidades são comuns. Após uma migração de CRA para Next.js, por exemplo, sites frequentemente terminam com tags canonical que discordam de seus conjuntos hreflang, e links divididos entre duas versões de uma página.

Se os números discordarem após a migração, verifique a tabela de solução de problemas antes de assumir que links foram perdidos. Uma atualização mensal sozinha explica muitas lacunas. Lacunas são frequentemente questões de tempo.

Espere a primeira comparação limpa cerca de duas atualizações mensais após o lançamento e anote a data de cada atualização em sua planilha para que um mês plano não seja confundido com um preso. Dê tempo. Ahrefs ou Semrush podem preencher a lacuna com crawlers mais recentes se você precisar de uma leitura intermediária.

Observe o que se move sem aviso de lançamento

O dia do lançamento tem um checklist, mas vários problemas chegam depois e silenciosamente. Eles aparecem nas linhas e no índice, muito depois que a equipe já passou para outro trabalho. Eles são fáceis de perder.

Noindex que viaja com uma build de staging

Uma cópia de staging que foi mantida fora da busca pode carregar suas configurações para o site ao vivo. Verifique as meta tags robots e qualquer header noindex no primeiro crawl, e amostre páginas de cada seção em vez de apenas a página inicial. Amostre todas as seções.

Templates quebram primeiro. Se uma seção inteira cair do índice após o lançamento, olhe para seu template antes de olhar para seu conteúdo.

Capturas de tela também ajudam. Mantenha uma cópia das configurações robots da build de staging também. Quando algo cai do índice, comparar os dois conjuntos de configurações leva minutos em vez de uma tarde.

Links fragmentados que são indexados

Links de salto, como um anchor de índice, podem aparecer como URLs separadas nos resultados de busca. Mecanismos de busca geralmente agrupam isso na página principal, mas quando não agrupam, o mesmo conteúdo pode aparecer sob vários endereços. Eles dividem sinais da página principal e podem parecer páginas duplicadas em um relatório de cobertura. URLs com hash se multiplicam silenciosamente.

Uma versão, um endereço. Uma tag canonical que aponta para um endereço enquanto o sitemap lista outro envia sinais mistos, e o relatório mostrará a incompatibilidade. Defina uma versão canonical para cada página e confirme que o sitemap lista a mesma versão.

Verifique o relatório de cobertura após o lançamento para URLs com hash nelas, porque essas são as que se multiplicam silenciosamente. Hashes são o culpado.

Um subdomínio que se torna o domínio principal

Mover um site de um subdomínio de staging para o domínio principal traz duplicatas por conta própria, porque ambas as versões podem permanecer acessíveis por um tempo. Decida qual host é canonical antes do lançamento. Escolha o host cedo.

Um host, em todos os lugares. Quando um host muda em um lugar e não em outro, a versão mais antiga pode continuar coletando links por meses sem ninguém notar. Então mantenha o sitemap, as tags canonical e quaisquer conjuntos hreflang apontando para esse único host.

Links do-follow que parecem desaparecer

Após um redesign, as linhas do-follow em uma ferramenta podem cair abruptamente, e a primeira suposição é que os links foram embora. Compare as páginas principais antigas com as novas antes de aceitar essa suposição, então verifique se cada endereço antigo agora redireciona corretamente. Verifique antes de entrar em pânico.

Corrija esse primeiro. Um link que ainda existe na página linkadora mas aponta para um endereço morto é o caso a corrigir primeiro.

Defina a data cedo. Dê à equipe uma data fixa para a comparação, para que ninguém execute a extração todos os dias e leia ruído como notícia.

Trabalhando com um desenvolvedor durante a migração

A maior parte do trabalho de redirecionamento recai sobre um desenvolvedor, e o monitoramento recai sobre quem lê a planilha. Escrever a divisão como uma tabela curta, com um nome em cada célula, é frequentemente suficiente para impedir que duas pessoas assumam a mesma tarefa. Divida esses papéis no papel antes do lançamento, para que ninguém assuma que o outro está monitorando. Papéis precisam de nomes.

Dê ao desenvolvedor um mapa, não uma lista de tarefas

Uma lista de tarefas diz a um desenvolvedor o que fazer, enquanto um mapa mostra para onde cada endereço antigo vai. Envie a tabela um-para-um com os códigos de status e o motivo de cada linha, para que casos extremos recebam uma decisão em vez de um palpite. Decisões vencem palpites.

Planos de teste vêm primeiro. Peça um plano de teste curto que comece com os endereços antigos do arquivo de páginas principais.

Concordem quem lê o arquivo mensal

A primeira comparação limpa vem cerca de duas atualizações após o lançamento, e o arquivo precisará de um leitor. A primeira leitura após o lançamento é geralmente ruidosa, e um leitor que sabe disso evitará reagir a um mês incomum único. Nomeie essa pessoa, o dia em que ela abre e a planilha onde o resultado vai. Alguém precisa ser responsável.

Datas resolvem a questão. Escrever a data da atualização ao lado de cada arquivo transforma uma preocupação sobre um índice preso em um fato simples sobre o calendário. Um mês plano é fácil de ler mal como um preso a menos que alguém anote as datas de atualização.

Peça que essa pessoa escreva uma linha por atualização, mesmo quando nada mudou, para que o arquivo mantenha um registro contínuo. Uma linha cada vez.

Planeje o rollback antes do lançamento

Se o novo host quebrar um caminho crítico, a equipe precisa de uma maneira de voltar que tenha sido testada antecipadamente. Escreva os passos, incluindo quem pode inverter a chave e como os redirecionamentos se comportam enquanto é desfeito. Ensaiem antes do lançamento.

Escreva o rollback. Um rollback que existe apenas na cabeça de uma pessoa não é um plano.