Come verificare se un sito ha robots.txt
Come verificare se un sito web ha un file robots.txt
Il file robots.txt è un semplice file di testo che fornisce istruzioni di scansione ai bot che scelgono di seguirle. Consultarlo può aiutarti a capire quali percorsi un sito chiede a determinati crawler di visitare o evitare. Non rivela tutte le impostazioni del sito e non è una barriera di sicurezza.
Se vuoi sapere come verificare se un sito web ha un file robots.txt, inizia dall’origine esatta del sito, poi controlla la risposta del server e il contenuto del file. Sono dettagli importanti: un file presente su un sottodominio potrebbe non riguardarne un altro e un errore del browser non significa sempre che il file sia assente.
1. Scopri cosa può e cosa non può dirti robots.txt
Il file robots.txt contiene regole per i crawler automatizzati. Una regola può chiedere a un bot di ricerca conforme di non eseguire la scansione di un percorso come /private/. È una richiesta, non un meccanismo di controllo degli accessi: un visitatore potrebbe comunque aprire quell’URL e un bot potrebbe ignorarla.
Inoltre, non garantisce che una pagina bloccata resti esclusa dai risultati di ricerca. Un motore di ricerca potrebbe scoprire un URL tramite link presenti altrove e inserirlo nei risultati senza scansionarne i contenuti. Se una pagina deve restare privata, usa un vero sistema di controllo degli accessi, come l’autenticazione, invece di affidarti a robots.txt.
Considera questo file come un insieme pubblico di indicazioni. Può aiutarti a capire il comportamento di scansione, ma non può confermare che una pagina sia accessibile, privata o indicizzata. Verifica separatamente questi aspetti.
2. Trova il file robots.txt del sito all’origine corretta
Per un sito all’indirizzo https://example.com, il percorso abituale è https://example.com/robots.txt. Per capire come trovare il file robots.txt di un sito, mantieni il protocollo e il nome host visualizzati nella barra degli indirizzi e includi l’eventuale porta non predefinita, se il sito ne usa una. Il percorso si trova alla radice di quell’origine, non dentro una cartella come /blog/.
Le variazioni di protocollo e nome host possono dare risultati diversi. Per esempio, http://example.com/robots.txt и https://example.com/robots.txt sono richieste distinte, anche se una reindirizza all’altra. Allo stesso modo, www.example.com и example.com potrebbero essere configurati separatamente.
I sottodomini hanno origini proprie. Un file su https://shop.example.com/robots.txt non si applica automaticamente a https://example.com/ o https://help.example.com/. Controlla l’host che ti interessa, soprattutto se un’azienda gestisce il negozio, l’assistenza e il sito principale su sottodomini separati.
Per un primo controllo, usa la barra degli indirizzi: inserisci l’URL completo di robots.txt e verifica cosa viene caricato. È normale visualizzare una pagina di testo semplice, ma va bene anche una vista formattata del browser. L’importante è sapere quale URL hai richiesto e cosa ha restituito il server.
3. Controlla la risposta, non solo la pagina visualizzata dal browser
Una risposta riuscita indica in genere che il server ha restituito dei contenuti per quell’URL. Molti siti rispondono con un codice HTTP come 200, ma il testo visualizzato potrebbe contenere un insieme di regole, essere vuoto o persino mostrare una pagina inattesa. Valuta il contenuto insieme al codice di stato: il semplice fatto che una pagina si carichi non dimostra che si tratti di un file robots.txt valido.
Per capire come verificare la risposta HTTP di robots.txt, considera sia il codice di stato sia il corpo restituito. Una risposta di risorsa non trovata, spesso 404, indica che il percorso richiesto non esisteva su quell’origine in quel momento. È un’indicazione utile, ma prima controlla il nome host e i reindirizzamenti. Un errore di battitura o un sottodominio diverso possono produrre lo stesso risultato.
È bene prestare attenzione ai reindirizzamenti. L’URL richiesto potrebbe portarti a un altro host o percorso e la destinazione potrebbe restituire contenuti appartenenti a un’origine diversa. Prima di decidere di aver letto le istruzioni del sito giusto, annota sia l’URL iniziale sia la destinazione finale.
Gli errori di accesso e i problemi del server non equivalgono all’assenza del file. Una risposta come 403 può indicare che il server ha rifiutato la richiesta; una risposta 5xx può segnalare un problema temporaneo del server. Anche un timeout di rete o un errore di connessione del browser possono impedire il controllo. Riprova più tardi o usa un secondo metodo prima di trarre una conclusione definitiva.
Per un’attività correlata di verifica del sito, puoi leggere anche come verificare se un sito web pubblica un’informativa sulle affiliazioni; questo controllo riguarda una policy visibile, non le istruzioni per i crawler.
4. Controlla le direttive di robots.txt per il crawler che ti interessa
Per capire come controllare le direttive robots.txt, leggi ogni gruppo di regole nel suo contesto. Una riga User-agent indica un crawler, mentre le righe Disallow e Allow specificano i percorsi che quel crawler dovrebbe evitare o può scansionare. L’interpretazione esatta può dipendere dal crawler: se il risultato è importante, consulta la relativa documentazione.
Per esempio, un gruppo che inizia con User-agent: ExampleBotpotrebbe applicarsi solo al crawler indicato. Un gruppo separato con User-agent: * è destinato ai crawler per i quali non esiste un gruppo più specifico. Non dare per scontato che una regola per un bot valga per tutti i motori di ricerca o gli altri servizi automatizzati.
Anche i percorsi sono importanti. Una regola per /images/ non equivale a una regola per /, e una regola per /drafts/ non copre necessariamente un percorso simile in un’altra posizione. Prima di applicarla a un URL, controlla il percorso completo e il gruppo in cui compare.
Considera un file che contiene Disallow: /private/all’interno di un gruppo generale di user-agent. Questa istruzione chiede ai crawler corrispondenti di evitare la scansione dei percorsi sotto quella directory. Non impedisce a qualcuno di aprire un URL noto e non dimostra che tutti i bot la rispetteranno.
Alcuni file contengono commenti, righe vuote o regole rivolte a servizi specifici. Concentrati sul gruppo user-agent pertinente alla tua domanda, poi consulta le regole pubblicate dal crawler per capire come gestisce direttive in conflitto o insolite. Se stai verificando un motore di ricerca specifico, la documentazione di quel motore è il riferimento giusto per interpretarne il comportamento.
5. Distingui un file vuoto da uno mancante o non valido
Una risposta vuota e un file mancante sono due risultati diversi. Se il server restituisce una risposta riuscita senza testo visibile, il file potrebbe esistere ma non contenere direttive. Se il server restituisce un codice di risorsa non trovata, non ha trovato un file all’URL richiesto. Registra sia il codice di stato sia il corpo della risposta per non confondere questi casi.
Se trovi contenuti inaspettati, verifica meglio. Una pagina con un messaggio di errore generale del sito, una schermata di accesso o codice HTML potrebbe indicare che la richiesta è stata indirizzata a una pagina di fallback invece che a un normale file robots.txt. L’URL può caricarsi correttamente, ma restituire comunque contenuti che non sono utili come istruzioni per i crawler.
Non cercare di interpretare a intuito le righe malformate o poco familiari. Salva la risposta esatta e confrontala con la documentazione del crawler che stai verificando. Se il file cambia tra un controllo e l’altro, annota l’ora: una risposta successiva potrebbe riflettere una versione corretta, non gli stessi contenuti.
6. Verifica i risultati con un secondo metodo
Se il risultato nel browser non è chiaro, invia una richiesta dalla riga di comando. Per esempio, curl -i https://example.com/robots.txt può mostrare le intestazioni della risposta e il corpo restituito in un’unica richiesta. Sostituisci l’indirizzo di esempio con l’origine esatta che stai controllando, includendo il sottodominio e la porta corretti, se necessario.
Gli strumenti per sviluppatori del browser offrono un’altra possibilità. Apri il pannello Rete, carica l’URL di robots.txt e seleziona la richiesta per esaminarne il codice di stato, le intestazioni e il corpo della risposta. È utile quando il browser mostra un reindirizzamento o una pagina formattata senza rendere evidente la destinazione finale.
Se i metodi danno risultati diversi, confronta l’URL esatto, l’orario, il codice di stato, i reindirizzamenti e i contenuti. Una richiesta dalla riga di comando e una dal browser potrebbero seguire reindirizzamenti diversi o incontrare un problema temporaneo del server. Se usi un proxy aziendale, una VPN o un’estensione del browser, quando opportuno prova senza: una risposta diversa potrebbe indicare la presenza di un intermediario anziché un problema del sito stesso.
Un altro esempio di verifica di un sito riguarda come verificare se un sito webmostra un’informativa sul copyright. Tienilo distinto da robots.txt: uno è un’informativa del sito rivolta ai lettori, l’altro è un file destinato ai crawler.
7. Annota l’ambito e i limiti del controllo
Annota l’URL esatto di robots.txt, la data e l’ora della richiesta, il codice di stato HTTP, l’eventuale destinazione del reindirizzamento e i contenuti visualizzati. Se stai interpretando un gruppo specifico di direttive, indica anche il crawler o il contesto dello user-agent. Queste informazioni permettono di ripetere il controllo se il sito cambia.
Mantieni circoscritta la conclusione. Una risposta riuscita mostra cosa ha restituito il server per una determinata origine e in un preciso momento; non dimostra che una pagina sia indicizzata, accessibile a tutti i visitatori o bloccata per ogni crawler. Una risposta di file mancante riguarda l’URL richiesto, non automaticamente ogni sottodominio o versione del protocollo.
Il contenuto di robots.txt può cambiare senza preavviso. Se una decisione dipende dalle regole attuali, ricontrolla l’origine esatta e conserva la nuova risposta invece di fare affidamento su una copia precedente.
