Checklist de Migração de Site (PDF)

Uma checklist de aprovação de migração de site imprimível: fases de pré-lançamento, dia do lançamento e pós-lançamento com caixas de seleção e linhas de assinatura dos responsáveis para que nada avance sem verificação.

Use esta checklist como a folha de aprovação imprimível para uma migração de site, a página que cada responsável assinala e assina antes e depois do go-live. Cada variante é uma fase, do planeamento e cópias de segurança, passando pelo dia do lançamento, até ao monitoramento pós-lançamento, terminando numa aprovação formal. Imprima-a, percorra-a fase a fase e não avance enquanto o responsável não tiver aprovado a fase. Isto mantém uma migração responsabilizada em vez de depender da memória e de boas intenções.

6 variações prontas para usar

Fase 1: Planear e Fazer Backup

Fixe o plano e faça cópias de segurança completas antes de alguém alterar um único URL.

Objetivo: garantir que a migração é reversível e totalmente planeada antes de o trabalho começar.

Assinale antes de começar

☐ Backup completo do site atual (ficheiros e base de dados) feito e restauro testado
☐ Rastreio completo do site antigo exportado e guardado
☐ Mapeamento de URLs (antigos para novos) esboçado para cada página
☐ Base de referência de analytics e Search Console registada: [instantâneo de tráfego / posições]
☐ Plano de rollback escrito e acordado com o responsável de dev
☐ Janela de lançamento agendada para horas de baixo tráfego: [Data / hora]

Aprovação da fase 1
Responsável: [Nome] Data: [Data] Assinado: [Assinatura]

Fase 2: QA em Staging

Verifique o novo site em staging para que os problemas sejam apanhados antes de se tornarem públicos.

Objetivo: confirmar que o novo site está correto e rastreável enquanto ainda é privado.

Assinale em staging

☐ Redirecionamentos testados em staging e a devolver os códigos esperados
☐ Títulos, meta descriptions e cabeçalhos presentes nas páginas-chave
☐ Tags canonical apontam para os novos URLs
☐ Links internos atualizados para os novos URLs, sem links para o domínio antigo
☐ robots.txt permitirá o rastreio no lançamento (noindex de staging removido no go-live)
☐ Sitemap XML gerado com os novos URLs e validado
☐ Renderização mobile e velocidade das páginas verificadas nos templates-chave

Aprovação da fase 2
Responsável: [Nome] Data: [Data] Assinado: [Assinatura]

Fase 3: Dia do Lançamento

A sequência de go-live, assinalada por ordem à medida que cada passo é concluído.

Objetivo: executar a mudança de forma limpa e confirmar o essencial no momento em que o site fica ativo.

Assinale durante o lançamento

☐ noindex / proteção por palavra-passe de staging removidos
☐ Redirecionamentos implementados em produção
☐ robots.txt ativo e a permitir o rastreio do novo site
☐ Novo sitemap submetido na Search Console
☐ Confirmado que analytics e tags de rastreio disparam no novo site
☐ Uma amostra de URLs antigos de alta prioridade confirmada manualmente a redirecionar
☐ Certificado SSL válido em todo o novo domínio

Aprovação da fase 3
Lançado por: [Nome] Hora do go-live: [Hora] Assinado: [Assinatura]

Fase 4: Primeiras 48 Horas

Apanhe os erros que só aparecem quando tráfego real atinge o site em produção.

Objetivo: encontrar e corrigir avarias do dia do lançamento antes que custem posições.

Assinale dentro de 2 dias

☐ Rastreio completo do site ativo executado; 404 e redirecionamentos quebrados registados
☐ Cadeias e loops de redirecionamento verificados e eliminados
☐ Search Console verificada quanto a erros de rastreio e avisos de cobertura
☐ Taxa de erros do servidor e tempos de carregamento monitorizados: [estado]
☐ Páginas de alta prioridade confirmadas como indexáveis e a devolver 200
☐ Qualquer conteúdo perdido na mudança restaurado ou assinalado: [notas]

Aprovação da fase 4
Responsável: [Nome] Data: [Data] Assinado: [Assinatura]

Fase 5: Monitoramento das Semanas 1–4

Observe as posições, a indexação e o tráfego a estabilizar para que quedas reais sejam tratadas cedo.

Objetivo: confirmar que a migração se aguentou e agir sobre tudo o que escorregou.

Assinale ao longo do primeiro mês

☐ Indexação dos novos URLs a progredir na Search Console
☐ Posições das palavras-chave prioritárias comparadas com a base de referência de pré-lançamento
☐ Tráfego orgânico acompanhado face ao mesmo período do ciclo anterior: [tendência]
☐ Quaisquer páginas que perderam posições investigadas e corrigidas
☐ Backlinks a apontar para URLs antigos continuam a resolver via redirecionamentos
☐ Sitemap antigo removido assim que os novos URLs estão indexados

Aprovação da fase 5
Responsável: [Nome] Data: [Data] Assinado: [Assinatura]

Fase 6: Aprovação Final

Encerre o projeto assim que a migração estiver verificada como estável e responsabilizada.

Objetivo: encerrar formalmente a migração com cada responsável de fase prestando contas.

Confirme antes de encerrar

☐ Todas as fases anteriores aprovadas
☐ Sem 404 pendentes ou redirecionamentos quebrados nas páginas prioritárias
☐ Tráfego e posições dentro de um intervalo aceitável da base de referência, ou a recuperar conforme o plano
☐ Questões em aberto registadas com responsáveis e prazos: [lista]
☐ Relatório pós-migração partilhado com os stakeholders

Aprovação do projeto

Responsável de SEO: [Nome] Data: [Data] Assinado: [Assinatura]

Responsável de dev: [Nome] Data: [Data] Assinado: [Assinatura]

Aprovador: [Nome] Data: [Data] Assinado: [Assinatura]

Como usar este modelo

Imprima a checklist e atribua um responsável nomeado a cada fase antes de qualquer trabalho começar.
Conclua a fase 1: faça e teste um backup completo, registe as bases de referência e acorde um plano de rollback.
Trabalhe a fase 2 inteiramente em staging para que redirecionamentos, metadados e rastreabilidade sejam verificados em privado.
Execute a sequência de lançamento da fase 3 por ordem e confirme redirecionamentos e rastreio no momento em que fica ativo.
Dentro de 48 horas, rastreie o site ativo em busca de 404 e problemas de redirecionamento e corrija-os rapidamente.
Monitorize a indexação, as posições e o tráfego ao longo das semanas 1 a 4 e investigue tudo o que escorregue.
Exija que o responsável de fase assine cada fase antes de a migração avançar para a seguinte.
Conclua a aprovação final apenas quando as páginas prioritárias estiverem limpas e os stakeholders tiverem o relatório.

Dicas profissionais

Trate cada linha de aprovação como um portão real, não uma formalidade: uma fase por assinar significa que o trabalho não está verificado, e o trabalho não verificado é onde as migrações perdem tráfego.
Faça e teste o restauro do seu backup antes de tocar em seja o que for; um plano de rollback que nunca testou é uma esperança, não um plano.
Agende o lançamento para horas genuinamente de baixo tráfego para que as inevitáveis correções da primeira hora afetem o menor número de utilizadores.
Continue a monitorizar durante um mês inteiro; as posições e a indexação estabilizam gradualmente, e as piores quedas surgem muitas vezes uma ou duas semanas após o lançamento, não no primeiro dia.

Perguntas frequentes

Porquê usar um PDF imprimível em vez de uma folha de cálculo?

Uma folha de aprovação é sobre responsabilização, não sobre dados. Imprimi-la e fazer cada responsável assinalar e assinar força uma paragem deliberada em cada portão. Combina bem com uma folha de cálculo de mapeamento de URLs, que trata do detalhe linha a linha, enquanto esta folha confirma que cada fase foi de facto concluída e assumida.

Com quanto tempo antes do lançamento deve começar a fase 1?

Comece o planeamento e os backups bem antes da janela de lançamento, idealmente semanas antes para um site grande. Apressar o plano e o mapeamento é de onde vem a maior parte dos danos evitáveis de uma migração. Quanto mais cedo existirem o rastreio, o mapeamento e o plano de rollback, menos pressão recai no dia do lançamento.

Qual é a fase mais importante?

Honestamente, o QA em staging da fase 2 e o rastreio de 48 horas da fase 4 apanham o mais. Testar redirecionamentos antes do lançamento e voltar a rastrear logo a seguir cobre as maiores fontes de perda de tráfego. Dito isto, saltar o backup na fase 1 é o único erro que realmente não pode desfazer.

Devo esperar uma queda de tráfego após migrar?

Uma quebra curta enquanto os motores de busca voltam a rastrear e reindexar é comum, mesmo numa migração limpa. O que importa é a tendência recuperar dentro de semanas. Uma queda que continua a aprofundar-se costuma apontar para redirecionamentos quebrados, conteúdo perdido ou problemas de indexação que a fase de monitoramento foi concebida para apanhar.

Quem deve assinar cada fase?

A pessoa realmente responsável por esse trabalho: normalmente um programador para o lançamento e os redirecionamentos, e um responsável de SEO para o QA e o monitoramento. Um aprovador final assina o projeto inteiro. Nomes reais em cada linha deixam claro quem verificou o quê, caso algo precise de ser revisto mais tarde.

Posso reutilizar isto para uma mudança menor, como um redesenho?

Sim, embora possa saltar as fases que não se aplicam. Um redesenho que mantém os URLs inalterados precisa de menos trabalho de redirecionamento, mas continua a beneficiar de QA em staging, de um backup e de monitoramento pós-lançamento. Reduza a folha às fases que correspondem ao âmbito da sua mudança específica.