Moveu um site para um novo domínio e ele está em baixo. Ou abre, mas sem estilos. Ou o painel de administração não o deixa entrar. Qualquer pessoa que tenha migrado manualmente o WordPress já passou por este momento: a base de dados ainda se lembra do URL antigo e o site tenta desesperadamente carregar recursos de um endereço que já não existe.

Quatro consultas SQL no phpMyAdmin resolvem o problema em cinco minutos. Sem plugins, sem WP-CLI, sem pânico. Abaixo encontra um guia passo a passo, desde encontrar o domínio atual até à verificação final. Com ajustes para prefixos de tabela não padrão, HTTPS e dados serializados.

💡 Visão geral rápida:

• Encontre o domínio atual na tabela wp_options: os campos siteurl e home
• Execute quatro consultas UPDATE no separador SQL do phpMyAdmin
• Redefina a palavra-passe do administrador através da wp_users se o painel de administração não o deixar entrar
• Guarde os permalinks nas definições do WordPress para restaurar os estilos
• Para lojas e multisites, utilize o Better Search Replace ou o WP-CLI: um REPLACE normal corrompe arrays serializados

Por onde começar: encontre o domínio atual na base de dados

Antes de substituir, certifique-se de que sabe qual o domínio atualmente definido para o site. Isto poupará tempo se o site já foi movido antes e um terceiro URL «intermédio» possa ter ficado na base de dados.

Abra o phpMyAdmin, selecione a base de dados do site e localize a tabela wp_options. Esta contém duas linhas: siteurl (o endereço do WordPress) e home (o endereço do site). Estes são os valores que vamos alterar primeiro.

Se o prefixo da tabela não for padrão (por exemplo, mysite_ em vez de wp_), procure a tabela mysite_options. Pode encontrar o prefixo no ficheiro wp-config.php: a variável $table_prefix.

Quatro consultas SQL para uma substituição completa do domínio

Execute cada consulta uma a uma no separador «SQL» do phpMyAdmin. Antes de as executar, certifique-se de fazer uma cópia de segurança da base de dados: exportar através do phpMyAdmin demora um minuto e evita erros irreversíveis.

Substitua http://www.oldurl por http://www.newurl em todas as consultas abaixo. Se o site funcionar com HTTPS, utilize https:// em ambos os endereços.

1. Atualizar HOME e SITEURL

Isto altera os dois endereços principais na wp_options. Sem este passo, o site simplesmente não abre no novo domínio; o WordPress continuará a tentar redirecionar para o antigo.

1
UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldurl', 'http://www.newurl') WHERE option_name = 'home' OR option_name = 'siteurl';

2. Atualizar os GUIDs dos artigos

O campo guid na wp_posts armazena o identificador permanente de cada artigo. Substituí-lo não é crítico para o funcionamento do site; o WordPress não usa o GUID para encaminhamento. Mas se as pessoas leem o seu site através de leitores RSS, a integridade dos GUIDs é importante: URLs antigos no feed levarão a links quebrados.

1
UPDATE wp_posts SET guid = replace(guid, 'http://www.oldurl', 'http://www.newurl');

3. Atualizar o conteúdo dos artigos

A consulta mais extensa. O post_content contém o texto de todas as páginas e artigos, incluindo imagens incorporadas e links internos. Depois de executar esta consulta, todas as imagens no conteúdo serão carregadas a partir do novo domínio.

1
UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldurl', 'http://www.newurl');

4. Atualizar campos meta

Campos personalizados, definições de plugins, dados de temas: tudo isto fica armazenado na wp_postmeta. Salte esta consulta e terá links quebrados em locais aparentemente inesperados: o logótipo no rodapé, o fundo no personalizador, o URL no seu plugin de SEO.

1
UPDATE wp_postmeta SET meta_value = replace(meta_value, 'http://www.oldurl', 'http://www.newurl');

Depois de executar as quatro consultas, abra o site no novo domínio. Se tudo foi feito corretamente, não deverá haver problemas. Mas, por vezes, acontece outra coisa: uma mensagem de «Erro ao estabelecer ligação à base de dados» ou a página abre sem estilos.

A primeira coisa de que precisa nesta situação é de acesso ao painel de administração.

Como aceder ao painel de administração se a palavra-passe foi perdida ou o site não o deixa entrar

O cliente não deixou a palavra-passe. Ou bloqueou-se a si próprio ao alterar o domínio e o /wp-admin atira-o para um redirecionamento infinito. Aqui estão duas formas de obter direitos de administrador diretamente através da base de dados.

Redefinir a palavra-passe do administrador através do phpMyAdmin

Abra a tabela wp_users (o seu prefixo pode ser diferente: mysite_users, etc.). Encontre o utilizador com direitos de administrador e clique em «Editar»:

Na linha user_pass, selecione a função MD5 no menu suspenso e introduza a nova palavra-passe no campo adjacente. Clique em «Executar»:

Nota: o WordPress moderno utiliza phpass (hashes bcrypt), não MD5. Mas quando introduz uma palavra-passe do WordPress, este verifica o hash em sequência: se a verificação bcrypt falhar, tenta a alternativa MD5 e, de imediato, refaz o hash da palavra-passe para o formato atual. É por isso que o MD5 via phpMyAdmin funciona como uma chave temporária.

Criar um administrador via PHP

Um método alternativo é adicionar um novo utilizador administrador de forma programática. O código é inserido no ficheiro functions.php do tema ativo ou através de um MU-plugin.

Adicione o seguinte ao functions.php do seu tema filho:

1
function sdstudio_add_admin_user() {
2
    $userdata = array(
3
        'user_login' => 'tempadmin',
4
        'user_pass'  => 'TempPass123!',
5
        'user_email' => '[email protected]',
6
        'role'       => 'administrator',
7
    );
8
    wp_insert_user( $userdata );
9
}
10
add_action( 'init', 'sdstudio_add_admin_user' );

A função wp_insert_user() cria um utilizador com os parâmetros fornecidos, e o hook init é executado em cada pedido ao WordPress. Basta abrir qualquer página do site uma vez e o utilizador é criado.

Depois de iniciar sessão no painel de administração, não se esqueça de apagar tanto a função do functions.php como o utilizador temporário que criou. Deixar o tempadmin com uma palavra-passe em texto simples é uma falha de segurança.

Corrigir imagens e estilos quebrados após a substituição do domínio

Tem acesso ao painel de administração, mas as imagens não carregam e o layout está quebrado. Em nove de cada dez casos, uma simples operação resolve.

Vá a "Definições" → "Links permanentes":

Não altere nada; basta clicar em "Guardar alterações":

O WordPress irá reconstruir a estrutura de URLs, atualizar a cache das regras de reescrita e limpar a cache de redirecionamento interno. Após isto, as imagens costumam voltar aos seus lugares.

Se isso não resultou, significa que o domínio antigo está incorporado em arrays serializados. Um REPLACE normal em SQL quebra-os: o comprimento da string num array serializado está codificado como um número, e substituir "dominio-antigo-longo.pt" por "novo-curto.io" altera esse comprimento, tornando o array ilegível. Instale o plugin gratuito Better Search Replace; este lida corretamente com a serialização e mostra quantas correspondências foram encontradas em cada tabela antes de substituir.

Para sites com WP-CLI, é ainda mais simples com um comando:

1
wp search-replace 'http://olddomain.ru' 'https://newdomain.io' --all-tables --dry-run

A flag --dry-run mostra primeiro o que será substituído sem fazer alterações. Quando estiver confiante, execute-o sem a flag. O search-replace do WP-CLI também lida com dados serializados e fá-lo mais rapidamente do que a interface web.

O vídeo abaixo demonstra todo o processo, desde o início de sessão no phpMyAdmin até à verificação do site após a substituição:

⁉️🤔 Perguntas frequentes

É obrigatório usar o phpMyAdmin para a substituição do domínio?

Não. Se o site ainda não foi migrado, o Duplicator ou o All-in-One WP Migration fazem a substituição automaticamente durante a implementação. Se o site já está no novo alojamento sem acesso de administrador, resta-lhe usar consultas SQL via phpMyAdmin, Adminer ou WP-CLI. Para a maioria dos webmasters, o phpMyAdmin é o método mais direto e controlado: vê cada operação em vez de confiar na caixa negra de um plugin.

O que devo fazer se o prefixo da tabela não for wp_?

Verifique o valor da constante $table_prefix no ficheiro wp-config.php. Normalmente é wp_, mas os alojamentos ou plugins de segurança como o Solid Security (antigo iThemes Security) por vezes alteram-no para algo aleatório. Em todas as consultas acima, substitua wp_ pelo seu prefixo (por exemplo, xyz123_options em vez de wp_options).

Porque é que o site abre sem estilos após a substituição?

O domínio antigo permanece nas configurações do tema, na cache ou na CDN. Reinicie os permalinks (instruções acima) e limpe a cache do seu plugin de caching. Se usar a Cloudflare ou outra CDN, invalide a cache no lado do fornecedor. Se isso não ajudou, execute o Better Search Replace: o URL antigo provavelmente está incorporado num array serializado theme_mods_*.

O site está em HTTPS, mas após a migração o certificado não funciona. O que devo fazer?

Certifique-se de que usou https:// (e não http://) em todas as consultas. Verifique se ambos os endereços nas definições do WordPress, após iniciar sessão no painel de administração, começam com https://. O certificado SSL em si é configurado no lado do alojamento, através do painel de controlo ou do Let's Encrypt gratuito. Este é um procedimento separado, não relacionado com a base de dados.

Posso substituir o domínio sem acesso ao phpMyAdmin?

Sim. WP-CLI: wp search-replace 'http://olddomain' 'http://newdomain' --all-tables. Apenas FTP: adicione as linhas define('WP_HOME','http://newdomain'); e define('WP_SITEURL','http://newdomain'); ao ficheiro wp-config.php. Isto substitui temporariamente os endereços e dá-lhe acesso de administrador. Após iniciar sessão, remova as linhas e guarde as definições através da interface.

Preciso de alterar o GUID no wp_posts ou posso ignorá-lo?

Não é necessário para o funcionamento do site. O WordPress não usa o GUID para encaminhamento, apenas para identificar publicações nos feeds RSS. Se as pessoas leem ativamente o seu site via RSS, a substituição faz sentido. Se não, pode ignorar a terceira das quatro consultas sem consequências.

Após substituir o domínio via SQL, algumas definições de plugins perderam-se. Porquê?

Plugins como WooCommerce, Advanced Custom Fields e sliders armazenam URLs em arrays serializados no wp_postmeta. Um REPLACE normal não tem em conta o contador de comprimento da string na serialização e quebra a estrutura. A solução é o Better Search Replace ou wp search-replace (eles desserializam o array, substituem a string e voltam a serializá-lo). Se já o quebrou, restaure a base de dados a partir do backup e repita a substituição com a ferramenta adequada.

O que fazer em casos complexos: lojas, multisites e bases de dados grandes

A substituição de domínio via SQL é um procedimento de cinco minutos se tiver acesso direto ao phpMyAdmin e um prefixo de tabela padrão. Mas há situações em que a substituição manual via REPLACE é genuinamente arriscada.

Lojas online em WooCommerce com centenas de milhares de encomendas. Redes multisite com dezenas de tabelas separadas para cada subsite. Sites onde os URLs estão codificados em arrays serializados (definições de temas, page builders, sliders). Nestes casos, um único REPLACE SQL pode danificar a estrutura de dados, e restaurar a base de dados a partir do backup levará mais tempo do que fazer uma substituição precisa à primeira.

O Better Search Replace ou o search-replace do WP-CLI lidam com a serialização; use-os. E se o tamanho da base de dados exceder um gigabyte e o custo de um erro for alto, uma hora de trabalho de um especialista em desenvolvimento custará menos do que restaurar uma loja cujo tempo de inatividade custa dinheiro.

Abordámos o tópico da migração de sites preservando o SEO e sem perder tráfego num guia separado. E se encontrar um erro específico após a substituição, escreva nos comentários e ajudaremos com o diagnóstico.