Verifica le regole del file robots.txt per qualsiasi crawler

Il file robots.txt è il primo punto di contatto tra un sito web e i crawler che lo visitano. Quando un bot come Googlebot o GPTBot arriva su un dominio, cerca questo file nella root (ad esempio, https://www.example.it/robots.txt) per capire quali pagine può o non può scansionare. Ma come fa il crawler a interpretare correttamente le regole? La risposta sta nella struttura a gruppi e nella logica di selezione del User-agent.

Un file robots.txt è organizzato in blocchi chiamati gruppi, ognuno dei quali inizia con una o più righe User-agent che specificano a quali crawler si applicano le regole successive. Ad esempio, un gruppo potrebbe iniziare con User-agent: Googlebot e contenere le direttive Disallow e Allow valide solo per quel bot. Un altro gruppo potrebbe usare User-agent: * per rivolgersi a tutti i crawler non esplicitamente menzionati.

La scelta del gruppo corretto segue una gerarchia precisa: il crawler cerca prima un gruppo che corrisponda esattamente al suo User-agent (ad esempio, Googlebot-Image). Se non lo trova, cerca il token padre (Googlebot). Solo se neppure questo esiste, il crawler si rivolge al gruppo *. È importante notare che un gruppo specifico sostituisce completamente il gruppo *, non si aggiunge ad esso. Questo significa che se un file contiene sia User-agent: Googlebot che User-agent: *, Googlebot ignorerà le regole del gruppo * e seguirà solo quelle del suo gruppo dedicato.

Un esempio pratico chiarisce meglio il concetto. Supponiamo di avere questo file robots.txt:

User-agent: *
Disallow: /private/

User-agent: Googlebot
Allow: /private/report.pdf

In questo caso, Googlebot potrà accedere a /private/report.pdf perché il gruppo Googlebot ha la precedenza sul gruppo *. Tutti gli altri crawler, invece, saranno bloccati dalla direttiva Disallow: /private/. Questa logica è fondamentale per evitare errori comuni, come pensare che le regole del gruppo * si applichino anche ai crawler specifici.

Per verificare come un crawler interpreterà le regole del tuo file, puoi usare il generatore di regole per crawler AI per scrivere le direttive e poi testarle con il Tester robots.txt, che simula il comportamento dei bot secondo lo standard RFC 9309.

Una delle regole fondamentali per interpretare correttamente un file robots.txt è quella del longest match wins, ovvero "il match più lungo vince". Questo principio determina quale direttiva Allow o Disallow viene applicata quando più regole potrebbero teoricamente corrispondere a un percorso. La logica è semplice: tra tutte le regole che matchano un URL, vince quella con il pattern più lungo. Se due regole hanno la stessa lunghezza, prevale la direttiva Allow.

Per capire meglio, consideriamo un esempio pratico. Supponiamo di avere questo file robots.txt:

User-agent: *
Disallow: /blog/
Allow: /blog/2024/

Se un crawler prova ad accedere a /blog/2024/articolo.html, entrambe le regole potrebbero applicarsi: /blog/ e /blog/2024/. Tuttavia, poiché /blog/2024/ è più lungo di /blog/, vince la direttiva Allow, e il crawler potrà accedere alla pagina. Se invece il percorso fosse /blog/archivio/, solo la regola Disallow: /blog/ farebbe match, bloccando l’accesso.

Un altro aspetto importante riguarda i caratteri jolly * e l’ancora finale $. Il carattere * funziona come wildcard, matchando qualsiasi sequenza di caratteri. Ad esempio, Disallow: /*.pdf blocca tutti i file PDF, indipendentemente dalla loro posizione. L’ancora $, invece, indica la fine di un percorso. Quindi, Disallow: /*.pdf$ blocca solo i file che terminano con .pdf, ma non quelli che contengono .pdf seguito da altri caratteri (come /documento.pdf?id=123).

Ecco una tabella riassuntiva con alcuni esempi di matching:

Questa logica può sembrare semplice, ma è facile commettere errori, soprattutto quando si combinano regole generiche e specifiche. Per evitare problemi, è utile testare il file robots.txt con uno strumento come il Tester robots.txt, che mostra esattamente quale regola viene applicata per ogni URL e perché. In questo modo, puoi correggere eventuali incongruenze prima di pubblicare il file sul tuo sito.

Negli ultimi anni, l’ascesa dei modelli di intelligenza artificiale ha portato alla nascita di nuovi crawler specializzati, come GPTBot (OpenAI), ClaudeBot (Anthropic) e Google-Extended. Questi bot scansionano il web per raccogliere dati utili ad addestrare i loro modelli, ma molti editori e proprietari di siti vogliono avere il controllo su quali contenuti condividere. Il file robots.txt è lo strumento principale per gestire questo accesso, ma come si fa a verificare che le regole funzionino correttamente per i crawler AI?

Il Tester robots.txt è uno strumento gratuito che permette di simulare il comportamento di qualsiasi crawler, compresi quelli AI, senza bisogno di pubblicare il file sul sito. Basta incollare il contenuto del robots.txt, inserire il token del crawler (ad esempio, GPTBot o ClaudeBot) e una lista di URL da testare. Lo strumento restituirà un verdetto per ogni percorso, indicando se è permesso o bloccato, insieme alla regola che ha determinato la decisione e il numero di riga corrispondente.

Un aspetto interessante dei crawler AI è la direttiva Content-Signal, introdotta per specificare l’uso previsto dei contenuti. Questa direttiva può assumere tre valori: - search: i contenuti sono destinati alla ricerca tradizionale (ad esempio, Google Search). - ai-input: i contenuti possono essere usati come input per modelli AI, ma non per l’addestramento. - ai-train: i contenuti possono essere usati anche per l’addestramento dei modelli.

Ad esempio, una regola come Content-Signal: ai-input indica che il crawler può accedere ai contenuti, ma solo per scopi di input, non per l’addestramento. È importante sottolineare che il Tester robots.txt riporta il valore di Content-Signal, ma non ne verifica l’applicazione: spetta ai crawler rispettare queste preferenze.

Per i siti italiani, questa funzionalità è particolarmente utile. Ad esempio, un giornale online potrebbe voler permettere a Googlebot di accedere a tutti gli articoli (Content-Signal: search), ma limitare GPTBot solo a una selezione di contenuti (Content-Signal: ai-input). Con il Tester robots.txt, puoi verificare che le regole siano scritte correttamente prima di pubblicarle, evitando errori che potrebbero esporre contenuti sensibili o riservati.

Se stai iniziando a scrivere le regole per i crawler AI, il generatore di regole per crawler AI può aiutarti a creare un file robots.txt ben strutturato, che potrai poi testare con il Tester robots.txt per assicurarti che funzioni come previsto.

Anche se il file robots.txt sembra semplice, è facile commettere errori che possono compromettere l’accesso dei crawler al sito o esporre contenuti che si vorrebbero proteggere. Il Tester robots.txt segnala molti di questi problemi, aiutando a correggerli prima che causino danni. Ecco alcuni degli errori più comuni e come evitarli.

Uno dei problemi più frequenti è l’uso di regole prima di qualsiasi direttiva User-agent. Secondo lo standard RFC 9309, tutte le regole devono appartenere a un gruppo, che inizia con User-agent. Se una direttiva come Disallow: /private/ appare prima di qualsiasi User-agent, i crawler la ignoreranno, lasciando accessibili percorsi che si volevano bloccare. Ad esempio, questo file è errato:

Disallow: /private/
User-agent: *
Disallow: /tmp/

La prima riga Disallow: /private/ non ha effetto, perché non appartiene a nessun gruppo. La soluzione è semplice: assicurarsi che ogni regola sia preceduta da almeno una riga User-agent.

Un altro errore comune riguarda i percorsi relativi. Tutte le direttive Allow e Disallow devono iniziare con /. Scrivere Disallow: private/ invece di Disallow: /private/ è un errore, perché i crawler non riconoscono il percorso come assoluto. Il Tester robots.txt segnala questi casi, permettendo di correggerli rapidamente.

La direttiva Crawl-delay è un altro punto critico. Sebbene alcuni crawler la supportino (come Bing), Google la ignora completamente. Se il tuo obiettivo è limitare la frequenza di scansione da parte di Googlebot, Crawl-delay non è la soluzione: devi usare le impostazioni di Crawl Rate nella Google Search Console. Il Tester robots.txt segnala la presenza di Crawl-delay come avvertimento, perché potrebbe non avere l’effetto desiderato.

Altri problemi comuni includono l’uso di direttive specifiche per alcuni crawler, come Host (usata da Yandex) o Clean-param (un’estensione di Yandex per rimuovere parametri dalle URL). Queste direttive non sono standard e vengono ignorate da molti crawler, ma il Tester robots.txt le segnala per evitare confusione. Anche la direttiva Noindex, sebbene talvolta usata nei file robots.txt, non è supportata da Google e non ha alcun effetto sul crawling o sull’indicizzazione.

Un errore concettuale diffuso è confondere il blocco del crawling con la rimozione dall’indice. Bloccare un URL nel robots.txt impedisce ai crawler di accedervi, ma non lo rimuove dai risultati di ricerca. Se un URL è già indicizzato e poi viene bloccato, potrebbe rimanere nei risultati di Google per mesi, anche se i crawler non possono più visitarlo. Per rimuovere un URL dall’indice, è necessario usare lo strumento Rimozione URL nella Google Search Console o aggiungere un meta tag noindex alla pagina.

Infine, è importante ricordare che i percorsi nel robots.txt sono case-sensitive. Ad esempio, Disallow: /Private/ non blocca l’accesso a /private/, perché le lettere maiuscole e minuscole sono considerate diverse. Questo dettaglio può causare problemi su server che non distinguono tra maiuscole e minuscole (come molti server Windows), ma i crawler seguono lo standard RFC 9309, che richiede il matching esatto.

Per evitare questi errori, è fondamentale testare il file robots.txt prima di pubblicarlo. Il Tester robots.txt è uno strumento ideale per questo scopo, perché segnala problemi di sintassi, percorsi relativi e direttive non standard, permettendoti di correggere tutto in pochi minuti.

Il Tester robots.txt è uno strumento potente per verificare come i crawler interpreteranno le regole del tuo file, ma ha dei limiti ben definiti. Comprenderli è fondamentale per usarlo in modo efficace e sapere quando rivolgersi ad altre soluzioni.

Innanzitutto, il Tester robots.txt non recupera il file robots.txt dal tuo sito. Funziona solo con il testo che incolli manualmente. Questo significa che puoi testare una bozza o un file non ancora pubblicato, ma non puoi verificare la versione attualmente online. Se vuoi controllare il file effettivamente servito dal tuo server, devi scaricarlo manualmente (ad esempio, visitando https://www.tuosito.it/robots.txt) e incollarlo nello strumento. Questa caratteristica è utile per testare modifiche prima di metterle in produzione, ma non sostituisce un controllo diretto del file live.

Un altro limite importante è che il Tester robots.txt non verifica lo stato di indicizzazione delle pagine. Può dirti se un URL è bloccato o permesso secondo le regole del file, ma non se quella pagina è presente nell’indice di Google o di altri motori di ricerca. Ad esempio, se blocchi un URL nel robots.txt, il Tester ti confermerà che i crawler non potranno accedervi, ma non ti dirà se quella pagina è già stata indicizzata in passato. Per questo tipo di verifica, devi usare la Google Search Console o strumenti come il site:tusito.it nella ricerca di Google.

Il Tester robots.txt non normalizza le URL con percent-encoding. Se incolli un percorso come /pagina%20con%20spazi/, lo strumento lo tratterà letteralmente, senza convertirlo in /pagina con spazi/. Questo può portare a discrepanze tra il test e il comportamento reale dei crawler, che tipicamente normalizzano le URL prima di applicare le regole. Per evitare problemi, è consigliabile incollare i percorsi nella loro forma decodificata.

Un altro aspetto da considerare è che il Tester robots.txt non simula il comportamento esatto di tutti i crawler. Segue lo standard RFC 9309 e le estensioni comuni (come * e $), ma alcuni crawler potrebbero avere comportamenti diversi in casi particolari. Ad esempio, Bing potrebbe interpretare Crawl-delay in modo diverso da Google, e alcuni crawler meno conosciuti potrebbero non supportare il carattere jolly *. Lo strumento fornisce una simulazione fedele per i crawler principali (Googlebot, GPTBot, ecc.), ma non può garantire un comportamento identico per tutti i bot esistenti.

Infine, il Tester robots.txt funziona interamente nel browser, senza inviare dati a server esterni. Questo significa che puoi usarlo anche con file sensibili o bozze private, senza preoccuparti della privacy. Tuttavia, non offre funzionalità avanzate come il monitoraggio continuo del file robots.txt o l’integrazione con altri strumenti SEO. Per queste esigenze, potresti dover combinare il Tester robots.txt con altri strumenti, come la Google Search Console (per verificare il file live e gli errori di crawling) o il generatore di chiavi di autenticazione per bot, se hai bisogno di verificare l’identità dei crawler che visitano il tuo sito.

In sintesi, il Tester robots.txt è uno strumento ideale per testare bozze, verificare regole specifiche e diagnosticare problemi di sintassi, ma non sostituisce una strategia completa di gestione del crawling e dell’indicizzazione. Usalo come parte di un workflow più ampio, che includa anche la verifica del file live e il monitoraggio dello stato di indicizzazione delle pagine.

Quando usi il Tester robots.txt, lo strumento restituisce una serie di informazioni per ogni URL testato. Sapere come leggere questi risultati è fondamentale per capire se le regole del tuo file robots.txt funzionano come previsto e, in caso contrario, dove intervenire.

Per ogni percorso inserito, il Tester robots.txt mostra un verdetto (Permesso o Bloccato), seguito da tre informazioni chiave: la regola decisiva, il gruppo applicato e il numero di riga. Ad esempio, se testiamo l’URL /blog/2024/articolo con un file che contiene:

User-agent: *
Disallow: /blog/

User-agent: Googlebot
Allow: /blog/2024/

Il risultato sarà: - Verdetto: Permesso - Regola decisiva: Allow: /blog/2024/ (riga 6) - Gruppo applicato: Googlebot

Questo indica che Googlebot può accedere alla pagina perché la regola Allow: /blog/2024/ (più lunga di Disallow: /blog/) ha la precedenza. Se invece testassimo lo stesso URL con un crawler diverso (ad esempio, Bingbot), il risultato sarebbe Bloccato, perché Bingbot non ha un gruppo dedicato e segue le regole del gruppo *.

Un altro elemento importante nei risultati è il valore di Content-Signal, se presente nel gruppo applicato. Ad esempio, se il file contiene:

User-agent: GPTBot
Disallow: /private/
Content-Signal: ai-input

Il Tester robots.txt riporterà Content-Signal: ai-input nei risultati, indicando che GPTBot può accedere ai contenuti non bloccati, ma solo per scopi di input, non per l’addestramento. Ricorda che questa direttiva è solo informativa: spetta ai crawler rispettarla.

Lo strumento segnala anche eventuali avvertimenti relativi alla sintassi del file. Ad esempio, se il file contiene una direttiva Crawl-delay o un percorso relativo (come Disallow: private/), il Tester robots.txt lo evidenzierà con un messaggio di warning. Questi avvertimenti non impediscono il funzionamento dello strumento, ma indicano potenziali problemi che potrebbero causare comportamenti inattesi nei crawler reali.

Infine, il Tester robots.txt elenca tutte le righe Sitemap presenti nel file. Queste direttive non influenzano il crawling, ma sono utili per segnalare ai motori di ricerca la posizione della sitemap XML del sito. Ad esempio, se il file contiene Sitemap: https://www.tuosito.it/sitemap.xml, questa informazione verrà riportata nei risultati, anche se non ha alcun effetto sul verdetto di Permesso o Bloccato.

Per esportare i risultati, puoi usare le opzioni CSV o Immagine. Il formato CSV è utile per analisi approfondite o per condividere i risultati con il team, mentre l’immagine può essere comoda per documentare rapidamente i test. In entrambi i casi, i dati esportati includono tutte le informazioni mostrate nello strumento, permettendoti di conservare una traccia delle verifiche effettuate.

Con la diffusione dei modelli di intelligenza artificiale, sempre più siti si trovano a dover gestire l’accesso di crawler come GPTBot (OpenAI), ClaudeBot (Anthropic) o Google-Extended. Questi bot scansionano il web per raccogliere dati utili ad addestrare i loro modelli, ma non tutti i contenuti sono adatti a questo scopo. Il file robots.txt è lo strumento principale per controllare quali pagine possono essere visitate dai crawler AI, ma scrivere regole efficaci richiede una comprensione chiara delle loro caratteristiche e delle direttive disponibili.

I crawler AI si comportano come qualsiasi altro bot: cercano il file robots.txt nella root del sito e seguono le regole che li riguardano. Tuttavia, hanno alcune peculiarità. Ad esempio, GPTBot si identifica con il token GPTBot, mentre ClaudeBot usa ClaudeBot. Se il tuo file robots.txt non contiene regole specifiche per questi crawler, essi seguiranno le direttive del gruppo *. Questo significa che, se vuoi limitare l’accesso solo a determinati contenuti, devi creare un gruppo dedicato.

Ecco un esempio di come gestire GPTBot in un file robots.txt:

User-agent: GPTBot
Disallow: /private/
Allow: /public/
Content-Signal: ai-input

In questo caso, GPTBot può accedere solo ai contenuti nella cartella /public/, mentre tutti gli altri percorsi sono bloccati. La direttiva Content-Signal: ai-input indica che i contenuti accessibili possono essere usati come input per i modelli AI, ma non per l’addestramento. Se volessi permettere anche l’addestramento, dovresti usare Content-Signal: ai-train.

Un aspetto importante da considerare è che i crawler AI possono avere un impatto significativo sulle risorse del server. Ad esempio, GPTBot può generare un traffico elevato, soprattutto su siti con molti contenuti. Per questo motivo, alcuni editori scelgono di limitare l’accesso solo a una parte del sito o di bloccare completamente i crawler AI. Tuttavia, è importante ricordare che bloccare un crawler nel robots.txt non impedisce necessariamente l’uso dei contenuti: se un modello AI è già stato addestrato su quei dati, il blocco avrà effetto solo sulle future scansioni.

Per i siti italiani, la gestione dei crawler AI può essere particolarmente rilevante. Ad esempio, un giornale online potrebbe voler permettere a Googlebot di accedere a tutti gli articoli (Content-Signal: search), ma limitare GPTBot solo a una selezione di contenuti (Content-Signal: ai-input). Oppure, un sito di e-commerce potrebbe bloccare completamente i crawler AI per proteggere i dati dei prodotti e le descrizioni uniche.

Per scrivere regole efficaci, puoi usare il generatore di regole per crawler AI, che ti aiuta a creare un file robots.txt ben strutturato. Una volta scritto il file, puoi testarlo con il Tester robots.txt per verificare che i crawler AI siano bloccati o permessi secondo le tue intenzioni. Ad esempio, puoi inserire percorsi come /articoli/2024/ o /prodotti/ e vedere se GPTBot o ClaudeBot possono accedervi.

Infine, è utile ricordare che il file robots.txt non è l’unico strumento per gestire l’accesso dei crawler AI. Alcuni siti usano anche il file llms.txt, un formato emergente per specificare le preferenze di accesso in modo più dettagliato. Se vuoi esplorare questa opzione, puoi usare il generatore di llms.txt per creare un file che lavori in sinergia con il robots.txt.