Clonare un sito WordPress: staging, copia in locale e cosa spegnere prima di aprirla

Clonare un sito WordPress vuol dire averne due accesi con gli stessi dati: lo stesso database, gli stessi utenti, gli stessi plugin con le loro impostazioni. È diverso dallo spostarlo, perché alla fine di un trasloco il sito resta uno solo, ed è diverso da un backup, che sta fermo finché non serve. La copia si fa in pochi minuti, dal pannello dell’hosting, con un plugin o con qualche comando. Il lavoro comincia dopo, perché la copia non sa di esserlo. Manda le email ai clienti, esegue le operazioni programmate del sito vero, usa le sue chiavi per parlare con pagamenti e newsletter, e nasce visibile ai motori di ricerca. Questa guida parte da che copia ti serve e da come si fa, poi mette in fila cosa eredita dal sito vero e come si spegne prima di aprirla, e finisce con l’errore più costoso, quello del ritorno.

Una nota sulle fonti. Le prove le ho fatte il 5 ottobre 2026 su due installazioni di WordPress 7.1.2 (PHP 8.3, WP-CLI 2.12.0) con WooCommerce 11.1.2 e Rank Math 1.0.279, un sito “vero” e la sua copia, fatta con i comandi che trovi più sotto. Il resto viene dal codice di WordPress e dei plugin citati e dalla loro documentazione ufficiale, letta lo stesso giorno. Dove compare un numero di versione, accanto c’è la data.

Che copia ti serve

Prima di scegliere come farla conviene sapere a cosa serve, perché da lì dipendono dove metterla, quanto tenerla e cosa toglierle. I casi sono quattro.

Per i clienti preparo soprattutto le prime due. In locale lavoro con Devilbox, un ambiente basato su Docker, dove sviluppo e verifico prima di portare le modifiche in produzione. Quando serve una copia online la metto su un sottodominio protetto da password con il file .htaccess, e la creo con Duplicator o con WP-CLI, a seconda del sito.

Nessuna delle quattro è un backup.

Una copia che sta sullo stesso server o sullo stesso account dell’hosting sparisce con loro, mentre un backup sta altrove, come nella guida al backup su S3 con il ripristino da WP-CLI.

Due casi stanno in altre guide. Se il sito deve cambiare server o dominio e alla fine ne resta uno, è un trasloco, con i suoi problemi di DNS e di downtime, e per spostare il sito su un altro server o dominio la procedura è un’altra. Se il sito da copiare è un sottosito di una rete multisito, NS Cloner (4.4.9.2, del 27 agosto 2026) lo duplica dentro la stessa rete; per farne un sito indipendente bisogna invece estrarre il sottosito e renderlo autonomo.

Se il sito non è tuo, la risposta è nell’ultima sezione.

Fare la copia: pannello, plugin o WP-CLI

Le tre strade arrivano allo stesso punto, con i file e il database del sito vero in un posto nuovo e l’indirizzo nuovo scritto nel database. La meccanica di fondo è quella di un trasloco, ed è spiegata passo per passo nella guida che tratta la meccanica della copia, dai dati serializzati al campo guid. Qui c’è quello che cambia quando il sito vero resta acceso.

Dal pannello dell’hosting

È la strada più corta, se il pannello la offre. Prima di premere il pulsante conviene sapere quattro cose, dalla documentazione o dall’assistenza. Dove finisce la copia, se su un sottodominio, in una sottocartella o su un altro server. Se è protetta da password. Cosa fa il pulsante che la riporta sul sito vero, e se in quel passaggio sovrascrive il database, che per un negozio è la domanda decisiva, come si vede più avanti.

Con un plugin

WP STAGING nella versione gratuita (4.16.0, del 1° ottobre 2026) copia il sito in una sottocartella, la apre solo agli amministratori e la tiene fuori dai motori di ricerca, perché sulla copia imposta l’opzione di WordPress che li scoraggia. Nel codice della versione gratuita, però, email, WP-Cron e coda di WooCommerce restano accesi. Le caselle per spegnerli sono della versione Pro, come il passaggio delle modifiche sul sito vero.

Duplicator (5.0.5, del 29 settembre 2026) lavora in un altro modo. Crea un backup fatto di due file, un archivio con file e database e il programma d’installazione installer.php, che si caricano nella cartella dove deve nascere la copia. Aprendo installer.php nel browser si indicano i dati del database della copia, e l’installazione sostituisce l’indirizzo. Nel terzo passaggio, fra le opzioni, la scheda dedicata al wp-config.php ha due caselle che su una copia servono, una per generare chiavi di sicurezza nuove e una per impostare DISABLE_WP_CRON, che però da sola non basta. Finita l’installazione, controlla che archivio e installer.php non siano rimasti nella cartella pubblica, perché l’archivio è il sito intero. Come si comportano gli altri plugin che lavorano a pacchetti, e quali impostazioni del server li fanno fallire a metà, l’ho scritto parlando dei plugin di migrazione e dei limiti del server che li fermano.

Con WP-CLI

Con l’accesso SSH bastano pochi comandi, e il primo non scrive niente sul sito vero. wp search-replace con l’opzione --export legge il database, sostituisce l’indirizzo e mette il risultato in un file invece che nelle tabelle, come dice la documentazione del comando. Nella prova ha esportato tutte le 49 tabelle del sito con i dati serializzati ricalcolati, e il checksum delle tabelle del sito vero era identico prima e dopo.

# Sul server del sito vero, nella cartella di WordPress:
# il database della copia in un file, con l'indirizzo già cambiato
wp search-replace 'https://www.tuosito.it' 'https://staging.tuosito.it' \
  --all-tables-with-prefix --skip-columns=guid --export="$HOME/copia.sql"

# I file, tranne wp-config.php: la copia ha il suo
rsync -a --exclude='wp-config.php' --exclude='wp-content/cache/' /var/www/tuosito/ /var/www/staging/

# Prima di importare, nella copia vanno il wp-config.php e il mu-plugin
# della sezione "Dire alla copia che è una copia". Poi il database:
cd /var/www/staging
wp db import "$HOME/copia.sql"
wp db search 'www.tuosito.it' --all-tables-with-prefix --stats
rm "$HOME/copia.sql"

Tre dettagli. --all-tables-with-prefix prende anche le tabelle dei plugin, mentre --all-tables, che si trova in molte guide, prende tutte le tabelle del database, comprese quelle di un altro sito se il database è condiviso. Il file finisce nella cartella home, fuori da quella pubblica, e si cancella appena importato, perché è il database intero, con utenti e clienti. Il wp-config.php della copia va preparato prima, con il database suo, lo stesso prefisso delle tabelle del sito vero e le protezioni che descrivo più avanti; per cosa controllare nel resto del wp-config.php c’è la guida all’installazione. Le protezioni vanno messe prima di importare il database, non dopo. Nella prova, sulla copia ancora senza protezioni, è bastato il controllo con wp db search subito dopo l’importazione. Il comando carica WordPress, WordPress ha fatto partire WP-Cron, e un evento e un’azione in coda sul sito vero sono stati eseguiti sulla copia in quel momento.

L’ultimo controllo dice cosa è rimasto. Nella prova le occorrenze erano 33. Quattordici stavano nel campo guid, lasciato com’è di proposito, e 19 in una cache di WooCommerce che salva gli indirizzi in JSON. In JSON PHP scrive le barre come \/, salvo indicazione contraria (la costante JSON_UNESCAPED_SLASHES), e la sostituzione normale quella forma non la riconosce. Una seconda passata con le barre la sistema.

wp search-replace 'https:\/\/www.tuosito.it' 'https:\/\/staging.tuosito.it' \
  --all-tables-with-prefix --skip-columns=guid

In locale

Per una copia sul tuo computer valgono gli stessi comandi, a una condizione. Il PHP deve essere della stessa versione del server, altrimenti la prova non dice niente su quello che succederà in produzione. Gli strumenti per avere WordPress in locale, da Local a DDEV, li ho elencati nella guida al tema da zero. WordPress Playground, che lo fa girare nel browser, ha una guida in calendario.

Tenerla fuori dai motori e dagli estranei

Una copia raggiungibile da chiunque è un sito doppio per Google e una porta in più verso i dati. La protezione che regge è una password chiesta dal server, prima ancora che WordPress si carichi. Google, per i contenuti riservati, scrive che “you need to password protect it” (documentazione aggiornata al 10 dicembre 2025). Come si imposta su Apache e su nginx lo trovi dove spiego una password chiesta dal server prima di WordPress.

La password ha un effetto che si nota nella Salute del sito. Le richieste che WordPress fa a se stesso ricevono anche loro la richiesta di credenziali, e la Salute del sito avverte che “Il tuo sito non ha potuto completare una richiesta di loopback”: su una copia protetta è normale. Fra quelle richieste ci sono le due che fanno partire WP-Cron e Action Scheduler. Nella prova, con la sola password e nessun’altra protezione, hanno ricevuto 401 e non è partito niente. È un effetto collaterale utile, su cui non conviene contare. Basta togliere la password per mostrare la copia a un cliente e la coda riparte, mentre le email legate a quello che fai sulla copia, come un ordine segnato come completato, partono comunque.

La casella “Scoraggia i motori di ricerca dall’effettuare l’indicizzazione di questo sito” ha invece due trappole. La prima è che sta nel database, quindi la copia la eredita dal sito vero, spenta. Appena importata, la copia della prova stampava index, follow con Rank Math, e nessun noindex senza. La seconda è il viaggio inverso. Se un giorno il database della copia torna sul sito vero, la casella spuntata torna con lui, e il sito vero esce dai risultati di ricerca. È uno dei motivi per cui un noindex dimenticato dopo il lavoro su una copia è un controllo fisso della checklist SEO. Con la casella spuntata WordPress stampa noindex, nofollow e lascia il robots.txt com’era; Rank Math 1.0.279 fa lo stesso con il suo meta robots. Più avanti c’è un modo per avere lo stesso risultato sulla copia senza toccare il database.

Cosa una copia fa da sola, se nessuno la ferma

Tutto quello che segue l’ho visto succedere sulla copia di prova appena importata, senza nessuna protezione.

Manda email vere

La copia ha gli stessi utenti, gli stessi clienti e gli stessi plugin del sito vero, quindi qualunque cosa faccia partire un’email la manda a persone vere. Nella prova, segnare come completato un ordine vecchio ha mandato al cliente “Il tuo ordine su Sito vero è stato completato”, e una richiesta di nuova password dalla pagina di accesso della copia gli ha mandato il link per cambiarla.

WooCommerce Subscriptions ha una difesa sua. Confronta l’indirizzo del sito con una copia che ha salvato, e se è cambiato passa i rinnovi al pagamento manuale e smette di mandare le email delle sottoscrizioni. La sua documentazione avverte che le email di WordPress, di WooCommerce e degli altri plugin possono partire lo stesso. La difesa, poi, non scatta se la copia ha lo stesso indirizzo del sito vero, come succede collaudando un server nuovo con il file hosts.

Il modo affidabile è fermare le email dentro WordPress, con il filtro pre_wp_mail, che il core applica all’inizio di wp_mail() dalla versione 5.7. Il filtro vale anche con i plugin SMTP che passano da wp_mail(), come WP Mail SMTP (4.10.0), e con quelli che la sostituiscono applicando lo stesso filtro, come Gravity SMTP (2.3.3), e l’ho verificato nel loro codice. Resta fuori chi spedisce senza passare da wp_mail(), un limite che WP STAGING scrive anche nella sua interfaccia, e un’email di prova dalla copia chiude la questione.

Con il filtro attivo, chi chiede una nuova password sulla copia vede “l’email non può essere inviata”. Su una copia è la risposta giusta. Se invece le email ti servono per provarle, la strada è dirottarle tutte su una casella tua, togliendo anche ogni destinatario in copia o in copia nascosta.

Esegue le operazioni programmate

WP-Cron non ha un orologio suo. Come spiega il manuale per sviluppatori, a ogni caricamento di pagina controlla se ci sono operazioni scadute e le esegue. La copia arriva con la coda del sito vero piena, e la prima visita la svuota. Basta anche un comando WP-CLI, che carica WordPress come una visita. Nella prova, aprire la home della copia ha eseguito sulla copia un evento programmato sul sito vero e un’azione di Action Scheduler, nello stesso secondo. Su un sito vero sono newsletter, rinnovi, sincronizzazioni con il gestionale, backup inviati allo stesso spazio di archiviazione del sito vero.

La costante DISABLE_WP_CRON ferma solo le esecuzioni partite dalle visite. Il commento in testa a wp-cron.php avverte che la costante e la chiamata diretta del file “are mutually exclusive”, e nella prova una richiesta a /wp-cron.php ha eseguito l’evento con la costante attiva. Action Scheduler, la coda usata da WooCommerce e da molti altri plugin, ha poi una strada sua. Alla fine delle richieste all’area di amministrazione, al massimo una volta al minuto, se ci sono azioni scadute, fa partire l’elaborazione della coda, e nella prova una richiesta anonima ad admin-ajax.php, senza parametri, a cui il server ha risposto 400, ha eseguito l’azione.

Le operazioni bloccate, poi, non spariscono. Aspettano.

Quando nella prova ho tolto le protezioni, la prima visita ha fatto partire tutto insieme, compreso il webhook di un ordine creato sulla copia mentre era protetta. Prima di riaccendere qualcosa su una copia, quindi, la coda si guarda e si svuota di quello che non deve partire, con wp cron event delete seguito dal nome dell’evento e, per Action Scheduler, con wp action-scheduler action cancel seguito dal nome dell’azione e da --all.

Usa le chiavi del sito vero

Le impostazioni dei plugin stanno nel database, e con loro le chiavi dei servizi esterni: il pagamento in modalità live, il servizio di newsletter, il CRM, lo spazio dove vanno i backup. La copia le usa come il sito vero. Nella prova un ordine creato sulla copia è arrivato al servizio collegato con un webhook di WooCommerce. L’intestazione della richiesta indicava come origine l’indirizzo della copia, e per il servizio era un ordine come gli altri.

Sulla copia i pagamenti vanno messi in modalità di prova, i webhook e le integrazioni che scrivono altrove vanno scollegati, la destinazione dei backup va cambiata se il plugin che li fa resta attivo. Due cose si dimenticano spesso. Il codice di Analytics o di Tag Manager, che la copia carica uguale e che manda le sue visite nelle statistiche del sito vero, e le licenze dei plugin a pagamento, che a volte contano i siti attivati e vedono nella copia un sito in più. Per un negozio il resto del lavoro su uno store da modificare senza toccare quello in vendita è nella guida alle integrazioni WooCommerce.

Contiene utenti, password e dati dei clienti

Una copia del database contiene ogni utente con la sua password cifrata, ogni cliente con indirizzo e ordini, ogni messaggio arrivato dai moduli. Per il regolamento europeo sulla protezione dei dati anche registrare, conservare ed estrarre dati è un trattamento (articolo 4, punto 2), e la copia si porta dietro gli obblighi dell’originale, sicurezza compresa. L’articolo 32 nomina fra le misure la pseudonimizzazione. Una copia che resta tua, protetta da password, può tenere i dati. Una copia da consegnare a uno sviluppatore o a un’agenzia va consegnata senza, con clienti e ordini cancellati o resi anonimi e utenti ridotti a quelli che servono.

Una copia che diventa la base di un altro sito va svuotata di tutto quello che non le appartiene, e ha bisogno di chiavi di sicurezza sue, perché quelle del wp-config.php sono rimaste le stesse del sito vero. wp config shuffle-salts le rigenera, e nella prova chi era collegato alla copia è stato rimandato alla pagina di accesso. Le chiavi sono anche il controllo sulle chiavi di sicurezza della checklist.

Alcuni plugin se ne accorgono, dall’indirizzo

Jetpack, quando l’indirizzo cambia, entra in Safe Mode e offre tre scelte. Si possono spostare le impostazioni al nuovo indirizzo, creare una connessione nuova oppure restare in Safe Mode, che la documentazione indica per le copie di prova. Scegliere la prima su una copia sposta lì statistiche e iscritti del sito vero. Subscriptions, come visto, smette di incassare. Tutti e due guardano l’indirizzo, e una copia raggiungibile allo stesso indirizzo del sito vero, in locale o con il file hosts, per loro è il sito vero.

Dire alla copia che è una copia

Dalla versione 5.5 WordPress ha un modo standard per dirlo, la costante WP_ENVIRONMENT_TYPE, che accetta local, development, staging e production e vale production se manca (nota per sviluppatori della 5.5). Va nel wp-config.php della copia, che resta suo e non torna sul sito vero insieme agli altri file. È il posto giusto per le protezioni, perché un’impostazione salvata nel database viaggerebbe con lui, in tutte e due le direzioni.

// Nel wp-config.php della copia, sopra la riga "Finito, interrompere le modifiche!"
define( 'WP_ENVIRONMENT_TYPE', 'staging' );
define( 'DISABLE_WP_CRON', true );

Il core, con questa costante, fa meno di quanto ci si aspetta.

Dalla 7.1 spegne i ping in uscita (pingback, trackback e notifiche ai servizi di ping) e quelli in arrivo (wp_should_disable_pings_for_environment()). Nella prova un trackback verso la copia è stato respinto con il messaggio “I trackback sono disattivati negli ambienti che non sono di produzione”. Con development accende WP_DEBUG, se non è definito altrove; con local permette le password per le applicazioni senza HTTPS; fuori da production la Salute del sito salta i controlli sulla cache. Su email, operazioni programmate e indicizzazione, la costante da sola non cambia niente.

A leggerla sono i plugin. Jetpack, con staging o development, non offre di spostare sulla copia le impostazioni del sito vero. Per tutto il resto serve un mu-plugin, un file che WordPress carica da solo e che dal pannello non si disattiva. Si mette in wp-content/mu-plugins/ della copia.

<?php
/**
 * Plugin Name: Questa è una copia
 * Description: Fuori da "production" niente email, niente indicizzazione e niente operazioni programmate che partono da sole. Va in wp-content/mu-plugins/ della copia.
 */

if ( 'production' === wp_get_environment_type() ) {
	return;
}

// Le email si fermano dentro wp_mail(), prima di partire.
add_filter( 'pre_wp_mail', '__return_false' );

// Fuori dai motori di ricerca, qualunque valore abbia l'opzione copiata dal sito vero.
add_filter( 'pre_option_blog_public', '__return_zero' );

// WP-Cron non trova niente da eseguire: né alle visite né chiamando wp-cron.php.
add_filter( 'pre_get_ready_cron_jobs', '__return_empty_array' );

// Action Scheduler (WooCommerce e altri plugin) non parte dalle richieste ad admin-ajax.php.
add_filter( 'action_scheduler_allow_async_request_runner', '__return_false' );

Sul sito vero il file non fa niente, perché lì l’ambiente è production, e si può copiare insieme al resto senza pensarci. Nella prova, con queste righe e le due costanti nel wp-config.php, la copia non ha mandato email né chiamato il servizio esterno. Non ha eseguito niente né alle visite, né da wp-cron.php, né da admin-ajax.php, e stampava noindex, nofollow mentre nel database la casella restava quella del sito vero. Il filtro su pre_get_ready_cron_jobs lascia le operazioni dove sono, e con WP-CLI si possono sempre far partire a mano, una per una.

Due avvertenze. La password chiesta dal server resta il primo strato, perché tiene lontano anche chi chiama wp-cron.php e admin-ajax.php dall’esterno. Il wp-config.php della copia, poi, non va mai portato sul sito vero, che con la costante staging e questo file in mu-plugins smetterebbe di mandare email.

Prima di aprire la copia a qualcuno, un controllo di un minuto, dalla sua cartella.

wp eval 'echo wp_get_environment_type(), PHP_EOL;'
wp option get siteurl
wp option get blog_public
wp user list --role=administrator --fields=user_login,user_email
wp cron event list --fields=hook,next_run_relative
wp action-scheduler action list --status=pending --per_page=-1 --fields=hook,scheduled_date

Le prime tre righe devono rispondere staging, l’indirizzo della copia e 0. Gli amministratori sono quelli del sito vero, con le loro email. Le ultime due mostrano cosa aspetta di partire; la seconda esiste dove c’è Action Scheduler, con WooCommerce per esempio, e senza --per_page=-1 elenca solo le prime cinque azioni.

Riportare sul sito vero quello che hai fatto sulla copia

Qui si fa l’errore più costoso.

Il database della copia non torna sul sito vero, perché nel frattempo il sito vero ha continuato a vivere. Nella prova ho creato un ordine sul sito vero mentre lavoravo sulla copia, poi ho riportato il database della copia. L’ordine numero 15, da 20, è stato sostituito da un altro ordine numero 15, quello creato sulla copia, da 10. Stesso numero, un altro ordine e nessun messaggio d’errore, e con lo stesso giro è arrivato sul sito vero anche il noindex della copia.

Tornano invece il codice e le impostazioni. Temi e plugin scritti da te si portano con un deploy o con Git, che sposta le loro cartelle e niente altro, mai uploads e mai il wp-config.php. Gli aggiornamenti si rifanno sul sito vero dopo averli provati sulla copia, come nella procedura per rifare l’aggiornamento sul sito vero dopo la prova. Le impostazioni si rifanno a mano, o si esportano dove il plugin lo permette. In un restyling le impostazioni sono gran parte del lavoro, e come si porta online un restyling fatto sulla copia è in una guida a parte.

Per sapere cosa riportare, il confronto più rapido è fra le versioni. wp plugin list --fields=name,status,version e wp theme list --fields=name,status,version, lanciati su tutti e due i siti, mostrano quali plugin e temi sono stati aggiornati, aggiunti o disattivati sulla copia. Le impostazioni cambiate non compaiono lì, e conviene annotarle mentre si lavora.

Su un negozio il giro che non fa danni è questo: un backup del sito vero appena fatto, poi gli stessi passaggi provati sulla copia, nello stesso ordine, in un’ora di traffico basso.

I pulsanti che pubblicano la copia, nei pannelli degli hosting e nelle versioni a pagamento dei plugin, fanno cose diverse da un prodotto all’altro. Prima di usarli bisogna sapere quali tabelle sovrascrivono e se si possono escludere. Su un negozio la scelta più sicura è portare solo i file. L’eccezione è un sito fermo, dove fra la copia e il ritorno non è arrivato niente, nessun ordine, commento, iscrizione o messaggio. Lì il database può tornare indietro, con la sostituzione dell’indirizzo al contrario e la casella “Scoraggia” da ricontrollare subito dopo.

Quando la copia non serve più

Si cancella per intero: file, database, sottodominio, il record DNS che lo faceva rispondere, gli utenti creati per chi ci ha lavorato, le chiavi dei servizi esterni generate apposta. Una copia dimenticata è un’installazione WordPress che nessuno aggiorna con i dati del sito vero dentro, e quando sta nella stessa cartella del sito è fra le prime cose da togliere per ripulire un sito dalle installazioni dimenticate.

Prima di cancellare il database con wp db drop, che elimina quello indicato nel wp-config.php, conviene leggere quale sia con wp config get DB_NAME. Se per errore il wp-config.php della copia punta al database del sito vero, il comando cancella il sito vero.

La copia in locale, se contiene dati di clienti, si cancella allo stesso modo.

Se il sito da clonare non è tuo

Da fuori, di un sito WordPress si può scaricare solo quello che il server manda al browser: HTML, fogli di stile, script e immagini. Database, PHP e pannello restano sul server, quindi si ottiene una fotografia statica, in cui WordPress non c’è. I servizi che promettono di clonare un sito partendo da un indirizzo, oggi spesso con l’intelligenza artificiale, ne ricostruiscono l’aspetto con un sistema loro. Da fuori si può sapere, invece, con cosa è fatto. Nel codice della pagina, i percorsi che contengono /wp-content/themes/ e /wp-content/plugins/ riportano il nome della cartella del tema e dei plugin, e quelli pubblici si trovano nel repository di WordPress.

Testi, immagini e codice di un sito sono opere protette dalla legge sul diritto d’autore, che all’articolo 1 tutela anche i programmi per elaboratore, e per pubblicarne una copia serve il permesso di chi ne ha i diritti. Se il sito è tuo e sta su un’altra piattaforma, la strada è portarlo su WordPress con i suoi contenuti e i suoi indirizzi. Per una copia statica del tuo sito WordPress, una guida è in calendario.

Domande frequenti

Da qui in avanti

Una copia fatta bene si riconosce da quello che non succede. Nessun cliente riceve un’email che non aspettava, nessun rinnovo parte due volte, nessuna pagina della copia compare su Google, e il giorno in cui il lavoro torna sul sito vero non sparisce nessun ordine. Ci si arriva decidendo prima che copia serve, dicendole che è una copia prima di aprirla, e riportando indietro solo il codice. Se la copia serve per un aggiornamento importante, il resto è nella guida su cosa controllare prima, durante e dopo un aggiornamento.

Se preferisci che la prepari io

Preparo copie di staging per i clienti, protette da password, spente in tutto quello che parla con il mondo e smontate a lavoro finito, e fa parte del servizio di migrazione e trasferimento del sito. Se vuoi che me ne occupi io, scrivimi che sito è e a cosa ti serve la copia: aggiornamenti da provare, un tema nuovo, un sito da far partire da questo.