Como atualizar urls na base de dados WordPress ao mover o domínio?

Mover um site WordPress (por exemplo, de dev.site.com para site.com) parece simples: basta executar um “Localizar e Substituir” na base de dados, certo?

ERRADO.

Se tentar executar uma consulta SQL bruta como: UPDATE wp_options SET option_value = replace(option_value, 'antigo.pt', 'novo.pt')

…vai quebrar o seu site. Especificamente, perderá Widgets, Opções de Tema e a configuração de muitos plugins.

#Como alterar o URL do WordPress na base de dados (a forma segura)

Alterar o URL do WordPress na base de dados de forma segura resume-se a um único comando WP-CLI, executado depois de fazer uma cópia de segurança:

wp search-replace 'https://old.com' 'https://new.com' --all-tables --precise

O comando atualiza siteurl e home em wp_options, todos os URLs no conteúdo e nos metadados e, sobretudo, trata corretamente os dados serializados. Sem acesso à shell, a ordem de preferência é esta: um plugin que respeita a serialização (Better Search Replace), depois o phpMyAdmin apenas para as duas linhas de wp_options (siteurl e home), e nunca um REPLACE() SQL em bruto sobre todas as tabelas. O resto deste guia explica porque é que este último método quebra sites e percorre cada alternativa passo a passo.

#O erro comum: Simples “find & replace”

Muitos programadores (é até alguns fornecedores de alojamento) sugerem usar a função simples SQL REPLACE() para atualizar URLs. Esta abordagem parece lógica, mas é fundamentalmente falhada no ecossistema WordPress.

A Tentação:

-- Isto parece seguro, mas NÃO É
UPDATE wp_options 
SET option_value = REPLACE(option_value, 'https://antigo.pt', 'https://novo.pt');

O Que Acontece:

• Alguns URLs são atualizados corretamente.
• Dados serializados tornam-se corrompidos.
• Widgets desaparecem.
• Opções do tema reiniciam para o padrão.
• Configurações de plugins são perdidas.
• O site fica parcialmente quebrado.

Por Que Falha: O WordPress não armazena todos os dados como texto simples. Muitos dados são armazenados como dados PHP serializados, o que requer tratamento especial.

#Entender a serialização: O problema central

#O que é serialização?

O WordPress armazena estruturas de dados complexas (arrays, objetos) na base de dados como Strings Serializadas. A serialização converte estruturas PHP numa string que pode ser guardada na base de dados.

Exemplo de Dados Serializados:

// Array PHP Original
array(
    'home' => 'https://antigo.pt',
    'siteurl' => 'https://antigo.pt',
    'admin_email' => '[email protected]'
)

// String Serializada (guardada na DB)
a:3:{s:4:"home";s:17:"https://antigo.pt";s:7:"siteurl";s:17:"https://antigo.pt";s:11:"admin_email";s:17:"[email protected]";}

#Decompor a string serializada

Vamos descodificar s:17:"https://antigo.pt":

• s = string (cadeia de caracteres)
• 17 = comprimento da string (número de caracteres)
• "https://antigo.pt" = o valor

A Parte Crítica: O número 17 representa a contagem exata de caracteres da string "https://antigo.pt".

#O que acontece com substituição simples?

Original:

s:17:"https://antigo.pt"

Após SQL Replace Simples (antigo.pt -> novo-domínio.pt):

O Problema:

• O comprimento da string mudou de 17 para 23 caracteres.
• A serialização ainda diz s:17 (espera 17 caracteres).
• PHP tenta ler 17 caracteres: "https://novo-domin"
• Falta o final.
• Todo o array torna-se inválido.
• Os dados estão corrompidos.

Resultado: O WordPress não consegue ler as configurações ou widgets, por isso ignora-os ou reinicia-os.

#Onde estão os dados serializados?

#Locais comuns

1. Tabela wp_options:

• siteurl e home.
• Dados de Widgets (sidebars_widgets).
• Modificações de Tema (theme_mods_*).
• Opções de plugins.

2. Tabela wp_postmeta:

• Campos Personalizados (Custom Fields).
• Dados do ACF.
• Metadados de anexos.

#A solução: Ferramentas conscientes de serialização

Precisa de uma ferramenta que:

1. Dessencialize os dados (converta string de volta para array PHP).
2. Substitua o texto dentro da estrutura de dados.
3. Recalcule as contagens de caracteres.
4. Ressencialize os dados.
5. Atualize a base de dados.

#Método 1: Wp-CLI (recomendado)

A Forma Profissional: Se tiver acesso SSH, o WP-CLI e a melhor ferramenta.

Uso Básico:

wp search-replace 'https://antigo.pt' 'https://novo.pt' --all-tables

Opções Avançadas:

## DRY run (ver o que mudaria sem executar)
wp search-replace 'https://antigo.pt' 'https://novo.pt' --all-tables --dry-run

#Método 2: Plugin better search replace

Para utilizadores sem CLI: Se não tiver acesso SSH, use o plugin Better Search Replace.

Como Usar:

1. Instale o plugin.
2. Vá a Ferramentas > Better Search Replace.
3. Insira o URL antigo é o novo.
4. Selecioné as tabelas.
5. Importante: Marque “Run as dry run?” primeiro.
6. Clique em “Run Search/Replace”.

#Resumo

Em 2026, é essencial usar as ferramentas certas para migração.

• Nunca use SQL REPLACE simples.
• Nunca edite ficheiros SQL com editor de texto.
• Sempre use WP-CLI ou Better Search Replace.

Isto garante que os seus widgets e configurações complexas sobrevivam à mudança de domínio.

Veja os nossos serviços de desenvolvimento WordPress.