Como clonar um site WordPress localmente

Quando estás a começar a mexer a sério num site — em WordPress ou em qualquer outro sistema — tens de interiorizar uma regra básica antes de começar: não faças experiências em produção.

Por vários motivos:

1. Porque os resultados podem ser catastróficos se não sabes bem no que estás a mexer ou se não tens backup.
2. Porque, por causa do ponto anterior e enquanto restauras tudo, podes sofrer um pico de stress nada desejável.
3. E porque montar uma cópia local demora apenas meia hora e vais agradecer eternamente.

Repito:

Primeiro montas uma cópia local. Depois mexes. Não ao contrário.

Nestes dias em que estou a mudar a fundo o meu site, tive de o fazer, por isso aproveitei e criei este tutorial.

O meu site tinha vários anos de conteúdo, 250 posts, imagens acumuladas desde 2013 e tamanho suficiente para que Duplicator ficasse a meio duas vezes antes de funcionar.

Isso também está aqui. Falhas — e respetivas soluções — incluídas.

Para que serve ter um clone local do WordPress

Uma cópia local permite-te trabalhar no teu computador sem tocar no site real.

Útil para: testar plugins, mudar de tema, rever a base de dados, preparar uma migração, fazer uma auditoria técnica, instalar Polylang, modificar CSS ou partir coisas sem que Google, os teus utilizadores ou o teu cliente reparem.

No meu caso, o objetivo era duplo:

1. Mudar completamente o design, passando de um site de captação de leads para uma revista digital.
2. Preparar o site para tradução assistida por IA. Um desenvolvimento próprio com algum nível de risco, já que implica mexer em várias coisas ao mesmo tempo.

Em qualquer caso, o processo é o mesmo se quiseres recategorizar de forma automatizada, mudar de tema, adicionar um plugin grande tipo WooCommerce ou simplesmente ter um ambiente de testes antes de mexer em algo sério.

Ferramentas que usei

• LocalWP: para criar o ambiente WordPress local.
• Duplicator: para exportar o site de produção.
• cPanel: o painel de controlo do hosting para descarregar manualmente a pasta de imagens.
• WP-CLI: incluído no LocalWP, para corrigir opções internas do WordPress.

Tudo gratuito. 

Guia passo a passo para clonar o teu WordPress localmente

Agora que já conheces as ferramentas, vamos ao passo a passo, que é um pouco mais longo do que o habitual.

De qualquer forma, para teres uma ideia, em mais ou menos 30 minutos terás tudo pronto, dependendo dos problemas que aparecerem. Porque, se o teu site for pequeno e não der nenhum erro, é possível que o tenhas em menos de dez minutos.

Poucos investimentos são mais rentáveis do que este.

Passo 1: instalar o LocalWP

O LocalWP cria instalações WordPress locais sem teres de configurar Apache, MySQL e PHP à mão. Não precisas de XAMPP, nem de WAMP, nem de LAMP.

Instalas, crias um novo site e em dois minutos tens um WordPress limpo a funcionar no teu computador.

No meu caso chamei-lhe yg, por isso o LocalWP atribuiu-lhe o domínio local https://yg.local com este ambiente:

Campo	Valor
Servidor	nginx
PHP	8.2
Base de dados	MySQL
WordPress	Instalação limpa

Com isso é suficiente para começar.

Passo 2: verificar se o WordPress local abre

Antes de importar seja o que for, abre o site local e entra no painel:

• https://yg.local
• https://yg.local/wp-admin

Se carregar e conseguires entrar, o ambiente está pronto. Não instales nada ainda. Não mexas nas definições. Apenas confirma que funciona.

Passo 3: instalar o Duplicator no site real

Entra no WordPress de produção (não no local) e instala o Duplicator:

Plugins > Adicionar novo > Duplicator

Instala-o e ativa-o.

Importante: o Duplicator instala-se em produção. A ideia é gerar um pacote do site real para depois o importar no LocalWP.

Passo 4: criar uma cópia com o Duplicator

A partir do painel de produção vai a:

Duplicator > Packages

Cria um novo pacote com um nome que identifique para que serve. Eu usei:

yagogonzalez-copia-local-fase0

A análise inicial avisou que o site era grande. Nada de estranho em sites com anos de conteúdo.

O problema surgiu ao construir o pacote:

Couldn't close zip archive

O servidor não conseguiu fechar o ficheiro ZIP. 

Não significa que o site se tenha partido. Significa que o hosting não conseguiu completar a operação, provavelmente por tamanho, tempo de execução ou limites de memória.

Primeiro problema a resolver.

Passo 5: experimentar o DupArchive se o ZIP falhar

O Duplicator oferece uma alternativa quando o ZIP falha: DupArchive.

Para isso é preciso mudar o motor de arquivo de ZIP para DupArchive. O pacote passa a ser gerado como .daf em vez de .zip.

Muda-se a partir de:

Duplicator > Definições > Cópias de segurança > Arquivo

Aí procura Archive Engine e muda ZipArchive para DupArchive.

Depois guarda as alterações.

Tudo pronto?

Pois não. Novo erro:

O tamanho total dos ficheiros e da base de dados ultrapassa o limite de 500 MB

A cópia pesava aproximadamente 1,33 GB. Também não servia mudar tudo per se.

A solução: não meter tudo dentro do pacote.

Passo 6: criar o pacote sem a pasta uploads

A pasta que dispara o peso de qualquer WordPress com anos de vida é wp-content/uploads/. 

É ali que estão imagens, PDFs, miniaturas, WebP e tudo o que foi carregado desde o primeiro dia.

Para reduzir o pacote de download, no Duplicator ativei os filtros de ficheiros e excluí:

• wp-content/uploads/
• wp-content/cache/
• wp-content/upgrade/
• wp-content/backups-dup-lite/
• wp-content/plugins/duplicator/backups/

Com isto, o pacote inclui o essencial para reconstruir o site: base de dados, WordPress, tema, plugins, configuração, posts, páginas, taxonomias, ACF, Yoast e definições internas. 

As imagens descarregamo-las à parte. Já te explico como no passo 8.

Passo 7: descarregar os ficheiros do Duplicator

Depois de gerado o pacote, o Duplicator cria dois ficheiros:

• installer.php
• ficheiro .zip ou .daf

Descarrega os dois.  

São eles que permitem reconstruir o site localmente. O instalador encarrega-se de extrair o pacote, importar a base de dados, substituir URLs e ajustar caminhos.

Passo 8: descarregar a pasta uploads

Como uploads não ia dentro do pacote, toca descarregá-la manualmente a partir do hosting.

O caminho habitual num WordPress:

/public_html/tudominio.com/wp-content/uploads/

Se tens um hosting normal, podes descarregá-la a partir das opções do gestor de ficheiros do cPanel. Foi o que eu fiz.

Se não conseguires por esta via, terás de o fazer à moda antiga, descarregando-a por FTP ou SFTP diretamente para o computador com FileZilla ou algo semelhante.

Conselho: não comprimas a pasta no servidor. Isso voltaria a colocar carga no hosting e poderia falhar tal como o Duplicator. O download direto é mais lento, mas mais seguro.

Passo 9: preparar o LocalWP para importar a cópia

Com os dois ficheiros do Duplicator descarregados, volta ao LocalWP:

1. Para o site local: clica em Stop site.
2. Abre a pasta do site: clica em Site folder.
3. Entra em app > public.
4. Apaga o conteúdo de public (o WordPress limpo que o LocalWP criou).
5. Copia aí os dois ficheiros do Duplicator.

Importante: é preciso apagar o conteúdo de public, não a pasta public.

A pasta deve existir e lá dentro só devem estar os dois ficheiros descarregados:

• installer.php
• copia-local.daf

Depois arranca o site: clica em Start site.

Passo 10: executar o instalador do Duplicator localmente

Abre o instalador no navegador:

https://yg.local/installer.php

O instalador deteta o pacote e começa o processo.

Para ligar à base de dados local, usa os dados do LocalWP:

Campo	Valor
Database Host	localhost
Database Name	local
User	root
Password	root

Como era uma instalação local vazia (a que o programa monta por defeito no início), assinala que aceitas que o Duplicator apague a base de dados anterior. 

Não há problema: só estava a apagar o WordPress limpo do LocalWP, não o site real.

Depois o Duplicator faz a substituição de URLs:

• Old URL: https://yagogonzalez.com
• New URL: https://yg.local

Ao terminar, já podes entrar no WordPress local.

Importante: depois de importar a base de dados, o utilizador e a palavra-passe são os do site real, não os criados inicialmente no LocalWP.

Passo 11: limpar os ficheiros de instalação

O Duplicator normalmente elimina os ficheiros do instalador ao terminar:

• installer.php
• ficheiro .daf
• pasta dup-installer
• logs de instalação

Em produção é importante por segurança. Em ambiente local é menos crítico, mas convém deixar tudo limpo.

Confirma que já não existem depois da instalação antes de continuar.

Passo 12: copiar uploads para o WordPress local

Com o site parado (Stop site) no LocalWP, entra em app > public > wp-content e copia aí a pasta uploads que descarregaste.

A estrutura correta:

<em>wp-content/</em>
├── plugins/

├── themes/

└── uploads/

    ├── 2013/

    ├── 2014/

    ...

    └── 2026/

O que não deve acontecer:

wp-content/uploads/uploads/2026/

Esse duplo uploads/uploads é um erro clássico de comprimir em zip antes de descarregar e quebra todos os caminhos das imagens.

Passo 13: corrigir o problema das imagens partidas

No meu caso, aqui chegou o problema mais grave (por inesperado): o site carregava, mas as imagens não apareciam. E não era por causa do caminho com duplo upload.

O problema estava na URL que o WordPress gerava para as imagens:

https://yg.local/C:/Users/pcadmin/Local Sites/yg/app/public/wp-content/uploads/2026/06/imagen.webp

Tudo o que está marcado a negrito sobrava. A URL correta tinha de ser:

https://yg.local/wp-content/uploads/2026/06/imagen.webp

O WordPress tinha guardada na opção upload_path um caminho absoluto do Windows:

C:/Users/pcadmin/Local Sites/yg/app/public/wp-content/uploads

Para corrigir isso, abre Site shell no LocalWP e executa estes três comandos um a seguir ao outro:

wp --url=https://yg.local option delete upload_path

wp --url=https://yg.local option delete upload_url_path 

wp --url=https://yg.local cache flush

Depois disso, ao recarregar, as imagens já apareciam.

O problema é que também apareciam vários Warnings (avisos).

Passo 14: corrigir warnings visíveis

Como te dizia, aparecia este warning no site local:

Constant WP_POST_REVISIONS already defined

Aqui recorri ao ChatGPT, porque não fazia ideia de como resolver.

O problema vinha de functions.php do tema, que definia WP_POST_REVISIONS sem verificar se já estava definida noutro sítio.

A correção:

<em>if ( ! defined( 'WP_POST_REVISIONS' ) ) {</em>
<em>    define( 'WP_POST_REVISIONS', false );</em>
<em>}</em>

Se no teu caso o valor for diferente, simplesmente respeita o teu:

<em>if ( ! defined( 'WP_POST_REVISIONS' ) ) {</em>
<em>    define( 'WP_POST_REVISIONS', <strong>5</strong> );</em>
<em>}</em>

Mudei-o a partir do editor de ficheiros do tema do WordPress (Aparência > Editor de ficheiros do tema) guardei o ficheiro e pronto.

Passo 15: limpar produção

Com a cópia local a funcionar, volta ao site real e elimina os rastos do Duplicator:

1. Duplicator > Packages:    apaga os pacotes criados.
2. Plugins > Plugins instalados: desinstala o Duplicator.

Isto não afeta a cópia local. Apenas evita deixar pacotes pesados e instaladores desnecessários em produção.

Não é obrigatório, mas é recomendável.

Passo 16: testar o clone local

Verifica vários URLs antes de continuar.  

No meu caso revi:

• A página inicial.
• Um post.
• Uma categoria.
• Uma subcategoria.
• Uma etiqueta.

Fiz assim porque cada uma usa um template diferente:

• https://yg.local
• https://yg.local/ruta-de-escape
• https://yg.local/tecnologia
• https://yg.local/ocio/series
• https://yg.local/negocio

Quatro coisas a rever:

1. O site carrega.
2. As imagens aparecem.
3. O design é igual ao de produção.
4. Os links internos apontam para yg.local, não para yagogonzalez.com.

Este último ponto é fundamental. Se clicas num artigo e ele te manda para produção, ainda tens URLs mal substituídos.

Passo 17: criar um ponto de restauro antes de continuar

Este passo, mais uma vez, é opcional, mas recomendável.

Antes de começares a fazer as alterações de que precisas localmente ou a mexer em qualquer coisa séria, cria um ponto de restauro.

No LocalWP podes clonar o site:

Clone site

No meu caso criei uma cópia chamada yg-pre-polylang.

A lógica:

• yg = site local de trabalho.
• yg-pre-polylang = cópia limpa antes de mexer em alguma coisa.

Se algo rebentar, não é preciso repetir toda a migração de produção do zero; basta que pegue nesta cópia limpa e trabalhe sobre ela. Não sem antes a voltar a clonar, claro.

Problemas habituais neste processo

As migrações locais quase nunca saem perfeitas à primeira. Agrupo aqui os problemas que apareceram neste caso.

O ZIP do Duplicator falhou

Erro: Couldn't close zip archive

Causa: limites do servidor (tamanho, tempo de execução, memória).

Solução: experimentar o DupArchive ou excluir pastas pesadas do pacote.

O DupArchive tinha limite de tamanho

Erro: o pacote ultrapassava os 500 MB.

Solução: excluir wp-content/uploads/ e descarregar essa pasta à parte.

As imagens não carregavam

Causa: o WordPress usava um caminho absoluto do Windows como se fosse uma URL pública.

Solução:

wp option delete upload_path

wp option delete upload_url_path

Warning de PHP por constante já definida

Causa: WP_POST_REVISIONS definida duas vezes em functions.php.

Solução: envolver a definição com if ( ! defined(…) ).

Conclusão

Se o teu site pesa pouco, o Duplicator faz tudo sozinho. Mas, se tem anos de conteúdo e imagens acumuladas, o habitual é dividir o processo em dois:

• Duplicator = base de dados + WordPress + tema + plugins
• FTP/SFTP = pasta uploads

E depois rever caminhos, imagens, warnings e links internos antes de mexer em qualquer coisa séria.

A cópia local não vale de nada se não funcionar de verdade.

E se vais mexer em algo delicado — multilingue, redesign, plugins grandes, migrações SEO — fazê-lo diretamente em produção é correr riscos desnecessários. 

Tens as ferramentas. São grátis. E o processo, embora não seja automático, faz-se em meia hora.

Lembra-te:

Primeiro local. Depois testes. A seguir produção. Por essa ordem.

Como Bale e o golfe, mas aplicado ao WordPress.

Já agora, deixo-te aqui a continuação deste artigo: como otimizar a velocidade do WPLocal.