Quelli che… “Googlebot non rispetta il robots.txt”

Semaforo rosso e segnale di stop

Se avessi ricevuto un euro per tutte le volte che ho sentito un SEO dire “Google non rispetta il robots.txt” avrei guadagnato circa dieci euro. Quindi l’ho sentito dire solo una decina di volte ma la mera quantità passa in secondo piano quando si scopre che tutte quelle dieci volte coincidevano con errori di interpretazione dell’interlocutore di turno.

Sia ben chiaro: esistono casi particolari in cui Google dichiara esplicitamente ed in piena trasparenza che non rispetterà alcune direttive presenti nel robots.txt, tuttavia il mancato rispetto che ho visto lamentare a diversi webmaster e SEO non fa riferimento a quei casi particolari ma è riferito alle normali attività di crawling di Googlebot.

Per farla breve, secondo i suddetti interlocutori la direttiva Disallow pare sia usata da Google come abituale succedaneo di carta igienica. In questo articolo voglio elencare alcuni di questi episodi e spiegare dove stava l’equivoco che ha generato, di volta in volta, le errate convinzioni.

Quando Google ignora davvero

Vale la pena chiarire innanzitutto in quali occasioni Google si prende la libertà di ignorare effettivamente la direttiva Disallow; ne cito tre perché me ne ricordo tre, se ve ne vengono in mente altre potete contribuire aggiungendole nei commenti.

Il primo caso riguarda lo spider AdsBot-Google, usato per AdWords per analizzare le landing page delle inserzioni e valutarne la qualità. Questo spider rispetta le direttive esplicitamente indirizzate ad esso (attraverso la dichiarazione User-agent: AdsBot-Google) ma ignora le direttive indirizzate genericamente a qualunque spider (User-agent: “*”). Le motivazioni dietro a tale scelta possono essere lette in questa pagina di supporto di Google.

Il secondo caso è più generico ed è stato osservato in passato per alcuni bot di Google dedicati a specifici servizi per gli utenti, per esempio Google Reader, il lettore di feed che Google ha deciso di dismettere. Nei casi in cui Google Reader necessitava di accedere ad una ricorsa web (es: un feed) a seguito di una esplicita richiesta dell’utente, tale accesso avveniva ignorando eventuali direttive Disallow nel robots.txt del sito che ospitava la risorsa.

La motivazione data da Google era che la richiesta andava considerata come una conseguenza all’azione di utente e non era quindi classificabile come l’iniziativa di un automatismo, che invece sarebbe stata soggetta alle direttive del robots.txt. Questa stessa motivazione è stata data in passato per spiegare perché il robots.txt veniva ignorato anche dallo spider che si occupava di creare gli screenshot di “Instant Previews”, le anteprime delle pagine web che apparivano a fianco dei risultati di ricerca quando l’utente spostava il puntatore a destra di un risultato.

Il terzo caso riguarda le pagine su cui viene pubblicato il pulsante “+1” di Google: tutte queste risorse sono considerate pubbliche e accessibili dagli spider di Google a prescindere da quanto chiede il robots.txt, per il motivo che quando un utente clicca il pulsante, Google deve essere in grado di accedere alla pagina per estrarne i dati che poi appariranno nel pop-up di condivisione. Per una spiegazione più elaborata potete leggere la risposta ufficiale di John Mueller in questa discussione su Webmaster Central.

Adesso che ho elencato i principali casi speciali in cui Google dichiara effettivamente di non voler/poter rispettare le direttive del file robots.txt, passo alla sezione più succosa dell’articolo.

Il Disallow, questo sconosciuto

Invece di attaccare col solito pippone accademico sulle basi del robots.txt e sul ruolo della direttiva Disallow, credo che il modo migliore per approcciare i tanti equivoci che ho osservato nel corso degli anni sia quello di elencare le affermazioni che ho sentito e spiegare di seguito dove stava la falla nel ragionamento dell’interlocutore.

Tutte le seguenti obiezioni riguardano il fatto che Googlebot avrebbe apparentemente ignorato la direttiva Disallow nel file robots.txt

1 – “La risorsa in Disallow è presente nelle SERP, quindi Googlebot non ha rispettato il robots.txt”

Questa è probabilmente l’obiezione più diffusa che ho sentito fare.

Una delle ragioni per le quali alcuni SEO ritengono corretta la logica dietro l’obiezione è che pensano erroneamente che la direttiva Disallow serva a chiedere ai motori di ricerca di non indicizzare una risorsa o di non farla apparire nelle SERP.

La direttiva Disallow, in realtà, non ha mai avuto il suddetto scopo. Al contrario, essa è nata solo per dotare i webmaster di uno strumento che consentisse loro di specificare a bot e spider quali risorse del sito non vanno richieste.

La seconda ragione per la quale l’obiezione viene spesso considerata valida è che si crede che una risorsa di cui si impedisce l’accesso agli spider non può apparire nelle SERP. Anche in questo caso si tratta di una convinzione errata, perché una risorsa non è un’entità monolitica ma può essere indicizzata anche parzialmente, presentando in SERP solo informazioni esterne alla risorsa stessa, acquisibili senza accedere ai suoi contenuti.

Riassumendo, non esiste una relazione tra le risorse che uno spider può richiedere ad un server e le risorse che il motore mostrerà nei risultati delle ricerche; le due cose sono distinte e appartengono a due fasi molto diverse del lavoro quotidiano di un motore di ricerca: la prima è quella del crawling e la seconda è quella dell’indexing.

Se non si desidera far apparire una risorsa nelle SERP, l’istruzione corretta è il NOINDEX, erogato attraverso tag meta o intestazioni HTTP.

2 – “Google ha assegnato il PageRank alla risorsa in disallow e questo potrebbe indicare che l’ha scaricata/indicizzata.”

Non esiste alcuna relazione tra l’assegnazione del PageRank ad una risorsa e come lo spider si è comportato nei suoi confronti.

Il PageRank è un valore numerico che vien fuori da un calcolo che si basa esclusivamente sui link ricevuti dalla risorsa. Di conseguenza il motore di ricerca non ha la necessità di richiedere la risorsa per poterne calcolare il PageRank perché, per essere precisi, il PageRank non viene assegnato alla risorsa o ai suoi contenuti bensì al suo URL, che è ovviamente visibile dall’esterno.

Per tale ragione, in nessun modo la presenza di un valore di PageRank può fornire un’indicazione riguardo l’eventuale richiesta della risorsa da parte di uno spider.

3 – “Dai log emerge che il file robots.txt non viene nemmeno letto da Googlebot.”

Questa obiezione sottintendeva che, non leggendo il file robots.txt, Googlebot non si interessasse nemmeno di conoscere quali risorse erano state messe in Disallow dal webmaster.

Nella specifica situazione che mi era stata portata all’attenzione, un’analisi dei log rivelava in realtà che il file robots.txt veniva richiesto, sebbene con una frequenza bassa.

Vale pertanto la pena di ricordare che la frequenza con la quale Googlebot richiede il file robots.txt varia da sito a sito: su siti trafficati quotidianamente dagli spider, il file robots.txt viene a volte richiesto una volta al giorno e a volte molte volte all’interno della stessa giornata.

Tempi maggiori di un giorno possono essere osservati solo nei casi in cui Googlebot ha deciso di non chiedere risorse del sito per diversi giorni, nel qual caso richiedere quotidianamente il file robots.txt risulterebbe superfluo.

La regola generale per comprendere il meccanismo è: “Se Googlebot ha deciso di richiedere una risorsa dal sito e se il file robots.txt posseduto dal motore è più vecchio di un giorno, allora esso viene nuovamente scaricato prima di effettuare le nuove richieste.”

4 – “Su GWT la pagina disallowata appare tra quelle che linkano un’altra risorsa, quindi Google ha sicuramente scaricato la pagina.”

Questa considerazione mi è stata fatta una sola volta e dal punto di vista logico non fa una piega: se su GWT Google mostra di conoscere link provenienti da risorse in Disallow, allora è certo che quelle risorse sono state scaricate.

Nel caso specifico, tuttavia, era successo che i contenuti del file robots.txt erano stati modificati accidentalmente nel corso del tempo e per un periodo di alcuni giorni i file scaricati non erano effettivamente in Disallow.

L’incidente mi dà comunque l’occasione per evidenziare che i più fastidiosi casini di errata indicizzazione che ho osservato nel corso degli anni hanno avuto come causa un’accidentale modifica del file robots.txt. Tenuto conto di quanto Google è famelico nei confronti delle risorse, è facile che un accesso temporaneo ad alcune cartelle possa provocare l’indicizzazione in poco tempo di una grande quantità di risorse secondarie. Questa è una ragione per la quale io suggerisco di dotarsi di un sistema di monitoraggio costante dei contenuti del file robots.txt, in modo da poter reagire velocemente in caso di involontarie modifiche alle istruzioni Disallow.

5 – “Ho aggiunto delle nuove istruzioni Disallow, più restrittive, ma la quantità complessiva delle risorse indicizzate è aumentata!”

Questo fenomeno è reale e a prima vista può sembrare controintuitivo, tuttavia tutto si spiega riprendendo l’ABC del funzionamento di un motore di ricerca e ragionando in particolare sulle relazioni tra la fase di canonizzazione e quella di indicizzazione.

Preciso innanzitutto che l’obiezione non fa riferimento a specifiche risorse in Disallow che vengono erroneamente indicizzate da Google ma riguarda solo la quantità totale di risorse indicizzate, come può essere osservata su GWT o usando l’operatore di ricerca “site:” se ci si accontenta di una (grande) approssimazione.

Come è possibile che aggiungendo istruzioni Disallow o rendendo più restrittive quelle già esistenti Google dichiari una quantità di risorse indicizzate maggiore?

La prima cosa da chiarire è che, nel gergo di Google usato in pubblico, “indicizzato” significa semplicemente “potenzialmente visualizzabile in SERP“. Occhio: non sto parlando di ranking o della capacità della risorsa di essere visibile per specifiche query, mi riferisco solo alla possibilità di poter osservare la risorsa come risultato di ricerca, per esempio cercandone direttamente l’URL completo.

Adesso che è stata data la definizione che Google dà al termine “indicizzato”, bisogna ragionare su come avviene la canonizzazione delle risorse. Quando Google ha pieno accesso alle risorse del sito, è in grado di scoprire sia le risorse principali sia quelle duplicate o estremamente simili. Il motore di ricerca stabilisce che una risorsa è duplicata facendo una comparazione con altre risorse e controllando se i contenuti sono molto simili oppure se le stesse contengono indicazioni esplicite di canonizzazione, attraverso l’apposita relazione “canonical”.

Quando Google ha determinato che alcune risorse sono duplicate, può decidere di non indicizzarle, ovvero di non presentarle mai in SERP.

(Chi ha seguito gli sviluppi di GWT potrà ricordare che queste risorse duplicate venivano in passato dichiarate come “Not Selected” nella pagina “Index Status”, prima che quella statistica venisse tolta per evitare che webmaster e SEO si facessero disidratanti pippe astrospaziali su saltuari picchi o flessioni di quel grafico. Una devastante applicazione di “Ignorance is bliss”.)

Ma che cosa succede quando Google non ha più accesso ai contenuti delle risorse duplicate a causa di Disallow più restrittivi e non può fare le comparazioni che gli consentono di individuare i duplicati? Semplice: le risorse duplicate che vennivano prima “accorpate” a quelle canoniche tornano ad essere indicizzate singolarmente, anche se solo in modalità parziale. Indicizzando le risorse che noi sappiamo essere duplicate, ma che Google non può più riconoscere come tali, il numero totale di risorse indicizzate sale.

Il fenomeno avviene dunque quando attraverso l’uso di nuovi Disallow o modificando i persorsi dei Disallow già esistenti, si chiede il Disallow di risorse che Google trattava come duplicate.

La richiesta di Disallow di questi contenuti duplicati può essere accidentale o volontaria, ma nel caso in cui sia volontaria, è bene ricordare che gli sforzi di canonizzazione non devono/possono fare uso dei Disallow nel robots.txt, in quanto l’istruzione impedisce ai motori di rendersi conto di che cosa il sito effettivamente contiene. Queste raccomandazioni vennero anche date tempo fa sul blog ufficiale di Google dedicato ai webmaster, in questo articolo.

Conclusioni

Quelle che ho esposto in questo articolo sono le obiezioni che mi sono state mosse più frequentemente nel corso degli anni. In generale, mi è parso di osservare una diffusa convinzione che Googlebot ignori le richieste di Disallow, tuttavia io non sono riuscito a trovare prove di tale fenomeno, che finora si è sempre dimostrato essere un equivoco di chi aveva poca dimestichezza con il funzionamento del motore di ricerca.

Molti molti anni fa ricordo di un caso in cui Googlebot aveva erroneamente scaricato una risorsa in Disallow a causa di un bug nello spider; sto comunque facendo riferimento ad un caso isolato avvenuto durante i primi anni di vita di Google, quando le tecniche di crawling non erano sofisticate come avviene oggi.

Da allora, nonostante i gridi di allarme, le investigazioni hanno sempre concluso che il fenomeno non si è mai realmente presentato in nessuno dei casi che mi sono stati sottoposti.

P.S.
Pensavo che sarebbe interessante parlare di argomenti simili in qualche evento. Giusto per dire.

12 Responses to Quelli che… “Googlebot non rispetta il robots.txt”

  1. Matteo scrive il 8 May 2013 at 09:22

    Ciao Enrico e complimenti per gli articoli sempre ben approfonditi.

    Per caso hai anche qualche case history dove il robots.txt non era presente, ma nel GWT vengono segnalate ugualmente url bloccati? Confermo che in nessuna pagina è presente il tag NOINDEX o è stato implementato qualcosa di strano.

    Grazie.

    • LowLevel scrive il 8 May 2013 at 09:46

      @Matteo: Ciao Matteo. L’unico episodio simile a quello che descrivi mi è capitato diverso tempo fa: Googlebot richiedeva il file robots.txt ed il sito presentava allo spider una risorsa HTML, non ricordo se direttamente o attraverso una redirezione. In quel caso Googlebot cercava di interpretare i contenuti della risorsa HTML come se fosse stata un robots.txt e, non riuscendoci, aveva considerato l’intero sito come non accessibile. Il proprietario del sito non era consapevole di quello che veniva erogato allo spider e la cosa venne a galla solo dando un’occhiata ai file di log del web server.

      Non so quanto l’episodio sia simile a quello che citi tu, perché nel mio caso il blocco avveniva su tutte le risorse del sito e non su risorse specifiche.

  2. francesco margherita scrive il 8 May 2013 at 09:38

    Ciao Enrico, non ho capito bene il fatto che l’istruzione disallow significa non richiedere.potresti farmi capire meglio?

    • LowLevel scrive il 8 May 2013 at 09:59

      @Francesco: La direttiva Disallow significa semplicemente “per favore non richiedere la seguente risorsa”. Per “richiedere” intendo il normale meccanismo di richiesta e risposta previsto dall’HTTP: un client richiede una risorsa ad un server ed un server (se vuole e può) gliela invia.

      Il “per favore” è d’obbligo, perché robots.txt e Disallow non creano alcun meccanismo che impedisce fisicamente ad uno spider di chiedere risorse al sito; tutto funziona solo perché gli spider dei principali motori di ricerca si sono impegnati a rispettare il desiderio espresso dai webmaster.

      L’errore frequente che ho visto fare è che diverse persone credono che se uno spider non richiede una risorsa, allora quella risorsa non può apparire nei risultati di ricerca del motore. Questa logica però non è corretta perché nei risultati di ricerca possono apparire anche risorse che non sono mai state richieste dagli spider al sito.

  3. Matteo scrive il 8 May 2013 at 09:54

    @LowLevel Grazie della risposta Enrico!

    Secondo me questo è un caso davvero strano perchè il sito ha circa 200 pagine (219) e quelle sono tutte ok, mentre dal GWT “sbucano” queste 7 url bloccate che non si sa da dove arrivano.

    Abbiamo anche inserito un file robots.txt dove viene aperto tutto il sito e lo spider lo ha preso il giorno dopo, ma a distanza di un mese e mezzo queste 7 url misteriose rimangono bloccate!

    • LowLevel scrive il 8 May 2013 at 10:08

      @Matteo: allora no, mi spiace, non ho mai indagato un caso del genere.

  4. Giacomo Gaggiotti scrive il 8 May 2013 at 10:00

    Ciao Enrico, belle considerazioni come sempre, e complimenti per l’articolo.

    Sai dove cascano secondo me gli asini?

    Inseriscono il disallow ad una risorsa nel robots.txt dopo che la risorsa é stata indicizzata, il risultato sará che Google-bot non crawlerá piú quella risorsa, ma che essa rimarrá comunque indicizzata.

    Secondo me molta gente, come hai ben detto tu, confonde il disallow con il NOINDEX, e non sanno che per rimuovere una pagina dall’indice di Google si deve usare il tag noindex o semplicemente un 404.

    Un esempio banale su come Google bot rispetti l’istruzione Disallow viene delle famose pagine di login di WordPress
    ” wp-admin o wp-login di wordpress” che di default sono immediatamente inserite nel robots.txt di ogni tema wordpress,

    User-agent: *
    Disallow: /wp-login.php o wp-admin che sia

    e a meno che non sia stato modificato prima delle messa online in nessun caso Google indicizza queste pagine, proprio perché non viene permesso al bot fin dall’inzio di leggere queste risorse.

    L’unica indicizzata volutamente che ho trovato, é quella di http://wordpress.com/wp-login.php che appunto ha prima deciso di indicizzarla per permetterne la reperibilitá agli utenti, ma che poi una volta indicizzata é stata anch’essa inserita nel robots.txt, infatti non esiste copia cache di tale pagina.

  5. Matteo scrive il 8 May 2013 at 10:17

    @LowLevel ti ringrazio lo stesso per l’attenzione Enrico! 😀

  6. Giorgia Nicolini scrive il 4 July 2013 at 04:00

    Bell’articolo! Non sono espertissima nel settore SEO (ma spero un giorno di diventarlo) e devo dire che ciò che hai scritto è stato per me illuminante. Bella anche l’aggiunta di Giacomo Gaggiotti.

  7. Lorenzo scrive il 20 July 2014 at 11:43

    Non sono assolutamente d’accordo con quanto lei afferma, la dimostrazione sussiste oggi, per me, quando al cambio aggiorrnamento versione Php del Server che ospita i miei domini .. ogni giorno G. Webmaster invia (mai visti prima) Improvvisi e falsi allarmi che Non riesce a visualizzare ed entrare nei siti web.

    Ma questa è una gran palla di Mr. G. e del suo ragno modificato dalle Holding che lui paga profumatamente per scannar via domini che sono regolarmente attivi e ben registrati da secoli in Webmaster.

    Parlo di domini con in fronte Root semplici pages html e in sotto-directories blog e forum fatti con Drupal 6 , 7 ecc.. regolarmente attivi e ben aggiornarti.

    Come sappiamo il file robot.txt di Drupal và messo in Root anche se drupal viene installato in subdirectory, esempio wwwROOT/drupal.

    Le semplici istruzioni del robot.tx di drupal viene letto come un errore ..mentre invece è solamente un’avvertenza.

    Faccio esempi concreti di un ns. robots.txt
    contiene :

    Disallow: /admin/
    Disallow: /comment/reply/
    Disallow: /filter/tips/
    Disallow: /node/add/
    Disallow: /search/
    Disallow: /user/register/
    Disallow: /user/password/
    Disallow: /user/login/
    Disallow: /user/logout/

    che giustamente servono a indicare a qualsiasi motore di ricerca di non leggersi le pagine di Admin, che per loggare bisogna essersi registrati, ecc.. ecc..

    ———————

    Tutti questi ..OGGI sono diventati errori di scansione per Mr. G.

    Come mai, secondo lei ?
    Come mai non lo erano prima ?

    Il problema è che non hanno più spazio utile e stanno scremando in modo indiscriminato i siti web per incentivare una linea progressiva contro Drupal e contro i siti di piccole e medie aziende a favore dei “Grossi Big” ?

    Cambio di politica basato su una sfacciata new line basata su lecchinismo e servilismo a un web che “da un bel pezzo” è in balia delle multinazionali iuessei ?

    Complimenti se cosi fosse, ma lei ci illumini se ci riesce ..perché la nostra ignoranza è si molto profonda ma la speculazione di queste holding è abissale.

    E non parlo di politica e commercio ma dell’idiozia di dare loro importanza da parte di tutti noi.

    Yahoo è crollata quando la libertà del web fù massacrata?

    Secondo me si, secondo Lei che è un Esperto?

    • LowLevel scrive il 22 July 2014 at 16:21

      @Lorenzo: grazie del commento. Ho qualche difficoltà a mischiare gli aspetti tecnici con quelli politici: sono ovviamente disposto a parlare di ciascuno dei due aspetti tenendoli separati tra di loro, ma evito sempre di metterli assieme perché ho scoperto che quando lo faccio i miei preconcetti politici offuscano la mia capacità di svolgere analisi tecniche obiettive.

      Ho anche realizzato che meno ne so degli aspetti tecnici di qualcosa, più sono indotto a fare congetture che esulano dal contesto tecnico e questo non è buono per me, perché non mi permette di accrescere le mie competenze e mi rende forse anche un po’ paranoico. Con gli anni ho cercato di risolvere il problema alla base: mai fare ipotesi senza prima acquisire dati, anche nei casi in cui fare ipotesi verrebbe molto facile. In questo modo le opinioni soggettive vengono messe da parte e vengono sostituite dai risultati di un’indagine basati su dati concreti e sulla conoscenza di protocolli e standard.

      Sir Arthur Conan Doyle metteva in bocca Sherlock Holmes una sacrosanta perla di rara intelligenza:
      “Never theorize before you have data. Invariably, you end up twisting facts to suit theories, instead of theories to suit facts”

      Confermo comunque quanto scritto nell’articolo: in tutti i casi in cui mi è stato dato pieno accesso a dati e informazioni, è stato facile individuare la causa dell’apparente negligenza di Googlebot, che si è rivelata poi una negligenza di chi avrebbe dovuto gestire bene l’infrastruttura di web server e siti. Ovviamente nel caso specifico citato da te non do una risposta perché non ho valutato la situazione.

      Saluti!

  8. Mystery News scrive il 14 October 2015 at 19:36

    Ciao! Ho una domanda. Sul nostro sito, in trumenti per i webmasetr tra “risorse bloccate” vediamo l’host delle immagini di facebook..questo cosa significa?

    Grazie per il tuo tempo!

Lascia un commento

More in Just SEO
L’analisi SEO del sito attraverso i log del web server

Quanti di voi si sono dedicati almeno una volta all'analisi dei log del web server nel tentativo di capire come...

Close