Migrazione WordPress multisito: come estrarre un sottosito e renderlo autonomo

Estrarre un sottosito da una rete WordPress e trasformarlo in un’installazione autonoma è un’operazione che sembra un normale trasloco di sito e non lo è. La differenza sta tutta in un punto: in un multisito alcune tabelle appartengono al sottosito e altre appartengono alla rete, e i ruoli degli utenti stanno dalla parte sbagliata del confine. Chi copia il database come farebbe con un sito singolo si ritrova un sito che si apre e nel quale non riesce più a entrare come amministratore.

Questa guida è la procedura completa per farlo senza perdere niente: quali tabelle esistono davvero, come si esportano, cosa va rinominato prima dell’import e quali quattro cose si rompono sempre subito dopo. È scritta per il caso più frequente — un sottosito che diventa un sito indipendente su un altro dominio — ma i passaggi valgono anche quando la destinazione è lo stesso server.

Il passaggio in produzione senza interruzioni — TTL del DNS, staging, cutover, sincronizzazione dei contenuti dell’ultimo minuto — non lo ripeto qui: è lo stesso di qualsiasi altra migrazione e l’ho già descritto passo per passo nella guida alla migrazione di un sito WordPress senza downtime. Quello che segue è la parte che riguarda solo il multisito, ed è la parte che non trovi in una guida generica.

Una nota sulle fonti. I nomi delle tabelle, il comportamento dei comandi WP-CLI, le costanti di configurazione e i requisiti citati qui li ho verificati uno per uno il 1º settembre 2026 sul codice sorgente di WordPress, sulla documentazione ufficiale di WP-CLI e sulla pagina dei requisiti di WordPress.org. Dove un’affermazione dipende da una versione o da un prodotto, accanto trovi il link alla fonte.

Una versione precedente di questo articolo conteneva quattro indicazioni sbagliate, tutte corrette qui sotto: proponeva di esportare tabelle chiamate wp_N_users e wp_N_usermeta, che in un multisito non esistono perché utenti e metadati utente sono globali; ometteva dall’elenco delle tabelle da esportare quelle delle tassonomie, senza le quali categorie e tag non arrivano a destinazione; usava wp search-replace per modificare un file SQL, cosa che quel comando fa solo con l’opzione --export; e citava una tabella wp_woocommerce_orders che non esiste in nessuna versione di WooCommerce. Erano inoltre datati il requisito minimo di PHP e i nomi di quattro dei plugin consigliati, nel frattempo rinominati.

Che cosa vuol dire davvero estrarre un sottosito

In una rete WordPress esiste una sola installazione di WordPress, un solo wp-config.php, una sola cartella wp-content e un solo database. I siti della rete non sono copie separate: sono gruppi di tabelle dentro lo stesso database, più una sottocartella dedicata dentro uploads. Tema e plugin sono fisicamente condivisi da tutti.

Estrarre un sottosito significa quindi ricostruire da queste parti un’installazione completa: prendere il gruppo di tabelle che gli appartiene, rinominarne il prefisso, recuperare i suoi media dalla sottocartella, copiare i temi e i plugin che effettivamente usa, e — il passaggio che quasi tutti dimenticano — riscrivere i riferimenti al numero del sottosito che restano nascosti dentro i dati. Non è un’operazione reversibile a metà: o si conclude, o si torna al backup.

Una precisazione che evita un errore frequente. Il prefisso delle tabelle dipende dall’ID del sito nella rete e il sito principale è un’eccezione: WordPress gli assegna il prefisso base senza numero. Se in wp-config.php il prefisso è wp_, il sito 1 usa wp_posts, mentre il sito 3 usa wp_3_posts. Lo stabilisce il metodo get_blog_prefix() della classe wpdb, che restituisce il prefisso base per gli ID 0 e 1 e vi accoda l’ID per tutti gli altri. Se stai estraendo il sito principale della rete, quindi, non hai nessun prefisso da rinominare: ti restano solo gli altri passaggi.

Quando conviene, e quando è meglio non farlo

Il multisito è nato per gestire più siti simili con una manutenzione sola. Finché i siti restano simili, funziona. Il momento in cui conviene separarne uno è quando quel sito ha smesso di assomigliare agli altri, e mantenerlo nella rete costa più di quanto la rete faccia risparmiare.

I casi in cui l’estrazione si ripaga sono quattro, in ordine di frequenza:

• Serve un plugin che la rete non può avere. In un multisito plugin e temi sono installati a livello di rete: le versioni sono le stesse per tutti. Quando un sito ha bisogno di una versione diversa, o di un plugin che confligge con quelli degli altri, la separazione è l’unica strada che non peggiora la situazione degli altri siti.
• Il sito cambia proprietario o gestore. Dare a un cliente o a un’agenzia esterna l’accesso al proprio sito, in una rete, significa dargli accesso a un ambiente condiviso: i permessi di WordPress arrivano fin lì, ma il confine resta poroso e ogni intervento sul server tocca tutti. Se il sito deve diventare di qualcun altro, deve diventare anche autonomo.
• Il traffico o il carico è sproporzionato. Un sito che consuma le risorse di tutta la rete penalizza gli altri e non può essere ottimizzato da solo: cache, CDN e database sono condivisi. Se il collo di bottiglia è quello, prima di separare vale però la pena escludere le cause ordinarie, che sono le stesse di qualsiasi sito WordPress lento e costano molto meno da risolvere.
• Il sito deve avere un’identità separata. Dominio proprio, dati strutturati propri, una Search Console propria. Molto di questo si ottiene anche dentro una rete, ma con vincoli che si pagano a ogni intervento.

E i casi in cui conviene fermarsi. Non estrarre un sottosito se dipende da personalizzazioni scritte a livello di rete — funzioni in un plugin must-use, tabelle condivise create da un plugin, utenti che devono restare gli stessi su più siti: fuori dalla rete quel codice non gira e va riscritto prima, non dopo. Non estrarlo se la ragione è solo la lentezza e non hai ancora verificato da cosa dipende. E non estrarlo se non hai un ambiente dove provarlo: questa è una procedura che si prova due volte e si esegue una.

Le tabelle di un multisito: quali sono del sottosito e quali no

È il punto in cui si decide se la migrazione riuscirà, e la fonte non è opinabile: l’elenco è scritto nel codice di WordPress, nella classe wpdb, in tre proprietà distinte. Le riporto per intero perché è la tabella che serve tenere aperta durante tutto il lavoro.

Da questa tabella discendono due conseguenze che vale la pena leggere con attenzione, perché sono la causa della maggior parte delle migrazioni fallite.

Prima: tabelle come wp_3_users non esistono. Utenti e metadati utente in una rete sono unici e condivisi da tutti i siti. Un comando di esportazione che le nomina fallisce, e se lo si “aggiusta” togliendole si porta via un sito senza nessun utente. La strada giusta non è esportarle intere — ci finirebbero dentro anche gli utenti che con questo sito non c’entrano — ma esportarle e poi ripulirle, oppure ricreare a mano i pochi account che servono. Torno sul come più avanti.

Seconda: le quattro tabelle delle tassonomie servono. terms, termmeta, term_taxonomy e term_relationships contengono categorie, tag e la loro associazione ai contenuti. Un export che elenca a mano solo posts, postmeta, options e i commenti produce un sito con tutti gli articoli e nessuna categoria: il danno si vede settimane dopo, quando gli archivi risultano vuoti. Il modo per non sbagliare è non scrivere l’elenco a mano, ed è quello che facciamo nel prossimo passaggio.

Prima di toccare qualsiasi cosa

Tre operazioni, nell’ordine. Nessuna è saltabile.

1. Identificare l’ID del sottosito

Tutto il resto dipende da questo numero. Sta nella tabella wp_blogs, e da riga di comando si legge così:

wp site list --fields=blog_id,url,registered

Annota l’ID e l’URL esatto, protocollo compreso: ti servono entrambi, e l’URL va copiato com’è, senza aggiungere o togliere lo slash finale.

2. Fare l’inventario di quello che il sito usa davvero

In una rete i plugin attivi si dividono su due livelli: quelli attivati per l’intera rete e quelli attivati dal singolo sito. Ti servono entrambe le liste, perché nel sito autonomo dovranno tornare tutti insieme:

wp plugin list --status=active-network
wp plugin list --status=active --url=https://dominio.it/sito3
wp theme list --status=active --url=https://dominio.it/sito3

Se il tema attivo è un tema figlio, segnati anche il tema genitore: vanno copiati tutti e due. È anche il momento buono per guardare quell’elenco con occhio critico e portarsi dietro solo quello che serve davvero — l’estrazione è l’occasione naturale per ripulire un sito WordPress da quello che si è stratificato negli anni, e farlo ora costa meno che farlo dopo.

3. Il backup, e dove va tenuto

Il backup che serve qui è quello dell’intera rete, non del solo sottosito: se qualcosa va storto durante l’esportazione, il rischio non è perdere il sito che stai migrando ma danneggiare quelli che restano. Database completo e cartella wp-content per intero, su una destinazione che non sia lo stesso disco del sito. La procedura con script e verifica del ripristino è nella guida al backup di WordPress su S3; qui basta il principio, ma il principio non è negoziabile.

Ultimo controllo prima di iniziare: allinea le versioni. La rete di partenza e l’installazione di destinazione devono avere la stessa versione di WordPress, e i plugin devono essere aggiornati prima della migrazione, non dopo. Importare un database in una versione diversa da quella che l’ha generato aggiunge una variabile a un’operazione che ne ha già abbastanza — sull’ordine corretto degli aggiornamenti ho scritto una guida dedicata.

Esportare il sottosito

Il database, senza scrivere l’elenco a mano

WP-CLI sa già quali sono le tabelle di un sito, e sa risolverle per il sottosito giusto. L’opzione --scope=blog restituisce esattamente le dieci tabelle del singolo sito, e --url le calcola con il prefisso corretto. Prima si guarda cosa verrà preso:

wp db tables --scope=blog --url=https://dominio.it/sito3

Devono comparire dieci nomi, tutti con il prefisso wp_3_. Se ne compaiono di più o di meno, fermati: significa che l’URL non corrisponde a nessun sito della rete e WP-CLI sta rispondendo sul sito principale. Quando l’elenco è quello giusto, lo si passa direttamente all’esportazione:

wp db export sito3.sql --tables=$(wp db tables --scope=blog --url=https://dominio.it/sito3 --format=csv)

È la forma documentata da WP-CLI ed è preferibile all’elenco scritto a mano per una ragione semplice: non può dimenticarsi una tabella. Se il sito usa plugin che creano tabelle proprie con il prefisso del sottosito — WooCommerce, i form, i sistemi di membership — quelle non sono registrate in wpdb e vanno aggiunte a parte:

wp db tables 'wp_3_*' --all-tables-with-prefix

Confronta questo elenco con il precedente: la differenza sono le tabelle dei plugin, e vanno nell’export anche loro.

Rinominare il prefisso

Nel file SQL ogni tabella si chiama ancora wp_3_qualcosa. Va sostituito con wp_, ed è una sostituzione testuale sul file:

sed -i.bak 's/`wp_3_/`wp_/g' sito3.sql

I backtick nel pattern non sono un dettaglio estetico: limitano la sostituzione ai nomi di tabella come li scrive mysqldump e le impediscono di toccare stringhe wp_3_ che compaiono dentro i dati — dove invece servono ancora, e dove le sistemeremo dopo l’import, deliberatamente. Il suffisso .bak lascia una copia del file originale: se la sostituzione va storta, non devi rifare l’export.

Gli URL

Gli indirizzi vecchi sono sparsi ovunque: nei contenuti, nelle opzioni, e dentro array serializzati di plugin e widget, dove una sostituzione testuale ingenua rompe il conteggio dei caratteri e rende il dato illeggibile. Per questo il search-replace va fatto con uno strumento che i dati serializzati li sappia riscrivere.

Il modo più sicuro è farlo dopo l’import, direttamente sul database nuovo, e lo vediamo tra due sezioni. Se però preferisci consegnare un file SQL già pronto, wp search-replace lo fa solo con l’opzione --export, che scrive un nuovo file invece di modificare il database:

wp search-replace 'https://dominio.it/sito3' 'https://nuovodominio.it' \
  --url=https://dominio.it/sito3 \
  --skip-columns=guid \
  --export=sito3-pronto.sql

Due avvertenze su questo comando. --skip-columns=guid esclude la colonna guid, che WordPress usa come identificatore interno dei contenuti e che non va riscritta anche se contiene un URL. E soprattutto: non usare mai --all-tables su una rete multisito. La documentazione di WP-CLI è esplicita — quell’opzione agisce su tutte le tabelle del database indipendentemente dal prefisso, il che su un multisito significa riscrivere anche i dati degli altri siti della rete.

I file

I media del sottosito stanno in wp-content/uploads/sites/3/, e in un’installazione singola devono diventare il contenuto di wp-content/uploads/. Quindi si copia il contenuto di quella cartella, non la cartella:

rsync -av wp-content/uploads/sites/3/ /destinazione/wp-content/uploads/

Lo slash finale dopo 3 è la differenza fra copiare il contenuto e copiare la cartella: senza, ti ritrovi uploads/3/ e tutte le immagini rotte. Poi i temi — quello attivo e, se è un tema figlio, anche il genitore — e i plugin dell’inventario, presi dalle rispettive cartelle della rete.

Un’ultima cosa da cercare prima di chiudere: eventuali plugin must-use in wp-content/mu-plugins/. Sono attivi su tutta la rete senza comparire nell’elenco dei plugin, spesso contengono il codice specifico del progetto, e sono la cosa che manca più spesso all’arrivo perché nessuno si ricorda che esistono.

Preparare l’installazione singola

Sul nuovo spazio serve un’installazione di WordPress pulita, della stessa versione della rete di partenza, con un database vuoto e le sue credenziali in wp-config.php. La procedura ordinaria — creazione del database, permessi, primo setup — è quella di sempre e l’ho descritta in installare e configurare WordPress. Qui contano tre cose che in una migrazione normale non ci sono.

Le costanti del multisito vanno tolte

È l’omissione che fa fallire più estrazioni, e il sintomo è un sito che non si apre affatto. Se copi il wp-config.php della rete come base, dentro ci sono le costanti che dicono a WordPress di comportarsi da multisito: WordPress prova a caricare il codice della rete, non trova le tabelle wp_blogs e wp_site, e si ferma. Queste sette righe devono sparire dal nuovo wp-config.php:

define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'dominio.it' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Sono esattamente le costanti che WordPress fa aggiungere quando si crea una rete, e il blocco è generato dal core in wp-admin/includes/network.php: il valore di SUBDOMAIN_INSTALL e quelli di dominio e percorso cambiano da installazione a installazione, i nomi no. Il modo più pulito di procedere resta comunque non copiare il vecchio wp-config.php, ma partire da quello generato dall’installazione nuova e riportarci a mano solo il prefisso e le eventuali costanti personalizzate.

L’.htaccess va rigenerato

Anche l’.htaccess di una rete contiene regole di rewrite specifiche del multisito, che riscrivono i percorsi dei file e delle pagine di amministrazione dei sottositi. Su un sito singolo non servono e fanno danno. Si sostituisce l’intero blocco con quello standard di WordPress, oppure — più semplice — si cancella il file e si salva di nuovo la struttura dei permalink da Impostazioni → Permalink: WordPress lo riscrive da solo, corretto.

Requisiti e permessi

Sul versante server, il riferimento è la pagina ufficiale dei requisiti di WordPress, che alla data di questa verifica raccomanda PHP 8.3 o superiore e MariaDB 10.11+ o MySQL 8.0+. Versioni precedenti continuano a funzionare, ma sono fuori supporto: il criterio che invecchia meno è «una versione di PHP che riceve ancora aggiornamenti di sicurezza», non un numero da ricopiare.

Sui permessi dei file, l’estrazione è il momento in cui è più facile sbagliarli, perché i file arrivano da un altro server con proprietari diversi. Vale la pena rimetterli a posto subito, insieme agli altri interventi di base descritti nella guida a come configurare la sicurezza di WordPress: un sito appena migrato è un sito che nessuno sta ancora guardando.

Importare: prefissi, ruoli e media

L’import in sé è una riga:

wp db import sito3.sql

Quello che viene dopo è la parte che distingue una migrazione riuscita da un sito che si apre e non funziona.

I riferimenti al sottosito rimasti dentro i dati

Rinominare le tabelle non basta, perché il numero del sottosito compare anche dentro due tipi di record, e lì la sostituzione va fatta esplicitamente. Il primo è il nome dell’opzione che contiene la definizione dei ruoli: WordPress la cerca componendo il prefisso del sito con la stringa user_roles, come stabilisce la proprietà role_key della classe WP_Roles. Nel sottosito 3 si chiama wp_3_user_roles e nel sito singolo deve chiamarsi wp_user_roles:

UPDATE wp_options SET option_name = 'wp_user_roles'
WHERE option_name = 'wp_3_user_roles';

Il secondo è il più insidioso, perché riguarda una tabella che non hai nemmeno esportato. I ruoli degli utenti non stanno nella tabella degli utenti: stanno in wp_usermeta, sotto una chiave che contiene anch’essa il prefisso del sito — wp_3_capabilities — come stabilisce la proprietà cap_key della classe WP_User. È per questo che un sito estratto correttamente sotto ogni altro aspetto ti lascia fuori dalla bacheca: gli utenti ci sono, ma nessuno di loro risulta amministratore.

UPDATE wp_usermeta SET meta_key = 'wp_capabilities'
WHERE meta_key = 'wp_3_capabilities';

UPDATE wp_usermeta SET meta_key = 'wp_user_level'
WHERE meta_key = 'wp_3_user_level';

Se hai preferito non portarti dietro le tabelle utenti — scelta legittima, e spesso la più pulita quando la rete ha centinaia di account che non c’entrano con questo sito — la strada alternativa è crearne uno nuovo da riga di comando e riassegnargli i contenuti:

wp user create nome [email protected] --role=administrator
wp post update $(wp post list --post_type=post,page --format=ids) --post_author=2

Gli URL, sul database nuovo

Se non l’hai già fatto in fase di export, è ora il momento. Sul sito singolo --all-tables non è più pericoloso, perché non c’è nessun altro sito nel database — ma conviene comunque un giro a vuoto prima, con --dry-run, per vedere quante sostituzioni verranno fatte e dove:

wp search-replace 'https://dominio.it/sito3' 'https://nuovodominio.it' --dry-run
wp search-replace 'https://dominio.it/sito3' 'https://nuovodominio.it' --skip-columns=guid

Attenzione a un percorso che il search-replace sugli URL non intercetta: dentro i contenuti e nei metadati degli allegati i media hanno ancora il percorso vecchio, /wp-content/uploads/sites/3/. Va sostituito a parte:

wp search-replace '/wp-content/uploads/sites/3/' '/wp-content/uploads/' --skip-columns=guid

Poi si rigenerano i permalink e si svuota ogni cache:

wp rewrite flush --hard
wp cache flush

I quattro punti che si rompono, e come si vedono

Dopo l’import il sito si apre, e la tentazione è dichiararlo fatto. Questi quattro controlli richiedono un quarto d’ora e sono quelli che intercettano i problemi che altrimenti si scoprono in produzione.

1. I ruoli

Il primo, perché senza è impossibile fare gli altri. Verifica che esista almeno un amministratore e che sia tu:

wp user list --field=user_login --role=administrator

Se la lista è vuota, non hai fatto la rinomina di wp_3_capabilities della sezione precedente. Il rimedio è quello, non la reinstallazione.

2. Le tassonomie

Apri un archivio di categoria e un archivio di tag. Se gli articoli ci sono ma gli archivi sono vuoti, mancano le quattro tabelle dei termini: torna all’export. È il modo più veloce per accorgersene, e va fatto adesso perché più tardi si confonde con un problema di permalink.

3. I media e le miniature

Controlla che le immagini si vedano dentro gli articoli, non solo nella Libreria media: sono due percorsi diversi e il secondo può funzionare mentre il primo è rotto. Se le immagini a piena risoluzione ci sono ma le miniature no, il file c’è e mancano solo le dimensioni intermedie, che si ricostruiscono. Il plugin storicamente usato per questo, Regenerate Thumbnails, sul repository di WordPress.org riporta oggi l’avviso di non essere stato testato con le ultime tre versioni maggiori di WordPress: prima di installarlo, controlla lo stato aggiornato sulla sua scheda. WP-CLI fa la stessa cosa senza aggiungere un plugin al sito:

wp media regenerate --yes

4. WooCommerce, se c’è

Un negozio aggiunge tabelle proprie, che hanno il prefisso del sottosito e non compaiono in --scope=blog: vanno prese con --all-tables-with-prefix come visto sopra. Quali siano dipende da come lo store archivia gli ordini. Dalla versione 8.2 di WooCommerce, uscita nell’ottobre 2023, le nuove installazioni usano per impostazione predefinita l’archiviazione ad alte prestazioni (HPOS), che salva gli ordini in quattro tabelle dedicate: wc_orders, wc_order_addresses, wc_order_operational_data e wc_orders_meta, ciascuna con il prefisso del sito davanti. Gli store più vecchi, o quelli che non hanno migrato, tengono invece gli ordini fra i contenuti, in posts e postmeta. Prima di esportare, verifica quale dei due sistemi è attivo: in WooCommerce → Impostazioni → Avanzate → Funzionalità lo dice esplicitamente.

Fatta la migrazione, apri un ordine e un prodotto variabile, e prova un pagamento in modalità test. Le licenze dei gateway sono legate al dominio e vanno riattivate: è la cosa che si scopre sempre al primo ordine vero. Sui plugin da tenere e su quelli da lasciare indietro, i criteri sono negli strumenti da integrare in WooCommerce.

Un quinto controllo, se il sito ha traffico: la cache. La configurazione della rete non si porta dietro, e un sito appena migrato spesso gira senza cache di pagina senza che nessuno se ne accorga. Fra le due opzioni più diffuse ho messo a confronto W3 Total Cache e WP Rocket: qui basta verificare che una delle due sia attiva e stia effettivamente servendo pagine statiche.

Il passaggio in produzione

Da qui in avanti l’estrazione non ha più niente di specifico: hai un sito WordPress autonomo e funzionante su un ambiente nuovo, e il problema che resta — farlo diventare il sito pubblico senza che nessuno veda una pagina di errore — è quello di qualsiasi trasloco. TTL del DNS abbassato con almeno ventiquattro ore di anticipo, prova completa su staging, cutover, sincronizzazione dei contenuti aggiunti nel frattempo: la sequenza è quella che ho descritto per spostare un sito senza interruzioni di servizio, monitoraggio delle prime ore compreso.

Due cose però restano tue, e vanno fatte sulla vecchia rete, non sul sito nuovo. La prima: i redirect 301 dai vecchi indirizzi. Se il sottosito stava su un percorso come dominio.it/sito3/, quel percorso continua a esistere finché la rete esiste, e va rimandato al nuovo dominio da lì — non dal sito appena migrato, dove nessuno arriverà mai. La seconda: non rimuovere il sottosito dalla rete finché i redirect non hanno lavorato per qualche settimana e Search Console non mostra le pagine nuove al posto delle vecchie. Su cosa controllare dopo il passaggio, la checklist SEO on-page copre canonical, titoli e struttura degli heading, che è dove si vedono per primi i danni di una migrazione fatta di fretta.

Domande frequenti

Hai un sottosito da estrarre?

Sono Alessandro Aili, sviluppatore WordPress. Se hai una rete multisito e uno dei siti deve diventare autonomo — perché cambia proprietario, perché ha bisogno di plugin che gli altri non possono avere, o perché è semplicemente cresciuto troppo — posso occuparmene io, oppure guardare con te il piano prima che tu lo esegua. Le reti con personalizzazioni profonde meritano un’occhiata preliminare: è lì che si decide se l’estrazione è una giornata di lavoro o un progetto. Scrivimi dalla pagina contatti.