Secondo la recente guida pubblicata da Google, il primo modo in cui gli agenti AI "vedono", è uno screenshot della pagina effettuato dopo il rendering. Questa sola affermazione basterebbe a mettere in crisi tutte le teorie secondo cui agli agenti AI non sarebbero in grado di interpretare una pagina HTML, a causa del rumore generato dagli elementi in essa presenti.
La guida di Google, oltre a fugare ogni dubbio a riguardo, implicitamente sottolinea l'importanza della SEO tecnica per garantire, attraverso l'ottimizzazione delle prestazioni del caricamento della pagina, il rendering completo della stessa, al fine di scongiurare una visualizzazione parziale o peggio ancora una pagina “bianca”, come spesso capita in presenza di pagine particolarmente lente e pesanti.
Inutile dire che non stiamo parlando di tecniche innovative, e meno ancora di esigenze specifiche per accontentare gli agenti AI, qui si tratta di interventi “basici” come conversione delle immagini in formati moderni quali WebP o AVIF, di riduzione, minimizzazione e concatenamento di risorse css e .js, gestione della cache e tutti quegli interventi che sono sempre stati necessari per la realizzazione di un progetto web di qualità. Fin qui, Nihil sub sole novum e di certo nulla che giustifichi un rebranding del termine SEO.
Il secondo modo attraverso il quale l'agente visualizza la pagina è attraverso l'analisi del DOM e la conseguente lettura dell'HTML. Anche in questo caso, come già scritto poc'anzi, Google ci conferma che gli agenti AI non hanno alcun problema a leggere e interpretare una “classica” pagina HTML, quindi se proprio volessimo fare una considerazione tecnica a riguardo, dovremmo forse chiederci, quanta attenzione viene posta oggi (da anni in realtà) alla struttura del codice HTML delle pagine ?
A fronte dell'estrema semplicità nel realizzare “siti web” con alcuni CMS, spesso con il supporto di plugin e page builder, basta prendersi la briga di guardare il codice sorgente delle pagine generate per notare una quantità sproporzionata di codice, rispetto alle reali esigenze, con una disposizione frammentata e confusionaria degli elementi che complica, quando non inibisce del tutto, la comprensione semantica della pagina. Qualche volta, cosa tutt'altro che rara, il codice presenta errori formali grossolani.
Anche in questo caso quindi, piuttosto che rincorrere nuovi formati da dare in pasto agli agenti AI, sarebbe forse opportuno ritornare alle basi dell'ottimizzazione e porre una maggiore attenzione alla pulizia del codice e al corretto uso dei tag semantici...per iniziare.
Il terzo modo attraverso il quale gli agenti AI visualizzano il sito è l'albero di accessibilità, un'API nativa dei browser. A differenza dello screenshot e dell'analisi del DOM, l'albero di accessibilità restituisce all'agente una rappresentazione già interpretata della pagina, con ruoli, stati e relazioni tra elementi, ed è quindi il layer che più direttamente espone eventuali carenze semantiche di implementazione. Un "role" applicato all'elemento sbagliato, un "aria-label" generico o assente, un "aria-hidden" usato per nascondere contenuti che invece sono rilevanti, errori purtroppo abbastanza frequenti, soprattutto nelle implementazioni basate su page builder, producono tanto sugli screen reader che per la visualizzazione degli agenti AI una rappresentazione distorta o incompleta del contenuto, giacché un agente AI che si affida all'albero di accessibilità "vede" la pagina esattamente come la vedrebbe un utente che fa uso di tecnologie assistive.
Anche in questo caso è fondamentale ricordare che i principi fondamentali dell'accessibilità proposti dal W3C e formalizzati nel WCAG 2.1 sono intrinsecamente legati alle fondamenta della SEO. Rendere un sito accessibile non vuol dire stravolgerne la natura o la modalità di fruizione, tutt'altro, vuol dire garantirne la corretta fruizione a tutti, eliminando quelle barriere tecnologiche che possono rappresentare frizioni, o peggio ancora limitazioni, tanto per utenti umani quanto per tecnologie assistive e bot. È forse opportuno ricordare che dal luglio 2025, per alcune tipologie di siti web, anche in Italia l'accessibilità è divenuta un obbligo normativo: chi ha affrontato seriamente la conformità alle WCAG si trova oggi, quasi per inerzia, ad avere un sito strutturalmente più leggibile anche dagli agenti AI, senza aver fatto nulla di specifico per loro. Un'ulteriore conferma che non esistono ottimizzazioni ad hoc, ma solo buone pratiche che si rivelano tali in contesti diversi.
Google inoltre ci avvisa che non è possibile affidarsi ad un unico metodo a discapito degli altri, senza che questo abbia una ripercussione negativa sull'interpretazione della pagina. Compito di chi sviluppa i siti web (o meglio di chi vuole seguire queste indicazioni) sarà creare i presupposti per garantire agli agenti AI che ognuno dei tre metodi proceda senza alcun intoppo.
Qui finisce quello che ci racconta Google e può iniziare qualche divagazione personale.
Nel mondo della SEO, il dibattito su quali siano gli strumenti per semplificare la vita agli agenti AI e trarne un conseguente vantaggio ha prodotto una quantità di letteratura a cui si fa sinceramente fatica a stare dietro.
Per fortuna, a fronte delle innumerevoli strategie innovative, i mirabolanti prompt dai risultati immediati e tool che sponsorizzano l' integrazione della feature definitiva per essere i “primi sull'AI”, esistono alcuni topics che più di altri stanno catalizzando l'attenzione, o forse sarebbe meglio dire la comunicazione.
Parto dal primo, e lo dirò senza giri di parole: con buona pace di quelli che sostengono l'esatto contrario, per me il file LLMS.TXT non serve a nulla. Voglio però rendere chiare le motivazioni, molteplici, per cui non ho alcun dubbio a riguardo.
Pur apprezzando lo sforzo di giungere ad uno standard condiviso, e quindi riconoscendo l'impegno di Jeremy Howard nel definire caratteristiche e modalità d'uso dell'llms.txt, la sua diffusione allo stato attuale è priva di qualsiasi fondamento. Ed è, in un certo senso, persino in contrasto con la proposta iniziale dello stesso Howard che, proponendo la definizione di un protocollo, ha dimostrato di essere ben consapevole che, senza di esso, il file llms.txt non ha alcun senso di esistere.
Il tentativo di rimanere nel solco tracciato dal robots.txt sembra funzionale in termini di "marketing comunicativo", infatti se ne parla tanto, ma mostra i suoi limiti tecnici nel momento in cui si propone di affrontare esigenze nuove, costretto da un formato, il .txt, che non è nato per soddisfarle. Il cortocircuito più evidente lo si vede nelle implementazioni concrete. In alcuni casi si arriva ad applicare la sintassi Markdown a un file plain text, nella speranza di dargli una struttura semantica che per definizione non può avere. Definire per un .txt un Mime Type text/markdown, anche se via header HTTP, più che una soluzione innovativa mi sembra un modo per avvelenare il pozzo di qualsiasi futura implementazione seria.
Scartata quindi l'ipotesi del .txt, la soluzione naturale sembrerebbe essere il formato .md. Anche qui però è necessario fermarsi a ragionare, e lo faccio partendo da quello che ho fatto io stesso. Chi avrà voglia di guardare il codice sorgente di questa pagina troverà che la risorsa in formato .md viene comunicata attraverso un link rel="alternate" con Mime Type "text/markdown", servita con un header x-robots-tag: noindex per evitare problemi di contenuto duplicato. Un test, appunto, non una raccomandazione.
Il punto critico è questo: per quanto il formato .md possa in teoria semplificare i processi di parsing e embedding, l'agente AI dovrà comunque prima caricare la pagina HTML per trovare il link che punta alla risorsa .md. Il risultato è un consumo di token maggiore, non minore. L'unico vantaggio ipotetico, una migliore qualità del dato estratto, è tutto da dimostrare. Il costo aggiuntivo in termini token, invece, è l'unico dato certo. Realisticamente, fino a quando non esisterà una convenzione "Markdown-First", un protocollo diffuso per cui gli agenti siano addestrati a richiedere direttamente [url].md prima ancora di caricare l'HTML, fornire risorse in formato .md resta una scommessa su uno scenario futuribile, nulla a cui si possa attribuire oggi il benché minimo beneficio concreto.
In un post su Bluesky, successivamente ripreso da Search Engine Journal, John Mueller ha sostanzialmente definito, il servire file Markdown appositamente per i crawler AI, una "idea stupida". Nell'articolo su SEJ vengono riportate altre sue dichiarazioni che contestualizzano la sua presa di posizione, basti pensare, ad esempio, che gli LLM sono stati addestrati su enormi volumi di pagine HTML, ma anche perché nel distillare il contenuto delle pagine si finisce per perderne il contesto (ad esempio la possibilità di approfondire l'argomento attraverso una struttura di navigazione interna).
Qualora il risparmio di token fosse così importante, per quale ragione aziende come Google, OpenAI o Anthropic non avrebbero dovuto apertamente sostenere questo tipo di soluzione ?
Nel prendere atto che John Mueller l'ha chiaramente definita una inutile perdita di tempo, anziché adottare il più generico e consueto “It depends”, non posso non ricordare una chiacchierata con lo stesso John e Martin Splitt che ha preceduto l'intervista per la trasmissione radiofonica di Patrick Domanico, tenutasi durante il Product Expert Summit di Google a Zurigo nel 2024, in cui entrambi sottolineavano l'impegno di Google per mantenere la complessità tecnologica dei fattori qualitativi richiesti a un sito web ad un livello accettabile, per non “tagliare fuori” i siti web di piccole attività commerciali che non hanno risorse sufficienti per consentirsi un sito web con caratteristiche tecniche eccellenti. Negare loro un presenza online, imponendo standard a cui realisticamente non possono arrivare, implicherebbe anche impedire ai potenziali utenti/clienti di conoscere e fruire del loro prodotto, anche quando eccellente (Martin faceva l'esempio di una bakery a Zurigo che sfornava dei tortini fantastici).
É possibile che oggi per Google questo tipo di considerazioni, quindi non solo le “esigenze” degli agenti AI, rappresentino un elemento imprescindibile nel definire gli scenari del prossimo futuro ?
Francamente non ho risposte certe a riguardo, tra l'altro continuo anche a chiedermi se i tortini di cui parlava Martin fossero poi veramente così buoni ...
In buona sintesi, ciò che si può serenamente affermare senza timore di essere smentiti, è che realizzare siti ottimizzati per gli agenti AI, non vuol dire altro che realizzare siti web ottimizzati per garantire la migliore esperienza utente possibile.
La sana e vecchia SEO tecnica, non solo è ben lungi dal morire ma sembra godere di una rinnovata giovinezza essendole apertamente riconosciuto il ruolo che da sempre le compete, di porre le fondamenta solide di qualsiasi progetto web che ambisca ad ottenere dei risultati.
In poche parole, realizzare siti per gli agenti AI non vuol dire che altro che realizzare siti web di qualità, cosa che all'oggi, richiede ancora competenze ed esperienze che non consentono scorciatoie.
Nota finale: Perché testare ciò che io stesso metto in discussione ?
A questo punto, se qualcuno è riuscito a leggere tutto questo "papiello", potrebbe essere lecito porsi la domanda (infatti qualcuno tra gli amici lo ha già fatto), "Perché testare ciò che metto in discussione? ".
Per rispondere a chi se lo stesse chiedendo aggiungo questo post scriptum.
Implementare il supporto al Markdown pur restando scettici sugli eventuali benefici non è una contraddizione, ma l'applicazione del metodo scientifico. Fare SEO significa validare ipotesi, non cercare conferme alle proprie convinzioni. Un test progettato solo per darsi ragione è un errore metodologico che porta inevitabilmente a risultati approssimativi e fuorvianti (eh si, anche i SEO sono soggetti ad allucinazioni).
Muoversi tra il pragmatismo di John Mueller e la visione "token-centrica" di Addy Osmani è funzionale per mettere in discussione le mie convinzioni, non per cristallizzarle.
