Trarre lezioni SEO dal gigantesco bug di Google Plus

Siccome non uso questo blog per affrontare temi che ritengo meno interessanti, non ho scritto un articolo sul gigantesco bug di Google+ scoperto due settimane fa, quello che permette di attribuire ad una pagina di Google+ una quantità di +1 sostanzialmente arbitraria, “copiandoli” da quelli di una qualsiasi altra pagina.

Se questo bug fosse emerso su Facebook, tutti i blog markettari internazionali avrebbero probabilmente evidenziato l’incredibile falla ed i vari servizi di “vendita di like” avrebbero stappato bottiglie di Dom Pérignon. Ma siccome Google+ se lo filano in quattro gatti ed i suoi utenti attivi si calcolano sulle dita di una mano di un monco (sì, è un’iperbole) la faccenda è passata relativamente inosservata.

Se non avete idea del bug del quale sto parlando, vi segnalo un articolo riassuntivo su Engeene ed un approfondimento tecnico su Ideativi. Ne consiglio la lettura per prendere familiarità col tema di cui sto per scrivere.

L’articolo che state leggendo, tuttavia, non è dedicato al bug in sé quanto a che cosa è possibile imparare sul funzionamento di Google ragionando un po’ sulla falla che è stata trovata e sul perché essa esiste.

Sarà anche un modo per approfondire un po’ parte del processo di canonicalizzazione delle risorse.

Buona lettura!

Cenni storici sull’hijacking

Per molti anni è stato possibile sfruttare i meccanismi interni di Google per effettuare almeno due forme di “hijacking”: PageRank hijacking e hijacking della posizione di una risorsa nelle SERP.

Il PageRank hijacking è una tecnica dedicata alla famigerata barretta verde della toolbar di Google e consiste nel riuscire a mostrare per una risorsa web un valore di PageRank che in realtà appartiene ad un’altra risorsa. Per esempio, la home page del sito del vostro ferramenta di fiducia, potrebbe mostrare un valore di PageRank corrispondente a quello assegnato alla home page di Repubblica.it

Va precisato che il fenomeno è esclusivamente estetico: una risorsa non acquisisce realmente il valore di PageRank di un’altra risorsa, rendendo la tattica assolutamente ininfluente per la visibilità sui risultati di ricerca.

Per tanto tempo, tuttavia, questa pratica è stata usata da alcuni domainers e rivenditori di siti per vendere nomi di dominio a prezzi più alti, facendo credere ad acquirenti sprovveduti che la home page del dominio venduto possedesse valori di PageRank alti o comunque non nulli.

Non seguo più il contesto dei domainers da un po’ di tempo, ma se volete farvi una cultura in merito, basta cercare [fake pagerank] per prendere visione dell’ecosistema che è nato attorno a questa tecnica di hijacking.

Una seconda tecnica di hijacking, più critica, si era invece resa disponibile in passato a causa di un bug di Google. In alcuni casi era possibile, attraverso un semplice redirect che puntava ad una risorsa web da “colpire”, prendere il posto di quella risorsa nei risultati di ricerca di Google, a prescindere dalla query cercata dall’utente.

Vale la pena di precisare che la sostituzione era totale: non si trattava di risorse-fotocopia che superavano di posizione i siti ufficiali, ma proprio di una completa scomparsa della risorsa ufficiale e della sua sostituzione con quella farlocca.

A differenza del PageRank hijacking, questa seconda forma di hijacking produceva ovviamente conseguenze molto concrete, disastrose per le vittime che scomparivano dalle SERP e benefiche per i proprietari dei siti che riuscivano a sostituirsi in tutto e per tutto in posizioni precedentemente occupate da altri siti.

Questa seconda tecnica non è più attuabile, perché Google ha modificato da molti anni i propri algoritmi per evitare questi gravi incidenti di sostituzione delle risorse nelle SERP, tuttavia è importante sottolineare che tutte e due le tecniche di hijacking avevano una cosa in comune: sfruttavano delle falle (concettuali o di implementazione) del sistema di canonicalizzazione delle risorse.

Quel gran casino della canonicalizzazione

Inizio subito col dire che la canonicalizzazione delle risorse, ovvero la comprensione di cosa sia una copia e che cosa sia un originale, rappresenta un obiettivo molto complesso per un motore di ricerca, reso difficile anche dalla quantità smisurata di duplicati che esistono sul web.

Molti CMS sembrano siano stati progettati senza il minimo scrupolo nei confronti della quantità di URL raggiungibili attraverso i link interni al sito. La conseguenza è che basta un qualsiasi sistema di “faceted navigation” per generare in modo incontrollato quantità smisurate di URL raggiungibili dagli spider dei motori.

A proposito, questo post sul blog di Google è un po’ incasinato ma comunque molto utile per affrontare i potenziali problemi derivanti dall’uso di faceted navigation. Magari dategli una letta, se non l’avete ancora fatto.

Per un po’ di tempo è girata voce tra i SEO che Google fosse in grado di gestire autonomamente i problemi di duplicazione dei siti web e che non vi fosse necessità per i webmaster di occuparsi del problema. Questa generalizzazione è purtroppo errata ed un buon modo per creare danni. Se è vero che Google non ha grandi problemi a gestire le risorse duplicate dei siti piccoli e medi, un discorso del tutto diverso va fatto per i siti molto grandi, complessi e popolari, sui quali i crawler di Google sono più famelici e assidui. Queste problematiche, oltre ad essere state osservate, sono state anche successivamente confermate da John Mueller.

Di fronte ad una notevole complessità di URL e a duplicazioni indiscriminate di grandi quantità di risorse, una percezione corretta dell’organizzazione degli URL di un sito diventa difficile persino ad un essere umano. Un motore di ricerca si può confondere ancora di più.

Per ottenere una visione più chiara e semplificata delle risorse che compongono un sito, ogni motore di ricerca necessita di sviluppare un sistema per la loro canonicalizzazione. Quello di Google è particolarmente complesso, per ragioni che non avrei modo di riassumere in poche righe, ed è proprio questa complessità che nel corso degli anni ha lasciato aperte alcune falle che sono state sfruttate da SEO e webmaster per trarre benefici immeritati.

Queste falle a volte sono dipese da errori di programmazione, altre volte sono invece di tipo concettuale, ovvero imputabili al meccanismo di base di un qualsiasi sistema di canonicalizzazione delle risorse, che funziona definendo per ogni risorsa primaria un elenco di URL alternativi, che potremmo considerare degli “alias” o “pseudonimi”.

Due tipi di canonicalizzazione

Io divido la canonicalizzazione in due tipi diversi, quella “esplicita” e “quella implicita”.

La canonicalizzazione esplicita avviene quando Google riceva dai gestori di un sito dei segnali espliciti che aiutano il motore a determinare che alcuni URL sono solo degli alias di un URL canonico. L’esempio più semplice di questi segnali espliciti sono le redirezioni e il rel=”canonical”.

A volte per la canonicalizzazione esplicita uso l’aggettivo “assistita”, perché sono i webmaster ad aiutare Google a capire quali URL sono quelli canonici.

La canonicalizzazione implicita è invece ciò a cui Google deve ripiegare quando non gli vengono forniti espliciti segnali da parte dei gestori dei siti web.

La canonicalizzazione implicita

Un esempio molto semplice di canonicalizzazione implicita esiste da molti anni e consiste nel tentare di individuare URL non canonici della home page di un sito web, limitatamente a quei casi in cui la richiesta di un alias non produce una redirezione ma eroga una copia dei contenuti della home page.

Per esempio, l’URL http://www.sito.com/ può essere considerato da Google canonico ed il motore di ricerca può individuare vari suoi alias, come:

• http://www.sito.com/index.html
• http://sito.com/
• https://www.sito.com/

Ognuna di queste associazioni non viene fatta di default, ma viene confermata da un’analisi dei contenuti che i server erogano quando gli URL secondari vengono richiesti dallo spider del motore.

Se i contenuti delle risorse restituite alla richiesta degli URL secondari combaciano con i contenuti dell’URL canonico, allora Google opera un “clustering” e inizia a considerare gli URL secondari dei semplici alias di quello canonico.

Al contrario, se i contenuti degli URL secondari non combaciano con quelli erogati chiedendo l’URL canonico, allora l’associazione non avviene e l’URL secondario viene considerato una risorsa a sé stante.

Un problema che Google incontra nel canonicalizzare le risorse autonomamente, senza segnali espliciti da parte dei webmaster, è che può essere difficile determinare quale dei vari URL di un gruppo va considerato quello canonico. Un grande aiuto a prendere questa decisione arriva dal PageRank e dai link che Google osserva sul web. In linea di massima, l’URL che viene linkato di più e che possiede il PageRank più alto diventa quello canonico e tutti gli altri diventano i suoi alias.

Questo sistema di canonicalizzazione di Google non è prono agli hack, perché è limitato agli URL interni di uno specifico sito e il peggior effetto negativo che può avvenire è che Google si sbagli ad individuare nel gruppo degli URL quello che il webmaster desidera essere quello canonico.

Gli errori sono diminuiti ancor di più da quanto su Google Webmaster Tools esiste l’opzione per dichiarare esplicitamente quale versione di un nome di dominio va considerata canonica.

La canonicalizzazione esplicita

A complicare l’intero processo di canonicalizzazione intervengono segnali espliciti da parte dei webmaster, che in teoria dovrebbero aiutare il motore a comprendere più facilmente quali URL sono quelli canonici ma che nella pratica aggiungono anche un livello di complessità maggiore al sistema. Ecco i principali:

• Link tra risorse
• Relazione di tipo “canonical”
• GWT: gestione dei parametri degli URL
• GWT: indicazione del nome di dominio canonico
• Redirezioni tra risorse

In teoria potri aggiungere anche la relazione di tipo “alternate“, che tuttavia non sarebbe proprio corretto considerare un segnale di canonizzazione anche se, per esempio, contribuisce al meccanismo di canonicalizzazione tra risorse desktop e risorse mobile.

I primi quattro di questi segnali esulano dal tema di questo articolo e mi focalizzerò quindi solo sull’ultimo segnale della lista: le redirezioni.

Le redirezioni lato server sono un segnale di canonicalizzazione esplicito estremamente chiaro e netto: una redirezione dichiara che l’URL richiesto è (temporaneamente o definitivamente) da considerare secondario e che un secondo URL va considerato quello principale, ovvero l’URL al quale l’utente viene rediretto dal browser.

Il segnale è molto forte in quanto l’URL che fa redirezione non corrisponde più, di fatto, ad una risorsa con un contenuto. Pertanto l’unico contenuto esistente è ospitato all’URL di destinazione ed i motori di ricerca preferiscono considerare canonico l’unico URL che ospita i contenuti.

Per diversi anni Google si è comportato diversamente tra redirezioni lato server di tipo 302 (temporanee) e redirezioni di tipo 301 (definitive o permanenti che dir si voglia). Nel corso del tempo, tuttavia, le cose son cambiate parecchio e adesso le redirezioni temporanee vengono sostanzialmente equiparate da Google a quelle permanenti nel momento in cui il motore di rende conto che sono state erroneamente usate dal webmaster quelle temporanee.

Ai fini della canonicalizzazione, oggi una redirezione 301 o 302 produce gli stessi effetti, anche se quelle 302 possono in alcuni casi richiedere un po’ più di tempo affinché Google comprenda che possono essere equiparate a quelle permanenti.

Da dove vien fuori il bug di Google+?

Quando una redirezione viene implementata e acquisita correttamente da Google, il motore determina che l’URL che fa redirezione è un alias dell’URL di destinazione della definizione.

Un alias non è altro che uno pseudonimo dell’URL canonico e quindi se si chiede a Google di fornire una caratteristica di un alias, Google risponderà con la corrispondente caratteristica dell’URL canonico. Per esempio, chiedendo il valore di PageRank di un alias, Google fornirà in realtà il valore di PageRank della risorsa canonica.

Il valore di PageRank è solo una delle informazioni sugli URL che è possibile chiedere a Google. Da quando è nato Google+, ciascun URL conosciuto dal motore di ricerca si è arricchito di un’informazione in più: la quantità di “+1” attribuiti dagli utenti all’URL.

Ovviamente, come avviene per il PageRank, chiedendo la quantità di +1 di un alias, Google risponderà con la quantità di +1 dell’URL canonico a cui l’alias è stato associato. Spero che iniziate a capire dove sta la magagna.

Quando si crea una pagina Google+ è possibile associare ad essa l’URL del sito web a cui la pagina fa riferimento. Non appena questa associazione viene fatta, i +1 accumulati dalla pagina Google+ non sono altro che i +1 accumulati dall’URL del sito a cui la pagina è stata associata.

Di conseguenza, fare +1 della pagina Google+ o fare +1 dell’URL del sito associato alla pagina è esattamente la stessa cosa perché il “contatore di +1” è lo stesso.

Il bug di Google+ nasce perché è possibile associare ad una pagina un URL che fa redirezione verso un’altra risorsa.

La redirezione induce il sistema di canonicalizzazione di Google a decidere che l’URL che fa redirezione non è altro che un alias di quello di destinazione e da quando la canonicalizzazione viene fatta, chiedere la quantità di +1 dell’URL del sito associato alla pagina Google+ equivale a chiedere la quantità di +1 dell’URL di destinazione della redirezione.

E’ dunque sufficiente che l’URL della homepage del mio sito faccia una redirezione verso http://www.google.com/ e da quel momento una richiesta della quantità dei suoi +1 corrisponderà ad una richiesta della quantità di +1 attribuiti all’URL http://www.google.com/

Ovviamente, all’atto pratico, l’hacker ha anche l’obiettivo di evitare che la redirezione scatti quando gli utenti visitano il sito, ma se avete letto i due articoli di approfondimento che ho citato all’inizio di questo post, avrete già scoperto quanto sia facile risolvere questo problema.

Lezione 0: le redirezioni sono una manna per la canonicalizzazione

Numerata come “lezione zero” perché sicuramente già conosciuta e palese ai lettori di questo blog, va comunque ricordato quanto forte sia il segnale di una redirezione e quanto è utile questo strumento quando si ha l’obiettivo di gestire contenuti duplicati ed evitare la dispersione di qualsiasi roba Google oggi trasmetta attraverso i link.

Lezione 1: c’è un problema e Google lo sa

Ad una valutazione superficiale, potrebbe sembrare che questo hack faccia leva su un aspetto sconosciuto dell’infrastruttura di Google+ o che la sua esistenza dipenda solo da qualche microscopica falla che gli sviluppatori di Google non avevano notato. Non è così.

Persino nelle linee guida ufficiali di Google+, si chiede espressamente di non associare alle pagine Google+ un URL che faccia redirezione verso altri. Adesso sappiamo il perché: da un lato esiste un sistema di canonicalizzazione che si accontenta di una redirezione per equiparare due URL e dall’altro esiste un Google+ che non effettua controlli su quali URL vengono associati alle pagine business.

Lezione 2: aggiustare le cose non è facile

Qualora Google volesse rimuovere il bug, è molto improbabile che mette mani all’ultra-incasinato sistema di canonicalizzazione usato dal motore di ricerca, perché sarebbe come cercare di uccidere una mosca con un bazooka. Inoltre il sistema di canonicalizzazione sta alla base di tantissimi processi delicati del motore di ricerca e del ranking: mettersi a giocare con esso per eliminare un semplice bug su Google+ sarebbe una follia.

E’ più probabile che la falla verrà coperta lavorando lato Google+, che è un sistema più semplice da gestire e da modificare, nonché meno critico per l’azienda californiana.

Lezione 3: le falle concettuali non muoiono mai

La possibilità di fare oggi hijacking di +1 sfruttando esattamente gli stessi meccanismi che in passato si usavano per fare hijacking di PageRank o di posizioni nelle SERP ci insegna che i tempi cambiano ma la pupù emana sempre lo stesso olezzo.

Il sistema di canonicalizzazione e il fatto stesso che alcuni URL possano essere considerati equivalenti ad altri sarà sempre un lato debole dell’infrastruttura tecnologica di Google, perché non esistono modi completamente diversi per gestire la canonicalizzazione delle risorse: l’obiettivo rimarrà sempre quello di associare risorse secondarie a risorse primarie e per far questo bisogna implementare un sistema di clustering degli URL ed abbracciare il concetto di “alias” affinché le informazioni raccolte sugli alias vengano poi attribuite all’URL canonico.

Coloro che hanno abbracciato il lato oscuro della SEO sono consapevoli quante nuove opportunità nasceranno da una falla ultradecennale.

Lezione 4: l’importanza di Google+

Consideratelo un semplice teorema: “La popolarità di un social network è inversamente proporzionale alla quantità di tempo impiegata per rimuovere un bug grosso come un palazzo.”. Più tempo passa e più significa che gli sviluppatori di Google+ sono consapevoli che non esiste una massa critica che sfrutterebbe il bug per scopi malevoli.

Lezione 5: il reverse engineering insegna tante cose

Il fenomeno di hijacking dei +1 è stato scoperto per puro caso ma il suo studio e la sua analisi hanno permesso di apprendere nuovi dettagli sul funzionamento del motore…

…e di farsi venire nuove idee per il futuro.

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