Skip to content
Controllo in tempo reale · scarica il tuo URL lato server

Robots.txt Checker

Analizza, testa per user-agent (inclusi GPTBot/ClaudeBot), rileva conflitti di regole.

Un file robots.txt dice ai crawler quali pagine possono e non possono accedere. La maggior parte dei validatori testa un bot e si ferma. Questo checker robots.txt testa per user-agent, includendo i crawler AI che contano nel 2026—GPTBot, ClaudeBot e PerplexityBot—rileva conflitti tra regole quando si applicano più direttive e convalida se i tuoi link sitemap esistono effettivamente.

Generate the whole content, not just check it.

BlazeHive writes SEO articles end to end from a single keyword. Outline, draft, meta, schema, internal links. Free trial, no card.

Start with BlazeHive Free trial

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

  1. Incolla il tuo dominio completo in Site URL. Recuperiamo automaticamente yourdomain.com/robots.txt. Non è necessario digitare /robots.txt.
  2. 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.
  3. Incolla un percorso in Test path se vuoi controllare un URL specifico. Lascialo vuoto per vedere l'intero ruleset parsato. Un percorso è del tipo /admin o /blog/post-slug.
  4. 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.
  5. 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: * con Disallow: / blocca ogni bot, incluso Google. Se vuoi Google dentro, aggiungi un blocco separato User-agent: Googlebot con Allow: / prima del blocco wildcard. L'ordine conta.
  • Dimenticare la barra iniziale. Disallow: admin non fa nulla. Deve essere Disallow: /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: /search blocca /search?q=test sulla maggior parte dei server, ma Disallow: /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.

Generate the whole content, not just check it.

BlazeHive writes SEO articles end to end from a single keyword. Outline, draft, meta, schema, internal links. Free trial, no card.

Start with BlazeHive Free trial

Domande frequenti

Cos'è un file robots.txt?

Un file robots.txt è un file di testo semplice alla radice del tuo dominio che dice ai crawler quali percorsi possono e non possono richiedere. Vive esattamente in una posizione: /robots.txt. Googlebot lo controlla prima di ogni crawl, così come Bingbot, GPTBot (OpenAI), ClaudeBot (Anthropic), CCBot (Common Crawl), PerplexityBot e Google-Extended. Il file usa una grammatica semplice. Scrivi uno o più blocchi User-agent, ciascuno seguito da regole Allow e Disallow. Una linea Sitemap vicino all'inizio punta i crawler al tuo index XML così non devono indovinare la struttura. Incolla qualsiasi URL di sito nel nostro checker robots.txt, scegli un User-agent e vedrai la tabella di regole parsate più quale regola vince per quel bot specifico su quel percorso specifico. Se non hai ancora un file, generane uno con il nostro generatore robots.txt e il preset CMS corretto integrato.

Cosa testa davvero uno checker robots.txt?

Un vero checker robots.txt fa quattro cose. Recupera il file e conferma che è raggiungibile con uno stato 200 e il content-type corretto. Parsa la sintassi così catturi typo che infrangono silenziosamente le regole: capitalization sbagliata su User-agent, due punti mancanti, caratteri BOM vaganti all'inizio del file. Risolve un percorso specifico per un bot specifico così puoi rispondere "è /admin bloccato per GPTBot adesso?" senza indovinare. E rileva conflitti di ordine-regola dove due bot ereditano regole diverse da blocchi User-agent sovrapposti. La maggior parte dei checker gratuiti si ferma al passo uno. Il nostro esegue il set completo. Imposta Site URL, scegli il bot da User-agent, rilascia un optional Test path e ottieni un verdetto per regola. Quando distribuisci una correzione, conferma il cambiamento con un secondo passaggio nel checker prima di passare ad altro lavoro.

Dove trovo il mio file robots.txt?

Digita il tuo dominio seguito da /robots.txt in qualsiasi browser. Se https://www.example.com/robots.txt restituisce un 200 e mostra testo semplice, ne hai uno. Se restituisce 404 o la tua homepage CMS, non ne hai uno. Il file deve stare esattamente alla radice del dominio. I percorsi sottodirectory come /blog/robots.txt vengono ignorati completamente da ogni crawler. I subdomini sono separati: blog.example.com e www.example.com ciascuno hanno bisogno del loro file alla loro radice. I siti WordPress di solito hanno uno virtuale generato dal plugin SEO; Shopify ne genera uno automaticamente e ne blocca la maggior parte; Next.js e Astro hanno bisogno che tu distribuisca un file statico sotto /public. Se non sei sicuro cosa vedano davvero i crawler, incolla il tuo URL nel nostro checker robots.txt e lo recuperiamo con gli esatti header che un bot reale invia così il risultato corrisponde alla realtà del crawler. Per una riscrittura pulita con preset CMS integrati, usa il generatore.

Come correggo un errore "blocked by robots.txt" in Search Console?

Search Console segnala "blocked by robots.txt" quando una regola Disallow copre l'URL che Google ha provato a crawlare. Apri lo strumento URL Inspection per vedere quale regola ha matched Google. Poi esegui lo stesso URL attraverso il nostro checker robots.txt con User-agent impostato a Googlebot e il percorso bloccato incollato in Test path. Il checker ti mostra la regola esatta che è stata matched e il blocco User-agent da cui proviene, così puoi correggere la fonte invece di indovinare. Tre correzioni coprono quasi ogni caso. Rimuovi la linea Disallow offensiva. Restringila con un percorso più specifico. O aggiungi una regola Allow sopra di essa (il match più lungo vince sulla sovrapposizione). Distribuisci il cambiamento, testa lo stesso percorso di nuovo nel checker, poi richiedi l'indicizzazione di nuovo in Search Console. Se le pagine risultano ancora bloccate, la copia cached di Google potrebbe essere in gioco; si aggiorna con robots.txt circa ogni 24 ore.

Dovrei bloccare i crawler AI in robots.txt?

Dipende da cosa stai ottimizzando. Bloccali se il tuo contenuto è il prodotto: editori, ricerca pagata, archivi di abbonamento, qualsiasi cosa in cui i dati di training gratuiti danneggiano il business. Consentili se vuoi essere citato nelle risposte di ChatGPT e Claude, dove essere la fonte citata guida traffico di referral di nuovo al tuo sito. L'elenco 2026 che vale la pena nominare esplicitamente: GPTBot (OpenAI), ClaudeBot e anthropic-ai (Anthropic), CCBot (Common Crawl, che allena molti modelli), PerplexityBot e Google-Extended (controlla l'uso di training delle pagine crawlate da Googlebot senza influire sui tuoi ranking nella ricerca Google normale). Il nostro generatore robots.txt ti dà una checkbox per ogni crawler così decidi per bot, non per tutto. Dopo aver distribuito, testa ognuno con il nostro checker contro un percorso reale per confermare che la regola si risolve come ti aspetti per quel bot. La maggior parte dei bug viene da conflitti di ordine-regola tra blocchi User-agent sovrapposti, non da voci mancanti.

Come dovrebbe essere strutturato un file robots.txt?

Inizia con una linea Sitemap che punta al tuo index XML. Poi raggruppa le regole per User-agent. Il blocco wildcard (User-agent: *) cattura ogni bot non nominato altrove, quindi mettilo ultimo. Sopra di esso, aggiungi blocchi nominati per i bot che vuoi trattare diversamente: Googlebot, Bingbot, GPTBot, ClaudeBot, CCBot, PerplexityBot, Google-Extended. Ogni blocco può avere più linee Allow e Disallow. Il match più lungo e più specifico vince quando le regole si sovrappongono. Mantieni i percorsi case-sensitive: Disallow: /Admin non blocca /admin. Elenca un Sitemap per dominio, dichiarato una volta vicino all'inizio. Mantieni il file sotto 500 KB o Google inizia a ignorare le linee dopo quel punto. Il nostro generatore robots.txt ti fornisce tutto questo con un preset CMS e toggle per crawler AI. Una volta che lo pubblichi, verifica che la struttura si parsi correttamente con il nostro checker contro una manciata di URL reali e ogni bot nominato prima di chiudere il ticket.

Qual è la differenza tra Disallow e noindex?

Disallow in robots.txt dice a un bot di non crawlare un URL. Non dice al bot di non indicizzarlo. Se un altro sito fa un link a una pagina Disallowed, Google può ancora elencare l'URL nei risultati di ricerca con "nessuna descrizione disponibile" sotto. Per effettivamente tenere una pagina fuori dall'indice, usa un tag meta robots noindex sulla pagina stessa o un header X-Robots-Tag noindex nella risposta HTTP. Il catch: Google deve crawlare la pagina per vedere il tag noindex. Quindi se sia Disallow che noindex, noindex non ha mai effetto e la pagina rimane nei risultati. Scegli uno per pagina. Disallow è per il crawl budget (bloccare admin, ricerca interna, URL di filtro). Noindex è per tenere il contenuto fuori dai risultati completamente. Per un audit completo a livello di pagina delle direttive robots, usa il nostro simulatore di crawler insieme al metadata checker del sito.

robots.txt funziona ancora nel 2026?

Sì, per i crawler che scelgono di onorarlo. Googlebot, Bingbot e i principali crawler AI (GPTBot, ClaudeBot, PerplexityBot, CCBot, Google-Extended) rispettano tutti robots.txt come materia di policy. Gli scraper canaglia lo ignorano perché il file è una richiesta gentile, non un firewall. Se hai bisogno di blocco duro, aggiungi regole lato server: deny list IP, gestione bot Cloudflare, rate limiting o autenticazione davanti ai percorsi sensibili. Usa robots.txt per quello che è buono: plasma quale pagina i bot che ti interessano spendono il loro crawl budget su. La differenza 2026 è l'AI. Cinque anni fa, "i bot" significava Google e Bing. Oggi l'elenco è più lungo e ogni crawler AI usa un nome User-agent diverso. Il nostro checker testa uno qualsiasi di loro in un click così puoi vedere esattamente cosa vede ogni bot. Abbinalo al nostro simulatore di crawler per una vista pagina renderizzata.

Posso usare wildcard in robots.txt?

Sì, due wildcard sono supportati e capiti da tutti i principali bot. L'asterisco (*) corrisponde a qualsiasi sequenza di caratteri e il segno di dollaro ($) ancora il pattern alla fine di un URL. Disallow: /*.pdf$ blocca ogni URL che finisce in .pdf. Disallow: /*?sort= blocca qualsiasi URL con un parametro sort da qualsiasi parte in esso. Combinali: Disallow: /search?*&page=$ blocca i risultati della ricerca interna paginati ma lascia la pagina di ricerca principale crawlabile. I wildcard non funzionano nelle linee User-agent, quindi non puoi scrivere User-agent: Google* e colpire ogni bot Google. Nomina ognuno esplicitamente (Googlebot, Googlebot-Image, Googlebot-News). Il match letterale più lungo vince su un match pattern più corto. Testa le regole wildcard con un percorso concreto nel nostro checker perché i modelli mentali si rompono velocemente con parametri annidati, query string e pattern sovrapposti che sembrano bene sulla carta. Per una baseline pulita, generane uno con il nostro generatore e itera da lì con percorsi di test.

robots.txt proteggerà le pagine sensibili?

No. Robots.txt è un documento pubblico che chiunque può leggere a yourdomain.com/robots.txt digitandolo in un browser. Elencare un percorso lì dice a ogni crawler, ogni competitor e ogni umano curioso che il percorso esiste sul tuo sito. Per URL di staging, pannelli admin o file privati, questo è l'opposto di quello che vuoi: hai appena pubblicizzato. La protezione reale viene dai controlli lato server: autenticazione con password, IP allow list, accesso solo VPN o semplicemente non esporre l'URL su un server pubblico. Un tag meta noindex tiene la pagina fuori dai risultati di ricerca se la pagina è raggiungibile ma vuoi che sia privata dai ricercatori. Per contenuto veramente nascosto, non fare link, non elencarlo in sitemap e portalo con autenticazione. Usa robots.txt per il shaping del crawl budget su pagine di cui non ti dispiace siano pubbliche. Controlla cosa è esposto con il nostro metadata checker e conferma le regole robots con il nostro checker robots.txt.

Strumenti gratuiti correlati

Tutti gli strumenti →