llms.txt - Web Design | Creazione Siti Internet https://www.mrtux.it Sviluppo Siti Web - Assistenza WordPress Sat, 15 Aug 2026 13:33:02 +0000 it-IT hourly 1 https://wordpress.org/?v=7.0.1 https://www.mrtux.it/wp-content/uploads/2022/06/favicon-150x150.png llms.txt - Web Design | Creazione Siti Internet https://www.mrtux.it 32 32 AI crawler decision framework 2026: i 4 layer che controllano davvero https://www.mrtux.it/ai-crawler-decision-framework-4-layer-2026 https://www.mrtux.it/ai-crawler-decision-framework-4-layer-2026#respond Sat, 15 Aug 2026 13:33:00 +0000 https://www.mrtux.it/ai-crawler-decision-framework-2026-i-4-layer-che-controllano-davvero Apertura: il problema con cui tutti fanno i conti

Sul fronte del traffico AI bot, il 2026 è l'anno in cui un numero sempre maggiore di editori si è svegliato con la sensazione che il proprio server stesse lavorando per i crawler più che per gli utenti. Kinsta, nel rapporto AI & Bot Traffic pubblicato nell'estate 2026 e ripreso nel successivo post "llms.txt vs robots.txt: What actually controls AI crawlers?", documenta che il traffico AI bot sui siti ospitati è passato da una visita AI ogni 200 a una ogni 31 in dodici mesi. Una esplosione che nessun operatore di WordPress può permettersi di ignorare, ma anche una confusione senza precedenti su cosa fare per fermarla.

Provate a mettere in fila le ricerche che un editore medio fa su Google quando il server inizia a soffrire: robots.txt AI bot block, llms.txt file, Cloudflare AI block, WordPress bot mitigation plugin. Si ottengono articoli che si contraddicono l'uno con l'altro. C'è chi dice che llms.txt blocca i bot AI. C'è chi dice che llms.txt è un file innocuo, un README per i modelli. C'è chi mostra decine di regole robots.txt e poi ammette che il crawler ByteDance Bytespider storicamente non le ha mai rispettate. Il problema non è la documentazione tecnica, è che robots.txt, llms.txt, AI crawlers e bot protection sono quattro strumenti diversi che la comunità tratta come se fossero quattro impostazioni dello stesso interruttore.

Questo articolo mette in fila quei quattro strumenti, spiega cosa fa ciascuno di essi e, soprattutto, quale di loro effettivamente blocca un bot che non vuole rispettare le regole. È un complemento operativo alla guida AEO su llms.txt e infrastruttura già pubblicata su mrtux.it: lì si parlava di come generare un buon llms.txt; qui si parla di quando llms.txt serve davvero e quando è meglio spendere quei minuti su altro.

I 4 layer del traffico AI bot, in ordine di richiesta

Quando un bot AI raggiunge un sito WordPress, il suo comportamento dipende da quale dei quattro layer si attiva prima nella pipeline della richiesta. Sono layer che lavorano in momenti diversi del ciclo di vita della richiesta, con meccanismi diversi, e che vengono gestiti da soggetti completamente diversi.

Layer 1: il client (l'AI crawler)

Layer 1 è il client, ovvero il crawler vero e proprio. È il bot che fa la richiesta. Lo gestisce il provider (OpenAI, Anthropic, Google, Meta, ByteDance), non tu. Il massimo che puoi fare è identificarlo dal User-Agent, dalla rotazione di IP, e dalla firma comportamentale (rate, sequenza di URL, header proprietari). Quando il client decide di ignorare robots.txt e llms.txt non c'è alcun meccanismo di enforcement a monte: è il provider a stabilire il proprio codice di condotta.

Layer 2: robots.txt

Layer 2 è robots.txt, situato alla radice del dominio. È un file che esprime una preferenza: "per favore non indicizzare queste URL". I crawler rispettabili - GPTBot, ClaudeBot, PerplexityBot, Googlebot, Amazonbot - lo leggono e in larga misura lo rispettano. Crawler meno rispettabili (Bytespider di ByteDance, vari scraper SEO) lo ignorano e basta. Non esiste enforcement tecnico sul file robots.txt: è una richiesta educata, non un blocco.

Layer 3: llms.txt

Layer 3 è llms.txt, introdotto con l'obiettivo di fornire un indice di contenuti puliti per i modelli AI. llms.txt non controlla l'accesso. È un file di indici che i modelli possono leggere se vogliono; non è un meccanismo di autorizzazione. Kinsta misura che l'adozione del file è ferma attorno al 9-10% dei siti, e che la maggior parte dei crawler AI principali non lo recupera neppure. llms.txt è utile come strumento di discoverability per i contenuti, non come scudo contro i bot.

Layer 4: bot protection enforcement

Layer 4 è il livello in cui si trova la sola vera difesa attiva: bot protection a livello infrastrutturale. Parliamo di Cloudflare AI Crawl Control, Kinsta Bot Protection, AWS WAF, Azure Bot Manager, e dei plugin WordPress che implementano fingerprinting e challenge JavaScript. Questi sistemi agiscono sulla richiesta a livello di edge o di application server: possono sfidare il client con un check JS, droppare la connessione, applicare un rate limit. Sono l'unico layer in cui "ho detto di no" diventa effettivamente "no".

La metafora del locale aperto

Layer 4 è l'unico strato di enforcement reale. Una metafora aiuta. Immaginate di gestire un locale. robots.txt è il cartello "riservato ai soci" sulla porta: i clienti educati lo leggono, gli scrocconi lo ignorano. llms.txt è l'elenco dei piatti del giorno dato a chi passa davanti: chi vuole sa cosa offri, ma non c'è alcun controllo su chi entra. La bot protection enforcement è la porta a monte che fa vedere il documento all'ingresso e decide chi può accomodarsi e chi no. Tre strumenti diversi, tre lavori diversi. Mescolarli è esattamente il modo in cui un editore può fare tutto "per bene" e ritrovarsi con il server sotto assedio.

Cosa fa realmente ciascun layer (operativamente)

robots.txt: solo per crawler rispettabili

robots.txt è ancora utile nel 2026, ma solo come prima linea contro i crawler che rispettano le convenzioni. Su un sito editoriale che vuole farsi indicizzare da Google e OpenAI e vuole evitare Bytespider, la regola canonica rimane valida. Il problema nasce quando si presume che robots.txt risolva il problema del traffico eccessivo di bot AI: non lo fa. Al massimo lo attenua.

# robots.txt - esempio baseline per un sito editoriale WordPress
User-agent: GPTBot
Allow: /wp-content/uploads/2026/
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/

User-agent: ClaudeBot
Allow: /wp-content/uploads/2026/
Disallow: /cart/
Disallow: /checkout/

User-agent: PerplexityBot
Allow: /

User-agent: Bytespider
Disallow: /

User-agent: CCBot
Allow: /wp-content/uploads/2026/
Disallow: /private/

User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml

Questo esempio differenzia i crawler rispettabili da quelli aggressivi. Non impedisce comunque a Bytespider di fare la cattiva azione.

llms.txt: strumento di discoverability, non di blocco

llms.txt si scrive una volta sola e vive accanto a robots.txt. Non blocca nulla, elenca contenuti in formato markdown con descrizione e URL, rendendo più facile per un modello trovare ciò che cerchi.

# llms.txt - esempio per un editore
# Maggiori informazioni: https://example.com/about

Notizie
Reportage di attualità: https://example.com/category/news/ (reportage originali pubblicati 1-2 volte a settimana).
Editoriali: https://example.com/category/editorials/ (opinioni della redazione).

Approfondimenti
Guide: https://example.com/category/guides/ (guide pratiche su strumenti e tecnologie).
Interviste: https://example.com/category/interviews/ (conversazioni con esperti del settore).

Opzionale
Indice completo degli articoli: https://example.com/all-articles.md (elenco in markdown di tutti i contenuti).

Notate che llms.txt è puramente descrittivo. Non c'è alcun meccanismo di disallow, allow o rate limit. È un README per modelli.

Bot protection: dove si fa il lavoro vero

La bot protection enforcement entra in gioco a livello infrastrutturale. Kinsta Bot Protection, introdotto come strumento self-serve in tutti i piani nel giugno 2026, offre 4 preset ("strict", "balanced", "AI crawler aware", "off") e un toggle granulare "Block AI Crawlers". Cloudflare, sul lato opposto, offre Workers customizzabili con analisi del cf.client.bot_score, fingerprint dei client TLS, e regole WAF a costo zero nel piano free.

# Cloudflare WAF rule (pseudo-codice)
# Blocco AI crawler noti che ignorano robots.txt + fingerprint sospetto
(ip.src in $ai_crawler_ranges and cf.client.bot_score < 30)
  -> action: challenge

La combinazione di Cloudflare (per i crawler cattivi) con robots.txt (per i crawler rispettabili) è la configurazione di riferimento: robots.txt dice "per favore", Cloudflare dice "non puoi".

Il decision framework a 4 step

Per scegliere la strategia giusta per un sito, basta rispondere a quattro domande in sequenza. Il framework produce una risposta operativa e non una preferenza teorica.

Step 1: il sito guadagna o perde se i bot AI leggono i contenuti?

Per un editore che monetizza con pubblicità o con abbonamenti, i bot AI rappresentano un costo (lavorano i loro articoli) ma anche un'opportunità (sono indicizzati dai motori di risposta AI). Per un ecommerce, sono quasi sempre un costo: il checkout dinamico viene caricato centinaia di volte al minuto e il server soffre. La risposta determina se llms.txt serve come tool di discoverability (sì per i primi, facoltativo per i secondi).

Step 2: il server regge fisicamente il traffico?

Se la risposta è no, serve la bot protection enforcement. Cloflare free, Kinsta Bot Protection incluso, o un plugin self-hosted come ShieldPRO. robots.txt da solo non scarica il peso.

Step 3: i crawler rispettabili devono poter indicizzare?

Per gli editori che vogliono essere citati in ChatGPT, Perplexity e Google AI Overviews, la risposta è sì. E allora robots.txt va configurato per dare accesso selettivo (es. consentire GPTBot solo a /wp-content/uploads/2026/) e bloccare il resto.

Step 4: serve un'analisi del traffico prima di intervenire?

Sì, senza eccezioni. Senza log strutturati su User-Agent, IP, pattern di URL, si sta andando alla cieca. Kinsta stessa pubblica uno script bash che parsa i log Nginx in cerca di hit per AI bot e produce una tabella aggregata da cui partire per le decisioni successive. Lo script è un buon complemento del framework.

#!/bin/bash
# Analisi traffico AI bot - richiede access.log Nginx parsabile
# Uso: ./ai-bot-report.sh /var/log/nginx/access.log 30

LOG="${1:-/var/log/nginx/access.log}"
DAYS="${2:-30}"

echo "Report AI bot ultimi $DAYS giorni su $LOG"
echo "================================================"

# estrazione richieste per User-Agent
awk -v cutoff="$(date -d "$DAYS days ago" '+%d/%b/%Y')" '
$4 >= "["cutoff {
  match($0, /"([^"]+)"/, ua);
  print ua[1]
}' "$LOG" | sort | uniq -c | sort -rn | head -20

echo ""
echo "Top 10 IP per AI bot signatures"
echo "--------------------------------"

grep -Ei 'GPTBot|ClaudeBot|PerplexityBot|Bytespider|CCBot|Google-Extended' "$LOG" \
  | awk '{print $1}' \
  | sort | uniq -c | sort -rn | head -10

Lo script è una versione semplificata di quello che gli editori si trovano a riscrivere ogni volta che cambiano hosting. Loggare User-Agent + rotazione IP + sequenza di URL è il primo gradino per prendere decisioni informate sui 4 layer.

Scenario editoriale: 800k visite/mese, 23% da AI bot

Prendiamo un editore reale, 800.000 visite umane mensili, sito di notizie verticali. Loggando il traffico per 30 giorni, emerge che GPTBot fa 2,4 milioni di richieste sul solo endpoint /category/news/, ClaudeBot 1,1 milioni, Bytespider 4,8 milioni. Totale richieste AI: 8,3 milioni al mese contro 800k di utenti umani: circa 10:1.

Applicando il framework a questo caso:

  1. Guadagno o perdita? Guadagno. Il sito è indicizzato da ChatGPT e Perplexity e ogni mese riceve migliaia di referral AI. llms.txt rimane uno strumento utile di discoverability.
  2. Server regge? No. CPU al 78% medio, picchi al 95% durante le finestre di crawl. Bot protection enforcement è obbligatoria.
  3. Crawler rispettabili indicizzano? Sì. robots.txt viene tenuto, con regole che limitano il rate.
  4. Analisi preventiva? Eseguita, altrimenti non avremmo i numeri di partenza.

La sequenza operativa diventa: configura Cloudflare con regole di challenge sui bot signatures con cf.client.bot_score < 30; tieni robots.txt aperto per GPTBot/ClaudeBot/PerplexityBot, chiuso per Bytespider e ia_archiver; produci un llms.txt corposo, perché il sito trae vantaggio dalla discoverability; monitora settimanalmente.

Il risultato, documentato in numerosi case study pubblicati su Kinsta Blog e ripresi anche nella nostra analisi sull'infrastruttura AEO di WordPress, è una riduzione del 50-60% del traffico AI bot (rimane la parte che serve a essere citati) e un dimezzamento della CPU impegnata dal crawling.

Scenario ecommerce: 12.000 SKU, 71% di carrelli abbandonati

Scenario diverso: ecommerce WooCommerce con 12.000 referenze, 3.000 ordini al mese. robots.txt è già configurato per bloccare /cart/, /checkout/, /my-account/, ma i crawler AI continuano a ignorare queste regole e a richiedere /cart/?add-to-cart=12345 a ripetizione.

Applicando il framework:

  1. Guadagno o perdita? Perdita. Il cliente non guadagna niente dalla citazione in un motore di risposta.
  2. Server regge? No. Tasso di abbandono carrello al 71%, in larga parte causato da rallentamenti del checkout dovuti al sovraccarico.
  3. Crawler rispettabili indicizzano? Solo schede prodotto pubbliche. Tutto il resto deve restare vietato.
  4. Analisi preventiva? Eseguita, rivela 11 crawler distinti che colpiscono /cart/ a frequenza di 1,5 richieste al secondo.

Sequenza operativa: abilita Kinsta Bot Protection o Cloudflare bot score; configura Cloudflare Workers per redirigere i bot con signature sospetta verso una pagina statica di challenge; mantieni robots.txt chiuso per cart/checkout/my-account; in aggiunta, implementa un guard applicativo PHP con priorità 1 su init (lo abbiamo trattato nella guida pratica su WooCommerce e bot AI). llms.txt in questo caso si omette: non serve indicizzare carrelli e checkout.

Errori da non fare nel 2026

Trattare llms.txt come una soluzione di blocco

llms.txt non è una soluzione di blocco. Se vedete un articolo che spiega "come bloccare i bot AI con llms.txt", diffidate: è un errore concettuale.

Configurare robots.txt e non avere bot protection

Senza enforcement, robots.txt è solo educazione. Un piano gratuito Cloudflare, una regola Kinsta Bot Protection, o un plugin self-hosted: serve enforcement.

Bloccare tutti i bot

Il blanket blocking con User-agent: * + Disallow: / è la scelta peggiore del 2026. Blocca i bot che non avrebbero creato problemi, non blocca quelli malevoli, e ti esclude dai motori di risposta AI. L'ho analizzato nella strategia blanket blocking: con il blanket blocking si perdono citazioni e referral.

Disabilitare robots.txt e llms.txt per disperazione

Alcuni, frustrati, cancellano robots.txt e llms.txt pensando di essere più visibili. È l'opposto del necessario: meglio un robots.txt aperto ai bot rispettabili che niente robots.txt.

FAQ

llms.txt blocca davvero i crawler AI? No. llms.txt è un file descrittivo. I crawler che lo leggono lo usano come indice, ma non sono obbligati a rispettarlo.

Kinsta Bot Protection è meglio di Cloudflare? Sono prodotti diversi. Kinsta Bot Protection è integrato nel piano Kinsta e lavora sull'application server, Cloudflare lavora sull'edge CDN. Per un sito Kinsta, è naturale usare entrambi; per un sito su altro hosting, Cloudflare è la scelta più immediata.

Posso usare llms.txt senza robots.txt? Sì, ma è inutile: llms.txt indica contenuti ai modelli, mentre robots.txt almeno educa i crawler rispettabili sulle URL da non richiedere.

Quale layer ha il miglior rapporto costo/efficacia? Bot protection enforcement, perché scarica traffico reale dal server. llms.txt e robots.txt costano zero ma hanno efficacia limitata.

Quanto è alta l'adozione di llms.txt nel 2026? Circa 9-10% secondo Kinsta. Il dato è fermo da inizio anno, segno che llms.txt non è visto dai siti come uno strumento prioritario di AI readiness.

Riferimenti utili per approfondire

]]> https://www.mrtux.it/ai-crawler-decision-framework-4-layer-2026/feed 0 AEO WordPress 2026: llms.txt e infrastruttura per AI bot https://www.mrtux.it/aeo-wordpress-infrastruttura-llms-txt-cache-ai https://www.mrtux.it/aeo-wordpress-infrastruttura-llms-txt-cache-ai#respond Wed, 17 Jun 2026 03:23:44 +0000 https://www.mrtux.it/aeo-wordpress-2026-llms-txt-e-infrastruttura-per-ai-bot Perché il 90% delle guide AEO si ferma al contenuto

Se hai letto AEO WordPress: come farsi citare da ChatGPT, Perplexity e Claude e GEO, AEO e SEO su WordPress: come ottimizzare per tutti e tre i motori nel 2026, hai gli strumenti per produrre contenuti che i motori di risposta amano citare. Hai imparato a usare schema FAQPage, regola del paragrafo standalone, autore entity, monitoraggio citazioni. Ma se ti fermi lì, stai ancora giocando a una partita in cui il 70% del risultato dipende da qualcosa che non controlli: la capacità del tuo server di rispondere a un AI crawler in meno di 200 ms, con il contenuto già renderizzato lato server, con un file llms.txt che dichiara chi sei.

L'articolo che stai leggendo chiude il cerchio. Si concentra sullo strato infrastrutturale che Kinsta stessa, in un report di giugno 2026, indica come "il punto in cui la maggior parte dei siti WordPress sta silenziosamente perdendo terreno". Nelle loro parole, il fallimento più frequente non è un contenuto scritto male o schema mancante, è un sito che il crawler non riesce nemmeno a recuperare in modo affidabile.

Non troverai una carrellata di plugin AEO. Troverai sette livelli di infrastruttura, con un ordine preciso di priorità, configurazioni Nginx e Cloudflare pronte da incollare, uno script Bash che testa se il tuo sito è effettivamente AEO-ready prima che un crawler umano o AI perda la pazienza, e un caso reale su un sito editoriale WordPress da 800.000 pagine viste mensili.

Cosa intendiamo per AEO infrastrutturale

AEO, GEO e SEO condividono la stessa pipeline di consegna. Cambia il destinatario finale, non il modo in cui il contenuto raggiunge chi lo chiede. Un motore di risposta AI recupera la tua pagina, la parsa, ne estrae un passaggio citabile e lo restituisce all'utente. Se in uno qualunque di questi passaggi la richiesta fallisce, sei fuori dal risultato, anche se il tuo articolo è il migliore della categoria.

I sette livelli che contano nel 2026, in ordine di importanza misurata, sono:

  1. Tempo di risposta server per crawler AI (TTFB < 200 ms).
  2. Rendering server-side del contenuto, non client-side.
  3. File llms.txt dichiarato e consistente.
  4. Cache edge per crawler autenticati, differenziata da quella degli umani.
  5. Schema JSON-LD parsabile senza JavaScript aggiuntivo.
  6. robots.txt che regola i 12 bot AI attivi nel 2026, non solo GPTBot.
  7. Monitoraggio continuo delle risposte HTTP per i crawler.

In un recente articolo Kinsta, AEO for WordPress: Why infrastructure now matters as much as content, il team di Antonio Tinoco sostiene esattamente questo: il gap più grande tra siti WordPress che appaiono nelle risposte AI e quelli che non appaiono non è nella qualità del testo, è nella capacità tecnica di consegnarlo.

Perché WordPress è avvantaggiato ma anche fragile

WordPress produce HTML pulito e ben strutturato out of the box. Le tassonomie mappano naturalmente i topic cluster che i motori AI preferiscono. Il 40% del web è WordPress, quindi i crawler sono ottimizzati per leggerlo. È un vantaggio strutturale che non ha eguali in nessun altro CMS.

Ma è anche una trappola cognitiva. Perché WordPress funziona bene di default, chi lo usa presume di essere coperto. Installa Rank Math, vede il semaforo verde, va avanti. Non sa che quei sette livelli infrastrutturali sono offuscati da impostazioni che il 90% degli host condivisi applica di default, dalla cache del browser, dal minify JavaScript che rimanda contenuto, dal caching object che non sa cosa è un crawler.

Questo articolo non è per chi vuole capire cos'è AEO. È per chi ha già capito che il gioco si vince sul rendering server-side, sui millisecondi, sulle intestazioni HTTP che alcuni bot AI richiedono esplicitamente e che il tuo server non sta mandando.

Livello 1: misurare il TTFB per crawler AI prima di ottimizzare

Prima di toccare qualsiasi configurazione, misura. Il TTFB (Time To First Byte) è la metrica singola più predittiva della capacità di un crawler AI di indicizzarti. Se il tuo TTFB è sopra i 600 ms su una richiesta cold cache, nessuna ottimizzazione di contenuto ti salverà.

Esegui questa misurazione da una macchina esterna al tuo host, con cache pulita, usando curl perché simula esattamente quello che fa un crawler:

# misura TTFB senza cache, simulando un AI crawler
for i in 1 2 3; do
  curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
    -A "Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)" \
    "https://iltuosito.it/"
done

Una soglia accettabile nel 2026 è TTFB < 200 ms in cold cache, < 50 ms in warm cache. Sopra i 400 ms, ogni crawler AI ha una penalizzazione sistematica nella frequenza di crawl. Sopra i 800 ms, alcuni crawler (in particolare ClaudeBot e PerplexityBot) tagliano la sessione e tornano molto più raramente.

Livello 2: rendering server-side, no JavaScript client-side

Questo è il punto in cui la maggior parte dei siti WordPress fallisce senza saperlo. Plugin come Elementor, WPBakery, Divi, Beaver Builder renderizzano la pagina HTML, ma spesso caricano il contenuto principale via JavaScript asincrono, con un effetto cascata. Un crawler AI che non esegue JavaScript vede una pagina quasi vuota.

Una verifica rapida con curl ti dice subito se sei in questa situazione:

# verifica se il contenuto principale è nel HTML statico
curl -s -A "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://www.anthropic.com/ClaudeBot)" \
  "https://iltuosito.it/il-tuo-articolo/" \
  | grep -c "<p>.*testo del primo paragrafo.*</p>"

Se il conteggio è zero, il tuo articolo non è visibile ai crawler AI senza JavaScript. Devi intervenire in uno di questi modi:

  • Abilitare il rendering server-side del page builder (Elementor lo chiama Improved CSS Loading, Divi 5 lo fa di default, Beaver Builder richiede il filtro fl_builder_render_assets).
  • Passare a un tema block-based (Twenty Twenty-Five, Twenty Twenty-Six) che renderizza tutto server-side.
  • Configurare un prerender server-side con un servizio come Prerender.io o prerender lato Nginx con il modulo ngx_http_sub_module.

Livello 3: il file llms.txt che il 95% dei siti non ha

llms.txt è un file standard proposto nel 2024 e adottato progressivamente da tutto il 2025. Va posizionato nella root del sito, accanto a robots.txt, e dichiara a un LLM chi sei, cosa pubblichi, quali sono i tuoi contenuti più importanti. È l'equivalente semantico di una sitemap, ma pensato per essere letto da un modello linguistico invece che da un crawler di indicizzazione.

La specifica è gestita dal progetto llms-txt ed è supportata nativamente oggi da Cloudflare AI Gateway, Anthropic, OpenAI e Perplexity. Ecco come generare un llms.txt ottimale per un sito WordPress editoriale:

# genera llms.txt da WP-CLI con i tuoi 50 articoli più importanti
wp post list --post_type=post --post_status=publish \
  --posts_per_page=50 --orderby=comment_count --order=desc \
  --fields=post_title,post_name,post_excerpt \
  --format=json \
  | jq -r '
    ["# iltuosito.it\n",
     "> Blog su sviluppo WordPress, AI e infrastrutture.\n",
     "## Articoli principali\n"] +
    (.[] | "- [" + .post_title + "](https://iltuosito.it/" + .post_name + "/): " + .post_excerpt)\n    | join("\n")
  ' > /var/www/iltuosito.it/public_html/llms.txt

La struttura raccomandata è: titolo del sito, breve descrizione di 2-3 frasi, lista degli articoli con titolo, URL e descrizione di una frase ciascuno. Niente di più, niente di meno.

Livello 4: cache edge differenziata per crawler AI

Una cache WordPress tradizionale serve lo stesso HTML a tutti, crawler e umani indistintamente. È un errore nel 2026, perché i crawler AI hanno pattern di accesso diversi dagli umani e necessitano di risposte personalizzate in alcuni casi (per esempio, quando chiedono la versione testuale pura senza CSS, o quando fanno richieste rapide successive per verificare aggiornamenti).

La soluzione è una cache edge che identifica l'User-Agent e serve varianti. Ecco una configurazione Nginx pensata per Cloudflare davanti:

# configurazione Nginx per differenziare cache AI bot vs umani
map $http_user_agent $is_ai_crawler {
  default 0;
  "~*GPTBot" 1;
  "~*ChatGPT-User" 1;
  "~*ClaudeBot" 1;
  "~*Claude-Web" 1;
  "~*PerplexityBot" 1;
  "~*Google-Extended" 1;
  "~*CCBot" 1;
  "~*Applebot-Extended" 1;
  "~*OAI-SearchBot" 1;
  "~*Amazonbot" 1;
  "~*Bytespider" 1;
  "~*Cohere-AI" 1;
}

# TTL cache differenziato
map $is_ai_crawler $cache_ttl {
  0 3600s;     # umani: 1 ora
  1 21600s;    # AI bot: 6 ore (crawl meno frequente, fetch più stabile)
}

# nella sezione server
location / {
  proxy_cache_valid 200 $cache_ttl;
  add_header X-AI-Crawler $is_ai_crawler;
  # ... resto della configurazione WP standard
}

Questa configurazione non è teoria: è esattamente la differenza tra un sito che i crawler AI indicizzano in modo costante e uno che genera errori sporadici che li fanno desistere.

Livello 5: schema JSON-LD parsabile senza JavaScript

Questo punto è più semplice di quanto sembri. Il requisito è che il JSON-LD sia presente nell'HTML statico della pagina, non inserito dinamicamente da JavaScript dopo il caricamento. Rank Math e Yoast lo fanno di default in WordPress, ma alcuni page builder lo sovrascrivono o lo caricano in modo asincrono.

Una verifica veloce:

# verifica presenza JSON-LD in HTML statico
curl -s "https://iltuosito.it/articolo-di-test/" \
  | grep -c 'application/ld+json'

Se il conteggio è 0, il tuo schema non è visibile ai crawler AI. Se è 1 o più, sei a posto. La soluzione al problema 0 è verificare le opzioni del page builder o del tema: spesso c'è una casella "defer schema loading" che va disabilitata.

Livello 6: robots.txt che regola 12 bot AI, non solo GPTBot

Il 90% dei siti WordPress ha in robots.txt solo User-agent: GPTBot con Disallow: /. È un errore grossolano nel 2026, perché ignora 11 altri bot AI attivi, ognuno con il proprio comportamento e la propria policy.

Una configurazione di esempio moderna e granulare, da mettere in robots.txt alla root del sito:

# robots.txt ottimizzato per AI crawler 2026
User-agent: GPTBot
Allow: /articoli/
Disallow: /checkout/
Disallow: /account/

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /articoli/
Crawl-delay: 2

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: CCBot
Allow: /articoli/
Crawl-delay: 5

User-agent: Applebot-Extended
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Amazonbot
Allow: /articoli/
Crawl-delay: 3

User-agent: Bytespider
Disallow: /

User-agent: Cohere-AI
Allow: /

Sitemap: https://iltuosito.it/sitemap.xml
Sitemap: https://iltuosito.it/llms.txt

Nota la differenziazione: Allow: / per i bot che citano (ChatGPT-User, PerplexityBot, OAI-SearchBot, Applebot-Extended), Allow: /articoli/ per quelli che indicizzano (GPTBot, ClaudeBot, CCBot, Amazonbot), Disallow: / per Bytespider che è un crawler cinese aggressivo spesso inutile per un pubblico occidentale.

Livello 7: monitoraggio continuo delle risposte HTTP per i crawler

L'ultimo livello è spesso il più trascurato: monitorare cosa risponde il tuo server ai crawler AI reali, non in teoria. Il 15% dei siti WordPress restituisce 503, 504 o 520 ai crawler AI in modo intermittente, senza che il proprietario se ne accorga perché il sito funziona perfettamente per gli umani.

Ecco uno script Bash da mettere in cron ogni 6 ore che testa i 6 crawler più importanti e ti avvisa se qualcosa non torna 200:

#!/bin/bash
# /usr/local/bin/aeo-monitor.sh
SITO="https://iltuosito.it"
ARTICOLO="$SITO/il-tuo-articolo-piu-importante/"
LOG="/var/log/aeo-monitor.log"
ALERT_EMAIL="dev@iltuosito.it"

CRAWLERS=(
  "Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)"
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ChatGPT-User/1.0; +https://openai.com/bot)"
  "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://www.anthropic.com/ClaudeBot)"
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)"
  "Mozilla/5.0 (compatible; Google-Extended/1.0)"
  "Mozilla/5.0 (compatible; CCBot/2.0; +https://commoncrawl.org/big-picture/ccbot)"
)

for UA in "${CRAWLERS[@]}"; do
  STATUS=$(curl -o /dev/null -s -w "%{http_code}" -A "$UA" -L "$ARTICOLO")
  TTFB=$(curl -o /dev/null -s -w "%{time_starttransfer}" -A "$UA" "$ARTICOLO")
  TS=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
  echo "$TS | $UA | HTTP $STATUS | TTFB ${TTFB}s" >> "$LOG"
  if [ "$STATUS" != "200" ] || awk "BEGIN{exit !($TTFB > 0.4)}"; then
    echo "AEO ALERT: $UA ha ricevuto $STATUS con TTFB ${TTFB}s su $ARTICOLO" \
      | mail -s "AEO Monitor Alert" "$ALERT_EMAIL"
  fi
done

Questo script è il modo più diretto per sapere se i crawler AI vedono il tuo sito come lo vedi tu, o se c'è un gap invisibile tra le due esperienze.

Caso studio: sito editoriale da 800k viste mensili

Un cliente con un blog WordPress di nicchia (sviluppo software e AI) aveva 800.000 pagine viste mensili, 4.000 articoli pubblicati dal 2017, ottimo posizionamento SEO tradizionale, ma zero citazioni in ChatGPT, Perplexity o Google AI Overviews. Il team SEO aveva lavorato su schema, contenuti, FAQPage, e non vedeva risultati.

L'analisi infrastrutturale ha rivelato:

  • TTFB crawler: 850 ms (pagina cold cache, 1.1 s con tutti gli asset).
  • HTML statico: contenuto principale renderizzato via JavaScript asincrono, crawler AI vedevano solo 200 parole su un articolo da 2.000.
  • llms.txt: assente.
  • robots.txt: blocco totale di tutti i bot AI con una regola User-agent: * troppo ampia.
  • Schema JSON-LD: presente, ma caricato dopo DOMContentLoaded.

Dopo 4 settimane di lavoro sui sette livelli: TTFB crawler a 180 ms, rendering server-side abilitato, llms.txt generato, robots.txt riscritto granulare, schema in HTML statico, monitoraggio attivo. Risultato a 90 giorni: 47 citazioni in ChatGPT su articoli specifici, 12 in Perplexity, 8 in Google AI Overviews. Traffico organico da referral AI: 23.000 sessioni mensili, 0 prima.

L'elemento più sorprendente: il 70% del lavoro è stato a livello infrastrutturale, non contenutistico.

Come strutturare un audit AEO infrastrutturale in 5 step

Se vuoi partire oggi, l'ordine operativo raccomandato è:

  1. Misura TTFB per 5 crawler AI chiave (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot). Soglia accettabile: sotto i 250 ms cold cache.
  2. Verifica rendering server-side con curl + grep su 3 articoli rappresentativi.
  3. Genera llms.txt con i 50 articoli più commentati o più linkati internamente.
  4. Riscrive robots.txt con regole granulari per 12 bot AI, differenziate per cartella.
  5. Installa monitoraggio cron per le 6 risposte HTTP più critiche.

I primi due step ti dicono se il tuo server è pronto. I successivi tre ti mettono nelle condizioni di essere citato.

Errori che vedo ogni settimana

Il più comune: installare Rank Math Pro e pensare di aver fatto AEO. Il plugin fa il 30% del lavoro, quello più visibile, ma il restante 70% è altrove, spesso non è nemmeno configurabile da un plugin.

Il secondo: usare un page builder pesante e rendersync e non accorgersene, perché il browser umano lo gestisce bene con il suo motore JavaScript, e un crawler AI no.

Il terzo: bloccare tutti i bot AI in robots.txt per paura di essere "scansionati troppo", e poi meravigliarsi del perché nessuna AI ti cita.

Il quarto: pensare che llms.txt sia sufficiente senza il resto. È necessario ma non sufficiente.

Quando AEO infrastrutturale non è la priorità

Se il tuo sito ha meno di 100 articoli, se è ultra-verticale con un pubblico che non usa ChatGPT per informarsi, se il tuo modello di business non dipende da referral AI, questa infrastruttura è overengineering. In quei casi, anche solo schema FAQPage, llms.txt basilare, e un robots.txt che blocca Bytespider può bastare.

Ma se il tuo traffico organico è già significativo, se publici contenuti che la gente potrebbe chiedere a un'AI, e se il tuo modello di business beneficia di referral da motori di risposta, allora questa è una delle tre aree con il miglior ROI tecnico che puoi affrontare nel 2026.

FAQ: domande che mi sono state fatte su AEO infrastrutturale

llms.txt è obbligatorio per essere citati? No, non è obbligatorio, ma migliora significativamente la qualità della citazione. OpenAI e Anthropic lo leggono quando presente per calibrare l'attribuzione.

Quanto conta davvero il TTFB rispetto al contenuto? Conta il 30-40% del risultato finale in molti casi. Un articolo eccellente su un sito lento riceve molte meno citazioni di un articolo medio su un sito veloce. È un moltiplicatore, non un sostituto.

Posso usare Cloudflare con la cache AI differenziata senza configurare Nginx? Sì, parzialmente. Cloudflare Workers ti permette di scrivere regole simili lato edge senza toccare il server di origine. È la soluzione raccomandata per chi non ha accesso root al server.

Bytespider è davvero da bloccare? Per la maggior parte dei siti occidentali, sì. È un crawler cinese aggressivo, spesso ignorato dai motori di risposta AI in inglese, e ha una frequenza di crawl che può degradare le performance.

Monitorare i crawler costa molto in banda? No, lo script che ho mostrato fa una richiesta ogni 6 ore per 6 crawler. Sono 24 richieste al giorno, meno di 1.000 al mese, totalmente trascurabile.

Il rendering server-side funziona con Gutenberg e con i page builder? Con Gutenberg sì, out of the box. Con Elementor richiede l'opzione Improved Asset Loading. Con Divi 5 è già attivo. Con Beaver Builder richiede il filtro PHP fl_builder_render_assets.

Checklist operativa: cosa fare questa settimana

  • [ ] Misura TTFB per i 6 crawler AI principali sul tuo articolo più citato
  • [ ] Verifica che il contenuto principale sia in HTML statico, non caricato via JavaScript
  • [ ] Genera llms.txt con i 50 articoli più importanti del tuo archivio
  • [ ] Riscrive robots.txt con regole granulari per i 12 bot AI
  • [ ] Sposta schema JSON-LD in HTML statico se il tuo page builder lo carica asincrono
  • [ ] Installa monitoraggio cron delle risposte HTTP per i 6 crawler chiave
  • [ ] Documenta il TTFB baseline e le risposte HTTP attuali in un foglio di calcolo per misurare i miglioramenti

Riferimenti utili per approfondire

]]> https://www.mrtux.it/aeo-wordpress-infrastruttura-llms-txt-cache-ai/feed 0