Blog

Di cosa ha bisogno un sito pronto per gli agenti AI: appunti dalla costruzione di dardo.studio

Abbiamo reso dardo.studio leggibile e richiamabile dagli agenti AI, un livello alla volta. Ecco cosa fa ogni livello, chi documenta di leggerlo oggi e quali rifaremmo.

Di Nicolás Cerón ·

Un piccolo robot su ruote segue una linea guida color cremisi in una galleria d'arte di notte, verso una scultura illuminata.

La risposta breve

Un sito pronto per gli agenti AI fa tre cose. Gli agenti AI possono raggiungerlo. Possono leggerlo senza farsi largo tra menu, banner e script. E, dove ha senso, possono richiamare alcuni strumenti dichiarati invece di tirare a indovinare quale pulsante premere.

Abbiamo integrato tutti e tre i livelli in dardo.studio all'inizio di ottobre 2026. Ecco cosa abbiamo messo online e quanto di tutto questo le principali piattaforme di AI documentano di usare, verificato sul sito live l'8 ottobre 2026.

Il riepilogo è meno entusiasmante della maggior parte delle checklist "AI-ready". I livelli più vecchi sono quelli che pesano di più: l'accesso dei crawler e un HTML pulito e semantico. Le copie in markdown e llms.txt sono comodità a basso costo. MCP, A2A e WebMCP sono protocolli veri, con client funzionanti, ma nessuna delle documentazioni sui crawler che citiamo, di OpenAI, Anthropic, Perplexity o Google, descrive i loro assistenti mentre trovano da soli gli strumenti di un sito.

Si parte dall'accesso: robots.txt e l'edge

Il nostro robots.txt ripete lo stesso gruppo di regole per l'agente predefinito (*) e per ogni crawler di ricerca AI e user fetcher che nominiamo:

User-agent: OAI-SearchBot
Allow: /
Disallow: /api/
Content-Signal: search=yes, ai-input=yes

Le stesse regole valgono per ChatGPT-User, PerplexityBot, Perplexity-User, Claude-SearchBot, Claude-User e Bingbot. Solo /api/ è chiuso.

I crawler di ricerca e quelli di addestramento sono distinti

Le grandi aziende ora documentano token separati per la ricerca e per l'addestramento:

  • OpenAI. OAI-SearchBot fa comparire i siti nella ricerca di ChatGPT. I siti che lo bloccano restano fuori dalle risposte della ricerca di ChatGPT, anche se possono comunque apparire come semplici link di navigazione. GPTBot raccoglie dati per l'addestramento. (crawler di OpenAI)
  • Anthropic. Claude-SearchBot indicizza per la ricerca, ClaudeBot raccoglie dati per l'addestramento e Claude-User recupera le pagine quando una persona fa una domanda a Claude. (crawler di Anthropic)
  • Perplexity. PerplexityBot fa comparire i siti e li collega nei risultati di Perplexity e non viene usato per addestrare modelli di base. (crawler di Perplexity)
  • Google. Google-Extended è un token di controllo per l'addestramento di Gemini e il grounding in altri prodotti Google. Non influisce sull'inclusione o sul posizionamento in Google Search. (crawler comuni di Google)

I fetcher attivati dall'utente sono un'altra cosa. OpenAI dice che robots.txt potrebbe non valere per ChatGPT-User, perché sono le persone ad avviare quelle richieste. Perplexity-User e i fetcher attivati dall'utente di Google in genere lo ignorano. Questi fetcher agiscono per conto di una persona in tempo reale; dove un blocco funziona, di solito impedisce soltanto all'assistente di quella persona di leggere la tua pagina.

Il nostro file non nomina i crawler di addestramento, quindi rientrano in * e sono consentiti. È una decisione di business, e i fornitori la documentano come un controllo separato: bloccare GPTBot o ClaudeBot non equivale a uscire dai loro indici di ricerca.

Content Signals: una riga, nessun impegno

La riga Content-Signal deriva dalla Content Signals Policy di Cloudflare, che indica tre usi: search, ai-input (fornire contenuti a un modello al momento della risposta) e ai-train. Noi omettiamo ai-train, che secondo la policy non concede né limita quell'uso. Cloudflare precisa che i segnali esprimono preferenze, non bloccano nulla e possono essere ignorati. Nessuna delle pagine sui crawler citate qui li menziona. Costa una riga; per ora non aspettarti nulla.

Controlla l'edge, non solo il file

robots.txt dichiara una policy; è la tua CDN a decidere cosa succede davvero. Nei nostri test del 2 ottobre, il Browser Integrity Check di Cloudflare rispondeva con un 403 al client HTTP predefinito di Python (Python-urllib) e a libwww-perl, mentre robots.txt consentiva tutto. Gli script scritti dagli agenti di programmazione spesso usano la libreria standard di Python senza modifiche.

Abbiamo aggiunto una regola di configurazione di Cloudflare che esclude le richieste GET e HEAD per i contenuti pubblici; /api/ risponde ancora 403. La stessa verifica ha mostrato che i nostri file .txt non avevano il charset, così alcuni client leggevano "Bogotá" come "Bogotá". La soluzione è stata un solo header: charset=utf-8.

Fai test con richieste reali sotto ogni user agent. Questo mostra che nulla blocca quel nome; non dimostra che il vero crawler sia passato.

HTML semplice e semantico: il livello da cui dipendono tutti gli agenti

La guida all'ottimizzazione per l'AI di Google descrive agenti del browser che analizzano screenshot, ispezionano il DOM e interpretano l'albero di accessibilità. Rimanda i proprietari dei siti alle indicazioni di web.dev per i siti adatti agli agenti, che per lo più sono lavoro di accessibilità: usare <button> e <a> al posto di <div> con stili, collegare ogni etichetta al suo campo e impedire che il layout si sposti durante uno screenshot.

Su dardo.studio ogni pagina ha un solo <main> e landmark <nav> con etichetta. I pulsanti del menu e del tema sono veri pulsanti che indicano il loro stato con aria-expanded e aria-pressed, e i menu chiusi sono inert. Ogni campo del modulo di contatto sta dentro il proprio <label>, che gli dà un nome accessibile. web.dev suggerisce l'attributo for; racchiudere l'input fa lo stesso lavoro.

Questo aiuta già oggi chi usa uno screen reader, e basterebbe come motivo.

Una copia markdown pulita di ogni pagina

Gli agenti pagano ogni token che leggono, e una pagina renderizzata include navigazione, banner dei cookie, script e grafiche decorative. Prima di questo lavoro, richiedere le nostre pagine con Accept: text/markdown restituiva tutto questo in HTML.

Ora un passaggio della build crea un file index.md accanto a ogni pagina indicizzabile. Si apre con il front matter (titolo, descrizione, URL canonico, lingua, versione nell'altra lingua e data di aggiornamento), seguito dal contenuto di <main> della pagina, senza script, pulsanti, immagini decorative né indice dei contenuti interno. Le risposte delle FAQ restano. I moduli diventano un elenco dei loro campi e delle opzioni, così un agente può dire a una persona cosa chiede il nostro modulo di contatto senza toccarlo.

Ci sono tre modi per ottenere la copia:

  • Invia Accept: text/markdown all'URL normale. Queste risposte includono Vary: Accept, così le cache tengono separate le versioni.
  • Richiedi il file: /en/services/seo/index.md.
  • Aggiungi .md al percorso della pagina (/en/services/seo.md). Per gli URL che terminano con una barra, la proposta llms.txt usa index.md, la forma indicata sopra.

Ogni pagina HTML rimanda inoltre alla propria copia con <link rel="alternate" type="text/markdown">.

Riportare i motori di ricerca all'HTML

La guida di Google osserva che può scansionare e indicizzare molti tipi di file oltre all'HTML, senza trattarli in modo speciale. Una copia in markdown potrebbe competere con la propria pagina, quindi ogni risposta markdown indica la pagina HTML come canonica:

$ curl -sI https://dardo.studio/en/services/seo/index.md
content-type: text/markdown; charset=utf-8
link: <https://dardo.studio/en/services/seo/>; rel="canonical", ...

Chi legge queste copie? Cloudflare ha creato Markdown for Agents per convertire l'HTML all'edge per le richieste che preferiscono il markdown, il che fa pensare che gli agenti lo richiedano. Non indica quali client inviino l'header e nemmeno noi abbiamo un elenco verificato. Se usi la funzione di Cloudflare, questa aggiunge Content-Signal: ai-train=yes, search=yes, ai-input=yes, a meno che il tuo origin non ne imposti uno proprio. Noi generiamo le nostre copie in fase di build, così corrispondono esattamente alla pagina.

llms.txt: un indice utile, senza effetti sulla ricerca

llms.txt è una proposta di Jeremy Howard, pubblicata per la prima volta a settembre 2024 e ancora aperta ai contributi della community: un file markdown in /llms.txt con il nome del sito, un breve riassunto ed elenchi di link che un agente potrebbe voler consultare.

Il nostro, in /llms.txt e /es/llms.txt, è generato dagli stessi dati delle pagine, quindi non può andare fuori sincrono. Riporta i dati dello studio (Bogotá, fondato nel 2026, un team di tre persone, come vengono definiti i prezzi dei progetti, canali di contatto), elenca servizi e lavori e spiega come ottenere le copie in markdown. llms-full.txt contiene il testo completo delle pagine studio, servizi, lavori e contatti.

Una riga indica attività con nomi simili che non siamo noi. Quando abbiamo controllato, il 2 ottobre, erano in testa ai risultati di ricerca per "dardo studio". Quella riga potrebbe essere la più utile del file.

La situazione, in parole semplici:

  • Google afferma che non serve llms.txt per comparire nella Ricerca o nelle sue funzioni di IA, che la Ricerca lo ignora e che averne uno non aiuta né danneggia.
  • OpenAI, Anthropic e Perplexity non dicono nella documentazione dei loro crawler che i loro bot leggano gli llms.txt di altri siti. I siti di documentazione di OpenAI, Anthropic e Perplexity ne pubblicano però uno, per gli agenti che leggono la loro documentazione.

Tienilo se è generato ed è accurato. Aiuta gli agenti di programmazione e gli strumenti che lo cercano. Non è una leva di visibilità.

Strumenti che gli agenti possono chiamare: MCP, A2A e catalogo API

Abbiamo pubblicato due strumenti di sola lettura:

  • list_services restituisce i nostri servizi pubblicati, l'ambito, i deliverable e gli URL delle fonti in inglese o spagnolo, filtrati da una parola chiave facoltativa.
  • get_project_brief restituisce le domande a cui rispondere prima di contattarci e il link di contatto localizzato per quel servizio.

Un'unica implementazione sta dietro a diversi punti di accesso:

Punto di accessoIndirizzo su dardo.studioStandard e stato
Server MCP/mcp, card in /.well-known/mcp/server-card.jsonMCP Streamable HTTP; la server card è una bozza di proposta
Agente A2A/a2a, card in /.well-known/agent-card.jsonA2A 1.0, JSON-RPC
Endpoint JSON/agent/services.json, descritto in OpenAPIHTTP semplice
Catalogo API/.well-known/api-catalogRFC 9727, IETF Standards Track

Ogni risposta HTML e markdown invia un header Link che punta al catalogo, all'indice delle agent skills e a entrambe le card, così da qualsiasi pagina si arriva al resto.

Regole di progettazione che ripeteremmo

  • Sola lettura e pubblico. Gli strumenti MCP dichiarano readOnlyHint: true e leggono lo stesso catalogo pubblicato dell'HTML, senza alcun database dietro. get_project_brief non invia, non prenota e non fa preventivi; una persona rivede e invia.
  • Input limitato. Il corpo delle richieste è limitato a 8 KiB, gli header Origin del browser vengono verificati (la specifica MCP lo richiede) e le chiamate hanno un proprio rate limit.
  • Nessuno stato. L'agente A2A risponde subito, non conserva task, ha lo streaming disattivato e non scarica file o URL che gli vengono inviati.
  • Condizioni chiare. /auth.md dice che non servono credenziali e che leggere dati pubblici non autorizza a inviare un messaggio o a effettuare un pagamento.

Abbiamo anche lasciato fuori alcune cose. Gli scanner di readiness cercano protocolli di commercio e OAuth discovery. Noi non vendiamo nulla tramite checkout e non proteggiamo alcuna risorsa, quindi pubblicarli descriverebbe funzionalità che non esistono.

Chi usa oggi questi strumenti: i client MCP che qualcuno ha collegato a /mcp e i client A2A a cui è stata data la nostra card. Per uno studio il valore è modesto: una risposta precisa a "cosa fa Dardo e cosa devo mandargli?" Il caso è più solido per un sito con dati in tempo reale su cui le persone fanno domande, come scorte, disponibilità o documentazione di prodotto. Gli agenti che scrivono dati richiedono autenticazione e passaggi di revisione; quello è lavoro di automazione con l'IA.

WebMCP: gli stessi strumenti dentro il browser

WebMCP permette a una pagina di registrare strumenti che un agente IA nel browser può chiamare. È un Draft Community Group Report del W3C Web Machine Learning Community Group e dichiara di non essere uno standard W3C. web.dev afferma che è in sviluppo attivo, può cambiare e si può provare in Chrome tramite un origin trial.

Le nostre pagine registrano gli stessi due strumenti tramite document.modelContext (o navigator.modelContext nelle anteprime meno recenti). Senza l'API, il browser non esegue nulla di aggiuntivo. Poiché gli strumenti esistevano già, sono bastate circa 40 righe. Consideralo un esperimento.

Ogni livello e se vale la pena

LivelloChe cos'èChi lo legge oggiNe vale la pena?
HTML semantico e moduli con etichettePulsanti, link, landmark ed etichette veriBrowser, tecnologie assistive e agenti browserSì. Parti da qui
robots.txt per search e user agentRegole per singolo crawler che separano la ricerca dall'addestramentoOpenAI, Anthropic, Perplexity e Google documentano i propri tokenSì. Poi testalo a livello di CDN
Content SignalsPreferenze search, ai-input, ai-train nel robots.txtNessuna azienda di IA tra quelle verificate documenta di rispettarleUna riga. Non aspettarti nulla
Copie markdown con header canonicalUna versione testuale pulita di ogni paginaAgenti che richiedono il markdown; non esiste un elenco pubblico di qualiSì, con l'header canonical
llms.txt e llms-full.txtUn indice curato e il testo completo per gli agentiGoogle Search lo ignora; nessuna documentazione dei crawler dichiara di leggerloTienilo se è generato. Non è una leva di visibilità
Server MCP (sola lettura)Strumenti dichiarati che gli agenti possono richiamareClient MCP che una persona collegaSolo se ci sono dati o azioni che valga la pena richiamare
Agent card A2AUna descrizione leggibile da una macchina di un agenteClient A2A che vengono indirizzati verso di essaSpeculativo per la maggior parte dei siti
Catalogo API (RFC 9727)Un unico elenco well-known delle tue API pubblicheStrumenti che lo cercanoEconomico se hai già delle API
WebMCPStrumenti che la pagina registra nel browserChrome, tramite un origin trialEsperimento

Cosa rifaremmo

In ordine: HTML semantico, accesso dei crawler testato, copie markdown con header canonical, un llms.txt generato e strumenti solo quando c'è qualcosa che valga la pena richiamare. Poi misura. I log del server mostrano quali agenti scaricano le copie markdown o chiamano /mcp. Un fetch non è una citazione, e nulla di tutto questo garantisce che un sistema di IA parli di te.

La predisposizione agli agenti fa parte del nostro lavoro di ottimizzazione per la ricerca con IA, insieme ai contenuti e alle misurazioni che decidono se le risposte dell'IA ti citano. Per integrarla nel tuo sito, raccontaci il tuo progetto.