Google lavora a uno standard ufficiale per il file robots.txt
Alle celebrazioni per il compleanno speciale del file robots.txt, rilasciato ufficialmente il 30 giugno del 1994, si è aggiunto Google, che attraverso una serie di pubblicazioni sul Webmasters Official Blog annuncia alcuni “regali” in arrivo per gli utenti e per i siti.
Uno standard ufficiale per il file robots.txt
La notizia principale riguarda l’impegno che il team del motore di ricerca più usato al mondo si è imposto: provare a creare uno standard Internet ufficiale e condiviso per le regole incluse nel file robots.txt, che finora non hanno avuto una struttura definita in modo formale e univoco.
La storia del file robots.txt
È il 1994 e i crawler stanno sovraccaricando i server con le loro richieste: per aiutare i webmaster, Martijn Koster (webmaster lui stesso) propone un protocollo per controllare gli url del sito a cui consentire l’accesso ai crawler. Il protocollo è molto semplice ed efficace: specificando un user-agent e le regole relative, i webmaster hanno un controllo granulare sulle aree accessibili ai crawler, non imposta se si tratti di singoli Url, di un file di tipo specifico o di un intero sito.
Incertezza per l’assenza di regole univoche
In questo quarto di secolo, il REP – Robots Exclusion Protocol – non ha mai adottato uno standard ufficiale ed è stato adottato dai motori di ricerca in maniera varia, lasciando agli sviluppatori libera interpretazione delle norme. Inoltre, non è stato realmente aggiornato per coprire tutti gli usi odierni, e ad esempio non è chiaro se un errore con status code HTTP 500 significhi che il crawler può scansionare tutto o nulla, come si legge nel tweet dell’account Google Webmasters.
Una situazione che provoca errori
Per cercare di risolvere questi problemi e offrire una procedura più lineare a webmaster, web developer, proprietari di siti, SEO (e per semplificare le operazioni di scansione di Googlebot e altri spider!), il team di Google si è messo al lavoro con Martijn Koster, il papà del Robots Exclusion Protocol, con webmasters e altri motori di ricerca per realizzare lo standard ufficiale del file robots.txt.
Nei 25 anni di attività il robots.txt è stato largamente adottato, al punto che si stima che oltre mezzo miliardi di siti lo usano: le linee di comando più usate sono user-agent, disallow, and allow, ma da Google raccontano che hanno trovato regole che consentono a Googlebot di “imparare emozioni” o di “assimilare The Pickled Pixie” (in inglese, “Learn Emotion” e “Assimilate The Pickled Pixie”).
Errori tipografici, misspell e regole mal interpretate
Ancor più grave, nei file si trovano tantissimi errori tipografici, misspell e altri orrori: tra quelli citati, mancanza di colonne nelle regole, regole impostate in “Dis Allow” e non “disallow” e così via, per arrivare a veri e propri guai che bloccano l’indicizzazione corretta. Inoltre, la situazione di standardizzazione de-facto ha generato implicazioni a volte frustanti, dicono i Google, come l’incertezza sui corner cases per i webmaster (ad esempio, quando l’editor di testo include i caratteri BOM nei loro file) o i dubbi per crawler e sviluppatori di tool sulle modalità di trattare i file robots.txt di dimensioni enormi centinaia di megabyte.
Per questo, come spiegato da Gary Illyes (che ha eseguito per settimane analisi dei noindex in robots.txt), Google ha pensato di lavorare per migliorare l’ecosistema Web e rendere più fluide le procedure, riducendo le possibilità per i siti di “farsi male da soli”.
Google rilascia il parser del robots.txt open source
Il risultato concreto è stato il rilascio open source del parser del robots.txt di Google, disponibile ora su GitHub, che potrà servire da riferimento agli sviluppatori che devono creare parsers che riflettono i requisiti del Robots Exclusion Protocol. La risorsa è aggiornata per comprendere tutti i corner cases e garantisce che Googlebot esegua solo la scansione di ciò che è consentito (allowed).
Le regole non cambiano, ma si definiscono meglio
Il progetto non cambia le regole introdotte nel 1994, ma piuttosto chiarisce essenzialmente tutti gli scenari non definiti per il parsing e il matching di robots.txt, estendendolo al Web moderno e conferendo ai publisher il potere di decidere con maggior precisione cosa vorrebbero far sottoporre a scansione sul loro sito e potenzialmente mostrato agli utenti interessati.
Sono quattro le indicazioni particolari segnalate da Google:
- Qualsiasi protocollo di trasferimento basato su URI (URI based transfer protocol) può utilizzare robots.txt, e dunque non è più limitato a HTTP e può essere utilizzato anche per FTP o CoAP.
- Gli sviluppatori devono analizzare almeno i primi 500 kibibyte di un file robots.txt: la definizione di una dimensione massima del file garantisce che le connessioni non siano aperte troppo a lungo, alleggerendo i carichi non necessari sui server.
- Un nuovo tempo massimo tempo di caching di 24 ore o, se disponibile, il valore della cache directive, offre ai proprietari di siti Web la possibilità di aggiornare i loro robots.txt ogni volta che desiderano e di non avere crawler che sovraccaricano i siti Web con richieste di robots.txt. Ad esempio, nel caso di HTTP, i Cache-Control headers potrebbero essere usati per determinare il caching time.
- Le specifiche ora prevedono che quando un file robots.txt accessibile in precedenza diventa inaccessibile a causa di errori del server, le pagine in disallow conosciute non siano sottoposte a scansione per un periodo di tempo ragionevolmente lungo.
Dal 1 settembre 2019 cambiano le regole non supportate da Google nel Robots
Ma le notizie che arrivano da Google non si fermano qui, e un altro post sul blog segnala l’ultima novità: a partire dal 1 settembre 2019 sarà ritirato tutto il codice che gestisce regole non supportate e non pubblicate (come noindex).
È ancora Gary Illyes a chiarire che, nel corso delle operazioni per rendere open source la parser library di Google, il team ha analizzato l’utilizzo delle regole robots.txt, concentrandosi soprattutto su regole non supportate, come il ritardo di scansione, il nofollow e il noindex (crawl-delay, nofollow, e noindex). Essendo regole mai documentate da Google, il loro utilizzo in relazione a Googlebot è molto basso e, approfondendo lo studio, si è scoperto che il loro utilizzo era contraddetto da altre regole nel 99,99 per cento di tutti i file robots.txt su Internet.
Cambia la regola per indicare gli Url noindex
Questi errori danneggiano la presenza dei siti web nei risultati di ricerca di Google in modi che forse i webmaster non comprendono a pieno, aggiunge il webmaster trends analyst di Mountain View. In concreto, entro il 1 settembre bisogna controllare i sistemi con i quali attualmente si segnalano ai bot le pagine noindex, perché chi usava le direttive noindex nel file robots.txt (e così pure i comando nofollow o crawl-delay) dovrà cambiare sistema, basandosi su una serie di alternative.
Come controllare il crawling di Googlebot
È ancora il post sul blog della compagnia americana a delineare i percorsi consentiti per controllare il crawling e bloccare l’indicizzazione delle pagine per Googlebot:
- Noindex nei meta tag robots: supportati sia nelle intestazioni delle risposte HTTP che in HTML, la direttiva noindex è il modo più efficace per rimuovere gli URL dall’indice quando la scansione è consentita.
- Codici di stato HTTP 404 e 410: entrambi i codici di stato indicano che la pagina non esiste, portando all’eliminazione di tali URL dall’indice di Google dopo che sono stati sottoposti a scansione ed elaborazione.
- Protezione con password: a meno che non venga utilizzato il markup per indicare contenuti con sottoscrizione o paywall, nascondere una pagina con un login di accesso porta in genere alla rimozione dall’indice di Google.
- Disallow in robots.txt: i motori di ricerca possono solo indicizzare le pagine di cui sono a conoscenza, quindi bloccare la scansione della pagina di solito significa che il suo contenuto non verrà indicizzato. Mentre il motore di ricerca può anche indicizzare un URL basato su collegamenti da altre pagine, senza vedere il contenuto stesso, miriamo a rendere tali pagine meno visibili in futuro.
- Strumento per la rimozione degli URL in Google Search Console: lo strumento è un metodo rapido e semplice per rimuovere temporaneamente un URL dai risultati di ricerca di Google.
