robots.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 robots.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