Você clonou o site, abriu o domínio novo e a home carregou. Só que ao tentar entrar no /wp-admin, o navegador te joga de volta para o endereço antigo. Ou pior: o layout aparece quebrado, imagens somem e o Elementor não carrega. Quem tenta clonar site WordPress para outro servidor sem ajustar a URL no banco de dados cai nesse cenário quase sempre.
A boa notícia é que o problema tem causa conhecida e correção direta. A parte que pega muita gente é outra: a troca de URL no banco resolve o endereço, mas não resolve dados serializados guardados por plugins e widgets. É aí que o clone parece pronto e não está.
Por que o site abre no destino mas o painel volta para o domínio antigo
O WordPress guarda o endereço do site em dois lugares principais: a tabela wp_options, nas chaves siteurl e home, e o arquivo wp-config.php, quando há constantes definidas. Se o banco foi copiado do servidor antigo, ele chega com as URLs antigas intactas.
Quando você acessa o domínio novo, o WordPress lê siteurl no banco, vê o endereço antigo e redireciona. O front-end às vezes escapa porque o tema ou um plugin força o domínio atual, mas o painel não perdoa: ele sempre respeita o valor do banco.
Por isso a ordem importa. Antes de qualquer ajuste, confirme que o DNS do domínio novo já aponta para o servidor de destino. Se você mexer no banco antes do DNS propagar, o site pode ficar inacessível nos dois endereços ao mesmo tempo.
O que a troca de URL no banco resolve e o que ela não resolve
Trocar siteurl e home resolve o redirecionamento do painel e a maior parte dos links internos gerados pelo WordPress. Resolve também menus, permalinks e chamadas de mídia feitas pelo core.
Não resolve dados serializados. Muitos plugins e widgets salvam configurações em um formato que guarda o tamanho da string junto com o conteúdo. Se você trocar https://antigo.com por https://novo.com com um UPDATE comum no banco, o tamanho declarado fica errado e o dado se corrompe. O resultado aparece como widget vazio, campo de plugin em branco ou erro silencioso.
Na prática, é isso que separa um clone que funciona de um clone que dá dor de cabeça três dias depois. A troca simples serve para o essencial; a substituição segura, que recalcula os tamanhos, serve para o resto.
Como identificar dados serializados quebrados
Depois do clone, abra o site novo e percorra:
- Widgets em Aparência → Widgets. Campos vazios ou sumidos indicam serialização quebrada.
- Plugins de página como Elementor, Beaver Builder ou WPBakery. Abra um template e veja se o conteúdo carrega.
- Opções de tema em Aparência → Personalizar. Cores, logo e rodapé costumam guardar URL antiga.
- Formulários, e-commerces e plugins de SEO. Cada um tem sua própria tabela com URLs gravadas.
Se algo estiver vazio, não tente recolar o conteúdo à mão antes de corrigir o banco. Você vai perder tempo e ainda pode sobrescrever dado bom.
Como clonar site WordPress para outro servidor: três caminhos
A escolha do método depende de quantos sites você vai migrar e do acesso que você tem no servidor de origem e no de destino.
| Método | Quando usar | Limite prático |
|---|---|---|
| Painel da hospedagem | Um site, hospedagens compatíveis, sem SSH | Depende das ferramentas do provedor |
| Plugin de migração | Um ou poucos sites, sem acesso a terminal | Pode travar em sites grandes ou com muitos plugins |
| Linha de comando | Vários sites, acesso SSH nos dois lados | Exige familiaridade com wp-cli e mysqldump |
Método 1: painel da hospedagem
Muitos provedores oferecem clonagem entre contas ou ambientes. Você aponta a origem e o destino, e a ferramenta copia arquivos e banco. É o caminho mais rápido quando funciona, mas costuma deixar a URL antiga no banco. Depois do clone, você ainda precisa ajustar siteurl e home.
Antes de começar, confirme se o destino tem PHP e MySQL em versões compatíveis com o site original. Um clone que chega em PHP mais antigo pode até abrir, mas plugins modernos vão reclamar. Se aparecer erro 500 logo depois, o caminho é diagnosticar sem derrubar o site, começando pelos logs de erro do WordPress.
Método 2: plugin de migração
Plugins de migração empacotam arquivos e banco e fazem a substituição de URL no destino. A vantagem é não precisar de SSH. A desvantagem é que, em sites grandes, o processo pode estourar o tempo máximo de execução do PHP ou o limite de memória.
Se você for por esse caminho, faça um backup completo antes. E não confie cegamente na substituição automática: depois do clone, verifique os mesmos pontos da lista de serialização acima. Plugins de migração costumam acertar o core e errar em dados de terceiros.
Método 3: linha de comando
Para quem tem SSH nos dois servidores, o caminho é o mais controlável e o mais indicado quando você vai clonar WordPress em lote. O fluxo básico:
- No servidor antigo, exporte o banco:
wp db export backup.sql. - Copie os arquivos com
rsyncouscppara o destino. - No destino, importe o banco:
wp db import backup.sql. - Ajuste as URLs:
wp option update home 'https://novo.com'ewp option update siteurl 'https://novo.com'. - Rode a substituição segura:
wp search-replace 'https://antigo.com' 'https://novo.com' --all-tables --precise.
A flag --precise faz o wp-cli recalcular os tamanhos dos dados serializados. Sem ela, a substituição é rápida, mas quebra o que precisa de ajuste de tamanho. A flag --all-tables garante que tabelas de plugins também sejam varridas.
Se você administra vários sites, esse é o único método que escala sem depender de cliques. Vale automatizar em script e rodar site por site, conferindo o resultado de cada um antes de passar para o próximo.
Ordem de verificação depois do clone
Terminada a cópia, siga esta sequência. Ela evita retrabalho e mostra cedo se algo saiu errado.
- Confirme que o DNS do domínio novo aponta para o servidor de destino.
- Acesse o front-end e veja se a home carrega sem redirecionar.
- Entre no
/wp-admin. Se voltar para o domínio antigo, o problema está emsiteurlouhome. - Rode a substituição segura em todas as tabelas.
- Percorra widgets, templates de página e opções de tema.
- Confira o certificado SSL e force HTTPS. Se aparecer aviso de conteúdo misto, veja como corrigir mixed content no WordPress.
- Teste formulários, checkout e login de usuários.
- Confira se o
robots.txtnão está bloqueando o site novo por engano.
Esse último item é mais comum do que parece: muitos ambientes de teste vêm com bloqueio de indexação, e o site vai ao ar com o bloqueio ativo. Se o clone é para produção, revise isso antes de divulgar o endereço. Para entender o impacto, vale revisar a importância do SEO para quem administra sites WordPress.
Quando NÃO usar cada método
O painel da hospedagem não serve quando origem e destino são provedores diferentes sem integração. Nesse caso, você perde tempo tentando e acaba refazendo na mão.
O plugin de migração não é boa escolha para sites com banco muito grande ou muitos plugins pesados. O processo pode estourar limites e deixar o clone pela metade, o que é pior que não ter começado.
A linha de comando não serve para quem não tem SSH ou não se sente seguro com terminal. Um search-replace mal parametrizado pode trocar strings que não deveriam ser trocadas, inclusive em campos de conteúdo editorial. Se você não tem certeza do que está fazendo, faça backup e teste em um ambiente isolado antes.
Também não clone por cima de um site em produção sem backup. Se o destino já tem conteúdo, a substituição pode misturar dados dos dois sites.
Erros comuns ao clonar site WordPress
- Trocar a URL só no
wp-config.phpe esquecer o banco. - Usar
UPDATEdireto no banco sem tratar serialização. - Esquecer de atualizar o arquivo
.htaccessquando há regras específicas do servidor antigo. - Deixar o certificado SSL para depois e publicar o site com aviso de segurança.
- Não revisar permissões de arquivo e pasta depois do
rsync. - Manter o site antigo no ar com o mesmo conteúdo, criando conteúdo duplicado.
Se depois do clone o site cair ou responder devagar, vale separar o que é servidor e o que é o próprio site antes de sair mexendo. O roteiro para isso está em site WordPress caiu: servidor ou o próprio site?.
Prevenção para quem clona com frequência
Quem migra um site por ano pode fazer tudo na mão. Quem migra vários por mês precisa de processo. Três hábitos resolvem boa parte do retrabalho:
- Padronize um checklist de verificação pós-clone e rode sempre na mesma ordem.
- Mantenha um script de
wp search-replacecom--precisee--all-tablespronto, para não improvisar sob pressão. - Registre as URLs antigas e novas de cada migração, para conferir depois se algo ficou para trás.
Quando o volume cresce, acompanhar cada site clonado individualmente deixa de ser viável. É aí que faz sentido centralizar a operação: o painel 100% WP reúne atualizações, backups e monitoramento de vários sites em um lugar só, o que ajuda a perceber cedo um clone que subiu com problema.
Se o clone envolve muitos sites, ambientes críticos ou prazos apertados, pode valer contratar quem faz isso com frequência. O serviço de hospedagem e migração cobre justamente esse tipo de operação.
Resumo do que resolve o erro de URL
Clonar site WordPress para outro servidor dá certo quando você trata três camadas: arquivos, banco e dados serializados. A troca de siteurl e home resolve o redirecionamento do painel. A substituição segura, com recálculo de tamanho, resolve widgets e plugins. A verificação pós-clone, na ordem certa, evita que o problema apareça só depois que o site já está no ar.
Se algo ainda parecer errado, revise a lista de erros comuns antes de refazer o clone inteiro. Na maioria dos casos, o problema está em um ponto específico que passou batido, não no processo todo.
