SEO serendipità: cosa si scopre su Googlebot quando meno te l’aspetti

Penso che la cosa meno noiosa di questo post sia il fatto che include un video in cui ho catturato i comportamenti di Googlebot su un sito. Ve l’ho scritto in cima all’articolo, così non c’è il rischio che ve lo perdiate.

Questa non è la prima volta che mi imbatto in situazioni di serendipità durante i miei test o studi legati alla SEO. Mi pare di averne dato evidenza sul blog durante la mia ricerca sui famigerati “Not Provided”, ma al di là di quanto ho documentato online non sono mancate altre occasioni in cui mi sono imbattuto in qualcosa di interessante mentre cercavo tutt’altro.

Recentemente ho valutando alcune tecniche per incentivare Google ad indicizzare più velocemente i contenuti di un sito ma non vi parlerò di questi tentativi perché i test sono ancora in corso. Quello che invece vi voglio raccontare è ciò che ho scoperto mentre ne portavo avanti uno.

Ne ho tratto un paio di considerazioni molto semplici e per niente sconvolgenti, ma che in futuro potranno essere tradotte in linee guida di buonsenso potenzialmente utili ad altri SEO.

Per queste ragioni, ho pensato di condividere con voi quello che ho osservato.

Scenario: diecimila link in una sola pagina

Uno dei test che sto portando avanti ha richiesto la creazione di una pagina HTML contenente la bellezza di diecimila link che puntano a nuove pagine da indicizzare, ospitate sul medesimo sito.

Le caratteristiche della pagina linkante, che d’ora in poi chiamerò “pagina index” sono le seguenti:

Diecimila link

  • Contiene solo un’intestazione H1 e un elenco di diecimila link
  • Il testo di ciascun link corrisponde ad un ID numerico che identifica la pagina di destinazione
  • L’ordine in cui le pagine vengono linkate sulla pagina è quello del loro ID numerico
  • Ciascun link è separato dal successivo da una virgola e da uno spazio
  • Viene linkata da ciascuna delle diecimila nuove pagine, ma non riceve link dall’esterno di questo microcosmo isolato e composto da 10.001 pagine.

Ecco invece qualche informazione sulle pagine di destinazione dei link:

Esempio dei contenuti di una pagina landing del test

  • Hanno un URL del tipo http://www.sito.com/pagina.php?parametro=123
  • Ho evitato di usare un nome di parametro solitamente associato a ID di sessione
  • Le pagine di destinazione contengono un’intestazione ed alcuni paragrafi di testo composto da parole inventate di sana pianta ma in grado di produrre testi unici, per evitare che risorse troppo simili potessero disincentivare gli spider a richiedere una maggiore quantità di URL
  • Ciascuna pagina riceve un solo link, che proviene dalla pagina index
  • Ciascuna pagina include un link alla pagina index per evitare la creazione di dangling pages (pagine che non linkano nessun’altra pagina), che in pura teoria potrebbero essere gestite diversamente rispetto alle pagine “normali”.

La pagina index è stata fornita allo strumento “Fetch as Googlebot” di Google Webmaster Tools, attivando l’opzione “Submit to index” ed estendendo la richiesta di indicizzazione a tutte le pagine linkate dalla index. Se non conoscete il meccanismo del “Submit to index” potete approfondirlo su questa pagina di aiuto di Google.

A seguito di questa richiesta di indicizzazione i crawled di Googlebot hanno iniziato ad effettuare richiesta delle nuove risorse, che sono state ovviamente memorizzate sui log del web server. Adesso introdurrò brevemente un paio di concetti e poi vi mostrerò come Googlebot ha richiesto le pagine create.

Due grammi di teoria spiccia

Un grafico che mostra una parte della fase di crawlingOgni volta che Google percepisce l’esistenza di un nuovo URL (occhio: URL, non risorsa) esso viene aggiunto ad un database adibito ad ospitare URL e informazioni associate a ciascuno di essi.

A ciclo continuo, uno scheduler stabilisce quali URL nel database devono essere scaricati attraverso i crawler, sulla base di diversi criteri.

In condizioni naturali, uno dei criteri su cui lo scheduler si basa per stabilire una priorità di crawling degli URL nel database è il valore di PageRank assegnato a ciascun URL. Questa non è una novità ed esiste più di un video in cui Matt Cutts afferma esplicitamente che, grossomodo, le priorità di scaricamento delle risorse seguono la distribuzione del PageRank sul web. Uno di questi video è questo qua, un po’ passatello ma ancora attuale.

Nel caso del nostro esperimento, tuttavia, le condizioni non possono essere considerate naturali, per almeno due ragioni:

  1. il test viene fatto su un microcosmo di 10.001 pagine, isolato dal resto del web, che non riceve alcun PageRank dall’esterno e che quindi possiede solo la quantità di PageRank creata dalle 10.001 risorse che lo compongono
  2. non c’è comunque garanzia che la richiesta di indicizzazione fatta attraverso GWT induca lo scheduler a comportarsi secondo gli stessi identici criteri che vengono seguiti durante il normale crawling dei siti web. In particolare, non c’è garanzia che lo scheduler usi il PageRank di ciascuna risorsa per stabilire come e quando essa va fatta scaricare al crawler.

Queste due importanti precisazioni aprono la strada a due possibili scenari, tra di loro alternativi:

a) Il valore di PageRank di ciascuna risorsa è uno dei criteri su cui lo scheduler si basa quando il crawling scaturisce da una richiesta di indicizzazione fatta dal webmaster attraverso GWT. Se così fosse, allora le modalità di scaricamento di ciascuna delle 10.000 pagine sarebbero anche una conseguenza del modo in cui il PageRank della pagina index si divide tra i 10.000 link che essa contiene.
b) Il valore di PageRank di ciascuna risorsa non è uno dei criteri su cui lo scheduler si basa quando il crawling scaturisce da una richiesta di indicizzazione fatta attraverso GWT. In tal caso, le modalità di scaricamento delle risorse avverrebbero seguendo altri criteri.

Sarebbe davvero interessante ed utile se, osservando il comportamento dei crawler, fosse possibile trarre informazioni e linee guida generali su come il PageRank si distribuisce tra i link contenuti in una pagina.

Sebbene il presente test non ha permesso di determinare se le azioni del crawler sono una conseguenza della distribuzione del PageRank tra i link contenuti nella pagina, il comportamento di Googlebot che sto per mostrare attraverso un video lascia intendere che l’obiettivo di raggiungere un verdetto è tecnicamente possibile svolgendo alcuni ulteriori test.

Ecco Googlebot che ciuccia risorse

Nel video che segue, ciascuna colonna rappresenta la quantità di richieste che Googlebot ha fatto di un gruppo di cento URL. Più precisamente, la prima colonna conteggia le richieste ricevute dai primi cento URL (primi = linkati in cima alla pagina index), la seconda colonna conteggia le richieste ricevute dal secondo gruppo di cento URL linkati dalla pagina index, e così via.

Alcune colonne superano quota cento perché Googlebot ha chiesto alcuni URL di quel gruppo più di una volta.

Adesso potete dare un’occhiata al video.

Precisazioni

Va innanzitutto detto che il video riassume l’attività di Googlebot di circa quattro giorni, che ho velocizzato perché escludevo che un video di oltre cento ore potesse risultare appetibile al pubblico. Non senza l’inclusione di GIF animate di gatti, almeno.

La seconda precisazione da fare è che il video non mostra il reale ritmo e la reale frequenza con cui sono state fatte le richieste. La quantità di richieste al minuto non è mai stata costante ma è variata nel tempo.

Per esempio, il primo gruppo di cento URL (la prima colonna da sinistra) è stato scaricato immediatamente e nella sua interezza in un minuto e mezzo di tempo, successivamente la velocità con cui le richieste sono arrivate al server è diminuita molto. Nel dettaglio:

  • URL 1-100: scaricati in 90 secondi (circa una richiesta al secondo)
  • URL 101-1000: scaricati in 15 ore (circa una richiesta al minuto)
  • URL 1001-10000: scaricati in 115 ore (una richiesta ogni 1,3 minuti)

Analisi del comportamento di Googlebot

Spider che ride

L’immediatezza e maggiore velocità che sono state adottate per scaricare i primi cento URL linkati dalla pagina index rende palese che gli URL non vengono trattati tutti allo stesso modo. E’ emerso con chiarezza che ad alcuni URL (quelli in cima) è stata assegnata una priorità di scaricamento ben superiore.

Una volta terminato lo scaricamento dei primi cento URL, Googlebot si è dedicato ai successivi 900, snobbando temporaneamente del tutto i rimanenti 9000 altri URL linkati dalla pagina index.

Come si vede dal video, questo secondo gruppo di 900 URL è stato scaricato in modo parallelo e non sequenziale; in altre parole, sono stati scaricati senza un ordine particolare tra loro. L’unico obiettivo di Googlebot sembrava quello di portarsi a casa i primi 1000 URL linkati dalla pagina index.

Una volta ottenuti i primi 1000 URL, Googlebot si è dedicato alla richiesta dei rimanenti 9000, dando evidenza di due principali fenomeni:

  • un primo flusso di richieste si è occupato di accedere ai 9000 URL in modo parallelo, ovvero richiedendo gli URL dell’intero gruppo senza un ordine preciso;
  • un secondo flusso di richieste si è occupato di richiedere URL in modo ordinato e sequenziale, dagli URL linkati più in alto sulla pagina index agli URL linkati più in basso.

Potete notare la combinazione di questi due fenomeni di crawling osservando nel video che al crescere lento e complessivo di tutte le colonne appartenenti al gruppo dei 9000 URL, da sinistra avanza inesorabile un crawling colonna-per-colonna, ovvero sequenziale.

Possono essere osservati diversi altri fenomeni particolari di crawling, per esempio a volte un crawling sequenziale focalizzato su un gruppo di URL più distante dalla cima si interrompe (una colonna smette di crescere in altezza) per dedicarsi temporaneamente alla richiesta di URL distribuite lungo sezioni più larghe del grafico.

I più curiosi tra di voi non mancheranno di individuare ulteriori particolarità nel comportamento di Googlebot, che comunque sono in parte tipiche dei sistemi di crawling distribuiti.

Osservazioni e prime conclusioni

La soglia dei primi cento link

Il fatto che sia stata dedicata un’attenzione maggiore ai primi cento URL linkati in cima alla pagina index riporta alla memoria una vecchia linea guida di Google, ormai scomparsa da un po’ di tempo, che suggeriva ai webmaster di evitare di inserire in una pagina una quantità di link superiore a cento.

Non c’è modo di sapere se quella raccomandazione era effettivamente legata ad una sorta di trattamento di “classe B” per i link successivi al centesimo, ma la corrispondenza con la cifra tonda di cento ed il fatto che il crawling ha effettivamente mostrato sugli URL linkati dai primi cento link un favoritismo esplicito in termini di velocità, regala un paio di coincidenze che a mio parere sarebbe poco accorto ignorare.

Niente limiti per il database di URL

All’inizio del test, osservando che solo i primi mille URL venivano richiesti dallo spider, non escludevo che i rimanenti 9000 non fossero nemmeno andati a finire nel database di URL, ovvero che Google si auto-imponesse di ignorare volutamente i link successivi al millesimo.

Concluse le richieste relative ai primi mille URL, tuttavia, Googlebot è passato ad occuparsi dei rimanenti 9000, quindi penso di poter concludere che (almeno fino al tetto iperbolico di diecimila link) non esiste un limite massimo di link per pagina oltre il quale gli URL non vengono più aggiunti nel database di URL.

Questa conclusione è compatibile con la considerazione, ormai universale e palese per tutti, che Google è incredibilmente famelico e poco incline a porsi dei limiti, compatibilmente con gli obiettivi di ottimizzazione della banda.

Una seconda soglia di 1000 link?

Non è corretto usare un solo test per generalizzare un fenomeno. Il fatto che gli URL associati ai primi mille link nella pagina index siano stati richiesti con modalità differenti da tutti quelli successivi, rende opportuna la pianificazione di ulteriori test per comprendere se la gestione particolare dei primi mille URL linkati rappresenta un caso particolare oppure una modalità di crawling applicata in tutti i casi.

Se procederò con test volti a far chiarezza su questo specifico punto, ve ne darò visibilità attraverso il blog.

La funzione del PageRank

Come accennato nella sezione “Due grammi di teoria spiccia”, questo specifico test non permette di capire se la maggiore attenzione assegnata ai primi cento URL linkati dalla pagina index è una conseguenza di come il PageRank della pagina è stato distribuito tra i diecimila link contenuti.

Sarebbe utile riuscire a determinare con certezza se ciascuno dei primi cento link di una pagina trasferisce più PageRank dei link successivi al centesimo. La cosa bella di tutto ciò è che è possibile scoprirlo con certezza, svolgendo appositi test aggiuntivi, che mi riprometto di pianificare.

La funzione degli ID numerici negli URL

Nella pagina index, i diecimila URL vengono linkati in ordine di ID numerico. Non si può escludere a priori che Google abbia ordinato gli URL in base all’ID numerico che contenevano e non in base alla posizione nella pagina dei link che conducevano alle risorse. Sarà necessario fugare questo dubbio.

Gli aspetti visuali

Durante tutto questo articolo ho fatto riferimento ai “primi link della pagina” intendendo quelli che appaiono visualmente in cima alla pagina, che in questo caso corrispondono anche a quelli che sono in cima al codice HTML.

Il test però non fornisce alcuna informazione su quale sia il criterio che Google effettivamente segue per stabilire cosa stia “in cima”; non sappiamo se nei contesti di crawling il criterio di Google è visuale o se l’ordine viene attribuito tenendo conto del solo codice HTML.

E’ vero che esistono specifici algoritmi di Google che tengono conto della posizione effettiva degli elementi di una pagina in base a come essa verrà renderizzata dai browser degli utenti, ma si tratta di algoritmi di alto livello, dedicati al ranking. Non è detto che simili criteri di valutazione entrino in gioco anche in fase di crawling, ovvero durante una fase preliminare della pipeline.

Fortunatamente, anche in questo caso sarà possibile svolgere ulteriori test volti a determinare se in fase di crawling Google applica criteri visuali o se tiene conto solo di come i link appaiono nel codice HTML della pagina.

Google Webmaster Tools non è Google

Non va mai dimenticato che il crawling delle 10.001 risorse è scaturito solo a seguito di una richiesta esplicita fatta attraverso il pannello di GWT. Non sarei affatto stupito se venisse fuori che i comportamenti di Googlebot osservabili nel video sono diversi dai comportamenti di Googlebot durante il normale e spontaneo crawling dei siti. Sarà necessario approfondire questo aspetto.

I prossimi passi

Gli obiettivi per i quali ho ideato il test non c’entravano un fico secco con il crawling di Googlebot ma adesso che esiste evidenza di peculiari comportamenti del crawler durante lo scaricamento delle risorse di un sito, vale la pena svolgere nuove investigazioni, che saranno in grado di determinare:

  • se le richieste di crawling avviate da GWT vengono eseguite seguendo gli stessi criteri applicati al normale crawling dei siti web
  • se gli URL vengono richiesti nell’ordine con cui sono linkati oppure nell’ordine degli ID presenti negli URL
  • se in fase di crawling vengono adottate valutazioni visuali delle pagine web
  • come il PageRank si distribuisce tra i link in una pagina
  • se esistono soglie o limiti numerici nella quantità di link per pagina che sarebbe bene non superare o raggiungere

Per il momento, accontentiamoci di aver confermato con i nostri occhi che i link su una pagina non sono tutti uguali e diamoci appuntamento al prossimo test rivelatore di questa serie!

17 Responses to SEO serendipità: cosa si scopre su Googlebot quando meno te l’aspetti

  1. niguli scrive il 31 October 2013 at 10:13

    Molto interessante questo test. Una curiosità forse stupida: hai caricato un file sitemap e forse l’hai anche inviato via GWT ?

    • LowLevel scrive il 31 October 2013 at 10:25

      @niguli: Ciao. No, non è stato usato alcun file sitemap. Google ha appreso dell’esistenza della pagina index solo attraverso la funzionalità di crawling prevista da GWT.

  2. Michele De Capitani (@dechigno) scrive il 31 October 2013 at 10:57

    @LowLevel grazie per aver condiviso i risultati di questo test. Sono d’accordo con te che il comportamento di Google-Bot è diverso quando è stimolato dal pulsante “Invia all’indice” del GWT rispetto al crawling tradizionale. Non ho test dimostrativi, ma a pelle mi pare proprio di si! 🙂

  3. Orazio Tassone scrive il 31 October 2013 at 12:04

    Hai anche tracciato il numero di volte che lo spider è passato nella pagina index?

    C’è stata qualche visita poco prima di iniziare a spiderizzare i successivi 9.000? Sei certo che tutti e 10.000 indirizzi sono stati messi nel db alla prima lettura della pagina?

    • LowLevel scrive il 31 October 2013 at 14:42

      @Orazio: ciao, sì, ho traccia anche delle richieste fatte alla pagina index.

      La pagina index è stata richiesta dieci volte durante il periodo di quattro giorni, in tempi e giorni diversi. Prima che lo spider iniziasse a chiedere URL con ID superiore al 1000, la pagina index è stata chiesta quattro volte.

      Non ho modo di sapere quando le rimanenti 9000 URL sono state aggiunte al database di URL, perché il meccanismo di aggiunta è strettamente interno. L’unica conclusione che si può fare è, come detto nell’articolo, che non esiste un limite massimo di link in una pagina oltre il quale i relativi URL non vengono più aggiunti al database di URL.

      Volendo fare una congettura, sarebbe più coerente credere che l’aggiunta immediata di tutti gli URL al database di URL abbia per il motore un costo inferiore. Sarei stupito nello scoprire che Google ha progettato un meccanismo che necessita il re-crawling delle pagine linkanti per acquisire maggiori quantità di URL precedentemente ignorati. Costa molto meno riprenderli dalla copia della risorsa che Google conserva in forma grezza nei propri archivi, oppure inserirli tutti in database alla prima occasione.

  4. simone scrive il 31 October 2013 at 12:48

    il filmato è qualcosa di meraviglioso 🙂

  5. Gianmaria Allisiardi scrive il 31 October 2013 at 14:26

    Articolo molto molto interessante…

    Il fatto che dopo i 7000 link ha lasciato che il lavoro venisse concluso da quello che tu hai definito come “flusso parallelo” sembrerebbe fissare un limite intermedio a 7000.

    Il video è bellissimo, potrebbe pero’ essere utile creare un grafico che mostri il TEMPO in cui queste richieste arrivano.

    Altri dati interessanti potrebbero arrivare dall’analisi degli IP degli spider. Si potrebbe scoprire che certi IP si occupano del lavoro “parallelo” che è definibile come approccio standard e costante sul sito (lentamente faccio tutto), mentre altri si occupano di quello che tu definisci “seriale”, che probabilmente viene svolto da una sorta di Special force, che arriva dove c’è necessità di potenza di calcolo, e attacca la massa di lavoro fino a certi limiti in tempi brevi (7000 appunto).

    • LowLevel scrive il 1 November 2013 at 00:00

      @Gianmaria: sì, pare che dopo i 7000 sia avvenuto qualcos’altro.

      Riguardo gli IP, la stragrande maggioranza delle richieste è stata effettuata da un solo IP e questa, sono certo, è una caratteristica che distingue il crawling chiesto via GWT dal crawling “normale”.

      Sono stati saltuariamente usati una manciata di altri IP, ma solo per richiedere poche decine di file. Non sono stato in grado di individuare nell’utilizzo di questi altri IP un pattern di alcun genere. Anche mettendo tutte le richieste su Excel e facendo delle pivot per tentare di far emergere particolarità legate a specifiche caratteristiche delle richieste (per esempio la dimensione in byte delle risorse scaricate) non è emerso alcun filo conduttore.

      Questo il dettaglio degli IP e della quantità di file richiesti da ciascuno di essi:

      IP Number of requests
      66.249.73.192 10386
      66.249.64.3 68
      66.249.64.2 57
      66.249.64.4 44
      66.249.66.160 2
      66.249.75.160 1
      66.249.66.170 1
      66.249.66.150 1
      66.249.74.180 1
  6. Luca Bove (@lithops) scrive il 31 October 2013 at 16:22

    l’id numerico del parametro potrebbe far comportare Google in maniera “strana” (URL guessing).

    Ho una case history di un sito molto grosso che aveva la paginazione simile a quella ed è andato avanti ad indicizzare pagine fittizie per centinaia di pagine.

    Come dici te sarebbe bene testare anche parametri non lineari…

    • LowLevel scrive il 1 November 2013 at 00:06

      @Luca: nel caso in questione mi sento di escludere episodi di URL guessing, perché il crawler ha richiesto esclusivamente gli URL linkati sulla pagina index. Concordo con la necessità di fare un test in cui il valore dei parametri sia pseudocasuale.

  7. Francesco scrive il 1 November 2013 at 23:42

    Molto interessante. Come hai fatto ad animare il grafico? 😀

    • LowLevel scrive il 2 November 2013 at 00:59

      @Francesco: ho usato HighCharts ed ho programmato uno script in JS che aggiorna le altezze delle colonne pescando da una lista degli ID richiesti da Googlebot. 🙂

  8. Alessandro scrive il 2 November 2013 at 14:02

    Complimenti per l’azzeccatissima colonna sonora del video!

  9. Marco D'Amico scrive il 2 November 2013 at 18:29

    Test molto interessante. Grazie per averlo condiviso.

    Sarà altrettanto interessante osservare come si comporterà lo spider nei prossimi giorni. Inoltre sono curioso di sapere se Googlebot richiederà altre risorse con id superiore a 10.000.

  10. seotorino scrive il 3 November 2013 at 08:13

    Sarebbe più interessante sapere con quale frequenza, numero e posizione in base a una query (non saprei quale, forse alfa-numerica) queste pagine si notano nelle SERP (?) che googlebot sia uno spyder specializzato nella ricerca di links non mi meraviglia… cmq bell’esperimento!

  11. Gianmaria Allisiardi scrive il 4 November 2013 at 11:17

    Dagli IP non emerge nulla di interessante purtroppo. Era un idea per tentare di scoprire qualcosa in piu’. Peccato.

    Resta comunque il dato interessante che in meno di 5 giorni ha comunque letto tutti i 10.000 url di una pagina.

    Il dato di 1000 url in 15 ore è comunque confortante.

    Sai dirmi la tempistica (anche approssimativa) sulle prime 7000 pagine?

    Grazie

  12. Alessandro Zuddas scrive il 4 November 2013 at 20:30

    Ho letto tutto con molto interesse e porgo i miei complimenti per tutto il blog in generale.

    Mentre ragionavo sugli scaglioni in cui i link sono stati divisi mi sono chiesto in che modo google bot possa aver trattato il backlink all’index presente in tutte le pagine destinazione.

    Per quello che ne so, quando il crawler incontra un link, lo piazza nel database degli url in coda per una scansione, quindi credo che sia lecito pensare che il link all’index sia finito nella coda degli url da scansionare ogni volta che una pagina destinazione sia stata analizzata.

    Mi chiedo quindi cosa accade quando l’url dell’index viene processato l seconda volta? e la terza? e la centesima?

    Sono sufficientemente sicuro che riconosca la risorsa come già scansionata, e quindi eviti di infilarsi in loop inutili, ma osservando il comportamento del bot sui link oltre il centesimo mi viene da pensare:
    “E se in realtà ogni scansione prelevi solo 100 link e quindi l’indicizzazione di quelli successivi sia dovuta alle scansioni seguenti dell’index?”
    Mi spiego, immaginando le scansioni organizzate a scaglioni si avrebbe un comportamento del genere:
    Scansione livello 1:
    index

    Scansione livello 2:
    primi 100 url di destinazione

    Scansione di livello 3:
    100x index
    (dato che ogni pagina del livello 2 la richiama)

    Scansione di livello 4:
    100x ulteriori 50 url di destinazione NON scansionati
    (dato che ha riconosciuto che l’index era già stata processata e ne ha ridotto la priorità)

    e così via…

    Notare come ho usato quel “50” nel livello 4 puramente a caso.

    In questo modo si spiegherebbe il comportamento preferenziale sui primi link ed anche i vari gruppi di analisi in parallelo.
    Le richieste multiple a varie risorse che fanno sforare il 100 alle colonnine sarebbero spiegati dal fatto che viaggiando i thread in parallelo, qualche volta due di essi accedono alla stessa risorsa per un problema di programmazione concorrente.

    Non so se questo argomento sia stato trattato già altrove nel blog o se da qualche parte nel web ci sia qualche informazione che lo avvalori o lo neghi, ma grazie comunque per l’attenzione.

Leave a Reply

Your email address will not be published. Required fields are marked *

More in Just SEO
Come funziona Google (solo un antipasto…)

Vi chiedo di prestare attenzione. Non l'ho mai fatto finora ma stavolta si tratta di un'occasione molto particolare. Quanto segue...

Close