Aggiorni il campo lastmod nella sitemap ogni volta che pubblichi qualcosa, anche se il contenuto non è cambiato? I sistemi RAG rilevano questo comportamento — e lo interpretano come un segnale di bassa affidabilità, non come freschezza. La logica si rovescia: aggiornare lastmod senza modifiche reali ti penalizza rispetto a chi aggiorna meno spesso ma con contenuto davvero revisionato. Non è un problema tecnico, è un problema di metodo. Bastano revisioni semestrali strutturate con dati aggiornati e il setup corretto di dateModified in schema. Ti spiego come segnalare la freschezza in modo che i crawler AI si fidino e scelgano il tuo contenuto.
Hai implementato HTTPS, il tuo sito si carica in meno di due secondi, i bot AI possono crawlarlo senza ostacoli e l’HTML e semanticamente corretto. Eppure il tuo contenuto continua a non comparire nelle risposte. Il pezzo che manca potrebbe non essere nel contenuto stesso, ma in un metadato che non hai mai toccato: la data.
Non parlo della data di pubblicazione che il lettore vede in fondo all’articolo. Parlo di tre segnali tecnici specifici che i sistemi RAG leggono prima ancora di valutare una singola parola di quello che hai scritto: il campo `dateModified` nello schema markup, il valore `lastmod` nella sitemap XML e il campo `datePublished` nello structured data. Sono metadati invisibili al lettore umano, ma perfettamente visibili alla macchina. E la macchina li usa per decidere se vale la pena passare il tuo contenuto al modello — o se e meglio prendere quello del competitor che ha una data più recente.
Versioni multiple, lo stesso contenuto: il problema che l’AI deve risolvere
Per capire perché questi metadati contano così tanto, serve partire da un problema reale che i modelli linguistici affrontano ogni giorno. Lazaridou et al. nel 2024 lo descrivono in modo preciso:
“Even more difficult are cases where there exist multiple versions of a resource, and the model may have been exposed to different versions at different times.” — Lazaridou et al., 2024
Fermati un secondo su questo punto. Il modello ha visto versioni diverse della stessa risorsa in momenti diversi. La tua pagina “servizi” di tre anni fa e la versione aggiornata sei mesi fa coesistono nello spazio informativo del sistema — e il sistema deve decidere quale e quella corretta. Come fa? Usa i segnali temporali. E se quei segnali mancano o sono incoerenti, il sistema non ha strumenti per distinguere la versione attuale da quella obsoleta.
Ho già approfondito il concetto di recency come fattore di retrieval nell’articolo sulla content recency. Qui il tema e diverso: non parliamo del principio, ma dei segnali tecnici specifici che devi implementare perché il sistema sappia leggere la freschezza del tuo contenuto.
Come il sistema RAG pesa i timestamp
I sistemi RAG non recuperano contenuti alla cieca. Ogni chunk che entra nella pipeline di retrieval porta con se dei metadati — e il timestamp e uno dei più influenti. Gao et al. nel 2024 formalizzano questo meccanismo:
“Assigning different weights to document timestamps during retrieval can achieve a balance between information relevance and timeliness.” — Gao et al., 2024
Un equilibrio tra rilevanza e tempestivita. Non e che il sistema scarta automaticamente tutto cio che non e di ieri. Ma quando due contenuti competono per lo stesso slot nella risposta — stessa pertinenza, stessa qualità percepita — il timestamp più recente vince. E quel timestamp non viene estratto dal testo visibile della pagina. Viene letto dai metadati strutturati.
Questo significa una cosa molto concreta: se il tuo contenuto non dichiara quando e stato aggiornato l’ultima volta in un formato che la macchina sa interpretare, stai rinunciando a un vantaggio competitivo che potresti avere gratis.
I tre segnali che devi controllare
Non tutti i segnali temporali hanno lo stesso peso, e non tutti vengono letti nello stesso momento del processo.
datePublished e dateModified nello schema Article. Quando implementi il markup schema.org sulla tua pagina (e dovresti farlo su ogni contenuto strategico), i campi `datePublished` e `dateModified` comunicano al sistema due informazioni distinte: quando il contenuto e nato e quando e stato toccato l’ultima volta. Il `dateModified` e il campo che pesa di più per la freschezza, perché dice al sistema RAG che qualcuno ha revisionato quel contenuto dopo la pubblicazione iniziale. Un articolo pubblicato nel 2022 con `dateModified` al 2026 comunica: questo contenuto e ancora mantenuto attivamente.
lastmod nella sitemap XML. La sitemap e il primo punto di contatto tra il crawler e il tuo sito. Il campo `lastmod` su ogni URL dice al bot: “questa pagina e cambiata in questa data”. I crawler AI — GPTBot, PerplexityBot, ClaudeBot — usano questo dato per decidere la priorità di crawling. Se il tuo `lastmod` non e mai stato aggiornato dalla prima pubblicazione, il bot potrebbe decidere che non vale la pena tornare a visitare quella pagina. E se non la visita, non la indicizza nella versione aggiornata.
L’header HTTP Last-Modified. Questo e il segnale più tecnico dei tre, gestito a livello server. Quando un crawler chiede una pagina, il server può rispondere con un header `Last-Modified` che indica l’ultima modifica del file. E un segnale di basso livello ma importante, perché agisce prima ancora che il contenuto venga parsato.
Questi tre segnali lavorano insieme. Se sono allineati — la sitemap dice che la pagina e stata aggiornata il 15 marzo, lo schema conferma un `dateModified` al 15 marzo, e l’header HTTP concorda — il sistema ha un segnale forte e coerente di freschezza. Se sono in contraddizione, il segnale si indebolisce. Ho parlato dell’importanza dell’allineamento dei segnali tecnici negli articoli su HTTPS e markup semantico: la coerenza tra i layer tecnici e un pattern che ritorna.
L’errore che rovina tutto: aggiornare la data senza aggiornare il contenuto
Arrivati qui, la tentazione e ovvia. Aggiorno il `dateModified` e il `lastmod` ogni settimana senza toccare il testo, e il sistema mi vede sempre fresco. No.
I sistemi evoluti di retrieval non si fermano al timestamp. Confrontano le versioni. Se il delta tra la versione precedente e quella “aggiornata” e zero — stesse parole, stessa struttura, stessi dati — il segnale di freschezza perde credibilità. Non e documentato in un singolo paper come una regola codificata, ma e una deduzione logica dal modo in cui funziona il versioning nei sistemi RAG: se il sistema tiene traccia delle versioni (e Lazaridou et al. confermano che lo fa), una versione identica con data diversa non e un aggiornamento. E rumore.
Il principio e semplice: aggiorna il contenuto prima, poi aggiorna i metadati. Nuovi dati, fonti più recenti, sezioni ampliate o riscritte, informazioni obsolete rimosse — questo e un aggiornamento. Cambiare la data e basta e l’equivalente digitale di girare il contachilometri.
Il legame con il knowledge cutoff
C’e un livello in più che riguarda il training, non solo il retrieval. Ne ho parlato nell’articolo sul knowledge cutoff: ogni modello ha una data oltre la quale non conosce nulla per via diretta. Ma anche dentro quella finestra temporale, il modello ha assorbito versioni diverse delle stesse pagine in momenti diversi del training.
Da questo segue — e ci tengo a segnalarlo come deduzione — che i segnali di freshness agiscono su due fronti. Nel retrieval RAG in tempo reale, influenzano il ranking dei contenuti recuperati. Nel training, determinano quale versione del tuo contenuto il modello ha interiorizzato. Se non aggiorni da anni, la versione nel training e quella vecchia. E ogni nuovo ciclo di addestramento che include contenuti più freschi dei competitor sullo stesso tema spinge la tua versione più in basso nello spazio vettoriale del modello.
Da dove partire
Questa e la parte operativa. Non servono strumenti complessi per fare un primo check:
- Verifica lo schema markup delle tue pagine chiave. Apri il Rich Results Test di Google, incolla l’URL e controlla se `datePublished` e `dateModified` sono presenti nello structured data. Se mancano, vanno aggiunti.
- Controlla la sitemap XML. Apri `tuosito.it/sitemap.xml` e verifica che ogni URL strategico abbia un campo `lastmod` con una data coerente con l’ultimo aggiornamento reale. Se tutte le pagine hanno la stessa data o nessuna data, il segnale e assente.
- Allinea i tre layer. Schema markup, sitemap e header HTTP devono raccontare la stessa storia. Un `dateModified` al 2026 con un `lastmod` fermo al 2023 e una contraddizione che indebolisce entrambi i segnali.
Questo ti da una fotografia iniziale. Per un’analisi completa serve incrociare i segnali di freshness con la crawlability effettiva del sito, la page experience e la qualità dei contenuti sottostanti — perché una data recente su un contenuto mediocre non fa miracoli.
La credibilità tecnica si costruisce a strati
Questo e l’ultimo tassello del blocco di approfondimenti che ho scritto sulla credibilità tecnica del tuo sito: dal protocollo HTTPS che ti fa entrare nel sistema, alla velocità che ti impedisce di essere scartato, alla crawlability che ti rende raggiungibile, al markup semantico che ti rende comprensibile, fino ai segnali di freschezza che ti rendono attuale.
Nessuno di questi segnali funziona da solo. Un sito veloce con HTTPS e markup perfetto ma con contenuti datati perde terreno. Un sito con contenuti freschi ma non crawlabile dai bot AI non esiste. La credibilità tecnica e il risultato della somma di tutti questi layer — e ognuno deve essere in ordine perché il successivo funzioni.
