Come funziona Google (solo un antipasto…)

La pipeline di Google

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

Quanto segue è un assaggio di quello che stava diventando un mastodontico e ingestibile articolo sullo scibile tecnico di Google, iniziato a scrivere diverso tempo fa.

Sono arrivato ad un punto in cui ho dovuto realizzare che un post in un blog non è più il contesto e metodo giusto col quale fornire questo tipo (e questa quantità) di informazioni. Per tante ragioni.

In un certo senso, mi sono arreso. Ma da un’altra prospettiva ne è nato qualcosa di molto molto più interessante.

Quindi ho deciso di proporvi oggi questa “opera incompiuta” e vi chiedo di fare un salto sul blog domani, 10 ottobre 2013, per darvi una notizia e per mostrarvi in che cosa ho trasformato questo articolo.

Se mi seguite da un po’ di tempo, sono certo di poter stuzzicare il vostro interesse.

A domani!

Aggiornamento: il 10 ottobre 2013 è arrivato e potete leggere la novità: Come funziona Google (sul serio).

Un assaggio di come funziona Google

Il diagramma che capeggia in cima a questo articolo è stato creato partendo da quello mostrato da John Mueller (Google) durante un Hangout tenutosi nell’agosto 2012 ed estendendolo con un paio di elementi.

In occasione dell’hangout, John si è purtroppo limitato ad usare il grafico per spiegare come Google gestisce i contenuti duplicati ma io ho ritenuto che lo schema, opportunamente ampliato, potesse dimostrarsi uno straordinario strumento per introdurre il funzionamento di Google, principalmente per ciò che riguarda le fasi di spiderizzazione e indicizzazione.

Essendo la SEO una disciplina nata in modo molto empirico, la percentuale di SEO che si son presi la briga di studiare su libri e documentazione com’è fatto e funziona un motore di ricerca non è mai stata altissima. Ho sempre considerato questo scenario un po’ anomalo, perché è come se coloro che devono perorare una causa davanti ad un giudice (Google) non avessero studiato il sistema di leggi su cui il giudice baserà le proprie sentenze.

Eppure le informazioni sull’architettura di un motore possono essere di estremo aiuto per fare deduzioni corrette durante un’analisi SEO, per identificare le cause più probabili di un’azione intrapresa da Google o per comprendere quello che accadrà dopo l’implementazione di modifiche ad un sito.

Per questa ragione ho pensato di partire dal diagramma di John, aggiungervi elementi che mi servono per affrontare temi importanti per i SEO e di scrivere il presente articolo.

Il post è inoltre disseminato di paragrafi “Ecco perché“, ovvero punti in cui riprendo alcune comuni nozioni SEO che solitamente siamo indotti ad imparare a memoria come pappagalli e faccio notare come sono in realtà una semplice conseguenza del modo in cui Google ha progettato il motore di ricerca, a riprova di quanto la conoscenza del funzionamento di un motore si può trasformare in uno strumento per effettuare deduzioni utili al lavoro quotidiano.

Una visione ad alto livello

Il diagramma che propongo rappresenta uno schema estremamente semplificato del funzionamento del motore di ricerca. Va considerato uno schema strettamente concettuale, che mette da parte la complessità delle reali implementazioni per fornire una visione d’insieme delle fasi principali tra cui si divide l’attività di Google.

Il grafico risulta semplificato anche per quanto concerne le connessioni tra i vari moduli presenti ed ho fatto il possibile per mostrare un processo quanto più lineare possibile. Per questa ragione, nonostante nella realtà ciascuno dei moduli presenti nel diagramma entra in gioco in più di una fase del processo, ho evitato di aggiungere ulteriori frecce tra un modulo e l’altro, per evitare di ottenere una incomprensibile spaghettata di collegamenti.

Vale anche la pena di precisare che essendo un diagramma di tipo logico, e non fisico, non è nato per dare indicazioni sull’infrastruttura hardware del motore. Scendendo più a “basso livello”, infatti, sarebbe necessario specificare in che modo i dati posseduti da Google vengono organizzati e conservati, informazioni che sono state rese disponibili al pubblico in modo molto parziale. Alla fine dell’articolo fornirò comunque un link di approfondimento che riguarda anche l’infrastruttura hardware.

Il flusso descrive prevalentemente la gestione delle risorse web di tipo HTML, acquisite attraverso il normale crawling. Lo schema è invece poco adatto a descrivere il funzionamento dei motori di ricerca verticali di Google (news, video, immagini, prodotti, ecc.), per i quali sarebbe necessario fare approfondimenti a parte.

Per ultimo, devo specificare che il diagramma non è focalizzato sul ranking/search, che rimane comunque come fase ultima di tutto il lavoro svolto dal motore. Sono consapevole che i SEO sono interessati principalmente al ranking, ma il ranking è “solo” una conseguenza di altri processi ed è studiando questi processi che si acquisisce la capacità di predire eventi e mosse di Google, comprese quelle relative al ranking.

Le principali fasi del processo

Per introdurre il funzionamento nella sua interezza e per illustrare la funzione di ciascun modulo presente nel diagramma, inizierò a descrivere l’iter ideale e semplificato di una risorsa. Potete scorrere il grafico da sinistra a destra.

Si parte da un database di URL, che contiene la risorsa di cui sto illustrando il percorso. L’URL della risorsa, assieme ad altri, viene fornito ad uno scheduler, che ha il compito di pianificare quando i crawler dovranno prendere in carico il suo download.

I crawler ricevono dallo scheduler l’ordine di effettuare la richiesta della risorsa, ne fanno il download e conservano i contenuti del documento in un database.

Successivamente un parser estrae la risorsa dal database e ne legge i contenuti, separandoli a seconda della tipologia. Se la risorsa contiene link, gli URL a cui essi puntano vengono aggiunti al database di URL e l’esistenza dei link viene memorizzata nel link graph.

Il parser ha anche il compito di estrarre i testi contenuti nella risorsa e di passarli all’indexer, ovvero alla fase in cui vengono creati dei riferimenti tra la risorsa e le parole/frasi che essa contiene (sto banalizzando molto; la sezione apposita dedicata all’indexer scenderà nei dettagli).

L’ultima fase del processo è quella della Search, che ha il compito di ricevere le richieste (query) degli utenti e di creare dei risultati attingendo alle informazioni che sono state acquisite durante le fasi precedenti.

L’iter appena descritto è abbastanza simile a quanto avviene effettivamente in realtà, sopratutto da quando Google ha implementato, nel 2010, l’infrastruttura Caffeine. Abbandonando lente fasi di indicizzazione “in batch” di grandi gruppi di risorse, Caffeine ha reso possibile l’indicizzazione pressoché immediata di ogni nuova risorsa scoperta, che quindi attraversa autonomamente tutte le fasi sopra descritte.

Attività trasversale: la canonicalizzazione

A far capolino in un paio di punti del diagramma c’è anche l’attività di canonicalizzazione delle risorse che, come si può notare, non è svolta in un singolo punto del flusso ma viene invece divisa in sotto-attività da svolgere in momenti diversi.

Per questa ragione è corretto considerare la canonicalizzazione un’attività “trasversale” all’intero flusso e non una fase a sé stante.

C’è ovviamente una ragione per questa suddivisione dell’attività in fasi diverse: la canonicalizzazione di una risorsa viene effettuata applicando diverse metodologie ed alcune di queste metodologie possono essere svolte più efficientemente durante la fase di crawling, mentre altre richiedono informazioni che Google estrae solo durante la fase di indicizzazione.

Questa è la ragione per la quale trovate un riferimento alla canonicalizzazione in fase di scheduling/crawling ed un riferimento durante la fase di indexing. Esiste in realtà una terza attività di canonicalizzazione, che ho però volutamente non citato perché attinente alla fase di presentazione dei risultati delle ricerche, che ho volutamente deciso di non approfondire.

Introduzione al concetto di “crawling”

Una prima e importante precisazione sul crawling è che ciò che viene comunemente chiamato “crawler”, cioè un software che scarica pagine e cerca al loro interno link ad altre risorse, è in realtà un insieme di più moduli e fasi.

Come già accennato nella sezione “Una visione ad alto livello”, ciascuna delle fasi del crawling viene gestita da software specifici, nella fattistecie sono lo scheduler, il parser e quello che nel diagramma originale di John Mueller viene chiamato “crawler”.

Per dirla tutta, nel momento in cui le sotto-attività del crawling vengono divise tra software diversi, è più corretto chiamare “fetcher” (un software che si limita a fare download di risorse) il modulo che nel diagramma viene chiamato “crawler”. Probabilmente Mueller ha lasciato questa dicitura per ragioni di facilità di comprensione ma la precisazione che ho fatto è necessaria per introdurre il primo “Ecco perché”.

Ecco perché. In un altro articolo di LowLevel.it, dedicato alla erronea convinzione che “i crawler seguono i link“, spiegavo proprio che il crawler è solo un fetcher, ovvero solo un downloader di risorse. Tutte le attività di individuazione di nuovi link e di pianificazione dei download delle nuove risorse viene in realtà svolta da altri software, come già accennato nella sezione “Le principali fasi del processo” e mostrato dal diagramma. Questa è la ragione per la quale uno spider (cioè un fetcher) che richiede una risorsa non “sta arrivando” da alcuna altra risorsa: gli è stato semplicemente ordinato di scaricare un file.

Il crawling è “il regno degli URL e del protocollo HTTP”, perché in questa fase preliminare il motore di ricerca si focalizza nell’individuare nuovi URL che non conosce, richiedere le risorse ad essi associate e cercare al loro interno link verso nuovi URL.

La suddetta considerazione è importante per chiarire che durante il crawling i contenuti delle risorse scaricate vengono in gran parte ignorati, tranne per la finalità di cercare al loro interno eventuali link ad altri URL. Siamo dunque ancora distanti dalle fasi in cui il codice HTML ed i testi della risorsa vengono analizzati per finalità più complesse, come l’indicizzazione.

Come spiegherò nella sezione dedicata al crawler, il fatto che nella prima fase di approccio con una risorsa il motore di ricerca si limiti a gestire solo URL e transazioni attraverso il protocollo HTTP, ha implicazioni di ordine pratico per i SEO.

Il database di URL

Per un motore di ricerca appena nato, il database di URL viene inizialmente riempito di URL provenienti da archivi di pubblico dominio o messi a disposizione da aziende specializzate. Il database poi cresce nel tempo perché viene alimentato con nuovi URL scoperti all’interno delle risorse già scaricate.

Quando Google iniziò la propria avventura, il “seme” di URL iniziali dai quali far partire le attività di crawling comprendeva l’archivio di siti recensiti da DMOZ (Open Directory Project). Siccome l’archivio di siti di DMOZ cresceva nel tempo, Google si occupava anche di riversarlo periodicamente nel proprio database interno di URL da spiderizzare.

Ecco perché. Sebbene Google abbia specificato più volte che i siti recensiti da DMOZ non ricevevano alcuna preferenza nei risultati delle ricerche, i SEO hanno sempre percepito dei vantaggi ad essere presenti nella directory. Uno dei vantaggi costisteva proprio nel fatto che, aggiungendo periodicamente al proprio database di URL l’elenco di siti recensiti da DMOZ, Google (quasi) garantiva a quei siti la presenza nel proprio indice.

Oggi il database di URL di Google viene alimentato da una moltitudine di fonti. Oltre ai link scoperti perlustrando il web, nel database vengono riversati anche URL che provengono da sitemap XML, feed, attività sui pulsanti +1, submission fatte dai gestori dei siti attraverso il pannello GWT e probabilmente URL provenienti da tante altre fonti differenti.

Ecco perché. Da secoli, Google mette a disposizione di webmaster e proprietari di siti di uno strumento pubblico per aggiungere URL al proprio database e molti SEO hanno creduto per diverso tempo che lo strumento permettesse di aggiungere risorse nell’indice quando in realtà si è sempre limitato ad aggiungere URL al database di URL.

Non deve comunque essere commesso l’errore di credere che la presenza di un URL nel database produca necessariamente il suo scaricamento da parte di uno spider. La decisione di scaricare o meno una risorsa, infatti, è solo di competenza dello scheduler.

Ecco perché. Il fatto che la conoscenza di un URL da parte di Google e la decisione di scaricare la risorsa associata sono due attività del tutto distinte spiega anche perché Google non garantisce che gli URL forniti dai webmaster attraverso i file sitemap XML vengano poi effettivamente scaricati da uno spider.

In altre parole, lo scheduler va “incentivato” a prendere la decisione di assegnare ad un crawler il download di una risorsa.

Lo scheduler

Lo scheduler svolge quasi tutte le attività decisionali che solitamente i SEO attribuiscono agli spider. Il compito di questo modulo è quello di decidere quali URL vanno passati ai crawler e quando una risorsa già scaricata va richiesta nuovamente.

Come ho già spiegato nell’articolo dedicato all’analisi SEO del sito attraverso i log del web server, uno dei segnali presi in considerazione dallo scheduler per stabilire quali URL passare al crawler è il valore di PageRank attribuito a ciascun URL ed è corretto dire che il crawling di un sito avviene in modo più approfondito e più frequente all’aumentare del valore di PageRank delle proprie risorse.

L’articolo linkato introduce anche alcune tipiche attività di crawling, quali il full recrawl e il crawling di risorse appartenenti all'”hidden web”. Tutte le attività citate (e probabilmente diverse altre) vengono orchestrate dallo scheduler, a cui spetta la decisione finale su quali risorse di un sito scaricare.

Si potrebbere commettere l’errore di credere che una risorsa non richiesta ad un server equivalga ad una risorsa non indicizzata o, per dirla con altre parole, che chiedere allo scheduler di non richiedere una risorsa equivalga ad impedire all’indexer di non associare alla risorsa uno o più termini/frasi. In realtà, come spiegherò nella sezione legata all’indexer, questa assunzione è errata.

Un’importante attività svolta dallo scheduler è inoltre quella di applicare una prima forma di canonicalizzazione delle risorse. Come spiegato, la fase di crawling si focalizza sugli URL e non sui contenuti delle risorse, di conseguenza le attività di canonicalizzazione svolte in questo contesto sono solo quelle che possono essere svolte basandosi esclusivamente sugli URL delle risorse.

Per esempio, lo scheduler riceve da GWT le direttive che i gestori dei siti hanno imposto sulla gestione dei parametri degli URL. Seguendo le direttive, lo scheduler può rimuovere o mantenere ciascun parametro, così come attribuire loro dei valori stabiliti dal webmaster.

Questa prima attività di canonicalizzazione, tuttavia, non si limita ad eseguire sugli URL le modifiche che i gestori del sito hanno richiesto attraverso il pannello di GWT associato al sito web. Al contrario, in mancanza di quelle informazioni lo scheduler possiede comunque una serie di euristiche che gli consentono di prendere da sé alcune decisioni. Una delle decisioni più semplici da prendere è quella di rimuovere dagli URL eventuali ID di sessione o il fragment (il testo introdotto dal carattere cancelletto).

Una volta prese le decisioni su quali URL richiedere ai server dei siti web, lo scheduler passa tali informazioni al crawler.

Il crawler

Come detto, chiamarlo “crawler” è un po’ fuorviante perché per “crawler” si intendono software che svolgono attività che nel caso di Google vengono assegnate ad altri elementi del diagramma, tuttavia ho deciso di mantenere il naming proposto da John Mueller per ragioni di semplicità e di compatibilità con il diagramma diffuso da lui. Sappiate dunque che da questo momento in poi per “crawler” intenderò solo il “modulo” che nel grafico è chiamato in tale modo.

Il compito del crawler è quello di scaricare le risorse che gli vengono assegnate dallo scheduler. Il crawler effettua delle richieste HTTP di tipo GET nei confronti degli URL che gli sono stati indicati e gestisce il risultato della richiesta, che ovviamente varia a seconda dei casi. Si noti che il crawler è progettato per gestire le transazioni HTTP e quindi riceve e può analizzare le intestazioni HTTP di risposta dei web server, tuttavia non svolge attività di analisi dei contenuti della risorsa.

Il crawler deve essere provvisto di una logica in grado di gestire nel migliore dei modi tutti i potenziali fenomeni che possono scaturire dalla richiesta di risorse: redirezioni, risorse inesistenti, errori dei web server, e così via. Si noti però che per “gestire” si intende il più delle volte “prendere atto della situazione” e passare ad altri software il compito di prendere le decisioni più opportune.

Per esempio, alla ricezione di uno status HTTP 404 alla richiesta di un URL il crawler reagisce memorizzando questa informazione nel database di URL, passandola indirettamente al software deputato ad organizzare le future richieste, ovvero allo scheduler, a cui tocca stabilire se e quando ritentare la richiesta dell’URL che ha prodotto l’errore 404.

Esistono inoltre dei meccanismi che consentono di trasferire l’informazione sull’errore 404 a tutti quei software che ne possono fare buon uso: l’indexer potrà decidere di de-indicizzare la risorsa e il software deputato alla gestione del link graph (che nel diagramma non ho esplicitato, ma che esiste) potrà decidere di rimuovere dal grafo i link che Google sapeva essere presenti nella risorsa scomparsa.

Il crawler si occupa anche della richiesta e interpretazione dei file robots.txt, a cominciare ovviamente dalla gestione delle istruzioni Disallow.

Ecco perché. Siccome tra webmaster e SEO è sempre esistita un po’ di confusione sul reale ruolo e scopo dell’istruzione disallow, vale la pena evidenziare che la fase del crawling, di cui sto illustrando i dettagli, è ben distante da quella dell’indicizzazione, che avviene molto dopo nel flusso di attività. Come conseguenza, il disallow non dovrebbe mai essere usato per indurre un motore di ricerca a non indicizzare una risorsa, proprio perché non ha per niente a che fare con la fase di indicizzazione ma si limita a definire quali risorse è vietato richiedere ad un server.

Per contribuire alla crescita del database di URL, il crawler ha due strade: scaricare una risorsa e lasciarne analizzare il contenuto dal parser, che a sua volta potrà individuare link verso nuovi URL da aggiungere al database, oppure individuare autonomamente nuovi URL nelle intestazioni HTTP della risorsa richiesta.

Per esempio, nel caso in cui un web server dichiari che una risorsa ha cambiato URL (status HTTP 301, 302 o 307) il crawler potrà acquisire il nuovo URL dalle intestazioni HTTP di tipo “Location” e, più o meno direttamente, potrà farlo memorizzare nel database di URL. Un altro esempio di URL presenti nelle intestazioni HTTP sono gli URL indicati nelle intestazioni “Link”, usati per comunicare l’esistenza di relazioni di vario tipo (tra le quali anche la relazione “canonical”) tra la risorsa richiesta ed una seconda risorsa.

Ecco perché. Visto che ho accennato alle redirezioni HTTP, ne approfitto per far notare perché una redirezione lato server di tipo 301 non può che essere considerata da Google una direttiva categorica mentre un “rel=canonical” viene considerato un semplice suggerimento. Le intestazioni HTTP fanno parte di un protocollo (L’Hyper Text Transfer Protocol, appunto) sul quale l’intero web poggia e senza il quale il web non potrebbe funzionare. Un codice di status 301 rientra tra quelle indicazioni che tutti i client HTTP accettano, sia gli spider dei motori di ricerca sia i browser degli utenti. Di conseguenza la presenza di una redirezione di tipo 301 produce un effetto concreto sulla navigazione dell’utente, che si ritrova dirottato su un indirizzo diverso da quello inizialmente richiesto. Visto l’effetto che una redirezione 301 ha sull’utente, Google decide di considerare tali redirezioni come delle direttive categoriche applicando una semplice logica: se, alla richiesta di un URL, gli utenti verranno dirottati dal server in via definitiva su nuovo indirizzo, allora anche Google vorrà considerare il nuovo indirizzo come “canonico” e suggerirlo nelle proprie SERP. La relazione di tipo canonical presente nel codice HTML di una pagina, invece, viene ignorata dai browser e non produce alcun effetto sulla navigazione dell’utente. Come è di consueto per diversi motori di ricerca, a qualcosa percepibile dall’utente viene assegnato un peso maggiore rispetto a qualcosa che l’utente non percepisce, di conseguenza il rel=canonical presente nel codice delle pagine viene considerato un consiglio e non qualcosa di peso comparabile ad una redirezione dell’utente verso un altro URL.

Come anticipato un po’ di paragrafi fa, queste prime fasi del processo di crawling prevedono solo la gestione di URL e di richieste HTTP: questo ha implicazioni pratiche per i SEO. La prima implicazione è che un’informazione percepita dal crawler raggiunge il motore di ricerca prima di un’informazione percepibile solo in fase di parsing, ovvero quando Google analizza i contenuti della risorsa.

Riprendendo la distinzione tra redirezioni 301 e rel=canonical, per esempio, l’implicazione pratica consiste nel fatto che le redirezioni 301 vengono percepite da Google molto prima rispetto alle relazioni canonical nel codice HTML. Quindi oltre alla differenza di “categoricità” tra le due informazioni esiste anche una differenza nei tempi di reazione del motore di ricerca: un rel=canonical non può essere considerato un sostituto delle redirezioni lato server anche per questa diversità di tempi di reazione del motore di ricerca.

Non bisogna però commettere l’errore di credere che qualunque indicazione percepita dallo spider equivalga ad una reazione più veloce da parte di Google. Per esempio, una direttiva noindex può essere erogata attraverso intestazioni HTTP oppure attraverso un meta tag ROBOTS tuttavia, anche nel caso in cui il noindex venga erogato attraverso intestazioni HTTP, il crawler si limiterebbe a passare l’informazione a quelle fasi successive del processo che hanno in carico la gestione dell’indicizzazione.

Detto in altri termini, una redirezione 301 viene sfruttata dal sistema prima di un’istruzione rel=canonical nel codice HTML non solo perché la redirezione viene osservata dal crawler sin dalle prime fasi di interazione con la risorsa ma sopratutto perché le redirezioni vengono gestite nella fase di crawling stessa.

Nel caso in cui la richiesta effettuata dal crawler vada a buon fine, il contenuto della risorsa ricevuta viene salvato attraverso il filesystem in quello che è il “Document datastore”, ovvero il database che contiene i documenti.

[…]

Epilogo

Qui s’arresta l’avventura
del Signor Bonaventura
che di scriver s’è stancato
e dal sonno è soggiogato.

Raggiungendo tosto il letto
viene colto da un sospetto:
“Vuoi veder che questo modo
d’insegnar non viene al sodo?”

“Ogni post è assai corposo
di parole che mai doso
e il lettore un po’ impigrito
può fuggir mostrando il dito.”

Ma spiegar per ben la SEO
non importa al dio Morfeo
che notato il nostro assorto
lo rapisce e taglia corto.

Nel reame dei dormienti
non si fanno esperimenti
ma ronfando sul cuscino
si raggiunge ormai il mattino.

E svegliatosi di botto
esultando sopra e sotto
grida “Eureka!” a profusione
“Ecco qua la soluzione!”

L’appuntamento con la novità è per domani, 10 ottobre 2013.

Aggiornamento: il 10 ottobre 2013 è arrivato e potete leggere la novità: Come funziona Google (sul serio).

Comments are closed.

More in Just SEO
Studi sui fattori di ranking: distinguere quelli utili da quelli farlocchi

In fondo a questo articolo c'è un'infografica. Lo scrivo in cima altrimenti c'è il rischio che ve la perdete. Non...

Close