Scegliere l’hosting non significa trovare il piano con più spazio, quello con lo sconto più alto o il provider che promette genericamente prestazioni migliori. La scelta corretta parte dal sito che devi ospitare: quanto lavoro deve svolgere, quali risorse richiede, quanto è importante la continuità del servizio e quanta parte della gestione tecnica vuoi delegare.
Se prima vuoi chiarire le basi, nella guida dedicata trovi cos’è un hosting e come funziona. Qui partiamo invece dal passaggio successivo: come scegliere l’hosting adatto a un progetto reale.
Il principio più utile è semplice: non esiste un hosting migliore in assoluto. Esiste un’infrastruttura più o meno coerente con il carico di lavoro, con le competenze disponibili e con il livello di servizio richiesto.
Da cosa partire per scegliere un hosting
Prima di confrontare provider e piani conviene definire i requisiti. Molte offerte sembrano simili perché utilizzano le stesse etichette commerciali, ma differiscono per risorse, limiti, gestione, backup, supporto e condizioni di rinnovo.
Il confronto diventa più semplice se parti da tre domande: che cosa deve fare il sito, quali risorse può realisticamente richiedere e chi dovrà occuparsi dell’infrastruttura quando qualcosa cambia o smette di funzionare.
Tipo di sito e carico di lavoro
Un sito aziendale con poche pagine prevalentemente statiche produce un carico diverso da un ecommerce con utenti autenticati, carrello, checkout, ricerche, filtri e numerose operazioni sul database.
Lo stesso vale per un blog. Un progetto editoriale con poche visite e contenuti facilmente memorizzabili in cache può richiedere relativamente poche risorse; un magazine con traffico elevato, molte query, utenti loggati o processi in background può avere esigenze ben superiori.
Il numero di pagine del sito, da solo, dice quindi poco.
Conta soprattutto quanto lavoro deve essere eseguito per rispondere alle richieste.
Per questo non sceglierei un VPS soltanto perché il sito è “professionale”, né un piano condiviso soltanto perché il progetto è appena nato. Prima bisogna capire il workload.
Risorse realmente necessarie
Spazio disco e traffico mensile sono i valori più facili da mostrare in una tabella commerciale, ma non sempre sono quelli che determinano il comportamento di un sito dinamico.
CPU, memoria, processi simultanei, I/O, limiti PHP, capacità del database e politiche di utilizzo delle risorse possono diventare molto più importanti.
Il punto non è acquistare il valore più alto possibile. È individuare la risorsa che rischia realmente di diventare un collo di bottiglia.
Un sito con pochi gigabyte di file può richiedere molta capacità di elaborazione. Al contrario, un archivio fotografico può occupare parecchio spazio senza richiedere un’infrastruttura particolarmente complessa.
Quando confronti i piani cerca quindi di capire non soltanto quanto spazio viene offerto, ma anche come vengono allocate e limitate le risorse che fanno funzionare l’applicazione.
Quanto controllo vuoi gestire
La seconda variabile spesso trascurata è la responsabilità operativa.
Avere più controllo non è automaticamente un vantaggio.
Su un ambiente molto gestito il provider può occuparsi di una parte significativa della configurazione, degli aggiornamenti dell’infrastruttura, del monitoraggio e di altre attività sistemistiche.
Con un VPS non gestito puoi invece avere una libertà molto maggiore, ma quella libertà comporta anche responsabilità: configurazione, aggiornamenti, sicurezza del sistema, troubleshooting e manutenzione possono ricadere su di te.
Un pannello di controllo può ridurre una parte di questa complessità, ma non cambia automaticamente il livello di gestione del servizio. Strumenti come Plesk o ispmanager permettono di amministrare server, domini, database, certificati, backup e applicazioni da un’interfaccia centralizzata; su un VPS unmanaged, però, aggiornamenti di sistema, sicurezza e troubleshooting possono restare comunque una tua responsabilità.
AWS indica proprio la competenza tecnica necessaria come uno dei punti da considerare nei VPS e nei server dedicati, mentre i servizi managed possono ridurre parte del lavoro di amministrazione.
Perciò, prima di scegliere, chiediti anche chi interverrà sul server alle tre di notte se l’applicazione smette di rispondere.
Quale tipo di hosting scegliere
Le categorie tradizionali non rappresentano una graduatoria universale. Condiviso, VPS, dedicato e cloud rispondono a esigenze differenti e, soprattutto, possono essere implementati in modi molto diversi dai singoli provider.
| Soluzione | Caratteristica principale | Ha senso quando |
|---|---|---|
| Hosting condiviso | Più account utilizzano la stessa infrastruttura | Vuoi semplicità gestionale e il progetto ha esigenze moderate |
| VPS | Ambiente virtualizzato con maggiore isolamento e controllo | Servono configurazioni o risorse più definite |
| Server dedicato | Accesso a una macchina fisica destinata al cliente secondo il servizio | Hai carichi o requisiti che giustificano risorse fisiche dedicate |
| Cloud hosting | Risorse erogate attraverso infrastrutture cloud | Servono elasticità, automazione o architetture distribuite |
| Managed hosting | Una parte maggiore della gestione viene delegata | Vuoi ridurre l’onere operativo indipendentemente dal tipo di infrastruttura |
Hosting condiviso
L’hosting condiviso rimane una scelta sensata per moltissimi siti.
Più clienti utilizzano risorse della stessa infrastruttura e il provider gestisce gran parte dell’ambiente. Questo permette normalmente di contenere costi e complessità.
Il possibile limite è proprio la condivisione delle risorse. Le modalità di isolamento e le policy variano, ma un ambiente condiviso offre generalmente meno libertà di configurazione rispetto a un VPS. AWS indica tra i limiti tipici anche il minor controllo sulla configurazione del server.
Non significa però che “condiviso” sia sinonimo di lento.
Un buon ambiente condiviso dimensionato correttamente può essere più adatto a un piccolo sito rispetto a un VPS configurato male.
VPS
Un VPS utilizza la virtualizzazione per creare ambienti separati all’interno dell’infrastruttura fisica.
È interessante quando hai bisogno di maggiore controllo, di risorse assegnate più chiaramente o della possibilità di installare e configurare componenti che un piano condiviso non consente.
Il vantaggio comporta però un cambio di responsabilità.
Devi capire se il servizio è managed o unmanaged e, soprattutto, cosa significa concretamente “managed” per quel provider. Il perimetro dell’assistenza può essere molto diverso da un’offerta all’altra.
Server dedicato
Con un server dedicato disponi di una macchina fisica destinata al tuo ambiente secondo le condizioni del servizio acquistato.
È una soluzione da valutare quando isolamento, requisiti software, capacità di elaborazione o controllo dell’ambiente giustificano un’infrastruttura fisica dedicata.
Non è invece il passaggio obbligatorio dopo un VPS.
Le architetture cloud hanno reso molto meno lineare la vecchia progressione condiviso → VPS → dedicato. In molti progetti il passo successivo può essere un’infrastruttura distribuita oppure un servizio gestito che cambia completamente il modello operativo.
Cloud hosting
Nel cloud hosting le risorse vengono fornite attraverso infrastrutture che applicano i principi del cloud computing all’hosting di siti e applicazioni, distribuendo elaborazione e servizi secondo l’architettura adottata dal provider.
Fra i vantaggi potenziali ci sono elasticità e possibilità di adattare l’infrastruttura al carico, ma il termine “cloud” da solo non garantisce scalabilità automatica, assenza di downtime o prestazioni migliori.
Dipende dall’architettura realmente utilizzata.
Anche i modelli di costo possono cambiare: alcune piattaforme cloud utilizzano in misura significativa un pricing basato sulle risorse consumate anziché un semplice canone fisso.
Managed hosting
Managed non identifica un nuovo tipo di macchina.
Descrive soprattutto quanto della gestione viene presa in carico dal provider.
Puoi avere un VPS managed, un’infrastruttura cloud gestita oppure un servizio specializzato per un determinato CMS.
Questo aspetto è particolarmente importante se non vuoi amministrare direttamente sistema operativo, configurazione del web server, patch, monitoring e altri componenti.
Prima dell’acquisto verifica però il perimetro del servizio: “managed” non significa necessariamente che il provider intervenga su codice, tema, plugin o problemi applicativi del sito.
E il serverless?
Per applicazioni moderne esistono modelli nei quali una parte ancora maggiore della gestione dell’infrastruttura viene astratta. Un PaaS delega al provider gran parte della piattaforma applicativa, mentre i modelli serverless spingono ulteriormente l’astrazione dell’ambiente di esecuzione.
Google Cloud propone Cloud Run come ambiente serverless gestito con scaling automatico e modello a consumo.
Non lo considererei però semplicemente “un hosting migliore”.
È un modello architetturale diverso e, per un normale sito WordPress, non rappresenta automaticamente un’alternativa diretta a un piano hosting tradizionale.
Come scegliere l’hosting per WordPress, ecommerce e siti aziendali
Il software utilizzato cambia radicalmente i requisiti.
Un errore frequente è partire dall’etichetta del piano anziché dal comportamento dell’applicazione.
Hosting per WordPress
WordPress richiede un ambiente compatibile con PHP, database e requisiti della versione utilizzata, ma la semplice compatibilità non distingue un servizio adeguato da uno insufficiente.
Contano anche risorse PHP, cache, backup, staging, gestione delle versioni, strumenti disponibili, supporto e capacità dell’infrastruttura di assorbire il carico prodotto da tema e plugin.
Se utilizzi questo CMS, il confronto specifico è approfondito nella guida su come scegliere un hosting WordPress.
Per progetti WordPress standard, un servizio gestito ben dimensionato può avere più senso di un VPS che richiede manutenzione sistemistica non necessaria.
Se stai valutando un provider specifico, puoi applicare questi criteri alla nostra recensione di Serverplan, dove analizziamo soprattutto gestione WordPress, strumenti di sviluppo e assistenza, oppure alla recensione di Xlogic, in cui entriamo nel dettaglio di LiteSpeed, cPanel, risorse CPU e RAM dichiarate, prezzi e supporto.
Per capire invece cosa cambia quando passi a un managed WordPress premium, la nostra recensione Kinsta analizza anche PHP thread, richieste dinamiche, caching, overage e limiti delle risorse: aspetti che diventano particolarmente importanti per WooCommerce, membership e siti business-critical.
Se devi scegliere anche l’ambiente del server, trovi separatamente il confronto fra hosting Linux e hosting Windows.
Hosting per ecommerce
Un ecommerce introduce normalmente una percentuale maggiore di richieste dinamiche.
Carrello, checkout, utenti autenticati, ricerca, filtri, gestione degli ordini e integrazioni esterne non possono sempre beneficiare della cache nello stesso modo di una pagina editoriale statica.
Per questo non utilizzerei come regola:
ecommerce = VPS
Un piccolo negozio può funzionare correttamente su un buon ambiente gestito, mentre un ecommerce complesso può richiedere un’architettura molto più articolata.
La domanda da fare al provider è piuttosto: quale carico può sostenere il piano quando le richieste non possono essere servite direttamente dalla cache?
Hosting per un sito aziendale
Un sito aziendale relativamente semplice può avere un consumo di risorse contenuto, ma questo non significa che affidabilità e backup siano poco importanti.
La continuità può avere un valore commerciale maggiore del numero di visite.
Un’interruzione durante una campagna, un problema con un form o l’impossibilità di ripristinare rapidamente il sito possono avere conseguenze molto più importanti di qualche millisecondo di differenza in un benchmark.
In questo scenario darei quindi molto peso alla gestione, al backup e alla qualità del supporto, senza acquistare capacità computazionale inutile.
Le caratteristiche da confrontare prima dell’acquisto
Una volta scelto il modello infrastrutturale, puoi confrontare i singoli servizi.
Qui conviene distinguere le caratteristiche tecniche reali dalle etichette commerciali.
CPU, RAM, storage e limiti reali
Se il provider dichiara CPU e memoria, verifica come vengono assegnate e quali limiti si applicano.
Su alcuni servizi possono esserci restrizioni anche su processi, I/O, inode, database, connessioni o altre risorse.
La dicitura “traffico illimitato” o “spazio illimitato” non significa quindi necessariamente che ogni altra risorsa sia priva di vincoli.
Leggi le condizioni d’uso e cerca la documentazione sui limiti.
Per un sito dinamico preferisco conoscere un limite realistico piuttosto che leggere una promessa di capacità “infinita” impossibile da interpretare.
Backup e ripristino
La presenza del backup non basta.
Devi sapere con quale frequenza viene eseguito, per quanto tempo vengono conservate le copie, quali dati comprende, dove sono memorizzati e soprattutto come avviene il ripristino.
Un backup che esiste ma che non puoi recuperare rapidamente quando serve ha un valore operativo molto limitato.
Per progetti importanti verificherei anche se puoi scaricare o mantenere copie indipendenti dall’account hosting.
Sicurezza e HTTPS
Controlla quali aspetti sono gestiti dal provider e quali restano sotto la tua responsabilità.
La disponibilità di un certificato SSL/TLS è ormai una componente di base utile a servire il sito tramite HTTPS, ma non esaurisce il problema della sicurezza.
Isolamento dell’ambiente, aggiornamenti, backup, accessi, protezioni di rete e sicurezza dell’applicazione restano livelli distinti.
Evita quindi di interpretare “SSL incluso” come sinonimo di “sito protetto”.
Supporto tecnico
Il supporto diventa veramente importante quando devi diagnosticare un problema.
Verifica i canali disponibili, gli orari, i tempi previsti dal servizio e soprattutto che cosa il team supporta realmente.
Un provider può gestire perfettamente l’infrastruttura e non intervenire su un problema causato da un plugin WordPress. Un altro può offrire un servizio molto più applicativo.
Sono due modelli differenti.
Il supporto va quindi confrontato sul perimetro, non soltanto sulla presenza della chat.
SLA e disponibilità
Una percentuale di uptime acquista significato solo se sai come viene misurata.
Prima dell’acquisto controlla l’eventuale SLA, le esclusioni, le finestre di manutenzione, il metodo di calcolo e cosa accade se il livello dichiarato non viene rispettato.
Non adotterei una soglia universale del tipo “mai sotto il 99,9%” come faceva la vecchia versione dell’articolo: la decisione dipende dal progetto e dal contratto, non da un numero isolato mostrato in una pagina commerciale.
Scalabilità e possibilità di migrare
Un buon servizio non deve soltanto funzionare oggi.
Deve anche permetterti di capire cosa succederà quando aumenteranno traffico, database, storage o requisiti applicativi.
Verifica se puoi cambiare piano senza migrazione, aumentare singole risorse oppure passare a un’altra infrastruttura.
Allo stesso tempo controlla la portabilità: devi poter recuperare file, database e dati necessari a spostare il progetto.
L’assenza di una via d’uscita semplice può diventare un costo molto più importante dello sconto iniziale.
Quanto costa un hosting
Il costo è una delle query già intercettate da /hosting/, ma non utilizzerei più le vecchie fasce rigide “Base 30–60 €, Medio 70–100 €, Pro 150–300 €”.
Non rappresentano uno standard di mercato e invecchiano rapidamente.
Il confronto corretto riguarda invece quanto spenderai per ottenere le risorse e i servizi realmente necessari.
Prezzo iniziale e prezzo di rinnovo
Molti servizi utilizzano promozioni sul primo periodo.
Questo non è un problema in sé, ma significa che il prezzo mostrato nella landing page non sempre coincide con il costo strutturale del servizio.
Prima di scegliere confronta quindi prezzo iniziale, durata dell’impegno e prezzo al rinnovo.
Se devi acquistare più anni anticipatamente per ottenere il prezzo pubblicizzato, considera anche questo elemento nel confronto.
Cosa è realmente incluso
Dominio, email, backup, CDN, certificato, staging, migrazione e altri servizi possono essere inclusi, opzionali o disponibili soltanto su determinati piani.
Due offerte con un canone differente potrebbero quindi avere un costo totale molto più simile di quanto sembri.
Il prezzo dell’hosting non va confrontato come una singola cifra: va confrontato il pacchetto realmente necessario al progetto.
Costi che possono emergere dopo l’acquisto
Considera anche ciò che può accadere quando il progetto cresce.
Aumenti di storage, upgrade delle risorse, backup aggiuntivi, servizi email, CDN, gestione del server o assistenza specializzata possono modificare il costo complessivo.
Su alcune infrastrutture cloud entrano inoltre in gioco modelli a consumo. Google Cloud, per esempio, utilizza pricing legato all’utilizzo per numerosi servizi.
Per questo la domanda utile non è soltanto “quanto costa questo hosting?”, ma:
quanto costa mantenere il mio progetto su questa infrastruttura nello scenario realistico dei prossimi anni?
Hosting e prestazioni: quando l’infrastruttura diventa un limite
Un hosting può diventare un collo di bottiglia, ma non è corretto attribuirgli automaticamente qualsiasi problema di velocità.
Le prestazioni di un sito sono il risultato dell’intero stack.
Tema, plugin, query al database, cache, immagini, JavaScript, servizi di terze parti e infrastruttura possono contribuire contemporaneamente.
Come riconoscere un possibile limite dell’hosting
Uno dei segnali da osservare è il comportamento del backend.
Se il server impiega molto tempo prima di iniziare a restituire una risposta anche dopo aver escluso problemi evidenti dell’applicazione, vale la pena approfondire il TTFB.
Anche errori collegati ai limiti di risorse, rallentamenti sistematici nei picchi o problemi ricorrenti di disponibilità possono indicare che il piano non è più adeguato.
La diagnosi deve però essere ripetibile.
Un singolo test lento non dimostra che il provider sia il problema.
Misura prima di migrare
Prima di cambiare infrastruttura controlla il sito in condizioni rappresentative.
Strumenti come GTmetrix possono aiutare nella diagnosi, ma il punteggio finale non identifica automaticamente la causa.
Devi distinguere quello che avviene sul server da quello che accade successivamente nel browser.
Un nuovo hosting può produrre un miglioramento sostanziale quando elimina un limite infrastrutturale. Non può invece correggere da solo un frontend pesante o codice inefficiente.
Hosting e SEO: cosa può influenzare e cosa no
La vecchia versione dell’articolo collegava più volte in modo diretto “buon hosting”, velocità e posizionamento.
Qui la formulazione deve essere più precisa.
Prestazioni e disponibilità contano, ma non funzionano come una scorciatoia SEO
Google Search Central raccomanda buoni Core Web Vitals per Search e per l’esperienza degli utenti e spiega che questi segnali si inseriscono nel quadro più ampio della page experience.
Un’infrastruttura insufficiente può rendere più difficile ottenere buone prestazioni, servire le pagine in modo affidabile o gestire correttamente i picchi.
Da questo possiamo inferire che rimuovere un collo di bottiglia server-side può migliorare condizioni tecniche importanti.
Ma è una cosa diversa dal dire:
hosting migliore = ranking migliore
Google non documenta una relazione di questo tipo.
Core Web Vitals non misurano soltanto l’hosting
I Core Web Vitals attuali misurano aspetti dell’esperienza reale relativi a caricamento, reattività e stabilità visiva attraverso LCP, INP e CLS.
Solo una parte di ciò che determina questi risultati appartiene all’infrastruttura hosting.
Per esempio, un server rapido non impedisce a un’immagine hero enorme di ritardare il rendering, non elimina JavaScript eccessivo e non evita layout instabili causati dal frontend.
Se vuoi approfondire la distinzione, trovi la guida dedicata ai Core Web Vitals.
L’hosting va quindi scelto per creare condizioni tecniche adeguate al progetto, non come prodotto SEO.
Errori da evitare quando scegli un hosting
| Errore | Perché è un problema | Approccio migliore |
|---|---|---|
| Scegliere il piano più economico senza leggere il rinnovo | Il costo effettivo può cambiare molto | Confronta il costo sul periodo realistico |
| Comprare il piano più potente “per sicurezza” | Paghi risorse o complessità che potresti non usare | Parti dal workload |
| Guardare solo spazio e traffico | Potrebbero non essere i veri limiti | Controlla CPU, RAM, I/O e limiti applicativi |
| Pensare che VPS significhi automaticamente più velocità | Configurazione e gestione restano determinanti | Valuta ambiente, risorse e competenze |
| Pensare che cloud significhi automaticamente zero downtime | L’architettura effettiva fa la differenza | Verifica come sono implementate ridondanza e scaling |
| Confondere managed con una tipologia di server | Sono due dimensioni differenti | Separa infrastruttura e responsabilità operative |
| Scegliere in base a un benchmark generico | Il comportamento dipende anche dal tuo stack | Misura il tuo workload |
| Comprare “per la SEO” | L’hosting non garantisce ranking | Valutalo per prestazioni, affidabilità e gestione |
| Ignorare backup e uscita dal provider | Il problema emerge quando devi ripristinare o migrare | Controlla ripristino e portabilità prima dell’acquisto |
La logica comune è sempre la stessa: prima il requisito, poi la caratteristica.
Se fai il contrario, rischi di costruire la tua decisione intorno alle metriche che il provider ha scelto di mettere in evidenza.
Quando conviene cambiare hosting
Cambiare provider ha senso quando hai individuato un problema che la nuova infrastruttura può realisticamente risolvere.
Prestazioni insufficienti, limiti di risorse, downtime ricorrente, supporto non adeguato, funzionalità mancanti o impossibilità di scalare possono essere motivazioni concrete.
Anche l’aspetto economico conta, ma va confrontato con il costo e il rischio della migrazione.
Prima individua il motivo del cambio
Definisci esattamente cosa vuoi ottenere.
Se il problema è un TTFB elevato causato da risorse insufficienti, cerca una soluzione capace di rimuovere quel limite.
Se hai bisogno di una particolare versione software o di una configurazione non consentita, valuta un ambiente con il controllo necessario.
Se il vero problema è invece un plugin che esegue query inefficienti, trasferire lo stesso sito su un nuovo server potrebbe soltanto spostare il problema.
Una migrazione senza diagnosi rischia di essere un cambio di provider, non una soluzione.
Pianifica la migrazione prima di acquistare
Prima di spostare il sito verifica backup, database, DNS, certificati, email, configurazioni applicative e procedura di rollback.
Per progetti complessi il passaggio va trattato come una modifica infrastrutturale pianificata, non come la semplice copia di una cartella.
Abbiamo raccolto il processo generale nella guida alla migrazione di un sito web.
L’obiettivo non è soltanto trasferire il sito, ma farlo mantenendo dati, funzionalità e continuità del servizio.
Conclusione
Per scegliere l’hosting giusto non partirei dal provider e nemmeno dal prezzo.
Partirei dal progetto.
Definisci prima il carico di lavoro, le risorse necessarie, il livello di controllo che vuoi mantenere e quello che vuoi delegare. Solo dopo confronta condiviso, VPS, dedicato, cloud o una soluzione managed.
Poi verifica i dettagli che determinano il valore reale del piano: limiti delle risorse, backup, supporto, sicurezza, SLA, rinnovo e possibilità di migrazione.
Un sito semplice non diventa migliore perché gira su un’infrastruttura complessa. E un progetto esigente non diventa affidabile solo perché il piano porta la parola “cloud” o “premium”.
La scelta più solida è quella che riesci a motivare tecnicamente: questo hosting è adeguato perché risponde ai requisiti attuali del sito, lascia un margine ragionevole di crescita e non introduce costi o responsabilità che non servono.