Formalizzare la specifica del protocollo di esclusione robot

Lunedì 1° luglio 2019

Per 25 anni, il protocollo di esclusione robot (REP, Robots Exclusion Protocol) è stato uno dei componenti di base più importanti del Web. Consente ai proprietari di siti web di impedire ai client automatici, ad esempio i web crawler, l'accesso sia parziale che completo ai loro siti.

Nel 1994, Martijn Koster (che era anche un webmaster) creò lo standard iniziale dopo che i crawler stavano stravolgendo il suo sito. Grazie al contributo di altri webmaster fu creato il REP, adottato dai motori di ricerca per aiutare i proprietari di siti web a gestire più facilmente le risorse dei loro server.

Tuttavia, il REP non è mai stato trasformato in uno standard Internet ufficiale, il che significa che gli sviluppatori hanno interpretato il protocollo in modo leggermente diverso nel corso degli anni. E, fin dall'inizio, il REP non è stato aggiornato per coprire i casi particolari attuali; questo è un problema importante per i proprietari dei siti web, perché l'ambiguità di questo standard de-facto rendeva difficile scrivere correttamente le regole.

Volevamo aiutare i proprietari di siti web e gli sviluppatori a creare esperienze fantastiche su Internet, invece di preoccuparsi di come controllare i crawler. Insieme all'autore originale del protocollo, ai webmaster e ad altri motori di ricerca, abbiamo documentato l'utilizzo del REP sul Web moderno e abbiamo inviato la documentazione all'IETF.

La bozza proposta relative al REP esamina oltre 20 anni di esperienza reale di utilizzo delle regole del file robots.txt, usate sia da Googlebot che da altri noti crawler, nonché da circa mezzo miliardo di siti web che si affidano a REP. Questi controlli granulari consentono al publisher di decidere quali elementi sottoporre a scansione sul proprio sito e mostrare potenzialmente agli utenti interessati. Non modifica le regole create nel 1994, ma definisce essenzialmente tutti gli scenari non definiti per l'analisi e la corrispondenza di file robots.txt e li estende per il web moderno. In particolare:

  1. Qualsiasi protocollo di trasferimento basato su URI può utilizzare il file robots.txt; ad esempio, non è più limitato ad HTTP e può essere utilizzato anche per FTP o CoAP.
  2. Gli sviluppatori devono analizzare almeno i primi 500 kibibyte di un file robots.txt. La definizione di una dimensione massima dei file assicura che le connessioni non siano aperte per troppo tempo, riducendo il carico superfluo sui server.
  3. Un nuovo tempo massimo di memorizzazione nella cache di 24 ore o un valore di istruzione della cache, se disponibili, offrono ai proprietari dei siti web la possibilità di aggiornare il proprio file robots.txt quando preferiscono, e i crawler non sovraccaricano i siti web di richieste del file robots.txt. Ad esempio, nel caso di HTTP, è possibile utilizzare le intestazioni Cache-Control per determinare il tempo di memorizzazione nella cache.
  4. La specifica ora stabilisce che, quando un file robots.txt in precedenza accessibile diventa inaccessibile a causa di errori del server, le pagine note non consentite non vengono sottoposte a scansione per un periodo di tempo ragionevolmente lungo.

Inoltre, abbiamo aggiornato la sintassi augmented Backus-Naur form nell'Internet Draft per definire meglio la sintassi del file robots.txt, che è fondamentale per consentire agli sviluppatori di analizzare le righe.

RFC sta per "Request for Comments" (richiesta di commenti) ed è proprio quello che vogliamo: abbiamo caricato la bozza su IETF per ricevere feedback dagli sviluppatori interessati ai componenti di base di Internet. Mentre ci impegniamo per fornire ai creatori web i controlli di cui hanno bisogno per comunicarci quante informazioni vogliono rendere disponibili a Googlebot e, per estensione, idonee a comparire nella Ricerca, dobbiamo assicurarci di lavorare nel modo corretto.

Se volete lasciare un commento, fare domande o solo salutare, potete trovarci su Twitter e nella community dei webmaster, sia offline che online.