Post recenti
Commenti recenti
- I Principali Test per un Sito Web in Ottica SEO - Ingegnerealbano.com on Come calcolare la distribuzione del “PageRank” tra le pagine di un sito
- SEO e keywords: esistono strategie e tecniche efficaci? | SERIAL EYE on Benedetta SEO, maledetta SEO
- LowLevel on Continuare a smontare Google: un’altra scoperta SEO
Tutti i post
-
Questa opera di Enrico Altavilla è concessa in licenza sotto la Licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.
Google non sa perché un sito ranka
Il titolo del presente articolo forse è un po’ un’esagerazione, ma mica di tanto, sapete?
Lo studio dei singoli fattori che determinano la posizione di una risorsa per una specifica query è un’attività tipica dei SEO che fanno reverse engineering ma non è necessariamente tipica di chi progetta un motore di ricerca.
L’obiettivo che mi do con questo post è spiegare perché, in alcuni contesti, fare reverse engineering in cerca di fattori che determinano una migliore posizione non ha un senso. E non intendo dire che sia troppo difficile raggiungere l’obiettivo ma proprio che non ha senso cercare qualcosa che non esiste.
Qualche mito da sfatare
Molte delle persone che hanno intrapreso la carriera di SEO hanno basi informatiche e questo background li aiuta nel momento in cui c’è da affrontare aspetti tecnici da valutare. Alcuni di loro sanno anche sviluppare software in qualche linguaggio di programmazione.Il retaggio da programmatori, tuttavia, a volte può rappresentare un handicap per comprendere il funzionamento e le logiche che stanno dietro ai moderni algoritmi dei motori di ricerca. Questo avviene perché tutti gli sviluppatori possiedono le basi della programmazione più semplice (strutture dati, algoritmi, strutture di controllo, ecc.) ma solo in pochi si sono cimentati con l’intelligenza artificiale o con classificazioni di natura statistica.
Le esperienze di programmazione più semplici possono indurre i programmatori a ritenere che gli algoritmi dei motori di ricerca preposti a determinare la posizione di una risorsa per una query si basino su semplici controlli condizionali del tipo:
- se il titolo della pagina contiene la query, allora attribuisci alla risorsa una rilevanza maggiore
- se la risorsa riceve molti backlink da altri siti, allora attribuisci ad essa un’importanza maggiore
- se la pagina contiene una percentuale troppo alta di ripetizioni delle parole della query, allora considerala di bassa qualità
Pensare all’algoritmo del motore di ricerca come se fosse un elenco di regole simili a quelle elencate è “pericoloso”. E’ pericoloso perché è fuorviante e crea nella testa del SEO alcune convinzioni:
- lascia credere che vi sia un elenco di fattori valevole ed utile per ogni sito
- lascia credere che vi siano regole rigide, che fanno riferimento a specifici fattori o riferimento a specifici calcoli
- lascia credere che i progettisti determinino da sé valori-soglia o quanto sia importante un elemento piuttosto che un altro (o addirittura si crede che tali valori e importanze valgano per qualsiasi sito)
Si tratta di convinzioni errate? A volte sì e combaciano sempre meno con la realtà dei motori di ricerca, via via che il tempo passa e che le metodologie di valutazione dei siti si fanno più sofisticate.
L’abbandono delle regole rigide
Se prendete un motore di ricerca open source (es: Lucene) e date un’occhiata al suo funzionamento, noterete che l’algoritmo di ranking si fonda sull’assegnazione, in base alla query, di pesi a certi elementi delle risorse e al calcolo di un valore di rilevanza complessivo che viene successivamente usato per ordinare tra loro le risorse prima di proporle all’utente.
Il modello si basa effettivamente su qualcosa di simile ai semplici controlli condizionali citati sopra e che vengono in mente quando si tenta di immaginare il funzionamento di un algoritmo di ranking. Invece di controlli condizionali vengono nella pratica usate formule matematiche, ma il concetto di base è lo stesso.
In un motore di ricerca semplice come Lucene, è il progettista o l’implementatore a decidere quanto peso attribuire a ciascun elemento e in che modo essi vanno gestiti per determinare il valore complessivo di rilevanza di ciascuna risorsa per una specifica query.
Il modello illustrato, però, è eccessivamente rigido per un motore di ricerca generalista come Google.
Quando l’obiettivo è quello di organizzare e cercare all’interno dell’intero web, bisogna necessariamente fare i conti col fatto che il web è un prodotto ed una manifestazione in continuo mutamento delle azioni degli esseri umani. Il web è uno specchio dei cambiamenti di abitudini, culture, storie ed eventi che avvengono nel mondo ed un’analisi fondata su regole rigide rischia di valutarlo in modo impreciso e soggetto a veloce obsolescenza.
Ovviamente è sempre possibile modificare costantemente regole e pesi degli algoritmi in modo da rendere il sistema più compatibile con gli ultimi sviluppi osservabili (attività che probabilmente non verrà mai abbandonata) ma esiste una strada migliore per venire incontro alla natura di un “essere in continuo cambiamento” quale è il web.
L’approccio adattivo
Invece di costruire un sistema di regole selezionate arbitrariamente, fondato su specifici elementi da valutare e su specifici pesi da attribuire a ciascuno di essi, è possibile creare un sistema in grado di adattarsi automaticamente a quanto è osservabile sul web e in grado di determinare da sé, per una query, quali risorse vanno considerate migliori di altre in funzione delle caratteristiche osservate.
Fondato su nozioni di intelligenza artificiale, un sistema di machine learning può partire da indicazioni fornite da esseri umani (in Google li chiamano Quality Rater) su piccoli insiemi di SERP e ne può trarre delle regole generiche, applicabili a contesti più ampi, da sfruttare in fase di classificazione delle risorse o ranking.
In un certo senso, il sistema adattivo è in grado di creare da sé, ma partendo da esempi reali forniti da persone, dei criteri e dei pesi da attribuire a ciascun elemento delle risorse.
Quello che un sistema adattivo produce non è un elenco di regole codificate in maniera simile ai controlli condizionali esemplificati sopra (“se è presente tale caratteristica allora comportati nel seguente modo”) ma per quello che ci interessa è sufficiente avere chiare due cose sul sistema ottenuto:
- serve a prendere decisioni sulle risorse
- si fonda su criteri che non sono stati stabiliti direttamente da un essere umano
E’ proprio questa seconda caratteristica che, come spiegherò, rende il reverse engineering virtualmente impossibile.
Il modello black box
Per una spiegazione più autorevole del concetto di “black box” vi invito a dare un’occhiata alla voce di Wikipedia; per le nostre necessità mi è sufficiente dire che con questa espressione si intende un qualsiasi sistema che riceve dati in input e li elabora per produrne altri in output senza dare visibilità dei criteri che regolano internamente l’elaborazione.
In pratica si tratta un modello che produce i risultati voluti partendo da informazioni iniziali ma il cui funzionamento interno è oscuro in parte o del tutto, persino a chi lo usa.
Nel contesto dei motori di ricerca, per esempio, tutte le volte che i progettisti sviluppano algoritmi che fanno uso di tecniche di machine learning introducono nel sistema uno o più componenti che producono risultati senza necessariamente rendere chiaro il processo seguito.
In altre parole, il progettista sa che qualcosa funziona e sa quanto bene funziona ma non sa necessariamente quale insieme di fattori ha prodotto il risultato aspettato.
E’ necessario aggiungere che se il sistema è stato mantenuto relativamente semplice, per esempio se valuta un numero di segnali non alto, per il progettista è tuttavia possibile “farsi dire” dal sistema quale concorso di cause e fattori ha prodotto l’output.
Tale possibilità viene sfruttata prevalentemente per “aggiustare il tiro” in presenza di output non soddisfacenti, andando a fondo per scoprire quali condizioni hanno contribuito a produrre un risultato problematico.
Una volta che tutto funziona per benino, però, il sistema va avanti “da sé” e non è più necessario per il progettista indagare sui dettagli di produzione dei risultati, dettagli che peraltro possono cambiare nel corso del tempo grazie al fatto che il sistema si adatta al cambiare dei segnali osservati.
La situazione raggiunta dunque è: funziona e i progettisti non hanno bisogno di indagare sul perché funziona fino a quando l’output sarà soddisfacente.
E per i SEO, ha senso andare alla ricerca di una formula magica sconosciuta perfino ai progettisti del motore, per giunta in costante evoluzione?
Un ranking inconsapevole?
Affermare che Google produca i propri risultati di ranking in modo inconsapevole per i progettisti è però vero solo in parte.
La ragione è che gli algoritmi usati dal motore di ricerca si fondano solo in parte sul machine learning e che l’intero approccio a tali metodologie da parte di Google è sempre stato cauto ed oculato. Quasi timoroso, direi.
C’è un bel post ufficiale di Google che illustra le lezioni imparate durante la progettazione del sistema di machine learning che viene usato per diversi problemi da affrontare e il cui utilizzo è stato successivamente aperto a tutti gli sviluppatori di software attraverso la prediction API.
Delle tante lezioni elencate da Google, quella che voglio evidenziare dice che l’adozione di tecniche di machine learning da parte dei progettisti del motore dovrebbe avvenire solo nel caso in cui tali tecniche producano risultati molto migliori rispetto a quelle “tradizionali”, dove per tradizionali si intendono classici algoritmi fondati su criteri, formule e pesi stabiliti dai progettisti.
Il problema è: non ci è dato sapere quali parti della valutazione dei siti e dell’algoritmo di ranking viene ancora gestita con i metodi tradizionali e quali parti vengono invece gestite attraverso tecniche di machine learning.
Nel primo caso, un SEO può sperare di riuscire a risalire ai criteri fissi attraverso reverse engineering (facendo test) ma nel secondo caso l’attività di reverse engineering perde senso perché il bersaglio è in continuo movimento e in una forma non intelligibile, ben diversa da un elenco di regole o pesi applicati.
L’esempio di Google Panda e di Seti
Premetto che parlare di Google Panda mi mette un po’ di nausea, non per l’argomento in sé quanto per il fatto che è stato largamente abusato come specchietto per le allodole da una frotta di SEO e markettari desiderosi di far traffico, anche quando non c’era nulla di interessante da dire o quando Panda non c’entrava nulla. L’unico post che mi sento di suggerire vivamente è l’articolo di Stuart su Panda. Il resto è noia.
Google Panda è un classificatore e, per come è stato descritto da Amit Singhal, risulta essere un Decision Boundary; ho approfondito gli aspetti tecnici in questo articolo passato.
Non si può escludere che parti di Panda possano beneficiare di tecniche di machine learning ma i risultati che vuole ottenere sono raggiungibili anche con metodologie del tutto “tradizionali”.
In sostanza, in Panda esiste un elenco di caratteristiche in base alle quali ciascun sito viene identificato ed esiste un confine che separa le combinazioni di caratteristiche tipiche dei siti “cattivi” dalle combinazioni di caratteristiche tipiche dei siti “buoni”. Più un sito si trova all’interno della zona dei siti cattivi e più la sua posizione nelle SERP sarà inferiore.
Tentare di fare reverse engineering su Panda ha un senso? Dipende.
Se Google Panda fosse un classificatore gestito attraverso il sistema di machine learning progettato da Google, che si chiama Seti, e basato su una quantità di segnali smodata, potremmo trovarci di fronte ad un muro invalicabile.
Al contrario, se Panda fosse semplicemente un decision boundary basato su pochi segnali selezionati a mano, fare reverse engineering di Panda potrebbe ancora avere un senso, e consisterebbe semplicemente con l’individuazione delle caratteristiche usate per identificare ciascun sito.
Anche in questo secondo caso, si tratterebbe di un obiettivo difficile da raggiungere, ma siccome ci troveremmo di fronte ad un elenco di elementi selezionati manualmente da esseri umani, ha ancora un senso dare la caccia a quelle combinazioni di segnali che potrebbero identificare i siti cattivi, per allontanarsene, e i buoni, per avvicinarsene.
Conclusioni
Oltre a fare un po’ di chiarezza su quali sono le possibilità odierne dei SEO di “smontare il nuovo giocattolo”, con questo post voglio sopratutto fare una considerazione sul futuro che ci aspetta, un futuro nel quale avrà sempre meno senso tentare di individuare i criteri specifici di ranking.
Avrà però sempre senso tentare di comprendere i criteri generici e quelli più ad alto livello. Del resto, sono anni che Google suggerisce di focalizzarsi sulla user experience e sulla qualità dei siti web e meno sui segnali dai quali la qualità viene poi inferita dal motore di ricerca.
Tutto sommato il messaggio è chiaro: meno simulazione e più concretezza. Lo scenario che si prospetta è affascinante perché è sempre più legato a scelte di business invece che a scelte tecniche, funzionali solo per il motore.
Ma il pippone sulla necessaria evoluzione dei SEO ve l’ho già fatto e quindi l’articolo termina qua. 😉
Pingback: » Le regole SEO ed i Trucchi
Pingback: Studi sui fattori di ranking: distinguere quelli utili da quelli farlocchi - LowLevel’s blog