{"id":838,"date":"2026-09-17T18:04:45","date_gmt":"2026-09-17T18:04:45","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/clonar-site-wordpress-para-outro-servidor-sem-erro-de-url\/"},"modified":"2026-09-17T18:04:46","modified_gmt":"2026-09-17T18:04:46","slug":"clonar-site-wordpress-para-outro-servidor-sem-erro-de-url","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/hospedagem\/clonar-site-wordpress-para-outro-servidor-sem-erro-de-url\/","title":{"rendered":"Clonar site WordPress para outro servidor sem erro de URL"},"content":{"rendered":"

Voc\u00ea clonou o site, abriu o dom\u00ednio novo e a home carregou. S\u00f3 que ao tentar entrar no \/wp-admin<\/code>, o navegador te joga de volta para o endere\u00e7o antigo. Ou pior: o layout aparece quebrado, imagens somem e o Elementor n\u00e3o carrega. Quem tenta clonar site WordPress para outro servidor sem ajustar a URL no banco de dados cai nesse cen\u00e1rio quase sempre.<\/p>\n

A boa not\u00edcia \u00e9 que o problema tem causa conhecida e corre\u00e7\u00e3o direta. A parte que pega muita gente \u00e9 outra: a troca de URL no banco resolve o endere\u00e7o, mas n\u00e3o resolve dados serializados guardados por plugins e widgets. \u00c9 a\u00ed que o clone parece pronto e n\u00e3o est\u00e1.<\/p>\n

Por que o site abre no destino mas o painel volta para o dom\u00ednio antigo<\/h2>\n

O WordPress guarda o endere\u00e7o do site em dois lugares principais: a tabela wp_options<\/code>, nas chaves siteurl<\/code> e home<\/code>, e o arquivo wp-config.php<\/code>, quando h\u00e1 constantes definidas. Se o banco foi copiado do servidor antigo, ele chega com as URLs antigas intactas.<\/p>\n

Quando voc\u00ea acessa o dom\u00ednio novo, o WordPress l\u00ea siteurl<\/code> no banco, v\u00ea o endere\u00e7o antigo e redireciona. O front-end \u00e0s vezes escapa porque o tema ou um plugin for\u00e7a o dom\u00ednio atual, mas o painel n\u00e3o perdoa: ele sempre respeita o valor do banco.<\/p>\n

Por isso a ordem importa. Antes de qualquer ajuste, confirme que o DNS do dom\u00ednio novo j\u00e1 aponta para o servidor de destino. Se voc\u00ea mexer no banco antes do DNS propagar, o site pode ficar inacess\u00edvel nos dois endere\u00e7os ao mesmo tempo.<\/p>\n

O que a troca de URL no banco resolve e o que ela n\u00e3o resolve<\/h2>\n

Trocar siteurl<\/code> e home<\/code> resolve o redirecionamento do painel e a maior parte dos links internos gerados pelo WordPress. Resolve tamb\u00e9m menus, permalinks e chamadas de m\u00eddia feitas pelo core.<\/p>\n

N\u00e3o resolve dados serializados. Muitos plugins e widgets salvam configura\u00e7\u00f5es em um formato que guarda o tamanho da string junto com o conte\u00fado. Se voc\u00ea trocar https:\/\/antigo.com<\/code> por https:\/\/novo.com<\/code> com um UPDATE<\/code> 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.<\/p>\n

Na pr\u00e1tica, \u00e9 isso que separa um clone que funciona de um clone que d\u00e1 dor de cabe\u00e7a tr\u00eas dias depois. A troca simples serve para o essencial; a substitui\u00e7\u00e3o segura, que recalcula os tamanhos, serve para o resto.<\/p>\n

Como identificar dados serializados quebrados<\/h3>\n

Depois do clone, abra o site novo e percorra:<\/p>\n

    \n
  1. Widgets em Apar\u00eancia \u2192 Widgets<\/strong>. Campos vazios ou sumidos indicam serializa\u00e7\u00e3o quebrada.<\/li>\n
  2. Plugins de p\u00e1gina como Elementor, Beaver Builder ou WPBakery. Abra um template e veja se o conte\u00fado carrega.<\/li>\n
  3. Op\u00e7\u00f5es de tema em Apar\u00eancia \u2192 Personalizar<\/strong>. Cores, logo e rodap\u00e9 costumam guardar URL antiga.<\/li>\n
  4. Formul\u00e1rios, e-commerces e plugins de SEO. Cada um tem sua pr\u00f3pria tabela com URLs gravadas.<\/li>\n<\/ol>\n

    Se algo estiver vazio, n\u00e3o tente recolar o conte\u00fado \u00e0 m\u00e3o antes de corrigir o banco. Voc\u00ea vai perder tempo e ainda pode sobrescrever dado bom.<\/p>\n

    Como clonar site WordPress para outro servidor: tr\u00eas caminhos<\/h2>\n

    A escolha do m\u00e9todo depende de quantos sites voc\u00ea vai migrar e do acesso que voc\u00ea tem no servidor de origem e no de destino.<\/p>\n\n\n\n\n\n\n\n
    M\u00e9todo<\/th>\nQuando usar<\/th>\nLimite pr\u00e1tico<\/th>\n<\/tr>\n<\/thead>\n
    Painel da hospedagem<\/td>\nUm site, hospedagens compat\u00edveis, sem SSH<\/td>\nDepende das ferramentas do provedor<\/td>\n<\/tr>\n
    Plugin de migra\u00e7\u00e3o<\/td>\nUm ou poucos sites, sem acesso a terminal<\/td>\nPode travar em sites grandes ou com muitos plugins<\/td>\n<\/tr>\n
    Linha de comando<\/td>\nV\u00e1rios sites, acesso SSH nos dois lados<\/td>\nExige familiaridade com wp-cli<\/code> e mysqldump<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    M\u00e9todo 1: painel da hospedagem<\/h3>\n

    Muitos provedores oferecem clonagem entre contas ou ambientes. Voc\u00ea aponta a origem e o destino, e a ferramenta copia arquivos e banco. \u00c9 o caminho mais r\u00e1pido quando funciona, mas costuma deixar a URL antiga no banco. Depois do clone, voc\u00ea ainda precisa ajustar siteurl<\/code> e home<\/code>.<\/p>\n

    Antes de come\u00e7ar, confirme se o destino tem PHP e MySQL em vers\u00f5es compat\u00edveis com o site original. Um clone que chega em PHP mais antigo pode at\u00e9 abrir, mas plugins modernos v\u00e3o reclamar. Se aparecer erro 500 logo depois, o caminho \u00e9 diagnosticar sem derrubar o site, come\u00e7ando pelos logs de erro do WordPress<\/a>.<\/p>\n

    M\u00e9todo 2: plugin de migra\u00e7\u00e3o<\/h3>\n

    Plugins de migra\u00e7\u00e3o empacotam arquivos e banco e fazem a substitui\u00e7\u00e3o de URL no destino. A vantagem \u00e9 n\u00e3o precisar de SSH. A desvantagem \u00e9 que, em sites grandes, o processo pode estourar o tempo m\u00e1ximo de execu\u00e7\u00e3o do PHP ou o limite de mem\u00f3ria.<\/p>\n

    Se voc\u00ea for por esse caminho, fa\u00e7a um backup completo antes. E n\u00e3o confie cegamente na substitui\u00e7\u00e3o autom\u00e1tica: depois do clone, verifique os mesmos pontos da lista de serializa\u00e7\u00e3o acima. Plugins de migra\u00e7\u00e3o costumam acertar o core e errar em dados de terceiros.<\/p>\n

    M\u00e9todo 3: linha de comando<\/h3>\n

    Para quem tem SSH nos dois servidores, o caminho \u00e9 o mais control\u00e1vel e o mais indicado quando voc\u00ea vai clonar WordPress em lote. O fluxo b\u00e1sico:<\/p>\n

      \n
    1. No servidor antigo, exporte o banco: wp db export backup.sql<\/code>.<\/li>\n
    2. Copie os arquivos com rsync<\/code> ou scp<\/code> para o destino.<\/li>\n
    3. No destino, importe o banco: wp db import backup.sql<\/code>.<\/li>\n
    4. Ajuste as URLs: wp option update home 'https:\/\/novo.com'<\/code> e wp option update siteurl 'https:\/\/novo.com'<\/code>.<\/li>\n
    5. Rode a substitui\u00e7\u00e3o segura: wp search-replace 'https:\/\/antigo.com' 'https:\/\/novo.com' --all-tables --precise<\/code>.<\/li>\n<\/ol>\n

      A flag --precise<\/code> faz o wp-cli<\/code> recalcular os tamanhos dos dados serializados. Sem ela, a substitui\u00e7\u00e3o \u00e9 r\u00e1pida, mas quebra o que precisa de ajuste de tamanho. A flag --all-tables<\/code> garante que tabelas de plugins tamb\u00e9m sejam varridas.<\/p>\n

      Se voc\u00ea administra v\u00e1rios sites, esse \u00e9 o \u00fanico m\u00e9todo 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\u00f3ximo.<\/p>\n

      Ordem de verifica\u00e7\u00e3o depois do clone<\/h2>\n

      Terminada a c\u00f3pia, siga esta sequ\u00eancia. Ela evita retrabalho e mostra cedo se algo saiu errado.<\/p>\n

        \n
      1. Confirme que o DNS do dom\u00ednio novo aponta para o servidor de destino.<\/li>\n
      2. Acesse o front-end e veja se a home carrega sem redirecionar.<\/li>\n
      3. Entre no \/wp-admin<\/code>. Se voltar para o dom\u00ednio antigo, o problema est\u00e1 em siteurl<\/code> ou home<\/code>.<\/li>\n
      4. Rode a substitui\u00e7\u00e3o segura em todas as tabelas.<\/li>\n
      5. Percorra widgets, templates de p\u00e1gina e op\u00e7\u00f5es de tema.<\/li>\n
      6. Confira o certificado SSL e force HTTPS. Se aparecer aviso de conte\u00fado misto, veja como corrigir mixed content no WordPress<\/a>.<\/li>\n
      7. Teste formul\u00e1rios, checkout e login de usu\u00e1rios.<\/li>\n
      8. Confira se o robots.txt<\/code> n\u00e3o est\u00e1 bloqueando o site novo por engano.<\/li>\n<\/ol>\n

        Esse \u00faltimo item \u00e9 mais comum do que parece: muitos ambientes de teste v\u00eam com bloqueio de indexa\u00e7\u00e3o, e o site vai ao ar com o bloqueio ativo. Se o clone \u00e9 para produ\u00e7\u00e3o, revise isso antes de divulgar o endere\u00e7o. Para entender o impacto, vale revisar a import\u00e2ncia do SEO para quem administra sites WordPress<\/a>.<\/p>\n

        Quando N\u00c3O usar cada m\u00e9todo<\/h2>\n

        O painel da hospedagem n\u00e3o serve quando origem e destino s\u00e3o provedores diferentes sem integra\u00e7\u00e3o. Nesse caso, voc\u00ea perde tempo tentando e acaba refazendo na m\u00e3o.<\/p>\n

        O plugin de migra\u00e7\u00e3o n\u00e3o \u00e9 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 \u00e9 pior que n\u00e3o ter come\u00e7ado.<\/p>\n

        A linha de comando n\u00e3o serve para quem n\u00e3o tem SSH ou n\u00e3o se sente seguro com terminal. Um search-replace<\/code> mal parametrizado pode trocar strings que n\u00e3o deveriam ser trocadas, inclusive em campos de conte\u00fado editorial. Se voc\u00ea n\u00e3o tem certeza do que est\u00e1 fazendo, fa\u00e7a backup e teste em um ambiente isolado antes.<\/p>\n

        Tamb\u00e9m n\u00e3o clone por cima de um site em produ\u00e7\u00e3o sem backup. Se o destino j\u00e1 tem conte\u00fado, a substitui\u00e7\u00e3o pode misturar dados dos dois sites.<\/p>\n

        Erros comuns ao clonar site WordPress<\/h2>\n