John Smith
You have 4 new messages
Il web può essere paragonato ad una città in continua espansione, in cui ogni pagina rappresenta un edificio e ogni collegamento ipertestuale una strada che conduce ad altre destinazioni.
Gli spider (o crawler) possono essere immaginati come esploratori automatizzati che percorrono queste strade al fine di analizzare i contenuti e inserirne tutte le informazioni nell’indice del motore di ricerca. Al loro arrivo in un sito, gli spider non si limitano a interpretarne il contenuto ma seguono i collegamenti interni ed esterni, ampliando progressivamente la propria “mappa” del territorio digitale.
Prima dell’era di Google, che oggi è certamente il motore di ricerca dotato della tecnologia di scansione più avanzata, il c.d. web invisibile era infinitamente più vasto rispetto a oggi e, conseguentemente, il raggio d’azione degli spider risultava molto più limitato. Già nel febbraio 1994, agli albori dell’era dei motori di ricerca, Martijn Koster – un software engineer danese – propose l’adozione di un protocollo per consentire ai webmaster di limitare l’attività degli spider sul proprio sito web, indicando bot indesiderati e/o aree del sito interdette al loro accesso. Si deve considerare che a quel tempo l’attività degli spider, per quanto molto ridotta, poteva impattare non poco sulla funzionalità dei webserver, dalle risorse decisamente limitate.
L’idea piacque così tanto che nell’arco di pochi mesi il RobotsNotWanted.txt poi semplificato in robots.txt divenne uno standard di fatto, supportato dai principali motori dell’epoca quali WebCrawler o Altavista.
Il robots.txt è un file di testo contenente le istruzioni dirette agli spider. È la prima segnaletica che un crawler verifica quando atterra su un sito e agisce come un “protocollo di esclusione” (Robots Exclusion Protocol). Ad oggi, si tratta di un protocollo cui i motori aderiscono su base volontaria, quindi inefficace nei confronti dei bot malevoli (malbot).
Per permettere a tutti gli spider di accedervi al fine di modulare la propria attività di scansione nel rispetto delle sue direttive, il robots.txt deve essere sempre raggiungibile all’indirizzo principale del nome host:
https://www.dominio.com/robots.txt
Qualsiasi altra collocazione lo rende inefficace. Inoltre, il file fa riferimento solo alle risorse presenti sullo specifico dominio su cui è stoccato e, salvo l’indirizzo delle sitemap.xml, non può contenere istruzioni relative a domini diversi.
Ad esempio, il robots.txt del terzo livello shop:
https://shop.dominio.com/robots.txt
Non avrà alcun impatto sul dominio www.
Predisporre il robots.txt è sempre fortemente consigliato in quanto, se il file non esiste, lo spider riceve una risposta 404 (risorsa non trovata), cosa da evitare in quanto può rallentare il processo di scansione del sito.
In presenza di un errore 404, infatti, i bot potrebbero sospendere ogni attività di crawling per evitare di violare eventuali direttive temporaneamente irraggiungibili. Per questa ragione è buona prassi implementarlo sempre anche senza istruzioni specifiche, semplicemente per dichiararne l’esistenza.
Per comprendere il rapporto tra robots.txt e Sitemap si può proseguire con l’analogia urbana: il robots.txt rappresenta, come abbiamo detto, la segnaletica, i cartelli di divieto d’accesso e le strade interdette. La Sitemap equivale a una guida turistica, che indica agli spider i punti di interesse e i percorsi raccomandati.
Insieme costituiscono due strumenti complementari di gestione della scansione e dell’indicizzazione.
Il robots.txt appartiene a una più ampia famiglia di strumenti di gestione degli spider. Questi ultimi, in particolare, si distinguono in:
strumenti di interdizione (exclusion): bloccano l’accesso alle risorse (es. robots.txt);
strumenti di segnalazione (inclusion): segnalano le risorse da indicizzare (es. sitemap);
strumenti di controllo e diagnostica: monitorano l’andamento del crawling (es. Google Search Console).
Il linguaggio utilizzato nel robots.txt è lineare e basato su direttive con ruoli specifici.
| Direttiva | Funzione | Esempio | Note |
|---|---|---|---|
| User-agent: | Indica a quale spider si rivolge l'istruzione. | User-agent: Googlebot | Il simbolo * vale per tutti. |
| Disallow: | Indica quale file o cartella si vuole bloccare dalla scansione. | Disallow: /cgi-bin/ | Blocca l'intera cartella. |
| Allow: | Crea un'eccezione all'interno di un blocco Disallow più ampio. | Allow: /cgi-bin/file.html | Permette il file specifico anche se la cartella è bloccata. |
Regola della Specificità: in caso di direttive contrastanti, gli spider tendono ad attenersi a quelle più specifiche (ad esempio, un Allow su un file specifico prevale su un Disallow sulla cartella) o più restrittive (ad esempio, tra Disallow: / e Allow: / prevarrà sempre il Disallow Dove con lo slash (/) si intende tutte le pagine del sito).
I siti moderni (soprattutto e-commerce) generano spesso URL con parametri che non dovrebbero essere scansionati (es. ?sessionid=123, ?sort=price).
| Direttiva | Funzione | Utilizzo | Note |
|---|---|---|---|
| Wildcard (*) | Utilizzata per bloccare tutti gli URL contenenti una stringa o un parametro. | Disallow: /*?sessionid=* | |
| Fine Stringa ($) | Utilizzata per specificare che la direttiva si applica solo all’URL che finisce esattamente in quel modo. | Disallow: /pippo.htm$ (Blocca solo .htm, non .html) | In questo caso blocca .htm e non .html. |
| Clean-param (Yandex) | Indica quali parametri ignorare per evitare di scansionare pagine duplicate. | Clean-param: sessionid&sort&ref /catalog/ |
Un esempio pratico di uso congiunto di wildcard e fine stringa è costituito dall’interdizione (o il permesso) di tutti i file di un sito con una certa estensione:
Disallow: /*.doc$ (risultano interdetti i file .doc ma non quelli .docx)
Per quanto riguarda, invece, il clean-param, questa direttiva usata da Yandex istruisce lo spider a considerare un set di URL come identici se differiscono solo per i parametri elencati. Questo risparmia risorse di scansione gestendo i contenuti duplicati e rappresentando, di fatto, una soluzione molto più efficace del canonical meta link.
| Direttiva | Funzione | Nota Importante |
|---|---|---|
| Sitemap: | Indica agli spider dove trovare la mappa completa delle risorse da indicizzare (XML Sitemap). | Fondamentale. Viene posizionata tipicamente alla fine del file, rivolta a tutti gli agenti. Non supporta wildcard (*). |
| Crawl-delay: | Suggerisce il tempo di attesa (in secondi) tra le richieste. | Ignorata da Googlebot, ma utile per altri motori (es. Bing) per ridurre il carico del server. |
È fondamentale distinguere tra blocco di scansione e blocco di indicizzazione:
il disallow impedisce la scansione di una pagina: lo spider non può leggerne il contenuto, ma il motore di ricerca può comunque inserirla nell’indice se questa è raggiungibile da link esterni di altri siti;
il noindex è il metatag fine alla deindicizzazione, ma preclude il fatto che la pagina sia accessibile agli spider.
Se blocchi una pagina via disallow, lo spider non può accedervi. Se quella pagina riceve link da altri siti, Google può comunque indicizzarla (pur non potendone leggere il contenuto) e mostrarla con una descrizione generica.
Per garantire che una pagina sia rimossa dall’indice, lo spider deve poterla scansionare per leggere il meta tag noindex al suo interno. Non bloccare mai con robots.txt pagine che contengono il noindex. In questo modo si mantiene il controllo sull’indicizzazione senza compromettere il flusso di PageRank.
Il robots.txt impedisce l’accesso e la scansione, causando la totale dispersione del Page Rank in entrata.
Bloccare una risorsa con robots.txt impedisce agli spider di accedervi e questo causa la perdita del valore SEO dei link in entrata (Page Rank), che non fluisce verso le pagine interne.
Per mantenere la scansione e il flusso di PageRank, pur evitando l’indicizzazione, è necessario utilizzare il meta tag noindex, follow.
Le modifiche al robots.txt non hanno un effetto immediato, bensì c’è un ritardo variabile tra l’upload del file e l’applicazione delle nuove istruzioni da parte degli spider.
Per rimozioni urgenti, è sempre preferibile utilizzare gli strumenti rapidi (come il tool di rimozione URL nella Google Search Console) anziché affidarsi solo al robots.txt.
Nel compilare il robots.txt è essenziale assicurarsi che ciascuna direttiva produca il risultato desiderato e non finisca per compromettere l’accessibilità di risorse che si vorrebbero indicizzate.
Google Search Console conteneva uno strumento di test molto utile, che permetteva di inserire direttive e poi testare URL per verificare se risultassero ammessi o esclusi. Purtroppo, lo strumento è stato eliminato e non risulta più disponibile dalla fine del 2023. Per contro, sia Bing che Yandex continuano ad offrire uno strumento di controllo delle direttive contenute nel robots.txt, ma si deve considerare che l’interpretazione della sintassi da parte dei motori può presentare differenze e che, pertanto, resta necessario comporre le regole dirette a Google seguendo le indicazioni fornite nella sua documentazione.
Il robots.txt è uno strumento potente e, quindi, potenzialmente pericoloso. Si pensi all’ipotesi del rilascio di un aggiornamento del sito in cui ci si porta dietro per errore il robots.txt dell’area staging, generalmente valorizzato con un disallow integrale: se la modifica non viene prontamente rilevata, si va incontro a una massiva deindicizzazione delle pagine del sito, con conseguente ricaduta negativa su ranking e traffico organico.
La Google Search Console offre la possibilità di verificare lo stato del robots.txt e le ultime versioni rilevate dal motore, funzione utile per dare una spiegazione a eventuali problemi di indicizzazione, ma in linea generale sarebbe utile monitorare i cambiamenti del file di robots.txt periodicamente o con strumenti di alerting ad hoc – come ad esempio Tomo, peraltro gratuito – che notificano ogni variazione del contenuto del file, evitando sgradite sorprese e perdite di visibilità e traffico.
Come abbiamo visto, il robots.txt agisce come una segnaletica urbana, indicando agli spider le aree accessibili e quelle da evitare. L’implementazione corretta del robots.txt influisce, quindi, sulla qualità della scansione e sull’efficienza dell’indicizzazione.
Un uso consapevole del file permette di:
massimizzare l’efficienza della scansione, concentrando gli spider sui contenuti rilevanti;
prevenire problemi di indicizzazione indesiderata senza compromettere il flusso di PageRank;
coordinare robots.txt con Sitemap e strumenti di diagnostica, assicurando un controllo preciso sull’indicizzazione e riducendo il rischio di errori critici.
In sintesi, il robots.txt non è solo un file tecnico, ma un elemento chiave della strategia SEO, capace di influire su visibilità, ranking e gestione delle risorse del sito.
