02 - GEO Retrofit Benchmark: 741 errori strutturali a zero senza toccare la prosa esistente

La maggior parte dei consigli GEO che girano online è cosmetica: allungare la meta description, infilare due keyword in più nell'H1, aggiungere un badge "ottimizzato per l'AI". Niente di tutto questo ha spostato un solo errore strutturale sui miei 194 articoli bilingue. Quello che li ha azzerati è stato un motore meccanico e noioso, che inietta due blocchi fissi (risposta diretta, FAQ) senza mai riscrivere una parola della prosa già pubblicata.

Nota di metodo: questo articolo descrive lo stesso motore pubblicato come repository open source, con fixture sintetiche e 13 test di riproduzione automatizzati. I numeri di produzione citati qui (741, 386, 310) sono reali, misurati sul corpus effettivo del sito prima e dopo il retrofit, non un esempio illustrativo.

Perché la maggior parte dei consigli GEO è cosmetica

Le checklist GEO più diffuse parlano di lunghezza del title, densità di keyword, tag alt sulle immagini: dettagli reali, ma che un motore di ricerca o un modello linguistico non usano per decidere se un articolo risponde davvero a una domanda. Il gate strutturale che uso internamente (audit-geo.mjs) ignora tutto questo e misura solo quattro cose binarie: l'articolo apre con una risposta diretta o con un preambolo lungo, il blocco di risposta ha una lunghezza ragionevole, esiste almeno una fonte citata con link esterno, e ci sono tra 3 e 5 domande frequenti. Sono controlli strutturali, non estetici: o la forma c'è, o non c'è.

Il motore additivo: inietta, non riscrive

src/geo-retrofit.mjs prende un paragrafo di risposta e un set di coppie FAQ (in produzione, generati nativamente per lingua da un LLM on-prem (Ollama, fino al 2026-10-23; dal 2026-11-12 il sito usa un motore AI locale sul proprio server, con una coda di lavori), mai tradotti 1:1) e inietta due frammenti HTML a forma fissa: un blocco .geo-retrofit-lead anteposto come primo contenuto letterale, e un blocco .geo-retrofit-faq appeso come ultimo contenuto letterale. Tutto quello che sta in mezzo, la prosa già scritta e pubblicata, non viene mai toccato: nessuna riscrittura, nessuna cancellazione, nessuna riformattazione.

Trade-off dichiarato: additivo contro riscrittura completa

Avrei potuto ottenere un risultato "migliore" su carta con una riscrittura completa di ogni articolo: paragrafi ribilanciati nella finestra di 40-60 parole, citazioni aggiunte ovunque, struttura uniformata. L'ho scartato deliberatamente. Riscrivere 194 articoli già indicizzati, con backlink e posizionamenti esistenti, significa rischiare regressioni di ranking che nessun gate automatico intercetta prima del deploy. L'approccio additivo ha un costo esplicito, un tetto di qualità più basso di quello che una riscrittura potrebbe raggiungere, ma limita il rischio a "aggiungo due blocchi ai margini" invece di "riscrivo tutto e spero che Google non se ne accorga".

Due guardie di idempotenza, non una

Il motore usa due controlli indipendenti per non ripetersi. Il primo è un attributo marker (data-geo-retrofit) che salta l'iniezione se già presente. Il secondo è più interessante: needsLead() e needsFaq() riusano le stesse funzioni checkAnswerFirst() e countFaqPairs() del gate di rilevazione, quindi un articolo che soddisfa già i criteri per conto proprio, senza alcun marker, viene lasciato intatto lo stesso. L'autocontrollo del motore e il gate di accettazione concordano per costruzione: sono letteralmente la stessa funzione, mai riderivata.

Perché il bilingue raddoppia la superficie

194 articoli per due lingue fanno 388 documenti HTML da controllare col gate, non 194. Ogni lingua genera la propria risposta diretta e la propria FAQ in modo nativo, mai tradotta 1:1 dall'altra: un modello che traduce meccanicamente produce prosa riconoscibile come tradotta, con un effetto negativo sull'esperienza di lettura e, indirettamente, sul segnale editoriale percepito. Il costo è un secondo controllo dedicato, assertParity(), che verifica che il conteggio di coppie FAQ combaci tra la versione IT e quella EN dello stesso articolo, in modo che una lingua non finisca fuori range mentre l'altra resta conforme.

I limiti onesti: il motore non chiude tutto da solo

I 310 errori di citazione mancante non sono stati chiusi da questo motore, e non potevano esserlo per costruzione: la regola di integrità è che il retrofit non inventa mai una fonte. test/reproduce.test.mjs lo verifica direttamente, contando i link href="https://..." prima e dopo l'esecuzione e pretendendo che il numero resti identico. Chiudere i 310 errori residui ha richiesto una passata manuale separata, articolo per articolo, con una fonte esterna verificata aggiunta a mano: più lenta, ma l'unica compatibile con la regola "nessuna fonte inventata".

A chi serve questo approccio

Se hai un corpus di contenuti già pubblicato e indicizzato che deve rispettare un nuovo standard strutturale (GEO, accessibilità, schema.org), il consiglio pratico è: preferisci un motore additivo e idempotente a una riscrittura, misura il gate prima e dopo con lo stesso identico script (non uno "equivalente"), e non delegare mai a un motore automatico la creazione di una fonte o di un dato che non hai verificato tu stesso.

Nella serie «Original Research», precedente: 01 - Sport Intelligence Benchmark; successivo: 03 - Quattro Postmortem di Produzione.