Il tuo sito è leggibile dagli agenti AI?

Fino a poco tempo fa, i siti web venivano costruiti pensando a tre lettori principali: persone, browser e motori di ricerca. Poi sono arrivati gli agenti AI.

Non parlo solo del crawler, parlo di strumenti che leggono documentazione, riassumono pagine, cercano informazioni per conto di qualcuno, aprono link, confrontano fonti, prendono decisioni operative e, in alcuni casi, usano il sito come parte di un flusso di lavoro.

La tentazione, ovviamente, è sempre la stessa: trasformare tutto in una nuova sigla vendibile: GEO, LLMO, AIO, eccetera.

Il punto, per me, è molto più semplice.

Il tuo sito è leggibile anche quando non c’è un umano davanti a un browser?

Se la risposta è no, significa che devi guardare il sito per quello che è davvero: un insieme di contenuti, URL, segnali tecnici, policy di accesso, markup, file pubblici e risposte HTTP. Un sito moderno non deve solo “apparire bene”. Deve essere comprensibile.

Da un utente. Da Googlebot o da un feed reader. Da un validatore oppure da un assistente AI che riceve una domanda specifica e prova a capire cosa fai, cosa vendi, dove sono le informazioni importanti e quali contenuti può usare senza perdersi in menu, cookie banner, JavaScript, footer infiniti e markup decorativo.

Semplice tecnica.

Prima distinzione: ranking e leggibilità non sono la stessa cosa

Partiamo dalla cosa noiosa, quindi importante.

Google, nella pagina ufficiale su AI features and your website, dice una cosa abbastanza chiara: per apparire in AI Overviews o AI Mode non servono requisiti aggiuntivi rispetto alla SEO tradizionale. Non servono file AI speciali, non serve uno schema.org dedicato, non serve inventarsi markup esoterico.

Tradotto: se qualcuno ti vende llms.txt come “la nuova sitemap.xml per posizionarsi nelle risposte AI”, io metterei mano al portafoglio solo per controllare che sia ancora in tasca.

Google dice anche che i fondamentali restano fondamentali: crawling consentito, buona connessione tra link interni, buona esperienza di pagina, dati strutturati coerenti con il testo visibile.

Perché il problema non è “convincere l’intelligenza artificiale”. Il problema è pubblicare contenuti che non richiedano un rito iniziatico per essere letti.

Un agente non guarda il sito come lo guardi tu. Non apprezza il font. Non si emoziona per l’animazione del blocco hero. Non perdona una navigazione confusa perché “visivamente è molto premium” (sinceramente non ho mai capito cosa intendessero dire).

Un agente cerca testo, struttura, link, relazioni, priorità.

Se deve spendere metà del contesto per capire dove finisce il menu e dove comincia il contenuto, hai già perso qualcosa.

HTML va bene. HTML rumoroso un po’ meno

HTML è il web. Non è il nemico. Semmai lo è la vita, per citare il compianto Richard.

Il problema è l’HTML che, visto da un sistema automatico, diventa una discarica ordinata male: header duplicati, menu mobile e desktop, blocchi nascosti, script, attributi generati, componenti idratati, markup di layout, banner, form, pixel, icone, SVG, classi infinite.

Un browser ci convive. Un utente vede il risultato finale, ma un modello linguistico, invece, deve considerare anche il rumore. E il rumore costa contesto.

Cloudflare lo dice senza girarci troppo intorno nella sua documentazione Docs for agents: gli strumenti AI lavorano meglio con Markdown che con HTML perché Markdown ha meno overhead e spreca meno token.

Non è una posizione filosofica. È un fatto pratico.

Guarda la differenza:

1
<section class="hero hero--dark" data-component="Hero">
2
  <div class="container">
3
    <div class="grid">
4
      <div class="copy">
5
        <span class="eyebrow">Consulenza tecnica</span>
6
        <h1>Sviluppo web e SEO tecnica</h1>
7
        <p>Aiuto aziende e agenzie a costruire siti più solidi.</p>
8
      </div>
9
    </div>
10
  </div>
11
</section>

1
# Sviluppo web e SEO tecnica
2

3
Aiuto aziende e agenzie a costruire siti più solidi.

Il browser ha bisogno del primo, o almeno di una sua versione pulita.

Un agente spesso preferisce il secondo.

Questo non significa che dobbiamo buttare HTML e tornare a scrivere pagine come nel 1998, anche se una parte di me ogni tanto ci pensa con affetto. Significa che, per certi contenuti, offrire una rappresentazione più asciutta può essere una scelta sensata.

Soprattutto quando il contenuto ha valore anche fuori dall’interfaccia.

Cosa fa davvero llms.txt

llms.txt nasce come proposta per dare agli LLM un punto di ingresso leggibile e curato.

Non è robots.txt. Non dice “puoi entrare qui e non qui”.

Non è sitemap.xml. Non deve elencare ogni URL indicizzabile.

Non è un file che trasforma un sito mediocre in una fonte autorevole.

È più simile a una mappa ragionata.

Nel formato proposto, il file vive di solito in /llms.txt, usa Markdown e contiene:

• un titolo;
• una descrizione breve;
• un po’ di contesto;
• liste di link verso le risorse più utili;
• eventualmente una sezione opzionale per contenuti secondari.

Esempio volutamente semplice:

1
# Studio Tecnico Rossi
2

3
> Consulenza tecnica per impianti industriali, sicurezza e manutenzione.
4

5
Lo Studio Tecnico Rossi lavora con aziende manifatturiere su audit, perizie,
6
documentazione tecnica e piani di manutenzione.
7

8
## Contenuti principali
9

10
- [Servizi](https://example.com/servizi/): cosa facciamo e per quali aziende
11
- [Casi studio](https://example.com/casi-studio/): esempi di interventi documentati
12
- [Contatti](https://example.com/contatti/): riferimenti e modalità di richiesta
13

14
## Optional
15

16
- [Archivio articoli](https://example.com/blog/): approfondimenti tecnici

La differenza rispetto a una sitemap è evidente: qui non stai dicendo “queste sono tutte le pagine”. Stai dicendo “se devi capire questo sito, parti da qui”.

E questa, su molti siti aziendali, è un’informazione che manca anche agli umani.

Quando ha senso usarlo

llms.txt ha senso quando il sito contiene informazioni che meritano una porta d’ingresso più esplicita.

Lo vedo utile soprattutto in questi casi:

• documentazione tecnica;
• siti di prodotto;
• siti editoriali;
• blog specialistici;
• pagine servizio dense;
• knowledge base;
• e-commerce con schede prodotto complesse;
• portali B2B;
• siti personali di professionisti;
• aziende con servizi difficili da spiegare in tre righe.

Non lo vedo invece come priorità per il sito vetrina fatto di cinque pagine generiche, zero contenuti originali e “soluzioni innovative per il tuo business” ripetuto in ogni sezione.

In quel caso il problema non è che manca llms.txt.

Il problema è che manca qualcosa da far leggere.

La regola è abbastanza pratica: se un consulente, un cliente o un nuovo collaboratore avrebbe bisogno di una spiegazione ordinata per capire il sito, probabilmente anche un agente AI ne beneficia.

Markdown delle pagine

Un llms.txt utile indica risorse. Ma se quelle risorse sono solo HTML rumoroso, hai fatto metà del lavoro.

La proposta llms.txt suggerisce anche una cosa più ambiziosa: rendere disponibili versioni Markdown delle pagine importanti. Per esempio:

1
/servizi/
2
/servizi.md
3

4
/blog/audit-seo-tecnico/
5
/blog/audit-seo-tecnico.md

Oppure usare content negotiation:

1
curl -H "Accept: text/markdown" https://example.com/servizi/

Cloudflare applica un approccio simile nella propria documentazione: ogni pagina può essere richiesta come Markdown aggiungendo /index.md o inviando l’header Accept: text/markdown. Espone anche endpoint come /llms.txt e /llms-full.txt per orientare agenti e strumenti automatici.

Questa non è teoria da laboratorio.

È una grande azienda infrastrutturale che dice, in pratica: se un agente deve leggere la documentazione, diamogli una forma adatta al lavoro che deve fare.

Sul fronte WordPress, ne avevo già parlato in Post WordPress in Markdown, per LLM e agenti, partendo dal problema pratico: gli agenti capiscono meglio contenuti puliti rispetto all’HTML renderizzato dal tema.

Il punto non è fare “SEO per gli LLM”

Qui bisogna stare attenti, perché il mercato ha già iniziato a produrre nebbia.

La domanda giusta non è: come mi posiziono dentro ChatGPT?

La domanda giusta è: cosa succede quando un sistema automatico prova a capire il mio sito?

• Trova una homepage piena di slogan o trova informazioni verificabili?

• Trova pagine servizio distinte o un unico minestrone “facciamo tutto”?

• Trova dati strutturati coerenti con il testo o markup messo lì per riempire un checklist?

• Trova autori, date, aggiornamenti, fonti, esempi, casi, limiti?

• Trova contenuto testuale o deve estrarlo da componenti caricati via JavaScript?

• Trova URL stabili o parametri, filtri e duplicati che si rincorrono?

Queste domande sono SEO tecnica classica. Solo che oggi hanno una conseguenza in più: non stai lavorando solo per la pagina dei risultati tradizionale. Stai lavorando per un ecosistema in cui il contenuto può essere letto, riassunto, citato, confrontato e usato dentro interfacce che non controlli.

E quando non controlli l’interfaccia finale, devi controllare meglio la sorgente.

Robots, Google-Extended e crawler AI

Rendere un sito leggibile non significa spalancare tutto a chiunque.

Qui entra in gioco l’altra metà del discorso: controllo.

robots.txt resta un file importante. Google documenta chiaramente come interpreta il Robots Exclusion Protocol, dove deve stare il file, quali direttive supporta e come vengono gestiti gli errori.

Per Google esiste anche Google-Extended, un token autonomo che i publisher possono usare in robots.txt per gestire l’uso dei contenuti da parte di alcuni prodotti AI di Google. Nella documentazione sui common crawlers, Google specifica anche che Google-Extended non influenza l’inclusione in Google Search e non è usato come segnale di ranking.

Esempio:

1
User-agent: Google-Extended
2
Disallow: /

Questo non significa “ho risolto il problema AI”.

Significa: per un attore specifico, che dichiara un comportamento specifico, posso esprimere una preferenza leggibile dalle sue infrastrutture.

Il resto del mondo è più disordinato.

Alcuni crawler si dichiarano. Alcuni rispettano robots.txt. Alcuni no. Alcuni passano da browser headless. Alcuni cambiano user agent. Alcuni non sono crawler di training, ma assistenti attivati da un utente. Alcuni arrivano tramite servizi terzi.

Qui un file di testo non basta più.

Servono log, CDN, regole WAF, rate limiting, monitoraggio e una scelta strategica: cosa voglio rendere facile da leggere e cosa voglio proteggere?

Cloudflare, con AI Crawl Control, va proprio in questa direzione: monitorare quali servizi AI accedono ai contenuti, gestire regole per crawler specifici, tracciare violazioni di robots.txt e, in alcuni casi, valutare modelli di monetizzazione come Pay Per Crawl.

Che poi Pay Per Crawl diventi uno standard o una parentesi storica, si vedrà.

Ma il segnale è chiaro: il traffico degli agenti e dei crawler AI non è più una curiosità da log. È una superficie tecnica da governare.

Una checklist concreta

Se dovessi controllare un sito oggi, partirei da qui.

1. Contenuto testuale vero

Le informazioni importanti devono esistere come testo leggibile.

Non solo dentro immagini. Non solo dentro componenti caricati tardi. Non solo in PDF messi online perché “tanto c’è il catalogo”.

Il testo deve essere nel posto giusto, con heading sensati e una gerarchia riconoscibile.

2. URL stabili

Un agente non deve inseguire cinque varianti della stessa pagina.

Canonical, redirect, trailing slash, parametri e archivi devono essere sotto controllo. Non è glamour, ma la SEO tecnica vive di cose non glamour che, quando mancano, fanno danni concreti.

3. Sitemap e robots puliti

La sitemap deve elencare ciò che vuoi far scoprire.

robots.txt deve dire ciò che vuoi limitare.

Non deve essere un fossile generato tre anni fa da un plugin dimenticato. Non deve bloccare asset necessari al rendering. Non deve restituire HTML per sbaglio. Non deve vivere in una sottocartella dove nessun crawler serio andrà a cercarlo.

4. Dati strutturati coerenti

I dati strutturati non sono decorazione.

Se dichiari FAQ, articoli, prodotti, organizzazione, breadcrumb o recensioni, il markup deve corrispondere al contenuto visibile. Google lo ripete anche nelle best practice per le funzioni AI: i dati strutturati devono combaciare con il testo della pagina.

Non serve “mettere schema”. Serve descrivere bene ciò che esiste.

5. llms.txt piccolo, curato, mantenibile

Meglio un llms.txt breve e aggiornato che un manifesto ambizioso dimenticato dopo due settimane.

Io partirei con:

• homepage;
• pagina servizi;
• pagina contatti;
• profilo aziendale o autore;
• contenuti editoriali principali;
• documentazione o pagine prodotto, se esistono;
• eventuale versione Markdown completa, se generata in modo affidabile.

6. Markdown dove serve davvero

Non tutto merita una versione Markdown.

La merita ciò che contiene informazione: guide, documentazione, articoli, pagine servizio, policy, manuali, schede tecniche.

Non la merita il contenuto puramente navigazionale, promozionale o duplicato.

7. Log dei crawler

Senza log stai ragionando a sensazione.

Almeno per i siti importanti, conviene capire:

• quali crawler passano;
• con che frequenza;
• su quali URL;
• con quali user agent;
• con che status code;
• se rispettano robots.txt;
• se generano carico o errori;
• se leggono contenuti che non dovrebbero interessare a nessuno.

Non serve diventare paranoici. Serve non essere ciechi.

Una scelta pragmatica

Io oggi non venderei llms.txt come priorità assoluta per ogni sito.

Lo metterei nella cassetta degli attrezzi della SEO tecnica, vicino a sitemap, robots, feed, dati strutturati, performance, accessibilità e contenuti testuali.

Non sopra. Non al posto.

Lo userei quando c’è contenuto da valorizzare e quando il sito ha una ragione concreta per essere letto anche da strumenti automatici.

Lo eviterei quando diventa un modo per dipingere di nuovo una parete con l’umidità sotto.

La direzione però mi sembra chiara: il web non viene più letto solo attraverso pagine renderizzate in un browser. Sempre più spesso viene letto da sistemi intermedi, assistenti, crawler, indicizzatori, strumenti di sviluppo e motori generativi.

Non possiamo controllare tutto quello che faranno.

Possiamo però controllare meglio ciò che pubblichiamo.

E, come spesso succede nella tecnica, la risposta meno spettacolare è anche quella più solida: contenuti chiari, HTML pulito, URL stabili, segnali espliciti, Markdown dove serve, log sotto controllo.

Il resto è rumore. E di rumore, sul web, ne abbiamo già abbastanza.