Mudar de plataforma sem se perder: o plano de migração de um site pequeno

Categoria: Sites e Trabalho Freelancer
Atualizado há mais de uma semana.

O site novo está aprovado, mas o antigo ainda recebe contatos, usa um domínio conhecido e compartilha serviços com o e-mail da empresa. Publicar a nova versão exige mais do que copiar textos. Você precisa saber o que será preservado, o que mudará e como agir se o caminho principal deixar de funcionar. Este roteiro organiza essas decisões para um site institucional pequeno. A execução técnica deve respeitar a plataforma e contar com alguém capacitado quando envolver infraestrutura.

Descreva a mudança e descubra o que depende do endereço atual

Comece escrevendo uma frase precisa: “Vamos trocar a plataforma, manter o domínio e preservar os endereços das páginas de serviço”. Isso é diferente de mudar domínio, identidade visual e estrutura de conteúdo simultaneamente. Quando várias mudanças acontecem juntas, fica mais difícil descobrir a causa de um problema e recuperar uma parte sem desfazer as demais.

Monte um inventário que inclua páginas, artigos, imagens, documentos para download e formulários. Liste também domínio, hospedagem ou plataforma, provedor de DNS, e-mail e serviços externos. Para cada item, anote responsável, acesso autorizado, vencimento e relação com a migração. Um serviço que parece antigo pode continuar sustentando uma função importante.

Há diferenças entre mudar onde o site é hospedado e alterar seus URLs. O Google mantém uma orientação específica para mudanças de infraestrutura sem mudança de endereço. Identificar seu cenário evita aplicar procedimentos de troca de domínio a um projeto que apenas muda de fornecedor.

Pergunte ao cliente onde o endereço atual foi divulgado. Um QR code em cartão, um link de orçamento enviado por mensagem ou um PDF antigo podem apontar diretamente para uma página interna. Essas entradas não aparecem necessariamente no menu. A lista de migração precisa considerar os caminhos reais que pessoas continuam usando.

Defina também o que não será transferido automaticamente. Uma exportação de conteúdo pode não incluir layout, permissões, contatos recebidos ou comportamento de formulários. Peça ao fornecedor a cobertura exata e teste um conteúdo representativo. Não prometa que uma função ficará idêntica apenas porque o texto e a imagem puderam ser copiados.

Crie um destino para cada página antes de publicar

Considere o exemplo fictício de uma consultoria com doze páginas. O novo site manterá oito endereços, reunirá duas páginas semelhantes e substituirá uma página de serviço por outra com nome mais claro. A última página divulga um evento encerrado, sem conteúdo equivalente atual. Cada grupo pede uma decisão; uma regra única para todo o site não resolve o problema editorial.

Registre, por endereço antigo, a situação prevista: preservado, transferido para um equivalente, consolidado ou removido sem substituto. Anote o destino e a justificativa. No exemplo, duas páginas sobre o mesmo serviço podem levar a uma apresentação consolidada que realmente cubra ambas. A página do evento não deve ser enviada para uma oferta sem relação apenas para evitar uma mensagem de inexistência.

A documentação do Google para mudanças de URL recomenda planejar o mapeamento, testar o novo site e acompanhar a transição. Ela também alerta que a visibilidade nas buscas pode oscilar. Portanto, explique ao cliente que planejamento reduz erros evitáveis, mas não permite prometer tráfego ou posições inalterados.

  • Inclua no mapa os endereços encontrados no site e nos materiais de divulgação.
  • Confirme que cada destino existe e responde à mesma necessidade do visitante.
  • Identifique arquivos e imagens importantes, além das páginas de texto.
  • Marque quem implementará e quem verificará cada decisão.
  • Reserve uma coluna para resultado observado após a publicação.

Quando a mudança for permanente, a configuração apropriada pode envolver redirecionamentos permanentes, como 301 ou 308, conforme explica o guia oficial sobre redirecionamentos. A implementação depende do serviço. Confirme se a plataforma suporta seu mapa antes de contratá-la para a migração. Não cole regras genéricas de servidor em uma instalação que você não conhece.

Cada endereço precisa de um destino. Página antiga: descubra entradas reais; Mapa de mudança: preservar ou redirecionar; Destino pertinente: conferir a chegada.

Use este modelo de decisões para o mapa de endereços da consultoria; a implementação deve ser validada na plataforma.

Situação da URL antigaTratamento planejadoConferência após a virada
Endereço preservadoPublicar o conteúdo no mesmo caminhoPágina e links internos corretos
Serviço renomeadoDestino equivalente e redirecionamento apropriadoChegada direta ao serviço correto
Duas páginas reunidasDestino que cubra ambas as intençõesConteúdo útil preservado
Evento sem substitutoTratamento de remoção ou arquivo contextualizadoSem envio para oferta sem relação

Inclua no ensaio uma entrada que ninguém acessa pelo menu, como um link de proposta antiga. Ela pode revelar um arquivo ausente ou um redirecionamento que a revisão da página inicial não encontraria. Para cada endereço crítico, guarde o resultado antes da virada e o esperado depois. Evite encadear remendos sucessivos que passam por vários destinos antigos; peça ao responsável técnico que confira o caminho completo. O visitante deve chegar ao conteúdo pertinente mesmo usando um material de divulgação anterior à migração.

Prepare uma recuperação possível e proteja os serviços que ficam

Antes da mudança, pergunte: “Se o novo site falhar, o que conseguimos recuperar e quem consegue executar isso?”. A resposta precisa indicar arquivos ou exportações disponíveis, data da cópia, conteúdo coberto e procedimento de recuperação. Um botão com o nome backup não explica essas condições.

Em uma instalação WordPress típica, a documentação oficial distingue arquivos e banco de dados. Em serviços gerenciados, a cobertura pode ser diferente. Peça uma verificação em ambiente separado quando aplicável e confirme que a pessoa responsável sabe restaurar. Não use o site público como primeiro ensaio de uma recuperação desconhecida.

As cópias podem conter informações pessoais. Limite acesso, evite links públicos e combine armazenamento e descarte de acordo com as responsabilidades do projeto. Se a migração exige dados de contatos, defina quais registros são necessários e quem autoriza a transferência. Copiar toda a base apenas por conveniência aumenta trabalho e exposição.

Proteja especialmente o e-mail. O DNS contém diferentes tipos de registros, e os registros MX estão relacionados ao recebimento de mensagens. A documentação de tipos de registro DNS da Cloudflare ajuda a distinguir essas funções. Alterar o destino do site não é autorização para remover a configuração do correio eletrônico.

No exemplo da consultoria, o site antigo e o e-mail estão contratados no mesmo fornecedor. A nova plataforma hospedará somente o site. Cancelar o serviço antigo imediatamente pode afetar caixas de e-mail que deveriam continuar. A decisão correta começa por confirmar o contrato e planejar separadamente qualquer migração do correio, com o responsável técnico e o cliente.

Mudar o site não deve interromper o e-mail. Serviço antigo: confira dependências; Site: destino da migração; E-mail: continuidade separada.

Organize a virada como uma sequência de decisões verificáveis

Escolha uma janela em que os responsáveis estejam disponíveis para testar e corrigir. Um horário de pouco movimento pode ser apropriado, mas uma sexta-feira à noite é uma escolha ruim se ninguém dará suporte depois. Registre quem autoriza a publicação, quem mexe na configuração e quem confere os contatos recebidos.

Combine um momento para parar alterações no conteúdo antigo ou registrar tudo o que mudar. Sem isso, um texto aprovado de manhã pode desaparecer na cópia feita à tarde. Em sites que continuam recebendo dados, planeje como os registros criados durante a transição serão tratados. Uma cópia feita ontem não inclui automaticamente os contatos de hoje.

Antes da virada, teste a versão preparada: páginas, menu, formulário, textos, celular e informações essenciais. Confirme como funcionam a proteção do ambiente de preparação e a visibilidade da versão pública. O responsável técnico deve verificar as configurações pertinentes, sem expor rascunhos por engano nem deixar o site definitivo bloqueado por uma configuração de teste.

Depois da publicação, abra o domínio correto e execute os caminhos principais novamente. Teste entradas antigas e seus destinos, confira downloads e envie um contato demonstrativo. Verifique o registro no local previsto; uma mensagem de sucesso na tela não comprova que a equipe recebeu a solicitação. Quando houver e-mail no escopo de conferência, teste envio e recebimento com os responsáveis.

Defina antecipadamente o que exige interrupção ou recuperação. Exemplos são perda do contato principal, exposição de dados e indisponibilidade ampla. Uma diferença pequena de espaçamento pode ser registrada para correção, desde que não impeça uso. O retorno à versão anterior também precisa considerar dados criados desde a mudança; desfazer às pressas pode apagar informações novas.

Acompanhe a transição e só então encerre o que ficou para trás

Durante o período combinado, acompanhe os problemas encontrados e repita os testes após correções. O objetivo é confirmar que a operação está funcionando e que as entradas antigas estão recebendo o tratamento planejado. Os relatórios disponíveis variam por plataforma; não presuma que todo construtor possui análise de acesso ou registros técnicos detalhados.

Separe falha operacional de variação nos indicadores. Um formulário que não registra contatos exige investigação imediata. Uma mudança de posição na busca, isoladamente, não prova erro de migração. Se houver Search Console ou outra medição previamente configurada, compare períodos e páginas com cuidado, documentando também mudanças de conteúdo e campanhas.

Não cancele domínio, hospedagem ou serviços antigos sem conferir dependências remanescentes, custos e condições contratuais. Redirecionamentos, e-mail e arquivos ainda podem depender deles. Registre o que continuará ativo, por quanto tempo será acompanhado e quem ficará responsável pelos pagamentos e futuras decisões.

Entregue um resumo da migração com data, mapa de endereços, testes, pendências e contatos de suporte. O cliente deve saber o que mudou e como operar o novo cenário. A migração termina com continuidade verificada e responsabilidades definidas, não apenas com a nova página inicial aparecendo no seu navegador.

Imagem de perfil do autor

Diego David

Sou UX Developer, conectando criatividade e código para criar experiências digitais excepcionais, transformando ideias em interfaces intuitivas e funcionais, elevando cada projeto a novos patamares de inovação.

Comentários

Deixe um comentário