Il robots.txt potrebbe divenire uno standard ufficiale

[federico.sasso]

Il robots.txt potrebbe divenire uno standard ufficiale

Google ha annunciato tre giorni fa la stesura di una bozza di RFC (Request for Comments), in collaborazione con l'inventore originale del protocollo Martijn Koster e altri motori di ricerca.
Ha anche annunciato di aver reso open source il codice del proprio parser, e pianificato di volervi eliminare le parti che supportano estensioni non-standard (es. la direttiva Noindex).

Una bozza di RFC è il primo passo per il raggiungimento di uno standard riconosciuto da un ente di certificazione internazionale, in questo caso IETF.

La RFC corrente copre parti che in origine erano lasciate all'interpretazione: che fare in presenza di codici di stato HTTP inattesi, come gestire i redirezionamenti, quando è giustificato usare una copia in cache, che limiti di dimensione considerare, come gestire i caratteri Unicode, BOM, etc...

Ho già scritto altrove la mia opinione su queste novità, ma le riassumo qui:

• In sé l'iniziativa è un'ottima cosa, perché in presenza di uno standard ratificato i motori di ricerca non devono fare da sé interpretando ognuno a modo proprio le eventuali ambiguità, ma possono segnalarle all'ente certificatore perché siano disambiguate.
  Sarà ben chiaro cosa è considerato standard riconosciuto, e cosa non lo è.
• Non mi piace come la bozza rifletta - inevitabilmente - fin troppo l'implementazione di Google. Mi domando quale sia il livello di coinvolgimento degli altri motori di ricerca visto che nei loro blog e rassegne stampa non ho trovato traccia della collaborazione.
• In particolare raggruppando tutti i codici 40x come "liberi tutti" invece dei soli 404 e 410, implicitamente la bozza dice che anche in presenza di codici di stato HTTP 401 "Unauthorized" e HTTP 403 "Forbidden" il crawler è libero di accedere a tutte le risorse del web server; è chiaro che 401 e 403 sono stati chiaramente concepiti per l'esatto contrario!
  D'altronde questa è già il comportamento odierno di Googlebot, cattivo!
• Altra bruttura dell'implementazione di Google che Google sta cercando di fare passare nel nuovo standard è come comportarsi in caso di direttive Allow e Disallow contrastanti.
  La soluzione proposta è quella di Google, ossia del "longest match": la direttiva con il percorso più lungo è quella che vince.
  Sarebbe elegante, peccato che in caso di uso di wildcard * la regola va completamente a funghi.
  Altri motori usano l'ordine in cui le direttive sono incontrate, che non ha tale problema.
• Non mi piace che al di là della direttiva Allow (edit: e i caratteri speciali $ e *), tutte le altre estensioni successive alla primissima stesura del protocollo non sono considerate. La RFC dice solo che il protocollo è estensibile con direttive non-standard che possono essere ignorate da tutti tranne che dagli interessati, e cita la direttiva Sitemap solo a titolo di esempio.
• Ovviamente nessun accenno a Crawl-Delay, notoriamente non supportato da Google. Vero è che Crawl-Delay è stato concepito in altri tempi e permette tempi ormai un po' troppo lunghetti, se tutti lo specificassero Google avrebbe forse difficoltà a indicizzare efficacemente quanto fa oggi. Preferisce imporre e dare l'opportunità di cambiare l'impostazione da GSC.
  Nota: Seznam, il motore della Repubblica Ceca, ha proposte alternative interessanti: Request-rate (equivalente a Crawl-Delay) e Visit-time, quest'ultima in particolare permetterebbe di sostituire l'impostazione fornita a Bing dal suo Webmasters Tool.
• Non vedo desiderio da parte di Google di spingere altre direttive interessanti come ad esempio Noindex, comodissima per de-indicizzare intere sezioni di un sito. Dato che dopo averla tenuta nascosta per anni intendono anche rimuovere la loro implementazione dal proprio parser è ancora più evidente non sono interessati a spingerla.
• Non vi è alcuno sforzo nella RFC di risolvere il problema dei web server con file system case-insensitive; personalmente proverò ad avanzare una proposta:
  Case-sensitive: [true | false] # default value is true

Ripeto, in sé la mossa di Google è una buona cosa, era fin troppo tempo che si sentiva il bisogno di uno standard ufficiale.
Le mie critiche sono numerose, ma non devono mettere in secondo piano questo punto.
Prima si inizia con uno standard minimale, poi si può sempre migliorare.

E voi, che ne pensate?

[giorgiotave]

Ciao Federico,
grazie per questo aggiornamento, lo citerò su FastFoward.

Stavo cercando di aggiornarmi e sono felice di trovare qui questo contributo così importante.

Devo dire che mi piace molto il "in collaborazione con l'inventore originale del protocollo Martijn Koster e altri motori di ricerca" e mi piacciono un po' meno le altre cose che anche tu critichi. Hai perfettamente ragione: è troppo Google-centrico.

Questa cosa ha alcuni risvolti. Di sicuro notiamo come Google dove agisce lo fa sì per migliorare le cose, ma anche per imporre le sue di interpretazioni.

Noi siamo lontani anni luce da quelle dinamiche, non sappiamo se gli altri motori di ricerca hanno effettivamente partecipato al dibattito. Che poi diciamocolo, su questa cosa in particolare: tutti gli altri si accodavano già a Google in linea generale.

Quindi, forse, è anche giusto che sia così.

Mi piacciono le due cose che fai notare:

• Nota: Seznam, il motore della Repubblica Ceca, ha proposte alternative interessanti: Request-rate (equivalente a Crawl-Delay) e Visit-time, quest'ultima in particolare permetterebbe di sostituire l'impostazione fornita a Bing dal suo Webmasters Tool.
• Non vi è alcuno sforzo nella RFC di risolvere il problema dei web server con file system case-insensitive; personalmente proverò ad avanzare una proposta:
  Case-sensitive: [true | false] # default value is true

Chissà Andrea Pernici (@juanin) cosa ne pensa