Checklist de migração de site: de T-4 semanas ao dia 45
Mudança de domínio, nova plataforma, mudança de hospedagem ou um novo esquema de URL: os links que apontam para você não se importam com isso. Esta lista indica o que capturar antes do lançamento e o que reconfirmar depois.
Equipe de pesquisa do ArchiLinks ·
Nossa posição
A maioria das perdas de migração vem de redirecionamentos ausentes, não do tipo de redirecionamento
As equipes debatem por horas sobre 301 versus 302 e depois lançam com 3.000 URLs de links externos retornando 404. Encontre todos os backlinks para um site antes de decidir qualquer outra coisa, porque a lista indica onde está o risco.
- Colete as páginas vinculadas 4 semanas antes, não na véspera.
- Cada URL com um link externo precisa de um redirecionamento 301 de um único salto para uma página relevante.
- Mantenha os redirecionamentos ativos por pelo menos um ano, porque links antigos muitas vezes sobrevivem às páginas a que antes apontavam.
O cronograma
T-4 semanas: inventário
Faça o crawl do site antigo, exporte o relatório de desempenho do Search Console e execute toppages mais refdomains para o host antigo. Armazene os três arquivos juntos com a data.
T-3 semanas: mapeamento
Construa o mapa de redirecionamento primeiro a partir das páginas vinculadas, depois pelo tráfego e por último pelo crawl. A receita do mapa de redirecionamento mostra o script de classificação.
T-2 semanas: teste na staging
Teste cada URL antigo na staging e verifique um único salto, status 301 e 200 no final. Falhe a build em caso de cadeia ou loop.
T-0: lançamento
Implante os redirecionamentos, o novo sitemap, as tags canonical atualizadas e os links internos em uma única release. Envie o novo sitemap no Search Console. Para uma mudança de domínio, use a ferramenta Change of Address.
T+1 semana: logs e cobertura
Verifique os logs do servidor para hits do Googlebot em URLs antigos, depois o relatório de Páginas para picos em 404 ou soft 404. Corrija o mapa; não espere.
T+30 a 45 dias: diferença de links
Após a atualização mensal, puxe refdomains para o novo host e compare com o arquivo antigo. Diferenças maiores que alguns poucos porcentos merecem uma análise.
O que muda com o tipo de mudança
| Mudança | Redirecionamentos | Verificações extras | Foco em dados de links |
|---|---|---|---|
| Novo domínio | 301 em todo o host, nível de caminho onde os caminhos mudam | Ferramenta Change of Address, domínio antigo mantido por pelo menos 12 meses | Domínios de referência migrando para o novo host ao longo do tempo |
| HTTP para HTTPS ou mudança de www | 301 no nível do host | Canonical, HSTS, conteúdo misto | Poucas diferenças; confirme que ambos os hosts resolvem para um |
| Replataforma, mesmo domínio | Mapa no nível do caminho | Paginação, parâmetros, barras finais | Páginas mais vinculadas que mudaram de caminho |
| Subdomínio para subpasta (ou vice-versa) | Mapa no nível do caminho, regras no nível do host | Cookies, robots.txt por host, analytics | Se os links apontam para o host antigo ou para o novo |
| Fusão de dois sites | Mapa muitos-para-um | Conteúdo duplicado, escolhas de canonical | Sobreposição de domínios de link via intersect |
A lista de verificação do dia do lançamento
- URLs antigas retornam 301 em um único salto, testado por um script em vez de manualmente.
- O novo host retorna 200 com um canonical auto-referenciado em cada template.
- robots.txt no novo host não carrega regras de staging. Um Disallow: / deixado para trás é o acidente clássico do dia do lançamento.
- O sitemap XML lista apenas URLs 200, indexáveis e canônicos.
- Links internos, navegação e dados estruturados apontam para URLs novos, não para redirecionados.
- Propriedades de Analytics e Search Console existem para o novo host antes da troca.
- Os arquivos JSON de linha de base são commitados, com a data em cada nome de arquivo.
Nosso grafo de links é reconstruído cerca de uma vez por mês. Um link criado na semana do seu lançamento pode não aparecer no pull do dia 30. Use o relatório Links do Search Console para a última milha e avalie a diferença a partir da segunda atualização. Os mesmos dados alimentam a revisão de equidade interna vs externa após o lançamento, e domínios regionais hreflang cobre o caso multi-país.
Um 301 que termina em 404 não mantém nada
Algumas equipes enviam todas as URLs antigas para o novo destino e deixam que as páginas de destino expirem mais tarde. O redirecionamento em si funciona. É por isso que o hábito é arriscado, já que cada salto parece limpo em um log enquanto a página no final responde com 404.
Digamos que você mova uma loja para um novo domínio e mantenha apenas os produtos que ainda são vendidos. As páginas de categoria que continham a maioria dos links externos agora não levam a nada útil. Conte as URLs vinculadas externamente antes de aposentá-las. Faça disso o primeiro passo. Uma página com domínios de link precisa de um alvo ativo no mesmo assunto, não de um indiferente.
Mantenha a regra curta: um salto, depois um 200 final. Qualquer outra coisa é um vazimento que você escolheu.
O que um 301 de um salto para uma página ativa protege
O valor de um link reside na URL a que ele aponta. Um redirecionamento carrega esse valor apenas se o endereço para o qual ele chega responder e ainda corresponder ao assunto. Um produto movido para o mesmo produto no novo catálogo passa nesse teste, enquanto um produto enviado para a página inicial geralmente não passa, mesmo quando era a página para a qual todos linkavam.
Reverifique o status final após cada alteração de template. Um redirecionamento que funcionava no lançamento pode terminar em 404 após uma release posterior, quando alguém remove uma categoria durante uma limpeza de menu.
Quando um 410 é a resposta honesta
Algumas URLs antigas não tinham links, visitas nem substituição real. Para essas, um 404 claro ou um 410 é mais honesto do que um redirecionamento para uma página que não responde à pergunta que a antiga fazia. Um redirecionamento para uma página não relacionada é frequentemente tratado como um soft 404, então não resgata nada.
Escreva a decisão para cada grupo de URLs, com o motivo ao lado. Uma pasta de tutoriais aposentados recebe uma resposta diferente de uma pasta de páginas com oitenta domínios de link, e você vai querer explicar essa diferença para um colega em seis meses.
Verificando o último salto, não apenas o primeiro
A maioria dos testes de redirecionamento para na primeira resposta, que é o lugar errado para parar. Siga a cadeia até o final, depois registre o número de saltos e o status final ao lado da URL antiga. Uma cadeia de dois saltos não está quebrada, mas adiciona atraso e mais um lugar para uma regra falhar.
Se um script estiver fora de alcance, uma planilha e algumas chamadas curl farão o trabalho. A página de scripts de API tem uma versão que você pode agendar.
Sitemaps e solicitações manuais após o lançamento
Mantenha o sitemap antigo acessível por algumas semanas após a mudança. Rastreadores que revisitam o host antigo ainda podem encontrar esses endereços em uma lista, o que acelera sua primeira passagem pelos redirecionamentos.
Solicitações manuais são uma ferramenta diferente. Use-as para as poucas páginas que mais importam, não para centenas de URLs enviadas uma por uma. Uma página solicitada sem links internos e corpo fino tende a cair novamente, então a solicitação é tão boa quanto a página por trás dela.
Esperar é um plano válido. Dê tempo ao crawl, depois avalie com base em dados.
Manter o sitemap antigo listado por um tempo
Deixe o sitemap antigo no Search Console até que as URLs antigas deixem de aparecer nas estatísticas de crawl. Então remova-o propositalmente e anote a data no log de migração.
Não remova no dia do lançamento apenas para deixar a propriedade com aparência organizada. A remoção precoce esconde a única lista que nomeia todas as URLs antigas que você ainda precisa rastrear.
Solicitando indexação para as páginas que carregam links
Escolha as vinte novas URLs com mais links externos, usando o mesmo join que você construiu para o mapa de redirecionamento, e solicite essas manualmente. O esforço então segue o risco em vez do tamanho do site.
Se uma página solicitada ainda estiver faltando após algumas semanas, analise a página antes de pedir novamente. Verifique seus links internos, seu canonical e seu conteúdo. Uma quinta solicitação não muda nada.
Quanto tempo antes que a mudança possa ser julgada
Avalie a mudança a partir do segundo pull de links, não do primeiro. Nosso índice é atualizado cerca de uma vez por mês, então um pull no dia três mostra principalmente a imagem do mês passado. Execute o segundo pull após a atualização e use-o para encontrar todos os backlinks para um site no novo host.
O relatório de Páginas e os dados de links respondem a perguntas diferentes. Leia-os lado a lado, não como vereditos concorrentes sobre a mesma mudança.
Cinco verificações antes do site de staging ir para o ar
Mantenha o staging fora do índice
Coloque uma senha ou uma lista de permissões na frente do staging. Uma regra robots.txt sozinha não impede que mecanismos de busca indexem URLs que já conhecem por links.
Verifique as configurações noindex e canonical
Abra o template e as configurações do CMS e procure por uma flag noindex ou um canonical que nomeie outra URL. No WordPress, a configuração de visibilidade de pesquisa é a que as pessoas esquecem após copiar um site do staging.
Substitua o arquivo robots de staging
Busque o robots.txt ao vivo assim que a troca for feita e compare com o arquivo que você pretendia implantar. Regras de staging que chegam à produção podem impedir rastreadores de todo o host.
Execute o teste de salto no host ao vivo
O staging prova que o mapa funciona em uma cópia. Execute o teste de um salto novamente no domínio real após as alterações de DNS, porque um cache de CDN ou uma regra de host pode se comportar de maneira diferente lá.
Mantenha o host antigo respondendo
Deixe o domínio antigo servindo redirecionamentos pelo tempo que suas URLs ainda receberem links ou visitas. Coloque a data de renovação em um calendário antes que alguém esqueça que o domínio existe.
Acompanhando o site após o lançamento, não apenas antes
Uma auditoria pré-lançamento registra o que era verdade no dia em que foi executada. A maioria dos danos do lançamento aparece mais tarde, após uma atualização de plugin, uma mudança de regra de CDN ou um template que toca em uma configuração que ninguém revisou.
Trate o acompanhamento pós-lançamento como um conjunto de pequenas diferenças contra uma linha de base salva. Nenhum dashboard necessário. Um cronograma e uma pasta de arquivos com data bastam.
O que um acompanhamento semanal deve comparar
Escolha as verificações que mais doeriam se mudassem e execute-as no mesmo dia toda semana.
- Código de status e URL final para as 50 URLs antigas mais vinculadas
- robots.txt e a meta tag robots nos templates principais
- Contagem de URLs 200 ativas contra a contagem no novo sitemap
- Tags canonical na página inicial, uma categoria e um artigo
Por que uma auditoria única perde a deriva lenta
As configurações derivam após o lançamento. Uma flag de teste deixada ligada, um plugin que reescreve permalinks ou um redirecionamento adicionado para corrigir uma página podem desfazer parte do plano. Uma auditoria feita no dia do lançamento não consegue ver nenhuma delas.
Uma diferença agendada pode. Mantenha os arquivos de linha de base no controle de versão e compare a saída de cada semana contra eles, para que uma mudança inesperada seja visível no dia em que acontecer.
Subdomínios, remoções e mudanças de domínio de site inteiro
Algumas equipes movem uma seção para um subdomínio e indexam apenas suas páginas populares. Isso pode funcionar. O custo é que links direcionados às páginas menos populares agora chegam a um host com menos histórico, então conte-os antes de cortar qualquer coisa.
Solicitações de remoção são mais estreitas do que parecem. O Search Console aplica uma remoção à propriedade onde você a registra, então uma solicitação feita em um subdomínio não age no domínio principal. Verifique a propriedade primeiro. Depois submeta e mantenha ambas verificadas.
Indexando apenas as páginas populares em um subdomínio
Comece com os links por URL nessa seção. Páginas que carregam links externos mas pouco tráfego são as primeiras que uma regra apenas-páginas-populares ocultaria. Mantenha-as rastreáveis ou redirecione cada uma para sua página popular mais próxima e escreva o motivo ao lado da regra.
Onde o site principal linka para o subdomínio decide o quão facilmente suas páginas são encontradas. Liste esses links antes de escolher quais páginas ficam ocultas, porque uma página que o site principal nunca linka é difícil de alcançar de qualquer forma.
Uma mudança de domínio de site inteiro, página por página
Uma regra no nível do host lida com a raiz, mas uma mudança de domínio também precisa de um mapa no nível do caminho. Quando a primeira parte da URL muda e o slug permanece igual, uma troca de host cobre a maioria das páginas, e as exceções precisam de suas próprias linhas.
Construa a lista a partir das páginas vinculadas primeiro, depois corresponda cada caminho antigo ao seu novo. A receita do mapa de redirecionamento mostra como classificar essa lista por links.
