Ciao! Se stai leggendo questa guida è perché vuoi capire come far girare bene il tuo sito WordPress senza impazzire. Partiamo da zero: un sito WordPress, per funzionare, ha bisogno di un hosting, cioè un server (un computer sempre acceso) che lo ospita e lo rende visibile a chi naviga. WordPress è il CMS (content management system) più diffuso al mondo, e scegliere un hosting scadente o configurarlo male ti porta a cali di velocità, buchi di sicurezza e posizionamento Google che crolla. In questa guida vediamo gli 8 errori più comuni che fanno i principianti (e non solo), e come risolverli con soluzioni che funzionano davvero nel 2026.
Se guardi cosa si dice in giro sui forum e community come r/Wordpress e i forum ufficiali di WordPress.org in italiano, trovi sempre la stessa storia: la maggior parte dei problemi di lentezza, crash e malfunzionamenti del pannello di amministrazione non dipendono dal tema o dai plugin che hai installato, ma da come è configurato il tuo hosting. Capire questi errori vuol dire ottenere un sito veloce e stabile, che si carica in meno di 200 millisecondi e resta online il 99,99% del tempo.
1. Scegliere un piano condiviso economico per siti dinamici o e-commerce
Risposta diretta: Scegliere un hosting condiviso a basso costo per siti dinamici espone il portale al fenomeno del ‘noisy neighbor’ e all’overselling di CPU e RAM. La soluzione consiste nel migrare verso un’infrastruttura Cloud VPS, Kubernetes o un hosting WordPress gestito con risorse computazionali isolate e scalabili.
Il primo errore, e anche il più comune, è scegliere il piano hosting solo guardando il prezzo. Lo capisco: quando inizi, 3€ al mese sembrano meglio di 30€. Ma ecco cosa succede davvero: gli hosting economici (detti shared, condivisi) mettono centinaia di siti sullo stesso computer. Quando un sito vicino al tuo riceve molti visitatori o subisce un attacco, anche il tuo rallenta. Si chiama effetto “noisy neighbor” (vicino rumoroso) e sull’hosting economico lo paghi eccome.
I sintomi dell’overselling sui server condivisi
L’overselling succede quando il provider vende più spazio di quanto ne ha davvero. Te ne accorgi subito: il sito risponde veloce la mattina, lentissimo il pomeriggio, senza che tu abbia cambiato niente. Come si risolve: passa a un VPS (un server virtuale tutto tuo) o a un hosting gestito. Costa un po’ di più, ma il sito diventa stabile.
- Picchi di TTFB (Time to First Byte): La richiesta HTTP iniziale rimane in coda al web server in attesa di processi PHP liberi.
- Errori 503 Service Unavailable: Superamento istantaneo dei limiti imposti da cPanel o CloudLinux (LVE limits come I/O limits, NPROC o PMEM).
- Latenza nei salvataggi in wp-admin: L’interfaccia di WordPress diventa lenta durante la stesura di articoli o la gestione degli ordini.
Come superare il problema dell’hosting condiviso
La soluzione è semplice: migra su un hosting WordPress gestito (VPS, Cloud o Kubernetes), dove le risorse sono solo per te. Esempi pratici sono le guide su come scegliere un hosting WordPress e i confronti tra i migliori hosting in Italia. Spendi qualche euro in più al mese, ma guadagni in velocità, stabilità e sonno tranquillo.
2. Sottodimensionare i limiti PHP: Errori comuni con WordPress hosting e come evitarli
Risposta diretta: Limiti PHP inadeguati provocano il crash improvviso di processi pesanti come importazioni, checkout WooCommerce e generazione di backup. Per evitarli, imposta memory_limit = 256M (512M per WooCommerce), max_execution_time = 180 e max_input_vars = 5000 all’interno del file php.ini o .user.ini.
Il secondo errore riguarda i limiti PHP, cioè quanta memoria e tempo il tuo sito ha a disposizione per elaborare le pagine. Pensa a PHP come il cuoco di un ristorante: se ha un forno piccolo e poco tempo, non riuscirà a preparare piatti complessi. Valori come memory_limit = 128M o max_execution_time = 30 secondi vanno bene per un blog con 5 articoli, ma se hai un e-commerce o usi page builder pesanti, ti serve almeno 256M di memoria (o 512M per WooCommerce). Quando il limite è troppo basso, vedi errori tipo Fatal Error: Allowed memory size exhausted e perdi ordini o contenuti.
Configurazione ottimale dei parametri PHP in produzione
In pratica, cosa scrivere nel wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');
Sono due righe che risolvono il 90% dei problemi di memoria. Chiedi al tuo hosting di configurare anche il PHP-FPM lato server con valori coerenti.
| Direttiva PHP | Valore Minimo Default | Valore Consigliato (Blog/Portfolio) | Valore Consigliato (E-commerce/LMS) |
|---|---|---|---|
memory_limit | 64M – 128M | 256M | 512M – 1024M |
max_execution_time | 30s | 120s | 300s |
max_input_vars | 1000 | 3000 | 5000 – 10000 |
post_max_size | 8M | 64M | 128M – 256M |
upload_max_filesize | 2M | 64M | 128M – 256M |
Come si risolve al meglio: il tuning di PHP-FPM (il gestore dei processi PHP) va fatto in base al traffico reale del tuo sito. pm.max_children troppo alto = saturi la RAM. Troppo basso = le code si allungano. La formula standard è RAM disponibile (MB) / 50 = max_children. Su un server con 4GB di RAM dedicati a PHP, imposti circa 80 processi massimi.
3. Errori comuni con WordPress hosting e come evitarli nella gestione della Cache Server
Risposta diretta: Il mancato utilizzo della cache lato server costringe l’interprete PHP a rigenerare l’HTML a ogni visita, saturando la CPU. Evita questo errore abilitando moduli a livello web server (Nginx FastCGI Cache, LiteSpeed LSCache) abbinati a un Object Cache in-memory come Redis.
Il terzo errore è la cache, e qui c’è confusione. Molti installano un plugin di cache sul frontend (tipo WP Super Cache o W3 Total Cache) e pensano di aver finito. In realtà, senza una cache a livello server (Nginx FastCGI Cache o LiteSpeed Cache) abbinata a una cache in memoria (Redis), il tuo sito continua a rielaborare ogni pagina da zero a ogni visita, anche se non è cambiata nulla. In pratica: attiva la cache server-side, non solo quella del plugin.
Page Cache vs. Object Cache: La sinergia necessaria
Page Cache e Object Cache non sono la stessa cosa:
- Server-Level Full Page Caching: Gestita direttamente dal web server (Nginx via
fastcgi_cacheo LiteSpeed Enterprise con LSCache). Il web server intercetta la richiesta ed eroga l’HTML statico in memoria RAM in meno di 50ms, senza mai invocare il processo PHP-FPM. - Persistent Object Caching (Redis / Memcached): Conserva in memoria RAM i risultati delle query SQL complesse (opzioni di configurazione, metadati utente, sessioni carrello). In questo modo, quando un utente registrato effettua una richiesta dinamica, il server evita di interrogare ripetutamente il disco fisso o il database MySQL.
Un errore subdolo: mettere troppi livelli di cache non coordinati tra loro (es. Cloudflare Cache Everything + un plugin WordPress + cache del tema). Risultato: vedi contenuti vecchi, oppure il carrello WooCommerce si confonde tra utenti diversi. Regola d’oro: scegli UN livello principale di cache server-side, configurato bene, e sopra aggiungi solo layer compatibili.
4. Utilizzo di versioni PHP obsolete e configurazioni PHP-FPM non calibrate
Risposta diretta: Mantenere versioni PHP deprecate (come PHP 7.4 o 8.0) espone il server a gravi falle di sicurezza e riduce il throughput fino al 35%. La soluzione consiste nell’aggiornare l’interprete a PHP 8.2 o 8.3 e calibrare il gestore processi PHP-FPM in base alla RAM effettiva.
Il quarto errore è usare versioni PHP vecchie. PHP 7.4 e 8.0 sono in “end of life” (fine vita) dal 2022: non ricevono più aggiornamenti di sicurezza, e sono sensibilmente più lente (fino al 35% in meno di velocità). Passare a PHP 8.2 o 8.3 è gratis lato hosting e ti dà anni di supporto e performance. Come verificare: vai su Strumenti → Salute del sito nel pannello WordPress, ti dice subito quale versione stai usando.
Il tuning matematico del pool PHP-FPM
Il tuning di PHP-FPM (il sistema che gestisce i processi PHP) è spesso ignorato ma fa una differenza enorme. I parametri chiave sono 3:
Setup consigliato per un sito WordPress serio: metti Nginx davanti ad Apache (configurazione reverse proxy), oppure usa OpenLiteSpeed. Apache da solo, senza reverse proxy, deve avviare PHP per ogni richiesta, anche quando potrebbe servire un file già cachato. Con Nginx davanti, le richieste statiche (CSS, JS, immagini) vengono servite senza toccare PHP, alleggerendo tutto.
Il quinto errore riguarda il database, e qui la metafora è una biblioteca: se non metti i libri a posto e non butti i vecchi giornali, prima o poi non trovi più niente. Con WordPress succede che le tabelle wp_options e wp_postmeta crescono a dismisura per via di plugin disinstallati male, transienti scaduti, e revisioni infinite. Risultato: ogni query al database rallenta. Dopo 3 anni, un sito tipico supera i 250MB di overhead. Come si risolve: ottimizza le tabelle regolarmente con phpMyAdmin o WP-Optimize.
5. Gestione errata del database MySQL/MariaDB e overhead delle tabelle
Risposta diretta: Database non manutenuti soffrono di frammentazione delle tabelle, accumulo di transienti scaduti e saturazione della tabella wp_options per dati con autoload attivo. Risolvi ottimizzando periodicamente le query, pulendo le revisioni e allocando un innodb_buffer_pool_size pari al 70% della RAM del DB.
Il trucco che risolve il 30% dei problemi: vai su phpMyAdmin, apri la tabella wp_options, e lancia questa query SQL:
SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 30;
Vedrai quali opzioni caricano più peso a ogni richiesta. Spesso sono di plugin disinstallati. Rimuovile e il tuo sito respirerà.
Il problema della tabella wp_options e dell’autoload
Quando un utente loggato (es. tu nell’admin, o un cliente che sta comprando) fa un’azione, l’Object Cache in RAM (Redis o Memcached) evita di chiedere le stesse cose al database più e più volte. Su WooCommerce con molti ordini, o su siti membership, fa una differenza enorme. Configuralo seguendo le istruzioni del plugin Redis Object Cache (gratuito e ben mantenuto).
- Controllo dimensione autoload: Eseguire regolarmente la query
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';per assicurarsi che resti sotto gli 800 KB. - Configurazione InnoDB: Assicurarsi che tutte le tabelle utilizzino il motore InnoDB (e non il vecchio MyISAM) e che il parametro
innodb_buffer_pool_sizesia sufficientemente capiente da mantenere l’intero database caricato nella RAM del server.
6. Errori comuni con WordPress hosting e come evitarli nella strategia di Backup
Risposta diretta: Salvare i file di backup sullo stesso storage dell’hosting appesantisce il disco, consuma inode e rende inutilizzabile il salvataggio in caso di compromissione del server. La prassi corretta prevede backup automatici a livello di snapshot salvati su cloud storage off-site crittografato (AWS S3, Google Cloud Storage o Wasabi).
Il sesto errore è il backup, e qui tantissimi lo fanno nel modo sbagliato. L’errore classico: salvare i backup sullo stesso disco dell’hosting. Così facendo appesantisci il server, riempi lo spazio disco, e quando davvero ti serve il ripristino è lentissimo. Regola d’oro: un backup che non puoi ripristinare in 15 minuti non è un backup, è una preghiera. Come si risolve: configura un backup WordPress automatico su uno spazio separato, idealmente off-site (S3, Wasabi, Backblaze, Google Drive).
La regola del backup 3-2-1 per WordPress
La regola 3-2-1 è semplice e ti salva la vita:
- 3 copie dei dati: Il sito di produzione attivo e due archivi completi e indipendenti.
- 2 supporti/infrastrutture differenti: Snapshot a livello di block storage dell’hosting e archivio compresso su Object Storage S3 compatibile.
- 1 copia off-site geograficamente remota: Il backup deve risiedere in un data center situato in una regione geografica differente rispetto al server principale, garantendo il ripristino istantaneo in caso di blackout o guasti catastali del provider.
7. Ignorare la sicurezza a livello server e l’isolamento dei permessi file
Risposta diretta: Assegnare permessi 777 a cartelle e file, disattivare il firewall per risolvere conflitti e utilizzare certificati SSL non automatici sono gravi errori sistemistici. Mantieni i permessi a 755 per le directory e 644 per i file, implementando un Web Application Firewall (WAF) a monte del traffico.
Consiglio pratico: testa il ripristino almeno una volta al trimestre. Non una volta sola. Fallo davvero. Ripristina il backup in un ambiente di staging (una copia del sito) e verifica che funzioni tutto. Un backup mai testato è come un estintore senza manometro: scopri che non funziona quando c’è l’incendio.
Hardening essenziale del web server
Il settimo errore è la sicurezza lato server. Errori classici da principiante: permessi dei file a 777 (mai, mai, mai), wp-config.php leggibile dal web, utente database con troppi privilegi. Se usi un hosting serio, molti di questi errori non li puoi proprio fare, ma sullo shared hosting li vedo continuamente. Soluzioni rapide: leggi la guida completa alla sicurezza WordPress, installa un firewall (Wordfence o Sucuri), e ricorda: minimo privilegio possibile, sempre.
- Blocco dell’esecuzione PHP nella cartella uploads: Impedire rigorosamente l’esecuzione di file
.phpall’interno di/wp-content/uploads/per neutralizzare la maggior parte delle backdoor caricate tramite form o vulnerabilità di plugin. - Protezione dell’endpoint xmlrpc.php e wp-login.php: Bloccare le chiamate XML-RPC e limitare le richieste brute force su
wp-login.phptramite rate limiting nativo o regole Cloudflare WAF. - Disabilitazione dell’editing file da bacheca: Inserire
define('DISALLOW_FILE_EDIT', true);nel filewp-config.phpper impedire a eventuali account compromessi di modificare file di temi e plugin direttamente dalla dashboard amministrativa.
8. Dipendere dal WP-Cron predefinito invece di configurare un Cron Job di sistema
Risposta diretta: Il sistema predefinito WP-Cron (wp-cron.php) viene innescato unicamente dal caricamento delle pagine da parte dei visitatori, causando latenza nelle visite o mancata esecuzione dei task pianificati. Disabilita il cron virtuale e imposta un cron job reale a livello di sistema operativo ogni 5-10 minuti.
Sull’hosting condiviso, un aspetto spesso sottovalutato: l’isolamento dei processi PHP tra un sito e l’altro. Se il tuo vicino di server ha un sito compromesso, e l’isolamento non è configurato bene, anche il tuo è a rischio. I container (Docker, LXC) con utenti separati sono lo standard minimo. Chiedi al tuo provider come gestisce l’isolamento: se non ti rispondono in modo chiaro, cambia provider.
- Su siti a basso traffico: I compiti programmati non vengono eseguiti per ore o giorni fino alla visita successiva.
- Su siti ad alto traffico: Migliaia di visite contemporanee innescano altrettante chiamate a
wp-cron.php, provocando lock del database, concorrenza nei processi e spreco ingente di CPU.
L’ottavo errore è il WP-Cron, il sistema di WordPress per le attività programmate (pubblicare articoli in automatico, inviare email, fare backup). Funziona in modo un po’ strano: si attiva solo quando qualcuno visita il sito. Su siti con poco traffico, le pubblicazioni partono in ritardo, i backup saltano, le email non escono. Come si risolve in 2 minuti:
Un cron reale a livello di sistema operativo è una riga in crontab e ti mette al sicuro da tutti i problemi del cron virtuale. Funziona anche se il sito non riceve visite. Funziona anche alle 3 di notte. È una delle cose che separa un sito amatoriale da uno professionale. La guida per creare un sito web da zero copre questo passaggio in dettaglio.
Errore bonus: alcune operazioni pesanti (generare PDF, export di migliaia di righe, invio massivo di email) non vanno mai fatte dentro il ciclo di una richiesta utente. L’utente aspetta, il server soffre, e se il processo muore a metà hai un disastro. Soluzione: mettile in coda con WP-Cron, oppure meglio ancora con un sistema di code esterno tipo Redis Queue o AWS SQS.
Qui sotto trovi una tabella riassuntiva con tutti gli 8 errori, i sintomi tecnici per riconoscerli, e l’azione correttiva da fare subito. Stampala e tienila vicino quando fai audit su un cliente o quando il tuo sito inizia a rallentare e non capisci perché.
Matrice Comparativa: Errori di Hosting, Sintomi Tecnici e Azioni Correttive
Se non hai voglia di controllare tutto a mano, esistono strumenti diagnostici che fanno la maggior parte di questi controlli in 30 secondi. Plugin consigliati: Query Monitor (per le performance del database), WP Health (per la salute generale), e il tuo hosting manager che dovrebbe già darti report periodici sullo stato del server.
| Errore di Hosting | Sintomo Tecnico Rilevato | Impatto sul Business | Azione Correttiva Immediata |
|---|---|---|---|
| Overselling Risorse | TTFB instabile, errori 503 frequenti | Perdita conversioni e ranking SEO | Migrazione a Cloud VPS / Managed Hosting isolato |
| Limiti PHP Bassi | Fatal error Allowed Memory Size, Timeout 504 | Blocco checkout e salvataggi | memory_limit >= 256M, max_execution_time >= 120s |
| No Server Cache | CPU al 100% durante picchi di traffico | Crash del server e lentezza generale | Nginx FastCGI Cache + Redis Object Cache |
| Backup sullo stesso disco | Saturazione spazio disco / Inode esauriti | Perdita irreversibile dei dati del sito | Snapshot automatizzati su Object Storage S3 off-site |
| PHP EOL / No WAF | Iniezioni malware, TTFB degradato | Blacklist Google e violazioni GDPR | Aggiornamento a PHP 8.2/8.3 + WAF di frontiera |
| WP-Cron Virtuale | Task non eseguiti o lock tabelle DB | Mancato invio email, code bloccate | Disattivare wp-cron e attivare crontab di sistema CLI |
- Qual è il limite minimo di PHP memory_limit raccomandato per WordPress nel 2026?
- u003cpu003eNel 2026 il limite minimo consigliato per installazioni standard con WooCommerce o page builder come Elementor/Gutenberg è di u003cstrongu003e256Mu003c/strongu003e (o u003cstrongu003e512Mu003c/strongu003e per siti e-commerce complessi). Valori inferiori a 128M provocano frequenti errori di esaurimento memoria (Fatal Error: Allowed memory size of bytes exhausted).u003c/pu003e
- Perché un hosting condiviso economico causa rallentamenti su WordPress?
- u003cpu003eGli hosting condivisi a basso costo applicano un’elevata densità di tenancy (overselling) sullo stesso server. Se i siti vicini consumano CPU, I/O disco o memoria, il tuo sito subirà ‘CPU throttling’, rallentamenti del TTFB (Time to First Byte) e timeout nei picchi di traffico.u003c/pu003e
- Che differenza c'è tra Object Cache e Page Cache su WordPress hosting?
- u003cpu003eLa u003cstrongu003ePage Cacheu003c/strongu003e memorizza l’output HTML finale della pagina per servirlo istantaneamente agli utenti non loggati. L’u003cstrongu003eObject Cacheu003c/strongu003e (come Redis o Memcached) memorizza le singole query al database in memoria RAM, velocizzando le operazioni dinamiche del backend e degli utenti autenticati.u003c/pu003e
- Come si previene l'errore 'Error Establishing a Database Connection'?
- u003cpu003eSi previene monitorando le risorse di connessione del database (max_connections), ottimizzando le tabelle da overhead e transienti scaduti, verificando le credenziali in wp-config.php e scegliendo un hosting con processi MySQL/MariaDB isolati e protetti da crash per OOM.u003c/pu003e
- Quale versione di PHP garantisce le migliori performance e sicurezza?
- u003cpu003eNel 2026 le versioni supportate e consigliate sono u003cstrongu003ePHP 8.2 e PHP 8.3u003c/strongu003e (con transizione a 8.4). Le versioni precedenti (come PHP 7.4 o 8.0) hanno raggiunto il termine del supporto di sicurezza (EOL) e risultano fino al 35% più lente nell’elaborazione del codice.u003c/pu003e
Conclusioni e Checklist Operativa
In conclusione: conoscere gli errori comuni con WordPress hosting e come evitarli è quello che separa un sito che crolla sotto carico da uno che regge. Non serve essere esperti: basta partire dalle basi giuste. Investi in:
Se ti serve una mano, possiamo fare un audit sistemistico completo del tuo setup attuale e dirti esattamente cosa migliorare. Se invece vuoi migrare senza disservizi verso un’infrastruttura ottimizzata per WordPress, dai un’occhiata ai nostri piani di hosting gestito. Nessuna pressione, siamo qui se hai bisogno.
Lascia un commento