Come creare e configurare un sito WordPress su WPMU DEV

Su WPMU DEV il punto non è “installare WordPress” e basta: il valore sta nel costruire un sito che nasca già con dominio, SSL, cache, backup e controlli minimi coerenti. Se salti la fase di verifica iniziale, il classico risultato è un sito apparentemente attivo ma con DNS non allineato, certificato in attesa, redirect incoerenti o wp-admin lento appena aumentano i plugin.

Qui sotto trovi un flusso operativo pensato per un ambiente hosting gestito su WPMU DEV, con l’obiettivo di arrivare a un sito WordPress funzionante e mantenibile, non solo “pubblicato”. L’ordine conta: prima inventario e prerequisiti, poi creazione del sito, quindi dominio e HTTPS, infine hardening e verifica prestazionale.

1. Prima di creare il sito: dominio, DNS e accesso

Prima di toccare il pannello, chiarisci tre cose: quale dominio userai, dove gestisci il DNS e chi deve avere accesso amministrativo. Se il DNS è già in mano a Cloudflare, al registrar o a un provider esterno, conviene decidere subito se WPMU DEV dovrà solo ospitare il sito o anche gestire parte del routing. Questo evita di creare un sito “pronto” che poi resta invisibile perché il record non punta ancora al cluster corretto.

Verifica il dominio con un controllo semplice dal terminale:

dig +short A esempio.it

dig +short AAAA esempio.it

dig +short CNAME www.esempio.it

Se i risultati non corrispondono alla destinazione attesa, il sito può anche essere creato correttamente ma resterà irraggiungibile o finirà su un vecchio origin. In questa fase cerca anche eventuali record AAAA non voluti: un IPv6 errato è una delle cause più banali di “funziona a metà” quando il browser preferisce quella via.

Se devi coinvolgere un team, raccogli in anticipo i permessi minimi: accesso al pannello WPMU DEV, accesso al DNS, accesso al registrar se serve modificare nameserver o deleghe. Non serve condividere password in chiaro: usa ruoli, inviti o vault aziendali.

2. Creazione del sito in WPMU DEV

La creazione del sito parte dal pannello WPMU DEV nella sezione dei siti/hosting. Il flusso tipico è semplice: aggiungi un nuovo sito, scegli l’ambiente WordPress, assegna un nome temporaneo o il dominio definitivo e completa il provisioning. In molti casi il provider prepara già stack, PHP, database e certificato di base; il dettaglio operativo può cambiare a seconda del piano, quindi il punto fermo è verificare cosa è stato effettivamente creato e cosa va ancora configurato.

Durante la creazione tieni a mente una regola pratica: il nome del sito nel pannello non è il dominio pubblico. Evita di confondere etichette interne con hostname reali, soprattutto se gestisci più ambienti. Una convenzione del tipo cliente-progetto-prod o cliente-progetto-staging riduce errori operativi quando devi fare restore, cambiare DNS o aprire ticket di supporto.

Appena il sito risulta creato, annota questi elementi:

• URL temporaneo o endpoint di preview
• versione PHP disponibile
• stato del database e eventuale accesso phpMyAdmin o strumenti equivalenti
• stato del certificato SSL iniziale
• eventuali backup automatici già attivi

Se uno di questi punti manca, non andare avanti a caso: serve capire se è una limitazione del piano, un ritardo di provisioning o un problema del backend. In pratica, prima osservi lo stato, poi modifichi.

3. Puntare il dominio sul sito corretto

Quando il sito esiste, il passaggio critico è associare il dominio. In WPMU DEV questo di solito si fa dalla sezione dedicata al dominio o ai domain mapping del sito. La logica è: il dominio principale deve corrispondere all’host che vuoi servire agli utenti, e il record DNS deve arrivare all’origin giusto.

Se il provider ti dà un target CNAME o un indirizzo da associare, aggiorna il DNS in modo coerente. Esempio classico:

www.esempio.it.   CNAME   site123.wpmudev.host.
esempio.it.       A       203.0.113.10

La sintassi reale dipende dal provider e dal modello di hosting, ma il criterio resta identico: un solo percorso chiaro dall’utente all’origin. Se usi sia apex sia www, decidi quale sarà canonico e imposta redirect puliti. Il sito WordPress non dovrebbe servire contenuti diversi a seconda dell’host, a meno che tu non stia gestendo casi multilingua o multisite con logica precisa.

Verifica la propagazione con un controllo minimale:

curl -I https://www.esempio.it
curl -I https://esempio.it

Atteso: risposta 200, 301 o 302 coerente con il redirect scelto. KO tipico: timeout, certificato non valido, redirect loop o pagina di default del vecchio hosting. Se vedi quest’ultimo caso, il DNS non è ancora allineato oppure la cache del resolver sta ancora puntando al posto sbagliato.

4. Installazione WordPress e configurazione iniziale

Una volta che il sito è raggiungibile, completa l’installazione di WordPress. Se WPMU DEV ti offre il deploy già pronto, di solito trovi WordPress installato con database e file core già presenti. In quel caso il lavoro vero è iniziale: sito, lingua, utente admin, permalink e parametri base.

Le prime impostazioni da sistemare subito sono queste:

• titolo sito e tagline coerenti con il progetto
• lingua dell’interfaccia
• fuso orario corretto
• struttura dei permalink non predefinita
• utente amministratore nominativo, non generico

Per i permalink, evita la struttura di default con i parametri numerici. Meglio una soluzione leggibile e stabile per SEO e manutenzione:

/%%postname%%/

Se il sito usa permalink personalizzati o plugin che riscrivono gli URL, fai subito una verifica con un paio di URL interni. Il problema classico non è il front-end, ma il backend che genera link sbagliati perché `.htaccess`, rewrite o configurazione equivalente non sono stati aggiornati.

Subito dopo, controlla che wp-admin risponda senza errori di sessione o redirect. Se compare una pagina bianca o un loop di login, la causa più probabile è una combinazione di plugin, cache o URL del sito non ancora allineati.

5. SSL, redirect e canonicalizzazione del traffico

Un sito WordPress su hosting gestito deve arrivare sempre in HTTPS, senza eccezioni ambigue. La configurazione corretta non è solo “attivare il certificato”, ma fare in modo che tutte le richieste HTTP convergano su un solo endpoint canonico.

Controlla questi tre punti:

• certificato emesso e associato al dominio giusto
• redirect HTTP → HTTPS attivo
• redirect tra apex e www coerente con la scelta architetturale

Se usi un reverse proxy o una CDN davanti al sito, il controllo va fatto anche lì. Un errore frequente è avere HTTPS valido tra browser e CDN, ma HTTP tra CDN e origin o viceversa. Il risultato può essere contenuto misto, cookie non sicuri o redirect doppi.

Un test utile è confrontare intestazioni e catena di redirect:

curl -I http://esempio.it
curl -I https://esempio.it
curl -I https://www.esempio.it

Atteso: una sola catena di redirect verso l’host canonico, senza passaggi intermedi inutili. Se vedi più salti, stai pagando in latenza e in complessità operativa. In un sito piccolo il danno sembra minimo; in un sito con plugin, CDN e cache la somma dei redirect si sente eccome.

6. Plugin essenziali: meno roba, più controllo

La tentazione tipica è installare subito troppi plugin. In un hosting gestito conviene l’opposto: partire con il minimo necessario e aggiungere solo ciò che risolve un requisito concreto. Ogni plugin in più aggiunge possibilità di conflitto, query extra, hooks e superfici d’attacco.

La base ragionevole, nella maggior parte dei casi, è questa:

• cache o ottimizzazione prestazionale, se non già gestita a livello piattaforma
• backup aggiuntivo, se vuoi una seconda linea di recupero
• sicurezza o hardening, ma senza duplicare funzioni già presenti nel pannello
• form o funzionalità di business strettamente necessarie

Evita di sovrapporre funzioni equivalenti. Se il provider già esegue backup automatici giornalieri, aggiungere tre plugin di backup non aumenta la resilienza: spesso aumenta solo il rumore. La stessa cosa vale per la cache: due layer non coordinati possono produrre pagine stale, login che non persistono o differenze strane tra mobile e desktop.

Per un controllo rapido dello stato plugin e versione WordPress, se hai accesso SSH e WP-CLI, puoi usare:

wp core version
wp plugin list
wp theme list

Se WP-CLI non è disponibile nel piano, usa il pannello WordPress e la dashboard del provider. Il punto non è il mezzo, ma la verifica: sapere cosa è attivo, cosa è aggiornabile e cosa può rompere il sito con un update.

7. Backup, restore e punto di ritorno

Su un sito nuovo il backup sembra superfluo, ma è proprio il momento giusto per impostarlo bene. Se il backup parte solo quando il sito è già in produzione e pieno di contenuti, stai rimandando il problema alla prima emergenza.

La regola operativa è semplice: prima di qualunque cambio importante, devi sapere dove sta il punto di ritorno. Questo vale per aggiornamenti core, plugin, tema, modifica DNS, migrazione e installazione di componenti custom.

Controlla che esista almeno un restore testabile con questi elementi:

• frequenza di backup
• retention
• tempo stimato di ripristino
• ambiente di test o staging per provare il restore

Se il pannello permette un backup manuale prima di un cambio, usalo. Se hai accesso al filesystem, esporta anche la configurazione rilevante, ad esempio eventuali file custom o snippet di deploy. Il backup del solo database non basta quando il problema è nel tema o in una configurazione PHP.

8. Performance: cosa misurare davvero

Per il sito WordPress su WPMU DEV non basta dire “è veloce”. La metrica utile, all’inizio, è il TTFB e poi la latenza p95 sulle pagine principali. Se il sito è commerciale, aggiungi anche il tasso di errore sulle richieste critiche e il tempo di risposta del backend wp-admin.

Un controllo rapido lato client può essere questo:

curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://www.esempio.it

Se il TTFB è alto ma DNS e TLS sono normali, il collo di bottiglia è probabilmente applicativo: query lente, cache assente, plugin pesanti o risorse del server insufficienti. Se invece connect o TLS sono lenti, il problema è più vicino al trasporto, al routing o alla CDN.

Per un sito appena creato, un buon obiettivo iniziale è avere homepage e pagine statiche con tempi coerenti e senza picchi improvvisi. Se la performance degrada dopo l’attivazione di un plugin, il colpevole non è “WordPress in generale”: è quel componente o la sua interazione con il resto dello stack.

9. Hardening minimo senza complicarsi la vita

La sicurezza di base non richiede magie: richiede disciplina. Cambia l’utente amministratore predefinito se è troppo ovvio, usa password robuste gestite da un vault, attiva MFA dove disponibile e limita gli account con permessi elevati. Non lasciare account orfani dopo il passaggio di consegne.

Controlla anche la superficie esterna: se il sito non deve esporre XML-RPC, REST o endpoint specifici, valuta se limitarli con criterio. Non bloccare a caso funzionalità che servono a editor, app mobile o integrazioni: il punto è ridurre l’esposizione, non rompere il lavoro altrui.

Un audit minimo utile comprende:

• lista utenti amministrativi
• plugin e tema aggiornati
• accessi SSH o SFTP limitati ai soli operatori necessari
• log di accesso e log errori consultabili

Se trovi secret in file di configurazione o note operative, ruotali e rimuovili dalla documentazione. In un contesto hosting, il problema più comune non è l’exploit sofisticato: è la credenziale dimenticata in un posto troppo visibile.

10. Verifica finale prima di dichiarare il sito pronto

Prima di consegnare il sito, fai una verifica finale con una checklist corta ma concreta. Non serve una cerimonia: serve sapere che il sito è raggiungibile, sicuro, aggiornato e recuperabile.

Controlla questi punti nell’ordine:

• il dominio risolve correttamente
• HTTPS è attivo e senza warning
• il redirect canonico è unico
• wp-admin funziona
• i backup risultano abilitati
• i plugin essenziali sono pochi e giustificati

Se vuoi un test secco lato HTTP, usa ancora `curl` e osserva codice, location e header. Se vuoi un test funzionale, apri homepage, una pagina interna e login amministrativo. Se qualcosa fallisce, non andare subito a cambiare tutto: isola il layer. DNS, edge, origin, app, database, storage. È quasi sempre uno di questi, non “WordPress che non va”.

Alla fine il criterio è questo: un sito WordPress su WPMU DEV deve essere facile da creare, ma soprattutto facile da mantenere. Se il setup iniziale è ordinato, ogni cambio successivo costa meno tempo e produce meno incidenti. Se invece il provisioning nasce confuso, il debito operativo arriva subito: e lo paghi alla prima modifica, non alla centesima.