Mudar um website WordPress de servidor exige mais do que copiar ficheiros. É preciso preservar a base de dados, as configurações e os serviços de que o website depende, além de garantir que a passagem para o novo alojamento não interrompe operações importantes.
Há uma distinção essencial: migrar o website, transferir o registo do domínio e mudar o serviço de email são operações diferentes. Podem integrar o mesmo projeto, mas cada uma exige verificações próprias. Uma migração bem planeada reduz o risco de indisponibilidade, perda de dados e problemas de SEO, sem prometer que esses riscos desaparecem por completo.
O que vai mudar na migração?
Antes de começar, convém perceber o âmbito da mudança. Nem sempre é necessário alterar o domínio, os endereços das páginas ou o serviço de email.
| Situação | Principal cuidado |
|---|---|
| Mesmo domínio, novo alojamento | Transferir a instalação, testar a compatibilidade e encaminhar o tráfego para o novo servidor, mantendo as URLs. |
| Novo domínio ou alteração de URLs | Preparar os novos endereços, os redirecionamentos e a transição nos motores de pesquisa. |
| Migração também do email | Transferir contas e mensagens, configurar o serviço de correio e coordenar a mudança dos registos DNS. |
O domínio pode continuar registado no fornecedor atual, mesmo que o WordPress passe para outro servidor. O DNS determina para onde são encaminhados o website, o email e outros serviços; mudar os servidores de nomes do domínio é diferente de alterar apenas o endereço do servidor web.
Preparação: inventário, cópia de segurança e testes
Uma migração começa por identificar o que deve ser copiado, o que se mantém e o que terá de ser reconfigurado. O inventário deve abranger:
- WordPress e conteúdos:
- ficheiros, base de dados, imagens, temas, plugins, código personalizado, utilizadores e configurações.
- Infraestrutura:
- versões de PHP e MySQL/MariaDB, extensões, limites do servidor, certificados HTTPS, regras de redirecionamento e tarefas agendadas.
- Serviços associados:
- DNS, email, envio por SMTP ou API, formulários, pagamentos, faturação, CRM, integrações e serviços como Cloudflare ou outras CDN.
- Pesquisa e medição:
- URLs, sitemap XML, diretivas de indexação, Google Search Console e ferramentas de análise de tráfego.
A cópia de segurança tem de permitir recuperar o website
Antes de fazer alterações, guarde uma cópia completa dos ficheiros e da base de dados, num local independente dos servidores envolvidos. No WordPress, os ficheiros incluem temas, plugins, imagens e personalizações; a base de dados contém conteúdos, definições, utilizadores e, numa loja, informação operacional.
Confirme que a cópia está íntegra e que existe um procedimento de recuperação viável. Uma cópia incompleta, ou demasiado antiga para um website em atividade, pode não servir para recuperar o estado necessário. Se o email também for migrado, as mensagens e a configuração das caixas exigem uma salvaguarda própria.
Testar o novo alojamento antes de mudar o tráfego
A instalação deve ser preparada e testada no servidor de destino, através de um ambiente de testes, de uma pré-visualização do fornecedor ou de um acesso local configurado para esse efeito. O ambiente de testes deve ter o acesso condicionado e não deve ser indexável.
É nesta fase que se detetam incompatibilidades com versões de PHP, extensões, limites de memória, configurações do servidor ou plugins antigos. A página inicial abrir corretamente é apenas uma parte da validação: também é preciso testar o painel de administração, gravação de conteúdos, formulários, pesquisas, autenticação e integrações relevantes.
Se o domínio mudar, a atualização das referências internas deve ser feita com ferramentas que respeitem os dados serializados do WordPress. Uma substituição indiscriminada de texto diretamente na base de dados pode danificar configurações de temas e plugins.
Como preservar URLs e SEO
Quando o domínio e as URLs se mantêm, a mudança de alojamento é, em regra, mais simples do ponto de vista do SEO. Não há motivo para alterar os endereços das páginas apenas porque o servidor mudou. Ainda assim, devem manter-se conteúdos, ligações internas, metadados, endereços canónicos e condições de rastreamento.
Quando as URLs mudam, o trabalho é diferente. Cada endereço antigo relevante deve ter um destino novo correspondente, preparado antes da transição. Por exemplo, se empresa.pt/servicos/websites passar a empresa.pt/websites, o endereço antigo deve encaminhar o visitante para a nova página, normalmente através de um redirecionamento permanente 301 ou 308.
Numa migração com alteração de URLs, é necessário:
- Mapear as páginas antigas e novas, incluindo conteúdos importantes, imagens e páginas que recebem visitas ou ligações externas.
- Configurar e testar os redirecionamentos, evitando cadeias desnecessárias e o envio indiscriminado de páginas para a página inicial.
- Atualizar as referências internas, os endereços canónicos, o sitemap XML e as indicações de idiomas, quando existem.
- Confirmar a indexabilidade, verificando
robots.txt, eventuais diretivasnoindexusadas nos testes e as propriedades adequadas no Google Search Console.
Na mudança para outro domínio ou subdomínio, pode ainda ser aplicável a ferramenta Alteração de endereço do Search Console. Não é necessária numa simples mudança de alojamento ou de caminhos dentro do mesmo domínio.
Uma migração com alteração de URLs pode provocar oscilações temporárias na Pesquisa Google. Os redirecionamentos ajudam a preservar a continuidade, mas não garantem que o posicionamento permaneça inalterado. Sempre que possível, é preferível separar a mudança de servidor de um redesenho profundo ou de uma reorganização das URLs, para facilitar a identificação de problemas.
DNS, HTTPS e email: evitar interrupções desnecessárias
A passagem de tráfego começa, normalmente, com a alteração dos registos DNS que identificam o destino do website. Os registos A e AAAA podem apontar para o servidor web; o CNAME pode estabelecer um nome alternativo, dependendo da configuração. Se existir Cloudflare com proxy ativo, é necessário verificar também o servidor de origem, os certificados e as regras de cache.
O TTL (tempo durante o qual uma resposta DNS pode permanecer em cache) influencia a transição. Reduzi-lo com antecedência, quando é configurável, pode diminuir o período de utilização de registos antigos. Não garante, porém, uma mudança simultânea para todos os visitantes. Por isso, não se deve desligar imediatamente o alojamento anterior.
O novo ambiente deve ter HTTPS operacional antes da passagem para produção. Depois, é preciso verificar o certificado, os redirecionamentos de HTTP para HTTPS e a ausência de recursos bloqueados por conteúdo misto.
Quando o email continua no mesmo fornecedor
Uma mudança de alojamento WordPress não obriga a migrar as caixas de correio. A receção de email depende, entre outros fatores, dos registos MX e da resolução dos servidores de correio. O envio e a autenticação podem depender de SPF, DKIM, DMARC e de configurações específicas do fornecedor.
Se mudar apenas o destino do website, preserve os registos de email necessários. Se mudar os servidores de nomes do domínio, confirme previamente que todos os registos DNS relevantes foram reproduzidos na nova zona, incluindo os de email, verificações e subdomínios; quando aplicável, reveja também o DNSSEC.
Quando as caixas de correio também são migradas
É necessário criar as caixas no novo serviço, transferir as mensagens, preservar endereços alternativos e reencaminhamentos e validar os programas de email. A mudança dos registos MX deve ser coordenada com a transferência das mensagens, porque durante a transição pode continuar a haver entregas no serviço anterior. Os testes devem abranger envio e receção, em ambos os serviços enquanto a mudança não estiver concluída.
Mesmo sem mudar de fornecedor de email, os formulários do website podem deixar de enviar mensagens depois da migração. Teste o envio através de SMTP ou API, a recuperação de palavra-passe e as notificações do WordPress ou WooCommerce. Uma página visualmente correta pode continuar a perder pedidos de contacto.
Como coordenar a passagem para o novo servidor
Depois de preparar e validar o destino, a mudança deve seguir uma sequência controlada:
- Definir a janela de transição e o plano de recuperação, incluindo quem verifica o resultado e como voltar a servir o website antigo, se necessário.
- Fazer a cópia ou sincronização final dos dados, garantindo que alterações recentes não ficam apenas no servidor anterior.
- Ativar o novo destino, ajustando DNS ou a configuração do proxy/CDN e confirmando HTTPS, cache e regras de acesso.
- Testar as operações essenciais no novo servidor e acompanhar erros, formulários, integrações e tráfego nos dois ambientes.
- Desativar o alojamento anterior apenas depois de confirmar a transição, preservando as cópias necessárias à recuperação.
Atenção especial às lojas WooCommerce
Numa loja ativa, as encomendas, os pagamentos, o stock e os dados dos clientes podem mudar continuamente. Imagine que é feita uma cópia às 10h e o domínio passa para o novo servidor às 15h: as encomendas recebidas nesse intervalo não estarão necessariamente na cópia inicial.
Consoante a arquitetura, pode ser necessária uma janela de manutenção, uma sincronização final ou um mecanismo que impeça que os dois ambientes recebam encomendas em simultâneo. Também é indispensável verificar os pagamentos, as notificações automáticas e as tarefas agendadas. Restaurar uma base de dados antiga sobre uma loja que já recebeu encomendas novas pode eliminar dados recentes.
Este cuidado aplica-se, em escala diferente, a qualquer website com registos, reservas, formulários ou outros dados que continuem a ser alterados durante a migração.
O que confirmar depois da migração
A validação deve incluir o funcionamento real, e não apenas a abertura da página inicial.
| Área | Verificações principais |
|---|---|
| Website e WordPress | Páginas, menus, imagens, ligações, autenticação, painel de administração, edição e tarefas agendadas. |
| SEO | Respostas 404, redirecionamentos, URLs canónicas, sitemap XML, robots.txt, noindex e dados do Search Console. |
| Formulários e email | Envios bem-sucedidos, receção efetiva, notificações, SMTP/API e caixas de correio, se migradas. |
| WooCommerce | Carrinho, finalização da compra, pagamentos em ambiente apropriado, encomendas, stock e mensagens automáticas. |
| Serviços externos | APIs, webhooks, CRM, faturação, CDN, certificados, regras de segurança e ferramentas de análise. |
Ao verificar a medição de contactos, compras e outras ações importantes, confirme também que os códigos e as integrações de análise continuam ativos. Nas lojas WooCommerce, os testes têm de contemplar o circuito completo da encomenda, e não apenas o catálogo.
Acompanhe os registos de erros e a utilização dos servidores antigo e novo durante a transição. Uma eventual reversão deve considerar os dados entretanto criados: regressar simplesmente a uma cópia antiga nem sempre é seguro.
Conclusão
Uma migração WordPress fiável começa por definir exatamente o que vai mudar e termina apenas quando o website e os serviços associados estão validados. Manter URLs quando não precisam de mudar, preparar o DNS e o HTTPS, proteger os dados recentes e testar o email são decisões que reduzem riscos reais.
O objetivo não é prometer uma mudança sem qualquer interrupção, mas controlar a transição e preservar a continuidade do negócio.
