1 17/04/2026 11 min

Preparare la VPS prima di toccare WordPress

Su VPSie il punto non è “installare WordPress”, ma mettere in piedi una base pulita e prevedibile. Se la VPS nasce già con un pannello o con un’immagine preconfezionata, conviene capire subito cosa c’è sotto: sistema operativo, web server, PHP, database e firewall. Un’installazione ordinata oggi evita di inseguire errori banali domani, soprattutto quando il sito cresce e inizi a toccare cache, permessi e certificati.

L’obiettivo minimo è questo: una VPS aggiornata, un web server funzionante, PHP compatibile con la versione di WordPress che vuoi usare, un database separato e un dominio già puntato verso l’IP pubblico. Se manca uno di questi pezzi, non si improvvisa: si chiude il gap prima di andare oltre.

Per verificare la base di partenza, entra in SSH e controlla sistema e rete:

uname -a
cat /etc/os-release
ip a
ss -lntp

Se non vedi la porta 22 in ascolto o il server non risponde, il problema è a monte di WordPress. In quel caso la priorità è accesso, rete e console del provider, non l’applicazione.

Scelta dello stack: LAMP o LEMP, ma senza complicarsi la vita

Per una VPS standard, WordPress gira bene sia su Apache sia su Nginx. Se vuoi una strada semplice e con meno punti di attrito, Apache resta la scelta più lineare per chi installa e gestisce in autonomia. Se invece prevedi più siti, più attenzione alla cache e una configurazione più asciutta, Nginx è spesso più comodo. In entrambi i casi il risultato finale deve essere lo stesso: PHP-FPM, database MariaDB o MySQL, HTTPS, log consultabili e permessi corretti.

La scelta non cambia il concetto operativo: installi il web server, il runtime PHP con le estensioni richieste da WordPress, il database e poi colleghi tutto con un virtual host dedicato. Evita di appoggiarti al sito di default del server: è un dettaglio che diventa confusione appena aggiungi un secondo dominio.

Installare pacchetti base e aggiornare il sistema

Su una distribuzione Debian o Ubuntu recenti, una base tipica per WordPress con Apache è questa:

sudo apt update
sudo apt -y upgrade
sudo apt -y install apache2 mariadb-server php php-cli php-fpm php-mysql php-curl php-gd php-xml php-mbstring php-zip php-intl unzip curl

Con Nginx, il pacchetto del web server cambia, ma il resto del blocco rimane molto simile:

sudo apt update
sudo apt -y upgrade
sudo apt -y install nginx mariadb-server php-fpm php-mysql php-curl php-gd php-xml php-mbstring php-zip php-intl unzip curl

Il punto non è il nome del pacchetto, ma la coerenza: PHP deve essere davvero disponibile per il web server e non solo da CLI. Se WordPress mostra pagina bianca o errore 500 dopo l’installazione, spesso il problema è proprio la catena web server → PHP-FPM → estensioni mancanti.

Controlla subito i servizi:

systemctl status apache2
systemctl status nginx
systemctl status mariadb
systemctl status php*-fpm

Non serve memorizzare la sigla esatta del servizio PHP-FPM: basta verificare che il demone sia attivo e che il socket o la porta siano coerenti con la configurazione del web server.

Configurare il database per WordPress

WordPress non va installato con l’account root del database. Serve un utente dedicato, con privilegi solo sul database dell’applicazione. È una misura di base, non un vezzo da hardening avanzato.

Accedi a MariaDB e crea database e utente:

sudo mysql
CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'una_password_lunga_e_unica';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Il charset `utf8mb4` è la scelta corretta per evitare problemi con emoji e caratteri estesi. Se usi una collation vecchia, non rompi subito il sito, ma ti porti dietro limiti inutili.

Se vuoi controllare che l’utente sia stato creato davvero, verifica così:

sudo mysql -e "SHOW DATABASES;"
sudo mysql -e "SHOW GRANTS FOR 'wpuser'@'localhost';"

Se il database non risponde o il servizio è fermo, prima risolvi quello. WordPress non può compensare un backend SQL non disponibile.

Scaricare WordPress e posizionarlo nella document root

La procedura pulita è scaricare l’archivio ufficiale, estrarlo nella directory del sito e assegnare i permessi corretti. Non usare la home dell’utente SSH come staging permanente: devi arrivare subito alla struttura finale del sito.

Esempio con document root dedicata:

cd /tmp
curl -O https://wordpress.org/latest.tar.gz
sudo mkdir -p /var/www/example.com
sudo tar -xzf latest.tar.gz -C /var/www/example.com --strip-components=1
sudo chown -R www-data:www-data /var/www/example.com

Se preferisci una struttura più esplicita, puoi tenere i file in `/var/www/example.com/public_html`. L’importante è che il virtual host punti alla directory giusta e che non ci siano file sparsi in percorsi ambigui.

Controlla il contenuto estratto:

ls -la /var/www/example.com
ls -la /var/www/example.com/wp-admin

La presenza di `wp-admin`, `wp-content` e `wp-includes` è il controllo più semplice per capire che l’estrazione è andata a buon fine.

Configurare Apache per il virtual host del dominio

Con Apache, crea un virtual host dedicato al dominio. Evita di appoggiarti al file di default perché ti complica l’ordine mentale e rende più difficile capire dove finisca il traffico del sito.

Un esempio minimale:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com

    <Directory /var/www/example.com>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/example.com_error.log
    CustomLog ${APACHE_LOG_DIR}/example.com_access.log combined
</VirtualHost>

Abilita il sito e il modulo rewrite, poi ricarica Apache:

sudo a2ensite example.com.conf
sudo a2enmod rewrite
sudo systemctl reload apache2

Il modulo rewrite serve quasi sempre per i permalink di WordPress. Se lo dimentichi, il sito può aprirsi ma i link interni non funzionano come previsto.

Verifica la configurazione prima del reload:

sudo apache2ctl configtest

Se il test non è `Syntax OK`, fermati lì. Ricaricare una configurazione rotta significa solo spostare il problema dal terminale al traffico utenti.

Configurare Nginx se preferisci uno stack LEMP

Con Nginx devi curare bene il blocco server e il passaggio a PHP-FPM. La logica resta semplice: Nginx serve i file statici, PHP-FPM esegue WordPress. Se il fastcgi pass è errato, la pagina restituisce errore o scarica il codice PHP come testo, che è un classico errore di configurazione.

Un blocco server base può essere questo:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com;
    index index.php index.html;

    access_log /var/log/nginx/example.com_access.log;
    error_log /var/log/nginx/example.com_error.log;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

Il percorso del socket PHP-FPM può cambiare in base alla versione installata. Non dare per scontato il nome del socket: controllalo in `/etc/php/*/fpm/pool.d/www.conf` o con `ss -lxp` se il demone espone una socket Unix diversa.

Prima del reload, verifica la sintassi:

sudo nginx -t
sudo systemctl reload nginx

Caricare wp-config.php e completare l’installazione web

A questo punto WordPress è sul disco, ma non è ancora collegato al database. Il file `wp-config.php` si può generare dal wizard web oppure creare a mano partendo da `wp-config-sample.php`. Per una VPS gestita bene, la seconda strada è spesso più trasparente perché sai esattamente cosa stai impostando.

Copia il campione e modifica i parametri principali:

cd /var/www/example.com
cp wp-config-sample.php wp-config.php
nano wp-config.php

Inserisci database, utente e password, poi verifica che i valori corrispondano a quelli creati in MariaDB:

define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wpuser' );
define( 'DB_PASSWORD', 'una_password_lunga_e_unica' );
define( 'DB_HOST', 'localhost' );

Se vuoi fare le cose bene, imposta anche le chiavi di autenticazione univoche. Non vanno riusate da altri siti e non vanno lasciate nel testo dell’articolo o in documenti condivisi. Recuperale dal generatore ufficiale e incollale nel file in modo controllato.

Una volta salvato il file, apri il dominio nel browser e completa la procedura guidata di WordPress. Se il wizard non parte, guarda subito i log del web server e di PHP-FPM. È il modo più rapido per distinguere un problema di permessi da un problema di connessione al database.

Impostare permessi e ownership senza aprire buchi inutili

Su WordPress i permessi sbagliati si pagano con due tipi di errore: il sistema non riesce a scrivere aggiornamenti e plugin, oppure diventa troppo permissivo. La regola pratica è semplice: il web server deve poter leggere i file e scrivere solo dove serve davvero, cioè `wp-content` e, in alcuni casi, cache e upload.

Una baseline ragionevole è questa:

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

Se gestisci aggiornamenti manuali via SSH, puoi decidere una strategia diversa con un gruppo condiviso. Ma non partire da lì se non hai già un motivo operativo concreto: è più facile sbagliare che guadagnare qualcosa.

Controlla i percorsi scrivibili dopo l’installazione:

ls -ld /var/www/example.com/wp-content
ls -l /var/www/example.com/wp-content/uploads

Attivare HTTPS con Let’s Encrypt

Un WordPress pubblico su VPS non dovrebbe restare in HTTP. Il certificato TLS serve non solo per il lucchetto del browser, ma anche per evitare problemi con cookie, login e contenuti misti. Se il dominio è già correttamente puntato alla VPS, il passo successivo è emettere il certificato e forzare il redirect verso HTTPS.

Su Apache o Nginx, con Certbot la procedura tipica è questa:

sudo apt -y install certbot python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com
sudo apt -y install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Dopo l’emissione, verifica rinnovo e scadenza:

sudo certbot renew --dry-run
sudo certbot certificates

Se il rinnovo simulato fallisce, il problema non è WordPress: è il routing HTTP, il firewall o la configurazione del virtual host. Prima di cambiare altro, controlla che la porta 80 sia raggiungibile dall’esterno e che il dominio risolva sull’IP corretto.

Rifiniture utili: cron, cache e aggiornamenti

Una VPS WordPress non si ferma all’installazione iniziale. Conviene sistemare subito almeno tre cose: cron, cache e strategia di aggiornamento. Il cron interno di WordPress funziona, ma su siti con traffico basso può essere meno affidabile di un cron di sistema. Se il sito deve fare backup, invii mail o task pianificati, meglio passare a un cron reale.

Disattiva il cron pseudo-interno e crea un job di sistema se necessario:

define( 'DISABLE_WP_CRON', true );
sudo crontab -e
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Per la cache, la scelta dipende dallo stack. Con Nginx e PHP-FPM puoi già guadagnare qualcosa con una configurazione pulita e una cache di pagina esterna. Con Apache, il discorso cambia meno di quanto si creda: il collo di bottiglia vero è quasi sempre PHP e il database, non il nome del web server.

Per gli aggiornamenti, evita di lasciare il sistema fermo per mesi. Un ciclo minimo di manutenzione dovrebbe includere aggiornamento pacchetti, patch di sicurezza, controllo log e verifica backup. Se il sito è in produzione, ogni change va trattato come change controllato: backup prima, modifica dopo, verifica subito.

Controlli finali: cosa deve funzionare prima di dire che è pronto

Una installazione WordPress su VPSie è davvero pronta solo se questi controlli passano senza ambiguità:

1. Il dominio risolve verso l’IP della VPS con un `dig` o un `nslookup` coerente.

dig +short example.com
curl -I http://example.com
curl -I https://example.com

2. Il web server risponde con `200`, `301` o la pagina di setup di WordPress, non con `500`, `502` o timeout.

3. I log del server non mostrano errori ripetuti di PHP, file mancanti o permessi negati.

sudo tail -n 50 /var/log/apache2/example.com_error.log
sudo tail -n 50 /var/log/nginx/example.com_error.log
sudo journalctl -u php*-fpm -n 50 --no-pager

4. Il login amministrativo funziona, gli upload passano e i permalink si aprono senza 404.

5. Il rinnovo del certificato TLS è verificabile con un dry-run, non solo “sembra andare”.

Se uno di questi punti fallisce, non forzare la mano. Parti dal layer giusto: DNS, edge, origin, app, database o storage. È il modo più veloce per evitare di trasformare un setup semplice in un problema da debug lungo e costoso.

Assunzione operativa: la VPS è una Debian o Ubuntu recente con accesso SSH amministrativo, dominio già registrato e WordPress installato su un solo sito, non su un hosting multi-tenant.