Questo post dedicato agli status 404 è volutamente poco approfondito.

In realtà per far le cose per bene, dovrei spiegare che la gestione dei contenuti inesistenti di un sito cambia sia al variare della tipologia del contenuto sia a seconda della ragione per la quale il contenuto non esiste (più).

Il primo esempio che mi viene in mente è quello della gestione di prodotti o contenuti temporanamente non disponibili. Non esistono regole generiche che possano essere applicate in ogni caso e mi è capitato nel corso del tempo di suggerire almeno due soluzioni tecniche diverse a seconda dei contenuti.

Mi riservo quindi di scrivere in futuro un bell’articolo SEO su dei casi specifici, nei quali l’uso dei codici di stato varia nonostante premesse simili.

Per il momento, accontentatevi di queste semplici nozioni generali e di un flow-chart chiarificatore.

1 – La criticità di un 404 dipende dai link

Uno degli errori più comuni è quello di credere che la presenza di un errore 404 erogato alla richiesta di una specifica risorsa abbia influenze SEO negative nei confronti di altre risorse del sito o del sito nella sua interezza.

Questo ragionamento è però corretto solo nel caso in cui sul sito vi siano link che conducono utenti e spider verso le risorse che generano lo status 404.

Se l’URL inesistente non è linkato dal sito, non c’è modo che gli utenti possano subire un’esperienza di navigazione negativa. Di conseguenza non sarebbe logico che un motore di ricerca si faccia un’idea negativa del sito, perché il sito sta accogliendo al meglio i propri visitatori.

Se, al contrario, sul sito ci sono link verso URL interni inesistenti, allora il problema è diverso perché c’è il rischio di proporre un’esperienza di navigazione frustrante agli utenti e di vanificare il crawling degli spider. Bisogna dunque fare attenzione che, se gli status 404 sono fisiologici o inevitabili, quantomeno utenti e spider non seguano link del sito che li conducano a risorse inesistenti.

2 – La permanenza non è intrinsecamente un male

Un errore 404 rappresenta una criticità solo se è stato prodotto da un problema tecnico, che andrebbe approfondito e risolto.

Ci sono però casi leciti nei quali un webmaster può decidere spontaneamente di far erogare al server uno status 404, per esempio quando viene fatta richiesta al server di una risorsa che non è mai esistita.

Nel suddetto caso lo status 404 e la sua permanenza non va percepito come una criticità, perché non è sintomo di un problema ma la soluzione più corretta per comunicare l’effettiva inesistenza di una risorsa.

3 – Lo status è associato ad una risorsa HTML

Tutti i web server permettono di erogare una pagina HTML associata alla produzione di un errore 404.

I contenuti di questa pagina HTML possono essere personalizzati in modo da accogliere al meglio l’utente che si è trovato di fronte ad un errore che non si aspettava.

Il modo in cui i contenuti vanno personalizzati variano da caso a caso. A volte ci si può limitare ad indicare dei link per riprendere la navigazione del sito da una categoria superiore o dalla home page. Altre volte è possibile determinare dall’URL richiesto (o dal referrer dichiarato) l’intento dell’utente e includere nella pagina contenuti più specifici, in grado di soddisfare al meglio la richiesta che non era andata a buon fine.

4 – Gli elenchi di 404 su GWT non sono una pestilenza

Va ricordato che GWT (“Strumenti per webmaster” di Google) non è Google e che il tool si limita a fare un elenco dei 404 individuati dallo spider nel corso del tempo.

Per le ragioni spiegate al punto 2, non tutti questi errori sono indice di un fenomeno negativo e quindi ciascuno di essi andrebbe investigato per capire se si tratta di un fenomeno fisiologico e ininfluente sul motore (per esempio 404 erogati alla richiesta di URL effettimanete mai esistiti) oppure se è sintomo di un problema tecnico.

Se alcuni degli status 404 riportati sono fisiologici e conosciuti, potete anche segnalare a GWT che l’eventuale “problema” è stato risolto; tali errori verranno rimossi dalla lista.

Purtroppo tali segnalazioni sono destinate a tornare sul pannello qualora la causa che ha generato i 404 non sia realmente scomparsa.

5 – Tenete conto delle alternative

Facendo parte di un nutrito insieme di status HTTP, i codici 404 andrebbero usati solo quando effettivamente opportuni. Ecco di seguito un breve flow-chart che spiega come destreggiarsi nell’uso dei più popolari codici di status HTTP.

Il grafico è lungi dall’essere completo e perfetto e sono certo che sulla completa assenza degli status 302 qualcuno potrebbe storcere anche il naso. I commenti del post sono a vostra disposizione per domande, correzioni e considerazioni.

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

(a grande richiesta, un articolo breve per far riprendere fiato ai lettori)

Questo articolo dovrebbe in teoria essere parte di un più vasto argomento che potrei intitolare “Google Webmaster Tools non è Google”.

Nel corso del tempo ho infatti osservato diversi casi in cui alcune persone reagivano alle informazioni pubblicate su GWT come se esse fossero valutazioni sul sito svolte dal motore di ricerca.

In realtà le cose non stanno proprio così e non mancherà l’occasione di affrontare l’equivoco più ampio, tuttavia questo post è dedicato ad una piaga specifica: il tool per la rimozione delle pagine dai risultati di ricerca di Google, che nella versione inglese di GWT viene chiamato “Remove URLs”.

Lascia perplessi quanto la finalità di questo tool sia stata incompresa da webmaster e SEO: in tutti gli episodi che ho valutato tale funzionalità di rimozione URL è stata infatti usata in modo errato, rendendo la vita a Google un po’ più difficile.

La confusione attorno allo strumento di rimozione URL è talmente grande e diffusa che questa funzionalità mi risulta essere l’unica per la quale Google si sia spinto a creare un’apposita pagina di supporto che spiega quando non usare il tool di rimozione URL.

Vale dunque la pena di capire come stanno effettivamente le cose per evitare errori futuri.

Usi impropri

Per focalizzare l’articolo sui problemi che ho osservato nell’uso dello strumento di rimozione URL, darò per scontato che voi conosciate già la funzionalità e vi lascerò un link alle pagine di supporto di Google dedicate ad essa nel caso in cui vogliate rinfrescarvi la memoria.

I modi (errati) in cui ho visto usare lo strumento sono principalmente due:

• dopo una modifica al sito che comportava il cambio di URL, il tool di rimozione è stato usato nel tentativo di eliminare le vecchie risorse dall’indice
• il tool è stato usato per rimuovere grandi quantità di contenuti duplicati o estremamente simili

Tutti e due gli errori nascono da un equivoco di base su che cosa cavolo fa effettivamente ‘sto benedetto strumento e quindi chiarisco subito: la funzionalità di rimozione URL fa scomparire le risorse dalle SERP, non dagli archivi o indici di Google. La differenza tra le due cose è davvero enorme, come sto per spiegarvi.

Crawling e indicizzazione

Questo è solo un dettaglio, molto semplificato, della pipeline di Google, che prosegue idealmente con la fase di indicizzazione.

Le fasi di crawling e indicizzazione di un qualsiasi motore di ricerca fanno parte di un sistema equilibrato dove tutto è connesso e dove il risultato di ogni passo dipende dai risultati dei passi precedenti.

L’intero processo comprende anche attività speciali il cui svolgimento può avvenire anche durante più di una fase. Per esempio in Google l’attività di canonizzazione degli URL, che ha un’influenza diretta su quali risorse vengono archiviate e indicizzate, avviene in parte durante la fase di crawling ed in parte durante la fase di indicizzazione.

La “pipeline” che include tutte le fasi citate, nonché diversi altri sotto-passi che non dettaglierò, va percepita come un unico organismo nel quale ogni fenomeno avvenuto durante una fase del processo può avere ripercussioni in altri momenti.

Proprio perché ogni fase è così complementare all’altra, introdurre un elemento estraneo tra ingranaggi così ben oliati rischia di produrre qualche grattacapo. In questo caso l’elemento estraneo è proprio il tool di rimozione URL.

Il “removal tool” è un intervento a gamba tesa

Purtroppo lo strumento di rimozione URL non è un elemento integrato organicamente nel flusso naturale delle cose.

Google ha introdutto questa funzionalità su GWT per fornire ai gestori dei siti un modo per nascondere urgentemente specifiche risorse nelle SERP, ma dotare il sistema di un meccanismo per rimuovere velocemente risorse, partendo da una richiesta degli utenti, ha costretto Google a scegliere tra due possibili strade:

• snaturare quel processo organico che è il sistema di crawling e indicizzazione, integrando una reale funzionalità di de-indicizzazione immediata delle risorse in grado di accettare richieste dall’esterno (e per “esterno” si intendono gli utenti)
• mantenere il sistema di crawling e indicizzazione sostanzialmente inalterato, creando uno strumento di “rimozione” URL che in realtà producesse solo un effetto cosmetico sulle SERP

Come forse intuirete, Google ha scelto la seconda strada, per motivazioni che possono essere comprensibili. Questa è la ragione per la quale lo strumento di rimozione URL non può essere usato per rimuovere realmente risorse da archivi o indici: non è ciò che la funzionalità fa. La funzionalità evita solo che le risorse siano visualizzate nelle SERP.

In altre parole il tool è una medicina che rimuove il sintomo ma che non cura alcuna causa, il che mi porta anche a fare la considerazione che segue.

Se rimuovi il sintomo, non puoi diagnosticare

Così come il dolore è per gli esseri viventi un segnale che consente di capire che qualcosa non va, allo stesso modo una qualunque condizione negativa emersa da un’analisi SEO di un sito va usata innanzitutto come punto di partenza per capire le cause del problema.

La presenza di molti contenuti duplicati, le lentezze del motore ad aggiornare i propri indici o le difficoltà a farsi perlustrare a fondo e frequentemente dagli spider sono sopra ogni cosa dei sintomi che ogni buon SEO dovrebbe studiare per diagnosticare i problemi che affliggono un sito web. Per ogni fenomeno osservato c’è sempre a monte (almeno) una ragione tecnica ed un SEO può essere considerato una via di mezzo tra un medico ed un investigatore.

Una delle ragioni per le quali il tool di rimozione URL è una iattura biblica quando viene usato per finalità errate è che rimuove dalla vista dei SEO quei sintomi che gridano a squarciagola al mondo che qualcosa non va, nella speranza di attirare l’attenzione di qualcuno.

Se Google è lento nel percepire i cambiamenti agli URL di un sito, ci sarà un motivo di fondo, no? Se i fenomeni di duplicazione delle risorse creano problemi tangibili alla qualità del traffico organico, ci sarà una ragione. Chiedere a Google di nascondere sulle SERP gli URL “vecchi” o duplicati equivale ad ignorare problemi che invece andrebbero analizzati.

Rimuovi i tuoi competitor da Google!

Per fornirvi un panorama completo di quanto inevitabilmente raffazzonato e problematico sia un qualsiasi tool di rimozione URL estraneo al sistema di crawlin/indexing, non posso esimermi dal raccontarvi di un paio di incresciosi aneddoti sui devastanti bug che hanno infestato i vari tool di Google preposti a questo scopo.

Tool di rimozione pre-GWT

Tanti anni fa stavo bazzicando sul forum di Webmasterworld.com, che ospitava a mio parere le discussioni SEO internazionali della qualità più alta. Un giorno entra un tizio nuovo, apre una discussione e asserisce che il proprio sito è stato de-indicizzato da Google e che il processo di rimozione URL fornito da Google è buggato e permette a chiunque di rimuovere il sito di chiunque altro. Il tizio spiega anche un po’ il metodo ma forse in modo non del tutto chiaro, di conseguenza gli “anziani” del forum reagiscono dicendo che secondo loro le cause erano altre. Il tizio insiste e cerca di spiegarsi meglio, poi alla fine capisce che è meglio fare un esempio pratico e dice: “Guardate, ho cancellato Microsoft.“. In tanti si va su Google a fare la ricerca ed effettivamente il sito di Microsoft è stato spazzato via dalle SERP. A quel punto l’intero pianeta SEO collassa.

Godetevi se volete un articolo dell’epoca per scoprire come è finita la storia e date il benvenuto al bug successivo.

Tool di rimozione di GWT

Qui non ho un’aneddoto da raccontare ma vi dovrebbe essere sufficiente sapere che anche in questo caso è stato possibile sfruttare un bug del tool di rimozione URL per rimuovere dalle SERP di Google anche siti di proprietà altrui. In questo articolo trovate tutti i dettagli.

L’obiettivo di questi due esempi era quello di dimostrare quanto intrinsecamente pericoloso è fornire ai webmaster un metodo per influire direttamente sul processo di indicizzazione. Spero di esserci riuscito.

Conclusione: quando non usare il tool

Dopo aver spiegato che il processo di rimozione URL di GWT altro non è che un intervento cosmetico, non integrato nelle normali attività di indicizzazione e analisi dei siti svolte da Google, dovreste aver già intuito da voi che il tool non va usato mai per tentare di aggiustare problemi di indicizzazione o duplicazione o canonizzazione o crawling. Insomma, niente che sia riconducibile a problemi tecnici o di ranking.

Come già accennato, Google fornisce anche un elenco di casi in cui il tool non deve essere usato. Vi fornisco il link pregandovi di non commettere l’errore di pensare che l’elenco presente in questa pagina di supporto sia quello completo dei casi in cui il tool non va usato. Fate al contrario: considerate quelli elencati nella pagina solo come alcuni esempi di cose da non fare e partite invece dal presupposto che il tool non vada usato mai e poi mai tranne nel caso per il quale è effettivamente nato, ovvero…

Conclusione: l’unico reale caso in cui usare il tool

Il tool può essere usato nei casi di estrema emergenza in cui è necessario rimuovere urgentemente dalle SERP risorse proprie, per problemi legali o di immagine.

Essendo comunque l’operazione una pezza-accrocchio indicibile e tenendo conto del fatto che le risorse rimangono in realtà da qualche parte nei datacenter di Google, bisogna stare attenti alle ripercussioni.

Per esempio le risorse rimosse dalla vista ricompariranno magicamente dopo 90 giorni dalla richiesta se le stesse saranno accessibili agli spider dopo il periodo di tre mesi. Per scongiurare il ritorno dei morti viventi, seguite bene le procedure indicate da Google, che cambiano leggermente tra rimozione di singole risorse e rimozione di intere directory.

Mi auguro che il post possa essere d’aiuto a chiunque voglia chiarirsi le idee sul modo in cui la funzionalità di GWT (non) va usata.

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

Un’ottima descrizione del PageRank e della sua relazione con un sito web può essere data parafrasando le parole di Obi Wan Kenobi quando in Star Wars descrive il concetto de “La Forza“.

“Il PageRank è ciò che dà al sito la possanza. E’ un campo energetico creato da tutte le risorse. Le circonda, le penetra, mantiene unito tutto il sito.”

Non fatevi ingannare dal paragone apparentemente giocoso e superficiale: in realtà è davvero incredibile quanto la descrizione che ho appena dato combaci perfettamente con le caratteristiche della formula del PageRank.

Dal punto di vista matematico, il PageRank viene effettivamente creato da ciascuna risorsa, si accumula e si distribuisce tra esse in funzione delle relazioni che esistono tra loro ed è uno di quei segnali che conferiscono ai siti quella “possanza” che viene tenuta in considerazione da Google quando c’è da stabilire quanta visibilità concedere a tutti i siti web.

In questo articolo spiego come prendere visione del modo in cui il PageRank di un sito si distribuisce tra le sue pagine e sezioni, un’informazione che può aiutare a capire se un sito ha problemi di dispersione del PageRank o se lo distribuisce in modo non compatibile con gli obiettivi di business.

Non proprio PageRank

Ho virgolettato “PageRank” nel titolo perché la formula finale che utilizzerò non è realmente quella divulgata da Brin e Page nel 1998 ma una variante più generica chiamata Eigenvector Centrality (EC). Per essere precisi, il PageRank è una forma speciale di EC.

La ragione per la quale ho scelto EC è di ordine pratico: il software che userò per il calcolo ottiene valori più precisi rispetto a quelli che otterrei calcolando il PageRank.

(se non volete essere ammorbati da un approfondimento sulle due formule, saltate pure alla prossima sezione del post)

Le due formule differiscono principalmente per una delle caratteristiche matematiche del PageRank che l’hanno reso famoso, ovvero il fatto di suddividere la quantità di PageRank veicolata per la quantità di link presenti in una pagina. Questa differenza, tuttavia, non cambia di molto i risultati pratici che si ottengono quando le due forme vengono applicate ad un grafo come quello dei link interni di un sito web, perché la distribuzione di “importanza” all’interno di un sito è più che altro influenzata dall’architettura del sito stesso e da quelle strutture di navigazione (menu, sotto-meu, breadcrumb, paginazioni, ecc.) che vengono ripetute su una grande quantità di pagine.

Per dirla tutta, l’obiettivo di calcolare una distribuzione di importanza tra le pagine di un sito è in realtà perseguibile attraverso una qualunque formula che abbia l’obiettivo di stimare la “centralità” di un nodo, ovvero una probabilità che un utente vi possa arrivare in funzione dell’interlinking delle pagine.

Esistono alcune formule del calcolo della centralità che attribuiscono ad alcuni nodi dei valori di “importanza” poco in linea con quelli che verrebbero loro assegnati intuitivamente da un essere umano, ma PageRank ed Eigenvector Centrality sono entrambe formule che si comportano molto bene e che sono in grado di tener conto anche delle connessioni indirette tra i nodi.

Se volete approfondire la questione, trovate uno studio e paragone di alcune di queste formule nel documento Justification and Application of Eigenvector Centrality [PDF].

Infine, aggiungo che non avevo alcuna convenienza a replicare in modo fedele la formula originaria del PageRank, in quanto essa è per certo molto diversa e molto meno sofisticata di quella che Google utilizza oggidì.

Da questo punto in poi, fate conto che i concetti che esprimerò sul PageRank sono applicabili anche all’effettiva formula che poi utilizzerò durante i calcoli.

Questo non è un tutorial

Ho fatto il possibile per non trasformare questo articolo in un tutorial passo-passo, un po’ perché il metodo che sto per spiegare prevede diversi passaggi e sarebbe davvero impossibile dettagliarli tutti senza trasformare il post in un chilometrico listone di azioni, un po’ perché ho un’alta considerazione di chi mi segue da un po’ e do per scontato che il lettore riuscirà ad approfondire e personalizzare le mie indicazioni generiche a seconda delle proprie necessità.

In particolare, il software Gephi richiede certamente un po’ di pratica prima di poter essere usato con dimestichezza, essendo un software di una certa complessità. Non attendetevi quindi dal presente articolo una guida su Gephi, perché sarebbe impossibile e fuori luogo proporla.

Per facilitare al massimo gli “smanettamenti” ho provveduto a creare un archivio ZIP contenente tutti i file prodotti durante l’analisi (circa 3 megabyte). Spero che possa agevolare lo studio ed i test che vorrete fare sui vostri siti.

A che cosa serve questa analisi

Scoprire come il PageRank di un sito viene diviso tra le risorse che lo compongono, in funzione di come esse si linkano tra loro, è una delle analisi di base per individuare eventuali criticità SEO.

Nella stragrande maggioranza delle volte, si parla di PageRank solo in riferimento al segnale che contribuisce alla visibilità di una risorsa nelle SERP di Google. E’ però possibile acquisire importanti indicazioni sullo “stato di salute” del sito facendo anche paragoni tra i valori di PageRank attribuiti a ciascuna risorsa.

Quali sono le risorse del sito che ricevono maggiore PageRank? Esistono risorse particolarmente strategiche che ricevono troppo poco PageRank rispetto alle altre? Di contro, esistono risorse poco importanti a cui viene accidentalmente assegnato molto PageRank?

Una buona regola generale per comprendere se la distribuzione del PageRank è in linea con i propri obiettivi di business è quella di iniziare ad ordinare le risorse del sito per tipologia, decidere quanto ciascuna tipologia deve risultare visibile su Google in paragone alle altre (per esempio, ci sono classi di prodotti che sarebbe preferibile vendere più di altri?) e infine accertarsi che tali obiettivi di visibilità siano coerenti con la quantità di PageRank che i link interni del sito conferiscono a ciascuna tipologia di risorse.

Per la mia esperienza, le difficoltà riscontrate su alcuni siti ad ottenere visibilità per specifiche classi di query sono state a volte comprese proprio dando un’occhiata a come l’importanza veniva ripartita tra le risorse di diverso tipo.

L’analisi che sto per fare non deve focalizzarsi sui valori assoluti del PageRank di ciascuna risorsa bensì sulla percentuale di PageRank che esse ricevono.

Siccome l’obiezione più tipica che sento fare è che “tutte le risorse sono importanti“, mi tocca adesso spiegarvi perché questa logica è fuorviante…

La coperta troppo corta

Nessuna risorsa è infinita. Questo presupposto vale quando si allocano i budget, quando si definiscono gli investimenti su ciascun canale di marketing, quando bisogna ripartire le risorse a disposizione sulle attività necessarie a portare avanti l’azienda e quando è necessario decidere dove fare tagli alle spese. Questo concetto vale anche per il PageRank.

La semplice cosa da realizzare è che prendendo in considerazione uno specifico momento, la quantità complessiva di PageRank a disposizione di un sito è una quantità finita, e quindi va amministrata al meglio.

Se è pur vero che i siti che possiedono una quantità di PageRank maggiore sono in media più capaci di ottenere visibilità sulle SERP per insiemi di query più grandi, anche in quei casi è necessario farsi scrupolo di come attribuire importanza alle risorse del sito, perché ogni spreco o dispersione di importanza su risorse o sezioni del sito poco strategiche rappresenta comunque un’occasione persa per acquisire maggiore visibilità con le risorse che interessano di più.

Questa è la ragione per la quale più di una volta ho usato la metafora della coperta troppo corta: è irrealistico pretendere di coprire tutto in modo omogeneo ed è invece necessario essere selettivi, classificare le risorse del sito per reale importanza e accettare di sacrificare ciò che ci interessa meno per ottenere vantaggi di visibilità su quanto ci interessa di più.

Ingredienti

Per la ricetta che sto per illustrare è necessario dotarsi di alcuni ingredienti:

• Un crawler in grado di esportare l’elenco di link interni al sito. Io ho usato Screaming Frog SEO Spider.
• Un foglio di calcolo in grado di supportare un bel po’ di righe. Ho usato Excel.
• Un qualunque tool in grado di eliminare i doppioni da un elenco testuale di URL. Io ho usato un’opzione del text editor Ultraedit.
• Gephi, che è un software per la progettazione ed il disegno di grafi.

Metodologia

Per semplificare al massimo questa trattazione, ho deciso di applicare il metodo di calcolo della distribuzione del PageRank ad un sito molto piccolo e semplice, ovvero a LowLevel.it

Essendo LowLevel.it un blog personale, non strutturato come sarebbe un sito contenente una categorizzazione di prodotti o servizi, la quantità di considerazioni finali su quanto l’effettiva distribuzione del PageRank sia compatibile con gli obiettivi del sito sarà purtroppo molto limitata.

Date dunque per scontato che ha molto più senso applicare il metodo che sto per spiegare a siti ben più complessi e grandi, sopratutto siti che possiedono obiettivi di marketing e di business ben definiti.

Il modo in cui il PageRank viene distribuito tra le pagine del sito verrà determinato attraverso i seguenti passi:

• Effettuerò un crawling del sito per ottenere un elenco dei link interni
• Partendo dall’elenco di link otterrò un elenco di nodi (nodes) e archi (edges), ovvero il tipo di elementi di cui si compone un grafo
• Fornirò l’elenco di nodi ed archi a Gephi e calcolerò qualcosa di molto simile al PageRank, chiamato Eigenvector Centrality (EC)
• Dal calcolo, otterrò sia un indice di EC per ciascuna delle risorse del sito sia una rappresentazione visuale del grafo
• I valori di EC per ciascuna risorsa potranno essere poi utilizzati per calcolare valori medi di importanza di intere sezioni del sito

Il metodo che applico tiene conto di quanto viene effettivamente mostrato a Googlebot, di eventuali attributi nofollow su specifici link e di eventuali informazioni su URL canonici erogate attraverso l’attributo rel=canonical.

Il crawling del sito (Screaming Frog)

La prima fase dell’analisi consiste nel raccogliere i dati sui link interni al sito. Per questo scopo, ho utilizzato il crawler Screaming Frog.

In pura teoria sarebbe possibile usare in alternativa Xenu Link Sleuth ma poi sorgerebbero problemi con l’esportazione dei dati dei link, che in Xenu non è purtroppo configurabile per ottenere solo i link tra risorse HTML. Per ottenere dei dati finali più puliti potrebbero teoricamente essere applicati dei barbatrucchi in fase di configurazione iniziale del crawling ma anche attraverso questi espedienti è difficile ottenere un output 100% pulito. Inoltre Xenu non fornisce informazioni sull’eventuale attributo rel=canonical dei link. Per tutte queste ragioni ho escluso Xenu.

Il crawling di Screaming Frog va configurato nel seguente modo:

In Configuration > Spider > disabilitare il check di tutto ciò che non è HTML e accertarsi che l’opzione “Check External Links” non sia attiva, come dallo screenshot che segue.

In Configuration > User-agent > impostare Googlebot come user-agent

Importante: per siti molto grandi è anche suggerito limitare il crawling in modo che produca una quantità di URL finali non eccessivamente alta. Il problema non è tanto in Excel (che comunque possiede un limite massimo di righe in un foglio) quanto Gephi, che può diventare un po’ lento in presenza di grafi molto grandi. Consiglio quindi di usare l’opzione “Limit Search Depht” nella finestra di configurazione di Screaming Frog ed impostare una profondità di crawling tale che l’elenco di link finali non superi il centinaio di migliaia, un limite che potete modificare a vostra discrezione in base alle prestazioni del vostro computer. Vi consiglio quindi di fare delle prove per comprendere fino a che punto la vostra macchina comincia ad avere problemi a gestire grandi quantità di dati.

A questo punto il crawling può iniziare e, una volta terminato, è necessario esportare due tipi di dati: l’elenco dei link trovati dallo spider e un elenco degli URL che includa l’indicazione dei loro eventuali URL “canonical”.

E’ possibile esportare l’elenco dei link attraverso l’opzione di menu “Advanced Export > All links”. Avendo configurato il crawling perché non seguisse link esterni, il risultato sarà un file CSV contenente solo i link interni al sito.

L’esportazione di un elenco degli URL che includa anche l’indicazione di eventuali attributi “canonical” può essere fatta selezionando il tab “Internal”, selezionando la voce “HTML” dalla lista “Filter” e cliccando sul pulsante “Export” per salvare il file CSV.

Ripulire i dati (Excel)

Prima di passare alla fase di preparazione dei dati nel formato accettato da Gephi, è necessario svolgere alcune piccole operazioni di “ripulitura” di quanto Screaming Frog ha esportato.

Siccome su diversi passaggi andrò veloce, vi suggerisco di chiarirvi le idee osservando il risultato finale nel file Excel presente nell’archivio ZIP linkato in cima a questo articolo.

I due file CSV esportati da Screaming Frong vanno innanzitutto importati in due schede di un foglio Excel; potete chiamare la prima “All links” e la seconda “Canonical info”, perché l’elenco degli URL servirà esclusivamente ad estrarre gli eventuali contenuti degli attributi rel=canonical.

Alla scheda “All links” vanno aggiunte due colonne: a fianco della colonna “Source” va aggiunta una colonna “Source Canonical” e a fianco della colonna “Destination” va aggiunta una colonna “Destination Canonical”. Per ciascuna riga del foglio, queste due nuove colonne conterranno gli URL canonici corrispondenti a quelli presenti in “Source” e “Destination”, che potete estrarre dalla scheda “Canonical info” usando la formula della ricerca verticale (CERCA.VERT o, in inglese, VLOOKUP).

Le pulizie di primavera della scheda “All links” avvengono svolgendo tre semplici passi:

• eliminazione dei link (cioè righe) da/verso risorse palesemente non HTML ma erroneamente dichiarate HTML dal server
• eliminazione dei link verso risorse che fanno redirezioni
• eliminazione dei link con attributo rel=nofollow

Risorse erroneamente dichiarate dal server come HTML possono essere facilmente individuate dando un’occhiata all’estensione dei file, le redirezioni si riconoscono perché Screaming Frog indica per ogni URL lo status HTTP restituito dal server e l’attributo rel=nofollow è individuabile perché, anche in questo caso, Screaming Frog crea un’apposita colonna contenente questa informazione.

Queste appena elencate sono le azioni che si sono rese necessarie per minimizzare il problema della duplicazione dei contenuti e quello dei link nofollow, che per definizione sono quei link per i quali Google non crea un arco nel link graph.

Applicata a siti più complessi, questa procedura di ripulitura potrebbe richiedere ulteriori passaggi, a seconda del tipo di risorse che Screaming Frog avrà incontrato e a seconda delle impostazioni del server o del CMS.

Preparare i dati per Gephi (Excel)

Gephi richiede che i dati del link graph gli vengano forniti sotto forma di due elenchi: un elenco di nodi, che nel nostro caso corrispondono all’elenco di risorse del sito, e un elenco di archi, ovvero di link che puntano da una risorsa all’altra.

Per creare l’elenco di nodi ho usato un semplice text editor: ho creato un file con l’elenco dei contenuti delle colonne “Source Canonical” e “Destination Canonical” ed ho eliminato tutti i duplicati. Questa lista è stata poi inserita in una nuova scheda del file Excel chiamata “Nodes” e a ciascun URL è stato attribuito un ID numerico univoco, semplicemente numerando gli URL da “1″ in poi, ed un’etichetta, che per semplicità ho fatto corrispondere con il percorso della risorsa, privo del nome di dominio. Il risultato finale è presente nella scheda “Nodes” del file Excel che ho allegato all’articolo, che ho poi interamente esportata in formato CSV.

Per creare l’elenco di archi ho aggiunto un’ulteriore scheda al file Excel e l’ho chiamata “Edges”. Quello che trovate all’interno dell’esempio allegato non è altro che una trasposizione dei link presenti nella scheda “All links” usando gli ID delle risorse che sono stati creati nel passaggio precedente e che sono presenti nella scheda “Nodes”. Anche questa scheda è stata poi esportata in formato CSV. Fate bene attenzione che per poter essere importati in Gephi, i nomi delle due colonne devono categoricamente essere “Source” (pagina linkante) e “Target” (pagina linkata).

Nell’archivio ZIP a corredo trovate per vostra comodità anche i due file CSV esportati, relativi ai nodi e agli archi del grafo.

Importare i dati su Gephi

Creati i due file CSV che contengono rispettivamente l’elenco di nodi e di archi del grafo, è necessario importarli su Gephi.

Lanciato il software e creato un nuovo progetto attraverso l’apposita opzione del primo menu, è necessario spostarsi nella sezione “Data laboratory”, cliccare sul pulsante “Nodes” e poi su “Import Spreadsheet” per importare il file CSV contenente l’elenco dei nodi del grafo. Si aprirà una finestra di dialogo attraverso la quale dare il via all’importazione. Trovate i dettagli di utilizzo della finestra in questa pagina del manuale di Gephi.

Allo stesso modo, sarà possibile importare gli archi del grafo cliccando sul pulsante “Edges” e poi su “Import Spreadsheet”. Per i dettagli fate sempre riferimento alla pagina del manuale sopra linkata.

Attribuire l’importanza alle risorse

Adesso che i dati del grafo sono stati importati in Gephi, è possibile calcolare finalmente l’importanza di ciascun nodo.

Per lanciare il calcolo è sufficiente spostarsi sulla scheda “Overview” cliccando l’apposito pulsante in alto a sinistra della finestra di Gephi, accedere al pannello “Statistics”, che è presente all’estrema destra della finestra e cliccare sul pulsante “Run” a fianco di “Eigenvector Centrality”, che aprirà una finestra di dialogo sulla quale sarà sufficiente confermare il comando cliccando su “Ok”. Lo screenshot seguente dovrebbe chiarire eventuali dubbi.

Una volta calcolato l’EC dei nodi del grafo, viene aggiunta una colonna all’elenco dei nodi importati durante la fase precedente. Questa nuova colonna è chiamata “Eigenvector Centrality” e contiene il valore di EC di ciascun nodo.

Se siete abbastanza smanettoni potete esportare in formato CSV la lista dei nodi, che adesso è completa dell’EC di ciascun nodo, ed importarla su un foglio di calcolo per fare le vostre proprie considerazioni su come il linking interno attribuisce importanza a ciascuna risorsa del sito. Ecco come appare l’elenco una volta importato su Excel:

Organizzare il grafo

Questo articolo non sarebbe completo se non vi indicassi, quantomeno in modo abbozzato, come visualizzare il grafo.

Gephi mette a disposizione molte tecniche per conferire automaticamente un layout al grafo ma i risultati migliori possono essere ottenuti definendo manualmente le caratteristiche visuali dei diversi elementi che compongono il grafo.

Nello specifico caso dei link si un sito io vi suggerisco di procedere come segue:

1. usate il box “Ranking” presente in alto a sinistra per conferire un colore ed una grandezza diversi a ciascun nodo in base al suo valore di EC. Io ho fatto in modo che i nodi con maggior valore di EC fossero più grandi e di colore azzurro, a differenza dei nodi meno importanti, che sono gialli e di dimensioni più piccole.
2. usate il box “Layout”, sottostante a quello “Ranking” per organizzare i nodi secondo un criterio. Io ho posto al centro del grafico i nodi più importanti lanciando in sequenza tre diversi algoritmi: Random Layout, Fruchterman Reingold e Label Adjust.

Il risultato dovrebbe essere qualcosa di simile allo screenshot che segue; ma molto più probabilmente no, perché Gephi è abbastanza incasinato e la probabilità che abbiate ottenuto lo stesso mio risultato partendo da generici suggerimenti è prossima a zero.

Notate che l’anteprima grafica ottenuta è di tipo interattivo e che è possibile modificare singoli elementi usando il mouse e diversi strumenti di disegno. Potete considerare Gephi una sorta di “Photoshop” dedicato ai grafi, quindi le possibilità di personalizzazione di layout e caratteristiche visuali sono sostanzialmente illimitate.

Creare una preview

Una volta ottenuta un’anteprima grafica accettabile, è possibile passare alla fase di rendering vera e propria, cliccando sul pulsante “Preview” posto in cima alla finestra.

Siccome anche in questa sezione del software la quantità di opzioni è da mal di testa, a fornirvi delle indicazioni puntuali non ci penso nemmeno, anche perché nell’archivio ZIP allegato al post trovate il file in formato Gephi del progetto, in cui sono già attive tutte le opzioni della sezione “Preview” che hanno dato vita all’immagine finale.

Vi invito quindi a smanettare da voi con le varie voci che servono a definire gli aspetti del disegno finale e mi limito ad evidenziarvi un’opzione molto utile nel caso di grafi molto grandi: “Preview ratio”, presente in fondo alla colonna “Preview Settings”, che è in grado di sfoltire un po’ la quantità di nodi ed archi visualizzati nel grafico finale per renderlo meno confusionario.

Ottenuto il risultato desiderato, è possibile esportare un’immagine attraverso il pulsante “Export: SVG/PDF/PNG” posto sotto lo slide “Preview ratio”.

Vi lascio con un’immagine di ciò che ho ottenuto io ma vi invito a non spendere troppo tempo in queste quisquilie visuali perché a mio parere l’attività più utile ed interessante verrà spiegata nella sezione seguente dell’articolo.

L’importanza delle sezioni

Come indicato nella sezione “Attribuire l’importanza alle risorse”, una volta calcolato l’Eigenvector Centrality di ciascun nodo è possibile esportare l’elenco di nodi da Gephi in formato CSV ed importarlo su Excel per svolgere tutte le considerazioni del caso.

La prima attività che mi sento di suggerire è quella di calcolare l’EC medio di intere sezioni del sito. Purtroppo il sito analizzato in questo articolo non è sufficientemente complesso per proporre un esempio pratico, ma nel caso di siti ben organizzati in categorie e sottocategorie risulta abbastanza facile calcolare indici di importanza di interi gruppi di risorse.

Per esempio, se le risorse del sito sono in qualche modo classificabili per tipologia attraverso una caratteristica dell’URL, sia essa il nome di una directory o la presenza di un parametro, potete creare una colonna sul foglio di calcolo destinata ad accogliere un’indicazione del tipo di risorsa e poi calcolare l’EC medio di ciascuna tipologia di risorsa attraverso una tabella pivot o anche per mezzo di semplici formule.

Ottenere un indice di importanza media di intere sezioni del sito o di intere tipologie di risorse accomunate da una medesima caratteristica è la ragione principale per la quale svolgo il tipo di analisi che ho spiegato in questo articolo. Attraverso la metodologia appena delineata mi è possibile comprendere velocemente se il linking interno del sito ripartisce l’importanza tra le risorse in modo coerente con le risorse che si desidera effettivamente rendere più visibili nei risultati dei motori di ricerca.

Più il linking interno di un sito web è complesso e più è facile non cogliere ad occhio nudo quelle caratteristiche delle strutture di navigazione che, sommate, possono influre pesantemente sul modo in cui l’importanza viene distribuita all’interno del sito. E’ questa la ragione per la quale all’inizio di questo post indicavo che un’analisi come quella spiegata acquisisce sempre più senso al crescere della complessità dell’architettura e del linking di un sito web.

Vale anche la pena di aggiungere che in pochi casi mi è capitato di valutare esempi di progetti di siti web in cui i link interni venissero pensati prendendo in considerazione gli obiettivi di usabilità. Per quella che è la mia esperienza, in fase di progettazione ho sempre notato la tendenza ad inserire link a destra e a manca, seguendo criteri generici e posticipando a future analisi di usabilità il compito di determinare se quei link avevano effettivamente senso di esistere nella forma e nel modo in cui erano stati pensati. Un’analisi come quella illustrata può quindi rivelarsi un ottimo aiuto a comprendere meglio gli effetti dell’organizzazione dei contenuti già in fase di progettazione del sito, prima che lo stesso venga reso pubblico.

Eccezioni alla regola

Dando un’occhiata all’elenco dei valori di EC vi verrà spontaneo notare che tra le pagine che ricevono una maggiore quantità di importanza ci sono anche quelle tipicamente “di servizio”, come la pagina della privacy o qualsiasi risorsa che riceva un link site-wide.

Il modo poco furbo di reagire a questa evidenza è quello di farsi prendere dal panico e applicare ciecamente attributi “nofollow” ai link verso queste pagine, oppure andare di mannaia con la direttiva “Disallow” nel robots.txt.

Ovviamente quelle contromisure non servono assolutamente a nulla, men che meno a “recuperare PageRank”. Il modo intelligente di reagire alla presenza di pagine secondarie con tanta importanza è invece quello di ricordarsi che un portavoce di Google ha detto esplicitamente in passato che gli ingegneri sono perfettamente consapevoli di questo fenomeno universale e che sono stati presi provvedimenti affinché quel tipo di pagine di servizio non corrano il rischio di essere percepite molto importanti, nonostante i link site-wide.

Questo aspetto mi dà modo di sottolineare di nuovo il modo corretto in cui l’analisi della distribuzione del PageRank va svolta: non focalizzatevi su valori assoluti e su risorse specifiche, cercate piuttosto di valutare l’importanza media di gruppi di risorse dalle caratteristiche comuni.

Conclusioni

In questo articolo ho cercato di condividere una modalità per accertarsi che i contenuti di un sito siano organizzati e raggiungibili in misura proporzionale all’importanza che gli si vorrebbe assegnare.

La metodologia proposta è solo una delle tante possibili soluzioni che potrebbero essere ideate per assolvere allo stesso compito, pertanto mi auguro che il metodo abbia almeno svolto la funzione di “food for mind” e che vi possa tornare utile prima o poi.

Come al solito, i commenti sono a disposizione di tutti per eventuali richieste di chiarimenti e per approfondire qualche aspetto.

Contenuto del file ZIP

• Lowlevel-it-crawl.seospider: il file di Screaming Frog con il crawling del sito
• Lowlevel-it-all_links.csv: il file con l’esportazione di tutti i link del sito
• Lowlevel-it-internal_html.csv: il file con l’esportazione degli URL interni al sito
• Lowlevel-it-crawl.xlsx: il file Excel in cui ho organizzato i dati
• Lowlevel-it-nodes.csv: il file con l’elenco di nodi da fornire a Gephi
• Lowlevel-it-edges.csv: il file con l’elenco degli archi da fornire a Gephi
• Lowlevel-it.gephi: il file di Gephi con il grafo del sito

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

Pur non avendo svolto alcuna valutazione dei lettori abituali di questo blog, sono indotto a credere che una loro buona percentuale sia composta da professionisti del settore con una certa esperienza sulle spalle.

Le precisazioni pubblicate nel presente articolo riguardo il concetto di “following” dei link risulterà forse un po’ banale a coloro che hanno ben chiaro come funzioni il crawling del web da parte di un motore di ricerca.

Ciononostante più di una volta mi è capitato di imbattermi in malintesi di fondo su che cosa significhi “following” e, di conseguenza, quale sia il significato e la funzione delle direttive “follow” e “nofollow”.

In un paio di occasioni il malinteso ha prodotto anche effetti negativi concreti e quindi ho pensato che ci stesse bene un breve articolo di chiarimento su questo tema.

La genesi

La motivazione a scrivere questo post è stata prevalentemente quella di aver osservato diversi episodi in cui a qualcuno è venuta l’idea di “impedire a Google di seguire backlink provenienti da siti web sgraditi al sito di destinazione”.

La logica dietro tale idea è che lo spider sia indotto ad ignorare un backlink sgradito nel momento in cui, seguendo quel backlink, si trovi di fronte ad uno status HTTP “forbidden” erogato dal sito di destinazione.

L’intero ragionamento avrebbe delle pecche logiche anche nel caso in cui gli spider dei motori seguissero effettivamente i link sul web, un po’ come fanno gli utenti che cliccano i link sui siti.

Il punto centrale della questione è che gli spider non “seguono” affatto i link e che l’intero processo di crawling del web avviene attraverso un metodo del tutto diverso. E’ dunque necessario sfatare il mito del “following”.

La cultura SEO tra cavoli e cicogne

Una critica che mi è capitato di muovere ai responsabili dei motori di ricerca che si occupano di comunicazione nei confronti di webmaster e SEO è quella che le spiegazioni sul funzionamento del motore vengono date facendo spesso uso di eccessive semplificazioni.

La scelta di semplificare molto i concetti e di allontanarsi dalle spiegazioni tecniche permette di allargare la base di utenti in grado di comprendere le nozioni principali ma purtroppo crea uno sgradito effetto collaterale: i professionisti che sono destinati a crescere nel settore della SEO partono con un identikit del motore di ricerca composto da allegorie, metafore ed esemplificazioni che nulla dicono di ciò che un motore realmente fa.

E’ un po’ come se dei trentenni fossero ancora convinti che i bambini vengano portati dalle cicogne o crescano sotto i cavoli. Non voletemene, ma è purtroppo evidente che molte persone interessate ad avere informazioni sul funzionamento dei motori vengano trattati dai responsabili dei motori stessi come dei fanciulli un po’ tardi e innocenti, da proteggere a tutti i costi dallo stress mentale che accuserebbero se venissero messi di fronte alla fredda realtà tecnica delle cose.

Insomma, oggi ci sono persone che credono che gli spider “seguano” i link perché per veicolare più facilmente il concetto di “spider” è stato deciso di umanizzare un software di crawling attribuendogli metodi di perlustrazione del web analoghi a quelli seguiti dagli esseri umani. Non c’è quindi da stupirsi se in giro c’è un po’ di confusione.

La cruda realtà

Tenetevi forte: i bambini vengono a questo mondo a seguito di un processo chiamato “riproduzione sessuata”. I dettagli non li do, perché sono un po’ scabrosi.

Come se questa prima dirompente rivelazione non fosse già di per sé sufficiente a sradicare violentemente ogni vostra convinzione sul genere umano, aggiungo anche che gli spider dei motori si limitano in realtà a richiedere le risorse sul web estraendole da un gigantesco elenco di URL da scaricare.

Quando uno spider visita una pagina web, estrae da essa gli URL delle risorse linkata dai link nella pagina e li aggiunge (se non li conosceva prima di quel momento) ad un elenco di URL condiviso con altri spider.

Un primo punto da chiarire è che, a differenza di un umano, uno spider non ha un’esigenza immediata a richiedere un URL appena scoperto. Se una persona clicca un link è perché desidera visitare subito la risorsa linkata ma uno spider ha obiettivi diversi nei confronti delle risorse e quindi la richiesta di una risorsa può avvenire anche dopo diverso tempo dalla scoperta del link in cui veniva citata.

Un secondo ed essenziale punto da smarcare è che non sempre è conveniente che una risorsa appena scoperta attraverso un link venga richiesta dallo stesso spider che l’ha individuata. Al contrario, nella logica di crawling distribuito che tutti i motori di ricerca impiegano, l’esercito di spider che si dividono il compito di scaricare risorse dal web viene organizzato in modo che il lavoro sia suddiviso per ridurre il più possibile i tempi ed i costi.

Per esempio, i software di crawling possono essere installati su computer dislocati in punti diversi del pianeta e le richieste di URL possono essere smistate cercando di minimizzare la distanza geografica tra uno spider e la presunta localizzazione geografica del server che ospita la risorsa da scaricare.

Di conseguenza se uno spider dislocato geograficamente in Europa trova un link ad una risorsa presumibilmente ospitata su un server dall’altro capo del pianeta, invece di effettuarne esso stesso la richiesta può limitarsi ad aggiungere l’URL ad un elenco condiviso di richieste da effettuare, che potranno poi essere prese in carico da spider geograficamente più vicini alle risorse da scaricare.

Non tutti i motori di ricerca si comportano in questo modo e la progettazione di un sistema di crawling distribuito è una delle attività più complesse studiate e portate avanti dalla disciplina dell’information retrieval. Anche se le implementazioni sono svariate, tuttavia, la filosofia di distribuzione di carichi e compiti sta alla base di tutti i più sofisticati sistemi di crawling e questo implica che per gli spider non è conveniente “seguire” il link ad una risorsa appena scoperta. Quindi, il fenomeno del “seguire un link” non esiste.

I danni dell’equivoco

La precisazione sul modo in cui gli spider perlustrano il web potrebbe terminare qua se non fosse che nel corso del tempo ho osservato diverse persone implementare regole sui propri server sulla base dell’equivoco.

Questi episodi mi permettono di illustrare una inevitabile conseguenza del fatto che gli spider in realtà non seguono affatto i link, ovvero che non dichiarano (quasi) mai un Referer, cioè l’intestazione di richiesta HTTP adibita a contenere l’URL di una eventuale risorsa di provenienza.

Chi credeva erroneamente che gli spider dei motori seguissero effettivamente specifici link, da una risorsa all’altra, era per conseguenza indotto anche a credere che gli spider presentassero un’intestazione Referer, dichiarando esplicitamente la pagina su cui era presente il link seguito.

Con questa convinzione in animo, ho visto casi in cui alcuni web server erano stati configurati per erogare uno statust HTTP di tipo Forbidden (codice 403) agli spider che dichiaravano la provenienza da specifici URL o siti, con l’obiettivo di far ignorare al motore di ricerca degli specifici backlink.

E’ difficile enumerare con lucidità la quantità di motivi per i quali la suddetta logica è, purtroppo, fallata. Quand’anche gli spider dei motori fossero progettati per seguire i link e quand’anche essi dichiarassero la risorsa di provenienza attraverso l’intestazione Referer, non ci sarebbe ragione di credere che vietando (Forbidden) agli spider di accedere alla risorsa si otterrebbe un effetto positivo.

Presentare agli spider uno status Forbidden su una specifica risorsa, indurrebbe semplicemente il motore di ricerca e de-indicizzare la risorsa stessa, visto che nessun motore vorrebbe includere nelle SERP una risorsa di cui è proibito l’accesso.

Non sarebbe logica nemmeno un’eventuale obiezione che lo status Forbidden sarebbe stato erogato allo spider solo condizionalmente, ovvero solo se lo spider avesse presentato come Referer l’URL di una risorsa linkante indesiderata. Il problema con questo ragionamento è che non tiene conto di una delle caratteristiche principali del protocollo HTTP, ovvero che è un protocollo stateless.

Stateless significa che il protocollo HTTP non possiede il concetto di sessione (un meccanismo per portarsi dietro un contesto comune durante richieste differenti) e che ogni richiesta fa dunque storia a sé.

Come conseguenza, un eventuale status Forbidden erogato da un server dichiarerebbe allo spider una caratteristica della risorsa richiesta (cioè che non è possibile accedervi), non una caratteristica della relazione tra la risorsa ed un’altra che la linka!

Tornando alle conseguenze negative dell’implementazione di un filtro lato server come quello sopra descritto, si può concludere che per fortuna esso si limita ad appesantire un minimo il server, visto che lo status Forbidden verrebbe erogato solo nel caso in cui gli spider presentino un Referer, cosa che non avviene (quasi) mai.

Intermezzo videoludico

Tempo fa avevo creato una breve presentazione proprio sul tema discusso in questo articolo. Era in inglese e l’ho tradotta in italiano, mi è parsa un buon riassunto. Buona visione.

Ma allora che significa follow/nofollow?

Una mappa del web. Fonte: OPTE Project (http://www.opte.org/maps/)

Stabilito che gli spider non seguono realmente i link è legittimo chiedersi allora che cosa cavolo significhi l’espressione “following” e, nel dettaglio delle due direttive previste dal Robots Exclusion Standard, quale sia il vero significato di “follow” e “nofollow”.

Vado subito al sodo. La direttiva “follow“, che rappresenta il comportamento di default degli spider e che pertanto è del tutto superflua quando viene inserita esplicitamente in un meta tag ROBOTS, chiede allo spider: “aggiungi tutti i link presenti in questa pagina al link graph”.

Di contro, la direttiva “nofollow” chiede allo spider: “non aggiungere questo/i link al link graph”.

Il link graph è semplicemente la mastodontica mappa di link tra le risorse del web che il motore di ricerca si è costruito durante le proprie perlustrazioni. Quando uno spider individua un nuovo link tra due risorse, fa in modo che nel link graph venga memorizzata l’esistenza di quel collegamento da una risorsa all’altra. Se il webmaster ha dichiarato quello specifico link come “nofollow” allora la memorizzazione di quel collegamento non avviene ed il link graph non viene modificato.

Tutto ciò, come vedete, non è poi così difficile da spiegare o da comprendere. Avrei fatto più fatica a spiegare la riproduzione sessuata.

Link di approfondimento

Distributed web crawling
On the Feasibility of Geographically Distributed Web Crawling [PDF]
Stateless protocol
Riproduzione sessuata

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

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.

Questo articolo descrive come ho svolto un test per determinare se una piccola modifica al testo di un tag TITLE avrebbe prodotto un CTR maggiore sulle SERP di Google.

Come spesso capita, tuttavia, “l’appetito vien mangiando” e oltre a determinare l’esito del test sulla base dei KPI definiti, lungo il cammino mi è venuta un’idea per definire un KPI diverso dal CTR, che potrà essere sfruttato in test futuri.

Vi do dunque visibilità dell’intero processo che ho seguito, dall’idea all’esecuzione, alle considerazioni che mi hanno spinto a tirar fuori dal cappello anche qualcosa di nuovo.

Ne approfitto per ringraziare il cliente che mi ha dato il permesso di divulgare i risultati del test, opportunamente anonimizzati.

Obiettivi del test

Avendo a disposizione una risorsa con una solida visibilità per “money query” abbastanza popolari e che da tutti i check di ranking appare saldamente ancorata alle stesse posizioni da molto tempo, ho pensato di svolgere un test per vedere se il CTR sulle SERP sarebbe aumentato.

L’idea di base era quella di aggiungere al testo del tag TITLE della risorsa un semplice aggettivo che avrebbe potuto motivare maggiormente gli utenti a cliccare sul risultato.

Oltre a misurare eventuali benefici sul CTR, esistevano due ulteriori ragioni per effettuare un test su una specifica risorsa:

• comprendere se la modifica al testo del titolo avrebbe potuto influenzare negativamente la visibilità della risorsa, un dubbio che andava necessariamente dissipato prima di estendere eventualmente la tecnica ad altre pagine del sito web
• sposare pienamente quel sano approccio che prevede che le decisioni debbano essere supportate dai dati, quando possibile, invece che indotte da opinioni, congetture ed ipotesi non confermate.

La modifica al titolo

Tipo di modifica

La risorsa oggetto del test ospitava informazioni su prodotti. La modifica al testo del titolo è consistita nell’informare l’utente del motore, attraverso l’inserimento di un semplice aggettivo, della freschezza di tali informazioni.

Semantica

Grande attenzione è stata posta nel non stravolgere il senso del titolo a seguito della sua modifica. Il titolo è stato dunque mantenuto sostanzialmente identico, in modo che il messaggio veicolato al lettore rimanesse lo stesso.

Mantenimento del target

Esisteva l’obiettivo di non produrre grandi cambiamenti all’insieme di query per le quali la risorsa era visibile. L’aggettivo aggiunto al titolo, quindi, è stato preferito ad altri anche perché non era tipico delle query degli utenti interessati a quel genere di risorse.

Obiettivi di comunicazione

In comparazione con l’aggettivo che è stato poi utilizzato nel test, esistevano sicuramente altri aggettivi che avrebbero potuto attrarre maggiormente il click degli utenti. Alcuni aggettivi, tuttavia, avrebbero potuto essere percepiti come leggermente fuorvianti o meno attinenti dai visitatori della risorsa. Il test pertanto ha tenuto conto degli obiettivi di comunicazione ed il cliente ha scelto un aggettivo che non avrebbe potuto generare alcuna perplessità o ambiguità.

KPI, misurazioni e condizioni

Per determinare se il titolo modificato avrebbe portato più risultati di quello originario, è stato necessario definire con chiarezza un KPI ed una serie di condizioni che avrebbero reso il test valido solo se le stesse fossero state rispettate.

La definizione dei KPI è una delle fasi più strategiche di un test, perché non è sufficiente scegliere un indicatore ma è necessario anche specificare in che modo esso va calcolato e quali strumenti usare per misurare esso o altri dati che concorrono a determinarlo. Più il processo di definizione dei KPI è rigoroso, più i risultati del test possono essere considerati attendibili.

Esistono inoltre diversi altri vantaggi per definire i KPI in modo rigoroso: innanzitutto una procedura chiara e dettagliata del loro calcolo permette di rendere il processo riproducibile in modo corretto anche in occasioni future, in secondo luogo la riproducibilità consentirà ad altre persone di cimentarsi nelle stesse misurazioni ottenendo risultati comparabili con quelli di test precedenti.

KPI

Il KPI scelto per misurare l’esito del testo è stato il CTR sulle SERP di Google riferito alla risorsa di cui sarebbe stato modificato il titolo. Il valore di CTR sarebbe stato calcolato dividendo i click ricevuti per le impression effettuate da Google. Lo strumento attraverso il quale estrarre i dati di click e impression sarebbe stato Google Webmaster Tools, che fornisce esplicitamente tali informazioni. L’acquisizione del dato sarebbe avvenuta attraverso il pannello di Google Analytics, sul quale è possibile importare i dati di GWT.

La comparazione da fare per determinare l’esito del test sarebbe stata quella tra il CTR registrato sui ventuno giorni che precedono il cambio del testo del titolo sulla SERP ed il CTR registrato sui ventuno giorni che seguono il cambio del testo del titolo sulla SERP. Pertanto:

Misurazioni

L’acquisizione dei dati necessari al calcolo del KPI avrebbe previsto l’estrazione da Google Analytics delle informazioni su impression e click di ciascuno dei giorni interessati ai periodi su cui sarebbero stati effettuati i calcoli.

Queste informazioni sarebbero state acquisite da GA nel seguente modo:

1. Accedendo alla sezione Traffic Sources > Search Engine Optimization > Landing Pages
2. Aggiungendo all’elenco un filtro che mostrasse esclusivamente la risorsa oggetto del test
3. Facendo mostrare sul grafico sia impression sia click
4. Esportando i dati attraverso la voce Export > Excel

Condizioni

Affinché il test possa essere considerato valido, è necessario che le seguenti condizioni vengano soddisfatte:

• Durante il periodo monitorato dal test, la posizione media della risorsa non deve cambiare in maniera consistente. La tolleranza massima accettata è di 0.2 posizioni di differenza tra la posizione media registrata sulle venti giornate precedenti la modifica e la posizione media registrata sulle venti giornate successive alla modifica.
• Durante il periodo monitorato dal test, lo snippet mostrato da Google dopo il titolo non deve subire modifiche per le top 10 query che generano più impression.
• Durante il periodo monitorato dal test, la classificazione delle query (es: informative, transazionali, ecc.) per le quali la risorsa viene proposta da Google non deve cambiare a seguito di fenomeni di mercato o stagionali. Per esempio, se una parola tipicamente presente nelle query diventasse il brand di una nuova azienda che si propone sul mercato, questo evento potrebbe modificare la classificazione di alcune delle query.

Se ci fate caso, tutte le condizioni sono state imposte per garantire che durante il periodo del test non subentrino fenomeni che potrebbero cambiare il CTR della risorsa monitorata.

In altre parole, comparare il CTR di due diversi periodi ha senso solo se durante il test lo scenario delle SERP rimane in più possibile stabile.

Il test

Sulla SERP, il testo del titolo della risorsa è cambiato in data 7 gennaio 2013.

La data era un po’ infausta, perché con l’epifania si chiude il periodo di festività e temevo che vi potessero essere differenze di comportamento degli utenti tra il periodo delle festività e quello di ritorno al lavoro. Come darò evidenza nella sezione “Fugare i dubbi”, non sono emerse evidenze a sostegno del mio timore.

A fine gennaio 2013, il test è stato chiuso. Sono state svolte delle analisi per accertarsi che le condizioni necessarie fossero state rispettate e prima di mettermi a calcolare il valore del KPI, ho iniziato a dare un’occhiata non-scientifica al CTR su Google Analytics, perché ero curioso di vedere se c’erano evidenze di una miglioria già “ad occhio nudo”.

Prime evidenze

Per scorgere eventuali differenze nel CTR in modo visuale, ho pensato di usare la visualizzazione animata di Google Analytics, partendo dal primo dicembre 2012 e facendo avanzare l’animazione fino alla fine di gennaio 2013. Ho ritenuto che il tipo di animazione più chiaro fosse quello con una barra verticale.

Che cosa osservare nel video che segue: il CTR della pagina ha oscillato attorno al 20% per tutto il periodo precedente la modifica del titolo sulla SERP. Dal momento in cui la modifica è stata apportata (periodo evidenziato in verde) il CTR del 20% è diventato invece la base minima ed il valore non è più sceso sotto quella soglia.

Già da queste prime osservazioni non emergeva un incremento consistente del CTR però sembrava evidente una miglioria, che il calcolo del KPI ha successivamente confermato.

Calcolo del KPI

Una volta soddisfatte in modo non scientifico le mie curiosità estemporanee, ho calcolato il KPI secondo le modalità e le formule stabilite a monte.

Da GA sono stati scaricati i dati di click e impression per la specifica risorsa oggetto del test ed è stato calcolato il CTR via Excel. Voglio sottolineare che non è stato preso il CTR comunicato da GWT/GA ma che esso è stato calcolato facendo il rapporto tra click e impression.

Una volta calcolato il CTR per ciascuna giornata, sono state calcolate le medie del CTR del periodo precedente alla modifica dello snippet e il periodo successivo alla modifica dello snippet.

Comparando il CTR medio dei due periodi è stato confermato anche matematicamente l’evidenza che emergeva dalla semplice osservazione dell’animazione del grafico del CTR: il valore risultava leggermente aumentato dal 19.9% al 22.7%.

Fugare i dubbi

C’era un ulteriore dubbio da fugare riguardo l’attendibilità del test: accertarsi che gli incrementi di CTR registrati nel secondo periodo non fossero imputabili ad una fisiologica variazione stagionale delle abitudini degli utenti.

Ho allora preso in esame un piccolo insieme di query che restituivano risultati diversi da quello oggetto del test, ma comparabili per tipologia. Per questi risultati lo snippet sulla SERP era rimasto invariato e una comparazione effettuata sugli stessi due periodi oggetto del test non ha mostrato variazioni di CTR (in positivo o negativo) significative quanto quella osservata sulla risorsa oggetto della modifica del testo del titolo.

Questa valutazione è tipica del test che fanno uso di un campione di controllo. Sarebbe stato meglio definire nel dettaglio le modalità di uso del campione di controllo prima dell’esecuzione del test, tuttavia in questo specifico caso ho dovuto ripiegare su un controllo post-test.

Esito del test

Il calcolo del KPI non dà spazio a dubbi e le condizioni inizialmente definite affinché il test potesse essere considerato valido sono state pienamente rispettate. Di conseguenza il test ha dimostrato che la lieve modifica al titolo della risorsa ha comportato un lieve incremento del CTR sulla stessa.

Esistevano quindi le condizioni per suggerire al cliente la modifica del titolo di altre risorse strategiche del sito, seguendo gli stessi criteri adottati per la risorsa oggetto del test.

E dunque test valido, risultato positivo, tecnica scalabile sul resto del sito, tutti contenti e bella lì.

Si può fare di più

Chiuso il test per il cliente, ho deciso di impiegare del tempo personale per ragionare sul KPI scelto, basato sul CTR della risorsa.

Non c’è dubbio che per voler misurare la capacità di una risorsa di attrarre dalla SERP il click dell’utente, il CTR è sicuramente l’indice che per primo viene in mente come strumento per misurare l’esito dell’attività.

Va però evidenziato che, per quanto sia una discreta base di partenza, il CTR è facilmente soggetto a fenomeni che inficiano test di questo tipo. Se la risorsa avesse cambiato posizione media in modo deciso durante i giorni di monitoraggio, il CTR sarebbe probabilmente cambiato in modo pesante, in quanto i click sulle risorse alle posizione superiori sono generalmente maggiori rispetto ai click sulle risorse alle posizioni inferiori.

Per esempio, una discesa della risorsa in SERP avrebbe prodotto un CTR minore e a quel punto non sarebbe stato possibile comprendere se e quanto la modifica al titolo avesse indotto gli utenti a cliccare di più o di meno. Allo stesso modo, una salita della risorsa nelle SERP avrebbe prodotto un CTR maggiore, da attribuire forse più al cambio di posizione che alla modifica del testo del titolo.

La scelta del CTR come KPI per un test simile rende dunque la validità del test stesso troppo facilmente vittima di fenomeni di cambio di posizione: se la posizione media subisce variazioni consistenti il test sarebbe invalido e da gettare via.

Nello specifico caso del test oggetto dell’articolo, ci si era volutamente focalizzati su una risorsa che da tempo mostrava posizioni consolidate e poco soggette ai naturali movimenti della SERP ma, nonostante l’esito positivo, al sottoscritto era rimasta la curiosità di individuare un KPI più solido, che mantenesse la propria validità prescindendo da eventuali cambi di posizione della risorsa.

Per essere più espliciti: volevo trovare un indicatore di quanto una risorsa in SERP fosse in grado di attrarre i click degli utenti in funzione del proprio “appeal”, a prescindere dalla sua posizione o dai cambiamenti di posizione. Se volete, consideratelo un indice di “intrinseca figosità”.

Siccome l’espressione “indicatore di quanto una risorsa in SERP fosse in grado di attrarre i click degli utenti in funzione del proprio appeal” era un po’ lunga, ho pensato per semplicità di chiamare questo indicatore “Click Love“. Adesso vi spiego come ci sono arrivato e come usarlo.

Click Love: prime prove

Il primo approccio per individuare una formula ragionevole per calcolare il Click Love è stato quello di partire dalla consapevolezza che ciò che appare in posizioni superiori è in media più cliccato di ciò che appare in posizioni inferiori.

Esistono eccezioni a questa regola, per esempio è stato notato che in diversi contesti il risultato che sta in prima posizione della seconda pagina può avere un CTR maggiore rispetto all’ultimo risultato della prima pagina. Per semplicità di analisi, tuttavia, restringerò il campo di studio alla sola prima pagina delle SERP.

Tenendo conto di questo naturale fenomeno di distribuzione dei click sulla SERP, è possibile fare delle prime considerazioni su come attribuire un Click Love ad una risorsa in SERP. Per esempio, un CTR alto misurato su una risorsa in prima posizione può essere plausibile ma lo stesso CTR misurato su una risorsa in settima posizione evidenzierebbe una particolare capacità di quella risorsa ad attrarre i click nonostante la posizione bassa.

Nella seguente tabella mi sono limitato a fare delle considerazioni sul significato di un CTR in base alla posizione della risorsa su cui è stato osservato, a parità di risorsa e query ed esagerando volutamente i valori per facilitare la comprensione della logica di fondo:

Sulla base delle suddette considerazioni è possibile abbozzare già una prima formula per il calcolo del Click Love. So che, a parità di CTR, il Click Love deve essere maggiore per le posizioni più in basso nella SERP e so che, a parità di posizione, il Click Love deve essere maggiore per le risorse su cui è stato osservato un CTR maggiore.

Con questo obiettivo, la formula più semplice che si può tirar fuori è una semplicissima moltiplicazione, ovvero:

Applicando questa semplice formula ai valori citati nella tabella di cui sopra, emerge che il concetto di fondo è corretto: i risultati più eclatanti mostrano un Click Love più alto (per avere dei valori moltiplicabili tra loro, ho tradotto le percentuali in un valore tra 0 ed 1. Dunque 30% è diventato 0,3):

Ragionando su questa prima bozza della formula, che consiste in una banale moltiplicazione tra CTR e posizione media, si evince con una certa facilità che è possibile ottenere un Click Love di 0,3 in infiniti modi, per esempio con un CTR del 30% su una risorsa in prima posizione oppure con un CTR del 10% su una risorsa in terza posizione. In entrambe i casi un Click Love di 0,3 non evidenzia una particolare capacità di una risorsa ad attrarre click, perché è abbastanza plausibile attendersi un CTR del 30% per la prima posizione, così come un CTR del 10% per la terza posizione.

E dunque abbiamo trovato la nostra formula del Click Love. Dal punto di vista teorico funziona, è un indice che tiene conto sia del CTR sia della posizione media delle risorse, tutti contenti e bella lì.

Click Love: perplessità

In realtà questa prima formula individuata è molto semplice e già sento echeggiare in testa un paio di critiche, la prima solleversi dal volgo armato di torce e forconi, la seconda mossa da me stesso a me stesso medesimo.

La prima perplessità è di tipo generico ed è indirizzata al senso dell’operazione in sé. “Enrico, la formula è troppo semplice e inadeguata. Le SERP sono soggette a fin troppi fenomeni che possono influenzare il click degli utenti: la personalizzazione e Universal Search e le immagini che attraggono l’occhio e le inserzioni AdWords e il Knowledge Graph e i One Box e la geolocalizzazione e la rava e la fava.”

E’ indubbio che esistano innumerevoli fenomeni che influenzano il click degli utenti, tuttavia non bisogna dimenticare qual è l’obiettivo del Click Love: eliminare (o quantomeno minimizzare) l’incognita del cambio di posizione dalla complessa valutazione di quanto una risorsa invita al click.

Il Click Love è dunque un primo passo in avanti per allontanarsi dall’inadeguato CTR, fin troppo soggetto a cambiamenti a seconda di eventuali cambi di posizione in SERP. Il Click Love non è né diventerà mai un indice perfetto ma per certo è migliore di un semplice CTR quando si devono comparare i risultati registrati su due diversi periodi, perché minimizza l’influenza di una variabile (la posizione della risorsa) che potrebbe inficiare l’intero test.

La seconda perplessità la pongo io e riguarda il modo in cui i click degli utenti vengono solitamente distribuiti lungo la SERP.

Nella prima bozza di formula che ho ideato, il CTR viene semplicemente moltiplicato per la posizione media. Questo significa che, a parità di CTR, è stato deciso che ad una risorsa in seconda posizione va attribuito un peso doppio rispetto ad una risorsa in prima posizione. Allo stesso modo, ciò che sta in quarta posizione “pesa” il quadruplo di ciò che sta in prima posizione e ciò che sta in ottava posizione viene moltiplicato per otto, ovvero otto volte quello che sta in prima posizione.

Questi valori con cui moltiplicare il CTR crescono quindi in modo del tutto lineare e sarebbero adeguati al nostro scopo solo se la distribuzione in SERP dei click degli utenti seguisse effettivamente un andamento altrettanto lineare. Nella realtà però le cose stanno in modo molto diverso: diverse ricerche hanno mostrato che i click sulle SERP si distribuiscono seguendo una curva che è tutto fuorché lineare.

Di conseguenza, una semplice moltiplicazione del CTR per la posizione media rappresenta una semplificazione eccessiva: nonostante sia corretto attribuire un Click Love maggiore alle risorse che stanno più in basso, il “quanto” il Click Love debba essere maggiore allo scendere della posizione è un punto importante della questione, che separa una formula grezza da una formula accettabile.

Per far le cose per bene, la formula del Click Love deve tener conto di una tipica distribuzione dei click sulle SERP.

Click Love: maggiore precisione

A costo di sembrare troppo perentoreo, sono costretto a fare un’affermazione un po’ drastica: tutte le ricerche che sono state effettuate da illustri brand e aziende sulla distribuzione dei click sulle SERP sono fuorvianti. Ma proprio tutte.

Sia ben chiaro, non sto mettendo in dubbio la validità degli approcci seguiti nel misurare i CTR o la correttezza dei risultati. Dico solo che il modo in cui i risultati sono stati presentati al pubblico, ovvero sotto forma di barbare semplificazioni, non può che generare applicazioni fuorvianti.

La misurazione del CTR sulle SERP è un argomento complesso e un’attività di difficile esecuzione. La complessità dei fenomeni che regolano l’interazione degli utenti con i risultati delle ricerche dei motori è talmente alta che qualsiasi tentativo di calcolare medie su una grande quantità di osservazioni genera risultati che descrivono male la realtà.

Diverse aziende che si sono cimentate nella misurazione del CTR, per esempio, hanno prodotto degli orrendi mischioni in cui il CTR veniva calcolato su query di ogni tipo. Già questo approccio genera risultati privi di significato, perché la distribuzione dei click varia considerevolmente a seconda delle diverse tipologie di query: navigazionale, informativa, branded/unbranded, di specifici settori merceologici, ecc.

Nonostante la ricerca che io giudico meglio portata avanti sia quella di Mec, riassunta in un’infografica che vi invito a leggere, la quantità dei dati pubblicati non era sufficiente per le mie necessità. Pertanto ho dovuto ripiegare sui dati misurati e pubblicati in uno studio analogo, svolto da Optify nel 2010 [PDF].

Per ottenere una formula di Click Love che tenesse conto della distribuzione dei click nelle SERP, ho proceduto come segue:

1) Ho preso i dati di Optify, che riguardavano i CTR registrati sulle prime venti posizioni delle SERP, ed ho preso in considerazione solo i CTR delle prime dieci posizioni;

2) Ho disegnato i valori dei CTR su un piano cartesiano;

3) Ho individuato una formula (a) che disegnasse una curva che segue approssimativamente l’andamento dei valori di CTR. La formula (a) è dunque in grado di descrivere la distribuzione dei click sulla SERP:

4) Ho creato una seconda formula (b) che moltiplicata ad (a) restituisse una costante. In altre parole la formula (b) annulla gli effetti di (a), che è la formula che rappresenta la distribuzione dei click. Se masticate un minimo di matematica, saprete che (b) si può ottenere semplicemente facendo il reciproco di (a):

5) Ho generalizzato (b) eliminando una costante che mi era servita solo per far combaciare inizialmente la curva con i dati dei CTR misurati da Optify, ottenendo infine un’espressione da usare come moltiplicatore del CTR per ricavare il Click Love:

La formula definitiva del Click Love, che stavolta è in grado di tener conto di una realistica distribuzione dei click sulle SERP, è dunque:

, dove “n” è una variabile che nell’esempio specifico dei dati di Optify equivale a 1.22 ma che può essere modificata a discrezione per meglio adattarsi alla distribuzione di click di una specifica query o classe di query. Per esempio, valori più alti di “n” sono adatti per calcolare il Click Love di query che registrano percentuali di click molto alte sui primi risultati (es: query brandizzate) mentre valori più bassi di “n” sono adatti per calcolare il Click Love di query che registrano click più omogeneamente distribuiti lungo i dieci risultati della SERP.

Sulla base dei dati di Optify, che delle diverse tipologie di query ha fatto un minestrone, il valore di “n” è pari a 1.22, che può essere considerato un valore da usare per query generiche, che inducono l’utente a cliccare più di un risultato della SERP.

E dunque formula trovata, obiettivo raggiunto, giochino matematico appagante e bella lì.

Click Love: vantaggi

La formula del Click Love può essere usata ogni qualvolta è necessario determinare un indice di “figosità” o “attrazione di click” di una specifica risorsa che appare in SERP, col vantaggio che l’indice mantiene una propria coerenza anche nel caso in cui la risorsa cambi di posizione durante il periodo di monitoraggio.

Nel caso in cui vogliate studiare in che modo le modifiche allo snippet di una risorsa hanno influito sui click che essa ha raccolto, il Click Love rappresenta un indice meno problematico e più affidabile del semplice CTR.

Click Love: come usarlo

L’indice è perfetto per fare comparazioni tra la capacità di attrarre click di una risorsa misurata prima e dopo una modifica al poprio snippet.

Va precisato che la formula è in grado di minimizzare gli eventuali effetti nefasti di un cambio di posizione della risorsa monitorata ma che non tiene conto di giganteschi sconquassi alla SERP. Se una SERP viene improvvisamente modificata da Google aggiungendo nuovi elementi in grado di attrarre l’attenzione dell’utente, non c’è formula che possa mantenere la propria validità. In fase di svolgimento di un test, quindi, rimangono opportune e valide le varie condizioni che sono elencate in cima all’articolo, con l’eccezione della condizione riguardante il cambio di posizione.

L’applicazione del Click Love ad un test come quello descritto ad inizio del post è del tutto analoga a quanto fatto col CTR: si calcola prima il Click Love di ciascuna giornata e si fa poi una comparazione tra il Click Love medio registrato sul periodo precedente alla modifica dello snippet ed il Click Love medio registrato sul periodo successivo alla modifica.

Una seconda applicazione del Click Love può essere quella di comparare tra loro i Click Love di diversi risultati nella stessa SERP, posto che si possiedano i dati di CTR e posizione media dei due snippet che si desidera comparare.

Sia che la comparazione avvenga tra due diverse risorse, sia che avvenga sulla stessa risorsa monitorata su due periodi differenti, bisogna fare attenzione ad attribuire il giusto valore ad “n” e a mantenerlo durante tutte le comparazioni effettuate su risultati della stessa query o tipologia di query.

Come già accennato, un valore di “n” attorno a 1.2 riesce a descrivere una distribuzione dei click tipica di query che inducono l’utente a visitare diversi risultati. Per query branded, “n” può superare 2 e personalmente consiglio di assegnargli un valore compreso tra 2 e 3.

Non fatevi ingannare dall’apparente difficoltà ad individuare un valore di “n” adatto, perché non esistono valori “giusti” o “sbagliati”: l’aspetto realmente importante è che “n” venga definito una volta per ciascuna tipologia di query e mantenuto per sempre.

Click Love: come non usarlo

Non potete usare il Click Love per comparare la “figosità” di snippet/risorse che appaiono per query diverse: sarebbe un’azione semplicemente priva di senso.

Il Click Love non è un indice di qualità intrinseco di una risorsa o snippet, ma solo un indice di quanto la risorsa è in grado di attrarre click all’interno di un contesto specifico, ovvero il contesto di una query o di un insieme di query dalle caratteristiche simili.

In pura teoria sarebbe possibile calcolare il Click Love medio di una grande quantità di query e poi monitorarlo nel corso del tempo, per esempio per osservare gli effetti di una vasta attività di copywriting dei titoli. Sebbene possibile, io sconsiglio di applicare il Click Love a grandi accozzaglie di query troppo diverse tra loro, per esempio query di settori diversi o di tipologia diversa (navigazionale, transazionale, ecc.). Questo genere di comparazioni acquista un po’ più senso classificando le query per tipologia, ma il mio consiglio rimane quello di non farsi prendere dalla voglia di usarlo su larga scala.

Per generalizzare: è una pessima idea usare il Click Love per vedere chi ce l’ha più lungo/alto/figo/duro.

Click Love: limiti

Il Click Love è lontano dall’essere perfetto. Questa affermazione va ben oltre la considerazione che non è possibile produrre una formula perfetta ma significa che anche dal punto di vista matematico è stato scelto di affidarsi ad una modalità di distribuzione dei CTR che presenta delle rigidità: può variare al variare di “n” ma rimane comunque di tipo esponenziale.

Per come la formula è stata presentata in questo articolo, inoltre, vale la pena di sottolineare di nuovo come essa sia dedicata solo ai primi dieci risultati della SERP. E’ facile estendere la formula ai risultati successivi al decimo, persino tenendo conto del fenomeno che vede il primo risultato della seconda pagina pià cliccato dell’ultimo risultato della prima pagina. Ma essendo il Click Love poco più di un “proof of concept”, lascerò eventuali estensioni al lettore.

Conclusioni

Test sul CTR effettuato, modalità di approccio descritte, idee su nuovo KPI condivise. Bella lì.

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

Torna, a richiesta di quei poveri dipendenti da quiz che me li chiedono spesso, un nuovo Quiz SEO bastardo!

I quiz SEO bastardi sono accuratamente progettati per far scervellare i SEO. L’obiettivo dei quiz è quello di studiare un po’ i motori di ricerca e magari imparare qualcosa di nuovo durante il processo di analisi che a volte è necessario intraprendere per arrivare alla risposta corretta.

Se non conoscete i quiz SEO bastardi, date un’occhiata alla categoria del blog che li raccoglie. Adesso bando alle chiacchiere e leggete il quiz!

Il quiz

Per vostra comodità pubblico anche un link ai risultati della ricerca [inmeta:sans] e uno screenshot, per come li vedo io in questo momento con Chrome su Google.com come utente loggato.

Occhio che se non si è loggati in Google (o se loggati con alcuni account, come qualcuno ha evidenziato da nei commenti) la SERP potrebbe apparire vuota!

Come di consueto, lascerò le votazioni ed i commenti aperti per alcuni giorni. Raggiunte un po’ di partecipazioni, chiuderò il quiz e dichiarerò il vincitore.

Siccome siamo qui per imparare, vi invito a non essere timidi e ad aggiungere un commento se vi va di argomentare la risposta che avete dato. Detto ciò, buon quiz a tutti!

La mia impressione è che questo genere di analisi fosse più comune in passato che non oggi, eppure osservando i comportamenti degli spider è possibile osservare possibili criticità e persino trarre informazioni sull’opinione che un motore di ricerca si è fatto di un sito web. I log sono utili anche per altri scopi, per esempio di web analysis, ma questo esula dal tema del presente post.

Questo articolo nasce da un breve post sull’argomento scritto tempo addietro su Google+. Martino Mosna mi chiedeva perché non ne facevo un articolo per il blog ed io non ritenevo che i contenuti fossero particolarmente interessanti.

Di conseguenza ho deciso di riscriverli e arricchirli, aggiungendo anche i risultati di una reale analisi SEO che ho svolto qualche mese fa, penso che alla fine sia venuto fuori qualcosa di potenzialmente utile.

Tutto ciò che segue fa riferimento al motore di ricerca Google e allo spider Googlebot dedicato all’indice Web. Alcune delle considerazioni fatte possono essere estese attraverso il (vostro) sano buonsenso anche agli spider di altri motori di ricerca.

Introduzione

L’analisi dei file di log del web server è un pezzo del vasto puzzle delle analisi SEO e può fornire indicazioni molto utili. Per esempio è possibile capire:

1. se c’è qualcosa che non va nella navigazione interna del sito
2. quanto velocemente lo spider reagisce alla pubblicazione di nuove risorse
3. se lo spider mostra poco interesse nei confronti di risorse strategiche e che è importante far indicizzare
4. se lo spider mostra troppo interesse nei confronti di risorse non strategiche e che è secondario che vengano indicizzate (sopratutto perché la banda assegnata da Google al sito non è infinita ed è corretto ottimizzarla)
5. quali sezioni del sito vengono perlustrate di più e quali vengono invece snobbate
6. quanta importanza Google effettivamente assegna al sito web e quanto il motore è “ingordo” dei suoi contenuti. La capacità di percepire correttamente questo fenomeno non è una scienza esatta ed è possibile raggiungerla dopo un po’ di pratica e dopo aver acquisito una chiara comprensione di tutti i differenti tipi di comportamenti dello spider.

Le basi ma veramente basi del crawling di Googlebot

Leggete la seguente documentazione e fatene il vostro breviario: https://developers.google.com/webmasters/control-crawl-index/

Le basi del crawling di Googlebot

Le modalità di scansione dei siti da parte di Googlebot variano grandemente da sito a sito. I fattori che determinano queste differenze sono principalmente i seguenti:

• L’importanza assegnata da Google a ciascuna risorsa
• La grandezza del sito, in termine di risorse
• La profondità del sito
• L’architettura dell’informazione
• L’unicità delle risorse
• La frequenza di pubblicazione di nuove risorse
• La frequenza di aggiornamento delle risorse già esistenti
• L’uso di redirezioni e la quantità di risorse inesistenti
• La presenza di status d’errore del web server
• La velocità del sito ad erogare le risorse
• La quantità massima di banda che Google ha deciso di dedicare al sito

E mo’ ci tocca dettagliare questi aspetti uno per uno.

L’importanza assegnata da Google

Il PageRank è dichiaratamente (video di Matt Cutts sul PageRank) il principale fattore su cui Google si basa per decidere quanto andare a fondo nella perlustrazione di un sito.

Si può semplificare la faccenda affermando che una risorsa considerata più importante da Google indurrà maggiormente Googlebot a seguire i link che la risorsa stessa contiene.

Questa caratteristica assume un ruolo decisivo sopratutto per quei siti web che presentano livelli di profondità gerarchica molto alta o strutture di linking interno particolarmente vaste.

Importante: il messaggio di fondo di questo articolo è proprio quello che la stretta relazione che esiste tra crawling e PageRank permette di capire quanto il sito gode di buona reputazione agli occhi del motore osservando semplicemente come esso viene perlustrato dai crawler. Le informazioni che seguono vi servono per avere visibilità di tutti quei fenomeni che influiscono sul crawling, sia quelli che sono correlati all’importanza che il motore assegna alle risorse sia quelli che non devono essere confusi come segnali correlati all’importanza delle risorse. Se riuscirete ad acquisire questa capacità di analisi, una veloce occhiata ai log del server vi potrà venire d’aiuto in più di un’occasione per chiarirvi le idee sul rapporto tra sito e Google.

La grandezza del sito

Solitamente l’obiettivo dello spider è quello di ottenere un’immagine quanto più possibile completa e aggiornata del sito web. A volte tale desiderio è debole o viene a mancare nel caso di siti che Google non percepisce particolarmente importanti, tuttavia l’obiettivo ideale e teorico del motore rimane quello.

La quantità di risorse pubblicate sul sito rappresenta quindi una delle principali caratteristiche che inducono lo spider a perlustrare più ampiamente i contenuti: più lo spider individua nuovi contenuti, più sarà incentivato a proseguire e più il sito riceverà accessi ogni qualvolta lo spider vorrà controllare che le risorse siano sempre al proprio posto e se i loro contenuti sono cambiati dall’ultimo accesso.

La profondità del sito

Il concetto più semplice di profondità di una risorsa coincide con il numero di click da fare per raggiungere la risorsa partendo dalla home page.

Come vedremo di seguito, questo tipo di profondità non è l’unica esistente dal punto di vista del motore di ricerca.

Per il momento ci basta sapere che nella stragrande maggioranza dei casi, lo spider deve essere incentivato a perlustrare un livello gerarchico inferiore a quelli che ha già scandagliato.

L’architettura dell’informazione

Per ottenere una visione completa delle caratteristiche che motivano il motore a scandagliare un sito non bisogna mai dimenticare che uno dei suoi obiettivi è quello di costruirsi un grafo del sito stesso, ovvero una mappa del suo linking interno.

L’architettura dell’informazione dunque influisce pesantemente sul tipo di grafo che verrà fuori e su come il PageRank verrà distribuito tra le risorse, con le conseguenze che potete immaginare tenendo in considerazione quanto già scritto nella sezione “L’importanza assegnata da Google”.

L’unicità delle risorse

Tranne eccezioni, se Googlebot individua continuamente copie di risorse che già possiede o nota la presenza di risorse sostanzialmente prive di contenuti, allora sarà poco incentivato a seguire la stessa categoria di link che lo hanno condotto alle risorse considerate di bassa qualità.

Ho scritto “tranne eccezioni” perché più in fondo darò evidenza di tali casi particolari.

La frequenza di pubblicazione

La frequenza di pubblicazione di nuove risorse rappresenta un incentivo per Googlebot a tornare sul sito web in cerca di novità.

La frequenza di aggiornamento

Anche la frequenza con la quale le risorse esistenti vengono aggiornate può rappresentare un incentivo per lo spider a ritornare spesso sulle stesse pagine, a volte per individuare contenuti nuovi o modificati, altre volte per controllare se sono stati pubblicati nuovi link.

Redirezioni e risorse inesistenti

Le redirezioni comportano un incremento delle richieste fatte dallo spider al web server, in quanto a ciascun accesso all’URL “vecchio” corrisponde anche un accesso al “nuovo” URL di destinazione della redirezione. Questa caratteristica è maggiore nel caso in cui le redirezioni siano di tipo temporaneo (status HTTP 302 e 307) perché Googlebot (ed i client HTTP in genere) mantengono come riferimento l’URL che effettua la redirezione temporanea, non quello della risorsa di destinazione.

Riguardo le risorse inesistenti (status HTTP 404 e 410) bisogna ricordare che i loro URL vengono saltuariamente ricontrollati dagli spider, specie se sul Web esistono ancora link che puntano ad essi. E’ dunque errato credere che una risorsa 404 non generi più richieste da parte di Googlebot: un saltuario controllo di tali URL viene comunque mantenuto.

Errori del web server

Gli status di errore HTTP della famiglia 5xx sono quelli previsti dal protocollo per comunicare errori del web server, solitamente di natura tecnica.

Alla presenza di errori di questo genere, i comportamenti degli spider possono variare considerevolmente, a cominciare dalla frequenza delle richieste. Alcuni fenomeni sono inoltre particolarmente subdoli, per esempio quello di un errore di classe 5xx associato al file robots.txt del sito (un tema ultimamente gettonato a causa di un intervento mio e di Cesarino Morellato ad un Convegno GT, già aggiunto alla lista di argomenti su cui scrivere un post).

Le richieste di URL che restituiscono uno status di errore del web server inducono di norma gli spider a richiedere la URL stessa fino a quando essa smetterà di restituire errori.

Velocità del sito

Se il sito è lento ad erogare le risorse, Googlebot eviterà di chiederne molte.

Lo spider è infatti progettato per evitare di inondare i server web di richieste che potrebbero “ingolfarli”. Questo fenomeno può accadere se lo spider è troppo veloce ad effettuare richieste e/o se il server è troppo lento ad erogare le risorse chieste.

Come conseguenza, Googlebot adatta dinamicamente la propria frequenza di richieste a seconda di quanto il server web è in grado di soddisfarle in fretta.

Massima banda concessa

L’osservazione mi ha portato a concludere che esista comunque una quantità massima di attenzione (si legga: banda) che il motore di ricerca è disposto a concedere al sito web.

Applicando buonsenso e logica informatica, sarei indotto a credere che tale quantità massima di attenzione concessa sia una semplice conseguenza della combinazione di tutti i fattori sopra elencati. Tuttavia il concetto che è importante tenere a mente è che, a prescindere dalla causa, esiste una quantità massima di banda che lo spider consumerà durante uno specifico lasso di tempo (es: 24 ore).

Questo implica che è importante indurre lo spider a scaricare le risorse che più ci interessa far indicizzare, cercando di minimizzare il più possibile gli sprechi di banda legati allo scaricamento di risorse non importanti.

Mettere tutto assieme

Va da sé che che ciascuno dei fattori sopra elencati non ha valenza a sé ma influisce sul comportamento di Googlebot solo quando viene messo in relazione con tutti gli altri.

Sarebbe quindi errato dedurre che è sufficiente ottimizzare uno di quei fattori per migliorare (quantomeno dal punto di vista quantitativo) il crawling dell’intero sito.

L’unico fattore che realmente può influire da solo e facilmente su tutti gli altri è quello della velocità del sito, nel senso che un sito eccessivamente lento induce immediatamente lo spider a ridurre pesantemente la quantità di richieste.

Concetti chiave e comportamenti tipici di Googlebot

Nei paragrafi precedenti ho fornito un elenco di fattori che concorrono a determinare quante e quali risorse verranno richieste dallo spider, adesso darò invece evidenza di alcuni concetti chiave del crawling.

Velocità di scoperta degli URL

Google è in grado di scoprire nuovi URL in modo molto veloce, usando più di un metodo. Nuovi URL possono essere scoperti attraverso i link sul web, per mezzo dei ping esplicitamente inviati al motore, in feed e sitemap XML e dai tanti segnali generati dalle azioni degli utenti.

In linea teorica, se un sito ha nei propri backlink il principale canale per far scoprire agli spider i nuovi URL, allora la velocità con cui Googlebot si rende conto della nascita dei nuovi URL può essere considerata un indicatore molto grezzo di quanto il motore di ricerca considera il sito importante.

Nella pratica, molti siti web possiedono ormai più di un metodo per comunicare al motore l’esistenza di URL nuovi, pertanto la velocità di scoperta dei nuovi URL è influenzata da fin troppi fattori oltre a quello della sola importanza associata al sito.

Come regola generale, dunque, il fatto che il motore sia in grado di scoprire velocemente i nuovi URL generati dal sito non può essere considerato di per sé un indicatore di alcunché. Al contrario, se i nuovi URL di un sito non vengono scoperti dal motore entro un lasso di tempo ragionevole (es: 48 ore) allora questo può effettivamente essere considerato un indicatore del fatto che il sito non è considerato particolarmente importante da Google.

Si noti che “scoperta” viene usato nel contesto del crawling nell’accezione “quando lo spider effettua il primo accesso alla risorsa” e non quando la risorsa viene indicizzata.

Aggiornamenti

Alcuni URL vengono ri-spiderizzati più frequentemente di altri, perché il motore di ricerca ritiene importante individuare aggiornamenti ai contenuti.

La ri-spiderizzazione è un fenomeno estremamente comune e, anche nei siti web grandi, si osserva dai log che diverse risorse considerate importanti vengono richieste ripetutamente in misura maggiore delle risorse considerate secondarie.

La ri-spiderizzazione è anche un fenomeno particolarmente importante per i blog ed i siti di news, a maggior ragione se tali siti sono presenti nell’indice di Google News. Ma il crawling effettuato da Google News segue criteri molto diversi dal crawling del web e quindi non approfondirò questo punto per non andare fuori tema.

Per tutti quei contenuti che non sono associati a feed o news, la frequenza di ri-spiderizzazione è correlata principalmente a quattro fattori: 1) PageRank, 2) quanto frequentemente vengono aggiornati i contenuti della pagina, 3) quanto del contenuto viene cambiato e 4) il parametro changefreq nella sitemap XML.

Profondità fisica e profondità logica

Il concetto che sto per esporre è piuttosto importante, perché può aiutare a comprendere come mai Googlebot è indotto a (ri)chiedere alcune risorse invece che altre.

Poniamo il caso che esista un sito che riceva backlink esclusivamente sulla propria home page. In tal caso la home page sarà l’unica pagina a ricevere PageRank dall’esterno e di conseguenza la pagina dalla quale il flusso del PageRank partirà per essere distribuito in modo più o meno indiretto a tutte le altre risorse del sito.

In questo caso, del tutto teorico, la profondità di un URL può essere approssimata in modo grezzo col numero di click minimo che dalla home page conducono alla risorsa con quell’URL.

Se immaginate tale sito come una struttura gerarchica simmetrica, ogni livello della gerarchia ospiterà risorse più profonde di quelle del livello gerarchico precedente. E voi direte: “Grazie al piffero, gerarchia significa esattamente quello.”.

Sul web tuttavia la realtà è molto diversa perché pressoché tutti i siti ricevono backlink sia alla home page sia a risorse più interne. Di conseguenza la home page non può più essere considerata l’unica pagina dalla quale il PageRank esterno viene ridistribuito internamente.

Detto in altre parole, non esiste più una singola pagina principale del sito ma ne esistono molteplici, in quanto gli utenti possono approdare al sito iniziando anche da pagine che non siano l’home page.

In questo caso è giusto percepire la profondità di un URL in modo diverso. Sebbene la sua profondità fisica corrisponda sempre al numero minimo di click che separano l’URL dalla home page, la sua profondità logica dipende anche da quanto l’URL è distante da tutte le risorse del sito che ricevono backlink dall’esterno.

Per esempio, se una pagina indice di categoria riceve molti backlink dall’esterno, allora essa stessa e le risorse che essa linka avranno una profondità logica inferiore a quella fisica, come esemplificato nel grafico che segue.

Il grafico mostra in alto un esempio di gerarchia con indici di profondità (i numeri tra parentesi quadre) strettamente fisici ed in basso un esempio di gerarchia con indici di profondità logica, influenzati dai backlink ricevuti dalle risorse interne (i valori numerici sono puramente indicativi).

Perché è importante comprendere la differenza tra profondità fisica e logica? E’ importante perché solo tenendo conto di come il sito riceve backlink dall’esterno è possibile percepire correttamente se una specifica sezione del sito sta ricevendo la giusta attenzione da parte di Googlebot.

Una corretta comprensione delle profondità logiche, inoltre, è utile per capire se le sezioni con contenuti particolarmente profondi possono essere rese “meno profonde” dal punto di vista logico aumentando i link che puntano ad esse, sia i link provenienti da altri siti sia i link provenienti dalle altre risorse dello stesso sito (e questo è un punto in cui la progettazione dell’architettura dell’informazione può influire sulla distribuzione dell’importanza tra le risorse).

I furbastri tra di voi avranno intuito che la “profondità logica” non è altro che un altro modo di concepire la distribuzione del PageRank tra le risorse del sito. Se ho voluto parlare di profondità e non di PageRank è perché alla parola “PageRank” è facile che la memoria vada alla fuorviante e striminzita barretta verde, che così poca informazione fornisce a webmaster e SEO. A mio parere è più utile imparare a stimare quanto una risorsa sia “vicina alla cima” sulla base dei link interni che riceve dal sito stesso e dei link esterni che riceve dal web.

La grossa raccomandazione che è necessario fare in chiusura di questa sezione del post è quella di non dimenticare mai che tutte le considerazioni appena esposte si riferiscono a quanto gli spider sono indotti a perlustrare in base ai link interni ed esterni del sito, ma che bisogna sempre tenere conto del fatto che gli spider possono sfruttare altri canali preferenziali di individuazione e accesso alle risorse, come sono per esempio le sitemap XML o i feed.

Hidden web e spazi infiniti

Ci sono casi in cui Googlebot decide di andare a fondo molto più di quanto il PageRank delle risorse giustificherebbe.

Il fenomeno avviene quando lo spider tenta di effettuare il crawling di FORM di tipo GET oppure quanto tenta di indovinare URL possibilmente usati sul sito ma non esplicitamente linkati (URL guessing) oppure quando un sito web crea inconsapevolmente quelli che Piersante ha battezzato “spazi infiniti“.

Un esempio tipico di spazi infiniti viene a crearsi quando il widget di un calendario usa dei normali link per navigare il calendario stesso, col risultato di arrivare indirettamente a linkare un infinito (o estremamente alto) numero di anni e date future, ciascuna delle quali corrisponde ad una risorsa HTML indicizzabile.

Queste tipologie di crawling e le loro profondità non possono essere correlate ad alcun segnale sull’importanza assegnata dal motore alle risorse e vanno pertanto considerate “attività speciali” di crawling che seguono criteri diversi da quelli legati all’importanza delle risorse scoperte.

Nell’esempio di analisi che mostrerò nell’ultima parte di questo articolo darò evidenza del fatto che questo tipo particolare di crawling non è incentivato nemmeno dalla qualità dei contenuti trovati sulle risorse richieste.

Full recrawl

Simile al fenomeno che in passato veniva chiamato “deep crawl” (e che adesso probabilmente non esiste più come concetto) il full recrawl avviene quando il motore di ricerca decide di svolgere un crawl quanto più completo del sito stesso. Tale decisione è a volte conseguente ad un cambiamento radicale dei contenuti del sito e delle sue URL.

Visto che il full crawl è un comportamento temporaneo e a volte una conseguenza di uno specifico fenomeno avvenuto sul sito, non è corretto considerarlo correlato all’importanza che il motore di ricerca ha assegnato al sito stesso.

Dalla teoria alla pratica

Imparare a capire dai comportamenti di Googlebot in che modo il sito è considerato dal motore di ricerca è, come detto, un obiettivo raggiungile solo facendo pratica con l’analisi dei log, tuttavia ho pensato di mostrarvi un esempio pratico di analisi, non perché esso sia un esempio di applicazione di tutte le nozioni sopra espresse, ma perché può essere considerato un piccolo tassello di quanto si può osservare ravanando nei file di log del server.

Informazioni sul sito analizzato

Il sito da analizzare ospitava, tra le altre cose, contenuti classificati per zone geografiche (città) ed avevo un interesse a comprendere quali sezioni geografiche ricevevano maggiore attenzione da parte dello spider, sopratutto in funzione degli obiettivi di business dell’azienda, che desiderava puntare più su alcune specifiche zone.

Una prima perlustrazione con Xenu Link Sleuth aveva fatto emergere una criticità di “spazi infiniti”; il crawling del sito era stato interrotto una volta preso atto del problema ed è dunque nata la volontà di capire quanto il fenomeno stava interessando Googlebot e quanto il sito stava sprecando preziosa banda.

Obiettivi dell’analisi

I due obiettivi che mi sono dato sono stati quello di evidenziare eventuali anomalie nel crawling e quello di determinare quali sezioni del sito da analizzare ricevevano maggiore attenzione dagli spider.

Strumenti utilizzati

Nel corso del tempo ho modificato più volte il tipo di strumenti usati per l’analisi dei log.

A volte mi sono affidato a soluzioni software dedicate in modo specifico a questa attività, altre volte ho preferito adottare soluzioni più artigianali, sopratutto quando avevo bisogno di estrarre informazioni particolari.

In passato, per esempio, mi sono affidato a Deep Log Analyzer per creare dei report custom basati su query SQL, senonché il software diventava molto lento nel momento in cui c’era da analizzare una quantità di log corposa.

Più recentemente, ho scoperto un piccolo e semplice software per filtrare velocemente i log e per dare loro delle veloci occhiate, si chiama Apache Logs Viewer (ma gestisce anche i log dei web server Microsoft).

Nel caso dell’analisi che vi sto per illustrare mi sono tuttavia affidato a semplici metodologie custom basate su grep (e l’inusabile ma potente PowerGrep) ed Excel. Sono ricorso anche all’aiuto saltuario di UltraEdit per visualizzare i dati grezzi.

Approccio seguito

E’ stato preso in considerazione un periodo temporale di sette giorni, distante da campagne di marketing svolte dall’azienda proprietaria del sito e giudicati sufficienti per estrarre un comportamento abituale di Googlebot.

Dai file di log sono state estratte le sole righe relative a Googlebot, circa ventiduemila, che sono state modificate con PowerGrep attraverso una regex per separare con TAB i vari campi di cui la riga di log si componeva e successivamente importate in Excel.

Su Excel è stata aggiunta una colonna destinata ad ospitare il nome della directory che conteneva la risorsa richiesta dallo spider e successivamente è stato creato un semplice grafico pivot che mettesse in risalto le directory più oggetto delle perlustrazioni dello spider.

Nello screenshot che segue potete vedere il grafico a torta che mette in evidenza le proporzioni tra le varie directory. I nomi reali delle directory sono stati cambiati per proteggere gli innocenti, ho lasciato reali solo i nomi delle regioni, giusto per amor patrio.

Osservazioni

Come si può notare, oltre un quarto delle richieste di Googlebot sono dedicate alla cartella che ospita la risorsa che genera gli “spazi infiniti”, nella fattispecie si trattava di un widget “calendario” che induceva lo spider a richiedere seguire link che puntavano ad anni futuri, fino a generare pagine riferite all’anno 2041.

L’aspetto interessante di questo comportamento di Googlebot è che le risorse in questione consistevano in pagine vuote, bianche come la neve e che includevano giusto quei link che spingevano lo spider ad andare sempre più in profondità.

Questo appena descritto è un tipico esempio di crawling non associabile alla distribuzione del PageRank. Oltre certi livelli di profondità, la quantità di PageRank associata alle risorse è quasi zero e non sufficiente a giustificare un ulteriore interessamento da parte dello spider a proseguire oltre.

Il fatto che i contenuti trovati ad ogni nuovo approfondimento fossero nulli fa anche pensare che l’obiettivo dello spider di individuare una quantità maggiore di risorse fosse talmente prioritario da non tener conto della qualità dei contenuti già trovati.

E’ questa osservazione sufficiente a far concludere che Googlebot non tiene conto della qualità delle risorse per decidere se andare a fondo o meno?

No. Come detto, infatti, esistono delle attività speciali dello spider che prevedono che esso vada più a fondo possibile, senza tener conto di qualità o importanza. Ma va sempre ricordato che la normale attività di crawling tiene sempre conto del PageRank delle risorse e quindi non ci si deve attendere per le normali risorse del sito lo stesso trattamento ingordo che viene concesso a quelle risorse superprofonde oggetto di crawling particolari.

In altre parole, lo spider è unico ma i task che gli vengono assegnati possono essere molteplici, ed uno di questi prevede di andare a fondo ad ogni costo al presentarsi di particolari scenari, come un FORM da “compilare” o un calendario da sfogliare (e qui vengono in mente audaci paralleli con camionisti e ragazze svestite che non farò per pudore e tatto).

Preso atto che oltre un quarto delle richieste riguardava interrogazioni a risorse inutili, va da sé che una correzione di questo problema potrà garantire un po’ di banda in più da sfruttare per lo scaricamento di risorse più strategiche.

Un’altra osservazione che emerge dal grafico è che la directory “carpentieri” è piuttosto snobbata dallo spider, pur rappresentando una tipologia di risorse sulle quali il cliente desiderava puntare. Sarà dunque necessario comprendere perché questo avviene e se è il caso di invitare in qualche modo lo spider a prestare maggiore attenzione a quela sezione, per esempio lavorando sui contenuti di quelle pagine oppure sul linking interno. Anche la directory “negozi” è messa piuttosto male e meriterebbe più attenzione.

Un’ulteriore osservazione è relativa all’attenzione concessa da Googlebot alle zone geografiche: sembra che lo spider sia più interessato a quelle città che vedono una maggiore presenza di UGC (user generated contents) sulle relative risorse. Questa informazione è interessante, vale la pena di prendere un appunto e di fare delle comparazioni tra le città di cui lo spider è più ingordo, quelle per le quali riceve più traffico organico e quelle sulle quali il cliente vuole effettivamente puntare di più. Chissà che non emergano considerazioni e nuove idee su come valorizzare le città più strategiche agli occhi degli utenti e del motore di ricerca…

Il resto delle sezioni del sito, a cominciare da “sarchiaponi” e “minolli” è abbastanza compatibile con quella quantità di attenzione che il sottoscritto ritiene giusto associare ai vari contenuti, pertanto l’analisi serve anche a capire quali cose filano per il verso giusto.

Mettere le cose in prospettiva

Occhio: l’analisi dell’attenzione degli spider non serve a nulla se non tiene in considerazione anche gli altri, importantissimi, elementi che ho più volte accennato lungo l’articolo: la qualità del traffico che arriva dai motori, gli obiettivi dell’azienda e la visibilità nei risultati delle ricerche.

Fate dunque bene attenzione ad incastonare le analisi del comportamento di Googlebot in quel puzzle più grande che è il rapporto tra sito e motore, di cui i log possono essere solo un parziale indicatore.

Conclusioni

Volevo anche aggiungere una nota sui dati che possono essere estratti da Google Wemaster Tools, in particolare quelli relativi alle risorse indicizzate ed esplicitamente “snobbate” dal motore di ricerca. Nel momento in cui scrivo questo articolo (gennaio 2013) GWT specifica quante risorse vengono ignorate, ovvero la quantità di risorse “not selected”, ma non quali.

Quindi magari dare ogni tanto un’occhiata ai log del server e alla robaccia che fate scaricare allo spider può essere un buon modo per capire la causa dei picchi della famigerata linea delle risorse che il motore preferisce ignorare. Evitare gli sprechi porta sempre benefici.

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

Molti anni fa su un gruppo di discussione su Internet lessi un informatico che stava cercando di progettare un nuovo algoritmo di ricerca di pattern nei testi. Un secondo informatico gli chiese: “Esistono già molti buoni algoritmi di ricerca. Perché reinventare la ruota?” ed il primo rispose: “Perché a me serve un razzo.“.

A distanza di tanti anni ricordo ancora distintamente quella discussione perché in poche parole riusciva a dipingere uno scenario piuttosto comune tra quelle comunità che dovrebbero investire parte del proprio tempo in ricerca e sviluppo e che invece preferiscono adagiarsi alla comodità di quanto già esiste, persino quando non opportuno o non conveniente.

L’espressione “reinventare la ruota” è stata sempre sfruttata per evidenziare esclusivamente l’apparente perdita di tempo (e denaro) nel cercare di ottenere qualcosa che esiste già.

Se da un lato questo tentativo di dissuasione appare figlio del buonsenso e del tutto giustificato, dall’altro però è necessario precisare che il tempo speso nel reinventare una ruota va considerato un investimento azzardato esclusivamente quando si tenta di ottenere esattamente la stessa ruota.

Dunque mi chiedo: che effetti negativi possono scaturire da questi tentativi di dissuazione se poi bloccano sul nascere anche quei percorsi di ricerca che potrebbero far emergere soluzioni migliori a problemi apparentemente già risolti in via definitiva?

Avete mai avuto l’impressione che l’ambiente attorno a voi preveda che la ruota debba girare in un preciso modo ma che nessuno sappia esattamente il perché?

Questo articolo è dedicato alle ruote che nessuno vuole reinventare e a quelle dentate degli ingranaggi industriali, tra le quali si rimane incastrati quando si decide di seguire ciecamente i binari tracciati da altri. Compresi i binari della SEO.

Playing safe

Nel cercare sempre la terra sotto i piedi, è inevitabile che gli esseri umani si aggrappino a tutte le certezze possedute. Si tratta di un comportamento che in genere è istintivo e positivo, perché appoggiarsi alle certezze è uno dei tanti modi di ridurre i rischi e di aumentare quindi le probabilità di successo.

Il diavolo, tuttavia, sta nei dettagli. Se è giusto appoggiarsi ad una certezza forse non è altrettanto salutare (hi there!) nel lungo termine adagiarsi ad esse in senso generale.

Non è raro osservare contesti nei quali persone in grado di portare innovazione sono relegate a ruoli meramente esecutivi e gli adepti del “playing safe” vengono invece assegnati a ruoli di gestione, dove le responsabilità sono maggiori e serve qualcuno che sia in grado di applicare e far applicare processi definiti.

La ragione per la quale in pochi tentano di reinventare la ruota in contesti lavorativi, dunque, è legata sia alla nostra predisposizione psicologica a muoverci per strade che conosciamo bene sia alla riduzione del rischio che se ne ottiene se tale approccio viene applicato alle attività lavorative.

Fin qui tutto bene, perché reinventare la ruota non è un processo intrinsecamente positivo o negativo. Il problema nasce quando il rifiuto a reinventare la ruota è conseguenza di una cultura che a priori teme il cambiamento o non accetta il rischio.

Riprenderò il discorso del contesto di lavoro successivamente, intanto vi racconto un aneddoto per mostrare uno dei vantaggi che si ottengono reinventando la ruota.

Cornuto e mazziato

In passato ho lavorato per alcuni anni in Sems, l’agenzia di search marketing fondata e diretta per anni da Marco Loguercio, al quale non ho mai raccontato l’episodio che segue. Alcune delle attività che portavo avanti riguardavano lo sviluppo di tool utili alla SEO.

Poco prima di andar via dall’azienda, mi son trovato nella condizione di dover fare una scelta critica: ero molto combattuto se copiare i sorgenti dei tool che avevo sviluppato per l’azienda o se ripartire da zero per crearne di nuovi, a beneficio dell’attività di consulente che avrei iniziato da lì a poco.

Da un lato la maggior parte del tempo investito nello sviluppo di quei tool era stato tempo personale, avendoli programmati spesso a casa in orari non lavorativi. E quindi, porca pagnotta, li sentivo “miei”. Dall’altro (tranne una rara eccezione) sono sempre stato una sorta di “soldato” nei confronti dell’azienda e quindi c’era una parte di me che avrebbe percepito il gesto come scorretto.

Non ricordo perché non chiesi semplicemente all’azienda se potevo prenderli… sta di fatto che indossai gli occhiali scuri, presi una chiavetta USB criptata e protetta da password, vi copiai i sorgenti, li portai via con me e vinsi il premio italiano 2009 per la creazione di nuove aberranti imprecazioni nell’infruttuoso tentativo di ricordare la password. Niente da fare. Formattazione. Pirla. Amen.

Spero che il riferimento a “cornuto e mazziato” sia adesso chiaro: inzozzare un minimo la coscienza era il prezzo da pagare per risparmiare un tedioso lavoro di rifacimento, invece commisi tutte le azioni necessarie a definirmi un delinquente patentato ed in cambio non ne ottenni un fico secco.

Non so se voi vedete in tutto ciò una profonda lezione morale, ma io ce l’ho vista: non criptate mai niente se avete una memoria di merda.

Che c’è di buono in questa storia? C’è che se l’occasione fa l’uomo ladro, la necessità fa l’uomo bravo. Fui costretto a riprogrammare da zero tutti i tool di cui sentivo la necessità e nel farlo vennero fuori molto più fighi ed utili di quelli sviluppati in passato.

Anche se l’aneddoto illustra una condizione forzata a dover reinventare la ruota, penso che il messaggio di fondo rimanga valido: reinventare la ruota è sempre un’opportunità che apre la strada a migliorie, ottimizzazioni, nuove scoperte, soddisfazioni e a soluzioni che si adattano meglio a nuovi scenari e condizioni.

Alla fine del processo la ruota inventata è diversa da quella che intendevamo reinventare ma per certo non avremmo prodotto nulla di nuovo e di migliore se avessimo rifiutato a monte l’idea di dover rifare qualcosa che apparentemente esisteva già.

Gli ingranaggi industriali della SEO

L’aspetto delle ruote da reinventare che più mi sta a cuore è quello legato alla loro apparente incompatibilità con l’industrializzazione delle attività SEO. E ho scritto apparente perché ritengo che l’incompatibilità sia solo tale.

Capita a volte che certi processi, ben definiti ed eseguiti con precisione quasi automatica dai dipendenti di un’azienda, sfocino in rigidità che possono alimentare fenomeni di stagnazione mentale e professionale.

Le aziende nelle quali si arriva ad instaurare questa condizione sono “accidentalmente” anche quelle nelle quali risulta più difficile sia la proposizione di nuovi approcci sia, come conseguenza, l’introduzione di migliorie ai processi stessi.

Introdurrò di seguito velocemente una semplice classificazione dei servizi SEO in Italia e poi tornerò a bomba a discutere dei processi aziendali.

Uno sguardo al mercato

Da quello che osservo, il mercato SEO italiano è estremamente eterogeneo. Una possibile divisione dei servizi di search marketing in due grandi classi potrebbe essere quella della vendita della SEO come prodotto e quella della vendita di servizi consulenziali di search marketing. Sono due estremi tra i quali esiste una moltitudine di approcci ibridi.

Mi piace illustrare questa divisione mettendola in relazione ad un’altra caratteristica, ovvero la tipologia del cliente. Nel grafico che segue ho dedicato una dimensione a quanto il cliente ne capisce di search marketing ed una dimensione a quanto l’approccio del venditore è di tipo consulenziale.

Ne son venute fuori quattro principali sezioni di cui esplicito il significato:

Sezione A: clienti evoluti gestiti prevalentemente da agenzie di search marketing che hanno adottato un modello in buona parte industriale. Le agenzie del settore A sono riuscite ad industrializzare la SEO attravero servizi preconfezionati per soddisfare la richiesta di aziende che vedono nella search un canale strategico per il proprio business e che solitamente investono da tempo in questo settore.

Sezione B: clienti evoluti gestiti da consulenti, sia freelance sia organizzati in agenzie. Questa tipologia di cliente è solitamente predisposta ad internalizzare la definizione di strategie di search marketing e di attività SEO e cerca all’esterno non tanto un “fornitore” a cui demandare attività quanto una guida che li aiuti a migliorare le proprie prestazioni.

Sezione C: clienti con poche conoscenze o interessi nel search marketing gestiti da agenzie che applicano alla SEO modelli industriali. A questo settore appartengono sia quelle agenzie di search marketing che puntano alla massa di piccole imprese a cui proporre servizi SEO molto semplici (si legga: posizionamento come si faceva anni fa) sia quelle agenzie di marketing che si ritrovano clienti per i quali il canale dei risultati naturali non è particolarmente strategico e ai quali possono essere proposti attività SEO molti semplici (si legga: posizionamento come si faceva anni fa).

Sezione D: clienti con poche conoscenze di search marketing gestiti da agenzie o freelance con un forte approccio consulenziale. Si tratta di quella fascia di clientela che ritiene indispensabile internalizzare in futuro il know-how e le attività SEO. Un esempio tipico di questa tipologia di aziende sono quelle in fase di startup, a volte necessitano di una consulenza di search marketing già in fase di progettazione del business plan. Le aziende di questa sezione sono destinate a muoversi verso il settore B, via via che acquisiranno competenze.

Torniamo adesso alle due grandi classi industriale e consulenziale, nel grafico collocate rispettivamente nella metà sinistra e nella metà destra.

Prendendo assolutamente con le pinze le mie impressioni, direi che la prima classe di servizi (sezioni A e C del grafico) è probabilmente quella che in Italia genera la fetta di fatturato maggiore. Si tratta della SEO venduta ancora un tot al chilo e per mezzo di pacchetti di attività preconfezionate, retaggio di un periodo in cui il concetto di “posizione per query” (ovvero il concetto di posizionamento) aveva ancora senso.

La seconda classe di servizi SEO è rappresentata da quelli che prevedono consulenze “custom”.

Non mi dilungherò su questo secondo tipo di approccio al search marketing, perché in questo post desidero proporre alcune reinvenzioni della ruota sopratutto a chi ha adottato un approccio più “vecchio stile” (sezioni A e C del grafico).

I processi aziendali

Per quello che ho osservato, la resistenza a reinventare la ruota nasce sopratutto perché il rapporto costi/benefici di una rivalutazione e revisione dei processi aziendali dedicati alla SEO viene spesso percepito troppo alto.

Le ruote però sono difficili da reinventare anche perché esistono spesso freni legati all’organizzazione del lavoro aziendale.

Per esempio, ecco di seguito alcune tipiche criticità nei processi di aziende che applicano in modo abbastanza rigido delle semplici procedure di ottimizzazione o posizionamento.

Alcuni dei seguenti problemi sono più caratteristici di aziende grandi e molto strutturate mentre altri sono comuni ad aziende di qualsiasi grandezza; tutti però rendono più difficile introdurre modifiche allo status quo:

• i processi SEO sono obsoleti (criticità che a sua volta è spesso conseguenza di problemi ben più seri, come una vision inesistente, un’indentità aziendale non ben definita o un posizionamento incerto sul mercato, ma qui mi fermo perché l’unico modo di approfondire le cause sarebbe attraverso la divagazione, che invece dribblo con astuzia volpina)
• i processi sono definiti ma non è stata formalizzata una procedura per la loro rivalutazione periodica: se qualcuno ha una buona idea non è chiaro se e come si possa proporla ad un decisore o testarne la validità o passare dalla teoria alla pratica
• i processi SEO vengono definiti da persone poco adatte al compito: va ricordato che prima che la SEO venisse baciata dalla dea del marketing, essa era relegata esclusivamente a contesti tecnici e ad attività più o meno automatizzabili, perché il target dell’attività era il motore da fregare e non l’utente del motore da accogliere. In molte aziende è ancora così e spesso la definizione dei processi SEO viene assegnata esclusivamente a persone che ricoprono ruoli tecnici, senza contributi da parte di coloro che ricoprono ruoli di gestione del marketing
• le modalità di rivalutazione di un processo sono formalizzate ma prevedono esclusivamente un approccio top-down, che detto in parole spicce significa che la ruota viene reinventata dai capoccia senza che alle decisioni contribuiscano le opinioni e le informazioni acquisibili da chi poi svolgerà effettivamente le attività
• la rivalutazione e revisione dei processi SEO spesso non è abbastanza agile da seguire la quantità smodata di novità del nostro settore

Leggendo la lista delle criticità si potrebbe erroneamente credere che esse siano riscontrabili solo in aziende con molti dipendenti, dove la presenza di diversi livelli gerarchici e di organigrammi complessi renda difficile ogni aggiornamento ed evoluzione dei processi.

In realtà io ho riscontrato i problemi sopra elencati anche in aziende relativamente piccole, nelle quali le resistenze a reinventare le ruote non erano da imputare ad organizzazioni complesse bensì a rigidità mentali di specifici dipendenti con ruoli di gestione o a rigidità del management.

Questa condizione generalizzata mi fa sperare che le proposte di ruote reinventate che farò nella seconda parte di questo articolo possano essere ritenute interessanti da aziende di qualsiasi grandezza.

Le conseguenze

La trattazione di questi ingranaggi aziendali non sarebbe completa se non elencassi almeno alcuni degli effetti collaterali negativi che sono tipici dei contesti in cui le attività SEO vengono fortemente industrializzate, seguendo processi particolarmente rigidi e difficili da modificare.

Gli effetti collaterali che più mi stanno a cuore sono quelli sulla sanità mentale dei dipendenti e quindi mi focalizzerò su questi ultimi.

Catena di montaggio

La percezione che si venga utilizzati come meri esecutori di attività ripetitive, sempre uguali, ponendo la correttezza di esecuzione del processo prima di ogni altra cosa, è probabilmente una delle principali cause di frustrazione del dipendente.

Il fenomeno si aggrava nel caso in cui il dipendente è dotato di intelligenza propria, magari associata ad una forte curiosità e passione per una professione, la SEO, che dal proprio punto di vista percepisce come creativa.

Disallenamento

Non c’è miglior modo di stancare e atrofizzare un cervello che fargli eseguire attività scimmiesche con periodicità fissa.

Visto che nella stragrande maggioranza dei casi le persone soggette alle attività scimmiesche sono le stesse che poi svolgono analisi e valutazioni SEO che richiedono intuizione, attenzione, capacità di critica e a volte una predisposizione a pensare “out of the box”, se ne deduce che la forzata coabitazione di Mr Hyde e Dr Jekyll rischia di influire negativamente sulle attività che richiedono più presenza mentale.

Confusione

A volte la rigidità di esecuzione è talmente alta che alcuni dipendenti iniziano ad avere la percezione che nessuno sappia perché le cose vadano fatte esclusivamente in uno specifico modo, apparentemente illogico o non ottimale. Questa sensazione è frustrante in particolar modo per chi è abituato a chiedersi il perché di tante cose.

E a questo proposito ho una storia da raccontare.

La lezione delle scimmie

La storiella che vi racconto è tratta da un reale esperimento e studio scientifico svolto nel 1966 (Cultural Acquisition of a Specific Learned Response Among Rhesus Monkeys) e illustrato con disegni accattivanti su questo blog.

In una gabbia sono state messe cinque scimmie ed una scala con in cima una banana.

Ogni volta che una scimmia tentava di salire la scala per prendere la banana, le altre quattro venivano innaffiate con acqua gelida.

Dopo un po’, se una scimmia osava tentare la scalata, veniva subito fermata e picchiata dalle altre, che temevano la doccia fredda. Si arrivò al punto che nessuna delle scimmie osò più avventurarsi su per la scala.

Fate attenzione: da questo momento in poi, le docce fredde non vengono più somministrate.

A questo punto una delle cinque scimmie viene sostituita e la prima cosa che questa nuova scimmia fa è tentare di prendere la banana. Come prevedibile, le altre quattro scimmie glielo impediscono picchiandola e dopo un po’ di episodi simili la nuova scimmia capisce che è vietato salire la scala, anche se non ha idea del perché.

Una seconda scimmia del gruppo originario viene sostituita e anch’essa tenta di salire la scala, venendo subito picchiata dalle altre quattro, compresa la scimmia che aveva imparato il divieto pur ignorandone il motivo.

Avvengono altre sostituzioni ed ogni volta la nuova scimmia introdotta nel gruppo impara dalle altre il divieto di non salire la scala.

Dopo un totale di cinque sostituzioni non ci sono più scimmie del gruppo originario e rimane dunque un gruppo di cinque nuove scimmie che picchiano chiunque osi avventurarsi sulla scala, anche se nessuno sa più il perché.

Se fosse stato possibile chiedere alle scimmie perché picchiavano chiunque tentasse di prendere la banana, forse la risposta che avrebbero dato sarebbe stata qualcosa del tipo: “Non lo so, ma da queste parti le cose funzionano così.”

La storiella è finita ma la ricollego subito alle ruote da reinventare evidenziando che a volte i processi aziendali hanno vita più lunga dei dipendenti che li hanno definiti e può succedere che dei dipendenti decidano di andare via dall’azienda lasciandole in eredità delle procedure definite ma non motivate.

Se qualche volta vi è capitato di chiedervi perché è stato deciso che un’attività debba essere svolta in un modo ben preciso, esiste una probabilità maggiore di zero che la motivazione completa sia sconosciuta persino a chi ha la responsabilità di controllare che il processo venga applicato alla lettera.

La seconda osservazione che mi sento di fare riguarda il comportamento delle scimmie: pare proprio che nessuna di esse abbia trovato opportuno reinventare una ruota (in questo caso una regola sociale) condivisa e funzionante.

Certo, la regola rendeva impossibile a chiunque mangiare la banana e forse sarebbe bastato ridiscutere la regola per scoprire che il pericolo della doccia fredda non esisteva più, tuttavia mi sento di giustificarle perché son scimmie e possiedono un sistema di comunicazione meno sofisticato del nostro.

Dall’homo sapiens invece è giusto aspettarsi uno scrupolo a contribuire al sistema di regole che governa la propria comunità/società.

Reinventare la SEO?

Storicamente, la SEO si è dimostrata la disciplina più incline ad accettare continue modifiche e migliorie, una reinvenzione ininterrotta guidata prevalentemente dalle evoluzioni dei motori di ricerca.

Una curiosa caratteristica degli operatori del settore abbarbicati a tecniche e prodotti SEO antidiluviani è che si decidono a cambiare le proprie metodologie solo in due casi: 1) sotto ricatto quando gli rapiscono la mamma o 2) quando sono costretti da devastanti aggiornamenti di Google che mettono a rischio lo stipendio.

Nella storia del search marketing questa condizione di costrizione è stata imposta da Google principalmente in tre periodi storici: nel 2003 con l’update Florida, a partire dal 2011 con gli update Panda e sopratutto a partire dal 2012 con gli update Penguin. Florida fu un’apocalisse ma anche Penguin non scherza.

Ovviamente Google ha regalato smottamenti tellurici nelle proprie SERP in modo costante e frequente anche in tutti gli altri anni, ma i tre eventi sopra indicati sono stati quelli che hanno creato criticità concrete a chi la SEO la fa di professione.

Riconoscere questi momenti storici è semplice: c’è un picco di richieste fatte ai consulenti da parte di aziende (comprese le agenzie di search marketing) che vogliono rivedere le proprie metodologie SEO.

Prendendo energie dal momento fibrillante e storico che la SEO sta attraversando, ho deciso di fornire di seguito alcune semplici proposte per reinventare qualche ruota.

Purtroppo non è possibile fornire consigli generici sui processi SEO aziendali, perché è un’attività nella quale la cura cambia da paziente a paziente, però è possibile fare qualche esempio pratico su come alcune classiche attività SEO possano essere riviste negli obiettivi, nelle procedure e nella comunicazione nei confronti del cliente.

Io lo faccio senza pretese, voi dategli un’occhiata. Magari si tratta di idee che state già applicando, magari nel vostro caso non sono applicabili e magari invece possono esservi di spunto per il lavoro.

Al rogo i listoni

Per semplificare le cose, ho deciso di focalizzarmi su una caratteristica comune a diverse attività SEO e di proporvi di reinventare le ruote associate ai processi che producono come output dei SEO-listoni.

Che cosa sono i SEO-listoni? Sono tutti quei prodotti di attività SEO che constano di lunghe liste di elementi: URL, keyphrases, valori numerici, backlink, posizioni in SERP… chi più ne ha più ne metta.

La reale criticità di questo materiale è che solitamente viene fornito al cliente come principale output di un processo, col risultato che il cliente riceve:

• troppe informazioni, più di quante gliene servano. Esistono degli intrinseci limiti cognitivi che rendono controproducente subissare una persona con lunghe liste di elementi.
• uno strumento inusabile. La quantità di informazioni e il formato ad elenco col quale vengono erogate rendono spesso poco usabile l’output, che potrebbe invece essere organizzato in strutture più funzionali allo sfruttamento dei dati.
• un prodotto esteticamente sgradevole. Non vanno mai sottovalutati gli effetti che una valutazione estetica negativa ha sulla più generica ed importante valutazione qualitativa di quanto si ha di fronte.
• (importante) una forte indicazione che l’approccio dell’agenzia/consulente è quantitativo prima ancora che qualitativo.

Per riassumere, i SEO-listoni non danno evidenza del lavoro che è stato svolto per ottenere i dati, non danno visibilità al processo di organizzazione delle informazioni, non rendono esplicito che l’agenzia/consulente oltre ad inviare l’output al cliente si è fatta scrupolo di valutare i risultati e non mettono in risalto le conclusioni tratte dalla suddetta valutazione.

Tra l’altro, più i SEO-listoni sono lunghi e più nel cliente si insinuerà la convinzione che sono stati ottenuti con palesi automatismi. Siccome non sempre questa congettura è vera ed alcuni lunghi output sono invece frutto di attività in parte manuali, è a maggior ragione opportuno mettere in evidenza tutti gli sforzi che sono stati fatti per svolgere scrupolosamente un’attività.

In altre parole, i SEO-listoni sono pessimi strumenti per comunicare col cliente.

La ruota dell’analisi dei backlink

In epoca Penguin, un’attività che è diventata protagonista delle tattiche SEO è stata quella della bonifica dei backlink. Le aziende più lungimiranti hanno iniziato a mettersi in riga ben prima che Penguin nascesse, la stragrande maggioranza si è invece mossa a penalizzazione inferta.

Nel caso in cui un cliente sia “in odore di spam”, potrebbe essere una buona idea mostrarsi proattivi e proporgli un’analisi ragionata dei propri backlink, organizzata in modo da poter quantificare facilmente eventuali rischi e prendere decisioni su eventuali contromisure.

Siccome mi è capitato di svolgere attività simili, vi condivido un output di quello che si può ottenere analizzando le interconnessioni di alcuni siti web attraverso il preziosissimo strumento Clique Hunter di Majestic SEO e dando visibilità alle informazioni importanti con Gephi, uno dei più utilizzati software per il design di grafi.

Il grafo mostra in che modo i siti del cliente (i quattro nodi arancio più grossi) ricevono link da un network di siti spammosi di bassa qualità (colore nero) e da altri siti di qualità accettabile (nodi arancio più piccoli).

La caratteristica più utile è che le frecce che uniscono i siti sono state colorate in base al colore del nodo linkante. In questo modo è stato possibile quantificare in una sola schermata l’entità del linking proveniente dal network di spam, facilitando le decisioni su come gestire la situazione.

Il vero e proprio processo di analisi di un network di siti, tuttavia, non ha come output il grafico di cui sopra, perché il reale vantaggio di un software come Gephi è quello di poter modificare al volo alcuni parametri ed osservarne in tempo reale il risultato.

Nel caso in oggetto, per esempio, durante la fase di analisi interattiva i colori dei link sono stati cambiati in funzione del sito linkato (mettendo quindi in evidenza quali siti linkavano il network spammoso) e attraverso un semplice calcolo è anche possibile mettere in evidenza i link reciproci o, se si possiedono tutti i dati necessari, persino in che modo il PageRank viene distribuito tra i siti.

Al termine di una valutazione svolta con Gephi, se i punti salienti raccolti sono pochi, possono probabilmente essere forniti al cliente sotto forma di un paio di grafici. Tuttavia in caso di maggiori evidenze e spunti emersi dall’analisi, la stessa verrebbe in parte vanificata se non si cogliesse l’occasione per mostrare di persona (o via Skype) al cliente, Gephi alla mano, le valutazioni che sono state svolte e per spiegargli quali osservazioni hanno motivato i suggerimenti e linee guida SEO che il consulente ha fornito a seguito dell’analisi.

E il SEO-listone di backlink? Lo si butta via? No, sarà probabilmente necessario al cliente nel caso in cui il consulente abbia consigliato un’attività di bonifica dei propri backlink, ma va trattato e presentato come un documento di supporto ad un’attività, non come l’output principale dell’analisi che è stata svolta.

La ruota delle richieste di grazia

Visto che parliamo di SEO-listoni di backlink vale la pena dare un’occhiata anche agli ingranaggi delle richieste di grazia fatte al vescovo a seguito della ricezione di una scomunica per backlink spammosi.

Nel campo delle richieste di riconsiderazione a Google ne viste di tutte i colori:

• Proprietari di siti che peroravano animatamente la propria causa attraverso estenuanti oratorie sulla rettitudine dell’azienda e la sua morale immacolata
• Paraculi che asserivano con voce impastata e sbavature zuccherine di essere del tutto estranei al concetto di “marmellata rubata”
• Persone che realmente non capivano dove avevano sbagliato e che chiedevano inutilmente maggiori dettagli al team antispam
• Politicanti che pretendevano di spiegare (loro a Google, eh?) che cosa fosse spam e che cosa non lo fosse (loro a Google, eh?)
• Gli immancabili speditori di sterili SEO-listoni, quando era il caso di indicare quali URL contenevano backlink spammosi che non si riusciva a rimuovere, attività che veniva già svolta ben prima dell’introduzione del famigerato Link Disavow Tool.

Alcuni di voi potrebbero obiettare che i SEO-listoni di questo ultimo genere non dovrebbero essere annoverati tra le attività consulenziali di un operatore del campo del search marketing, in quanto Google non è un cliente. Io dissento: in questo caso Google è un cliente come qualsiasi altro, essendo un soggetto al quale si desidera vendere qualcosa. Nel caso specifico, si intende vendergli la validità di una tesi da sostenere o la genuinità di una redenzione avvenuta. In qualsiasi modo la vogliate vedere, Google è un soggetto al quale comunicare correttamente qualcosa e anche in questo contesto i SEO-listoni possono fare danni.

(alcuni SEO non percepiscono Google come uno stakeholder, cosa che a tutti gli effetti ovviamente è. Forse prima o poi ci scriverò un articolo sopra)

Una nota storica per farvi capire che nonostante l’introduzione del link disavow tool non è cambiato in realtà molto: la necessità di inviare a Google elenchi di backlink di bassa qualità che non si riuscivano a rimuovere è sempre esistita. Chi doveva farlo si limitava ad inviare una normale richiesta di riconsiderazione al team antispam, all’interno della quale spiegava nel dettaglio la situazione e indicava quali backlink non era possibile eliminare dal web, chiedendo dunque a Google che venissero ignorati.

Successivamente è stato creato il Link Disavow Tool, il cui nome è perlomeno fuorviante visto che non si tratta affatto di un “tool”, ovvero di uno strumento che in qualche modo automatizza l’attività di disconoscimento dei backlink, bensì di una procedura per comunicare in modo più ordinato al team antispam quali backlink sono indesiderati.

Non si pensi dunque che l’introduzione di questa procedura comporti un iter molto diverso da quello che prima veniva eseguito manualmente attraverso le normali richieste di riconsiderazione: sempre attraverso la valutazione del team antispam si deve passare. Pertanto anche se leggete “tool” è necessario approcciare il problema come una richiesta da spiegare e motivare agli esseri umani che leggeranno l’elenco dei backlink inviati. In altre parole, si tratta sempre di una causa da perorare davanti ad un giudice, non un comando che viene inviato al motore di ricerca.

Come approcciare dunque la comunicazione con Google nel migliore dei modi? Potrebbe forse farvi comodo un template di messaggio di provata efficacia da inviare a Google quando bisogna effettuare una riconsiderazione per backlink spammosi?

Ebbene, miei stimati lettori traspiranti essenza di mughetto e scevri da ogni debolezza umana, se il globo terracqueo fosse popolato esclusivamente da esseri illuminati ed evoluti come voi potrei anche pubblicare un template di messaggio con la raccomandazione di modificarlo approfonditamente e scrupolosamente, in modo da far percepire a Google un genuino e personale scrupolo a tornare sulla retta via…

…tuttavia, come già spiegato, siccome la fauna del pianeta SEO annovera anche specie filosoficamente inclini ad industrializzare ogni santissimo processo nonché un affollato sottobosco di esseri che si nutrono di “trucchi” e “formule magiche”, esiste l’effettivo rischio che un template si diffonda e passi di mano in mano per finire usato come una circolare da inviare in ciclostile a Google ad ogni necessità, vanificando il messaggio principale di queste mie proposte di reinvenzione delle ruote, ovvero: personalizzate e valorizzate la comunicazione.

Pertanto mi limiterò ad indicare gli obiettivi dell’attività e a consigliare una traccia generica, lasciando a voi il compito di scrivere di volta in volta il testo più opportuno.

Contesto: è arrivato un avviso da Google che avverte della presenza di backlink spammosi e comunica una penalizzazione. I proprietari del sito sono consapevoli di aver svolto attività di link building con l’obiettivo di gonfiare il PageRank del sito o di tematizzarlo per alcune query di ricerca e, comprendendo di dover svolgere un’attività di bonifica, sono in grado di (far) eliminare parte dei backlink ma non tutti.

Cosa significa: Google conosce già parte dei backlink spammosi e in teoria avrebbe potuto limitarsi ad ignorarli, come alcune volte di fatto avviene. La penalizzazione ed il relativo avviso sono invece il risultato di una ragionevole certezza che i gestori del sito abbiano svolto attività che sono andate ben oltre la sporadica produzione di pochi backlink con ancore ottimizzate. L’interesse di Google non è più quello di svalutare degli specifici backlink per impedire loro di influenzare le SERP ma è quello di penalizzare un soggetto incline ad utilizzare metodologie spammose.

Obiettivi: 1) cambiare filosofia di link building e abbandonare per sempre ogni attività di spam 2) bonificare lo scenario accennato nell’avviso di Google e 3) dare evidenza al team antispam di aver cambiato definitivamente rotta.

L’obiettivo di cui al punto 1 è quello che Google desidera osservare per poter concedere la riabilitazione del soggetto. Ancora, pongo volutamente l’evidenza sul fatto che dietro l’apparenza di una semplice notifica di backlink spammosi si cela in realtà un interesse di Google a chiarire la posizione e l’attitudine del soggetto che gestisce il sito. Non tentate di fare i furbi, perché Google potrebbe decidere di non concedere al sito una seconda chance.

L’obiettivo di cui al punto 2 si raggiunge facendo un’attenta, approfondita e dettagliata valutazione di tutti i backlink del sito, che vanno classificati in funzione di due principali criteri: qualità e possibilità di eliminarli o di farli eliminare.

Posto che si usi strumenti quali Excel (o simili) per organizzare i lavori, dovreste aggiungere per ciascun link anche una nota sul tipo di attività di link building che è stata svolta per produrlo (es: article marketing, comment spamming, directory submission, ecc.) ed una nota che indichi lo stato dell’eventuale attività di rimozione del link (es: rimozione ottenuta, rimozione richiesta, rimozione rifiutata, nessuna risposta ricevuta, ecc.).

Tutti i backlink frutto di dubbie attività devono essere possibilmente rimossi. Se volete approcciare la bonifica da kamikaze, potete approfittare dell’occasione per eliminare anche alcune tipologie di backlink di bassa qualità, anche se non siete stati responsabili della loro creazione.

Qualunque decisione prenderete, siate consapevoli che nella stragrande maggioranza dei casi le rimozioni influiscono negativamente sulla visibilità del sito. Questo effetto non è evitabile ed è possibile solo lavorare in futuro affinché la visibilità migliori a seguito di nuove attività di sviluppo della web popularity compatibili con le linee guida di Google.

L’obiettivo di cui al punto 3 va perseguito in modo leggermente diverso a seconda dei risultati dell’analisi dei backlink e della loro bonifica.

Se è stato possibile rimuovere la quasi totalità dei backlink spammosi e quelli residui rappresentano solo “pochissime briciole” di bassa qualità che non contribuivano molto a spingere il sito sulle SERP e presumibilmente venivano già ignorati dal motore di ricerca, il mio consiglio è semplicemente quello di inviare una normale richiesta di riconsiderazione seguendo questa semplice traccia:

• Ringraziare per l’avviso ricevuto
• Dichiarare di avere analizzato approfonditamente tutte le decine/centinaia/migliaia di backlink individuabili
• Confermare trasparentemente che una parte erano frutto di attività di link building svolte dal proprietario del sito o da chi per lui, specificando il tipo di attività di link building svolte
• Affermare di aver compreso che le azioni compiute vanno contro le linee guida di Google
• Precisare che a seguito della penalizzazione è stato rivalutato il proprio approccio alla SEO e che sono state revisionate le proprie procedure interne affinché questo tipo di attività considerate spam non vengano mai più approcciate in futuro
• Indicare che a fine del messaggio è presente sia una lista dei backlink rimossi (o un campione, nel caso in cui siano troppi per includerli in un messaggio testuale il cui primo obiettivo è dare evidenza del cambio di rotta) sia una lista dei pochi backlink che non è stato possibile rimuovere nonostante i tentativi
• Chiedere quindi che la penalizzazione venga rimossa e ringraziare per il supporto

Se invece le attività di bonifica non hanno consentito di rimuovere una buona quantità (in termini assoluti o percentuali) di backlink spammosi, è opportuno usare il Link Disavow Tool. In tal caso:

• Redigete scrupolosamente l’elenco di backlink che non vi è stato possibile eliminare
• Producete il file da fornire al “tool” seguendo le indicazioni ufficiali pubblicate sul blog di Google e sulla pagina delle FAQ dedicata
• Non dimenticate di inserire nel file dei commenti per spiegare perché non è stato possibile eliminare ciascun backlink o ciascuna classe di backlink. Aiutatevi con le note che avete prodotto in fase di bonifica.
• Uploadate la lista di backlink “irrimovibili” attraverso il tool
• Attendete un paio di giorni e poi inviate anche una richiesta di riconsiderazione, seguendo lo stesso modello suggerito sopra ma con la differenza che invece di includere nel messaggio i link che non è stato possibile rimuovere dovrete evidenziare al team antispam che la loro lista completa è stata già inviata attraverso il Link Disavow Tool.

Fine. Se sarete riusciti a non farvi percepire come semplici uploader di SEO-listoni bensì come mortificati rei confessi che si sono dati un gran da fare per ripulire il proprio profilo di backlink e che mai più solcheranno i tempestosi mari caraibici dello spamming corsaro, allora le cose prenderanno una buona piega.

La ruota dei ranking report

Chiudo questo elenco di ruote da reinventare con quello che per antonomasia è considerato il SEO-listone per eccellenza, ovvero quelle orripilanti ed interminabili liste di keyphrase con associate una presunta posizione nella SERP in cui il sito del cliente appariva in un non precisato istante, effettuando la richiesta da un non precisato luogo.

Non è obiettivo di questo articolo rimarcare l’anacronisticità di tali SEO-listoni. Mi limito invece a fornire qualche indicazione di massima affinché si possa percepire dietro la loro produzione lo scrupolo di un essere umano nei confronti degli obiettivi del cliente invece che la potenza di una funzione “Esporta” di uno dei tanti software di controllo del ranking che esistono.

Come primo passo è necessario modificare gli obiettivi che stanno dietro la produzione dei report di ranking tradizionali.

In tutti i casi che ho osservato, il report viene prodotto per dare evidenza dei risultati delle attività di posizionamento previste dal contratto di fornitura che è stato stipulato col cliente. Si tratta quindi di un’istantanea scattata solitamente una volta al mese e motivata principalmente dal fatto che c’è un contratto che prevede di fornire periodicamente al cliente quella roba.

Ricorda un po’ lo scontrino che gli esercenti dei negozi consegnano alla clientela: un mero obbligo che non viene sfruttato per evidenziare il lavoro e lo scrupolo che sono stati profusi nei confronti del cliente.

Posto che effettivamente sussista il desiderio di rendere un report di ranking uno strumento più utile e significativo, la prima modifica che propongo è quella di effettuare i controlli di visibilità quando realmente servono e sono opportuni, non (principalmente) a scadenze prefissate da un contratto.

Con tutte le attività di ottimizzazione che vengono svolte per i clienti è normale che prima o poi vengano prodotti effetti sulla visibilità nelle SERP. Il monitoraggio della visibilità è inoltre utilissimo per prendere atto degli effetti (negativi o positivi che siano) conseguenti alcune attività SEO critiche, come una migrazione di un sito, la modifica di grandi quantità di URL, di contenuti o di link interni al sito stesso.

Ha pertanto molto più senso iniziare a considerare il monitoraggio della visibilità un’attività diagnostica dello stato di salute del sito.

Ha senso comparare la visibilità precedente e successiva ad una implementazione corposa, ha senso dare visibilità al cliente dei risultati conseguiti e di eventuali anomalie osservate, ha senso sfruttare i dati raccolti per motivare al cliente nuove attività di ottimizzazione, ha senso fargli percepire che esiste un processo che si prende cura dello stato di salute del sito anche durante quel mese di silenzio che solitamente passa tra un “report di contratto” e il successivo.

Modificato l’obiettivo, ecco adesso alcuni suggerimenti in più sui contenuti e la forma del report:

• Se potete mandare all’aria il concetto di posizione e sostituirlo con quello di posizione media, fatelo e strutturatevi per evangelizzare i clienti in tal senso e produrre report coerenti con questo nuovo modello.
• Prendete spunto dai colleghi del keyword advertising e prendete l’abitudine di classificare le query, per esempio apponendo dei tag legati al loro tema o classe di prodotto/servizio. Questo suggerimento è particolarmente importante per i siti che ospitano una varietà molto ampia di contenuti e argomenti. Fate conto che si tratti di un negozio ed iniziate a farvi scrupolo delle prestazioni di ciascun reparto nel corso del tempo. Se potete, calcolate e fornite un indice di visibilità per l’intero reparto invece che per le singole keyword, tecnica che tra le altre cose vi consentirà di accorgervi subito di eventuali penalizzazioni o “promozioni” relative a specifiche classi di query o di risorse.
• Indicate sempre quali risorse del sito appaiono nei risultati delle ricerche. Per alcune classi di query è importante che le risorse visibili siano quelle legate alla vendita, per altre classi di query è opportuno che appaiano in SERP delle risorse informative. Più in generale, è essenziale fare attenzione che la risorse preferite dal motore siano effettivamente quelle che presumibilmente gli utenti troverebbero più utili e attinenti (in base ad un’analisi del target e delle query utilizzate che in teoria avreste dovuto fare a monte).
• Siate elastici nelle modalità di erogazione dei report: se a seguito di un controllo periodico avete notato un fenomeno che richiede un interessamento vostro e del cliente in tempi brevi, lasciate perdere query e posizioni e inviate al cliente una normale mail nella quale trattate il fenomeno specifico. Il che ci porta anche all’ultimo consiglio per reinventare il SEO-listone di ranking…
• …ad ogni report inviato spiegate sopratutto al cliente che cosa è successo dal check precedente, quali sono le novità salienti che emergno dall’ultimo check, su quali elementi a vostro parere bisognerebbe lavorare, se vengono percepite criticità di qualsiasi natura e se ci sono opportunità che sono emerse sia dal check di visibilità sia dal corrispondente controllo della qualità del traffico che in teoria dovreste sempre accoppiare. Usate il formato che preferite, sia esso un breve documento PDF o una semplice mail o una presentazione, ma mettete sempre al centro della comunicazione questa vostra valutazione e non il SEO-listone.

Queste indicazioni e suggerimenti, frutto dell’analisi periodica o estemporanea della visibilità di un sito, costituiscono una delle principali ragioni per le quali un consulente viene pagato dal cliente. Se questo supporto viene sostituito da uno sterile SEO-listone prodotto da un software, equivale a rinunciare ad un’opportunità di crescita professionale ed economica.

Ovviamente, come già detto per altre ruote da reinventare, il SEO-listone con i dati dettagliati può comunque essere fornito, purché rimanga relegato ad un contesto secondario e si ponga in primo piano quel tipo di consulenza che solo un essere umano può produrre e fornire.

Altre ruote da reinventare

Esistono tantissime altre ruote che si potrebbero prendere in considerazione per reinventarle in toto o in parte.

Il primo esempio che mi viene in mente è il famigerato documento di analisi tecnica SEO, che solitamente consiste di SEO-listoni di criticità rilevate e di soluzioni da apportare. Ma trattare questo tipo di attività meriterebbe un articolo a sé.

Di SEO-listoni ne esistono molti altri, come l’output del crawling di un sito (che raramente ho visto fornire ad un cliente in forma aggregata) o gli utilissimo log del web server, che possono essere analizzati per individuare potenziali criticità e opportunità per una maggiore visibilità.

Ma qui mi fermo perché la triste realtà è che mi sono scocciato di scrivere così tanto.

Conclusioni

Sono consapevole di non aver realmente perorato la causa del search marketing più incline alla consulenza, perché fornendo solo esempi di modifiche di specifiche attività SEO non mi sono focalizzato sul vero aspetto aziendale che influisce e determina il modo in cui la SEO viene svolta: il modello di business dell’operatore del search marketing.

Ci sarà però modo di parlarne in futuro, sopratutto perché per passione rimango un attento osservatore di come il nostro settore è cambiato e sta cambiando sempre più.

Per il momento, visto che scrivo questo articolo in data 30 dicembre, mi limito ad archiviare questo anno 2012, che tanti grattacapi personali mi ha regalato ma che mi ha permesso anche di risolvere in via definitiva. E quindi auguro a tutti voi uno splendido nuovo anno, come sono certo che sarà anche per me.

Epilogo

Everything in this article may be wrong. (cit.)

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

La semantica è un argomento che periodicamente torna ad essere protagonista delle news dedicate ai motori di ricerca. Durante una decina di anni di osservazione e tenendo conto degli sviluppi concreti in questo ambito, la mia impressione è che il più delle volte la parola “semantica” venga usata prevalentemente come specchietto per le allodole.

Da un lato mi sorge il dubbio che per i motori di ricerca si tratti di una carta jolly da tirar fuori in periodi di magra e di penuria di significative evoluzioni della tecnologia.

Dall’altro noto che molte volte gli utenti (SEO compresi) tendano a confondere per semantica dei risultati che possono essere prodotti senza scomodare tale concetto.

Vale dunque la pena di fare il punto della situazione e di cercare di capire che cosa ci si può aspettare realmente per il futuro.

Il papà di AdSense

Molti non sanno perché c’è scritto “sense” in AdSense. La ragione è legata alla semantica.

Nel 1999 un’azienda chiamata Oingo Inc. aveva sviluppato un motore di ricerca in grado di svolgere un’analisi semantica delle query degli utenti e, in caso di ricerche ambigue, permetteva all’utente di definire meglio il significato di quanto era stato digitato.

Oggi siamo abituati ad una qualità dei risultati di ricerca estremamente alta: qualsiasi motore moderno è capace di fornire un’esperienza quantomeno accettabile. Oingo, nonostante i buoni propositi, non proponeva risultati particolarmente apprezzabili, nemmeno per gli standard dell’epoca. Tranne qualche contesto specifico, a mio parere la qualità era piuttosto bassa. E non solo a parere mio.

Forse consapevoli di questo limite e ritrovandosi con un algoritmo ed un approccio forse poco adatti per affrontare la complessità di un motore di ricerca generalista, nel 2002 Oingo Inc. cambiò nome in Applied Semantics per concentrarsi sullo sviluppo di soluzioni di advertising contestuale che potevano beneficiare degli algoritmi di analisi semantica dei testi fino a quel momento usati per valutare le query di ricerca.

Una di queste soluzioni si chiamava AdSense.

It’s all about the money

Google acquisì Applied Semantics e la tecnologia AdSense nel 2003, conferendo al servizio di advertising un’estrema popolarità.

Le tecnologie sviluppate da Applied Semantics rimasero circoscritte al contesto pubblicitario (ovvero all’analisi dei testi delle pagine su cui pubblicare annunci AdSense) e le analisi semantiche non vennero applicate alle ricerche sul web.

Col senno di poi è facile comprendere le ragioni della scelta di Google: da un lato la tecnologia e infrastruttura già esistenti del motore di ricerca non rendevano facile l’integrazione di analisi semantiche, dall’altro bisogna confessare che Oingo era più un limitato accrocchio accademico (basato su ODP e WordNet) piuttosto che un reale tentativo di produrre un motore di ricerca general purpose.

Esisteva anche un’altra ragione per la quale in quel periodo storico non si sentiva la necessità di un approccio semantico all’information retrieval e cioè che i risultati di Google erano già di qualità eccelsa se comparati ai risultati dei motori di ricerca concorrenti in quel periodo.

Deja vu

Nel 2001, il sito di Oingo Inc. presentava la tecnologia di ricerca nel seguente modo: “Oingo Meaning-Based Search is powered by the Oingo Ontology, a highly detailed database of over 1,000,000 words and meanings, linked by millions of relationships in a semantic network that is constantly changing to reflect the currency of everyday language.“. Potete approfondire la tecnologia qua.

Se il database di parole e significati collegati tra loro da milioni di relazioni vi ricorda le parole spese da Google quando il mese scorso ha presentato il Knowledge Graph è perché, alla faccia degli oltre dieci anni trascorsi, si tratta tutto sommato della stessa zuppa, sebbene molto molto più abbondante e gustosa.

E’ bene chiarire: esistono gigantesche differenze tra WordNet, usato da Oingo e in ambiti accademici come ontologia di base, e Freebase, che è una delle fondamenta del Knowledge Graph. Tuttavia il concetto di fondo è esattamente lo stesso: un database di entità e relazioni semantiche che possono essere sfruttate per meglio comprendere il significato di testi e query.

Verrebbe spontaneo chiedersi perché una reale applicazione della semantica si sia fatta attendere per dieci anni ma la risposta è ancora più amara della domanda e assai spiazzante: la verità è che un’applicazione della semantica agli ambiti più interessanti non c’è nemmeno adesso.

Per alcuni aspetti, Oingo faceva (maluccio) cose che il Google odierno non si azzarda nemmeno a tentare e di seguito vi spiego il perché.

Il Sacro Graal della semantica

Per capire a che punto siamo riguardo l’applicazione della semantica a Google e ai motori di ricerca in genere, è necessario prima definire in che punto si desidera arrivare.

In assoluto, uno dei più importanti obiettivi che alcuni motori di ricerca si sono posti per il futuro è quello di dotarsi di un sistema in grado di estrarre il significato dai testi dei documenti e sopratutto delle query degli utenti.

Un motore in grado di comprendere il reale significato di una query è un traguardo compatibile con la sempre maggiore tendenza e desiderio dei motori a trasformarsi in strumenti di risposta diretta.

In assenza della capacità di trasformare il testo di una query in una richiesta chiara e sensata, che potrebbe avere una risposta precisa da presentare all’utente, i motori hanno finora ripiegato nella fornitura di risorse web che presumibilmente hanno a che fare col testo cercato dall’utente.

L’analisi semantica di un testo, tuttavia, è un compito estremamente arduo per un algoritmo. La ragione è che quella capacità di comprensione che agli umani sembra così naturale e che risulta così spontanea è in realtà il frutto di un bagaglio culturale accumulato nel tempo grazie a concrete esperienze di vita, percepite attraverso sensi di cui gli umani sono dotati. E che gli algoritmi o i computer ovviamente non possiedono.

Nell’impossibilità di replicare lo stesso processo di crescita e apprendimento tipico degli esseri umani, tutto ciò che un algoritmo può fare è tentare di simulare il risultato di un’analisi semantica. Sia ben chiaro: non simulare il processo di analisi tipico degli umani ma simularne solo il prodotto finale ovvero, nel caso dei motori di ricerca/risposta, l’individuazione di una richiesta, domanda o necessità a cui assolvere.

Se ci fossero ancora dubbi sull’obiettivo di Google (e di molti altri motori) basta infine fare riferimento a quanto scritto da Jack Menzel nel post che nel 2010 annunciò l’acquisizione di Metaweb, l’azienda che stava alle spalle di Freebase, poi esteso a quello che è diventato il Knowledge Graph.

Riferendosi alle query degli utenti, Menzel scrisse: “But what about [colleges on the west coast with tuition under $30,000] or [actors over 40 who have won at least one oscar]? These are hard questions, and we’ve acquired Metaweb because we believe working together we’ll be able to provide better answers.”

Definito il traguardo, diamo un’occhiata al presente e, giusto per divertirsi un po’, anche al passato.

Vi presento Watson

Voglio mostrarvi quello che al momento può essere considerato un discreto risultato conseguito da IBM. Watson è un motore di risposta in grado di interpretare una domanda posta in un linguaggio naturale.

Per mettere alla prova i suoi algoritmi, nel 2011 IBM ha preso accordi con il quiz televisivo Jeopardy affinché Watson gareggiasse contro due dei più grandi campioni che hanno partecipato alla trasmissione.

Watson ha letteralmente sbaragliato i concorrenti, anche se è facile notare in quali contesti ha maggiore difficoltà di interpretazione delle domande.

Vi invito a guardare uno pezzo del video della trasmissione, Watson calcola per ogni domanda alcune possibili risposte e risponde solo quando tra di esse ne ha individuato una che ha un alto indice di probabilità di essere corretta.

Di seguito vi segnalo invece un video di IBM che spiega come Watson funziona.

E’ vero che Watson è in grado di rispondere correttamente nella stragrande maggioranza dei casi, tuttavia è corretto porre nel giusto contesto questa capacità, per esempio evidenziando che una singola risposta può richiedere diversi secondi di calcolo per essere formulata e che un motore di ricerca generalista sul web non si potrebbe permettere di attendere così tanto tempo per fornire una risposta all’utente.

Pertanto, per quanto IBM sia stata in grado di sviluppare un sistema di risposta di qualità, ciò non implica che la soluzione sia al momento applicabile a contesti diversi da quelli di un telequiz a premi.

Una bufala DOP

Sapete qual è stato il motore di ricerca/risposta che più di ogni altro ha investito per comunicare la propria capacità di interpretare correttamente il reale significato delle query e fornire subito una risposta all’utente? Ask Jeeves; negli anni successivi ribattezzato semplicemente “Ask”.

C’è da chiedersi come Ask Jeeves facesse, nel 1996, a svolgere questo arduo compito quando ancora oggi i più grandi colossi arrancano per trovare soluzioni decenti ad un problema così complesso come l’analisi semantica dei testi/query.

La risposta è semplice: barava un po’.

Non molti sanno infatti che i dipendenti di Ask Jeeves passavano il proprio tempo ad osservare quali query degli utenti erano le più gettonate e per ciascuna di esse si premuravano di confezionare manualmente e salvare in archivio una SERP con la giusta risposta.

Molti risultati erano quindi amorevolmente preparati a manina. Per le restanti ricerche il motore cercava di “interpretare” la query seguendo le semplici valutazioni di occorrenza delle keyword nei documenti, che erano tipiche nei motori di ricerca di quella generazione.

Ask Jeeves era in un certo senso una riproposizione moderna de “Il Turco“, un temibile giocatore meccanico di scacchi, un automa, divenuto famoso nel diciottesimo secolo per la sua bravura ma che nascondeva al proprio interno uno scacchista nano che ne muoveva gli ingranaggi.

Al di là del caso specifico, l’esempio di Ask Jeeves mette in evidenza il critico rapporto tra motori di ricerca e analisi semantiche, rapporto che rimane critico anche oggi, perché la tecnologia per proporre un reale motore di risposta generalista e in grado di estrarre un senso dalle query non esiste nemmeno adesso.

E la famigerata svolta semantica di Google, strombazzata dai giornali e blog di mezzo mondo qualche mese fa?

Come stanno le cose

Al momento Google di semantico ha solo le buone intenzioni ed un gigantesco grafo poco sfruttato.

E’ vero che il Knowledge Graph è probabilmente uno dei più grandi database di concetti e relazioni esistenti tuttavia, a differenza del moderno Watson o del vecchio Oingo, quelle relazioni non vengono al momento sfruttate per effettuare un’analisi semantica delle query.

Quello che fa Google col Knowledge Graph al momento è proporre all’utente una semplice navigazione dei suoi contenuti. Al presentarsi di alcune specifiche query il motore estrae informazioni dal database e le mostra all’utente nella parte destra della SERP.

Si potrebbe erroneamente credere che le query che vedono apparire il box di approfondimento vengano selezionate attraverso analisi semantiche delle query stesse, e invece no. E’ stata semplicemente fatta un’analisi prettamente statistica del gigantesco database di query degli utenti per determinare quali di esse meritavano il box di approfondimento e quali tipi di informazioni, per ciascuna di esse, era opportuno presentare nel box.

Facendo proprio l’esempio che appare nel post che annuncia il Knowledge Graph, l’analisi statistica del database di query ha permesso di determinare che lo scrittore Charles Dickens viene nominato dagli utenti specificando spesso l’oggetto dell’informazione richiesta, per esempio quali libri ha scritto. Questo permette a Google di sapere che “libri” è un termine che nelle query viene frequentemente associato con “Charles Dickens” e tanto gli basta per stabilire che una risposta alla query [Charles Dickens] potrebbe beneficiare dell’elenco delle opere dello scrittore.

Il punto della situazione è dunque che Google possiede uno dei più grandi archivi di concetti e relazioni mai esistito ma che non lo usa per l’obiettivo dichiarato e principale, ovvero quello di svolgere analisi semantiche delle query degli utenti (o dei testi dei documenti).

Il Knowledge Graph è sicuramente indispensabile per le future analisi semantiche delle query che Google si propone di fare, ma al momento Google nemmeno ci prova.

Conclusioni

E’ curioso osservare come le cose sembrino non cambiare nonostante il tempo trascorso.

Mirabolanti capacità del passato si scroprono essere farlocche, reali capacità di analisi semantica delle query esistevano ma sono state acquisite e messe da parte da Google (probabilmente per la scarsa qualità dei risultati), nuovi player come IBM hanno fatto passi da gigante ma non applicabili alla quantità di query di un motore generalista come Google.

E infine Google stesso, che ha fatto un importante ed essenziale primo passo verso il dichiarato obiettivo di estrarre un senso dalle query, senza però precisare che al momento non lo fa.

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