WP-Cron si attiva solo quando qualcuno visita il sito: su siti a basso traffico i task ritardano o non partono, su siti ad alto traffico generano richieste parallele che appesantiscono il server. La soluzione è la stessa in entrambi i casi: aggiungere DISABLE_WP_CRON = true in wp-config(.)php e configurare un cron di sistema che chiami wp-cron.php ogni 15 minuti via cPanel o SSH. Per e-commerce WooCommerce il cron di sistema non è un’ottimizzazione opzionale.
Il post programmato per le 9:00 non è stato pubblicato. Il backup automatico di ieri notte non risulta nell’elenco di UpdraftPlus. Le email di notifica del plugin non arrivano più. In tutti e tre i casi, la causa è quasi certamente la stessa: qualcosa non va con il sistema di attività pianificate di WordPress.
Post programmati, avviare backup automatici, controllare aggiornamenti, inviare notifiche. Funziona in modo diverso da un cron di sistema Unix, e questa differenza è la causa di quasi tutti i problemi.
Come funziona WP-Cron (e perché non è un vero cron)
Un cron di sistema Unix esegue i task all’orario preciso per cui sono stati programmati: indipendentemente dal traffico, dal carico del server, da qualsiasi condizione esterna. Se hai programmato qualcosa per le 2:00 di notte, gira alle 2:00 di notte.
WP-Cron funziona diversamente. Ad ogni caricamento di pagina, WordPress controlla se ci sono task in coda il cui orario pianificato è già passato. Se li trova, li esegue. Se nessuno carica una pagina per ore, quei task restano in attesa.
Questo meccanismo è stato progettato per risolvere un problema reale: la maggior parte degli hosting condivisi non permette ai clienti di configurare cron di sistema. WP-Cron aggira questa limitazione usando il traffico del sito come trigger. Funziona bene su siti con traffico costante. Su siti con traffico basso o intermittente, o con molto traffico, crea i problemi descritti nella sezione successiva.
| Cron di sistema | WP-Cron |
|---|---|
| Esegue il task esattamente all'orario programmato | Esegue il task alla prima visita dopo l'orario programmato |
| Funziona indipendentemente dal traffico | Se nessuno visita, il task aspetta |
| Richiede accesso ai cron di sistema (VPS, hosting che lo permette) | Funziona su qualsiasi hosting, incluso il condiviso |
| Carico sul server controllato e prevedibile | Su alto traffico può generare richieste parallele a wp-cron.php |
I sintomi di un WP-Cron che non funziona
I problemi con WP-Cron si manifestano in due modi opposti, con cause diverse.
Sito a basso traffico: task che non partono
- Post programmati che non vengono pubblicati all’orario impostato.
- Azioni UpdraftPlus che saltano o partono in ritardo di ore.
- Email di notifica da plugin (WooCommerce, form di contatto, plugin di sicurezza) che non arrivano.
- Aggiornamenti automatici di plugin e temi che non vengono eseguiti.
La causa: se il sito non riceve visite nelle ore in cui i task sono programmati, WP-Cron non viene mai chiamato. I task rimangono in coda e partono solo alla visita successiva; che può essere ore dopo.
Sito ad alto traffico: task che rallentano il sito
- Il sito è lento in modo intermittente senza una causa apparente.
- wp-cron.php appare tra le richieste più lente nel pannello di monitoraggio delle performance.
- Il server mostra picchi di carico CPU in corrispondenza di alcune richieste di pagina.
La causa: su siti con molto traffico, molti visitatori caricano pagine contemporaneamente, e ognuno puo’ innescare wp-cron.php. Se un task richiede molto tempo (un backup, una sincronizzazione con API esterne), più istanze dello stesso task possono girare in parallelo consumando risorse. Se hai il monitoraggio uptime WordPress attivo, probabilmente vedi questo come spike ricorrenti nel tempo di risposta.
Diagnosticare il cron con WP Crontrol
wp cron event list via WP-CLI per chi preferisce la riga di comando.
La schermata mostra tutti gli eventi cron pianificati: nome del task, orario della prossima esecuzione, ricorrenza, e quale hook lo gestisce. Quello che cercare:
- Task in ritardo: se l’orario di “prossima esecuzione” è nel passato, WP-Cron non sta girando correttamente. Il task è in coda ma non viene mai chiamato.
- Task duplicati: lo stesso task con nome identico che appare più volte. Quasi sempre lasciato da un plugin mal configurato che ha creato lo stesso evento cron più volte. I duplicati consumano risorse ogni volta che girano.
- Task orfani: eventi con nomi non riconoscibili o che appartengono a plugin non più installati. Rimangono in wp_options anche dopo la disinstallazione e vengono eseguiti inutilmente.
I task cron orfani si accumulano nella tabella wp_options insieme agli altri dati di autoload. Pulizia del cron e ottimizzazione del database WordPress vanno fatte insieme nella manutenzione mensile.
Per eliminare un task da WP Crontrol: clicca su “Elimina” accanto all’evento. Per i task duplicati, elimina tutte le istanze tranne una; o tutte, se il plugin responsabile è stato disinstallato.
Quando WP-Cron è sufficiente e quando non lo è
WP-Cron funziona bene in uno scenario specifico: sito con traffico costante durante le ore in cui i task sono programmati, task che non richiedono esecuzione in orari precisi, hosting condiviso senza accesso ai cron di sistema. Un blog personale con decine di visitatori al giorno entra in questa categoria.
In tutti gli altri casi vale la pena sostituirlo. Tre scenari concreti:
Sito a basso traffico o con traffico irregolare
Nessuno visita il sito alle 3:00 di notte quando il backup è programmato. Il backup parte alle 10:00 del mattino, quando arriva il primo visitatore. Se nel frattempo il sito aveva un problema, il backup precedente all’incidente non c’è. La soluzione è un cron di sistema che esegue wp-cron.php ogni 15 minuti indipendentemente dal traffico.
E-commerce WooCommerce
WooCommerce dipende pesantemente da WP-Cron per sincronizzare ordini, aggiornare inventari, inviare email transazionali, pulire sessioni scadute. Su un e-commerce con ordini anche notturni, un WP-Cron che gira solo quando c’è traffico è inaffidabile per definizione. Qui il cron di sistema è obbligatorio, non una scelta.
Sito ad alto traffico
wp-cron.php in parallelo. Disabilitare WP-Cron elimina questo overhead e sposta l’esecuzione dei task a un processo dedicato con cadenza controllata.
Come sostituire WP-Cron con un cron di sistema
Passo 1 — Disabilita WP-Cron in wp-config(.)php
define('DISABLE_WP_CRON', true);Aggiungi questa riga in wp-config(.)php prima della riga /* That’s all, stop editing! */
Da questo momento, WordPress non eseguirà più WP-Cron ad ogni caricamento di pagina. I task in coda non vengono persi: restano pianificati, ma non partono finché non viene chiamato wp-cron.php esternamente.
Non disabilitare WP-Cron senza configurare immediatamente un cron di sistema. Senza un’alternativa, tutti i task pianificati smettono di girare: niente aggiornamenti automatici, niente backup programmati, niente email da plugin.
Passo 2 — Configura il cron di sistema via cPanel
Accedi a cPanel → Advanced → Cron Jobs. Aggiungi un nuovo cron con questa configurazione:
- Frequenza: ogni 15 minuti (espressione: */15 * * * *)
- Comando: scegli uno dei due in base al tuo hosting:
Via wget:
wget -q -O /dev/null https://tuosito.it/wp-cron.php?doing_wp_cron
Via PHP CLI (se wget è disabilitato o il tuo hosting blocca le richieste loopback):
cd /home/utente/public_html && php wp-cron.php > /dev/null 2>&1
Sostituisci il percorso con quello reale della tua installazione WordPress.
Una nota sulla frequenza: 15 minuti è il valore standard per siti con task critici (e-commerce, form, notifiche). Per siti standard senza task urgenti, ogni 30 minuti è sufficiente.
Passo 3 — Configura via SSH con crontab (VPS o server dedicato)
Se hai accesso SSH, modifica il crontab dell’utente:
crontab -e
Aggiungi questa riga:
*/15 * * * * cd /percorso/wordpress && php wp-cron.php > /dev/null 2>&1
Salva e chiudi. Il cron di sistema eseguirà wp-cron.php ogni 15 minuti, indipendentemente dal traffico del sito.
Passo 4 — WP-CLI: il metodo più affidabile su VPS
wp-cron.php direttamente. WP-CLI esegue il cron nel contesto corretto di WordPress, evitando problemi con path PHP e variabili di ambiente:
*/15 * * * * cd /percorso/wordpress && wp cron event run --due-now > /dev/null 2>&1
Verifica che il cron di sistema funzioni
Dopo aver configurato il cron di sistema, torna su WP Crontrol → Strumenti → Cron Events e controlla che gli orari di “prossima esecuzione” dei task si aggiornino regolarmente. Se un task ha l’orario nel passato per più di 30 minuti dopo aver configurato il cron, c’è un problema di configurazione: verifica il percorso nel comando e che PHP sia accessibile dal cron di sistema.
wp cron event list.
Cron orfani e task duplicati: come identificarli e rimuoverli
I cron orfani si accumulano silenziosamente. Ogni plugin che installi e poi disinstalli può lasciare task pianificati in wp_options. Non causano errori visibili: eseguono una funzione che non esiste più, WordPress genera un errore interno che non vedi, e il ciclo si ripete.
Con WP Crontrol, il segnale più chiaro di un task orfano è il nome del hook: se non corrisponde a nessun plugin attualmente installato, è quasi certamente orfano. I task con nomi come action_scheduler_run_queue appartengono ad Action Scheduler (usato da WooCommerce e altri plugin) e sono normali. I task con nomi generici o numerici che non riconosci meritano verifica.
Per i task duplicati: controlla se lo stesso hook appare più di una volta con la stessa ricorrenza. Questo succede quando un plugin chiama wp_schedule_event() senza prima verificare con wp_next_scheduled() se l’evento esiste già — un bug comune in plugin mal scritti. Elimina tutti i duplicati e tieni solo un’istanza.
Frequenza consigliata: una volta al mese, nello stesso momento in cui fai la pulizia del database — sono due operazioni che si completano a vicenda. WP Crontrol non richiede più di 5 minuti per un’ispezione completa. Se preferisci non occuparti di questa manutenzione in prima persona, puoi affidarti a chi si occupa del prendersi cura del sito WordPress in modo sistematico.
In sintesi
WP-Cron non è un cron. Si attiva solo quando qualcuno visita il sito, e questo crea due problemi opposti: su siti a basso traffico i task ritardano o non partono; su siti ad alto traffico generano richieste parallele che appesantiscono il server. In entrambi i casi la soluzione è la stessa: disabilitare WP-Cron in wp-config(.)php e configurare un cron di sistema che chiami wp-cron.php ogni 15 minuti.
Per e-commerce WooCommerce il cron di sistema non è un’ottimizzazione opzionale. WooCommerce usa i task pianificati per email transazionali, sincronizzazione inventari, pulizia sessioni. Affidarsi a un meccanismo che gira solo quando c’è traffico su un sito con ordini notturni è una scelta che prima o poi si paga.
Sul fronte della diagnostica: WP Crontrol mostra in una schermata lo stato di tutti i task pianificati. Task con orario nel passato indicano che WP-Cron non gira. Task duplicati indicano un plugin mal scritto. Task con nomi non riconoscibili sono quasi sempre orfani da plugin disinstallati: vanno rimossi nell’ambito della manutenzione mensile.
La configurazione del cron di sistema richiede 10 minuti via cPanel. Il metodo più affidabile su VPS con SSH è WP-CLI. Il risultato è un sistema di task pianificati indipendente dal traffico, con carico sul server prevedibile e controllato.
Domande frequenti (FAQ)
Perché i miei post programmati non vengono pubblicati all'orario giusto?
Quasi certamente WP-Cron non viene chiamato all’orario in cui il post è programmato. Succede su siti con traffico basso o assente nelle ore notturne. Installa WP Crontrol (Strumenti → Cron Events) e verifica se il task wp_publish_future_post ha l’orario di prossima esecuzione nel passato. Se sì, il problema è confermato. La soluzione è configurare un cron di sistema come descritto in questo articolo.
Posso disabilitare WP-Cron senza configurare un cron di sistema?
Tecnicamente sì, ma non è consigliato. Disabilitando WP-Cron senza un’alternativa, tutti i task pianificati smettono di girare: niente aggiornamenti automatici, niente backup programmati, niente email da plugin. Se disabiliti WP-Cron, devi necessariamente configurare un cron di sistema che lo sostituisca entro pochi minuti.
Con quale frequenza far girare il cron di sistema?
Ogni 15 minuti è il valore standard per siti con task critici come e-commerce, form o notifiche. Per siti standard senza task urgenti, ogni 30 minuti è sufficiente. Non ha senso scendere sotto i 5 minuti: WordPress accumula i task in coda e li esegue tutti alla chiamata successiva.
Il plugin di cache interferisce con WP-Cron?
Può succedere. Alcuni plugin di cache intercettano le richieste HTTP a wp-cron.php e restituiscono una versione cached invece di eseguire il file PHP. Il risultato è che WP-Cron non viene mai realmente eseguito anche se risulta chiamato. Se usi un cron di sistema che chiama wp-cron.php direttamente via PHP o via WP-CLI (non via wget/curl), questo problema non si verifica: il PHP viene eseguito direttamente senza passare per il layer HTTP su cui agisce la cache.
Come faccio a sapere se il cron di sistema sta funzionando correttamente?
Vai in Strumenti → Cron Events (con il plugin WP Crontrol installato) e controlla che i task schedulati di sistema (wp_update_plugins, wp_update_themes, wp_scheduled_delete) si aggiornino regolarmente. Se un task ha sempre l’orario nel passato nonostante il cron di sistema attivo, controlla il log del cron nel pannello hosting. I problemi più comuni: percorso PHP sbagliato nel comando, permessi insufficienti, o errori nel file wp-cron.php stesso.
Se il cron genera problemi ricorrenti — post non pubblicati all’orario previsto, backup che saltano, email di WooCommerce non inviate, è uno dei casi coperti da una gestione WordPress professionale attiva.