Migrar um site parece simples quando o plano é descrito como trocar um domínio ou publicar uma nova versão. Na prática, a mudança pode alterar centenas de URLs, registros DNS, certificados, caixas de email, campanhas, callbacks de pagamento, aplicativos móveis e links guardados por clientes. A página inicial pode responder com 200 enquanto uma fatura não é entregue, uma API continua apontando para o endereço antigo ou um certificado não cobre o novo host. Por isso, a migração deve ser tratada como uma mudança operacional com evidências, donos e critérios de interrupção, e não como uma tarefa isolada de conteúdo.
Defina o escopo e o resultado esperado
Comece listando domínio antigo, domínio novo, variantes com e sem www, HTTP e HTTPS, subdomínios, caminhos importantes, email, API e links publicados em campanhas ou documentos. Registre protocolo, host, porta, caminho, parâmetros e destino esperado. Diga também o que não será movido, porque uma migração parcial exige regras diferentes de uma troca completa. O resultado esperado deve ser observável: cada URL crítica chega ao conteúdo correto, o certificado corresponde ao host, o email continua recebendo e enviando, e os fluxos de negócio terminam sem duplicação. Um simples teste de página inicial não pode ser o critério de aprovação.
A documentação do Google recomenda preparar o novo site, criar um mapa entre URLs antigas e novas, ativar redirecionamentos e monitorar os dois lados. Faça esse mapa antes do lançamento. Inclua páginas com mais tráfego, páginas que geram receita, documentos, imagens, scripts, feeds e URLs que aparecem em links externos. Para cada linha, informe destino, código esperado, conteúdo equivalente, proprietário, teste e exceção. Evite mandar muitas URLs para a home sem relação, pois isso confunde usuários e pode parecer um soft 404. Quando uma página foi consolidada de verdade, documente essa decisão em vez de usar uma regra genérica.
Verifique delegação e registros DNS
O DNS deve ser verificado em camadas. Primeiro confirme a delegação e os servidores NS retornados pelo pai. Depois consulte cada servidor autoritativo para SOA, NS, A, AAAA, CNAME, MX, TXT e CAA. Compare serial, valores e respostas entre servidores. Um site pode abrir para parte do público quando apenas um servidor foi atualizado ou quando o MX foi esquecido na cópia da zona. Em seguida, observe os mesmos nomes por diferentes resolvedores públicos. NXDOMAIN, SERVFAIL, resposta vazia e timeout têm causas diferentes e não devem ser reduzidos a um único estado de falha.
TTL ajuda a estimar por quanto tempo respostas antigas podem permanecer em cache, mas não promete uma troca simultânea para todos os usuários. Registre TTL, horário da alteração e a primeira e a última observação. Dê atenção especial a MX, TXT de verificação, SPF, DKIM, DMARC e CAA, além dos endereços usados por integrações. A zona nova precisa preservar o que ainda é necessário e remover o que não tem dono, sempre depois de confirmar a finalidade. Uma fotografia antes e outra depois permitem distinguir propagação, erro de configuração e mudança posterior.
Teste redirecionamento até o destino final
Sempre que possível, faça o endereço antigo chegar diretamente ao novo destino, sem passar por várias regras intermediárias. Teste HTTP para HTTPS, www para não www, maiúsculas, barra final, caracteres codificados, parâmetros de campanha, arquivos antigos e caminhos removidos. Registre código, cabeçalho Location, quantidade de saltos, host final e resposta. Uma cadeia longa aumenta latência e torna o diagnóstico difícil. Não aplique a mesma expectativa a login, pagamento e callbacks que exigem autenticação; use contas de teste e uma aprovação segura para esses caminhos.
Escolha o destino pelo significado da página. Um produto antigo deve ir para o produto equivalente, um artigo para a versão correspondente e uma página retirada pode precisar de 404 verdadeiro ou de uma página substituta relevante. Redirecionar tudo para a home preserva pouco da experiência e pode esconder conteúdo perdido. O Verificador de redirecionamento do DomScan ajuda a conferir cadeias e respostas finais em lotes de amostra. Guarde também respostas desconhecidas, bloqueios e timeouts, pois uma URL que não pôde ser lida não é um sucesso.
Combine HTTPS, sitemap e sinais de pesquisa
Confira o certificado apresentado por cada host crítico, incluindo raiz, www, login, API, arquivos e status. Valide nome, SAN, período, cadeia e conexão em IPv4 e IPv6 quando ambos existirem. Depois procure referências antigas em canonical, hreflang, sitemap, robots, links internos, scripts e imagens. O endereço abrir no navegador não prova que todos os recursos apontam para a versão nova. Atualize propriedades no Search Console, envie o sitemap novo e mantenha o mapa antigo para investigação. Flutuação temporária pode ocorrer durante a recrawling, mas 404 persistente, canonical antigo e cadeia de TLS incorreta exigem ação.
Em sites multilíngues, trate cada idioma como um conjunto relacionado, não como um detalhe visual. A página em português pode apontar para o novo domínio enquanto a versão espanhola mantém canonical ou hreflang antigos. Verifique também PDFs, imagens, vídeos e feeds que costumam ficar fora do CMS. Atualize links internos e campanhas assim que a mudança começar, mas preserve redirecionamentos antigos pelo tempo planejado. A lista de links externos importantes ajuda a priorizar contatos e evita depender indefinidamente de um redirecionamento lento.
Não esqueça email e integrações
A mudança web não substitui a migração de email. Confira MX, prioridade, SPF, seletores DKIM e política DMARC no nome novo e faça testes de recebimento, envio, resposta, encaminhamento e bounce a partir de endereços externos. Teste senha esquecida, nota fiscal, formulário e atendimento, porque esses fluxos podem usar origens diferentes. Não remova TXT antigo até saber qual aplicativo o utiliza. Um site disponível não prova que mensagens chegam, assim como DNS correto não prova que uma aplicação apresenta o certificado esperado.
Integrações com CRM, pagamento, webhooks, aplicativos móveis e parceiros não aparecem na navegação comum. Para cada callback, confira host, autenticação, reenvio, idempotência e código de resposta com uma transação controlada. Faça uma lista de consumidores que ainda podem chamar o endereço antigo e defina quando serão atualizados. Se um nome antigo precisa permanecer por compatibilidade, registre proprietário, motivo, regra e data de revisão. O rollback deve recuperar configurações e credenciais relacionadas, não somente o registro A.
Observe o lançamento e prepare rollback
No lançamento, compare tráfego antigo e novo, códigos 3xx, 4xx e 5xx, erros DNS, falhas TLS, conversões, contatos e bounces. Faça observações em horários de pico e fora dele, de redes externas e em dispositivos relevantes. Registre URL de entrada, destino, horário, posição de observação, evidência e responsável. Se o processo de verificação não executar ou todos os resultados ficarem desconhecidos, isso é uma falha da verificação, não uma ausência de problemas. Uma segunda medição no dia seguinte e outra após o primeiro ciclo de tráfego oferecem uma base mais confiável.
Defina critérios de rollback antes de publicar: aumento de 404 em páginas críticas, falha de pagamento, certificados incompatíveis, perda de recebimento, callbacks rejeitados ou divergência entre servidores autoritativos. Documente a ordem para restaurar DNS, redirecionamentos, certificados, email, aplicações e sitemap. Nomeie quem pode interromper a mudança e quem comunica clientes e parceiros. Guardar a baseline e o estado novo evita discussões baseadas em memória e permite provar qual alteração coincidiu com o incidente.
Para muitos sites, padronize a entrada e a saída. Cada linha deve conter URL, expectativa, resultado, horário, evidência, dono e estado de incerteza. O DomScan oferece verificações separadas de redirecionamento, DNS, histórico DNS, SSL e perfil do domínio para que a equipe veja qual sinal está causando o problema. Automação reduz omissões e organiza revisão, mas não decide se duas páginas são equivalentes, se uma integração pode ser encerrada ou se uma queda de conversão é aceitável. Essas decisões precisam de contexto do negócio.
Faça uma reunião de aceite com marketing, suporte, engenharia, financeiro e quem cuida de email. Para cada caminho, peça uma evidência pequena e concreta: uma URL antiga e sua resposta final, uma consulta autoritativa, um certificado observado, uma mensagem de teste, uma transação de callback e uma linha do relatório de indexação. Se as equipes trouxerem apenas afirmações como ‘parece tudo certo’, transforme a afirmação em um teste repetível. Quando um resultado depender de uma janela de cache ou de uma aprovação externa, registre a condição e a próxima data de revisão em vez de marcá-lo como concluído.
Em sites de comércio, compare também carrinho, login, checkout, confirmação de pedido e atendimento após o redirecionamento. Em sites de conteúdo, compare páginas mais visitadas, imagens, feeds e dados estruturados. Para cada amostra, anote navegador ou cliente, rede, hora, URL inicial, destino, código e impacto. Um erro que só aparece em uma variante de host pode ficar escondido atrás de uma média geral. Depois de uma semana, revise URLs que ainda recebem tráfego antigo, tickets de clientes, conversões e respostas desconhecidas. O encerramento deve ser uma decisão com evidência, não o fim da janela de lançamento.
Faça uma verificação de continuidade no dia seguinte e outra após o primeiro pico de tráfego. Compare URLs que ainda recebem acessos antigos, páginas que geram receita, tickets, buscas internas, conversões e chamadas de API. Um resultado correto em horário tranquilo não representa necessariamente uma campanha ou um fechamento financeiro. Se o problema aparecer somente em uma região, endereço IPv6, cliente móvel ou parceiro, mantenha o caso aberto até identificar a condição. Registre a decisão de encerrar ou continuar observando, com pessoa responsável e data de revisão, para que a pressão do calendário não substitua evidência.
A migração está encerrada quando a delegação e os registros importantes correspondem ao plano, URLs críticas chegam ao destino final, HTTPS cobre os nomes esperados, email e integrações passam nos testes e cada item desconhecido tem dono e data. Mantenha os redirecionamentos pelo período aprovado, atualize links próprios e revise o relatório de pesquisa. Se uma autoridade DNS divergir, um MX desaparecer, um certificado não corresponder ou um caminho financeiro falhar, suspenda o fechamento. Uma migração bem executada é uma mudança observável e reversível, não apenas uma nova página que abriu uma vez.