WordPress Multisite: pro, contro e quando NON conviene (anche per le agenzie)

Multisite è una di quelle funzionalità di WordPress che sembra sempre una buona idea finché non la metti in produzione con clienti reali. Sulla carta è elegante: un'installazione, un database, un admin, più siti che condividono core, plugin e temi. Nella realtà, il primo plugin che va in fatal error blocca non un sito ma l'intera rete. E l'agenzia che lo ha scelto per 'semplificare la gestione' si ritrova con un problema che non sa risolvere senza downtime per tutti i clienti contemporaneamente.

Il punto è che Multisite non è 'più siti in uno'. È 'un solo sito con più frontend'. Condivide tutto: il database (con prefissi di tabella per ogni subsite), i plugin, i temi, il core. Un aggiornamento del core è un aggiornamento per tutti. Un plugin disattivato a livello di rete è disattivato per tutti. Un plugin incompatibile con un singolo subsite lo fa vedere a tutti. Non è una scalata, è un accoppiamento.

Quando Multisite funziona davvero

Ci sono scenari dove Multisite è la scelta corretta, e vale la pena essere onesti su quali. Funziona quando i siti sono omogenei per struttura, plugin e modello — una rete di blog con lo stesso tema, un'università con un sito per ogni dipartimento, un'azienda con un subsite per ogni divisione. In questi casi la condivisione è un vantaggio: un solo aggiornamento del core, un solo tema da mantenere, una sola configurazione di sicurezza. Il costo di gestione si divide per N.

Funziona anche quando i subsite non hanno bisogno di plugin personalizzati per cliente. Se ogni cliente vuole il suo plugin di booking, il suo gateway di pagamento, il suo tema custom, Multisite diventa un incubo — perché non puoi attivare un plugin solo su un subsite senza che il network admin lo permetta, e ogni plugin personalizzato è un punto di rottura per l'intera rete.

Il problema del singolo punto di rottura

L'argomento decisivo contro Multisite per le agenzie che gestiscono siti di clienti diversi è questo: un solo plugin incompatibile blocca l'intera rete. Se aggiorni il core e un plugin non compatibile va in fatal error, non è un sito giù — sono tutti giù. E il ripristino richiede di disabilitare il plugin problematico a livello di rete, il che significa downtime per ogni cliente mentre lo individui.

# Identifica il plugin problematico in una rete Multisite
# (da WP-CLI a livello di rete)

# Disabilita un plugin a livello di rete
wp plugin deactivate plugin-problematico --network

# Vedi quali plugin sono attivi a livello di rete (condivisi da tutti)
wp plugin list --status=active --network

# Vedi quali plugin sono attivi su un singolo subsite
wp plugin list --status=active --url=miosito.com/sito-1/

# Se il sito è giù e non sai quale plugin è:
wp plugin deactivate --all --network
# poi riattivali uno a uno per identificare il colpevole

Il database condiviso: più righe, più rischio

Multisite usa un database unico con prefissi di tabella per ogni subsite (wp_1_posts, wp_2_posts, ecc.) più tabelle condivise (wp_users, wp_blogs, wp_signups). Questo significa che una query sbagliata su un subsite, un plugin che fa un join mal scritto, o un bug nel core può impattare la performance dell'intero database. Su siti con molti subsite, la tabella wp_users può diventare enorme perché contiene tutti gli utenti di tutti i siti — e ogni query su quella tabella rallenta tutto.

Per le agenzie che gestiscono clienti diversi c'è un problema ancora più serio: la separazione dei dati. In Multisite gli utenti sono condivisi (un utente registrato su un subsite esiste a livello di rete). Se il cliente A e il cliente B sono sulla stessa rete Multisite e il cliente A ha un plugin con una vulnerabilità, il rischio si estende ai dati del cliente B. Non è isolamento, è esposizione.

Quando è meglio gestire siti separati

Per le agenzie che gestiscono siti di clienti diversi — ognuno con il suo plugin, il suo tema, la sua configurazione, il suo livello di servizio — la scelta migliore è quasi sempre siti separati, non Multisite. Questo significa più installazioni da aggiornare, ma significa anche isolamento completo: un plugin rotto sul sito del cliente A non tocca il cliente B. Un aggiornamento core può essere schedulato cliente per cliente, in base alla disponibilità di ciascuno. Un breach di sicurezza resta confinato.

# Gestione multi-sito con siti separati via WP-CLI
# (lo schema che usiamo per le agenzie in white label)

# Lista di tutti i siti gestiti (esempio)
sites=(
    "cliente1.com /var/www/cliente1"
    "cliente2.com /var/www/cliente2"
    "cliente3.com /var/www/cliente3"
)

# Aggiorna ogni sito in modo indipendente
for entry in "${sites[@]}"; do
    domain=$(echo $entry | awk '{print $1}')
    path=$(echo $entry | awk '{print $2}')
    echo "Aggiorno $domain..."
    cd $path
    wp core update --quiet
    wp plugin update --all --quiet
    wp theme update --all --quiet
done

Il caso d'uso dove Multisite è la scelta giusta

Per essere onesti fino in fondo: Multisite non è un anti-pattern, è uno strumento per un caso specifico. È la scelta giusta quando hai un'entità (azienda, università, network) che gestisce più siti omogenei sotto un'unica governance, con un team tecnico che può gestire la rete come un singolo sistema. In quel contesto la condivisione di core, plugin e tema è un vantaggio, non un rischio — perché chi decide per il sito A decide anche per il sito B, ed è lo stesso team.

Il punto di rottura è quando la governance si frammenta: cliente A vuole il suo plugin, cliente B il suo tema, cliente C non vuole aggiornare. A quel punto Multisite obbliga a compromessi che nessuno voleva. La domanda giusta da farsi prima di scegliere Multisite non è 'quanti siti abbiamo', ma 'i siti hanno lo stesso modello di governance e lo stesso set di plugin?'. Se la risposta è no, Multisite è quasi sempre la scelta sbagliata.

Per un'agenzia che gestisce multi-sito in white label, la scelta tra Multisite e siti separati dipende da questo: se i clienti sono omogenei (stesso tema base, stessi plugin, stessa struttura), Multisite può funzionare. Se ogni cliente è diverso, siti separati con gestione centralizzata via WP-CLI e dashboard è la soluzione che scala senza rischi.