Come clonare un sito WordPress in locale

Quando inizi a mettere davvero mano a un sito -in WordPress o in qualsiasi altro sistema- devi interiorizzare una regola di base prima di cominciare: non sperimentare in produzione.

Per diversi motivi:

1. Perché i risultati possono essere catastrofici se non sai bene cosa stai toccando o non hai un backup.
2. Perché, per colpa di quanto sopra e mentre ripristini tutto, puoi beccarti un picco di stress per niente desiderabile.
3. E perché montare una copia in locale ti richiederà solo mezz’ora e me ne sarai grato per sempre.

Ripeto:

Prima monti una copia locale. Poi tocchi. Non al contrario.

In questi giorni, mentre sto cambiando a fondo il mio sito, mi è toccato farlo, quindi ne ho approfittato e ho creato questo tutorial.

Il mio sito aveva diversi anni di contenuti, 250 articoli, immagini accumulate dal 2013 e una dimensione sufficiente perché Duplicator sibloccasse a metà due volte prima di funzionare.

Anche questo è qui. Errori -e relative soluzioni- inclusi.

A cosa serve avere un clone locale di WordPress

Una copia locale ti permette di lavorare sul tuo computer senza toccare il sito reale.

Utile per: provare plugin, cambiare tema, controllare il database, preparare una migrazione, fare un audit tecnico, installare Polylang, modificare CSS o rompere cose senza che Google, i tuoi utenti o il tuo cliente se ne accorgano.

Nel mio caso l’obiettivo era doppio:

1. Cambiare completamente il design, passando da un sito di acquisizione lead a una rivista digitale.
2. Preparare il sito alla traduzione assistita dall’IA. Uno sviluppo mio, con un certo livello di rischio, perché implica toccare varie cose allo stesso tempo.

In ogni caso il processo è lo stesso se vuoi ricategorizzare in modo automatizzato, cambiare tema, aggiungere un plugin grande tipo WooCommerce o semplicemente avere un ambiente di test prima di toccare qualcosa di serio.

Strumenti che ho usato

• LocalWP: per creare l’ambiente WordPress locale.
• Duplicator: per esportare il sito di produzione.
• cPanel:  il pannello di controllo dell’hosting per scaricare manualmente la cartella delle immagini.
• WP-CLI: incluso in LocalWP, per correggere opzioni interne di WordPress.

Tutto gratuito. 

Guida passo passo per clonare il tuo WordPress in locale

Ora che conosci gli strumenti, passiamo al passo passo, che è un po’ più lungo del solito.

In ogni caso, per farti un’idea, in circa 30 minuti avrai tutto pronto, a seconda dei problemi che ti si presenteranno. Perché se il tuo sito è piccolo e non dà errori, è possibile che tu ce l’abbia in meno di dieci minuti.

Pochi investimenti sono più redditizi di questo.

Passo 1: installare LocalWP

LocalWP crea installazioni WordPress in locale senza dover configurare Apache, MySQL e PHP a mano. Non ti servono XAMPP, WAMP o LAMP.

Lo installi, crei un nuovo sito e in due minuti hai un WordPress pulito funzionante sul tuo computer.

Nel mio caso l’ho chiamato yg, quindi LocalWP gli ha assegnato il dominio locale https://yg.local con questo ambiente:

Campo	Valore
Server	nginx
PHP	8.2
Database	MySQL
WordPress	Installazione pulita

Con questo basta per iniziare.

Passo 2: verificare che il WordPress locale si apra

Prima di importare qualsiasi cosa, apri il sito locale ed entra nel pannello:

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

Se carica e riesci a entrare, l’ambiente è pronto. Non installare ancora nulla. Non toccare le impostazioni. Controlla solo che funzioni.

Passo 3: installare Duplicator sul sito reale

Entra nel WordPress di produzione (non in quello locale) e installa Duplicator:

Plugin > Aggiungi nuovo > Duplicator

Installalo e attivalo.

Importante: Duplicator si installa in produzione. L’idea è generare un pacchetto del sito reale per poi importarlo in LocalWP.

Passo 4: creare una copia con Duplicator

Dal pannello di produzione vai su:

Duplicator > Packages

Crea un nuovo pacchetto con un nome che identifichi a cosa serve. Io ho usato:

yagogonzalez-copia-local-fase0

La scansione iniziale ha avvisato che il sito era grande. Niente di strano in siti con anni di contenuti.

Il problema è arrivato durante la costruzione del pacchetto:

Couldn't close zip archive

Il server non è riuscito a chiudere il file ZIP. 

Non significa che il sito si sia rotto. Significa che l’hosting non è riuscito a completare l’operazione, probabilmente per dimensione, tempo di esecuzione o limiti di memoria.

Primo problema da risolvere.

Passo 5: provare DupArchive se lo ZIP fallisce

Duplicator offre un’alternativa quando lo ZIP fallisce: DupArchive.

Per farlo bisogna cambiare il motore di archiviazione da ZIP a DupArchive. Il pacchetto passa a generarsi come .daf invece che come .zip.

Si cambia da:

Duplicator > Impostazioni > Backup > Archivio

Lì cerca Archive Engine e cambia ZipArchive con DupArchive.

Poi salva le modifiche.

Tutto pronto?

Macché. Nuovo errore:

La dimensione totale dei file e del database supera il limite di 500 MB

La copia pesava circa 1,33 GB. Non serviva nemmeno cambiare tutto di per sé.

La soluzione: non mettere tutto dentro il pacchetto.

Passo 6: creare il pacchetto senza la cartella uploads

La cartella che fa esplodere il peso di qualsiasi WordPress con anni di vita è wp-content/uploads/. 

Lì ci sono immagini, PDF, miniature, WebP e tutto ciò che è stato caricato dal primo giorno.

Per ridurre il pacchetto di download, in Duplicator ho attivato i filtri dei file ed escluso:

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

Con questo, il pacchetto include l’importante per ricostruire il sito: database, WordPress, tema, plugin, configurazione, articoli, pagine, tassonomie, ACF, Yoast e impostazioni interne. 

Le immagini le scarichiamo a parte. Ti spiego come al passo 8.

Passo 7: scaricare i file di Duplicator

Una volta generato il pacchetto, Duplicator crea due file:

• installer.php
• file .zip o .daf

Scarica entrambi.  

Sono quelli che permettono di ricostruire il sito in locale. L’installer si occupa di estrarre il pacchetto, importare il database, sostituire gli URL e regolare i percorsi.

Passo 8: scaricare la cartella uploads

Poiché uploads non era dentro il pacchetto, bisogna scaricarla manualmente dall’hosting.

Il percorso abituale in un WordPress:

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

Se hai un hosting normale puoi scaricarla usando le opzioni del file manager di cPanel. È quello che ho fatto io.

Se non puoi farlo così, dovrai farlo alla vecchia maniera, scaricandola via FTP o SFTP direttamente sul computer con FileZilla o simili.

Consiglio: non comprimere la cartella sul server. Finiresti per rimettere carico sull’hosting e potrebbe fallire come Duplicator. Il download diretto è più lento, ma più sicuro.

Passo 9: preparare LocalWP per importare la copia

Con i due file di Duplicator scaricati, torna su LocalWP:

1. Per il sito locale: clicca su Stop site.
2. Apri la cartella del sito: clicca su Site folder.
3. Entra in app > public.
4. Cancella il contenuto di public (il WordPress pulito creato da LocalWP).
5. Copia lì i due file di Duplicator.

Importante: bisogna cancellare il contenuto di public, non la cartella public.

La cartella deve esistere e dentro devono esserci solo i due file scaricati:

• installer.php
• copia-local.daf

Poi avvia il sito: clicca su Start site.

Passo 10: eseguire l’installer di Duplicator in locale

Apri l’installer nel browser:

https://yg.local/installer.php

L’installer rileva il pacchetto e avvia il processo.

Per collegarsi al database locale usa i dati di LocalWP:

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

Essendo un’installazione locale vuota (quella che il programma ti crea di default all’inizio), digli che accetti che Duplicator cancelli il database precedente. 

Non succede nulla: stava solo cancellando il WordPress pulito di LocalWP, non il sito reale.

Poi Duplicator fa la sostituzione degli URL:

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

Alla fine puoi già entrare nel WordPress locale.

Importante: dopo aver importato il database, utente e password sono quelli del sito reale, non quelli creati inizialmente in LocalWP.

Passo 11: pulire i file di installazione

Duplicator normalmente elimina i file dell’installer al termine:

• installer.php
• file .daf
• cartella dup-installer
• log di installazione

In produzione è importante per sicurezza. In locale è meno critico, ma conviene lasciarlo pulito.

Controlla che non esistano dopo l’installazione prima di continuare.

Passo 12: copiare uploads nel WordPress locale

Con il sito fermo (Stop site) in LocalWP, entra in app > public > wp-content e copia lì la cartella uploads che hai scaricato.

La struttura corretta:

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

├── themes/

└── uploads/

    ├── 2013/

    ├── 2014/

    ...

    └── 2026/

Quello che non deve succedere:

wp-content/uploads/uploads/2026/

Quel doppio uploads/uploads è un errore classico di chi comprime in zip prima di scaricare e rompe tutti i percorsi delle immagini.

Passo 13: correggere il problema delle immagini rotte

Nel mio caso, qui è arrivato il problema più grosso (perché inatteso): il sito caricava, ma le immagini non si vedevano. E non era per il percorso con doppio upload.

Il problema era nell’URL che WordPress generava per le immagini:

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

Tutto quello segnato in grassetto era di troppo. L’URL corretto doveva essere:

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

WordPress aveva salvato nell’opzione upload_path un percorso assoluto di Windows:

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

Per correggerlo, apri Site shell in LocalWP ed esegui questi tre comandi uno dopo l’altro:

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

Una volta fatto, ricaricando, le immagini apparivano già.

Il problema è che comparivano anche diversi Warnings (avvisi).

Passo 14: correggere i warning visibili

Come ti dicevo, sul sito locale compariva questo warning:

Constant WP_POST_REVISIONS already defined

Qui ho chiesto a ChatGPT, perché non avevo idea di come risolverlo.

Il problema veniva da functions.php del tema, che definiva WP_POST_REVISIONS senza controllare se fosse già definita da qualche altra parte.

La correzione:

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

Se nel tuo caso il valore è diverso, rispetta semplicemente il tuo:

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

L’ho cambiato dall’editor dei file del tema di WordPress (Aspetto > Editor dei file del tema) ho salvato il file e fine.

Passo 15: pulire la produzione

Con la copia locale funzionante, torna al sito reale e elimina le tracce di Duplicator:

1. Duplicator > Packages:    elimina i pacchetti creati.
2. Plugin > Plugin installati: disinstalla Duplicator.

Questo non influisce sulla copia locale. Serve solo a evitare di lasciare pacchetti pesanti e installer inutili in produzione.

Non è obbligatorio, ma è consigliabile.

Passo 16: testare il clone locale

Controlla diversi URL prima di continuare.  

Nel mio caso ho controllato:

• La homepage.
• Un articolo.
• Una categoria.
• Una sottocategoria.
• Un tag.

L’ho fatto così perché ognuna usa un template diverso:

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

Quattro cose da controllare:

1. Il sito carica.
2. Le immagini si vedono.
3. Il design è uguale a quello in produzione.
4. I link interni puntano a yg.local, non a yagogonzalez.com.

Quest’ultimo punto è fondamentale. Se fai clic su un articolo e ti manda in produzione, hai ancora URL sostituiti male.

Passo 17: creare un punto di ripristino prima di continuare

Questo passaggio, di nuovo, è facoltativo, ma consigliato.

Prima di metterti a fare le modifiche che ti servono in locale o a toccare qualsiasi cosa seria, crea un punto di ripristino.

In LocalWP puoi clonare il sito:

Clone site

Nel mio caso ho creato una copia chiamata yg-pre-polylang.

La logica:

• yg = sito locale di lavoro.
• yg-pre-polylang = copia pulita prima di toccare nulla.

Se qualcosa esplode, non bisogna ripetere tutta la migrazione dalla produzione da zero, ma prendo questa copia pulita e lavoro su quella. Non senza averla prima clonata di nuovo, ovviamente.

Problemi abituali in questo processo

Le migrazioni locali quasi mai riescono perfette al primo colpo. Ti raggruppo qui quelli comparsi in questo caso.

Lo ZIP di Duplicator è fallito

Errore: Couldn't close zip archive

Causa: limiti del server (dimensione, tempo di esecuzione, memoria).

Soluzione: provare DupArchive o escludere cartelle pesanti dal pacchetto.

DupArchive aveva un limite di dimensione

Errore: il pacchetto superava i 500 MB.

Soluzione: escludere wp-content/uploads/ e scaricare quella cartella a parte.

Le immagini non caricavano

Causa: WordPress usava un percorso assoluto di Windows come se fosse un URL pubblico.

Soluzione:

wp option delete upload_path

wp option delete upload_url_path

Warning PHP per costante già definita

Causa: WP_POST_REVISIONS definita due volte in functions.php.

Soluzione: avvolgere la definizione con if ( ! defined(…) ).

Conclusione

Se il tuo sito pesa poco, Duplicator fa tutto da solo. Ma se ha anni di contenuti e immagini accumulate, la cosa normale è dividere il processo in due:

• Duplicator = database + WordPress + tema + plugin
• FTP/SFTP = cartella uploads

E poi controllare percorsi, immagini, warning e link interni prima di toccare qualsiasi cosa seria.

La copia locale non serve a niente se non funziona davvero.

E se devi toccare qualcosa di delicato -multilingua, redesign, plugin grossi, migrazioni SEO- farlo direttamente in produzione significa correre rischi inutili. 

Hai gli strumenti. Sono gratis. E il processo, anche se non è automatico, si fa in mezz’ora.

Ricorda:

Prima locale. Poi test. Dopo produzione. In quest’ordine.

Come Bale e il golf, ma applicato a WordPress.

A proposito, qui ti lascio il seguito di questo articolo: come ottimizzare la velocità di WPLocal.