wp-cron e automazioni WordPress: scheduling affidabile senza affidarsi al traffico (che non arriva)

wp-cron gira su ogni visita ed è inaffidabile su siti a basso traffico o su hosting cloud con page cache. I backup non partono, i post pianificati non si pubblicano, le sincronizzazioni saltano. Come disabilitare wp-cron nativo, sostituirlo con un cron di sistema, e schedulare tutto in modo affidabile.
wp-cron è una delle idee più geniali e più problematiche di WordPress. Invece di affidarsi a un cron di sistema (quello che su Linux si chiama crontab), WordPress esegue le attività schedulate — backup, pubblicazione di post pianificati, sincronizzazioni, scadenze — su ogni visita. Quando un utente carica una pagina, WordPress controlla se ci sono task in coda e li esegue. È geniale perché funziona ovunque, anche su hosting condiviso dove non hai accesso al crontab. È problematico perché dipende dal traffico: se nessuno visita il sito, i task non partono.
Lo scenario più comune: un cliente pianifica un articolo per le 9:00 di lunedì mattina. Il lunedì alle 9:00 il sito ha 3 visitatori. wp-cron controlla la coda al primo caricamento di pagina, ma se la page cache serve l'HTML senza far girare PHP, wp-cron non viene mai attivato. L'articolo resta in stato "pianificato" finché qualcuno non carica una pagina non cachata — che potrebbe essere ore dopo, o mai. Il cliente chiama alle 11:00 chiedendo perché il suo articolo non è online. La risposta è wp-cron.
Perché wp-cron è inaffidabile (e quando lo è di più)
wp-cron funziona così: ogni volta che una pagina viene caricata, WordPress fa una richiesta HTTP interna a wp-cron.php. Se la page cache serve la pagina senza far girare PHP — cosa che fa qualsiasi hosting con cache a livello server — wp-cron non viene mai attivato. Su un sito con molto traffico, le richieste non cachate (admin, AJAX, pagine dinamiche) sono sufficienti a far girare wp-cron regolarmente. Su un sito a basso traffico, o uno dove quasi tutto è cachato, wp-cron può non girare per ore.
Il secondo problema è il timeout. wp-cron.php ha un timeout di default di 60 secondi. Se un task (un backup completo, una sincronizzazione con un'API esterna) impiega più di 60 secondi, viene interrotto. Su un database grande, un backup può impiegare minuti. wp-cron lo interrompe, il backup è incompleto, e nessuno lo sa finché non serve un ripristino e scopre che l'ultimo backup valido è di tre settimane fa.
La soluzione: disabilitare wp-cron e usare un cron di sistema
La soluzione corretta è disabilitare wp-cron nativo e sostituirlo con un cron di sistema che chiama wp-cron.php a intervalli regolari, indipendentemente dal traffico. Su hosting gestito con accesso SSH (o un pannello che supporta i cron), si fa in due passi.
Primo: disabilita wp-cron nativo in wp-config.php:
// wp-config.php — disabilita wp-cron nativo
define( 'DISABLE_WP_CRON', true );
// wp-cron non verrà più attivato dalle visite.
// I task schedulati restano in coda e vengono eseguiti
// solo quando wp-cron.php viene chiamato esplicitamente
// (dal cron di sistema, vedi sotto).Secondo: configura un cron di sistema che chiama wp-cron.php ogni minuto (o ogni 5 minuti). Su un server Linux con accesso SSH:
# Crontab — esegui wp-cron.php ogni 5 minuti
# Modifica con: crontab -e
*/5 * * * * curl -s https://www.example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
# Oppure con WP-CLI (più affidabile, non dipende da HTTP):
*/5 * * * * cd /var/www/example.com && wp cron event run --due-now --allow-root > /dev/null 2>&1
# Verifica che il cron funzioni:
# wp cron event list --allow-root
# wp cron event run --all --allow-rootI task che più spesso saltano (e perché non lo sai)
I task wp-cron più critici che vediamo saltare regolarmente: i backup automatici (se il plugin usa wp-cron, il backup non parte se il traffico è basso); la pubblicazione dei post pianificati (l'articolo resta in stato pianificato); le sincronizzazioni con servizi esterni (CRM, newsletter, API di pagamento); i report periodici (il report mensile non viene generato); la pulizia del database (revisioni e transients si accumulano).
Il problema è che nessuno se ne accorge finché non serve. Il backup non parte per settimane, e lo scopri quando hai bisogno di un ripristino e l'ultimo backup valido è di un mese fa. Il post pianificato non si pubblica, e lo scopri quando il cliente chiama. La sincronizzazione con il CRM salta, e lo scopri quando un lead non arriva nel sistema. wp-cron silenzioso è il fall mode più pericoloso perché non dà errori — semplicemente non fa nulla.
Verificare che wp-cron stia funzionando
Dopo aver configurato il cron di sistema, verifica che i task vengano eseguiti. Il modo più semplice è controllare i timestamp dell'ultima esecuzione:
# WP-CLI: lista tutti i task schedulati con il prossimo esecuzione
wp cron event list --allow-root
# Output esempio:
# +------------------------+----------+------------------+-------+
# | hook | schedule | next_run | args |
# +------------------------+----------+------------------+-------+
# | wp_backup_daily | 1 day | 2026-10-25 09:00 | [] |
# | wp_scheduled_publish | 1 hour | 2026-10-24 13:00 | [] |
# +------------------------+----------+------------------+-------+
# Se next_run è nel passato, il task non è stato eseguito.
# Esegui manualmente per testare:
wp cron event run wp_backup_daily --allow-root
# Controlla i log del cron di sistema:
grep CRON /var/log/syslog | tail -20wp-cron su hosting cloud con page cache
Il caso più insidioso è l'hosting cloud con page cache a livello server. Se la page cache serve ogni pagina senza far girare PHP, wp-cron non viene mai attivato dalle visite — nemmeno su un sito ad alto traffico. La soluzione è la stessa: disabilitare wp-cron nativo e usare un cron di sistema. Ma su hosting cloud (Cloudflare Workers, Vercel, ambienti serverless), il cron di sistema potrebbe non essere disponibile — in quel caso, usa un servizio di cron esterno (cron-job.org, EasyCron) che chiama wp-cron.php a intervalli regolari.
Su un hosting WordPress gestito di qualità, il cron di sistema è configurato di default: wp-cron è disabilitato e i task vengono eseguiti ogni 5 minuti dal cron del server, indipendentemente dal traffico. È una di quelle cose che non vedi finché non hai problemi — ma quando hai problemi, capisci quanto vale. Un backup che parte sempre, un post che si pubblica sempre in orario, una sincronizzazione che non salta mai: sono cose che non dovresti nemmeno dover pensare.
Codice pulito, prestazioni e dipendenze ridotte al minimo.
Sviluppo WordPress personalizzato: temi leggeri, plugin su misura e integrazioni API senza appesantire il sito.
Articoli correlati

Integrazione API in WordPress: collegare il sito al CRM senza appesantire il database
Leggi
MU plugin WordPress: l'arma sottoutilizzata per modifiche che sopravvivono agli aggiornamenti del tema
Leggi
