Installare e configurare WordPress: hosting condiviso, VPS e primo setup

Installare WordPress è la parte facile. Su un hosting condiviso sono cinque minuti e tre clic; su un VPS sono venti minuti di terminale. Quello che decide se il sito starà in piedi nei due anni successivi succede dopo: come è scritto wp-config.php, chi possiede i file, quali impostazioni sono rimaste ai valori di default e quali plugin sono stati installati il primo giorno senza chiedersi se servivano.

Questa guida copre l’intero arco: la scelta fra hosting condiviso e VPS, l’installazione in entrambi gli scenari, e il primo setup — la parte che quasi tutte le guide liquidano in un elenco di plugin consigliati. Ogni comando qui dentro è stato eseguito, non copiato: una versione precedente di questo articolo conteneva un blocco di codice che, incollato così com’era, mandava il sito in errore fatale. Ne parlo apertamente nella sezione su wp-config.php, perché è l’errore più istruttivo dei cinque che ho corretto riscrivendola.

WordPress self-hosted: cosa cambia davvero

Esistono due WordPress, e la confusione fra i due è il primo ostacolo per chi comincia. WordPress.org è il software: lo scarichi, lo installi su un server tuo, e da quel momento il sito è tuo in ogni senso — codice, database, file, responsabilità. È quello che si chiama self-hosted, ed è ciò di cui parla questa guida. WordPress.com è un servizio commerciale che usa quello stesso software ma te lo gestisce: non tocchi il server, e in cambio decidi molto meno. Sul suo estremo più automatico c’è la possibilità di farsi generare il sito dall’AI su WordPress.com, che è la strada opposta a questa guida.

La differenza pratica si vede su tre cose, e sono le tre che contano quando il progetto cresce:

• Il codice. Su self-hosted puoi installare qualsiasi plugin e qualsiasi tema, compresi quelli che scrivi tu. Sul piano gratuito di WordPress.com non puoi installare niente.
• I dati. Il database è sul tuo server: puoi esportarlo, migrarlo, interrogarlo, romperlo. Nessuno può cambiare le condizioni d’uso sotto ai tuoi contenuti.
• La manutenzione. Che è il rovescio esatto dei due punti sopra: aggiornamenti, backup, sicurezza e prestazioni diventano lavoro tuo. Se nessuno lo fa, non lo fa nessuno.

Il resto di questa guida assume che tu abbia scelto self-hosted. È la scelta giusta se il sito è un asset di lavoro; è la scelta sbagliata se non hai nessuna intenzione di occuparti del punto tre e nessuno a cui delegarlo.

Hosting condiviso o VPS: come si decide

La domanda viene quasi sempre posta male: “qual è meglio”. Sono due prodotti diversi, e la scelta dipende da una sola variabile — chi si occupa del server. Su un hosting condiviso se ne occupa il provider: aggiorna PHP, applica le patch, tiene su MySQL. Su un VPS te ne occupi tu, o qualcuno per te.

Su un hosting condiviso più siti convivono sulla stessa macchina e ne condividono CPU, RAM e I/O. Costa poco, si configura da un pannello, e il provider mantiene lo stack. In cambio: le prestazioni dipendono anche dai vicini di server, non hai accesso root, e le configurazioni avanzate — una object cache persistente, un modulo PHP specifico, una regola nginx — o ci sono già o non le avrai mai.

Su un VPS hai una macchina virtuale con risorse riservate e accesso root. Le prestazioni sono prevedibili, puoi installare e configurare qualsiasi cosa, e il TTFB smette di dipendere da fattori che non controlli. In cambio ti prendi il lavoro di sistemista: aggiornamenti di sistema, firewall, certificati, monitoraggio, e la responsabilità di sapere cosa fai quando qualcosa smette di funzionare alle 23 di venerdì.

Due precisazioni che cambiano la scelta più della tabella. La prima: esiste una via di mezzo, il VPS gestito o l’hosting WordPress gestito, dove paghi qualcuno perché faccia il lavoro di sistemista al posto tuo. Costa più di un condiviso e meno di un sistemista, ed è la scelta corretta per la maggior parte dei siti professionali.

La seconda: un VPS non rende veloce un sito lento. Se il sito arranca per immagini da tre megabyte, quaranta plugin e nessuna cache, cambiare macchina sposta il problema di qualche centinaio di millisecondi e basta. Il momento in cui l’hosting diventa davvero il collo di bottiglia è riconoscibile — è quando il TTFB resta alto dopo aver sistemato tutto il resto — e l’ho descritto nella guida alle sei cause di un sito WordPress lento.

Se invece il sito esiste già e stai valutando lo spostamento, la procedura non è quella di questa guida: è una migrazione senza downtime, con DNS, cutover e redirect da gestire in un ordine preciso.

Cosa serve prima di iniziare

Quattro cose, indipendentemente dal tipo di hosting.

Un dominio, con i DNS già puntati. Il dominio si registra da qualsiasi registrar serio; quello che conta è che i record A (o i nameserver) puntino al server prima di installare, altrimenti WordPress si registra in database con l’indirizzo sbagliato e ti tocca correggerlo a mano. Una nota che vale la pena scrivere: fino a qualche anno fa questa guida consigliava Google Domains, che non esiste più — le registrazioni sono state cedute a Squarespace e la migrazione si è conclusa a luglio 2024. È un buon promemoria del fatto che un elenco di fornitori invecchia molto più in fretta di una procedura.

Un piano hosting con uno stack aggiornato. Qui evito deliberatamente di scrivere numeri di versione, perché sono esattamente la parte che invecchia peggio: la versione minima di PHP che WordPress dichiara oggi non è quella che dichiarava due anni fa, e soprattutto non coincide con la versione che ti conviene usare. I due riferimenti da controllare sono la pagina dei requisiti ufficiali di WordPress e l’elenco delle versioni PHP con supporto attivo. La regola pratica: installa sull’ultima versione di PHP che il tuo stack supporta e che riceve ancora patch di sicurezza, non sul minimo indispensabile. Serve poi un database MySQL o MariaDB e HTTPS attivo.

Un accesso ai file. Un client FTP/SFTP su hosting condiviso, un accesso SSH su VPS. Se il provider ti offre solo FTP in chiaro senza SFTP, è già un’informazione sul provider.

Il pacchetto WordPress preso dalla fonte ufficiale. Sempre e solo da wordpress.org. I pacchetti “preconfigurati” trovati altrove sono uno dei vettori con cui il malware entra prima ancora che il sito sia online.

Installare WordPress su hosting condiviso

Con l’installer automatico

Quasi tutti i pannelli — cPanel, Plesk, o i pannelli proprietari dei provider — includono un installer come Softaculous o Installatron. Cerchi WordPress nella sezione degli auto-installer, avvii, e compili un modulo. I campi che sembrano irrilevanti e non lo sono:

• Directory di installazione. Lascia il campo vuoto per installare nella root del dominio. Se ci scrivi wp — e alcuni installer lo precompilano — il sito vivrà su tuodominio.it/wp/ e spostarlo dopo è più lavoro di quanto sembri.
• Nome utente amministratore. Mai admin, mai il nome del dominio, mai il tuo nome pubblico. È l’unica metà della credenziale che un attaccante può scoprire senza indovinarla.
• Prefisso delle tabelle. Molti installer lo espongono in una sezione “avanzate” precompilato a wp_. Cambiarlo in qualcosa di casuale non è sicurezza vera, ma azzera un’intera categoria di exploit automatizzati scritti dando per scontato wp_. Costa zero al momento dell’installazione ed è scomodo da cambiare dopo.
• Protocollo. Scegli https://. Se il certificato non è ancora attivo, attivalo prima di installare invece di installare in HTTP e correggere dopo: il “dopo” significa aggiornare gli URL dentro il database.

Al termine ricevi un’email con le credenziali e puoi entrare da tuodominio.it/wp-admin.

A mano, via FTP

Serve quando l’installer non c’è, o quando vuoi controllare esattamente cosa finisce sul server. Sono cinque passaggi: crei il database e l’utente dal pannello (annotando nome, utente, password e host); scarichi il pacchetto da wordpress.org; lo scompatti in locale e carichi via SFTP il contenuto della cartella wordpress, non la cartella, dentro la document root; apri tuodominio.it nel browser e completi la procedura guidata; verifichi che wp-config.php sia stato scritto correttamente.

Se la procedura guidata non riesce a scrivere wp-config.php — succede quando i permessi non glielo consentono — ti mostra il contenuto da copiare a mano in un file nuovo. In quel caso vale la pena leggere la sezione seguente prima di incollare.

Installare WordPress su un VPS

I comandi qui sotto sono per Ubuntu/Debian. Su altre distribuzioni cambia il gestore di pacchetti, non la sostanza.

1. Connessione e aggiornamento del sistema

ssh tuo_utente@IP_del_server
sudo apt update && sudo apt upgrade -y

Se stai entrando come root con una password, fermati qui e sistema prima quello: crea un utente non privilegiato, abilita l’autenticazione a chiave e disattiva il login SSH con password. Un VPS con SSH aperto in password viene trovato dai bot in poche ore.

2. Il web server e PHP

Qui c’è un bivio che va preso sul serio, ed è il secondo errore che ho corretto riscrivendo questa guida: i pacchetti PHP da installare non sono gli stessi per Apache e per nginx. La versione precedente dava un unico comando con libapache2-mod-php, che su un percorso nginx installa Apache come dipendenza e lascia PHP senza il processore che nginx si aspetta. Il risultato è un sito che, nel migliore dei casi, restituisce il PHP come testo da scaricare.

Su Apache (stack LAMP):

sudo apt install apache2
sudo apt install php libapache2-mod-php php-mysql php-cli php-curl php-xml php-mbstring php-zip php-gd php-intl unzip

Su nginx (stack LEMP):

sudo apt install nginx
sudo apt install php-fpm php-mysql php-cli php-curl php-xml php-mbstring php-zip php-gd php-intl unzip

Su nginx serve poi dichiarare nel virtual host che i file .php vanno passati al socket di PHP-FPM: senza quel blocco location, nginx serve i sorgenti invece di eseguirli. I moduli gd, intl e zip non sono decorativi — WordPress li usa per il ridimensionamento delle immagini, la localizzazione e l’installazione dei plugin dal backend.

3. Database: la riga che va scritta con attenzione

sudo apt install mysql-server
sudo mysql_secure_installation

Poi, dentro la console MySQL:

CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'password_lunga_e_casuale';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;

Terza correzione: il set di caratteri. La versione precedente creava il database con utf8 e utf8_unicode_ci. Quello che MySQL chiama utf8 non è UTF-8 completo: sta in tre byte per carattere e non arriva a coprire il piano supplementare, cioè emoji, molti ideogrammi e diversi simboli. WordPress usa utf8mb4 da oltre dieci anni proprio per questo. Un database creato in utf8 funziona benissimo finché qualcuno non incolla un’emoji in un titolo: da lì in poi il contenuto viene troncato al primo carattere a quattro byte.

La password del database non la digiterai mai più: falla lunga e casuale, e non riusare quella dell’utente amministratore di WordPress.

4. Scaricare WordPress senza lasciare macerie

cd /tmp
curl -O https://it.wordpress.org/latest-it_IT.tar.gz
tar -xzf latest-it_IT.tar.gz
sudo rsync -av wordpress/ /var/www/tuosito/
rm -rf /tmp/wordpress /tmp/latest-it_IT.tar.gz

Quarta correzione, e la più subdola perché non produce nessun errore. La versione precedente scaricava e scompattava direttamente dentro /var/www/html con sudo mv wordpress/* ., lasciando sul posto sia l’archivio .tar.gz sia la cartella wordpress ormai vuota — entrambi raggiungibili dal web. Ma soprattutto /var/www/html, su un’installazione Apache appena fatta, contiene già un index.html: la pagina di default di Ubuntu. Apache serve index.html prima di index.php, quindi il risultato è un sito installato correttamente che continua a mostrare la pagina di benvenuto di Apache, con il proprietario convinto che l’installazione sia fallita.

Le due contromisure sono nel comando sopra: si scompatta in /tmp e si sincronizza nella document root, che è una cartella dedicata al sito e non quella di default; e si ripulisce. Se stai comunque usando /var/www/html, cancella l’index.html prima di dare la colpa a PHP.

5. Permessi e proprietario

sudo chown -R www-data:www-data /var/www/tuosito
sudo find /var/www/tuosito -type d -exec chmod 755 {} \;
sudo find /var/www/tuosito -type f -exec chmod 644 {} \;

La versione precedente si fermava al chown. Il chown da solo non basta: senza i permessi corretti sulle directory WordPress non riesce a scrivere negli upload, e senza proprietà corretta ti chiede le credenziali FTP ogni volta che provi ad aggiornare un plugin dal backend. Quella richiesta di credenziali FTP che vedono in tanti non è una funzionalità: è WordPress che ti sta dicendo che non possiede i propri file. Ne riparlo più avanti.

6. HTTPS e chiusura

Prima di aprire il browser, il certificato. Con Let’s Encrypt e certbot è un comando e un rinnovo automatico che poi va verificato una volta — un certificato che scade di sabato mattina è un sito offline fino a lunedì. Fatto questo, apri il dominio: WordPress presenta la procedura guidata, scrive wp-config.php e crea l’utente amministratore.

wp-config.php: le righe che contano

È il file più importante del sito e quello che quasi nessuno riapre dopo l’installazione. Cominciamo dall’errore, perché è quello per cui vale la pena leggere questa sezione anche se il sito è già online da anni.

La versione precedente di questo articolo mostrava le credenziali del database così:

DB_NAME = 'wordpress';
DB_USER = 'wp_user';
DB_PASSWORD = 'password_sicura';
DB_HOST = 'localhost';

Non è una semplificazione: è PHP non valido. Non esiste una variabile DB_NAME — quelle sono costanti, e in PHP le costanti si dichiarano, non si assegnano. Incollate in wp-config.php, quelle quattro righe producono un errore fatale e una schermata bianca, con l’aggravante che il messaggio parla di costanti indefinite e non dice affatto che il problema è la sintassi. La forma corretta, che è anche quella che trovi in wp-config-sample.php, è questa:

define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'password_lunga_e_casuale' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );

Chiarito questo, ci sono altre quattro cose nello stesso file che meritano un minuto.

Le otto chiavi di sicurezza. Firmano i cookie di autenticazione. Se hai installato dalla procedura guidata sono state generate per te; se hai scritto wp-config.php a mano copiando da wp-config-sample.php, sono rimaste ai valori segnaposto. Cerca nel file la stringa put your unique phrase here: se compare anche una sola volta, i cookie di sessione del tuo sito sono falsificabili. Si generano dal servizio ufficiale di WordPress e si sostituiscono in blocco. È il controllo 17 della checklist di sicurezza WordPress, dove trovi anche cosa comporta rigenerarle su un sito già in uso.

Il prefisso delle tabelle, la riga $table_prefix. Vale quanto detto sopra: cambiarlo prima dell’installazione costa zero, cambiarlo dopo significa rinominare una dozzina di tabelle e correggere due voci dentro wp_options e wp_usermeta.

Il debug. Deve essere spento in produzione. Con WP_DEBUG attivo e WP_DEBUG_DISPLAY a true i messaggi di errore stampano a video percorsi assoluti, nomi di tabelle e frammenti di query: informazioni che a te non servono e a un attaccante sì.

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'DISALLOW_FILE_EDIT', true );

L’editor di file dal backend, l’ultima riga qui sopra. Di default WordPress permette a un amministratore di modificare i file di temi e plugin direttamente da Aspetto > Editor del tema. È una comodità che nessuno usa davvero e che trasforma un singolo account amministratore compromesso in esecuzione di codice arbitrario sul server. Si disattiva con una riga, il primo giorno.

Perché WordPress ti chiede le credenziali FTP

Merita una sezione a sé perché è la domanda che ricevo più spesso su un’installazione appena fatta, e perché la risposta che circola in rete — “aggiungi FS_METHOD a wp-config.php” — è un cerotto su un problema diverso.

Quando aggiorni un plugin dal backend, WordPress deve scrivere dentro wp-content. Prima di provarci controlla se l’utente con cui gira PHP possiede quei file. Se sì, scrive e basta. Se no, non può fare altro che chiederti un altro modo per entrare — e quello che conosce è l’FTP. La finestra delle credenziali FTP è la diagnosi, non il problema: ti sta dicendo che i file del sito appartengono a un utente diverso da quello del web server.

La correzione è quella della sezione precedente: proprietario coerente con l’utente di PHP-FPM o di Apache (di norma www-data su Debian e Ubuntu), directory a 755 e file a 644. Forzare FS_METHOD a direct senza sistemare la proprietà non fa sparire il problema: fa sparire la richiesta, e gli aggiornamenti falliscono in silenzio.

Il rovescio vale altrettanto: chmod 777 non è una soluzione, è una porta aperta. Una cartella scrivibile da chiunque in cui è possibile caricare file è il modo più diretto per trasformare un upload innocuo in codice eseguibile — motivo per cui la checklist di sicurezza dedica un controllo specifico ai permessi e all’esecuzione di PHP dentro uploads.

Il primo setup, prima di ogni plugin

WordPress è installato. Prima di installare qualsiasi cosa, dieci minuti nelle impostazioni valgono più di dieci plugin.

1. Togli la spunta “Scoraggia i motori di ricerca dall’indicizzare questo sito”. Sta in Impostazioni > Lettura. Se il sito è stato installato in ambiente di prova o se qualcuno l’ha attivata durante lo sviluppo, WordPress emette un noindex su tutto il sito e nessuna quantità di SEO successiva serve a niente. È la prima cosa da controllare, e la causa numero uno dei “il mio sito non compare su Google” che mi arrivano.

2. Imposta i permalink. Impostazioni > Permalink > Nome articolo. Farlo il primo giorno costa un clic; farlo fra un anno significa gestire i redirect di ogni URL esistente. Su tutto quello che la struttura degli indirizzi porta con sé — categorie, archivi, link interni — il riferimento è come si progetta la struttura di un sito WordPress; per l’ottimizzazione della singola pagina resta la checklist SEO on-page.

3. Decidi www o non-www, e HTTPS ovunque. Impostazioni > Generali, campi Indirizzo WordPress e Indirizzo sito. Devono coincidere, essere in https:// e usare la stessa forma con o senza www che usi nei DNS. Due forme entrambe raggiungibili significano contenuto duplicato.

4. Fuso orario, formato data e lingua. Sempre in Generali. Un fuso sbagliato manda in confusione le pubblicazioni programmate e i log.

5. Cancella quello che WordPress lascia in dote. L’articolo di esempio, la pagina di esempio, il commento di esempio e i temi di default che non usi. Non è pulizia estetica: un tema inattivo continua a ricevere aggiornamenti di sicurezza solo se lo aggiorni, e un tema inattivo e non aggiornato è codice vulnerabile raggiungibile dal web.

6. Sistema il profilo dell’amministratore. Nickname e “Mostra pubblicamente come” diversi dallo username: di default WordPress mostra il nome utente accanto agli articoli, regalando metà credenziale a chiunque legga il blog.

7. Decidi i ruoli prima di creare gli utenti. Amministratore solo a chi deve davvero poter installare plugin. Chi scrive è Autore o Editore. È il principio del privilegio minimo, e su un sito con più persone è la differenza fra un account compromesso e un sito compromesso.

8. Configura i commenti in modo consapevole. Impostazioni > Discussione. Se non li vuoi, disattivali per i nuovi articoli invece di lasciarli aperti e non moderati: un form di commento aperto e senza protezione anti-spam si riempie in settimane.

9. Metti in sicurezza l’accesso. Password robusta, autenticazione a due fattori sull’amministratore, limitazione dei tentativi di login. Sono i primi controlli della checklist sicurezza WordPress, e il momento giusto per farli è adesso, quando il sito non ha ancora nulla da perdere e nessuna configurazione da rompere.

10. Attiva i backup e prova un ripristino. Un backup mai ripristinato è un’ipotesi, non un backup. La destinazione deve stare fuori dal server che stai salvando — se il server sparisce, spariscono anche i backup che ci stavano sopra. Ho descritto una configurazione completa in come impostare i backup di WordPress su S3.

11. Decidi come gestirai gli aggiornamenti. Minori automatici, major dopo verifica su staging. La procedura, con la checklist del prima e del dopo, è in aggiornamento WordPress: cosa fare prima e dopo; per capire cosa aspettarti da una major e quali release hanno cambiato i requisiti — la 6.3 e la 7.0 hanno entrambe alzato il minimo di PHP — c’è lo storico completo delle versioni.

12. Collega Search Console e verifica la proprietà. Il giorno in cui qualcosa va storto sull’indicizzazione, i dati partono da quando hai collegato la proprietà, non da quando ti sei accorto del problema.

13. Decidi quali crawler AI lasciar passare. Non è una domanda da rimandare: addestramento, ricerca e visita su richiesta dell’utente sono tre cose diverse, si controllano separatamente, e il default lo decide qualcun altro — il plugin, o la CDN che hai davanti.

Cosa non installare subito

Ogni guida all’installazione si chiude con un elenco di plugin consigliati. Il problema di quegli elenchi è che sono indipendenti dal sito: consigliano le stesse dieci cose a un blog personale e a un e-commerce con ventimila prodotti. La versione precedente di questa guida faceva esattamente questo, e la sostituisco con quattro criteri.

Un plugin per funzione, e solo quando la funzione serve. Non installare un plugin di cache prima di avere contenuti da mettere in cache, né un plugin SEO prima di avere pagine da ottimizzare. La domanda non è “questo plugin è buono” ma “questo problema ce l’ho già”.

Solo da fonti verificabili. Repository ufficiale o sviluppatore con un nome, una manutenzione recente e una politica di sicurezza. I plugin nulled — versioni premium “sbloccate” — sono il vettore di infezione più prevedibile che esista. Sul meccanismo con cui una dipendenza legittima diventa un attacco, ho raccontato un caso reale in supply chain attack su WordPress, e i criteri di valutazione stanno in sicurezza dei plugin WordPress.

La cache è una scelta, non un default. Quale plugin di caching convenga dipende dallo stack: su un condiviso senza controllo del server le opzioni sono poche, su un VPS con Redis e un reverse proxy davanti il ragionamento cambia del tutto. Il confronto sui due più diffusi è in W3 Total Cache vs WP Rocket; su cosa fanno concretamente lazy loading, caching e minificazione — e su cosa non fanno — c’è questa guida. Se il server lo permette, abilitare HTTP/3 sul server dà un guadagno che nessun plugin può darti.

Il tema pesa più di dieci plugin. Un tema multiuso che carica un page builder, una libreria di icone e tre framework CSS su ogni pagina è un costo che paghi a ogni visita e che nessuna ottimizzazione recupera del tutto. Se il progetto lo giustifica, la strada alternativa è un tema scritto su misura: l’ho documentata passo per passo in come creare un tema WordPress da zero.

Domande frequenti

Dove sei arrivato

Hai un WordPress installato su uno stack aggiornato, con un wp-config.php scritto correttamente, chiavi di sicurezza uniche, permessi che permettono gli aggiornamenti senza aprire buchi, e le impostazioni di base decise invece che ereditate. È una base su cui si può costruire per anni, e la differenza fra questa e un’installazione fatta di fretta non si vede il primo giorno: si vede al primo aggiornamento che fallisce, al primo tentativo di indicizzazione, al primo picco di traffico. Da qui in poi la curva di apprendimento è meno tecnica di quanto sembri: la parte che accelera davvero è conoscere chi WordPress lo costruisce, e il modo più diretto per farlo costa meno di quanto ci si aspetti.

Se il sito è un progetto di lavoro e preferisci partire da una configurazione già solida — o se hai un’installazione esistente che sospetti sia stata messa su in fretta — è una delle cose di cui mi occupo: installazione, configurazione e messa in sicurezza iniziale, con lo stack scelto in base al progetto e non al prezzo di listino.