Miglior hosting WordPress: come scegliere tra condiviso, managed e VPS

Il miglior hosting WordPress non è necessariamente quello più costoso o con più spazio disco. È il piano i cui limiti tecnici, strumenti inclusi e livello di gestione corrispondono al comportamento reale del sito e alle competenze disponibili per amministrarlo.

Le visite mensili sono solo un primo indizio. Un blog con pagine pubbliche, page cache e CDN può sostenere molto traffico con risorse contenute. Un WooCommerce con meno visitatori, ma numerosi utenti contemporanei su carrello, checkout e area account, può invece richiedere più capacità PHP e database.

Questa guida aiuta a confrontare offerte documentate e a scegliere fra hosting condiviso, managed WordPress e VPS/cloud in base a criteri verificabili.

1. Scegli il modello di hosting in base allo scenario

Prima di confrontare provider e promozioni, individua il profilo che si avvicina di più al tuo progetto. La qualità del singolo piano resta decisiva: uno shared evoluto può includere cache, staging e SSH, mentre una VPS non gestita richiede competenze e attività che un servizio managed può già coprire.

 
La tabella indica un punto di partenza, non una soglia assoluta. Un piano va sempre confrontato con i requisiti effettivi del sito.

2. Parti dal carico reale, non dalle visite mensili

Un modello utile, ma non predittivo, è: carico reale = traffico × quota dinamica × contemporaneità × complessità applicativa. Non stabilisce da solo quando acquistare una VPS, ma spiega perché siti con lo stesso numero di visite possano avere esigenze molto diverse.

Dati da raccogliere prima di scegliere un piano

• Tipo di progetto: blog, sito aziendale, portale editoriale, e-commerce, membership, LMS, multisito o gruppo di siti per clienti.
• Traffico medio, picchi e loro origine: newsletter, campagne pubblicitarie, lanci, saldi o contenuti molto condivisi.
• Rapporto tra pagine pubbliche cacheabili e richieste dinamiche, come login, ricerca, dashboard, contenuti personalizzati, carrello e checkout.
• Numero di utenti autenticati contemporaneamente, particolarmente importante per negozi, corsi e community.
• Plugin, tema, integrazioni API, query complesse, importazioni e codice personalizzato.
• Processi pianificati: WP-Cron, Action Scheduler, sincronizzazioni, feed, invio email e backup.
• Tempo e competenze interne disponibili per aggiornamenti, sicurezza, monitoraggio e ripristino.
• Budget totale, considerando rinnovo, IVA, email, CDN, backup aggiuntivi ed eventuale gestione tecnica.

Cache e richieste dinamiche

La page cache serve HTML già generato e può evitare esecuzioni PHP e query al database per gran parte delle pagine pubbliche. Per questo un sito editoriale ben configurato può gestire molte visite senza avere le stesse esigenze di un e-commerce.

Carrello, account, wp-admin, ricerca e contenuti personalizzati restano invece richieste dinamiche. Raggiungono PHP e database e incidono su worker, memoria e connessioni. La documentazione WordPress distingue le diverse forme di cache e il loro ruolo nelle prestazioni: approfondisci la cache in WordPress.

Errori 429, 502, 503 o 504 e rallentamenti sulle pagine non cacheabili sono segnali da analizzare, non prove automatiche di un hosting sottodimensionato. Un 429 può dipendere da rate limiting, WAF, CDN o protezioni applicative; un 502 o 504 può coinvolgere proxy, PHP-FPM, servizi esterni o timeout. Prima di attribuire il problema al piano, controlla error log, log PHP, metriche del provider, processi attivi, query lente e, se disponibile, un sistema di monitoraggio delle prestazioni.

3. Hosting condiviso, managed WordPress o VPS: cosa cambia davvero

Quando scegliere hosting condiviso

È adatto a blog, portfolio e siti vetrina prevalentemente pubblici e cacheabili, con budget contenuto e poche esigenze di personalizzazione. Può essere una scelta adeguata se il provider offre SSL, backup affidabili, cache lato server e limiti espliciti.

Le formule “spazio illimitato” o “traffico illimitato” non descrivono la capacità computazionale disponibile. Contano CPU, memoria, I/O, processi simultanei, inode, timeout, limiti del database e cron. Controlla inoltre le condizioni di fair use del piano.

Quando scegliere managed WordPress

Il valore principale di un servizio managed è operativo: può integrare cache, CDN, backup, restore, staging, monitoraggio, sicurezza e assistenza specializzata. Questo riduce il lavoro quotidiano, ma non rende automaticamente il piano più adatto di ogni alternativa.

Verifica limiti su visite, worker PHP, database, storage e cron, oltre a plugin o configurazioni non consentiti. Alcune piattaforme applicano restrizioni documentate per evitare conflitti con i propri sistemi di cache, backup o sicurezza: un esempio è l’elenco di plugin non consentiti da WP Engine.

Quando scegliere VPS o cloud

Una VPS o un cloud server è indicato quando servono controllo dello stack, SSH, WP-CLI, deploy, automazioni, configurazioni personalizzate o separazione tra applicazione, database, cache e processi in background. È una scelta sensata per team tecnici e agenzie, non un passaggio obbligato per ogni sito in crescita.

Il costo del server non comprende necessariamente aggiornamenti del sistema operativo, hardening, firewall, monitoraggio, alert, backup applicativi, test di ripristino, WAF e gestione degli incidenti. Prima di scegliere questa strada, assegna chiaramente queste responsabilità a una persona interna o a un fornitore.

4. Cosa verificare nella documentazione del piano

WordPress raccomanda PHP 8.3 o superiore, MariaDB 10.11+ oppure MySQL 8.0+, HTTPS e preferibilmente Apache o Nginx: i requisiti aggiornati sono disponibili nella documentazione ufficiale. La compatibilità minima non dimostra però che il piano sia sufficiente per un sito con carico dinamico.

Confronta due o tre offerte usando sempre le stesse voci:

• CPU, RAM, I/O, processi simultanei, worker PHP, memoria PHP e timeout;
• dimensione, connessioni e strumenti di gestione del database;
• cache, CDN e object cache persistente, se rilevante per il progetto;
• backup: frequenza, retention, copertura di file e database, export e modalità di restore;
• staging, SSH, SFTP, WP-CLI, cron di sistema e accesso ai log;
• numero di siti, storage, inode, data center, overage e prezzo di rinnovo;
• canali, orari, tempi di risposta e competenza del supporto su WordPress e WooCommerce.

La variabile WP_CACHE, da sola, non attiva una strategia completa di cache, come chiarisce la documentazione di WordPress. Anche Redis non è una risposta universale: per un piccolo sito editoriale possono incidere di più page cache, CDN, immagini e tema; per un e-commerce diventano spesso rilevanti anche worker PHP, database e processi in background.

5. Casi particolari: WooCommerce, membership e agenzie

WooCommerce ed e-commerce con campagne

WooCommerce va valutato su checkout, carrello, account, ricerca, ordini, email e utenti contemporanei. Queste aree sono meno cacheabili delle pagine prodotto o delle pagine editoriali e richiedono attenzione a worker PHP, database, cron, backup e corrette esclusioni dalla cache.

Su installazioni con molte attività pianificate, verifica come il piano gestisce WP-Cron e se permette cron di sistema o WP-CLI. La documentazione WooCommerce sugli eventi pianificati mostra l’importanza di questi processi per estensioni che eseguono attività ricorrenti. Le indicazioni della scaling FAQ di WooCommerce aiutano inoltre a valutare il carico oltre il semplice conteggio delle visite.

HPOS utilizza tabelle dedicate per la gestione degli ordini, come descritto nella documentazione WooCommerce, ma non elimina la necessità di verificare query, plugin, compatibilità e carico applicativo. Per campagne critiche, testa checkout, email e processi di background prima del picco previsto.

Membership, LMS, community e agenzie

Login e contenuti personalizzati riducono l’efficacia della page cache. Per membership, LMS e community conta soprattutto il numero di utenti autenticati simultaneamente, insieme alle prestazioni dell’area riservata, alle query e ai processi in background.

Per agenzie e sviluppatori, i criteri principali sono standardizzazione, numero di siti, Git, SSH, WP-CLI, deploy, ruoli e capacità di gestione sistemistica. Un managed multisito può semplificare l’operatività; un cloud o una VPS gestiti offrono più controllo quando esiste già un processo tecnico affidabile.

6. Backup, staging e migrazione

“Backup giornaliero” non basta per valutare un piano. Controlla frequenza, retention, copertura di file e database, posizione delle copie, possibilità di export, costo del ripristino e restore completo o selettivo. Per siti importanti, mantieni anche una copia indipendente e prova periodicamente il recupero.

Verifica le caratteristiche dello staging prima di usarlo per aggiornamenti delicati: risorse disponibili, cache, gestione di email e webhook, pagamenti, protezione con password e noindex. Lo staging può differire dalla produzione; i provider documentano spesso limiti e comportamenti specifici dei propri ambienti.

Se cambi hosting, prepara un backup indipendente e un piano di rollback. Testa il nuovo ambiente prima dello switch e controlla DNS, SSL, login, form, checkout, email, webhook, API e cron. Dopo il passaggio verifica canonical, robots, sitemap e noindex, quindi monitora errori e tempi di risposta. Google raccomanda di testare il sito e di seguire il monitoraggio previsto durante una migrazione del sito.

La scelta finale dovrebbe essere concreta: confronta due o tre piani sulle stesse voci e scegli quello meno complesso che soddisfa il tuo caso d’uso, le esigenze di gestione e i picchi realistici del sito.