Sto sperimentando i workflow SEO agentici da sei mesi. Alcuni funzionano. La maggior parte no. Ecco cosa ho scoperto.
La promessa della SEO agentica è seducente: agenti AI autonomi che monitorano le tue posizioni in SERP, rilevano quando un contenuto inizia a perdere terreno, lo riscrivono con prompt contestuali, eseguono controlli QA e pubblicano l’aggiornamento — tutto senza intervento umano. Un motore di contenuti che si aggiorna da solo. La fine del classico “chi si occupa del refresh delle pagine questo trimestre?”.
La realtà è più disordinata. Ho costruito tre versioni di questa pipeline in SEOJuice, e ognuna mi ha insegnato che la distanza tra “agente autonomo” e “agente autonomo che non rompe nulla” è enorme. Però la terza versione funziona, entro i limiti che descriverò con onestà. E il risparmio di tempo, per le parti che davvero funzionano, è abbastanza rilevante da farmi pensare che qualsiasi team serio che lavora sui contenuti dovrebbe iniziare a sperimentare in questa direzione.
Nel mondo degli LLM, un agente autonomo è un loop che si autodirige: percepisce (legge dati), decide (ragiona rispetto a un obiettivo) e agisce (chiama API) senza che intervenga una persona. La SEO agentica applica questo schema alla manutenzione dei contenuti: un sistema monitora in modo continuo i movimenti in SERP, decide quali pagine hanno bisogno di aiuto, le aggiorna, esegue controlli di qualità e pubblica la modifica.
Questo è il concetto. Ora ti racconto com’è nella pratica, rispetto a quello che promettono i materiali di marketing.
Quello che dicono i blog post: “L’agente rileva un calo di posizioni, riscrive il contenuto in pochi minuti e ti fa recuperare terreno prima ancora del caffè del mattino.”
Quello che succede davvero, versione uno: L’agente rileva un calo di posizioni, riscrive il contenuto in un modo che cancella la voce del brand, introduce due errori fattuali, cambia il significato di un paragrafo tecnico e crea una pull request che il tuo editor deve sistemare in 45 minuti — più tempo di quanto avrebbe richiesto una riscrittura manuale.
Quello che succede davvero, versione tre (dopo sei mesi di iterazioni): L’agente rileva un calo di posizioni, recupera contesto da un database vettoriale del tuo contenuto esistente, prepara un’espansione mirata della sezione più debole, la sottopone a verifica fattuale contro il tuo database di fonti e crea una PR con un diff chiaro che mostra esattamente cosa è cambiato e perché. Il tuo editor la rivede in 10 minuti. L’aggiornamento va online lo stesso giorno.
La differenza tra la versione uno e la versione tre non è il modello AI. Sono i vincoli di sicurezza.
Descriverò l’architettura su cui ci siamo assestati, non come raccomandazione universale ma come punto di riferimento. Il tuo stack sarà diverso in base al CMS, al volume dei contenuti e alla tua tolleranza verso i sistemi autonomi.
LangChain è la base. LangChain trasforma i large language model in sistemi che agiscono collegandoli a strumenti — API SERP, endpoint del CMS, GitHub, il tuo database interno con la style guide. Una chain di agenti tipica nel nostro sistema:
CrewAI per coordinare processi multi-step. CrewAI entra in gioco sopra LangChain quando hai bisogno di più agenti che lavorano in sequenza. Noi configuriamo un Monitoring Agent che osserva solo le posizioni, un Rewrite Agent che prepara la bozza e un QA Agent che rifiuta tutto ciò che non supera i controlli di leggibilità o conformità. CrewAI orchestra i passaggi: scrape, riassunto, bozza, commit — assicurandosi che nessun passaggio venga eseguito fuori sequenza.
Una nota su CrewAI nello specifico: non è l’unico livello di orchestrazione che funziona in questo scenario. Anche AutoGen e workflow custom con Celery possono ottenere risultati simili. Noi abbiamo scelto CrewAI perché la sua astrazione basata sui ruoli degli agenti si allinea bene al nostro workflow editoriale. Se hai già un’infrastruttura Celery (noi sì, in SEOJuice), costruire l’orchestrazione lì è altrettanto sensato.
Database vettoriali per la memoria istituzionale. Questo è il pezzo che ci ha portati dalla versione uno alla versione tre. Senza un database vettoriale, il Rewrite Agent allucina. Con un database vettoriale, recupera rappresentazioni vettoriali a livello di frase dai tuoi articoli esistenti, le usa come contesto di riferimento e le cita nel prompt di riscrittura. Noi usiamo PGVector (nativo Postgres, visto che siamo già su Postgres), ma anche Pinecone e Weaviate funzionano bene.
Un agente che riscrive a caso è un rischio. L’abbiamo imparato nel modo peggiore quando la nostra prima versione ha attivato una riscrittura su una pagina che aveva perso tre posizioni per una fluttuazione temporanea della SERP, non per un vero problema di qualità. La riscrittura ha peggiorato la pagina.
Ecco lo schema decisionale che abbiamo definito dopo molti tentativi andati male:
Soglia di attivazione: Una keyword tracciata perde più di tre posizioni in una finestra di 48 ore. Abbiamo testato soglie più basse (2 posizioni) e abbiamo visto troppi falsi positivi dovuti alla normale volatilità della SERP.
Validazione dell’intento: Prima di attivare una riscrittura, un agente di classificazione dell’intento analizza gli snippet attuali della top-5 in SERP. Se la SERP è passata da contenuti informativi a contenuti comparativi, allora la riscrittura è giustificata. Se la composizione della SERP non è cambiata, di solito basta un intervento più leggero — aggiungere una sezione FAQ o ampliare una sezione troppo scarna.
Controllo della voce del brand: Il QA Agent verifica che la bozza mantenga il tono corretto e non introduca affermazioni legalmente problematiche. È qui che la maggior parte delle pipeline “autonome” si rompe. Senza questo passaggio, l’agente scrive contenuti generici, con un tono autorevole ma intercambiabile, che potrebbero appartenere a qualsiasi brand.
Una volta che il motore decisionale dà il via libera, il Rewrite Agent esegue un template di prompt che incorpora tutte le best practice on-page:
You are an SEO copy-editor for {{Brand}}. Goal: regain rank for "{{Target Keyword}}". Constraints: - Keep H1 unchanged. - Insert primary keyword in first 100 words. - Add at least two internal links to {{Related URLs}}. - Follow brand tone guide: concise, confident, no jargon. Provide Markdown output only.
L’agente recupera dal database vettoriale i cinque paragrafi semanticamente più correlati come contesto di riferimento. Estrae gli H2 delle prime cinque pagine concorrenti per valutarne il livello di approfondimento. La bozza del modello passa poi attraverso la Grammarly API per lo stile e un controllo SEO custom che verifica lunghezza del meta title, presenza dell’alt text, numero di link interni e validità dello schema.
Qualsiasi errore rimanda la bozza all’LLM con commenti inline per l’auto-correzione — di solito uno o due passaggi. Poi il GitHubCommitTool apre una PR con una nota nel changelog: "Auto-rewrite triggered by rank-drop: 'best headless CMS' from #5 to #9."
Risultato: un refresh dei contenuti completamente documentato, guidato da policy e pronto per la produzione in meno di venti minuti, quando funziona. Sottolineo “quando funziona” perché circa il 15% delle riscritture attivate viene ancora rifiutato dal nostro QA Agent e inviato a revisione umana. Questo tasso di rifiuto sta scendendo, ma non è arrivato a zero, e non credo che ci arriverà.
Questa è la sezione più importante, e quella che viene saltata nella maggior parte degli articoli sulla SEO agentica. I vincoli di sicurezza non sono la parte noiosa. Sono la parte che decide se la tua pipeline è utile o pericolosa.
Limite di iterazione: Ogni URL può attivare al massimo una riscrittura ogni sette giorni, e nel repository non possono esistere più di tre versioni contemporaneamente. Se il Monitoring Agent rileva ancora un calo dopo tre passaggi, il task viene escalato a un editor umano. Questo elimina il problema del loop infinito in cui una pagina rimbalza tra posizione 7 e 9, riscrivendosi fino a perdere completamente senso.
Integrità fattuale: Ogni bozza passa attraverso un agente di verifica fattuale che confronta entità nominate, statistiche e affermazioni con una lista di fonti affidabili. Se il confidence score scende sotto il 98% — cioè più di un fatto non supportato ogni mille parole — la bozza viene messa in quarantena per revisione manuale. Nessun merge avviene senza approvazione umana.
Pagine protette: Tutto ciò che genera più del 5% del fatturato mensile, qualsiasi contenuto legale o di conformità e qualsiasi contenuto medico o finanziario viene etichettato come protetto. L’agente può preparare aggiornamenti, ma può aprire PR solo in modalità review-only. Se nessun umano risponde entro 48 ore, il sistema esegue un rollback e invia un alert su Slack.
Voglio essere diretto su una cosa: anche con tutti questi vincoli di sicurezza, rivedo ogni PR auto-generata prima del merge sul nostro sito. Il sistema è abbastanza valido da gestire in autonomia l’85% degli aggiornamenti sui siti dei clienti, dove la tolleranza al rischio è più alta. Per i nostri contenuti — dove un errore fattuale o una stonatura nella voce del brand sarebbe imbarazzante in modo molto diretto — guardo ancora ogni diff. Magari tra altri sei mesi cambierà. Per ora no.
Per onestà, ecco cosa ho provato e poi abbandonato o messo in pausa:
Google non penalizza l’automazione; penalizza output di bassa qualità o spam. Se la tua pipeline include un QA che impone leggibilità, integrità fattuale e tono del brand, gli aggiornamenti sono indistinguibili dal lavoro di un editor umano. Noi eseguiamo aggiornamenti agentici sul nostro sito da sei mesi senza segnali negativi sulle posizioni.
La chiave è la retrieval-augmented generation. L’agente deve recuperare contesto di riferimento da un database vettoriale dei tuoi contenuti verificati e citare fonti per qualsiasi statistica o affermazione. Sopra questo livello, aggiungi un agente di verifica fattuale che confronti la bozza con una lista di fonti affidabili. Imposta una soglia di confidenza e metti in quarantena tutto ciò che sta sotto.
Imposta un limite rigido di frequenza (un aggiornamento per URL a settimana) e un massimo di tre versioni salvate. I diff più vecchi vengono compressi o rimossi. Questo evita sia la crescita eccessiva del repository sia il continuo rimaneggiamento del contenuto.
Sì, anche se gli headless CMS rendono il loop Git-commit più pulito. Su WordPress, il Deployment Agent invia gli aggiornamenti tramite REST API o WP-CLI invece di una Git PR. Assicurati che la cache lato server venga svuotata dopo ogni pubblicazione, così i crawler recuperano l’HTML aggiornato.
Monitora tre cose: velocità di recupero delle posizioni (tempo tra il calo e il recupero), totale delle ore di editing manuale risparmiate e retention netta del fatturato sulle pagine gestite dagli agenti rispetto a un gruppo di controllo. Nel nostro caso, i recuperi avvengono il 40% più velocemente e il tempo dedicato ai contenuti di routine si è dimezzato rispetto al workflow pre-agentico.
no credit card required
