Checklist de SEO para Migração de Site

Uma migração de site é uma mudança controlada na plataforma, domínio, protocolo, arquitetura da informação, estrutura de URL ou sistema de renderização de um site. Ela só está completa quando usuários, rastreadores e analytics conseguem acessar o conteúdo pretendido através de rotas estáveis e a equipe pode provar que a visibilidade valiosa sobreviveu.

Checklist: SEO para migração de site. Timebox: comece de 6 a 12 semanas antes do lançamento para um site médio; reserve os últimos 5 dias úteis para um congelamento de mudanças, o dia do lançamento para validação com equipe dedicada e pelo menos 4 semanas para monitoramento ativo. Responsável: um líder de migração responsável por todo o lançamento, apoiado por proprietários nomeados de engenharia, SEO, analytics, conteúdo e infraestrutura.

Por que este checklist existe e por que é executado aqui

Esta camada de controle de lançamento no Processo de SEO consome evidências de rastreamento e índice da auditoria técnica de base , decisões de manter/mesclar/remover do inventário e auditoria de conteúdo e a hierarquia de destino do mapa temático e arquitetura da informação . Esses resultados devem existir antes que redirecionamentos ou staging possam ser avaliados.

Execute-o depois que a estrutura de destino for aprovada, mas antes que as rotas de produção sejam congeladas. Se executado antes, a equipe mapeia redirecionamentos para destinos que ainda podem mudar. Se executado depois, roteamento, templates, analytics ou comunicações de lançamento podem já estar caros demais para serem corrigidos com segurança.

O mapa de redirecionamentos é o artefato de maior risco porque conecta rotas antigas às novas. Cada URL antiga valiosa deve ir individualmente para o destino mais próximo que preserve seu propósito. Nunca use a página inicial como um “pega-tudo”: isso frustra visitantes e disfarça destinos ausentes.

Entradas e saídas

As saídas são o contrato com as operações de lançamento. Uma planilha sem responsáveis, evidências ou condições de aceitação não é uma transferência válida.

O checklist

Cada item informa o quê, por quê, como, ferramenta e uma condição observável de conclusão. Substitua um limite apenas por uma regra mais rigorosa ou uma baseada em evidências documentadas.

Fase 1: inventário pré-migração

1. Construa o inventário unificado de URLs. O quê: combine cada URL antiga descobrível de rastreamentos, XML sitemaps, analytics, Search Console, exportações de backlinks, registros CMS, campanhas pagas e logs de servidor. Por quê: nenhuma fonte única contém toda URL valiosa ou solicitada; uma página ausente na navegação ainda pode ter links, tráfego ou importância contratual. Como: normalize protocolo, host, maiúsculas/minúsculas, barra final, parâmetros e caracteres codificados, retendo o valor bruto da fonte. Deduplique apenas após registrar onde cada URL foi encontrada. Ferramenta: rastreador, exportação CMS, analytics, Search Console, dados de backlinks e logs. Concluído quando: toda fonte tem data, toda linha tem uma URL normalizada e fonte de descoberta, duplicatas são resolvidas e os totais das fontes reconciliam com o inventário final.

2. Classifique a disposição de cada URL. O quê: rotule cada URL como manter, mover, mesclar, remover ou investigar. Por quê: os redirecionamentos não podem ser mapeados corretamente até que a decisão de conteúdo seja explícita. Como: combine tráfego, conversões, backlinks, estado do índice, qualidade do conteúdo, necessidade de negócio e intenção; registre a evidência e o responsável aprovador. Ferramenta: pasta de trabalho do inventário e auditoria de conteúdo. Concluído quando: 100% das URLs no escopo têm uma disposição, um responsável, um destino ou motivo de remoção, e nenhuma linha “investigar” não resolvida permanece no congelamento.

3. Capture a base de referência assinada. O quê: preserve sessões orgânicas pré-lançamento, cliques, impressões, conversões, receita, URLs indexadas, erros de rastreamento, códigos de resposta, uptime e desempenho para templates e diretórios prioritários. Por quê: sem um ponto de comparação datado, variação normal e dano de migração parecem iguais. Como: exporte pelo menos 28 dias comparáveis, anote campanhas e sazonalidade, e identifique URLs prioritárias que exigem revisão diária. Ferramenta: analytics, Search Console, rastreador, dados de rank e monitoramento. Concluído quando: a base é somente leitura, reproduzível, segmentada, com timestamp e aprovada pelos responsáveis de SEO e analytics.

Fase 2: mapeamento de redirecionamentos

4. Mapeie fontes individualmente sempre que possível. O quê: atribua cada URL antiga movida ou mesclada à URL nova mais próxima com a mesma intenção primária. Por quê: um destino preciso preserva a continuidade para o visitante e dá aos rastreadores um sinal de substituição coerente. Como: compare tópico, produto, geografia, idioma e tarefa; mapeie mesclagens para a página sobrevivente e documente remoções deliberadas. Nunca mapeie URLs não correspondentes para a página inicial. Ferramenta: pasta de trabalho do mapa de redirecionamentos, inventário e rastreamento do destino. Concluído quando: toda fonte em mudança tem exatamente um resultado aprovado, todo destino é relevante e está no escopo, e mapeamentos pega-tudo para a página inicial são zero.

5. Valide a mecânica dos redirecionamentos antes do lançamento. O quê: teste códigos de status, destinos, comportamento de consulta, variações de maiúsculas/minúsculas, protocolo, subdomínios, barras finais, arquivos e URLs de campanha. Por quê: uma planilha de aparência correta ainda pode produzir loops, cadeias, curingas que engolem páginas válidas ou destinos que retornam erros. Como: gere as regras de staging ou proxy, solicite cada fonte, siga os saltos e compare a URL final com o mapa aprovado. Ferramenta: teste HTTP automatizado, rastreador e revisão de configuração do servidor. Concluído quando: 100% das fontes mapeadas alcançam o destino 200 aprovado em um salto de redirecionamento permanente; loops, cadeias, redirecionamentos temporários e destinos com erro são zero.

6. Reconcile canônicas, links e sitemaps com os redirecionamentos. O quê: faça a URL canônica , links internos, referências hreflang, dados estruturados, feeds e XML sitemaps apontarem diretamente para as URLs finais. Por quê: redirecionar URLs antigas enquanto continua a publicá-las cria sinais conflitantes de migração e desperdiça solicitações de rastreadores. Como: rastreie cada fonte de referência e compare os alvos normalizados com o mapa de redirecionamentos. Ferramenta: rastreador, HTML renderizado, analisador de sitemap e diff de configuração. Concluído quando: as páginas finais auto-canonizam-se a menos que uma exceção aprovada diga o contrário, referências internas a URLs redirecionadas são zero e os novos sitemaps contêm apenas URLs 200 canônicas.

Fase 3: validação em staging

7. Teste o staging sem torná-lo publicamente indexável. O quê: rastreie o lançamento completo em staging enquanto impede que mecanismos de busca indexem o ambiente. Por quê: a equipe precisa de evidências em nível de rastreador sem permitir que um site duplicado entre nos resultados de busca. Como: use controle de acesso para rastreadores externos, depois execute um rastreamento interno autenticado com renderização JavaScript onde o site de produção depender dela. Trate um bloqueio de staging como configuração temporária de lançamento, não algo a copiar cegamente para produção. Ferramenta: rastreador autenticado, navegador e inspeção de cabeçalhos de resposta. Concluído quando: o inventário esperado de staging é rastreável pela equipe de teste, a indexação pública não autorizada está bloqueada e o checklist de lançamento em produção remove explicitamente os controles exclusivos do staging.

8. Verifique templates e jornadas prioritárias. O quê: teste páginas representativas de cada template, além de navegação, busca, formulários, cadastro, checkout, localização, paginação, filtros e páginas de erro. Por quê: uma aprovação na página inicial não revela um bug de canônica em páginas de produto ou um estado de consentimento quebrado que suprime analytics. Como: crie uma matriz de dispositivos e templates, teste sessões limpas e de retorno, e registre capturas de tela ou evidências de resposta para cada resultado. Ferramenta: navegador, verificador de acessibilidade, validador de dados estruturados, depurador de analytics e testes de transação. Concluído quando: todo template no escopo e toda jornada primária são aprovados nos navegadores e dispositivos acordados, com zero defeitos críticos abertos.

9. Compare o staging com os contratos aprovados. O quê: compare títulos, descrições, cabeçalhos, canônicas, diretivas robots, dados estruturados, links internos, códigos de resposta, conteúdo e tags de analytics com o site antigo e a especificação de destino. Por quê: migrações de plataforma frequentemente perdem metadados ou alteram a renderização mesmo quando a cópia visível parece intacta. Como: rastreie a produção antiga e o staging com configurações equivalentes, segmente diferenças por template e aprove apenas mudanças intencionais. Ferramenta: relatório de diff de rastreamento e inspeção de fonte. Concluído quando: toda diferença material é corrigida ou listada como uma alteração aprovada com responsável e motivo; alterações acidentais de noindex, canônica, conteúdo e rastreamento são zero.

10. Congele o candidato a lançamento. O quê: congele o inventário de URLs, mapa de redirecionamentos, definições de rotas, regras de canônicas e robots, geração de sitemaps, configuração de analytics e consentimento, plano de DNS/CDN e implantações de produção não relacionadas. Por quê: um resultado de teste se aplica apenas à versão testada. Como: etiquete os artefatos do lançamento, restrinja mudanças ao caminho de incidentes e exija reteste de qualquer coisa afetada por uma edição de emergência. Ferramenta: sistema de implantação, registro de alterações e registro de aprovação. Concluído quando: um candidato imutável é nomeado, o acesso é restrito, todas as exceções têm um responsável e toda mudança pós-congelamento carrega um resultado de teste.

Fase 4: dia do lançamento

11. Execute um runbook com proprietário único. O quê: implante roteamento, aplicação, DNS/CDN, analytics, sitemaps e monitores na ordem aprovada. Por quê: mudanças paralelas não sequenciadas dificultam o isolamento de falhas e tornam o rollback inseguro. Como: um líder de migração coordena cada etapa, o operador designado registra a conclusão e os validadores testam a evidência antes do próximo passo dependente. Ferramenta: runbook, logs de implantação, verificações de DNS e canal de incidentes compartilhado. Concluído quando: cada linha tem um horário real, operador, resultado e link de evidência, e nenhuma dependência é marcada como concluída apenas com garantia verbal.

12. Execute o teste smoke de lançamento. O quê: teste a página inicial, arquivo robots, sitemaps, pelo menos uma URL por template, toda jornada prioritária, recebimento de analytics e uma amostra estratificada de fontes de redirecionamento. Por quê: a resposta segura mais rápida vem da detecção de uma falha ampla antes que caches e rastreadores a propaguem. Como: teste de fora da rede de produção, use desktop e mobile, verifique tanto o HTML entregue pelo servidor quanto a saída renderizada, e compare com as expectativas congeladas. Ferramenta: rastreador, navegador, cliente HTTP, visão em tempo real do analytics e monitor de transações. Concluído quando: páginas críticas retornam o status e conteúdo pretendidos, redirecionamentos prioritários alcançam seus destinos exatos, eventos de analytics chegam com URLs corretas e todas as verificações de bloqueio de lançamento passam.

13. Envie e verifique os sinais de descoberta. O quê: publique os sitemaps finais, confirme o comportamento de robots e canônicas, e solicite inspeção para um pequeno conjunto de URLs prioritárias. Por quê: sinais de descoberta limpos ajudam rastreadores a encontrar o conjunto de destino sem tratar o envio como garantia de indexação. Como: envie cada sitemap de produção uma vez, inspecione URLs novas representativas e registre a canônica e o estado do índice informados pelo Google. Ferramenta: Sitemaps e Indexação e Inspeção de URL . Concluído quando: os sitemaps estão acessíveis e contêm o inventário canônico congelado, inspeções representativas não mostram bloqueio de produção ou canônica errada, e todo aviso tem um responsável.

Fase 5: monitoramento pós-lançamento

14. Monitore as primeiras 72 horas como uma janela de incidentes. O quê: monitore uptime, 5xx, 4xx, falhas de redirecionamento, latência, volume de rastreamento, recebimento de analytics, conversões, processamento de sitemaps e jornadas prioritárias de forma contínua ou no menor intervalo prático. Por quê: defeitos de infraestrutura e roteamento surgem rapidamente, enquanto o desempenho de busca leva mais tempo e não deve ser usado como o único alarme de lançamento. Como: compare com a base de referência assinada, segmente por template e diretório, e direcione alertas para um responsável de plantão. Ferramenta: logs, analytics, rastreador, Monitores de Uptime e painel de incidentes. Concluído quando: o painel não tem alerta crítico de lançamento inexplicado, cada incidente tem um responsável e timestamp, e as revisões de 24, 48 e 72 horas estão assinadas.

15. Continue o monitoramento de busca e índice após a estabilidade. O quê: acompanhe cliques por página, impressões, estado do índice, canônicas selecionadas, erros de rastreamento, desempenho de diretórios e resultados de conversão por pelo menos quatro semanas. Por quê: o rastreamento, a seleção de canônicas e a substituição do índice ficam atrás da validação de infraestrutura. Como: compare janelas equivalentes, separe URLs movidas de controles não alterados e investigue clusters em vez de reagir ao total de um único dia. Ferramenta: Páginas do Google Search , Visualização por Diretório , Inspeção de URL, analytics e logs. Concluído quando: destinos prioritários estão descobríveis e indexáveis, URLs antigas resolvem consistentemente para destinos aprovados, perdas inexplicadas têm tickets e a responsabilidade transita para o ritmo normal de relatórios.

Ferramentas no AmICited

O AmICited fornece evidências de lançamento e superfícies de monitoramento; o mapa de redirecionamentos aprovado e os logs de implantação permanecem a fonte da verdade operacional.

Regras de decisão

Estas são salvaguardas de lançamento, não limites universais de mecanismos de busca. Concorde-as antes do lançamento e restrinja-as onde o risco exigir.

Reverter (rollback) restaura um estado de serviço conhecido como bom; não reverte flutuações comuns de busca. A autoridade de lançamento aplica as regras acordadas e registra as evidências.

Entregável

Entregue um pacote de controle de migração versionado acessível para engenharia e SEO. Use uma pasta de trabalho ou banco de dados para registros em nível de linha, um runbook para ações de lançamento e um painel para métricas ao vivo.

Ele deve conter: o inventário congelado e a reconciliação de fontes; mapa de redirecionamentos aprovado com responsáveis e testes; rastreamentos correspondentes antigo, staging e novo; diffs de metadados, canônicas, robots, sitemap, hreflang, dados estruturados, links e analytics; base assinada e coortes prioritárias; runbook de lançamento e procedimento de recuperação; regras numéricas de rollback e responsável pela decisão; e as evidências de 24, 48 e 72 horas com responsabilidade de monitoramento por quatro semanas.

O líder de migração deve ser capaz de identificar o lançamento exato, comprovar cada teste crítico, reconstruir cada decisão de roteamento e atribuir cada exceção. Caso contrário, o pacote está incompleto.

O que dá errado

O mapa de redirecionamentos usa apenas o sitemap atual. URLs órfãs, URLs de campanha, backlinks e rotas previamente indexadas desaparecem, então cada linha da planilha passa enquanto solicitações reais falham.

A página inicial se torna o destino padrão. Usuários chegam a algum lugar irrelevante, os sinais dos rastreadores se tornam ambíguos e o conteúdo ausente é disfarçado como progresso de implementação.

Redirecionamentos funcionam, mas as referências permanecem antigas. Navegação, hreflang, canônicas, dados estruturados e sitemaps continuam enviando rastreadores através de saltos desnecessários e destinos conflitantes.

A proteção do staging chega à produção. Um noindex copiado, regra de autenticação, bloqueio de robots ou política de CDN destrói a indexabilidade . Exija uma etapa explícita de remoção e teste externo.

A equipe valida apenas a página inicial. Um template compartilhado pode configurar incorretamente milhares de páginas enquanto a página inicial passa. Amostre cada template e rastreie regras em escala.

Lançamentos não relacionados são enviados juntos. Quando plataforma, analytics, consentimento, navegação, checkout e mudanças de CDN compartilham uma janela, as falhas se tornam difíceis de isolar ou reverter.

A busca é julgada cedo demais ou de forma muito ampla. Os totais do site escondem diretórios quebrados e um dia volátil provoca correções desnecessárias. Compare coortes movidas, controles não alterados, diretórios e janelas correspondentes.

O rollback é debatido durante a interrupção. Um bom plano nomeia limites, tomador de decisão, tempo de recuperação, comandos, consequências de dados e sequência de validação antes do lançamento.

Próxima fase

Assim que as primeiras 72 horas estiverem estáveis, o próximo passo é a atualização e iteração contínuas . Ela precisa da base assinada, mapeamento final de URLs, anotações de lançamento, coortes de diretório, exceções conhecidas, histórico de incidentes e responsáveis nomeados deste checklist. Sem essas entradas, uma perda de tráfego posterior não pode ser separada de forma confiável entre dano de migração, mudança normal de demanda, decadência de conteúdo ou falha de medição.

Mantenha o mapa de redirecionamentos e a anotação de migração permanentemente. Mova descobertas não críticas para o ritmo normal de relatórios com gravidade, hipótese, responsável, data de vencimento e método de verificação.

Perguntas frequentes

Quando a equipe de SEO deve participar de uma migração de site?

Antes que rotas, templates e restrições de plataforma sejam fixadas. O SEO precisa de tempo suficiente para inventariar URLs atuais, preservar destinos valiosos, influenciar a nova arquitetura da informação, definir o comportamento dos redirecionamentos e concordar com regras mensuráveis de lançamento e rollback.

URLs antigas devem redirecionar para a página inicial quando não houver substituto direto?

Não. Redirecione uma URL antiga para a página mais próxima que atenda à mesma intenção do usuário. Se não existir um destino relevante e o conteúdo não deva ser preservado, retorne um 404 ou 410 honesto em vez de enviar usuários e rastreadores para uma página inicial não relacionada.

Por quanto tempo os redirecionamentos de migração devem permanecer ativos?

Mantenha redirecionamentos permanentes enquanto URLs antigas puderem receber visitas, links, favoritos ou solicitações de rastreadores. Trate-os como infraestrutura de roteamento durável, não como andaime de lançamento a ser removido após algumas semanas.

O que deve ser congelado antes do lançamento da migração?

Congele o inventário de URLs aprovado, o mapa de redirecionamentos, as regras de canônicas e robots, a geração de sitemaps, a configuração de analytics e consentimento, as alterações de DNS e CDN, e os lançamentos de produção não relacionados. Correções de emergência seguem o caminho nomeado de controle de mudanças.

Quando uma migração deve ser revertida (rollback)?

Use critérios acordados antes do lançamento. Execute rollback para falhas como indisponibilidade prolongada, respostas 5xx generalizadas, jornadas primárias quebradas, falta de analytics ou defeitos de roteamento que afetem uma parcela material das URLs prioritárias e não possam ser corrigidos com segurança dentro da janela de recuperação acordada.