Venerdì 28 marzo 2025
Nei post precedenti sul protocollo di esclusione robot (REP, Robots Exclusion Protocol), abbiamo esplorato cosa potete già fare con i suoi vari componenti, ovvero il file robots.txt e i controlli a livello di URI. In questo post vedremo in che modo il REP può svolgere un ruolo di supporto nella relazione in continua evoluzione tra i client automatici e il web delle persone.
Il REP (e in particolare il file robots.txt) è diventato uno standard nel 2022 come
RFC9309.
Tuttavia, il lavoro più difficile è stato fatto prima della sua standardizzazione: è stato il periodo tra il 1994 e il 2022 a renderlo abbastanza popolare da essere adottato da miliardi di host e da quasi tutti i principali operatori di crawler (esclusi i crawler adversarial come gli scanner di malware). È una soluzione semplice ed elegante per esprimere le preferenze con una sintassi semplice ma versatile.
Nei suoi 25 anni di vita è cambiato poco dalla sua forma originale, infatti ha ricevuto una sola regola allow se consideriamo soltanto le regole universalmente supportate dai crawler.
Ciò non significa che non esistano altre regole: qualsiasi operatore di crawler può creare le proprie. Ad esempio, regole come "clean-param" e "crawl-delay" non fanno parte del protocollo RFC9309, ma sono supportate da alcuni motori di ricerca, anche se non dalla Ricerca Google.
La regola "sitemap", che non fa parte del protocollo RFC9309, è supportata da tutti i principali motori di ricerca. Con un supporto sufficiente, potrebbe diventare una regola ufficiale nel REP.
Infatti, il REP può ricevere "aggiornamenti"; è un protocollo ampiamente supportato e dovrebbe crescere assieme a internet. Apportare modifiche non è impossibile, ma non è semplice; ed è giusto così, proprio perché il REP è ampiamente supportato. Come per qualsiasi modifica a uno standard, deve esserci il consenso sul fatto che le modifiche siano vantaggiose per la maggior parte degli utenti del protocollo, sia per i publisher che per gli operatori di crawler.
Grazie alla sua semplicità e alla sua ampia adozione, il REP è un candidato eccellente per supportare nuove preferenze di scansione: ad esempio, miliardi di publisher hanno già familiarità con il file robots.txt e la sua sintassi, quindi apportare modifiche è più naturale per loro. D'altra parte, gli operatori di crawler hanno già parser e matcher robusti e ben testati (e Google ha anche reso open source il proprio parser robots.txt), il che significa che è molto probabile che non si verifichino problemi di analisi con le nuove regole.
Lo stesso vale per le estensioni a livello di URI del REP, l'intestazione HTTP X-robots-tag e la relativa controparte del meta tag. Se è necessaria una nuova regola per gestire le preferenze di disattivazione, queste sono facilmente estendibili. In che modo?
La cosa più importante che potete fare, in qualità di lettori, è parlare pubblicamente della vostra idea e riunire persone che la appoggiano. Poiché il REP è uno standard pubblico, nessuna entità può apportarvi modifiche unilaterali. Certo, può implementare il supporto per qualcosa di nuovo, ma questo non diventerà lo standard. Tuttavia, parlare di questa modifica e mostrare all'ecosistema (sia agli operatori di crawler che ai publisher) che è vantaggiosa per tutti, genererà consenso e aprirà la strada all'aggiornamento dello standard.
Analogamente, se al protocollo manca qualcosa, parlatene pubblicamente. sitemap
è diventata una regola ampiamente supportata in robots.txt perché era utile sia per i creator di contenuti che per i motori di ricerca, il che ha spianato la strada all'adozione dell'estensione. Se avete una nuova idea per una
regola, chiedete agli utilizzatori del file robots.txt e ai creator cosa ne pensano e collaborate con loro per risolvere i potenziali (e probabili) problemi che emergono, quindi scrivete una proposta.
Se il vostro obiettivo è il bene comune, ne vale la pena.