Quattro siti aziendali, uno per area geografica, iniziano a usare moduli e aggiornamenti diversi: tenerli in ordine diventa presto un lavoro a sé. WordPress Multisite può riunirli in un’unica installazione, purché la rete abbia regole tecniche davvero comuni; se ogni sito deve restare indipendente, il risparmio iniziale può trasformarsi in un vincolo.
Una rete funziona quando i siti condividono governance e manutenzione
- Un’unica installazione gestisce più siti con file core comuni.
- Ogni sito mantiene contenuti e tabelle dedicate, mentre temi e plugin sono gestiti a livello di rete.
- Sottodomini e sottocartelle richiedono configurazioni diverse: decidere l’indirizzo dopo la migrazione complica il lavoro.
- Un problema condiviso può coinvolgere più siti; backup e verifiche devono considerare l’intera rete.
La rete conviene se i siti seguono le stesse regole
Una sede di Milano e una di Palermo possono avere pagine e contatti diversi, ma usare la stessa identità visiva, gli stessi moduli e un processo editoriale comune. In questo caso Multisite mette i siti sotto un unico Network Admin, cioè il pannello da cui si gestiscono installazione, temi, plugin e autorizzazioni della rete.
La documentazione ufficiale di WordPress precisa che i siti condividono i file principali e possono condividere temi e plugin, mentre conservano tabelle separate per i propri dati. La distinzione è utile: una modifica tecnica può essere centralizzata, ma contenuti e configurazioni specifiche del singolo sito non diventano automaticamente un patrimonio comune.
Per decidere, uso una soglia pratica: se almeno tre quarti delle regole tecniche sono comuni, valuterei una rete; se ogni sito richiede un ciclo di aggiornamenti, un hosting o plugin diversi, preferirei installazioni separate. È una regola organizzativa, non una funzione di WordPress, ma costringe a verificare la dipendenza reale tra i progetti prima di migrare.
Immagina quattro siti regionali con un tema, un modulo di contatto e un solo gruppo che approva gli aggiornamenti. La rete evita di replicare la stessa manutenzione quattro volte. Se invece un sito vende online, un altro deve restare statico e gli altri appartengono a clienti diversi, la condivisione riduce la libertà di intervenire su ciascun progetto. Io sceglierei Multisite nel primo caso, dove la governance comune esiste già, e non nel secondo, dove sarebbe imposta dall’architettura.
Sottodomini e sottocartelle vanno decisi prima della migrazione
La forma dell’indirizzo sembra un dettaglio grafico, finché non bisogna configurare DNS e server. Una rete basata su sottodomini usa indirizzi come negozio.azienda.it; una rete basata su sottocartelle usa percorsi come azienda.it/negozio. La scelta dipende anche dall’hosting e dalla struttura del WordPress già attivo.
Per i sottodomini, il server deve indirizzare i vari nomi alla stessa installazione; la creazione automatica di nuovi siti richiede inoltre sottodomini wildcard. Con le sottocartelle la configurazione è diversa: la guida ufficiale segnala che non si può scegliere questo tipo di rete se l’installazione esistente ha più di un mese, a causa dei permalink già presenti. È il genere di limite che può smentire il consiglio generico di “attivare Multisite quando serve”.
Puoi associare alla rete anche domini distinti, ma il collegamento richiede una configurazione aggiuntiva. In ogni caso, verifica prima DNS, regole del server e riscrittura degli indirizzi; la documentazione menziona, per esempio, mod_rewrite su Apache. Prima dell’attivazione, fai un backup di file e database e definisci gli URL: cambiare il dominio di siti già avviati può rendere la migrazione più delicata.
I plugin si installano centralmente, ma non sempre si attivano per tutti
Qui nasce un equivoco frequente: avere un solo catalogo di plugin non significa che ogni sito debba usare gli stessi. Un amministratore di rete può installare un plugin e poi consentire che i singoli siti lo attivino, oppure attivarlo a livello di rete. Installazione e attivazione sono decisioni distinte.
La differenza aiuta a contenere le funzioni superflue. Un sito dedicato alle sedi può usare il modulo per le mappe, mentre un portale interno mantiene solo gli strumenti che gli servono; però un aggiornamento del plugin condiviso può coinvolgere più siti. Prima di aggiungerlo, controlla che supporti Multisite e prova l’aggiornamento in un ambiente di staging, cioè una copia separata usata per verifiche.
Anche gli utenti vanno pianificati. La rete gestisce gli account a livello comune, ma ruoli e accessi ai singoli siti devono essere assegnati con attenzione: chi amministra un sito non dovrebbe ricevere automaticamente i poteri del super amministratore. Per un’azienda, separare questi permessi riduce gli errori e rende più chiaro chi può cambiare impostazioni che riguardano tutti.
Un errore su un sito può avere cause diverse da un guasto di rete
Quando un sottosito mostra un errore, la tentazione è intervenire subito sul core o disattivare plugin a caso. Conviene prima capire se il problema riguarda un solo sito, un componente condiviso o il collegamento dell’indirizzo: la diagnosi evita modifiche che si propagano all’intera rete.
| Situazione | Possibile causa | Intervento iniziale |
|---|---|---|
| Un solo sito non carica dopo un cambio di URL | Dominio, DNS o percorso non corrispondenti alla configurazione del sito | Controlla l’indirizzo assegnato in Network Admin e la risoluzione DNS prima di cambiare regole globali. |
| Più siti mostrano lo stesso errore dopo un aggiornamento | Plugin o tema attivato a livello di rete | Verifica l’ultimo aggiornamento nell’ambiente di staging e ripristina il backup se il problema è esteso. |
| Un utente accede a un sito ma non a un altro | Account presente nella rete, ma ruolo non assegnato al secondo sito | Controlla i permessi di quel sito senza promuovere l’utente a super amministratore. |
| La dashboard è lenta, mentre i siti pubblici sembrano normali | Query o cache del pannello, oppure un plugin amministrativo | Misura il carico e disattiva le modifiche una alla volta in staging, così individui il componente coinvolto. |
Un dettaglio spesso trascurato è che Multisite non garantisce prestazioni migliori: riduce la duplicazione dell’installazione, ma i siti continuano a usare lo stesso ambiente server. Per un progetto aziendale che cresce, misura anche database, cache e traffico dei singoli siti; un collo di bottiglia condiviso può rallentare l’intera rete.
La scelta più sostenibile è quella che riduce manutenzione senza legare progetti incompatibili
Accorpare i siti può ridurre aggiornamenti ripetuti, installazioni duplicate e lavoro operativo, soprattutto quando l’azienda applica le stesse regole editoriali e tecniche a ogni sede. Il vantaggio, però, dipende dalla disciplina di rete: backup completi, test prima degli aggiornamenti e responsabilità chiare devono accompagnare la centralizzazione.
Se i siti condividono componenti e persone responsabili, Multisite può rendere più ordinata la gestione digitale. Se hanno esigenze divergenti o devono poter cambiare hosting e strumenti in autonomia, mantenerli separati protegge la flessibilità. Prima di unificare, confronta ciò che davvero condividono: è quel confronto, più del numero di dashboard, a indicare quale architettura produrrà meno sprechi nel tempo.