Lista de verificação pós-migração do WordPress: Guia para SSL, DNS e problemas de e-mail

Principais conclusões

• SSL e conteúdo misto: Utiliza a pesquisa e substituição da base de dados para uma correção permanente em vez de depender de plug-ins temporários.
• Estratégia de DNS: Reduzir o TTL antes da migração, monitorizar as ferramentas de propagação e testar através do teu ficheiro de anfitriões antes de entrar em funcionamento.
• Fiabilidade do correio eletrónico: Verifica os registos MX após as actualizações do DNS. Usa SMTP em vez de PHP mail() e adiciona registos SPF/DKIM.
• Envia código: Os pushes apenas de ficheiros são mais seguros. Os pushes de banco de dados correm o risco de sobrescrever dados vivos – sempre faz backup e tem um plano de rollback.

A tua migração para o WordPress foi bem sucedida… ou não?

Os ficheiros transferidos. A base de dados importada. O teu site carrega no URL temporário. Mas agora os visitantes estão a receber avisos de segurança. Os teus formulários de contacto não estão a enviar e-mails. E estás a olhar para as definições de DNS a pensar se configuraste tudo corretamente.

Isto parece-te familiar?

A maioria dos guias de migração não te diz que a transferência real de ficheiros é apenas o primeiro passo. Depois da migração, as coisas tornam-se realmente difíceis. Tens de configurar corretamente os certificados SSL, gerir a propagação do DNS sem causar tempo de inatividade e corrigir o correio eletrónico que misteriosamente deixou de funcionar.

Ao longo dos anos, os clientes têm partilhado connosco os seus problemas de configuração pós-migração. Estas três áreas (SSL, DNS e e-mail) são as que causam mais confusão e pedidos de suporte. Mas não te preocupes, estamos a ajudar-te a perceber como podes voltar ao caminho certo.

Este guia concentra-se exclusivamente nas 24-72 horas após a conclusão da migração. Iremos abordar a configuração e a resolução de problemas de SSL, a gestão de propagação de DNS, as estratégias de restauro de e-mail e os fluxos de trabalho de preparação para produção seguros. Pensa nisto como o teu companheiro técnico para aqueles primeiros dias críticos em que estás a preparar o teu site migrado para a produção.

Vamos começar com a questão que afecta quase todas as migrações: Configuração SSL.

Porque é que o meu certificado SSL não funciona após a migração?

As migrações não transferem certificados SSL. Estás a começar de novo no teu novo alojamento WordPress, mesmo que o teu site anterior tenha uma configuração HTTPS funcional, porque são específicos do servidor.

As pessoas são apanhadas desprevenidas. “Mas o meu site tinha SSL!” é uma queixa comum. De facto, tinha. Esse certificado foi instalado e confirmado no teu servidor anterior.

Estás a mover os ficheiros e a base de dados do teu sítio Web, mas os certificados SSL não são transferidos automaticamente. Tens de instalar um novo certificado no teu novo anfitrião, quer se trate de um serviço gerido ou de um VPS. Tal como uma fechadura de porta física, o teu novo servidor tem de ser configurado para utilizar a chave privada do teu certificado SSL.

Enfrentarás desafios diferentes consoante o teu cenário:

• Migração de HTTP para HTTPS: O primeiro SSL requer a atualização de todos os URLs internos.
• Site HTTPS existente: Reinstala o SSL e corrige problemas de conteúdo misto.
• Mudança de domínio: Um novo domínio requer um novo certificado e uma transferência de URL.

Estás pronto para mudar todos os teus sites WordPress para um alojamento melhor?

Executa migrações ilimitadas com o plugin Cloudways Migrator e desfruta de um alojamento WordPress rápido, seguro e escalável.

TESTE AGORA

Instalando certificados SSL em seu host Cloudways

Os certificados SSL (https://) são praticamente uma caraterística não negociável de um site para segurança e credibilidade da marca. Na Cloudways, esse processo é rápido e geralmente gratuito.

A Cloudways oferece um Let’s Encrypt SSL gratuito com 1 clique e um SSL personalizado que tenhas comprado noutro local.

O que fazes depois de instalares um certificado SSL?

Há duas tarefas importantes a fazer na secção do certificado SSL da lista de verificação pós-migração:

1. Ativar a renovação automática (para Let’s Encrypt):
   • Verás agora as informações do teu certificado no mesmo ecrã do Certificado SSL.
   • Certifica-te de que o interrutor Renovação automática está ligado. A cada 90 dias, os certificados Let’s Encrypt expiram. Com esse serviço, a Cloudways pode renová-los automaticamente para que seu site nunca fique inativo.
2. Força o redireccionamento HTTPS:
   • Tens de te certificar de que todos os que visitam o teu sítio são enviados para a versão segura de https://.
   • Vai a Definições da aplicação no menu Gestão de aplicações.
   • Clica no botão de alternância na secção REDIRECÇÃO DE HTTPS para o ativar.

Estás a enfrentar o erro Git SSL após a migração do WordPress?

Lê o nosso guia para o corrigir.

Verifica agora

Como é que corrijo os “Avisos de Conteúdo Misto” no WordPress depois de instalar o SSL?

Acabaste de instalar o SSL, mudaste o interrutor para HTTPS e agora estás a olhar para um ícone de aviso irritante em vez do cadeado verde que esperavas. A consola do teu browser? Está a dar erros de conteúdo misto a torto e a direito.

Acredita em mim, isto deixa toda a gente louca quando configuram o SSL pela primeira vez. O culpado são normalmente aqueles antigos links HTTP enterrados na tua base de dados do WordPress: ainda estão a apontar para as versões não seguras das tuas imagens, scripts e folhas de estilo. Quando a tua nova e brilhante página HTTPS tenta carregar estes recursos HTTP, os browsers basicamente passam-se e assinalam-na como um risco de segurança.

Detetar conteúdos mistos:

Abre o Chrome ou o Firefox e visita a tua página problemática. Clica com o botão direito do rato em qualquer lugar (qualquer lugar serve) e clica em “Inspecionar” ou “Inspecionar elemento”. Clica no separador Consola e verás avisos que se parecem com:

 

Conteúdo misto: A página em ‘https://yourdomain.com’ foi carregada por HTTPS, mas solicitou uma imagem insegura ‘http://yourdomain.com/image.jpg’

 

Essa é a tua arma fumegante. Mostra-te exatamente quais os ficheiros que estão a causar problemas.

Livra-te de vez dos conteúdos mistos:

Já experimentei praticamente todos os métodos que existem, e aqui estão as três abordagens que realmente funcionam:

1. Pesquisa e substituição de bases de dados (Recomendado)

Este aborda o problema na sua origem, convertendo todos os URLs HTTP para HTTPS na própria base de dados.

Pega no plugin “Better Search Replace”. Faz o seguinte:

• Vai a Ferramentas → Melhor pesquisa Substituir
• No campo de pesquisa: http://yourdomain.com
• No campo de substituição: https://yourdomain.com
• Escolhe todas as tabelas (no mínimo, pega em wp_posts, wp_postmeta e wp_options)
• Assinala sempre, SEMPRE, a opção “Run as dry run” primeiro: isto permite-te ver o que vai mudar
• Se tudo parecer bem, desmarca o funcionamento em seco e puxa o gatilho

Avisa-nos: Faz uma cópia de segurança da tua base de dados antes de tocares em qualquer coisa. A sério. Aprendi isto da maneira mais difícil. Queres ter essa rede de segurança se as coisas correrem mal.

2. Solução de plug-in (correção rápida)

O “Really Simple SSL” pode trocar automaticamente HTTP por HTTPS à medida que as tuas páginas carregam. Faz o trabalho, mas vou ser sincero, está a tapar as fendas. O plugin não corrige realmente esses URLs na tua base de dados; apenas os intercepta e reescreve em tempo real, o que significa que o teu servidor está a fazer trabalho extra sempre que alguém visita o teu site.

Normalmente recomendo isto quando os utilizadores precisam que o HTTPS funcione ontem e voltaremos mais tarde para uma limpeza adequada da base de dados.

3. Constantes manuais do wp-config.php

Coloca estas duas linhas no teu ficheiro wp-config.php (coloca-as acima da linha “stop editing”):

define('FORCE_SSL_ADMIN', true);

define('FORCE_SSL_LOGIN', true);

No entanto, é bom avisar que isto apenas protege as tuas áreas de administração e de login. Os teus problemas de conteúdo misto do front-end continuarão a existir, mas pelo menos o teu painel de administração fica bloqueado.

Como posso solucionar erros comuns de SSL?

Problema: “Certificado não confiável” ou “Certificado inválido”

O que está a acontecer: Nove em cada dez vezes, ou é um problema de configuração ou estás a utilizar um certificado auto-assinado

A solução: Obtém um certificado assinado por uma CA válida. Let’s Encrypt e Sectigo são escolhas sólidas. Os browsers detestam certificados auto-assinados e vão sempre queixar-se deles. Com o Let’s Encrypt, por vezes basta reinstalar o certificado para resolver o problema.

Problema: “NET::ERR_CERT_COMMON_NAME_INVALID”

O que está a acontecer: O teu certificado e o teu domínio não coincidem

A solução: Normalmente, isto significa que tens SSL em “exemplo.com”, mas as pessoas estão a clicar em“www.example.com”(ou vice-versa). A maioria dos instaladores de certificados lida com ambas as versões automaticamente, mas verifica se o teu cobre todas as variações do teu domínio. Os utilizadores do Cloudflare devem verificar se o seu modo SSL é “Completo” ou “Completo (Estrito)”. A definição “Flexível” causa todo o tipo de dores de cabeça.

Problema: Loops de redireccionamento

O que está a acontecer: Tens redireccionamentos HTTPS a lutar entre si em locais diferentes

A solução: Abre o teu ficheiro .htaccess e conta quantas regras de redireccionamento vês. Os redireccionamentos ao nível do servidor e os plug-ins que forçam o HTTPS muitas vezes pisam os pés uns dos outros. Tenta desativar temporariamente o teu plugin SSL. Se o loop desaparecer, encontraste o culpado. E não te esqueças de verificar se a definição “Usar sempre HTTPS” do Cloudflare está activada, pois adora entrar em conflito com os redireccionamentos do servidor.

Problema: a área de administração permanece HTTP mesmo com HTTPS ativado

O que está a acontecer: As tuas definições de URL do WordPress estão erradas

A solução: Vai a Definições → Geral e certifica-te de que tanto o “Endereço do WordPress (URL)” como o “Endereço do site (URL)” começam por https://. Se não conseguires aceder à administração, adiciona estas linhas ao wp-config.php como solução alternativa:

define('WP_HOME', 'https://yourdomain.com');

define('WP_SITEURL', 'https://yourdomain.com');

Lista de verificação do DNS pós-migração

Toda a gente te diz que “a propagação do DNS demora 24-48 horas”, certo?

Claro que isso não está errado. Mas essa afirmação generalizada confundiu mais pessoas do que ajudou. Faz-te imaginar uma onda lenta a rastejar pela Internet, actualizando os servidores um a um. O que está realmente a acontecer é muito mais interessante. Assim que o perceberes, podes trabalhar com ele em vez de ficares à espera, sem fazer nada.

O que é a propagação de DNS e quanto tempo demora realmente?

A questão é a seguinte: a propagação do DNS não acontece de uma só vez em todo o lado. Existem milhares de servidores DNS em todo o mundo e cada um deles decide quando obter novas informações sobre o teu domínio. E todos eles seguem as regras definidas pelas definições de TTL (Time To Live) do teu domínio.

Imagina isto: Um servidor DNS em Tóquio tem o teu endereço IP anterior. Vai continuar a dar-te esse endereço antigo até que o seu período TTL se esgote. O teu TTL está definido para 86400 segundos? Esse servidor nem sequer pensará em procurar actualizações durante um dia inteiro. Mas e se o baixaste para 300 segundos? Agora estamos a chegar a algum lado; irá atualizar a cada cinco minutos.

A verdadeira linha do tempo:

– Usa um TTL alto (como 86400 segundos): Estás a olhar para aquela janela completa de 24-48 horas antes de todos estarem na mesma página

– Usa um TTL baixo (digamos, 300 segundos): A maioria das pessoas verá o teu novo site dentro de 30-60 minutos

– Variação geográfica: Os utilizadores de diferentes regiões vêem versões diferentes porque consultam servidores DNS diferentes

É por isso que algumas pessoas vêem o teu novo sítio imediatamente, enquanto outras ainda vêem o antigo. Estão a pedir a servidores DNS diferentes, que são actualizados em horários diferentes.

Otimização de DNS antes da migração (o que devias ter feito)

Num mundo perfeito, eis o que farias: Cerca de 48 a 72 horas antes de ativar a migração, baixavas o TTL do teu domínio para 300 segundos. Basicamente, estás a dizer aos servidores DNS em todo o lado para começarem a verificar com mais frequência.

Agora, porquê o aviso prévio? Porque – e este é o ponto crucial – a própria alteração do TTL tem de se propagar primeiro. Se baixares o teu TTL cinco minutos antes da migração, a maioria dos servidores DNS ainda está a funcionar com aquele velho e preguiçoso calendário de atualização. Eles nem sequer saberão que mudaste as regras durante mais um ou dois dias.

Não fizeste este trabalho de preparação? Junta-te ao clube! A maioria das pessoas falha este passo. Não é o fim do mundo. As tuas alterações ao DNS vão demorar o seu tempo. Infelizmente, não existe um botão mágico para acelerar as coisas depois do facto, mas há formas de contornar a situação.

Qual é a diferença entre atualizar um registo A e alterar os servidores de nomes?

Quando redireccionas o teu DNS para o teu novo fornecedor de alojamento, estás essencialmente a atualizar as coordenadas GPS da Internet para o teu site. Tens duas formas de lidar com isto:

Abordagem 1: Uma atualização do registo

Esta é a abordagem cirúrgica. Só mudas para onde vai o tráfego do teu site, deixando tudo o resto (registos de e-mail, códigos de verificação, etc.) exatamente onde está.

Primeiro, procura o endereço IP do teu novo anfitrião. Depois, entra nas tuas definições de DNS e actualiza-as em conformidade:

– Tipo de registo: A

– Anfitrião/Nome: @ (representa o teu domínio de raiz)

– Valor/Pontos para: O endereço IP do teu novo servidor

– TTL: 300 (5 minutos) inicialmente

Adiciona um segundo registo A para www:

– Tipo de registo: A

– Anfitrião/Nome: www

– Valor/pontos para: O mesmo endereço IP

– TTL: 300

Abordagem 2: Alteração do servidor de nomes

Basicamente, isto entrega as chaves DNS ao teu novo fornecedor de alojamento. Vais entrar nas definições do teu fornecedor de serviços de registo de domínios e trocar os servidores de nomes pelo que o teu novo anfitrião te fornecer.

Opta por esta via se quiseres que a tua empresa de alojamento trate de todo o trabalho pesado do DNS, ou se eles o exigirem diretamente para que a sua configuração funcione. O senão é que isto limpa a tua lista de DNS. Todos os registos personalizados desaparecem.

Por isso, terás de reconstruir manualmente todos os registos MX para e-mail, registos SPF para autenticação e qualquer outra magia de DNS personalizada que tenhas feito. Não é divertido, mas às vezes é necessário.

Se a Cloudflare está a tratar das tuas tarefas de DNS e CDN, aqui está o manual:

1. Entra no painel de gestão de DNS do Cloudflare e troca esse registo A para o endereço IP do teu novo anfitrião
2. Vês aquele pequeno ícone de nuvem? Mantém-no cinzento (é o modo apenas de DNS) enquanto estás a testar as coisas
3. Depois de teres experimentado e confirmado que tudo está a funcionar corretamente, vira a nuvem para laranja para ativar o modo proxy

Vê porque é que isto é importante: Se fores diretamente para o modo de nuvem laranja, a cache do Cloudflare pode continuar a servir o teu site antigo, mesmo depois de as actualizações de DNS terem sido feitas. Já vi pessoas baterem com a cabeça na parede perguntando por que nada está mudando quando é apenas o Cloudflare fazendo seu trabalho de cache.

Testa primeiro com a nuvem cinzenta. Certifica-te de que o teu novo servidor real está a responder corretamente e deixa o Cloudflare fazer a sua magia de proxy quando souberes que tudo está bem.

Teste antes da propagação de DNS (o método do ficheiro Hosts)

Eis uma dica profissional que poupa muita ansiedade: podes pré-visualizar o teu site no novo alojamento antes de actualizares o DNS, substituindo temporariamente o DNS no teu computador.

Isto utiliza o ficheiro “hosts” do teu computador, que funciona como uma substituição do DNS local:

No Windows:

1. Abre o Bloco de Notas como Administrador (clique com o botão direito do rato → Executar como administrador)
2. Abre o bloco de notas: C:\Windows\System32\drivers\etc\hosts
3. Adiciona na parte inferior:

123.45.67.89 teudomínio.com

123.45.67.89 www.yourdomain.com

4. Guarda o ficheiro

No Mac/Linux:

1. Terminal aberto
2. Escreve: `sudo nano /etc/hosts`
3. Adiciona as mesmas linhas na parte inferior
4. Pressiona Ctrl+X, depois Y, depois Enter para salvar

Substitui 123.45.67.89 pelo endereço IP do teu novo anfitrião.

O teu computador utilizará esta substituição em vez do DNS quando acederes a yourdomain.com no teu browser. Podes ver exatamente o que vai acontecer quando o DNS se propagar, o que te permite testar tudo antes de tornares a mudança pública.

Importante: Remove estas linhas do teu ficheiro hosts depois de testares, ou verás sempre o novo servidor mesmo que o DNS aponte para outro local.

Quais são as melhores ferramentas para monitorizar a propagação de DNS em tempo real?

Depois de actualizares o DNS, queres saber quando foi propagado. Estas ferramentas mostram-te o estado atual:

WhatsMyDNS.net

Mostra a resolução de DNS de dezenas de locais em todo o mundo com um mapa visual. Introduz o teu domínio e o tipo de registo (A) e verás que regiões estão a ver o teu novo IP em comparação com o antigo.

Verificador de DNS

Semelhante ao WhatsMyDNS, mas com informações mais detalhadas sobre o servidor. Útil para diagnosticar problemas de propagação regional.

O que deves considerar “completo”:

Não precisas de 100% de propagação global para entrar em funcionamento. Quando vires 75-80% dos locais testados a devolverem o teu novo IP, a maioria dos utilizadores verá o teu novo site. Os restantes servidores recuperarão o atraso em poucas horas.

Como é que limpo a minha cache de DNS local?

O teu computador também armazena o DNS em cache. Mesmo que o DNS se tenha propagado globalmente, podes continuar a ver o site antigo porque o teu computador não o actualizou. Limpa a tua cache de DNS local:

– Windows: Abre o Prompt de Comando e executa `ipconfig /flushdns`

– Mac: Abre o Terminal e executa `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`

– Linux: Varia de acordo com a distribuição; normalmente `sudo systemd-resolve –flush-caches`

Depois de limpar a cache, testa numa janela anónima/privada do browser para evitar problemas com a cache do browser.

 

Resolução de problemas de DNS após a migração para o WordPress

O teu problema: “Continua a ver o site antigo após 48 horas”

Primeiro, verifica se os teus registos DNS estão realmente actualizados:

1. Vai a WhatsMyDNS.net
2. Introduz o teu domínio
3. Verifica se ALGUMAS localizações mostram o teu novo IP

Se nenhum local mostrar o teu novo IP, o teu DNS não foi atualizado na fonte. Inicia sessão no teu fornecedor de serviços de registo de domínios ou de DNS e verifica se as alterações foram guardadas corretamente. Por vezes, as alterações ficam presas no estado “pendente”.

Se alguns locais mostrarem um novo IP, mas não todos, trata-se de uma propagação normal. Espera um pouco mais.

Solução: Se todos os locais mostrarem o novo IP, mas continuares a ver o site antigo, o problema é a cache local (cache do browser, cache DNS local ou cache do ISP). Limpa todas as caches e testa a partir de uma rede diferente (como dados móveis em vez de WiFi).

 

Problema: “Alguns utilizadores vêem o novo site, outros vêem o antigo”

Isto é completamente normal durante a propagação. Diferentes utilizadores consultam diferentes servidores DNS com diferentes horários de atualização. Não há nada que possas fazer para forçar uma propagação mais rápida – tens apenas de esperar que os ISPs de todo o mundo actualizem as suas caches.

Solução: Considera colocar um aviso de manutenção temporária no teu site antigo que diga “Estamos em processo de migração. Se estás a ver esta mensagem, limpa a tua cache e volta em breve.”

 

Problema: “Registo A atualizado, mas faltam registos MX – e-mail quebrado”

Isto acontece quando alteras os servidores de nomes em vez de actualizares apenas os registos A. As alterações de servidores de nomes apagam todos os registos DNS, incluindo os registos MX para e-mail.

Solução: Entra no teu gestor de DNS e volta a adicionar manualmente todos os registos MX, registos SPF e quaisquer outras entradas de DNS que se tenham perdido. (Abordaremos o DNS específico de email na próxima secção).

 

Problema: “O Cloudflare mostra o IP antigo mesmo após a atualização”

Se estiveres a utilizar o Cloudflare, verifica duas coisas:

1. Actualizaste o registo A na gestão de DNS da Cloudflare (e não apenas no teu registo)?
2. A cache do Cloudflare está a servir o site antigo?

Solução: Actualiza o registo A no painel de controlo do Cloudflare e, em seguida, limpa a cache do Cloudflare (Caching → Configuração → Limpar tudo). Desativa também temporariamente o proxy (nuvem cinzenta do registo DNS) para testar se o Cloudflare é o problema.

Lista de verificação pós-migração: Os e-mails deixaram de funcionar

A quebra de e-mail após a migração para o WordPress apanha as pessoas de surpresa. “Mas eu não mexi nas minhas definições de e-mail!”, dizem-nos. E isso é verdade, mas a migração afecta o e-mail de formas que não são imediatamente óbvias.

Porque é que os e-mails do WordPress não estão a funcionar quando apenas migrei o meu site?

Eis o que se passa: Os registos DNS, especialmente os registos MX, informam outros servidores de correio eletrónico para onde enviar o correio eletrónico do teu domínio. Quando moves o teu site e alteras o DNS, a forma como fazes as modificações pode alterar a forma como o correio eletrónico é encaminhado.

Três cenários comuns de correio eletrónico após a migração:

Cenário 1: Correio eletrónico alojado no antigo anfitrião Web

É possível que a tua antiga empresa de alojamento controlasse as tuas contas de e-mail. Se for esse o caso, esses servidores de e-mail não estão ligados ao teu site. Acabaste de dizer à Internet que o teudomínio.com tem um novo endereço IP quando alteraste o DNS para o apontar para o novo alojamento. No entanto, não lhe disseste para onde enviar o e-mail.

Resultado: O e-mail não é entregue ou é enviado na direção errada.

Cenário 2: Correio eletrónico de terceiros (Google Workspace, Microsoft 365)

É bom que o teu correio eletrónico seja armazenado separadamente pelo Google ou pela Microsoft. O correio eletrónico deve continuar a funcionar mesmo que o anfitrião do teu sítio Web mude. Os servidores de nomes, e não apenas os registos A, podem ter-se perdido quando mudaste de servidor de nomes. Estes registos apontam para os servidores de correio da Google e da Microsoft.

O resultado: Os outros servidores não conseguem lidar com as mensagens de correio eletrónico recebidas porque não sabem para onde as enviar.

Cenário 3: E-mails transaccionais do WordPress (formulários de contacto, redefinições de palavra-passe)

O envio de e-mails no WordPress é feito por padrão com o método mail() do PHP. Muitos sites não permitem esta função por razões de segurança ou impõem-lhe muitos limites para impedir o spam. É possível que o teu antigo alojamento te permita fazê-lo, mas o teu novo alojamento pode não o permitir.

Resultado: O teu site não consegue enviar e-mails. A reposição de palavras-passe, a obtenção de notificações de formulários de contacto e as confirmações de venda do WooCommerce falham sem qualquer ruído.

Como posso diagnosticar que parte do meu e-mail está avariada?

Antes de poderes corrigir o correio eletrónico, tens de perceber o que está avariado. Executa estes testes:

Teste 1: Repor a tua palavra-passe do WordPress

Na página de início de sessão do teu site (wp-login.php), clica em “Esqueceste-te da tua palavra-passe?” Introduz o teu endereço de e-mail e pede uma reposição. Aguarda alguns minutos. Recebeste o e-mail? Vê também na tua pasta de spam.

Teste 2: Envia um formulário de contacto

Envia uma mensagem de teste utilizando o formulário de contacto do teu site. Chegou lá? Se tiveres o WooCommerce ou outro plugin de comércio eletrónico, faz uma encomenda de teste e procura e-mails a confirmar a encomenda.

Teste 3: Testa um e-mail de fora da empresa

Envia um e-mail de uma conta externa (como o Gmail ou o Outlook) para o e-mail do teu domínio ([email protected]). Chegou lá? Verifica o e-mail recebido, que depende do registo MX.

Como ler os resultados:

– Nada funciona: Parece que os registos DNS ou MX estão em falta ou errados.

– Os e-mails que chegam funcionam, mas os e-mails do WordPress não: Problema com a configuração de e-mail do WordPress (SMTP necessário)

– Vai tudo para o spam: Não existem registos de autenticação (SPF/DKIM)

Agora vamos corrigir cada problema.

Como posso corrigir o meu e-mail verificando ou adicionando registos MX?

Os registos MX (Mail Exchanger) informam os outros servidores de e-mail para onde enviar o e-mail do teu domínio. Se estes estiverem errados ou ausentes, o correio eletrónico não será enviado.

Encontrar os teus registos MX corretos:

Os registos MX de que precisas dependem do local onde o teu e-mail está alojado:

Para o Google Workspace:

Prioridade 1: ASPMX.L.GOOGLE.COM

Prioridade 5: ALT1.ASPMX.L.GOOGLE.COM

Prioridade 5: ALT2.ASPMX.L.GOOGLE.COM

Prioridade 10: ALT3.ASPMX.L.GOOGLE.COM

Prioridade 10: ALT4.ASPMX.L.GOOGLE.COM

Para o Microsoft 365:

Prioridade 0: o teu domínio-com.mail.protection.outlook.com

(Substitui “yourdomain-com” pelo teu domínio, utilizando hífenes em vez de pontos)

Para o e-mail do teu antigo anfitrião:

Entra no painel de controlo do teu antigo anfitrião ANTES de cancelares a conta. Encontra a secção de e-mail ou DNS e copia todos os registos MX exatamente como são apresentados. Terás de os recriar no teu novo fornecedor de DNS.

Adiciona registos MX:

O local onde os adicionas depende da tua configuração de DNS:

– Se simplesmente mudaste os registos A: Adiciona registos MX onde geres o DNS, que é normalmente o teu fornecedor de serviços de registo de domínios (como Namecheap, GoDaddy, etc.).

– Se mudaste de servidores de nomes para o teu novo anfitrião: Adiciona registos MX às definições de DNS do teu novo anfitrião.

– Se usares o Cloudflare: Adiciona registos MX às definições de DNS do Cloudflare.

O formato é normalmente o seguinte:

– Tipo de registo: MX

– Nome/Host: @ (ou deixa em branco – representa o teu domínio)

– Prioridade: 1, 5 ou 10 (números mais baixos = maior prioridade)

– Valor/pontos para: O endereço do servidor de correio eletrónico

Verifica:

Depois de adicionar registos MX, espera 10-30 minutos e, em seguida, verifica com a MXToolbox:

1. Vai a mxtoolbox.com/SuperTool.aspx
2. Introduz o teu domínio
3. Seleciona “MX Lookup” no menu pendente
4. Verifica se aparecem todos os registos MX esperados

Depois de verificado, testa o correio eletrónico recebido enviando uma mensagem do Gmail ou de outro serviço externo.

Configuração SMTP do WordPress: A solução fiável

O WordPress ainda requer um meio de ENVIAR e-mail, mesmo quando os registros MX estão configurados corretamente para lidar com e-mails recebidos. A função mail() do PHP não é muito fiável porque os servidores de correio eletrónico que a recebem normalmente bloqueiam-na, desactivam-na ou marcam-na como spam.

SMTP (Simple Mail Transfer Protocol) é a resposta. O WordPress envia mensagens diretamente para um servidor de correio em vez de utilizar a função de correio do servidor. Isto é verificado, fiável e torna a entrega muito mais fácil.

Configura o SMTP com o plugin WP Mail SMTP:

1. Obtém o plugin “WP Mail SMTP” e ativa-o (a versão gratuita funciona perfeitamente).
2. Clica em Definições no WP Mail SMTP
3. Escreve o teu “From Email”, que pode ser [email protected].
4. Escreve o nome do teu site ou da tua empresa no campo “Nome do remetente”.

Agora tens de escolher um serviço de correio. Tens várias opções:

Opção 1: Utilizar o teu fornecedor de e-mail existente

Se tiveres o Google Workspace ou o Microsoft 365, podes utilizar os seus servidores SMTP:

Definições do Google Workspace:

– Anfitrião SMTP: smtp.gmail.com

– Encriptação: TLS

– Porta SMTP: 587

– Autenticação: LIGADO

– Nome de utilizador: [email protected]

– Palavra-passe: A tua palavra-passe específica da aplicação (NÃO a tua palavra-passe normal do Google – tens de a gerar nas definições de segurança do Google)

Definições do Microsoft 365:

– Anfitrião SMTP: smtp.office365.com

– Encriptação: STARTTLS

– Porta SMTP: 587

– Autenticação: LIGADO

– Nome de utilizador: [email protected]

– Palavra-passe: A tua palavra-passe da Microsoft

Opção 2: Utiliza um serviço de correio eletrónico transacional

Para um maior volume ou melhor capacidade de entrega, considera os serviços de correio eletrónico transacional dedicados:

– SendGrid: O nível gratuito inclui 100 e-mails/dia

– Mailgun: O nível gratuito inclui 5.000 e-mails/mês

– SendLayer: Especialista em e-mail transacional WordPress

– Amazon SES: Muito acessível para grandes volumes ($0,10 por 1.000 e-mails)

Estes serviços fornecem credenciais SMTP nos seus painéis de controlo. Introduz essas credenciais na opção “Outro SMTP” do WP Mail SMTP.

Testa:

Após a configuração, o WP Mail SMTP tem uma funcionalidade de teste incorporada:

1. Vai para WP Mail SMTP → Teste de e-mail
2. Introduz o teu endereço de e-mail
3. Clica em “Enviar e-mail”
4. Verifica se chegou (incluindo a pasta de spam)

Se o teste for bem-sucedido, os teus e-mails do WordPress estão a funcionar. Se falhar, verifica a mensagem de erro. Normalmente, indica se se trata de um problema de autenticação, bloqueio de porta ou erro de configuração.

Problemas comuns de SMTP:

“Não é possível autenticar“: Verifica novamente o nome de utilizador e a palavra-passe. Além disso, a Google tornou-se mais exigente. Atualmente, precisas de uma palavra-passe específica da aplicação e não do teu início de sessão normal.

“A ligação expirou na porta 587“: O teu anfitrião pode estar a brincar ao polícia de trânsito com o SMTP de saída. Muda da porta 587 com TLS para a porta 465 com SSL e vê se isso ajuda. Ainda estás preso? Está na altura de contactar o suporte do teu alojamento. Alguns hosts bloqueiam deliberadamente o SMTP para manter os spammers afastados.

“Falha na verificação do certificado“: As definições SSL do teu anfitrião estão provavelmente desactualizadas. Podes desativar a verificação SSL nas definições SMTP do WP Mail como solução alternativa, embora essa seja definitivamente a opção mais arriscada.

Registos SPF e DKIM: Evitando a pasta de spam

Se o teu e-mail está a funcionar bem, mas tudo continua a ir parar ao spam, é muito frustrante. É provável que te faltem os registos de autenticação para manteres as tuas mensagens credíveis.

O SPF (Sender Policy Framework) funciona como um endereço de retorno num envelope postal. Indica aos servidores de correio receptores quais os endereços IP que têm permissão para enviar correio do seu domínio. Sem esta verificação, os servidores tratam as tuas mensagens como pacotes sem identificação que aparecem à porta de alguém. Sem dúvida que és suspeito.

O DKIM (DomainKeys Identified Mail) vai mais longe. Pensa nisto como um selo de cera numa carta antiga. Adiciona uma assinatura digital aos seus e-mails enviados, provando que o conteúdo não foi adulterado durante o trânsito. Tal como um escriba de um castelo notaria um selo quebrado num envelope, os servidores podem detetar se alguém alterou a tua mensagem ao longo do caminho.

Ambos melhoram significativamente a capacidade de entrega. Vamos configurá-los.

Configurar registos SPF:

O SPF é adicionado como um registo TXT no teu DNS. O formato depende de quem envia o correio eletrónico para o teu domínio:

Se estiveres a utilizar o Google Workspace:

v=spf1 include:_spf.google.com ~all

Se estiveres a utilizar o Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Se utilizares o servidor de correio do teu anfitrião Web:

v=spf1 mx ~todos

(Isto diz que “os servidores listados nos registos MX podem enviar correio eletrónico”)

Se utiliza vários serviços de correio eletrónico:

Podes encadear vários includes:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Adiciona isto como um registo TXT no teu DNS:

• Tipo de registo: TXT
• Nome/Host: @ (ou deixa em branco)
• Valor: A tua cadeia de registo SPF

Tem apenas UM registo SPF. Se já tiveres um, edita-o para adicionar mais includes em vez de criares um segundo registo SPF (vários registos SPF causam falhas de validação).

Configura o DKIM:

O DKIM é mais complexo porque envolve a geração de um par de chaves. O processo varia consoante o fornecedor:

Google Workspace:

1. Consola de administração → Apps → Google Workspace → Gmail → Autenticar e-mail
2. Clica em “Gerar novo registo”
3. Copia os valores do registo TXT

Microsoft 365:

1. Centro de administração → Definições → Domínios
2. Seleciona o teu domínio → Registos DNS
3. Procura os registos DKIM e ativa-os

SendGrid/Mailgun: Estes serviços geram registos DKIM nos seus painéis de controlo em definições de autenticação ou DNS.

Adiciona o registo DKIM ao teu DNS como um registo TXT com o nome específico fornecido (normalmente algo como default._domainkey.yourdomain.com).

Verifica:

Utiliza estas ferramentas para verificar a autenticação do teu e-mail:

• MXToolbox: Verifica os registos SPF com a sua ferramenta SPF Record Lookup
• Testador de correio eletrónico.com: Envia uma mensagem de correio eletrónico para o endereço que te forneçam e, em seguida, vê a tua pontuação (procura obter 8/10 ou mais)
• Validador DKIM: Procura por “DKIM validator” e utiliza qualquer uma das ferramentas gratuitas

Quando o SPF e o DKIM estiverem corretamente configurados, a capacidade de entrega do teu correio eletrónico deverá melhorar drasticamente.

Lista de verificação pós-migração: Move com segurança um site WordPress da fase de preparação para a produção

Para os usuários do Cloudways, todo esse processo é gerenciado em um ambiente de preparação dedicado, com um clique, projetado para evitar os problemas exatos de perda de dados descritos aqui.

O ambiente de preparação do Cloudways 1-Click

Em vez de fazeres envios manuais de ficheiros ou fusões complexas de bases de dados, o fluxo de trabalho é..:

1. Cria a preparação: No painel Gerenciamento de aplicativos, clica em “Criar teste”. A Cloudways clona todo o seu site ativo (arquivos e banco de dados) em um aplicativo de teste separado e protegido por senha.
2. Testa e desenvolve: Podes fazer quaisquer alterações com segurança (atualizar plugins, modificar temas, testar novo código) neste site de teste sem afetar o teu site de produção ao vivo.

1. Empurra ou puxa dados: Quando estiveres pronto para implementar, o separador Staging Management dá-te duas opções simples:
   • Empurra: Move as suas alterações (pode escolher ficheiros, base de dados ou ambos) de Staging para Production (Live).
   • Pull: Esta opção actualiza o teu site de teste com os dados mais recentes da produção (útil se o teu site ativo tiver novas encomendas ou comentários que precises de testar).

A funcionalidade push lida automaticamente com a pesquisa e substituição de URLs da base de dados e dá-te um controlo granular, permitindo-te mover ficheiros sem alterar a tua base de dados ativa (com as suas novas encomendas ou comentários).

Porque é que a encenação para produção precisa de uma estratégia própria

Estás a utilizar um ambiente de preparação para testar antes de entrar em funcionamento? Estás a lidar com uma besta totalmente diferente de uma migração básica. Não se trata de mover um site que está parado. Estás a tentar sincronizar alterações entre dois ambientes que estão vivos e a funcionar, e é provável que as pessoas estejam a utilizar ativamente o teu site de produção enquanto o fazes.

O principal risco: escrever por cima dos dados de produção. Se estiveste a testar na fase de preparação durante uma semana enquanto os clientes faziam encomendas ou os utilizadores comentavam no teu site de produção, um “push to production” descuidado pode apagar todos os novos dados.

Esta secção é sobre sincronização selectiva – mover apenas o que pretendia alterar enquanto preserva os dados de produção que foram criados ou modificados enquanto trabalhava no staging.

Compreender o que deve (e o que não deve) ser impulsionado

Antes de passares qualquer coisa da fase de preparação para a produção, pára e pensa: Alguma coisa mudou no site ativo desde que o clonaste para a fase de preparação?

Se nada tiver mudado (talvez seja um site novo ou o tenhas bloqueado em modo de manutenção), avança e envia tudo. Estás livre.

Mas e se as coisas estiverem a acontecer na produção enquanto estás a trabalhar? Agora tens de escolher cuidadosamente.

É seguro empurrar a partir da preparação:

• Ficheiros de temas (wp-content/themes/yourtheme/)
• Ficheiros de plugins (wp-content/plugins/)
• Novos carregamentos de média que adicionaste no staging
• Conteúdo da base de dados que criaste (novos posts, páginas)
• Definições de plug-ins/tema (se as tiveres reconfigurado)

É perigoso escrever por cima na produção:

• Contas e perfis de utilizadores (tabelas wp_users, wp_usermeta)
• Comentários sobre o conteúdo da produção (tabela wp_comments)
• Encomendas WooCommerce efectuadas na produção (várias tabelas woocommerce_*)
• Envios de formulários de contacto recebidos na produção
• Qualquer conteúdo criado por visitantes/clientes durante o teu trabalho de preparação

A matriz de decisão crítica:

Tipo de local	Podes empurrar com segurança	Tem de ser seletivo
Blogue (sem comércio eletrónico)	Base de dados completa se não tiverem sido publicadas novas mensagens na produção	Exclui novos conteúdos de produção
Loja WooCommerce	Apenas ficheiros de temas/plugins	NUNCA envia a base de dados (apagaria as encomendas)
Site de membros	Ficheiros de tema/plugin	Exclui contas de utilizador e dados de membros

Métodos de preparação para a produção

Método 1: Transferência apenas de ficheiros

Esta é a abordagem mais segura para sites activos. Envia ficheiros de temas e plug-ins, mas deixa a base de dados de produção intocada.

Utiliza o FTP/SFTP:

1. Liga-te à fase de teste e à fase de produção através de FTP
2. Descarrega a pasta de temas actualizada a partir da fase de teste
3. Faz o upload para a produção, substituindo os ficheiros de temas existentes
4. Repete a operação para todas as pastas de plug-ins atualizadas
5. Testa o site de produção

Isto funciona muito bem para:

• Actualizações de temas
• Actualizações de plugins
• Adição de novos ficheiros multimédia

Isto não funciona para:

• Novos posts/páginas criados na fase de teste
• Alterações nas definições do plugin
• Actualizações de menu
• Alterações na colocação de widgets

Porquê? Porque esses dados estão na base de dados e não em ficheiros.

Método 2: Envio seletivo da base de dados (avançado)

Se necessitares de fazer alterações à base de dados sem substituir os dados de produção, terás de exportar tabelas específicas.

Ferramentas para isso:

• WP Migrate DB Pro (plugin) – Permite-te selecionar tabelas específicas para enviar
• phpMyAdmin – Exportação/importação manual de tabelas específicas
• WP-CLI – Operações de linha de comando na base de dados

Exemplo de fluxo de trabalho:

1. Identifica as tabelas da base de dados que contêm as tuas alterações (normalmente wp_posts para o conteúdo, wp_options para as definições)
2. Exporta essas tabelas específicas da fase de preparação
3. Faz uma cópia de segurança da base de dados de produção (cópia de segurança completa!)
4. Importa as tabelas específicas para a produção
5. Executa a pesquisa-substituição se os URLs forem diferentes entre a preparação/produção

Importante: Para isso, tens de compreender a estrutura da base de dados do WordPress. A tabela wp_posts contém posts/páginas, mas também menus de navegação. A tabela wp_options contém definições, mas também plug-ins activos. Importar as tabelas erradas pode danificar o teu site.

Método 3: Push assistido por plug-in

Alguns fornecedores de alojamento gerido e plug-ins de migração oferecem a funcionalidade de envio de preparação para produção com salvaguardas incorporadas:

• WP Staging Pro – Oferece um envio seletivo com filtragem de tabelas
• BlogVault – Inclui gestão de staging com opções de fusão
• Funcionalidades de alojamento gerido – Cloudways, WP Engine, Kinsta, Flywheel incluem staging push

Estas ferramentas fornecem GUIs para selecionar o que empurrar, reduzindo o risco de erros.

Lista de verificação pós-impressão

Depois de transferir as alterações da fase de preparação para a produção, testa imediatamente estas funções:

Testes de função crítica:

• Consegues entrar na área de administração?
• As páginas do frontend são carregadas sem erros?
• Os formulários são enviados corretamente?
• A pesquisa funciona?
• Para eCommerce: Os utilizadores podem adicionar ao carrinho de compras e chegar ao checkout?
• Para associações: Os utilizadores conseguem iniciar sessão?

Verificações técnicas:

• Limpa todas as caches(cache do servidor, cache de plugins, cache do browser)
• Verifica se existem erros de PHP (ativa temporariamente o WP_DEBUG, se necessário)
• Verifica se o SSL ainda funciona
• Testa em dispositivos móveis
• Verifica os tempos de carregamento da página (não deve ser dramaticamente mais lento)

Verificação do conteúdo:

• As mensagens/páginas recentes continuam a aparecer
• Os menus de navegação funcionam corretamente
• Os widgets aparecem nos locais corretos
• As imagens são carregadas corretamente

Problemas comuns após o lançamento:

Erros 404 em todas as páginas, exceto na página inicial:

A tua estrutura de permalink precisa de ser actualizada. Vai a Definições → Permalinks e clica em “Guardar alterações” sem alterar nada. Isto gera novamente o ficheiro .htaccess (ou a configuração do nginx) com as regras de reescrita adequadas.

Ecrã branco da morte:

Normalmente é um conflito de plugins ou um erro fatal de PHP. Acede ao teu site através de FTP e renomeia a pasta wp-content/plugins/ para wp-content/plugins-disabled/. Isto desactiva todos os plugins. Se o site carregar, sabes que se trata de um problema de plug-in. Volta a mudar o nome da pasta e, em seguida, isola o plug-in problemático, desactivando um de cada vez.

Erro de ligação à base de dados:

Se escreveste acidentalmente o wp-config.php durante o push, podes ter quebrado as credenciais da base de dados. Volta a introduzir o nome da base de dados, o nome de utilizador e a palavra-passe corretos em wp-config.php.

Imagens partidas ou em falta:

Verifica a pasta wp-content/uploads/. Se enviaste os uploads de teste para a produção, podes ter substituído as imagens de produção. Restaura a partir do backup.

Qual é um plano de reversão seguro se o meu impulso de preparação falhar?

Tem sempre uma estratégia de reversão antes de passar da fase de preparação para a produção.

Antes de empurrares:

1. Faz uma cópia de segurança completa da produção (ficheiros e base de dados)
2. Documenta exatamente o que estás a mudar
3. Anota a hora atual para saberes qual a cópia de segurança a restaurar, se necessário
4. Verifica se podes aceder à produção através de FTP/SSH, caso a área de administração fique inacessível

Se alguma coisa se partir:

Não entres em pânico. Aqui está o teu processo de recuperação:

1. Para problemas menores: Corrige no local se souberes o problema exato
2. Para problemas graves: Restaura imediatamente a partir do backup pré-push
3. Não consegues aceder à administração: Utiliza o FTP para mudar o nome da pasta do plugin/tema recentemente atualizado para o desativar
4. Ecrã branco em todo o lado: Substitui todos os ficheiros do backup via FTP
5. Problemas com a base de dados: Importar a tua cópia de segurança da base de dados pré-push através do phpMyAdmin

O segredo é ter esse backup antes do push. Sem ela, a recuperação de um mau envio é extremamente difícil.

A lista completa de verificação pós-migração de 72 horas

Vamos juntar tudo num plano de ação baseado numa linha de tempo. Isto tem em conta a realidade da propagação do DNS e dá prioridade às tarefas que evitam o tempo de inatividade ou a perda de dados.

Queres migrar o teu site WordPress com apenas alguns cliques?

Usa o plugin gratuito Cloudways WordPress Migrator para migrações ilimitadas e sem complicações, com suporte especializado 24 horas por dia, 7 dias por semana.

Migra gratuitamente

Quais são os erros mais críticos a evitar após a migração do WordPress?

Estes erros podem causar grandes problemas:

Não canceles imediatamente o alojamento antigo – Espera pelo menos 7-30 dias para garantir que tudo está estável

Não sal tes o backup pré-push – Precisas de um ponto de restauro se o staging push correr mal

Não ignores os avisos de SSL – “Vou resolver isto mais tarde” muitas vezes significa nunca, e os utilizadores não vão confiar no teu site

Não te esqueças de limpar TODAS as caches – cache do servidor, cache de plugins, cache CDN e cache do browser

Não faças alterações à base de dados durante a propagação do DNS – Espera até que a propagação esteja concluída para as principais operações da base de dados

Conclusão

A conclusão de uma lista de verificação pós-migração não é um trabalho muito atraente, mas é o que separa um site que funciona de um que realmente funciona.

SSL, DNS e e-mail – estes três são os que te darão mais dores de cabeça após qualquer migração. No entanto, as boas notícias são que, depois de compreenderes o que está a acontecer nos bastidores, todos eles seguem padrões previsíveis que podes resolver.

As primeiras 72 horas após a migração? É nessa altura que tudo se avaria. O DNS está a propagar-se, o SSL dá erros, os e-mails são devolvidos e descobres aquilo de que te esqueceste. Segue a lista de verificação hora a hora e resiste à vontade de te apressares.

Acede aos nossos recursos de migração de Web sites passo a passo

• Quanto custa migrar um site em 2026?
• Como migrar o teu site WordPress sem tempo de inatividade?
• Vê os melhores plug-ins de migração do WordPress para 2026

O que deves fazer agora:

Estás a migrar? Começa de forma simples. Confirma que o teu site carrega, põe o SSL a funcionar e depois verifica o DNS. Faz uma coisa de cada vez.

Estás a planear com antecedência? Marca este guia como favorito e reduz o TTL do DNS agora. Esse único movimento poupar-te-á horas de tempo de propagação mais tarde.

Estás a lidar com uma crise? Passa diretamente para o que está avariado. Resolução de problemas de SSL, problemas de DNS ou correcções de e-mail. Cada secção leva-te rapidamente do problema à solução.

Olha, as migrações já são suficientemente stressantes sem a confusão pós-migração. Pelo menos agora já sabes o que vem aí.