Cosa fa davvero uno checker robots.txt
Uno checker robots.txt recupera il file /robots.txt dal tuo dominio, parsa ogni blocco user-agent e regola disallow, poi testa se un dato percorso è consentito o bloccato per uno specifico crawler. Applica la regola con il matching più lungo quando più pattern si sovrappongono, segue l'ordine di precedenza nella specifica e segnala se un URL di test verrebbe crawlato.
La maggior parte dei crawler cerca prima il proprio blocco user-agent. Se esiste, usano quelle regole. Se no, ricadono nel blocco wildcard User-agent: *. Questo significa che un sito può consentire a Googlebot di accedere a /admin mentre blocca tutti gli altri bot. Il nostro checker simula questa cascata per qualsiasi user-agent tu scelga dal menu a tendina User-agent to test.
Due errori comuni infrangono i file robots.txt silenziosamente. Il primo è errori di sintassi: spazi extra, due punti mancanti, line ending Windows o "Disallow" maiuscolo quando funziona solo minuscolo. Il secondo è regole conflittuali—linee allow e disallow che si sovrappongono, lasciando ambiguo se un percorso è bloccato. Il nostro checker segnala entrambi e mostra quale regola vince.
Come usare questo checker robots.txt
- Incolla il tuo dominio completo in Site URL. Recuperiamo automaticamente
yourdomain.com/robots.txt. Non è necessario digitare/robots.txt. - Scegli un User-agent to test dal menu a tendina. Googlebot, Bingbot, GPTBot, ClaudeBot, CCBot, PerplexityBot, anthropic-ai o * per wildcard. Questa è l'identità del crawler che simuliamo.
- Incolla un percorso in Test path se vuoi controllare un URL specifico. Lascialo vuoto per vedere l'intero ruleset parsato. Un percorso è del tipo
/admino/blog/post-slug. - Clicca Check robots.txt. Ottieni il file parsato, regole per-agent, link sitemap, crawl-delay se impostato e un verdetto per il tuo percorso di test.
- Espandi Rule conflicts se righe sono segnalate. Mostriamo linee allow/disallow sovrapposte e ti diciamo quale seguirebbe un crawler reale.
Prova a testare yourdomain.com con User-agent impostato a GPTBot e Test path impostato a /blog. Se il tuo robots.txt non ha un blocco GPTBot ma disallowa tutti i bot da /admin, il blog è consentito e admin è bloccato. Cambia l'user-agent a ClaudeBot e il risultato potrebbe cambiare se hai un blocco specifico per ClaudeBot.
Perché testare per user-agent è importante
I crawler di ricerca non sono più gli unici bot che leggono robots.txt. I crawler di training AI—GPTBot di OpenAI, ClaudeBot di Anthropic, CCBot di Common Crawl, PerplexityBot e Google-Extended—ora rispettano robots.txt per decidere se possono scrapare il tuo contenuto per il training del modello. Se li blocchi, le tue pagine rimangono fuori dai dataset di training. Se li consenti, opt-in.
Tre conseguenze pratiche.
Chiarezza della policy. Un robots.txt che dice User-agent: * / Disallow: / blocca tutti, incluso Google. Se non è tua intenzione, hai bisogno di blocchi separati per agent. Testare per user-agent rivela cosa vede ogni bot prima che un modello si alleni sul tuo contenuto.
Controllo dei crawler AI. Nel 2026, la maggior parte dei proprietari di siti vuole i bot di ricerca dentro ma i bot di training fuori. Questo richiede blocchi espliciti disallow per GPTBot, ClaudeBot e CCBot. I competitor ignorano questi agent. Li testiamo di default perché contano.
Rilevamento dei conflitti. Quando hai sia Disallow: /blog che Allow: /blog/public, la regola più specifica vince. Ma parsare a mano quale regola è più lunga o più specifica è soggetto a errori. Testare ti mostra esattamente cosa farebbe un bot, non quello che pensi dica il file.
Precedenza delle regole e wildcard
La specifica robots.txt definisce un ordine di precedenza quando più regole corrispondono allo stesso percorso. La regola con il prefisso corrispondente più lungo vince. Se due regole hanno la stessa lunghezza, la regola allow vince su disallow.
I wildcard rendono questo più difficile da vedere. Una linea come Disallow: /admin* blocca /admin, /admin/users e /admin-panel. Una linea successiva Allow: /admin/public la scavalca per quella cartella perché /admin/public è più lunga di /admin. Il nostro checker valuta entrambe e ti dice quale si applica.
Il wildcard $ ancora la fine di un percorso. Disallow: /*.pdf$ blocca tutti i file PDF ma consente /report.pdf.html perché il percorso non finisce in .pdf. I competitor spesso parsano $ male o lo ignorano. Corrisponiamo all'implementazione Google.
Il nome dell'user-agent è case-insensitive nella specifica, quindi User-agent: googlebot e User-agent: Googlebot sono identici. I percorsi Disallow sono case-sensitive sulla maggior parte dei server. /Admin e /admin sono URL diversi. Il nostro checker rispetta entrambe le regole.
Validazione sitemap e direttive di crawl
Ogni file robots.txt dovrebbe includere almeno una linea Sitemap: che punta al tuo file sitemap.xml. Questo dice ai crawler dove trovare l'elenco degli URL che vuoi indicizzati. Il nostro checker recupera ogni URL sitemap elencato nel tuo robots.txt e riporta il codice di stato HTTP. Se un sitemap restituisce 404, i crawler non possono usarlo e perdi un segnale che aiuta con la discovery.
Più dichiarazioni sitemap sono valide. Se hai sitemap separati per post, pagine e prodotti, elenca tutti e tre. Se usi un sitemap index che riferisce sitemap figli, elenca solo l'index. Evita di elencare ogni sitemap figlio individualmente perché ingombra il file e duplica informazioni già nell'index.
La direttiva Crawl-delay: imposta i secondi minimi che un bot dovrebbe aspettare tra le richieste al tuo server. Googlebot ignora completamente questa direttiva e usa il suo tasso di crawl adattivo basato sul tempo di risposta del server. Bingbot, Yandex e alcuni crawler più piccoli la rispettano. Un crawl-delay di 1 secondo è sicuro. Un ritardo di 10 o superiore ferma effettivamente la maggior parte dei crawling su siti grandi. Usalo solo se il tuo server non riesce a gestire tassi di crawl normali.
Una direttiva meno comune è Request-rate:, che imposta un numero di richieste per finestra temporale. Pochi crawler la supportano e non è parte della specifica ufficiale. Se la vedi in un robots.txt, è probabilmente legacy o non-standard. Il nostro checker la nota ma non la applica perché il comportamento del crawler varia.
Errori di sintassi e edge case di validazione
La sintassi robots.txt è spietata. Un singolo spazio o tab fuori posto può invalidare una regola. Il nome della direttiva—User-agent, Disallow, Allow, Sitemap, Crawl-delay—deve essere seguito da due punti senza spazio prima e almeno uno spazio o tab dopo. Disallow:/admin fallisce. Disallow: /admin funziona. Il nostro checker segnala problemi di spaziatura e suggerisce correzioni.
I line ending Windows—\r\n invece di \n—causano problemi su alcuni server. Quando un file robots.txt è editato su Windows e caricato senza conversione, i bot possono leggere male i line break e trattare più linee come una. Il nostro checker rileva line ending non-Unix e li riporta come avviso.
I commenti in robots.txt iniziano con #. Tutto dopo il # su quella linea è ignorato. Un errore comune è commentare accidentalmente una direttiva: # Disallow: /admin non fa nulla. Se vedi regole che dovrebbero applicarsi ma non lo fanno, controlla i caratteri # vaganti.
Le linee vuote separano i blocchi user-agent. Una linea vuota termina il blocco attuale e il prossimo User-agent: inizia uno nuovo. Se hai User-agent: Googlebot, Disallow: /private, poi una linea vuota, poi Allow: /public, la regola allow non si applica a Googlebot—inizia un nuovo blocco senza user-agent, il che non è valido. Il nostro checker segnala direttive orfane e suggerisce di raggrupparle sotto l'user-agent corretto.
Errori comuni
- Bloccare Googlebot accidentalmente. Un blocco
User-agent: *conDisallow: /blocca ogni bot, incluso Google. Se vuoi Google dentro, aggiungi un blocco separatoUser-agent: GooglebotconAllow: /prima del blocco wildcard. L'ordine conta. - Dimenticare la barra iniziale.
Disallow: adminnon fa nulla. Deve essereDisallow: /admin. Il nostro checker lo segnala come probabile errore di sintassi. - Testare solo Googlebot. Il tuo robots.txt potrebbe consentire Google ma bloccare Bingbot o GPTBot senza che te ne accorga. Testa tutti gli agent che ti interessano, non solo uno.
- Lasciare fuori i crawler AI. Se il tuo file non ha un blocco GPTBot o ClaudeBot, quei bot ricadono in
User-agent: *. Quello potrebbe consentirgli quando pensavi che tutto fosse bloccato. I blocchi espliciti per-agent rendono la policy inequivocabile. - Assumere che i link sitemap siano validati altrove. Un URL sitemap in robots.txt può essere rotto, restituire 404 o puntare a un file XML che non esiste più. Il nostro checker testa il link e riporta il codice di stato.
Suggerimenti avanzati
- Testa lo stesso percorso contro più user-agent in sequenza. Se il risultato cambia, i tuoi blocchi per-agent funzionano. Se rimane lo stesso, potresti fare affidamento solo sul blocco wildcard.
- Controlla la linea Crawl-delay se presente. Googlebot l'ignora, ma Bingbot e altri la rispettano. Un ritardo di 10 secondi può rallentare un crawl quasi a un arresto su siti grandi.
- Guarda le linee Sitemap. Più dichiarazioni sitemap sono valide. Se hai un sitemap index, elencalo una volta invece di ripetere ogni sub-sitemap. Recuperiamo ogni link e confermiamo che restituisca HTTP 200.
- Testa un percorso con parametri di query.
Disallow: /searchblocca/search?q=testsulla maggior parte dei server, maDisallow: /search$no perché$si aspetta nessun carattere finale. Se vuoi bloccare query string, usa l'asterisco:Disallow: /search*. - Scarica l'output parsato come riferimento. Quando rigeneri robots.txt o cambi CMS, ri-controlla contro gli stessi percorsi di test per confermare che il comportamento non sia cambiato.
- Usa il report di conflitto prima di deployare un nuovo robots.txt. Se due regole si sovrappongono, la tua interpretazione locale potrebbe differire da quella di Googlebot. Testare rimuove il mistero.
Se hai bisogno di generare un nuovo file robots.txt da zero con preset per WordPress, Shopify o Next.js, usa il nostro generatore di file robots.txt. Include toggle espliciti per crawler AI e produce un file pronto per la produzione con sintassi garantita valida. Dopo il deployment, ri-controllalo con questo strumento. Se vuoi vedere come Googlebot renderizza la pagina dopo aver rispettato robots.txt e aver eseguito JavaScript, il simulatore di crawler Google mostra l'HTML esatto e il testo visibile che un bot indicizza. Per confermare che ogni URL nel tuo sitemap è raggiungibile e restituisce 200, usa lo checker sitemap.