WordPress Multisite è una funzionalità nativa di WordPress che permette di creare e amministrare più siti all’interno della stessa installazione. I siti appartengono a una rete comune: condividono il core di WordPress e possono condividere temi e plugin, mentre mantengono contenuti e configurazioni specifiche.
La distinzione più importante, però, viene prima della configurazione tecnica. WordPress Multisite non è semplicemente uno strumento per gestire tanti siti da una sola dashboard. È una scelta architetturale.
Se i siti devono appartenere realmente alla stessa rete, condividere infrastruttura, governance e componenti, Multisite può semplificare molto il lavoro. Se invece stai gestendo siti di clienti indipendenti, con esigenze, hosting, plugin e cicli di manutenzione diversi, creare una rete potrebbe introdurre più dipendenze di quante ne elimini.
La documentazione ufficiale di WordPress Multisite definisce infatti Multisite come una funzione che consente di creare più siti gestiti attraverso una sola installazione WordPress.
In questa guida vediamo quindi non solo come attivare WordPress Multisite, ma soprattutto quando conviene usarlo, quando è preferibile mantenere installazioni separate e quali conseguenze comporta per domini, utenti, plugin, SEO, sicurezza, backup e manutenzione.
Cos’è WordPress Multisite e come funziona una rete
Con una normale installazione WordPress hai un sito associato alla propria installazione. Se vuoi creare un secondo progetto completamente indipendente, normalmente installi nuovamente WordPress con i suoi file, il suo database e la sua configurazione.
Multisite cambia questo modello.
Una rete utilizza una sola installazione dei file core di WordPress. I siti secondari non sono copie complete della directory WordPress: sono siti gestiti all’interno della stessa infrastruttura. Nella configurazione standard condividono il database, ma WordPress crea tabelle separate per i dati specifici dei diversi siti e directory distinte per i relativi media.
Se vuoi prima chiarire la struttura di una normale installazione, trovi il quadro generale nella nostra guida a WordPress.
Cosa condividono i siti e cosa rimane separato
Pensare a Multisite come a una serie di siti “clonati” porta facilmente a decisioni sbagliate. È più corretto immaginarlo come una piattaforma comune che ospita più siti logicamente distinti.
In particolare:
| Elemento | In una rete Multisite |
|---|---|
| Core WordPress | condiviso |
| Installazione dei plugin | condivisa a livello di rete |
| Installazione dei temi | condivisa a livello di rete |
| Contenuti | separati per sito |
| Impostazioni del sito | separate |
| Tabelle principali dei contenuti | separate per sito |
| Media | organizzati separatamente per sito |
| Gestione superiore della rete | centralizzata |
| Dominio/URL | può essere differente per ciascun sito |
Questa architettura è ciò che genera sia i vantaggi sia i limiti di Multisite.
Aggiornare il core significa intervenire sulla piattaforma che sostiene tutta la rete. Installare un tema significa renderne i file disponibili nell’installazione comune. Allo stesso tempo, modificare un articolo o le impostazioni di un singolo sito non modifica automaticamente gli altri.
La stessa documentazione WordPress chiarisce che i contenuti dei siti non vengono condivisi automaticamente tra i membri della rete.
Network Admin, Super Admin e amministratori dei singoli siti
Con l’attivazione di Multisite compare un livello amministrativo aggiuntivo: Network Admin.
Il Super Admin controlla la rete e dispone di capacità che il normale amministratore di un singolo sito non possiede. Per esempio, nella configurazione standard gli amministratori locali non possono installare autonomamente nuovi temi o plugin: queste operazioni restano sotto il controllo dell’amministrazione della rete.
Questo è un vantaggio quando vuoi imporre uno stack tecnico coerente. È invece un limite se ciascun sito deve avere piena autonomia.
La differenza fra Super Admin, Administrator, Editor e gli altri ruoli diventa quindi ancora più importante rispetto a una normale installazione. Se devi rivedere permessi e capacità, consulta anche la guida ai ruoli WordPress e alla gestione degli utenti.
WordPress Multisite o siti WordPress separati: cosa scegliere
Questa è la decisione che dovrebbe precedere qualsiasi modifica a wp-config.php.
Avere molti siti non è, da solo, un motivo sufficiente per usare Multisite. La domanda corretta è un’altra: quei siti devono essere parti della stessa infrastruttura oppure devono soltanto essere amministrati in modo più efficiente?
Il confine può sembrare sottile, ma cambia completamente la progettazione.
| Scenario | Multisite | Installazioni separate |
|---|---|---|
| Siti dello stesso progetto con stack comune | spesso adatto | possibile, ma più ridondante |
| Sedi o divisioni della stessa organizzazione | spesso adatto | dipende dall’autonomia richiesta |
| Rete editoriale centralizzata | spesso adatto | possibile |
| Siti di clienti indipendenti | da valutare con cautela | spesso più flessibile |
| Hosting differenti per ogni sito | poco adatto | adatto |
| Plugin e temi molto diversi | meno conveniente | più flessibile |
| Proprietà e credenziali completamente separate | meno naturale | adatto |
| Necessità di migrare ogni sito autonomamente | più complesso | più semplice |
| Provisioning di molti siti omogenei | interessante | richiede altra automazione |
Quando una rete Multisite ha davvero senso
Multisite esprime il suo vantaggio quando la centralizzazione è una caratteristica del progetto, non un semplice desiderio di avere meno dashboard aperte.
Un’azienda con siti regionali che utilizzano gli stessi componenti, un’università con siti per dipartimenti, una rete di portali con governance tecnica comune o una piattaforma che deve creare molti siti secondo uno standard condiviso sono scenari coerenti con questo modello.
In questi casi avere un solo core e un catalogo centrale di temi e plugin riduce la duplicazione e permette di stabilire regole tecniche comuni.
Multisite può essere interessante anche per sistemi di provisioning o piattaforme WordPress-as-a-Service, ma qui si entra in progetti più avanzati: Multisite offre l’architettura di base, non trasforma automaticamente WordPress in un SaaS completo. Billing, onboarding, isolamento delle funzionalità, limiti degli account e automazioni richiedono progettazione aggiuntiva.
Quando è meglio mantenere installazioni indipendenti
Se ogni sito deve poter evolvere senza dipendere dagli altri, l’indipendenza diventa un vantaggio.
È il caso tipico di molti portfolio di clienti di un’agenzia: un cliente può voler cambiare hosting, un altro utilizzare uno stack completamente differente, un altro ancora richiedere una migrazione o consegna completa del progetto.
Inserire tutti questi siti nella stessa rete significa collegarne maggiormente i cicli tecnici.
Lo stesso vale quando i siti hanno requisiti molto diversi in termini di plugin, performance, sicurezza o aggiornamenti. In quel caso un unico ambiente condiviso può diventare un vincolo.
Multisite e dashboard multi-sito non risolvono lo stesso problema
Questo punto crea molta confusione.
Strumenti per la gestione di più installazioni WordPress possono centralizzare attività come aggiornamenti, monitoraggio e backup senza trasformare i siti in membri della stessa rete WordPress.
ManageWP, per esempio, nasce come dashboard per gestire più siti WordPress e supporta anche network Multisite come livello di gestione aggiuntivo.
MainWP appartiene alla stessa categoria generale della gestione centralizzata, ma la sua documentazione corrente precisa che le configurazioni Multisite non hanno supporto ufficiale dedicato.
La differenza pratica è questa:
Multisite decide come sono costruiti i siti; una dashboard multi-sito decide come li amministri.
Se vuoi soltanto evitare di entrare manualmente in dieci installazioni separate, non devi necessariamente convertirle in Multisite.
Vantaggi e limiti di WordPress Multisite nella pratica
Il vantaggio principale di Multisite è la standardizzazione. Il limite principale è esattamente lo stesso: i siti diventano più interdipendenti.
Dove la gestione centralizzata fa davvero risparmiare lavoro
Con una rete puoi amministrare temi e plugin a livello centrale, gestire la disponibilità dei componenti per i vari siti e controllare gli aspetti generali della rete dal Network Admin.
Il beneficio cresce quando molti siti devono utilizzare una base tecnica simile.
Se dieci siti devono utilizzare la stessa versione di WordPress e lo stesso insieme di componenti, evitare dieci installazioni completamente separate può semplificare manutenzione e governance.
Ma questo non significa che ogni operazione diventi automaticamente globale. I contenuti restano separati e molte impostazioni continuano a essere specifiche del singolo sito.
Il rovescio della medaglia: dipendenze e failure domain condivisi
Una rete centralizzata concentra anche il rischio.
Un aggiornamento del core riguarda l’intera installazione. Un plugin attivato a livello di rete opera su tutti i siti interessati. Un problema infrastrutturale alla base della rete può quindi avere un impatto più ampio rispetto a quello di un guasto su una singola installazione autonoma.
Non è un motivo per evitare Multisite. È un motivo per usarlo quando la centralizzazione giustifica questa dipendenza.
Per lo stesso motivo, staging, procedure di aggiornamento e possibilità di ripristino diventano più importanti man mano che aumenta il valore della rete.
Compatibilità, autonomia e migrazione dei singoli siti
Non puoi dare per scontato che un plugin compatibile con WordPress funzioni allo stesso modo in Multisite.
La documentazione ufficiale raccomanda esplicitamente di verificare la compatibilità del singolo plugin con l’ambiente Multisite.
La ragione è semplice: un’estensione può essere stata progettata assumendo un solo sito, una sola serie di impostazioni o un determinato modello di permessi.
Anche l’uscita dalla rete richiede più attenzione. Un subsite utilizza elementi dell’installazione comune e dati organizzati secondo l’architettura Multisite; renderlo nuovamente un sito standalone è quindi una vera migrazione, non la semplice copia di una cartella.
Per questo, se sai già che i siti dovranno essere frequentemente consegnati, separati o spostati su infrastrutture indipendenti, considera questo costo prima di scegliere Multisite.
Come attivare WordPress Multisite
WordPress non richiede un plugin per abilitare la modalità Multisite. La funzione è nel core, ma va esplicitamente attivata e configurata.
Prima di intervenire su un sito esistente, è importante lavorare con un backup recuperabile. La procedura ufficiale WordPress richiede inoltre di verificare il funzionamento dei permalink e indica di disattivare temporaneamente i plugin durante la creazione iniziale della rete.
Cosa verificare prima di creare la rete
Prima di modificare la configurazione, definisci almeno questi aspetti:
- struttura domain-based o path-based;
- gestione DNS se userai sottodomini o domini personalizzati;
- compatibilità dell’hosting con Multisite;
- accesso ai file di configurazione;
- compatibilità dei plugin essenziali;
- backup di file e database;
- strategia di ripristino in caso di errore.
Un altro aspetto da decidere subito è l’architettura degli URL. WordPress consente di modificare successivamente il tipo di rete in alcune configurazioni, ma la documentazione avverte che la riconfigurazione può non essere semplice.
Abilitare Multisite in wp-config.php
Apri wp-config.php nella directory dell’installazione e, prima del punto in cui WordPress termina il caricamento della configurazione, aggiungi:
/* Multisite */ define( 'WP_ALLOW_MULTISITE', true );
Salva il file e ricarica l’amministrazione.
La voce per creare la rete comparirà in Strumenti → Configurazione della rete. È esattamente il passaggio previsto dalla procedura ufficiale di WordPress.
Creare la rete da Strumenti → Configurazione della rete
Nella schermata di configurazione WordPress ti permette, quando l’installazione lo consente, di scegliere tra una rete basata su:
- sottodomini, come
negozio.example.com; - sottocartelle, come
example.com/negozio/.
Dovrai inoltre definire il nome della rete e l’indirizzo email del Network Admin.
Non scegliere la struttura sulla base di una presunta scorciatoia SEO. La scelta dovrebbe riflettere il rapporto reale tra i siti, le esigenze DNS, la gestione e l’architettura prevista per il progetto.
Applicare le modifiche generate a wp-config.php e al server
Dopo la creazione della rete, WordPress mostra le direttive da aggiungere alla configurazione.
Usa quelle generate dalla tua installazione, invece di copiare alla cieca configurazioni prese da tutorial datati.
Il modo in cui vengono applicate le regole dipende anche dal web server. Su installazioni Apache interviene normalmente .htaccess; con altre configurazioni server, come Nginx, il routing va gestito nel relativo ambiente.
Dopo aver completato la procedura ed effettuato nuovamente l’accesso, troverai My Sites → Network Admin, da cui puoi amministrare la rete, i siti e le impostazioni generali.
Sottodomini, sottocartelle e domini personalizzati
La struttura iniziale definisce come WordPress assegna gli indirizzi ai siti creati all’interno della rete.
Una rete domain-based può utilizzare indirizzi come:
roma.example.com
Una rete path-based può usare:
example.com/roma/
Esiste poi una terza esigenza pratica: far apparire un subsite con un dominio completamente autonomo, come:
example-roma.it
È qui che entra in gioco il domain mapping.
Rete domain-based o path-based: cosa cambia
La differenza non riguarda soltanto l’aspetto dell’URL.
I sottodomini richiedono una corretta configurazione DNS. Le sottocartelle mantengono invece i siti sotto lo stesso hostname e organizzano la rete attraverso i percorsi.
La scelta può dipendere da come vuoi rappresentare organizzazioni, divisioni, mercati o progetti differenti.
Per capire cosa accade quando colleghi hostname e indirizzi IP, puoi approfondire cos’è il DNS e come funziona.
Quando serve il wildcard DNS
Una delle semplificazioni più diffuse è: “se scegli Multisite con sottodomini devi sempre configurare un wildcard DNS”.
La documentazione WordPress corrente è più precisa: il wildcard DNS è necessario per la creazione on-demand di siti domain-based, non come requisito universale di ogni possibile rete basata su domini.
Per esempio, se il sistema deve permettere la generazione automatica di:
cliente1.example.comcliente2.example.comcliente3.example.com
una regola wildcard può evitare di creare manualmente un record DNS per ogni nuovo hostname.
Se i siti vengono invece predisposti manualmente con configurazioni DNS specifiche, lo scenario può essere differente.
Come funziona oggi il domain mapping
Il domain mapping permette di associare un subsite a un dominio che non mostra il dominio principale della rete.
Per esempio:
cliente.network.example → cliente.it
Il punto importante è che da WordPress 4.5 il domain mapping è una funzione nativa. Non serve più presentare un plugin di domain mapping come requisito standard, come avveniva nelle installazioni precedenti.
La documentazione ufficiale sul domain mapping indica la necessità di configurare correttamente DNS, certificati SSL e indirizzo del sito nel Network Admin.
Con domini distinti, ogni dominio pubblico deve inoltre essere gestito correttamente sul piano HTTPS.
Sottodomini o sottocartelle: non esiste un vincitore SEO automatico
Non sceglierei mai example.com/sito/ soltanto perché “eredita più autorità”, né sito.example.com perché dovrebbe offrire un vantaggio particolare.
La SEO Starter Guide di Google suggerisce di scegliere tra sottodomini e sottocartelle sulla base di ciò che ha senso per il business e per la gestione del sito.
Quindi la domanda corretta non è “quale struttura ranka meglio?”, ma:
questi siti devono essere percepiti e gestiti come sezioni dello stesso progetto o come entità maggiormente separate?
L’architettura SEO viene dopo questa risposta, non prima.
Gestire siti, utenti, temi e plugin da Network Admin
Una volta attivata la rete, il Network Admin diventa il punto di controllo delle funzioni che appartengono all’infrastruttura comune.
Creare e amministrare i siti della rete
Dal pannello Sites puoi visualizzare i membri della rete, aggiungere siti e intervenire sulle loro impostazioni.
L’amministratore del network controlla quindi la struttura globale, mentre i normali backend continuano a essere utilizzati per il lavoro specifico sui singoli siti.
Questo doppio livello è importante: Multisite non sostituisce il backend di ogni sito con una sola schermata gigantesca. Aggiunge un livello amministrativo sopra i siti.
Gestire utenti e privilegi del Super Admin
Un account può essere associato a più siti della stessa rete con ruoli differenti.
Il Super Admin dispone invece di privilegi a livello di network e deve essere trattato come un account ad alto impatto: se viene compromesso, il problema non riguarda soltanto un singolo sito.
Per questa ragione conviene limitare il numero di Super Admin e proteggere gli account privilegiati con misure adeguate, inclusa quando appropriata l’autenticazione a due fattori per WordPress.
Installazione, attivazione per sito e Network Activation dei plugin
La terminologia può creare confusione.
Installare un plugin significa aggiungerne i file all’installazione condivisa.
Successivamente, a seconda del plugin e delle impostazioni della rete, puoi:
- attivarlo soltanto su determinati siti;
- renderne disponibile l’attivazione agli amministratori locali;
- eseguire una Network Activation, che lo rende attivo a livello di rete.
Un plugin attivato a livello di network non può essere semplicemente disattivato dal normale amministratore del singolo sito. La documentazione ufficiale dettaglia questo comportamento nella sezione dedicata alla Multisite Network Administration.
Prima di installare un componente importante, verifica sempre che lo sviluppatore ne dichiari o documenti il comportamento in Multisite.
Come funzionano i temi in una rete Multisite
Anche i temi sono installati nell’ambiente condiviso.
Abilitare un tema a livello di rete, però, non significa applicarlo automaticamente a tutti i siti: significa renderlo disponibile affinché i siti autorizzati possano usarlo.
Questo permette di controllare il catalogo grafico della rete senza obbligare necessariamente ogni sito a utilizzare lo stesso tema.
È un buon esempio del modello Multisite: centralizzi ciò che deve essere governato centralmente, ma mantieni una parte delle configurazioni a livello locale.
WordPress Multisite e SEO: cosa cambia davvero
WordPress Multisite non dovrebbe essere scelto come tattica SEO.
La struttura modifica l’organizzazione tecnica dei siti, ma non crea da sola qualità dei contenuti, autorevolezza, crawling efficiente o migliori posizionamenti.
Il vantaggio SEO, quando esiste, deriva indirettamente da una buona architettura, da una manutenzione coerente e dalla capacità di gestire correttamente i singoli siti. Lo stesso vale al contrario: una rete mal progettata può aumentare la complessità, ma Multisite in sé non è sinonimo di problema SEO.
Multisite non offre un vantaggio SEO automatico
Non esiste una ragione per aspettarsi che trasformare più installazioni in una rete aumenti automaticamente la loro visibilità organica.
Sottodomini, sottocartelle e domini mappati devono essere scelti in base all’architettura necessaria. Come visto, Google stesso non prescrive una delle due strutture come scelta universalmente migliore ai fini SEO.
Evita quindi formule come:
“sottocartella = SEO alta”
“sottodominio = SEO media”
Non descrivono il funzionamento della ricerca e possono portare a costruire l’intero network sulla premessa sbagliata.
Indicizzazione, canonical e sitemap vanno gestiti per i singoli siti
Ogni sito pubblica proprie URL e propri contenuti. La gestione dell’indicizzazione deve quindi riflettere la struttura reale delle pagine che vuoi rendere disponibili ai motori di ricerca.
Questo significa verificare per ciascun sito, quando pertinente:
- pagine che devono essere indicizzate;
- canonical;
- sitemap;
- redirect;
- robots directives;
- contenuti duplicati o eccessivamente simili;
- collegamenti interni;
- eventuali configurazioni internazionali.
Una rete tecnicamente centralizzata non rende automaticamente centralizzata la strategia SEO.
Se utilizzi Multisite per replicare siti partendo dallo stesso modello, presta particolare attenzione a non trasformare il template in una serie di siti con contenuti quasi identici. La standardizzazione tecnica può essere utile; la standardizzazione indiscriminata dei contenuti molto meno.
Sottodomini e sottocartelle: la scelta deve seguire l’architettura
Per una rete di dipartimenti dello stesso progetto, una struttura in sottocartelle potrebbe risultare naturale.
Per divisioni che devono avere maggiore separazione, i sottodomini possono essere più leggibili sul piano organizzativo.
Per brand con domini propri, il domain mapping può essere la soluzione coerente.
Nessuna di queste decisioni deve essere presa partendo da un presunto bonus di ranking. Prima definisci l’architettura del progetto; poi costruisci la configurazione SEO coerente con quell’architettura.
Sicurezza, backup e prestazioni in una rete Multisite
Multisite riduce alcune duplicazioni operative, ma aumenta l’importanza dell’infrastruttura condivisa.
Più siti dipendono dallo stesso ambiente, più devi sapere cosa succede quando quell’ambiente ha un problema.
Perché il rischio operativo può coinvolgere l’intera rete
Core, componenti installati e infrastruttura sono condivisi.
Di conseguenza, un errore a livello di network può avere un raggio di impatto più ampio rispetto a quello di un’installazione isolata.
La risposta non consiste nell’installare molti plugin di sicurezza a caso, ma nel ridurre la superficie di rischio con:
- account privilegiati limitati;
- aggiornamenti controllati;
- componenti realmente necessari;
- verifica della compatibilità Multisite;
- protezione dell’accesso amministrativo;
- staging quando il progetto lo giustifica;
- backup realmente ripristinabili.
Il principio è semplice: più aumenta la centralizzazione, più deve aumentare la disciplina operativa.
Backup e ripristino: pensare alla rete e al singolo sito
Prima della creazione di una rete WordPress raccomanda esplicitamente di eseguire il backup di database e file.
Dopo l’attivazione, però, la domanda diventa più articolata.
Non basta sapere che “esiste un backup”. Devi sapere:
posso ripristinare l’intera rete? Posso recuperare il singolo sito che ha un problema? Quanto tempo e quanti dati posso permettermi di perdere?
Per una piccola rete editoriale il livello di protezione può essere diverso da quello richiesto da una rete ecommerce o da una piattaforma con decine di siti.
Per questo non esiste una frequenza universale come “un backup al giorno conservato sette giorni” che sia corretta per ogni progetto. Frequenza, retention e tipo di backup devono seguire la criticità dei dati e gli obiettivi di recupero.
Soprattutto, un backup mai testato non dimostra che il ripristino funzioni.
Aggiornamenti, staging e autenticazione degli amministratori
Gli aggiornamenti di componenti condivisi meritano un approccio più prudente quando la rete è importante.
Su network critici è sensato verificare almeno gli aggiornamenti più delicati in un ambiente di staging rappresentativo prima della produzione.
Lo stesso principio vale per gli account Super Admin: meno persone hanno accesso ai privilegi di rete, più semplice è controllare la superficie amministrativa.
Non disattiverei invece REST API, XML-RPC o altre funzionalità come regola generale soltanto perché una rete deve essere “più sicura”. Una funzione va limitata quando esiste un rischio concreto e hai verificato che non serva al progetto, non per applicare una checklist generica.
Prestazioni e risorse condivise
Più siti non significano necessariamente problemi di performance, ma tutti dipendono dalla capacità dell’infrastruttura che sostiene la rete.
Se un sito genera un carico anomalo, utilizza query costose o subisce un picco importante, può consumare risorse disponibili anche per altri membri del network.
Caching, CDN e object cache possono essere utili in determinati scenari, ma non sostituiscono il dimensionamento dell’infrastruttura.
Prima di aggiungere strumenti, conviene capire dove si trova il collo di bottiglia: PHP, database, query, I/O, memoria, traffico, plugin o risorse disponibili.
Migrare, separare o far crescere una rete Multisite
Una buona decisione architetturale deve considerare non soltanto come il progetto funziona oggi, ma anche come potrebbe cambiare domani.
Aggiungere siti nuovi e incorporare progetti esistenti non sono la stessa cosa
Creare un nuovo subsite all’interno di una rete già configurata è un’operazione prevista dal modello Multisite.
Portare invece un sito standalone esistente nella rete significa migrare contenuti, media, utenti, impostazioni e spesso URL.
Se il sito ha già una storia, traffico organico o integrazioni esterne, la migrazione deve includere anche una verifica di redirect, canonical e collegamenti.
Non trattare quindi “aggiungere un sito” e “migrare un sito esistente nella rete” come procedure equivalenti.
Estrarre un singolo sito da Multisite richiede pianificazione
Lo stesso problema si presenta al contrario.
Se un subsite deve diventare un’installazione autonoma, devi ricostruire ciò che prima dipendeva dalla rete: dati, media, plugin, temi, configurazione e dominio.
Questo non rende Multisite una scelta irreversibile, ma introduce un costo di separazione che deve essere considerato soprattutto quando i siti appartengono a clienti o soggetti differenti.
Se la probabilità che un singolo progetto lasci la rete è alta, l’isolamento iniziale può valere più della comodità della centralizzazione.
Quando la crescita della rete suggerisce di ripensare l’architettura
Non esiste un numero di siti oltre il quale Multisite diventa automaticamente la scelta migliore.
Dieci siti estremamente omogenei possono essere un buon network. Cinque siti completamente differenti possono essere pessimi candidati.
Allo stesso modo, una rete nata correttamente può cambiare nel tempo: brand che diventano indipendenti, requisiti infrastrutturali differenti, ecommerce che crescono, team separati o nuove policy possono modificare il rapporto tra i siti.
La domanda da rifare periodicamente è quindi:
la condivisione dell’infrastruttura continua a offrire più valore delle dipendenze che crea?
Se la risposta cambia, può essere il momento di separare una parte del network o riprogettare l’architettura.
Conclusione
WordPress Multisite è una soluzione molto efficace quando più siti devono davvero comportarsi come una rete: stesso WordPress, governance centrale, componenti condivisi e un’infrastruttura progettata per essere amministrata come un unico sistema.
Ha molto meno senso quando l’unica esigenza è entrare più velocemente nei backend di siti che, per il resto, devono rimanere autonomi. In quello scenario le installazioni separate, eventualmente affiancate da una dashboard di gestione centralizzata, mantengono un isolamento che può diventare prezioso per migrazioni, clienti, sicurezza e crescita futura.
Prima di attivare Multisite, quindi, non partire da wp-config.php. Parti dalla relazione tra i siti.
Se condividono davvero infrastruttura e governance, Multisite è un candidato naturale. Se condividono soltanto il manutentore, probabilmente stai cercando un altro tipo di soluzione.
Se devi progettare, migrare o mettere in sicurezza una rete esistente e vuoi evitare che una scelta architetturale sbagliata diventi un problema operativo, puoi valutare il nostro servizio di assistenza e consulenza WordPress.