Blog SEO automatizzato: come funziona il sistema che ho costruito

Ho costruito un sistema che pubblica articoli SEO sul mio sito quasi da solo. Quasi, perché ho ancora bisogno di approvare ogni articolo prima che vada live. È una scelta, non una limitazione tecnica.

Questo articolo spiega come funziona, cosa lo rende diverso da un semplice wrapper a ChatGPT e perché l’ho reso disponibile anche per i clienti.

Il problema che stava cercando di risolvere

Un blog fermo non aiuta nessuno. Lo sappiamo tutti. Il problema è che scrivere un articolo SEO decente richiede 2–3 ore: ricerca del tema, angolo editoriale, scrittura, revisione. Per un professionista che già lavora a pieno ritmo, non succede mai con la frequenza giusta.

L’alternativa classica è esternalizzare a un copywriter. Funziona, ma ha due problemi: costa, e spesso il tono non è tuo. Dopo tre articoli si capisce che non li hai scritti tu.

L’obiettivo era diverso: un sistema che scriva come scrivo io, che parta da dati reali e che richieda al massimo 5 minuti a settimana di attenzione da parte mia.

Come è strutturato il sistema

Il flusso è in 5 fasi, tutte automatizzate tranne la review.

1. Research. Prima di scrivere, il sistema interroga un motore di ricerca reale (Brave Search) con query costruite attorno agli interessi del cliente e alla geo. Salva i risultati in un database. Non parte mai da zero: ogni articolo ha una base di dati reali su cosa sta cercando la gente.

2. Proposta topic. Un modello leggero analizza i risultati della ricerca e propone 1–2 temi, ciascuno con titolo e angolo editoriale breve (non l’articolo, solo la direzione). Arriva una notifica email. Il cliente approva o rifiuta con una nota in 30 secondi. Se rifiuta, la nota viene salvata nel profilo.

3. Scrittura. Solo dopo l’approvazione parte il modello principale (32B parametri, in locale) a scrivere il testo completo. Usa il profilo di voce del cliente e i risultati di ricerca come contesto. Non allucina referenze: ogni claim è supportato dai dati raccolti.

4. Review. L’articolo arriva nella dashboard con un editor markdown. Il cliente legge, modifica o approva. Ogni modifica viene registrata.

5. Deploy. Al click su approva, il file markdown viene committato su GitHub via API. Cloudflare Pages lo deploya in automatico. Nessun accesso manuale, nessun FTP, nessun CMS da aprire.

La parte che cambia tutto: il profilo di voce

Questa è la differenza tra contenuto generico e contenuto riconoscibile.

Prima di generare il primo articolo faccio una sessione di estrazione voce. Analizzo testi che il cliente ha già scritto (email, post precedenti, il copy del sito) e ne estraggo pattern: quanto sono lunghe le frasi in media? Usa la prima persona? Dà opinioni dirette o resta neutro? Usa gergo tecnico o parla in modo accessibile? Fa domande retoriche?

Tutto questo diventa parte del system prompt usato per ogni generazione. Il modello non scrive “in generale”: scrive cercando di replicare quei pattern.

Funziona meglio di quanto mi aspettassi per temi tecnici. Funziona meno bene per temi narrativi o molto creativi. Per articoli SEO di settore da 700–900 parole è sufficiente.

Il feedback loop: cosa succede quando correggi

Qui c’è la parte più interessante dal punto di vista tecnico.

Quando il cliente modifica una bozza, il sistema non aggiorna solo quell’articolo. Fa girare un job di analisi che confronta la versione originale con quella modificata e ne estrae pattern differenziali: hai accorciato sistematicamente le frasi lunghe? Hai rimosso aggettivi commerciali? Hai aggiunto riferimenti geografici che mancavano? Hai cambiato la conclusione da “call to action” a “takeaway pratico”?

Questi pattern si accumulano nel profilo del cliente. Non riscrivono il prompt di base, ma vengono aggiunti come esempi e vincoli aggiuntivi.

L’effetto pratico: dopo 5–10 articoli il gap tra prima bozza e versione finale si riduce. Non perché il modello “apprende” nel senso classico del machine learning (non aggiorno i pesi). Ma perché il contesto che guida la generazione diventa progressivamente più preciso.

Il topic pool e l’anti-repetizione

I temi non vengono generati al volo ogni volta. C’è un pool strutturato, costruito da un modello che analizza il profilo interessi del cliente (un testo libero che descrive il suo settore, i clienti tipo, le domande che gli fanno più spesso, la geo di riferimento).

Ogni topic nel pool ha: priorità, stagionalità, storico di utilizzo e stato. Il sistema non propone mai un tema già coperto finché il pool non si rigenera. Gestisce anche la stagionalità: un articolo sull’impianto di riscaldamento non viene proposto in luglio.

Quando il pool si esaurisce o invecchia, parte un job di espansione: il modello rianalizza gli interessi e genera nuovi topic candidati.

Privacy e infrastruttura

La generazione avviene su un modello open-weight che gira su hardware che controllo. I testi del cliente (dettagli su clienti, processi, prezzi) non escono mai dall’infrastruttura.

L’unica API esterna usata per il contenuto è Brave Search per la research. Per le notifiche si usa Resend (email). GitHub per il commit finale.

Se il modello locale non è disponibile, il sistema fa fallback automatico su Anthropic Claude e mi notifica solo me. Il cliente non vede la differenza.

Perché lo offro come servizio

Perché funziona sul mio sito da mesi e il tempo che mi richiede è effettivamente quello che dicevo: 5 minuti a settimana per approvare topic e leggere bozze.

Il vincolo principale è che i siti cliente devono essere su Astro + Cloudflare Pages + GitHub, lo stack che uso per tutti i siti che costruisco. Per chi è già su questo stack, il setup è zero.

Se ti interessa vederlo su un tema specifico del tuo settore, scrivimi.