Introduzione: il REP
15 fatti poco noti
Un'estensione da supportare
Una proposta di estensione
Robots.txt in Tribunale
Conclusioni
Introduzione: il Robots Exclusion Protocol
Venti anni fa furono scritte le prime specifiche del Robots Exclusion Protocol - all'epoca noto come il Robots Exclusion Standard.
Consistevano di una descrizione basilare del file /robots.txt e alcuni suggerimenti su come ulteriori informazioni potessero essere aggiunte in meta tag.
Dopo due decadi, vediamo cosa andò per il verso giusto, cosa no, e come potrebbe essere corretto.
15 fatti poco noti sul robots.txt
- La prima specifica fu scritta da Martijn Koster nel 1994 dopo che il sito web da lui amministrato subì un involontario attacco DOS da parte di un bot scritto male
- Il primo crawler compatibile con il robots.txt - CharlieSpider/0.3 - fu scritto da un oggi popolare, Charles Stross, che fu anche la prima persona a causare il primo attacco DOS verificato non intenzionale.
- Kostner lo stesso anno propose anche una soluzione alternativa (un file '/site.idx' in formato IAFA) per affrontare problemi oltre la "crawlability" e più orientati alla indicizzabilità. In retrospezione il formato sembra porre le fondamenta di quanto sarebbe diventato il protocollo XML Sitemap.
- Kostner era già abbastanza noto nel mondo dei costruttori di bot, e aveva così a cuore i pericoli di potenziale abuso dei crawler da scrivere delle Guidelines for Robot Writers.
- Anche se in seguito descritta in una RFC formale, la sintassi robots.txt non è mai diventata uno standard riconosciuto da un ente di standardizzazione internazionale.
È uno standard de-facto. - In un documento successivo alle specifiche originali, era citata una ipotetica direttiva "DontIndex" da essere usata sia in un meta tag (vi ricorda qualcosa?) che come direttiva del robots.txt.
- Google in effetti implementò (senza supportarla ufficialmente) una direttiva Noindex: probabilmente ispirata da tale documento.
- Le specifiche originali del robots.txt hanno diverse lacune e i produttori di crawler dovettero arrangiarsi. Ad oggi le specifiche proprietarie disponibili al pubblico più complete sono quelle di Google.
- La soluzione di Google per decidere se permettere l'accesso a una risorsa in caso di conflitti tra direttive Disallow e Allow è un poco naïve; invece di seguire le specifiche, è basata sulla lunghezza dei percorsi. Quando sono usate le wildcard *, il risultato può variare a seconda delle lunghezza in caratteri del nome o della cartella.
- Google è uno dei pochi maggiori Motori di Ricerca a che non supportano la direttiva Crawl-delay, e - facendo forza sulla sua posizione dominante - impone ai webmaster desiderosi di avere qualche controllo sulla frequenza di crawl di googlebot a sottoscriversi e utilizzare la Google Search Console (ex Google Webmaster Tools). Va concesso: googlebot agisce normalmente come un crawler a bassa frequenza.
- Per quanto vi siano diverse estensioni generalmente accettate come parte dello standard (Allow, il "path matching" tramite le wildcard * e $, Sitemaps, Crawl-delay), vi sono altre altre estensioni interessanti proposte, spinte e supportate da Yandex:
le direttive Host e Clean-param directives. - Quando nacque robots.txt, Unicode così come è conosciuto oggi non esisteva. Oggi il formato file raccomandato è UTF-8
- Vi sono limitazioni sulla dimensione del file imposte da implementazioni proprietarie. Se il limite di Google a 500KB è probabilmente equo, i 32KB imposti da Yandex sembrano un po' troppo draconiani, perché - secondo le specifiche di Yandex ogni file robots.txt eccedente il limite deve essere considerato come un "tutto è permesso"!
- Andando un po' oltre quanto le specifiche originali dicono, Google tollera le redirezioni sul file /robots.txt; inoltre accetta come "permesso completo" non solo un codice di risposta HTTP 404 "Not Found", ma codici di risposta HTTP 401 "Unauthorized" e HTTP 403 "Forbidden" (andando pertanto in direzione opposta alle raccomandazioni della RFC originale).
- Il pericolo di robot programmati in modo malevolo è preso in seria considerazione da parte dei fondatori di Google, che provano a proteggersi dai robot Terminator.
- AGGIORNAMENTO- Fatto Bonus: altre due estensioni interessanti precedentemente proposte - Visit-time e Request-rate - sono entrambe pienamente supportate da Seznam con la sua estensione Request-rate.
Sebbene gli obiettivi di Request-rate si sovrappongono parzialmente con quelli Crawl-delay, la parte Visit-time permette di indicare ai webmaster l'intervallo di tempo preferito per le visite al sito da parte degli spider.
Noindex: un'estensione che dovrebbe essere supportata
Come detto in precedenza, Google ha implementato in via sperimentale il supporto alla direttiva Noindex.
Non sono sicuro del perché non sia stata spinta. La trovo potenzialmente molto utile.
Oggi per togliere dall'indice - o per prevenire l'indicizzazione di una risorsa - devi esporre la stessa al crawler perché la possa scaricare tramite una richiesta HTTP, e il motore di ricerca possa leggerne un noindex nel meta tag o nello header HTTP X-Robots-Tag, o vederne un codice di stato HTTP 404/410.
Il Crawling è un modo molto inefficiente per raggiungere tale risultato, e un grande spreco di risorse per il web server, il motore di ricerca, e tutta la rete in generale.
De-indicizzare in particolare prende molto tempo facendo così. Google permette di de-indicizzare manualmente singoli URL tramite la GSC se sono bloccati da robots.txt, ma de-indicizzare migliaia di URL in questo modo non è una soluzione percorribile.
Inoltre, ogni soluzione basata sull'uso dei Webmaster Tool del singolo MdR funzionarà solo per quello specifico motore di ricerca.
L'uso della direttiva Noindex: directive risolverebbe tali problemi in modo molto più efficace, senza richiedere il coinvolgimento del crawler.
AGGIORNAMENTO: Alec Bertram ho dimostrato che Google in via non ufficiale onora anche la direttiva Nosnippet:, e forse anche Noarchive:.
AGGIORNAMENTO: Google ha annunciato l'intenzione di ritirare tutto il codice che gestisce regole non supportate e non pubblicate (come Noindex) Per il 1 Settembre 2019
Case-sensitive: la mia personale proposta di estensione
Non è solo un mi cruccio, ESISTE un problema non risolto: i percorsi delle direttive nel robots.txt sono interpretate come case-sensitive (ossia distinguendo maiuscole da minuscole), ma i web server case-insensitive esistono e sono molto diffusi.
È inutile a mio parere dire che le specifiche HTTP vogliono gli URL (non è del tutto vero[1]), i server IIS sono largamente diffusi: 13.7% del mercato, secondo w3techs.com (dato di Lugliio 2014).
...e i web server IIS di Microsoft hanno un file system case-insensitive.
Ciò comporta potenziali problemi con il file robots.txt - che suppone i path rispettino appieno le specifiche e siano case-sensitive, come sottolineato da Enrico Altavilla con il suo esempio /cat/ :
Per bloccare l'accesso a una risorsa, dovremmo bloccarne tutte le permutazioni di lettera maiuscola/minuscola del suo percorso.
Altavilla non vuole gatti
A mia modesta opinione, i motori di ricerca dovrebbero fare uno sforzo in più e basare le decisioni di "case sensitiveness" sul tipo di server (come letto dallo header HTTP Server, quando disponibilie):
Non vi sto invitando a farlo, ma... anche i link esterni esistono; sarebbe facile provare a causare problemi di contenuti duplicati creando link a pagine in IIS prive del tag canonical.
La mia proposta è di permettere ai webmaster di dire ai motori di ricerca come interpretare il loro file system:
Case-sensitive: [true | false] # default value is true
where default value is a case-sensitive file system.
Nota: Leggendo i commenti al post di Enrico Altavilla, potrai notare che Enrico - che stimo molto - ed io ebbimo una visione diversa sul se i motori di ricerca debbano accettare che un web server possa essere case-insensitive (indicò anche un modo per rendere il file system di Windows case-sensitive). Non so quale sia la sua opinione sulla mia proposta di estensione.
[1] RFC 2616 sec.3 (HTTP spec.) dice "...a client SHOULD use a case-sensitive...
" where SHOULD is defined as:
mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course
...Capisco sto facendo l'avvocato del diavolo qui, penso MS avrebbe dovuto lavorare diversamente, ma Google potrebbe per lo meno fare uno sforzo.
Il robots.txt in Tribunale
Mentre nel mondo occidentale il file robots.txt file has è apparso in tribunale solo occasionalmente, molti saranno sorpresi di scoprire che è in Cina - paese dove la competizione nel Search è unica e spietata - dove il primo caso "Big-money" che ha coinvolto il robots.txt è stato portato in giudizio.
Il gigante dei motori di ricerca Baidu già nel 2012 citò in giudizio il 16 Ottobre 2012 il suo concorrente Qihoo 360 per avere pescato dati da Baidu nonostante il blocco nel loro file robots.txt. Gli ultimi aggiornamenti parlano di un indennizzo di 100 milioni di yuan (circa 11,86 milioni di Euro), senza che le due parti raggiungessero un accordo.
Quanto manca a mio avviso oggi per dare solidità in giudizio è la ratifica del REP da parte di un ente di certificazione internazionale - IETF, W3C, ISO... - che sarebbe un prerequisito per i burocrati per legislare (apparentemente è stata proprio questa la linea difensiva di Qihoo: che robots.txt è solo una pratica comune nell'industria e non è regolata da leggi).
Penso vedremo sempre più casi come questo in futuro, anche in scala molto più ridotta. Tribunali e leggi sono famosi per non stare mai al passo con la tecnologia, ma il robots.txt è qui già da due decadi ormai, e qualche giudice potrebbe accorgersene.
Nel frattempo, raccomando fortemente i costruttori di bot web di prepararsi in anticipo con un pieno supporto al Robots Exclusion Protocol e le sue note estensioni!
Conclusioni: è tempo di farne un vero standard
È ormai tempo che i maggiori player formino una commissione, scrivano una RFC aggiornata, e applichino una seria specifica a un ente di standardizzazione.
AGGIORNAMENTO - 4 Luglio 2019:
Grandi novità dal mondo della SEO Tecnica: la sintassi del robots.txt potrebbe divenire uno standard riconosciuto.
Dopo avere lette le specifiche dell'RFC e tutti gli annunci fatti, ne abbiamo dettagliato il Buono, il Brutto e il Cattivo nell'articolo
25 Anni di robots.txt ... l'avevamo detto!
Da parte nostra, terremo d'occhio l'evoluzione della proposta di standardizzazione, faremo la nostra proposta di estensione allo standard, e manterremo il parser di robots.txt di Visual SEO Studio compatibile con il nuovo standard.