Plano de Migração de Website: Fases, Redirecionamentos e Verificações de Lançamento

Um estudo de 2025 de 892 migrações de domínio constatou que, em média, um site levou 523 dias para recuperar seu nível anterior de tráfego orgânico estimado, de acordo com a Search Engine Journal, conforme relatado no guia de reformulação de marca de websites da Veza Digital^[1]. Isso é um motivo para tratar a migração como proteção para o tráfego que você já conquista, e não apenas como uma implantação bem-sucedida.

Um plano de migração de website precisa cobrir o que acontece depois que o arquivo de redirecionamento é enviado. Os mecanismos de busca precisam descobrir as mudanças, os visitantes ainda precisam concluir suas tarefas e alguém precisa ser responsável pelas URLs antigas muito depois de a equipe de lançamento seguir em frente.

Este guia é o plano do projeto. Para a sequência detalhada de testes, veja nosso guia de testes de migração de website e, especificamente para uma mudança de domínio, mudança de domínio para SEO.

Fases da migração, responsáveis e entregas em resumo#

Estruture o cronograma em torno de marcos de aceitação, não da data de lançamento preferida pela equipe de design. O cronograma a seguir é ilustrativo, não um requisito universal de prazo.

Fases da migração, cronograma, entregas e responsáveis

Agende dependências antes das datas#

O responsável de SEO aprova os destinos antes de a engenharia escrever as regras de produção. Os redirecionamentos devem passar pela validação em staging antes da troca do sitemap, e os testes de experiência devem ser concluídos antes de a equipe se comprometer com a virada.

Para um site institucional pequeno com conteúdo estável, a auditoria e o mapeamento podem correr em paralelo. Isso economiza tempo de handoff, mas não justifica pular os testes das tarefas: um formulário de contato quebrado pode tornar uma migração, de outra forma organizada, comercialmente inútil.

Quando a tabela listar responsabilidades partilhadas, nomeie um responsável e registe os revisores de apoio. Faça isso antes de a auditoria começar, incluindo quem pode adiar o lançamento e quem pode autorizar o rollback. Caso contrário, decisões não resolvidas tendem a chegar à engenharia հենց quando a janela de implementação se fecha.

Audite o Site Legado e Defina uma Linha de Base#

Comece com um crawl do site em produção usando Screaming Frog ou Sitebulb. Complete com exportações do CMS, sitemaps XML, páginas de entrada do analytics e logs do servidor, porque um crawler não descobrirá páginas órfãs por meio de links internos.

Não presuma que a configuração do hostname seja óbvia. Em amostras de desktop, o uso de www caiu de 48,64% em 2019 para 41,01% em 2022, de acordo com o relatório de tecnologia do HTTP Archive^[2]. O comportamento do seu próprio host precisa de testes explícitos, e não de uma decisão baseada na convenção.

Produza exportações auditáveis#

Dê a cada exportação um esquema definido para que outro membro da equipe possa reproduzir a linha de base.

• crawl-export.csv: Inclua URL, código de status, destino canônico, indexabilidade, título, modelo e contagem de links internos. Preserve a string original da URL juntamente com qualquer chave de correspondência normalizada.
• gsc-landing-pages-12m.csv: Exporte o histórico anual disponível do Search Console com página de destino, data, cliques, impressões e propriedade. Mantenha os filtros consistentes entre as exportações.
• backlinks-by-url.csv: Use Ahrefs, Semrush ou outra ferramenta de backlinks para registrar a URL de destino, a contagem de domínios de referência e páginas importantes com links.
• host-check.csv: Registre a URL solicitada, a jornada de redirecionamento, o hostname final e a tag canônica para solicitações seguras e inseguras, variantes de hostname, diferenças de maiúsculas e minúsculas e o comportamento da barra final.

Uma revisão externa pode ajudar a distinguir problemas de visibilidade existentes dos riscos de migração. O recurso da Baikou para revisar a visibilidade de pesquisa do seu site^[3] é um contexto útil ao decidir quais páginas legadas merecem uma investigação mais cuidadosa.

Congele uma referência utilizável#

Crie baseline-metrics.csv com contagens de páginas indexadas, estatísticas de rastreamento, Core Web Vitals por modelo e eventos de conversão por tipo de página. Inclua datas de medição e métodos de coleta para que ninguém compare o desempenho de campo com um teste de laboratório não relacionado.

Anexe resultados automatizados de acessibilidade e achados de tarefas realizadas apenas com teclado para modelos importantes. Registre se os visitantes podem abrir a navegação, enviar formulários, recuperar-se de erros e concluir a autenticação, em vez de salvar apenas uma pontuação de auditoria.

Armazene as exportações em uma pasta compartilhada datada com acesso de leitura para todos os proprietários. Assim que a auditoria for encerrada, preserve esse snapshot; as correções devem ficar em uma nova versão datada com uma nota de alteração.

Mapeie cada URL e escreva as regras de redirecionamento#

Trabalhe o inventário em uma sequência deliberada:

1. Classifique a URL legada. Combine status de resposta, tráfego, backlinks e valor do conteúdo.
2. Escolha o destino. Selecione a página mais próxima que satisfaça a mesma intenção do visitante.
3. Atribua a resposta. Diferencie mudanças permanentes, roteamento temporário e remoções reais.
4. Teste o comportamento da regra. Verifique caminhos, parâmetros, ativos, normalização do hostname e precedência das regras.

Escolha a relevância antes da conveniência#

Uma página quebrada com domínios de referência valiosos precisa de investigação. Um arquivo raso, sem conteúdo útil, talvez não mereça um substituto. Nenhuma dessas decisões deve ser tomada apenas com base no código de resposta atual.

A consolidação precisa de aprovação editorial. Se vários artigos se tornarem um hub de tema, o proprietário do conteúdo deve confirmar que o hub responde às perguntas que esses artigos abordavam. Uma página de categoria ampla não é automaticamente um destino equivalente.

Ação de redirecionamento e código de status por caso de URL legada

Use o comportamento de redirecionamento permanente versus temporário para definir a intenção antes da implementação. O roteamento temporário precisa de uma decisão de expiração, não apenas de um código de resposta diferente.

Uma verificação de um salto que você pode repetir#

Cada linha na tabela acima deve terminar em um único salto. Em 27 de outubro de 2026 (por volta de 01:20 UTC), solicitamos as quatro variantes da página inicial da RedirHub com curl a partir de um servidor em nuvem, sem seguir redirecionamentos. Cada variante que redirecionava chegou à página inicial canônica em um único salto:

Execute curl -sS -o /dev/null -w "%{http_code} %{redirect_url}" em cada variante do seu próprio host e corrija qualquer uma que retorne um segundo redirecionamento antes de lançar. A combinação de 301 e 308 acima está correta: ambos são permanentes, e a escolha só importa quando o método da solicitação precisa ser preservado.

Escreva exceções explícitas#

Preserve a atribuição da campanha e os parâmetros funcionais da query, mas não carregue cegamente identificadores de sessão obsoletos ou parâmetros que quebrem o destino. Teste caracteres codificados, parâmetros repetidos e caminhos profundos na aplicação real.

Inclua arquivos para download e imagens vinculadas. Para projetos de comércio eletrônico, as melhores práticas de redirecionamento na migração para Shopify^[4] da Grumspot fornecem contexto específico da plataforma para revisar regras junto com o comportamento da loja.

A lista de verificação de migração de Patrick Stox^[5] recomenda mapeamentos permanentes diretos, incluindo ativos, e manter as cadeias em cerca de três saltos ou menos. Prefira a resolução direta ao destino final em vez de empilhar um redirecionamento de hostname, um redirecionamento de protocolo e uma reescrita de caminho.

Armazene o mapa aprovado como um arquivo versionado com URL antiga, destino, resposta pretendida, justificativa, responsável e revisor. Dê precedência a mapeamentos específicos sobre padrões amplos e exija revisão sempre que alguém alterar qualquer um deles. O Migration Redirect Mapper pode ajudar a organizar os pares de URL antigo-novo.

Configurar o Search Console para ambos os sites#

Prepare o acesso aos relatórios antes da transição. O responsável por SEO precisa inspecionar as propriedades antiga e nova de forma independente; um painel combinado pode ocultar uma seção legada com problemas atrás do crescimento em outra área.

Preparar acesso e relatórios#

• Verificar a propriedade: Use uma verificação duradoura controlada pela organização, não a conta de um contratado que está saindo. Inclua subdomínios que geram tráfego no escopo do monitoramento.
• Corresponder o escopo da propriedade: Propriedades de domínio incluem variações de hostname e protocolo, enquanto propriedades com prefixo de URL têm limites mais restritos. Certifique-se de que as comparações cubram conjuntos de URLs equivalentes.
• Preparar o sitemap: Gere-o a partir dos destinos canônicos pretendidos e valide-o antes da publicação. Segure o envio até que esses destinos e seus redirecionamentos funcionem em produção.
• Arquivar relatórios: Salve as exportações de desempenho e indexação na pasta de auditoria, com os filtros e os nomes das propriedades registrados.
• Atribuir revisores: Nomeie um responsável e um substituto para cada propriedade, com uma reunião de revisão recorrente durante a estabilização.

Lidar com a mudança de domínio de forma deliberada#

Para uma mudança de domínio elegível, prepare o fluxo de Trabalho de Mudança de Endereço na propriedade antiga e envie-o depois que os redirecionamentos estiverem ativos e as verificações forem aprovadas. Não o use como substituto para o mapeamento de URLs nem para alterações que ele não suporta.

Mantenha a propriedade antiga verificada enquanto os URLs legados continuarem relevantes para o monitoramento. Remover o acesso cedo dificulta investigar impressões persistentes, URLs perdidos e comportamento inesperado de rastreamento.

Preserve também a continuidade da análise. Confirme os nomes dos eventos, o comportamento de consentimento e as configurações entre domínios para que uma mudança de rastreamento não pareça uma perda de tráfego ou conversões.

Para uma reformulação no mesmo domínio, em que o domínio permanece mas a plataforma por trás dele muda, o Modo de Integração permite que a nova plataforma (Cloudflare Workers, Next.js na Vercel ou Caddy) sirva o mapa de redirecionamento do RedirHub sem alteração de DNS e reporte os 404 que os visitantes ainda acessam após o lançamento.

Verificações Pré-Lançamento e a Decisão de Ir ou Não Ir#

Uma página inicial aprovada não estabelece que o site esteja pronto. Monte o conjunto de testes a partir de páginas que recebem tráfego, ativos vinculados, formas alternativas de URL e os templates que os visitantes usam para concluir tarefas valiosas.

Reproduza o inventário no ambiente de staging#

A engenharia deve reproduzir o roteamento de produção em um ambiente isolado, incluindo regras de CDN e redirecionamentos da aplicação. Use uma substituição de host ou configuração controlada equivalente para testar solicitações legadas sem expor o staging aos mecanismos de busca.

O relatório de reprodução precisa conter a URL solicitada, o destino esperado, o destino real, a jornada da resposta, o resultado do parâmetro e a indexabilidade final. Sinalize loops, cadeias sem explicação, respostas bem-sucedidas inesperadas, incompatibilidades de destino, parâmetros perdidos e redirecionamentos que terminam em erros.

Verifique também os recursos e os sinais de descoberta:

• Ativos da aplicação: JavaScript, CSS, imagens e downloads devem carregar sem autenticação ou falhas de roteamento.
• Diretrizes de pesquisa: Revise robots.txt, tags canônicas, referências hreflang, links internos e entradas do sitemap.
• Controles de lançamento: Confirme que a produção não herdará senhas de staging, bloqueios acidentais de rastreamento ou diretivas noindex não intencionais.
• Medição: Verifique os eventos de conversão usando envios de teste e transações concluídas, e não apenas visualizações de página.

Nosso Verificador de Redirecionamentos gratuito pode apoiar a repetição, enquanto nosso Serviço de Redirecionamento 301 oferece suporte ao mapeamento de destinos, ao encaminhamento obrigatório de caminho e consulta, e aos testes do percurso antes do lançamento. Use o fluxo de trabalho de verificação em massa de redirecionamentos para tornar os resultados repetíveis em vez de depender de verificações pontuais no navegador.

Compare as distribuições por classe de resposta com a linha de base, levando em conta as remoções aprovadas. Contagens de páginas indexadas, cliques orgânicos e atividade do rastreador tornam-se comparações de produção após o lançamento; o staging pode estabelecer a prontidão técnica, não a recuperação de pesquisa.

Teste se as pessoas conseguem concluir#

Execute tarefas equivalentes nas experiências antiga e nova usando navegação apenas por teclado, um leitor de tela e dispositivos móveis. Inclua checkout ou formulários de leads, autenticação, erros de validação e recuperação após um envio com falha.

A Lei Europeia de Acessibilidade entrou em vigor em 28 de junho de 2025 para produtos e serviços abrangidos que atendem usuários da UE, conforme descrito no guia de migração de sites da Niteco^[6]. Trate a aceitação de acessibilidade como relevante para conformidade quando aplicável, e peça ao especialista jurídico ou de acessibilidade responsável que confirme o escopo do projeto.

Escreva os critérios de aceitação das tarefas antes dos testes. Exija a conclusão bem-sucedida sem uma desaceleração repetível em condições comparáveis e investigue diferenças de tempo em vez de tratar a variação normal dos participantes como um defeito.

Torne a decisão de lançamento explícita#

O líder da migração deve recolher a aprovação com base em evidências concretas:

• Inventário e mapeamento: O inventário está atualizado, as decisões de destino estão aprovadas e o lançamento faz referência à versão do mapa revisada.
• Aceitação técnica: Não permanecem falhas de roteamento sem explicação em URLs de alto valor.
• Aceitação da experiência: As tarefas críticas não têm regressões de acessibilidade ou funcionais sem resolução.
• Prontidão para recuperação: Os backups podem ser restaurados, o rollback foi ensaiado e a reconciliação de transações tem um responsável.
• Cobertura operacional: Todas as fases têm uma pessoa responsável e um contacto de escalonamento.

Um item de alto valor com falha adia o lançamento. Problemas estéticos podem entrar numa fila de remediação documentada, mas checkout quebrado, rastreamento bloqueado e formulários inacessíveis não são cosméticos.

Procedimento do dia do lançamento em ordem#

Use um runbook com um operador, um verificador e um resultado registrado para cada ação. Escolha uma janela de baixo tráfego quando as pessoas necessárias para o diagnóstico estiverem disponíveis, e não apenas a hora mais calma no gráfico de tráfego. Um lançamento às 3h da manhã que ninguém consegue depurar é mais arriscado do que um lançamento em um horário moderado com a equipe completa online.

Executar a transição#

1. Congele as alterações. Pare a publicação de conteúdo e as edições de URL em ambos os sistemas durante o intervalo acordado antes da transição. Documente as exceções essenciais e regenere os testes de mapeamento afetados antes de prosseguir.
2. Verifique o artefato de lançamento. Compare a configuração de redirecionamento com o mapa aprovado usando uma soma de verificação ou um identificador de versão. Um nome de arquivo familiar não prova que a engenharia possui as regras revisadas.
3. Implante o roteamento e o novo site juntos. Coordene as alterações de aplicação, CDN e infraestrutura para que os visitantes não encontrem um ambiente parcialmente alternado. Remova as restrições de acesso exclusivas de produção e os bloqueios de indexação não intencionais como parte do lançamento controlado.
4. Teste rapidamente as URLs prioritárias. Verifique as páginas de destino legadas de maior valor, os destinos de backlinks e os pontos de entrada de transações. Confirme o roteamento direto, as respostas pretendidas, os parâmetros necessários e um destino canônico indexável; depois, inicie a repetição do inventário completo.
5. Publique e envie o sitemap. Libere o sitemap de produção somente após os destinos resolverem corretamente. Mantenha a propriedade antiga do Search Console acessível e conclua qualquer notificação de mudança aplicável.
6. Verifique cada hostname. Valide a resolução de DNS, a cobertura do certificado e o roteamento para domínios antigos e subdomínios ativos. Não desative um servidor antigo até que outro endpoint consiga servir seus redirecionamentos de forma confiável.
7. Observe o comportamento ao vivo. A engenharia monitora erros de servidor e logs de redirecionamento enquanto a análise verifica eventos recebidos e a UX valida tarefas críticas. Registre o horário da implantação para que investigações posteriores possam distinguir os efeitos do lançamento de alterações não relacionadas.
8. Aplique a regra de rollback acordada. Interrompa ou reverta o lançamento afetado quando jornadas críticas falharem, surgirem loops de redirecionamento ou os erros de servidor ultrapassarem a tolerância de base acordada. Evite improvisar grandes reescritas em produção enquanto os clientes estão enfrentando falhas.

Mantenha o rollback utilizável#

Defina se rollback significa restaurar os arquivos da aplicação, alternar o roteamento, restaurar os dados ou alguma combinação disso. Para sites transacionais, reverter a infraestrutura sem reconciliar novos pedidos ou envios pode criar um segundo incidente. Atribua a etapa de reconciliação a um responsável nomeado antes do lançamento e ensaie a sequência completa para que a equipe saiba quanto tempo uma reversão leva sob carga.

Trate a camada de redirecionamento como parte da decisão de rollback, não como um pano de fundo fixo. Se as novas regras de roteamento forem a origem das falhas, reverter apenas o código deixa os mesmos redirecionamentos quebrados em produção. A documentação de migração de site do Google^[7] recomenda redirecionamentos do lado do servidor desde o momento em que a migração começa, o envio do sitemap após as novas URLs serem resolvidas e o monitoramento separado das propriedades antiga e nova do Search Console. A implantação é, portanto, um marco operacional, não o ponto em que a responsabilidade pela migração termina.

Monitoramento Pós-Lançamento e Governança de Redirecionamentos#

Mantenha um responsável nomeado vinculado a cada janela de monitoramento. As orientações de risco de transformação web da Siteimprove^[8] identificam um inventário de redirecionamentos vivo, propriedade atribuída, limites de escalonamento e decisões de término de regras temporárias como lacunas operacionais no planejamento de migração.

Cadência de monitoramento pós-lançamento

O seguinte é um cronograma operacional proposto. Ajuste a equipe ao risco sem remover as verificações.

Gerencie mudanças, não apenas incidentes#

A análise é responsável pela integridade do rastreamento e pelas comparações de base; SEO é responsável pela investigação de busca; engenharia é responsável pela implantação e reversão; conteúdo é responsável pela relevância do destino e pelas correções de links internos. Use um fluxo de trabalho documentado de monitoramento de redirecionamentos para que os alertas cheguem à pessoa responsável.

Mantenha o inventário pesquisável e versionado, com um revisor para cada edição. Regras temporárias precisam de uma data de expiração e de um revisor nomeado; a expiração deve disparar uma decisão, não a exclusão automática sem verificar o tráfego.

A documentação do Google sobre mudança de site recomenda manter os redirecionamentos por pelo menos 180 dias, e por mais tempo quando as URLs antigas continuarem recebendo tráfego de pesquisa do Google. Nossa recomendação é manter os redirecionamentos permanentes de migração indefinidamente, porque backlinks, favoritos e URLs indexadas podem continuar enviando visitantes por anos.

Imagine que uma empresa de SaaS muda o blog para um diretório de recursos. Mais tarde, boletins antigos ainda trazem visitantes qualificados para os endereços legados dos artigos, então o responsável pelo conteúdo mantém esses mapeamentos ativos em vez de aposentá-los para organizar o inventário.

Avalie a recuperação com base em tendências sustentadas, com comparações sazonais e diagnóstico por página. Uma semana de lançamento tranquila não comprova sucesso, e uma queda de tráfego isolada também não identifica a falha.

A RedirHub oferece mapeamentos de migração com importação CSV, encaminhamento de caminho e consulta, e HTTPS automático para hostnames conectados. Visite RedirHub para colocar seu mapa de URLs aprovado em operação e manter os links legados funcionando após o lançamento.