RAG index
Reindicizza i contenuti modificati, genera chunk e embedding in batch paginati.
RAG 2.0
Async Job Queue
La coda che tiene il sito veloce mentre l'AI lavora
Indicizzazione RAG, audit delle immagini, scansioni, citazioni, IndexNow, llms-full e report: tutto passa da gop_jobs. Fuori dalla richiesta dell'utente, dentro un sistema che sa riprovare, riprendersi e fare pulizia.
15hook cron registrati
8tipi di job gestiti
0lavoro pesante nella richiesta admin
326test automatici superati
gop_jobs: il lavoro ha una casa, uno stato e un proprietario
La tabella della coda conserva ogni richiesta con il contesto necessario per eseguirla, riprenderla o annullarla. Non è un transient che scade: è una struttura persistente e interrogabile.
- Stati leggibili: pending, running, completed, failed
- Payload JSON con l'oggetto e i parametri del job
- Priorità per decidere cosa processare prima
- Lock owner e scadenza per evitare doppie esecuzioni
- Contatore dei tentativi e disponibilità temporale
- Timestamp di creazione, aggiornamento e completamento
Anatomia della coda
Campi di gop_jobs e ciclo di vita di un job
Ogni colonna risponde a una domanda operativa: cosa devo fare, per quale oggetto, con quale priorità, chi lo sta facendo e quando riprovare.
| Campo | Ruolo | Perché conta |
|---|---|---|
job_type | Il tipo di lavoro da eseguire. | Instrada il job al gestore corretto. |
payload | Dati JSON: ID contenuto, allegato, URL, parametri. | Rende il job eseguibile senza stato implicito. |
dedupe_key | Impronta di tipo, oggetto e versione del payload. | Impedisce accodamenti duplicati. |
status | pending, running, completed, failed. | Rende visibile il punto del ciclo di vita. |
attempts | Numero di tentativi effettuati e massimo previsto. | Governa retry e fallimento definitivo. |
priority | Ordine di processamento. | Fa passare prima i job urgenti. |
locked_by / locked_at | Worker che ha preso il job e momento del lock. | Abilita stale recovery e diagnosi. |
available_at | Quando il job può essere eseguito o ritentato. | Implementa backoff e pianificazione. |
1. Enqueue
L'admin, un hook o un job padre accoda una richiesta. La dedupe key viene calcolata subito: se esiste già un job equivalente attivo, non viene creato nulla.
2. Claim e lock
Un worker prende il job con una scrittura atomica, imposta lo stato running e registra il proprio lock con una scadenza.
3. Esecuzione
Il gestore del tipo di job esegue il lavoro in batch controllati. Le chiamate AI passano dalla reserve/release del budget.
4. Completamento o retry
In caso di successo il job passa a completed. In caso di errore viene riprogrammato con backoff, oppure marcato failed dopo il numero massimo di tentativi.
5. Recupero e pruning
Un lock scaduto riporta il job in pending. I job completati vengono eliminati secondo la retention; quelli falliti restano più a lungo per la diagnosi.
Tipi di job
Otto famiglie di lavoro, tutte asincrone
Ogni funzione pesante del plugin passa dalla coda. Nessuna di queste attività viene eseguita dentro il caricamento di una pagina admin o di una richiesta front-end.
Vision audit
Analizza le immagini, propone alt text, rileva decorative e calcola il quality score.
Vision 2.0Content gap
Aggiorna la tabella dei topic ed entità non coperti dal sito.
Content GapIssue scan
Scansiona i contenuti idonei e aggiorna il repository degli issue.
Issue CenterCitations
Verifica lo stato delle citazioni e delle fonti collegate alle pagine.
E-E-A-TIndexNow
Invia a IndexNow gli URL modificati, senza bloccare il salvataggio del contenuto.
Crawlerllms-full
Rigenera il file llms-full.txt con i riassunti e il limite totale configurato.
llms.txtReports
Genera report programmati, rollup giornalieri e dati per l'invio email.
Report
Affidabilità
Dedupe, lock, retry, stale recovery: le quattro regole
Una coda che non gestisce i fallimenti è solo un elenco di cose da fare. Queste quattro regole tengono il sistema prevedibile anche quando un worker muore.
Dedupe key
La chiave combina tipo di job, oggetto e versione del payload. Se la stessa operazione è già pending o running, la nuova richiesta viene assorbita. Quando il contenuto cambia, la versione cambia e il job può essere riaccodato.
Lock atomico
Il claim avviene con una singola operazione sul database. Due worker non possono ottenere lo stesso job, anche se partono nello stesso istante.
-- claim atomico di un job disponibile
UPDATE wp_gop_jobs
SET status = 'running', locked_by = 'worker-1', locked_at = NOW()
WHERE status = 'pending' AND available_at <= NOW()
ORDER BY priority DESC, id ASC
LIMIT 1;
UPDATE wp_gop_jobs
SET status = 'running', locked_by = 'worker-1', locked_at = NOW()
WHERE status = 'pending' AND available_at <= NOW()
ORDER BY priority DESC, id ASC
LIMIT 1;
Retry con backoff
Un errore non brucia subito il job. I tentativi sono multipli e distanziati nel tempo; esaurito il massimo, lo stato diventa failed e l'errore resta leggibile nell'admin.
Stale recovery
Se un worker si interrompe, il lock scade e il job torna disponibile. Il contatore dei tentativi sale, così un job che continua a rompere il worker non entra in loop infinito.
Nessun job invisibile. Ogni passaggio lascia stato, timestamp e motivo dell'errore. Il team vede cosa è successo senza dover leggere i log del server.
Cron hooks
I 15 hook che tengono in movimento il framework
Gli hook sono registrati dal plugin e rimossi alla disattivazione. Le frequenze sono pensate per distribuire il lavoro senza creare picchi.
| Hook | Cadenza | Cosa attiva |
|---|---|---|
gop_run_queue | Ogni 5 minuti | Processa il prossimo batch di job pending. |
gop_rag_reindex | Ogni ora | Accoda la reindicizzazione dei contenuti modificati. |
gop_vision_audit | Ogni ora | Avvia gli audit alt-text mancanti o da rivedere. |
gop_content_gap_scan | Giornaliero | Aggiorna la tabella dei content gap. |
gop_issue_scan | Giornaliero | Scansiona i contenuti idonei e aggiorna il repository issue. |
gop_citation_check | Giornaliero | Verifica lo stato delle citazioni e delle fonti. |
gop_indexnow_submit | Ogni ora | Invia gli URL modificati al servizio IndexNow. |
gop_llms_full_rebuild | Giornaliero | Rigenera llms-full.txt con i contenuti aggiornati. |
gop_report_daily | Giornaliero | Prepara report programmati e rollup dei dati. |
gop_visibility_sync | Due volte al giorno | Sincronizza GSC e GA4 con l'AI Visibility Hub. |
gop_tracker_cleanup | Giornaliero | Applica la retention ai dati del tracker. |
gop_ai_usage_rollup | Giornaliero | Aggrega il ledger gop_ai_usage per report e controllo costi. |
gop_schema_cache_prune | Giornaliero | Rimuove le cache schema scadute. |
gop_jobs_prune | Giornaliero | Elimina i job completati oltre la retention. |
gop_retention_cleanup | Settimanale | Pulisce log, prompt log opzionali e dati scaduti. |
Hook registrati, non lasciati al caso. Gli eventi vengono pianificati all'attivazione e rimossi alla disattivazione. Se la licenza non è valida, i moduli premium e i relativi job non partono: il comportamento è fail-closed.
WP-Cron va bene. Un worker è meglio.
WP-Cron non è un vero scheduler: parte con le visite al sito. Su un sito con poco traffico, o con cache molto aggressiva, i job possono accumulare ritardo. La coda funziona lo stesso, ma per la produzione conviene un innesco affidabile.
- Cron di sistema ogni minuto su
wp-cron.php - Oppure WP-CLI con esecuzione degli eventi dovuti
- Worker dedicato per batch più grandi
- Lock e dedupe proteggono anche con più worker
- Timeout e memoria controllati per ogni job
- Monitoraggio dei job failed dall'admin
# wp-config.php: disattiva il cron basato sul traffico
define('DISABLE_WP_CRON', true);
# crontab: esegue gli eventi dovuti ogni minuto
* * * * * cd /var/www/sito && wp cron event run --due-now >/dev/null 2>&1
# alternativa senza WP-CLI
* * * * * curl -s https://tuosito.it/wp-cron.php?doing_wp_cron >/dev/null 2>&1
define('DISABLE_WP_CRON', true);
# crontab: esegue gli eventi dovuti ogni minuto
* * * * * cd /var/www/sito && wp cron event run --due-now >/dev/null 2>&1
# alternativa senza WP-CLI
* * * * * curl -s https://tuosito.it/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Se il hosting blocca il cron o WP-CLI, la coda continua a funzionare con WP-Cron: perdi solo la garanzia di puntualità, non la persistenza dei job.
Manutenzione
Pruning, strumenti manuali e admin che resta leggero
La coda è un sistema vivo: va ispezionata, pulita e a volte fermata. Tutto è disponibile dall'admin, senza toccare il database a mano.
Prune dei job
I job completati vengono eliminati oltre la retention configurata. I falliti restano più a lungo, perché contengono l'informazione utile a capire cosa è andato storto.
Tool di manutenzioneControllo manuale
Avvia la coda, rilancia un job fallito, annulla quelli in attesa, metti in pausa il processamento o ispeziona il payload direttamente dal pannello.
StrumentiZero impatto
Le pagine admin accodano soltanto. Nessuna chiamata AI, scansione o generazione parte durante il caricamento di una schermata o il salvataggio di un post.
Costi sotto controlloCosa monitorare
- Numero di job pending, running e failed
- Età del job pending più vecchio
- Ultima esecuzione riuscita per tipo di job
- Tentativi e motivi di errore dei failed
- Dimensione della coda e crescita nel tempo
Quando intervenire
- Coda ferma: verifica cron, licenza e lock scaduti
- Molti failed: controlla chiavi API e budget
- Job vecchi: riduci i batch o aumenta la frequenza
- Database cresciuto: esegui il pruning dei completati
- Hosting lento: sposta il worker su cron di sistema
Il worker non è il sito. Un job lento non rallenta le pagine pubbliche. Se un batch è troppo pesante, viene spezzato e ripreso al giro successivo.
Domande frequenti
Automazione e coda, senza misteri
La coda funziona solo con WP-Cron?
No. WP-Cron avvia gli hook, ma la coda può essere processata anche da un cron di sistema o da un worker WP-CLI. Su siti con poco traffico il cron di sistema è la soluzione consigliata.
Cosa succede se un job resta bloccato?
Il lock ha una scadenza. Un job rimasto in esecuzione oltre il limite torna in stato pending, incrementa il contatore dei tentativi e può essere ripreso da un altro worker.
Come vengono evitati i job duplicati?
Ogni job ha una dedupe key che combina tipo, oggetto e versione del payload. Se la stessa richiesta è già in coda o in esecuzione, non viene accodata una seconda volta.
Quanti tentativi fa un job fallito?
I job prevedono tentativi multipli con backoff progressivo. Esaurito il numero massimo, lo stato diventa failed, l'errore resta visibile e il job può essere rilanciato manualmente dall'admin.
I job completati restano per sempre nel database?
No. Il pruning elimina i job completati secondo la retention configurata e conserva più a lungo i job falliti, utili per la diagnosi.
Posso gestire la coda manualmente?
Sì. Dai tool puoi avviare la coda, rilanciare un job fallito, annullare quelli in attesa, mettere in pausa il processamento, ispezionare il payload ed eseguire il pruning.
Torna ai prezzi
Lascia che il lavoro pesante aspetti il suo turno.
30 giorni di prova gratis, 14 giorni money back e tutte le funzioni Pro incluse. La Async Job Queue è nella licenza e muove tutte le automazioni del framework.