Tra il 28 e il 29 Settembre 2007 il noto search engine di Microsoft propone un profondo cambiamento del proprio algoritmo, abbandonando definitivamente il vecchio motore per un approccio basato in maniera decisa sul concetto di "pertinenza" e "rilevanza" dei risultati.
Il "fu" Msn
Facendo un passo indietro ricordiamo Msn in qualche modo come il " paradiso dei Seo ", il motore sul quale ottenere posizionamenti ai primissimi posti era sostanzialmente una questione di link popularity e keywords density. Una popolarità basata però solo sulla massa di link in entrata, senza troppi riguardi per la qualità e pertinenza delle pagine linkanti e soprattutto senza una vera scrematura nei confronti di siti web sovra ottimizzati o addirittura di veri e propri spam engine.
Un paradiso dunque anche per spammer a diversi livelli, spesso posizionati ai primissimi posti delle serp, rendendole sempre meno efficaci e pertinenti a danno dei visitatori.
Forse proprio questo handicap del vecchio sistema, e l'incredibile impegno dei concorrenti proprio sulla qualità dei risultati (in primo luogo di Google), spinge lo staff di Microsoft a lavorare su Live Search, a investire in modo deciso e definitivo su un nuovo motore: più veloce, in grado di ampliare la portata dei risultati, che elimini lo spam, che restituisca serp più pertinenti.
Parlarne ad un anno di distanza è fondamentale perché forse proprio ora si può comprendere pienamente la portata e gli effetti di questo cambiamento, operato attraverso diversi sforzi, tra i quali:
lo sviluppo e l'ampliamento di ricerche verticali;
il nuovo algoritmo in grado di generare serp pertinenti;
il miglioramento delle capacità di indicizzare pagine web.
Ricerche verticali, sulle orme della "ricerca universale" di Google.
Il nuovo Live Search investe innanzitutto nella direzione già intrapresa dal principale competitor Google (e in parte anche da Yahoo), fornendo all'utente possibilità di ricerca sempre più articolate e multimediali, definite ricerche verticali, ovvero che diano la possibilità di trovare immagini, mappe, video, notizie, ed altro, oltre ai tradizionali risultati testuali, come nel caso delle molteplici possibilità offerte dal motore di Mountain View (Google News, Google Images, Google Video, ecc.).
Questo approccio dà il segno della profonda "rivoluzione" attuata in casa Microsoft al fine di competere veramente nel futuro delle ricerche on line, intercettando e cavalcando le nuove frontiere già ampiamente sfruttate e apprezzate dagli utenti del web.
Serp più pulite e pertinenti
Quello che probabilente è tra i risultati più brillanti del "nuovo corso" è legato alla qualità delle serp, una qualità ottenuta, a detta della stessa Microsoft, tramite lo sfruttamento di alcuni fattori:
lavorando sul clickstream degli utenti (ovvero sulle informazioni relative ai percorsi seguiti on line dagli utenti, rilevate ad esempio tramite i cookies);
considerando fattori come la sintassi e l'associazione logica delle chiavi, per meglio interpretare e tematizzare le risposte alle ricerche degli utenti;
concentrandosi in generale sulla qualità dei contenuti delle pagine indicizzate, rilevando ed escludendo più efficacemente tecniche illecite di ottimizzazione e tentativi di spam.
Le serp generate dal nuovo Live Search sono valide, posizionano prima i contenuti rilevanti e pertinenti, bannando siti di spamming o che utilizzino trucchi contrari alle linee guida.
La link popularity conta ancora molto, ma è solo parte dell'algoritmo, non più il "lasciapassare" per le prime posizioni come nel passato, e sembra tenere conto non solo della massa ma anche della autorevolezza dei backlinks.
Un indice da 20 miliardi di pagine
"Un indice molto più grande! Stiamo cercando 20 Miliardi di pagine web. Quattro volte la dimensione del nostro indice precedente. Una cosa ancora, noi adesso abbiamo l'infrastruttura per aggiungerne facilmente ancora a miliardi (si, milardi) con relativa facilità. Questo garantisce che stiamo spingendo sulla nostra dotazione per accogliere la conoscenza umana nel nostro indice."
La frase di sopra, tradotta da un post del 2 Ottobre 2007 apparso sul Blog ufficiale dello staff di Live Search, annuncia, nel presentare le nuove caratteristiche del motore di ricerca, l'ampliamento della "dotazione", portando la capacità di indicizzazione del motore a superare le 20 miliardi di pagine.
In effetti nel corso dei mesi si è verificato una sorta di "azzeramento" delle pagine di moltissimi siti web precedentemente catalogate, con una nuova indicizzazione, ma non sempre più profonda rispetto a prima, anzi... Sui forum del Webmaster Center sono nei mesi fioccate lamentele per siti , completamente indicizzati in passato, improvvisamente spariti dagli indici o relegati ad un pugno di pagine (se non spesso alla sola homepage) in conseguenza della "reindicizzazione" di Live Search.
Inoltre sui nuovi siti pubblicati il motore di Microsoft non sembrerebbe ancora "splendere" in termini di velocità di inserimento.
Tra le motivazioni valide per spiegare il fenomeno, lo staff di Live Search raccomanda gli utenti un uso corretto di sitemaps, file robots.txt, o riconduce all'eventuale presenza di tecniche non consentite dal regolamento, sulle sezioni non prese in considerazione dall'indice del motore. Infine sottolinea che le pagine vengono indicizzate in base alla propria "rilevanza".
Tra i webmaster quella che invece spesso prevale è l'idea che si tratti di semplici ritardi legati forse proprio alla nuova massa del "super indice". Con i mesi infatti molti dei siti soggetti alla incompleta indicizzazione delle proprie pagine sono rientrati completamente (o quasi) alla situazione precedente.
Dal punto di vista dei publisher
Si è notata una serie graduale di innovazioni dirette agli addetti ai lavori, tra cui l'adeguamento del protocollo sitemap agli standard XML (identico oggi per Google, Yahoo e Live), la creazione del Live Search Webmaster Center , sito di supporto ricco di strumenti utili a gestire l'indicizzazione di uno o più siti web, la nascita del Forum e del Blog di supporto per informare ed aiutare utenti e titolari di siti web.
Concludendo questa piccola cronistoria dedicata a Live Search e alle sue evoluzioni nel corso dell'ultimo anno, è possibile fare una considerazione strettamente legata agli stessi publishers. Se prima il posizionamento su Msn poteva considerarsi "una passeggiata" , avvalendosi di qualche piccolo accorgimento e trucco, ad oggi il livello di difficoltà sulle chiavi è ormai paragonabile, se non in alcuni casi più elevato, a quello riscontrabile su Google e Yahoo.
Per questo, da quel "lontano" fine Settembre del 2007, lo sviluppo serio dell'algoritmo Live ha prodotto fluttuazioni negative degli accessi di molti siti contenenti codice ai limiti del consentito, siti che in qualche modo sono stati "riportati alla partenza", e che hanno dovuto e dovranno rifarsi strada nelle serp puntando su contenuti originali e di qualità, e su un corretto lavoro di ottimizzazione delle pagine.
: Roberto Federico
Il motore di ricerca che verrà
L'ultimo sussulto l'ha dato Cuil: appena messo online, in molti si sono chiesti se fossimo di fronte all'erede di Google. Già, l'erede: lo sforzo è di guardare avanti e di immaginare a chi spetterà l'onore di strappare la corona del numero uno a Big G. Ammesso naturalmente che il primato attuale sia destinato a terminare in tempi brevi.
Gli utenti determinano il numero uno
Possiamo però chiederci quali saranno o dovranno essere le caratteristiche del dopo Google.
Al tempo della nascita, Page e Brin avevano (vittoriosamente) puntato su una grafica minimalista e un algoritmo (più o meno) efficace. Tanto bastò a far passare Google da outsider a numero uno senza alcun investimento particolare in marketing promozionale.
Da qui isoliamo già un primo aspetto: i motori di ricerca costruiscono il loro successo su quello che dimostrano di saper fare. Campagne e pubblicità hanno un'efficacia piuttosto limitata: è la pratica e il passaparola degli utenti a determinare il successo.
E teniamo presente che ai tempi del debutto di Google blog e Web 2.0 non esistevano ancora: se nascesse oggi un motore di ricerca con lo stesso "carisma" ne sentiremmo parlare in tempi brevissimi. Come è successo con Cuil, salvo mostrarsi (almeno per ora) più una meteora che un pretendente.
La nuova frontiera: il Web 2.0
Un aspetto è sicuro: l'erede dovrà muoversi in modo brillante nel "nuovo" web. Elaborare ricerche "classiche" ma anche all'interno di blog, video, social network e le altre forme di User Generated Content. Il 2.0 insomma sarà il suo habitat di riferimento.
Non sarebbe male se dimostrasse la capacità di valutare l'autorevolezza dei contenuti e delle fonti, scremando al meglio in base alla qualità. Un compito certamente non facile che possiamo immaginare come un evoluzione molto più completa (e complessa) del Trustrank di Google.
E perché no, anche la possibilità di confrontare le diverse fonti all'interno di una panoramica ragionata.
Una nuova interfaccia?
Questa serie di esigenze possono tradursi anche in una nuovo modello di interfaccia.
La distribuzione grafica di Cuil rappresenta una possibilità d'impostazione: più colonne, maggiore utilizzazione dell'intera schermata, spazio minimo per una descrizione aggiuntiva. Un pò come l'home page di Chrome, con le sue miniature dei siti più visti dall'utente.
Stiamo parlando insomma di qualcosa di nuovo rispetto al mono colonna Google, che poi è lo stesso format di tutti i principali motori di ricerca. Siamo stati abituati ad una linearità interrotta solo da eventuali annunci pubblicitari, segnalazioni video o mappe geografiche: tremendamente usabile ma ormai, forse, un pò limitativa per la ricchezza multimediale della rete.
Certo, Big G permette ricerche precise per ambito: blog, video,... ma ora serve qualcosa di più sintetico e aggregante.
Aggregazione
E aggregazione è forse il termine forte per l'immaginazione, l'obiettivo macro da realizzare. In una rete sempre più densa di contenuti, il motore di ricerca si consolida come un punto di riferimento e di filtro per non smarrirsi.
Lo stanno già facendo i soliti Google (IGoogle) e Yahoo! ma anche qui c'è da lavorare e, forse, l'impostazione di Facebook può diventare un modello su cui ragionare.
Mi riferisco alla possibilità di incorporare applicazioni esterne in modo libero e, ancora più interessante, il fatto di poterle creare da zero.
In conclusione
Abbiamo troppe aspettative verso l'erede? È forse un pò troppo per un motore di ricerca? Io credo di no: i confini e le definizioni tendono a sfumare e per il futuro dobbiamo aspettarci qualcosa di sempre più ampio e allargato. In fondo per "spodestare" Google servirà uno strumento nuovo e particolarmente sorprendente: auguriamo buon lavoro e tanta fantasia ai pretendenti.
: Nicola Ferrari
Gli utenti determinano il numero uno
Possiamo però chiederci quali saranno o dovranno essere le caratteristiche del dopo Google.
Al tempo della nascita, Page e Brin avevano (vittoriosamente) puntato su una grafica minimalista e un algoritmo (più o meno) efficace. Tanto bastò a far passare Google da outsider a numero uno senza alcun investimento particolare in marketing promozionale.
Da qui isoliamo già un primo aspetto: i motori di ricerca costruiscono il loro successo su quello che dimostrano di saper fare. Campagne e pubblicità hanno un'efficacia piuttosto limitata: è la pratica e il passaparola degli utenti a determinare il successo.
E teniamo presente che ai tempi del debutto di Google blog e Web 2.0 non esistevano ancora: se nascesse oggi un motore di ricerca con lo stesso "carisma" ne sentiremmo parlare in tempi brevissimi. Come è successo con Cuil, salvo mostrarsi (almeno per ora) più una meteora che un pretendente.
La nuova frontiera: il Web 2.0
Un aspetto è sicuro: l'erede dovrà muoversi in modo brillante nel "nuovo" web. Elaborare ricerche "classiche" ma anche all'interno di blog, video, social network e le altre forme di User Generated Content. Il 2.0 insomma sarà il suo habitat di riferimento.
Non sarebbe male se dimostrasse la capacità di valutare l'autorevolezza dei contenuti e delle fonti, scremando al meglio in base alla qualità. Un compito certamente non facile che possiamo immaginare come un evoluzione molto più completa (e complessa) del Trustrank di Google.
E perché no, anche la possibilità di confrontare le diverse fonti all'interno di una panoramica ragionata.
Una nuova interfaccia?
Questa serie di esigenze possono tradursi anche in una nuovo modello di interfaccia.
La distribuzione grafica di Cuil rappresenta una possibilità d'impostazione: più colonne, maggiore utilizzazione dell'intera schermata, spazio minimo per una descrizione aggiuntiva. Un pò come l'home page di Chrome, con le sue miniature dei siti più visti dall'utente.
Stiamo parlando insomma di qualcosa di nuovo rispetto al mono colonna Google, che poi è lo stesso format di tutti i principali motori di ricerca. Siamo stati abituati ad una linearità interrotta solo da eventuali annunci pubblicitari, segnalazioni video o mappe geografiche: tremendamente usabile ma ormai, forse, un pò limitativa per la ricchezza multimediale della rete.
Certo, Big G permette ricerche precise per ambito: blog, video,... ma ora serve qualcosa di più sintetico e aggregante.
Aggregazione
E aggregazione è forse il termine forte per l'immaginazione, l'obiettivo macro da realizzare. In una rete sempre più densa di contenuti, il motore di ricerca si consolida come un punto di riferimento e di filtro per non smarrirsi.
Lo stanno già facendo i soliti Google (IGoogle) e Yahoo! ma anche qui c'è da lavorare e, forse, l'impostazione di Facebook può diventare un modello su cui ragionare.
Mi riferisco alla possibilità di incorporare applicazioni esterne in modo libero e, ancora più interessante, il fatto di poterle creare da zero.
In conclusione
Abbiamo troppe aspettative verso l'erede? È forse un pò troppo per un motore di ricerca? Io credo di no: i confini e le definizioni tendono a sfumare e per il futuro dobbiamo aspettarci qualcosa di sempre più ampio e allargato. In fondo per "spodestare" Google servirà uno strumento nuovo e particolarmente sorprendente: auguriamo buon lavoro e tanta fantasia ai pretendenti.
: Nicola Ferrari
Google e i link a pagamento
La campagna di Google contro i link testuali a pagamento: analizziamo quali sono gli aspetti emersi riguardo a questo tema controverso. Vendere link è contrario alle linee guida di Google? Come comportarsi per evitare perdita di ranking?
La cronaca degli eventi
Il 14 Aprile del 2007 sul blog di Matt Cutts (noto esponente del quality group di Mountain View) appare un post nel quale egli invita gli utenti a segnalare, tramite l'apposito modulo per lo spam report di Google, siti contenenti link a pagamento, inserendo la parola "paidlink" nel campo relativo al tipo di infrazione da denunciare.
In realtà, già dal 2005 nel suddetto blog si cominciava a discutere riguardo all'influenza negativa sui risultati delle ricerche indotta dal meccanismo dei link testuali a pagamento.
Ma con questo intervento di Aprile viene per la prima volta stabilita e resa esplicita una strategia ben precisa da parte di Google: tramite la raccolta delle informazioni dallo spam report sarà possibile modificare gli algoritmi del motore di ricerca con il fine di penalizzare siti web che contengano la fornitura, dietro compenso, di link utili a trasmettere (e quindi di fatto "vendere") PageRank.
Il 21 Agosto 2007 alla conferenza SES (Search Engine Strategies) di San Jose viene dedicata una sessione all'argomento con l'emblematico titolo "Are Paid Links Evil?". Il sottotitolo era "Search engines, especially Google, say don't do 'em. But some search marketers say paid links work. Are paid links subverting search quality? Or are they simply a fact of life, here to stay? We explore the issues, in this session."
Già in fase di presentazione della discussione appare dunque netta la presa di posizione nei confronti dei paid links, giudicati in grado di "sovvertire la qualità delle ricerche".
Durante questa sessione Matt Cutts sosterrà che i link a pagamento in grado di passare PR sono contrari alle linee guida di Google, etichettandoli come "spazzatura" e promettendo interventi da parte del motore di ricerca, sia in fase di elaborazione degli algoritmi sia con l'apporto dei quality rater "sguinzagliati" da Mountain View.
Più recentemente l'intervento di Cutts, postato sul notissimo Search Engine Journal il 29 Ottobre 2007, annuncia che l'ultimo aggiornamento del PageRank avrebbe colpito, con una penalizzazione in termini di valore assegnato, proprio i siti contenenti link a pagamento in grado di trasmettere PageRank. Di seguito un estratto:
"The partial update to visible PageRank that went out a few days ago was primarily regarding PageRank selling and the forward links of sites. So paid links that pass PageRank would affect our opinion of a site."
Opinioni e soluzioni
Inutile segnalare la quantità di commenti, critiche o vere e proprie accuse, mosse da alcuni protagonisti del settore, riguardo alle diverse esternazioni di Matt Cutts, e le richieste di spiegazioni più chiare sullo spirito e in particolare sulla la natura pratica di queste penalizzazioni promesse e/o attuate.
L'impatto di simili operazioni infatti non sarebbe indifferente soprattutto per gli operatori che negli anni, studiando gli sviluppi delle SERP, hanno creato significativi business legati ai Links Ads. E in questo senso sono considerabili logiche le proteste e le critiche, in quanto appare evidente l'entità del danno in caso di penalizzazioni o ban da parte di una delle prime fonti di traffico presenti nel web, appunto Google.
Negli ultimi anni infatti l'evoluzione degli algoritmi dei motori di ricerca ha gradualmente aumentato il peso degli link ricevuti dai siti web ai fini del posizionamento. Il meccanismo del PageRank di Google in particolar modo, una formula in grado di assegnare un valore ed esternarlo tramite la celeberrima "barretta verde", ha riscosso un successo netto, creando di fatto un "mercato" di link florido e, fino ad oggi, in continua espansione. Link in grado di aumentare la popolarità di un sito, il suo livello di PageRank, e in definitiva di determinarne un miglior posizionamento nelle SERP.
La compravendita di collegamenti ha in alcuni casi generato sopravvalutazioni di siti web, in grado di ottenere alti punteggi di PageRank indipendentemente dalla qualità e popolarità dei contenuti, servizi o prodotti offerti, ma piuttosto semplicemente acquistando link da altri siti più autorevoli (in termini di ranking).
Questi avvenimenti non hanno evidentemente garantito (agli occhi degli esperti di Google) il rispetto di criteri di qualità e veridicità nell'assegnazione del PR, in alcuni casi favorendo nelle SERP siti web disposti a comprare i propri link, a discapito di progetti validi spinti da un principio di concorrenza leale, fondato cioè su link in entrata generati spontaneamente.
Tra le critiche più diffuse sulla scelta di Google ci sarebbe l'accusa, rivolta al motore di ricerca, di una volontà discriminatoria (se non monopolistica) nei confronti delle sponsorizzazioni tramite link concorrenti rispetto ai programmi Adsense/Adwords.
Il tutto sarebbe quindi, secondo le contestazioni, deleterio per l'autonomia e l'autodeterminazione di un mercato sul quale molte sono le aspettative (e gli investimenti) di soggetti grandi e piccoli: la pubblicità on line.
A questo proposito in realtà è necessario chiarire un punto fondamentale della vicenda: di fatto Matt Cutts e Google non hanno in nessun modo posto sotto osservazione o penalizzazione la vendita di link in quanto tale, ma esclusivamente la presenza di link a pagamento in grado di "passare" PageRank.
Come è possibile leggere da una revisione del post di Matt Cutts, Google ritiene assolutamente consentito, senza incorrere in svalutazioni di nessun genere, inserire link sponsorizzati nelle proprie pagine, evitando però che essi influiscano sul ranking assegnato dai motori di ricerca.
A tale scopo è possibile ad esempio utilizzare l'apposito tag "nofollow" all'interno di ciascuno collegamento pubblicitario, come nel presente codice:
Questo tag è in grado di impedire allo spider del motore di seguire il link e di conseguenza permette di non influenzare il PR del sito collegato (e il posizionamento dello stesso nelle SERP).
Un'altra soluzione indicata da Matt Cutts è quella di inserire o indirizzare i link verso pagine interdette ai motori di ricerca tramite appositi comandi nel file robots.txt:
Per escludere una directory:
User-agent: *
Disallow: /directory da escludere/
Per escludere una pagina:
User-agent: *
Disallow: /pagina.htm
Per certi versi quindi la politica di Google nei confronti dei link a pagamento non apparirebbe dettata da fini monopolistici o repressivi, ma assolutamente coerente con le linee guida per i webmaster, e in linea con il perenne studio di algoritmi in grado di avvicinare sempre di più i risultati delle ricerche a criteri di attinenza e qualità. Ma nella comunità i dubbi sull'opportunità e le finalità di queste misure rimangono, e i comportamenti futuri del colosso californiano forse aiuteranno a fare maggiore chiarezza
: Roberto Federico
La cronaca degli eventi
Il 14 Aprile del 2007 sul blog di Matt Cutts (noto esponente del quality group di Mountain View) appare un post nel quale egli invita gli utenti a segnalare, tramite l'apposito modulo per lo spam report di Google, siti contenenti link a pagamento, inserendo la parola "paidlink" nel campo relativo al tipo di infrazione da denunciare.
In realtà, già dal 2005 nel suddetto blog si cominciava a discutere riguardo all'influenza negativa sui risultati delle ricerche indotta dal meccanismo dei link testuali a pagamento.
Ma con questo intervento di Aprile viene per la prima volta stabilita e resa esplicita una strategia ben precisa da parte di Google: tramite la raccolta delle informazioni dallo spam report sarà possibile modificare gli algoritmi del motore di ricerca con il fine di penalizzare siti web che contengano la fornitura, dietro compenso, di link utili a trasmettere (e quindi di fatto "vendere") PageRank.
Il 21 Agosto 2007 alla conferenza SES (Search Engine Strategies) di San Jose viene dedicata una sessione all'argomento con l'emblematico titolo "Are Paid Links Evil?". Il sottotitolo era "Search engines, especially Google, say don't do 'em. But some search marketers say paid links work. Are paid links subverting search quality? Or are they simply a fact of life, here to stay? We explore the issues, in this session."
Già in fase di presentazione della discussione appare dunque netta la presa di posizione nei confronti dei paid links, giudicati in grado di "sovvertire la qualità delle ricerche".
Durante questa sessione Matt Cutts sosterrà che i link a pagamento in grado di passare PR sono contrari alle linee guida di Google, etichettandoli come "spazzatura" e promettendo interventi da parte del motore di ricerca, sia in fase di elaborazione degli algoritmi sia con l'apporto dei quality rater "sguinzagliati" da Mountain View.
Più recentemente l'intervento di Cutts, postato sul notissimo Search Engine Journal il 29 Ottobre 2007, annuncia che l'ultimo aggiornamento del PageRank avrebbe colpito, con una penalizzazione in termini di valore assegnato, proprio i siti contenenti link a pagamento in grado di trasmettere PageRank. Di seguito un estratto:
"The partial update to visible PageRank that went out a few days ago was primarily regarding PageRank selling and the forward links of sites. So paid links that pass PageRank would affect our opinion of a site."
Opinioni e soluzioni
Inutile segnalare la quantità di commenti, critiche o vere e proprie accuse, mosse da alcuni protagonisti del settore, riguardo alle diverse esternazioni di Matt Cutts, e le richieste di spiegazioni più chiare sullo spirito e in particolare sulla la natura pratica di queste penalizzazioni promesse e/o attuate.
L'impatto di simili operazioni infatti non sarebbe indifferente soprattutto per gli operatori che negli anni, studiando gli sviluppi delle SERP, hanno creato significativi business legati ai Links Ads. E in questo senso sono considerabili logiche le proteste e le critiche, in quanto appare evidente l'entità del danno in caso di penalizzazioni o ban da parte di una delle prime fonti di traffico presenti nel web, appunto Google.
Negli ultimi anni infatti l'evoluzione degli algoritmi dei motori di ricerca ha gradualmente aumentato il peso degli link ricevuti dai siti web ai fini del posizionamento. Il meccanismo del PageRank di Google in particolar modo, una formula in grado di assegnare un valore ed esternarlo tramite la celeberrima "barretta verde", ha riscosso un successo netto, creando di fatto un "mercato" di link florido e, fino ad oggi, in continua espansione. Link in grado di aumentare la popolarità di un sito, il suo livello di PageRank, e in definitiva di determinarne un miglior posizionamento nelle SERP.
La compravendita di collegamenti ha in alcuni casi generato sopravvalutazioni di siti web, in grado di ottenere alti punteggi di PageRank indipendentemente dalla qualità e popolarità dei contenuti, servizi o prodotti offerti, ma piuttosto semplicemente acquistando link da altri siti più autorevoli (in termini di ranking).
Questi avvenimenti non hanno evidentemente garantito (agli occhi degli esperti di Google) il rispetto di criteri di qualità e veridicità nell'assegnazione del PR, in alcuni casi favorendo nelle SERP siti web disposti a comprare i propri link, a discapito di progetti validi spinti da un principio di concorrenza leale, fondato cioè su link in entrata generati spontaneamente.
Tra le critiche più diffuse sulla scelta di Google ci sarebbe l'accusa, rivolta al motore di ricerca, di una volontà discriminatoria (se non monopolistica) nei confronti delle sponsorizzazioni tramite link concorrenti rispetto ai programmi Adsense/Adwords.
Il tutto sarebbe quindi, secondo le contestazioni, deleterio per l'autonomia e l'autodeterminazione di un mercato sul quale molte sono le aspettative (e gli investimenti) di soggetti grandi e piccoli: la pubblicità on line.
A questo proposito in realtà è necessario chiarire un punto fondamentale della vicenda: di fatto Matt Cutts e Google non hanno in nessun modo posto sotto osservazione o penalizzazione la vendita di link in quanto tale, ma esclusivamente la presenza di link a pagamento in grado di "passare" PageRank.
Come è possibile leggere da una revisione del post di Matt Cutts, Google ritiene assolutamente consentito, senza incorrere in svalutazioni di nessun genere, inserire link sponsorizzati nelle proprie pagine, evitando però che essi influiscano sul ranking assegnato dai motori di ricerca.
A tale scopo è possibile ad esempio utilizzare l'apposito tag "nofollow" all'interno di ciascuno collegamento pubblicitario, come nel presente codice:
Questo tag è in grado di impedire allo spider del motore di seguire il link e di conseguenza permette di non influenzare il PR del sito collegato (e il posizionamento dello stesso nelle SERP).
Un'altra soluzione indicata da Matt Cutts è quella di inserire o indirizzare i link verso pagine interdette ai motori di ricerca tramite appositi comandi nel file robots.txt:
Per escludere una directory:
User-agent: *
Disallow: /directory da escludere/
Per escludere una pagina:
User-agent: *
Disallow: /pagina.htm
Per certi versi quindi la politica di Google nei confronti dei link a pagamento non apparirebbe dettata da fini monopolistici o repressivi, ma assolutamente coerente con le linee guida per i webmaster, e in linea con il perenne studio di algoritmi in grado di avvicinare sempre di più i risultati delle ricerche a criteri di attinenza e qualità. Ma nella comunità i dubbi sull'opportunità e le finalità di queste misure rimangono, e i comportamenti futuri del colosso californiano forse aiuteranno a fare maggiore chiarezza
: Roberto Federico
Quegli strani avvisi di Google
"Siamo spiacenti... ... ma non possiamo elaborare la tua richiesta in questo momento. Un virus o un'applicazione spyware ci sta inviando richieste automatiche e sembra che il tuo computer o la tua rete siano stati infettati."
Alcuni di voi potrebbero probabilmente supporlo. Tuttavia non ci troviamo di fronte ad un comune messaggio di un antivirus per computer, bensì ad un avviso di Google che, qualche volta, potrebbe apparire al posto di una ricerca. Non ci credete? Ecco una prova in italiano (riproducibile):
e l'originale versione in inglese.
Quindi Google si è messo a produrre un antivirus? Anche in questo caso la risposta è no. Più semplicemente, da un anno a questa parte Google ha iniziato a prendere evidenti precauzioni in termini di sicurezza su due fronti:
da un lato per l'utente, con l'intento di salvaguardare la sicurezza del navigatore fornendo avvisi per siti potenzialmente pericolosi. Su questo argomento consiglio di leggere l'articolo Google e Stopbadware;
dall'altro lato per la stessa Google. L'obiettivo del motore di ricerca è quello di cautelarsi il più possibile rispetto al fenomeno delle query automatiche, peraltro vietate dai termini d'uso di Google, generate al fine di ottimizzare risorse e prestazioni.
Ed è proprio il secondo punto ad aver richiesto, da parte di Google, l'implementazione di alcune misure di sicurezza preventive al fine di limitare l'uso indiscriminato dello scraping, una tecnica che si basa sulla richiesta ed analisi di una pagina web da cui viene 'scaricato' l'intero contenuto. L'obiettivo, inutile dirlo, è quello di eseguire query automatiche via Google, estrapolarne i risultati e gestire le informazioni attraverso tool o interfacce sostitutive a Google.
Quali sono le cause di questo messaggio?
Arriviamo dunque al succo del discorso: quali sono le cause che possono portare Google a mostrare questo messaggio?
Nonostante il contenuto del messaggio faccia riferimento alla possibile presenza di un virus o di qualche spyware sul vostro computer, non lasciatevi prendere dal panico.
L'ipotesi che realmente il vostro computer sia infetto è assolutamente remota, soprattutto nel caso in cui stiate leggendo questo articolo e le vostre competenze siano tali da far presupporre piuttosto l'uso di strumenti avanzati di monitoraggio per SEO.
Sono infatti questi software che, nella maggior parte dei casi, Google riesce ad individuare con una certa facilità. Tra i software più a rischio risultano:
Strumenti di analisi del posizionamento
Strumenti per l'analisi delle keyword
Strumenti per calcolare il page rank o ottenere informazioni su un sito in SERP
Tra questi programmi rientrano nomi noti, come ad esempio WebCEO o Keyword Analyzer. In passato, alcuni di questi strumenti sono anche stati bannati dagli indici di Google per violazione ripetuta delle TOS.
Attenzione, questo non significa che non dobbiate usare questi strumenti... solo siate scaltri nel configurarli in modo tale che il loro uso delle query automatiche non sia eccessivo in un breve lasso di tempo.
Disabilitazione totale o per query
Il messaggio di errore che avete visto nello screenshot non è il solo avviso che potreste incontrare. Esistono infatti due tipi di precauzione:
Limitazione delle ricerche per la singola query, ovvero la casistica identificata nello screenshot pubblicato in apertura. In questo caso Google tenta di prevenire un comportamento che sembra essere ricondubile ad un singolo worm/spyware/virus circoscritto a specifiche query.
Limitazione delle ricerche allargata che, come mostra lo screenshot seguente, si estende a qualsiasi query verso il motore di ricerca per un arco di tempo imprecisato. Questo è il caso "più problematico". Google ha individuato che dal computer (o dalla rete in caso di intranet) è stato inviato un numero eccessivo di query, normalmente riconducibile ad una infezione o all'uso di software. In questo caso, per ogni query successiva è richiesta la digitazione di un codice CAPTCHA che autentica la richiesta come se fosse proveniente da una persona.
Non tutte le query sono uguali
L'utilità o meno di questo sistema, così come la sua efficacia sono argomenti al di fuori dallo scopo di questo articolo.
La parte più interessante del sistema, a mio avviso, è verificare come lo stesso sia modellato anche in base ai reali pericoli della rete. Questo significa sostanzialmente che il "peso" attribuito ad ogni query da Google per determinare, in combinazione con il fattore frequenza, la corrispondenza ad una query anomala è diverso da query a query.
Potremmo dire che la probabilità che la query sia "maligna" è data dal superamento di una soglia di sicurezza, corrispondente in modo banale ad un valore. Così come avviene ad esempio per i filtri antispam nell'email, ogni query parte da un valore 0 al quale vengono sommati dei punti a seconda di determinati fattori. Il numero di query è anomalo? Somma +N punti. Il tipo di query è a rischio? Somma +N punti. Il tipo di query è molto a rischio? Somma +N*2 punti.
Questo significa, ad esempio, che se cercate rapidamente con la query Powered by PhpBB saltando tra pagine non consecutive, potrebbe capitarvi di visualizzare il messaggio più facilmente che se cercate il mio nome.
Il motivo alla base di questo sistema è tutto sommato semplice da capire. Alcuni worm hanno obiettivi specifici, come spiegato sul blog sicurezza di Google, ad esempio quello di identificare vulnerabilità su piattaforme tendenzialmente a rischio come PhpBB. In una scala di pericolosità, invece, una query per il mio nome suscita minore preoccupazione... e certo, sono mica Kevin Mitnick io!
Come prevenire il problema
Prevenire è meglio che curare. La prevenzione, in questo caso, consiste nel limitare l'uso di software che inviano richieste automatiche a Google. Una sana manutenzione al proprio computer, tuttavia, non guasta mai, giusto per essere sicuri che il vostro hard disk non assomigli ad un allevamento intensivo di virus.
: Simone Carletti
Alcuni di voi potrebbero probabilmente supporlo. Tuttavia non ci troviamo di fronte ad un comune messaggio di un antivirus per computer, bensì ad un avviso di Google che, qualche volta, potrebbe apparire al posto di una ricerca. Non ci credete? Ecco una prova in italiano (riproducibile):
e l'originale versione in inglese.
Quindi Google si è messo a produrre un antivirus? Anche in questo caso la risposta è no. Più semplicemente, da un anno a questa parte Google ha iniziato a prendere evidenti precauzioni in termini di sicurezza su due fronti:
da un lato per l'utente, con l'intento di salvaguardare la sicurezza del navigatore fornendo avvisi per siti potenzialmente pericolosi. Su questo argomento consiglio di leggere l'articolo Google e Stopbadware;
dall'altro lato per la stessa Google. L'obiettivo del motore di ricerca è quello di cautelarsi il più possibile rispetto al fenomeno delle query automatiche, peraltro vietate dai termini d'uso di Google, generate al fine di ottimizzare risorse e prestazioni.
Ed è proprio il secondo punto ad aver richiesto, da parte di Google, l'implementazione di alcune misure di sicurezza preventive al fine di limitare l'uso indiscriminato dello scraping, una tecnica che si basa sulla richiesta ed analisi di una pagina web da cui viene 'scaricato' l'intero contenuto. L'obiettivo, inutile dirlo, è quello di eseguire query automatiche via Google, estrapolarne i risultati e gestire le informazioni attraverso tool o interfacce sostitutive a Google.
Quali sono le cause di questo messaggio?
Arriviamo dunque al succo del discorso: quali sono le cause che possono portare Google a mostrare questo messaggio?
Nonostante il contenuto del messaggio faccia riferimento alla possibile presenza di un virus o di qualche spyware sul vostro computer, non lasciatevi prendere dal panico.
L'ipotesi che realmente il vostro computer sia infetto è assolutamente remota, soprattutto nel caso in cui stiate leggendo questo articolo e le vostre competenze siano tali da far presupporre piuttosto l'uso di strumenti avanzati di monitoraggio per SEO.
Sono infatti questi software che, nella maggior parte dei casi, Google riesce ad individuare con una certa facilità. Tra i software più a rischio risultano:
Strumenti di analisi del posizionamento
Strumenti per l'analisi delle keyword
Strumenti per calcolare il page rank o ottenere informazioni su un sito in SERP
Tra questi programmi rientrano nomi noti, come ad esempio WebCEO o Keyword Analyzer. In passato, alcuni di questi strumenti sono anche stati bannati dagli indici di Google per violazione ripetuta delle TOS.
Attenzione, questo non significa che non dobbiate usare questi strumenti... solo siate scaltri nel configurarli in modo tale che il loro uso delle query automatiche non sia eccessivo in un breve lasso di tempo.
Disabilitazione totale o per query
Il messaggio di errore che avete visto nello screenshot non è il solo avviso che potreste incontrare. Esistono infatti due tipi di precauzione:
Limitazione delle ricerche per la singola query, ovvero la casistica identificata nello screenshot pubblicato in apertura. In questo caso Google tenta di prevenire un comportamento che sembra essere ricondubile ad un singolo worm/spyware/virus circoscritto a specifiche query.
Limitazione delle ricerche allargata che, come mostra lo screenshot seguente, si estende a qualsiasi query verso il motore di ricerca per un arco di tempo imprecisato. Questo è il caso "più problematico". Google ha individuato che dal computer (o dalla rete in caso di intranet) è stato inviato un numero eccessivo di query, normalmente riconducibile ad una infezione o all'uso di software. In questo caso, per ogni query successiva è richiesta la digitazione di un codice CAPTCHA che autentica la richiesta come se fosse proveniente da una persona.
Non tutte le query sono uguali
L'utilità o meno di questo sistema, così come la sua efficacia sono argomenti al di fuori dallo scopo di questo articolo.
La parte più interessante del sistema, a mio avviso, è verificare come lo stesso sia modellato anche in base ai reali pericoli della rete. Questo significa sostanzialmente che il "peso" attribuito ad ogni query da Google per determinare, in combinazione con il fattore frequenza, la corrispondenza ad una query anomala è diverso da query a query.
Potremmo dire che la probabilità che la query sia "maligna" è data dal superamento di una soglia di sicurezza, corrispondente in modo banale ad un valore. Così come avviene ad esempio per i filtri antispam nell'email, ogni query parte da un valore 0 al quale vengono sommati dei punti a seconda di determinati fattori. Il numero di query è anomalo? Somma +N punti. Il tipo di query è a rischio? Somma +N punti. Il tipo di query è molto a rischio? Somma +N*2 punti.
Questo significa, ad esempio, che se cercate rapidamente con la query Powered by PhpBB saltando tra pagine non consecutive, potrebbe capitarvi di visualizzare il messaggio più facilmente che se cercate il mio nome.
Il motivo alla base di questo sistema è tutto sommato semplice da capire. Alcuni worm hanno obiettivi specifici, come spiegato sul blog sicurezza di Google, ad esempio quello di identificare vulnerabilità su piattaforme tendenzialmente a rischio come PhpBB. In una scala di pericolosità, invece, una query per il mio nome suscita minore preoccupazione... e certo, sono mica Kevin Mitnick io!
Come prevenire il problema
Prevenire è meglio che curare. La prevenzione, in questo caso, consiste nel limitare l'uso di software che inviano richieste automatiche a Google. Una sana manutenzione al proprio computer, tuttavia, non guasta mai, giusto per essere sicuri che il vostro hard disk non assomigli ad un allevamento intensivo di virus.
: Simone Carletti
Cosa gli spider dei motori di ricerca non sanno fare
Search Engine Strategies, forum SEO e blog sul posizionamento: non c'è un'occasione dove non si senta parlare, o non si legga, delle caratteristiche dei motori di ricerca, delle regole da seguire per una corretta indicizzazione e dei suggerimenti da tenere in considerazione.
Sebbene questi elementi siano in realtà la sostanza di un corretto posizionamento, è bene considerare che si tratta del risultato dell'interpretazione delle capacità dei crawler dei motori di ricerca. Mi spiego meglio.
Si sente spesso che è importante limitare il numero di parametri in querystring al fine di garantire la corretta indicizzazione della pagina web. Perchè? La risposta è tutto sommato semplice e deriva da alcune limitazioni dei crawler meno evoluti che potrebbero incappare in loop o duplicazioni automatiche a causa di eccessivi parametri o una configurazione errata del sito web. Risultato? Le pagine non verranno indicizzate.
Insomma, praticamente ogni buona regola per una corretta indicizzazione deriva da quello che i crawler dei motori di ricerca sanno e non sanno fare. Giusto! Ma allora, cosa non sanno fare i motori di ricerca, oggi? Andiamo a scoprire alcune limitazioni, desiderate o indesiderate, dei crawler. Conoscerle ci aiuterà a progettare meglio un sito web ed agevolare l'indicizzazione.
Gestire i Cookie
I motori di ricerca non sanno gestire i cookie o, più semplicemente, gestirli potrebbe non risultare così interessante agli occhi dei motori di ricerca.
Ogni qual volta che il crawler accede ad una pagina del vostro sito ogni cookie inviato scade nell'esatto momento in cui termina la richiesta del crawler, indipendentemente che si tratti di un cookie di sessione o di un cookie datato. Ogni successiva richiesta del crawler non conterrà traccia dei cookie precedentemente inviati e quindi sono sarà possibile risalire a proprietà precedentemente impostate.
In pratica, i crawler non potranno quindi portare avanti un processo di acquisto in un e-commerse se il carrello è gestito via cookie (beh, dubito comunque che sia di vostro interesse un acquisto da GoogleBot), così come non potranno seguire percorsi di navigazione alternativi basati sull'ultima connessione dell'utente, ovviamente se salvata nei cookie.
In sintesi
Data questa limitazione è bene non affidare ai cookie dati che possano limitare la navigazione del sito. Ad esempio, implementare un controllo sulla capacità di gestire i cookie ed inviare il client ad una pagina di errore se il controllo fallisce non è certo una soluzione utile. Qualsiasi crawler di un motore di ricerca finirà sempre, inesorabilmente, nella pagina di errore ed il vostro fantastico sito da 10.000.000 di pagine non verrà neanche visto di striscio!
Gestire le Sessioni
L'argomento sessioni è tutt'altro che banale. Prima di procedere è bene chiarire brevemente il valore delle sessioni ed il loro funzionamento.
Il funzionamento della sessione
Poiché il protocollo HTTP è senza stato, ovvero non conserva alcuna informazione tra una richiesta e l'altra, per poter garantire interazioni avanzate tra utenti e siti web, come una transazione di commercio elettronico, è stato neceessario introdurre il concetto di sessione. Ogni qual volta vi connettete ad un sito web, il web server che lo gestisce genera un identificativo univoco chiamato ID di sessione che vi rappresenterà per un limitato periodo di tempo. In questo modo, sarà possibile associare alla vostra sessione una serie di dati caratterizzanti, come ad esempio il vostro nome utente se siete autenticati nel sito, oppure la lingua preferita per permettervi di navigare agevolmente su un sito tradotto in più versioni.
Ora arriviamo al punto cruciale: nella maggior parte dei casi, anzi praticamente sempre, i crawler non sanno gestire le sessioni. Il motivo è sostanzialmente una conseguenza dell'incapacità di usare i cookie e della natura multi-threading dei crawler. Vediamo insieme cosa significa.
L'ID di sessione, generato dal server, deve essere salvato dal client in qualche modo. Il modo predefinito è un cookie, un semplice cookie che contiene l'ID univoco e scade al termine della sessione stessa, in genere 20 minuti. Poiché abbiamo appena visto che i crawler non sanno gestire i cookie, la sessione non può essere salvata e di conseguenza i crawler non sanno gestire le sessioni.
Esiste un'alternativa. Nel caso in cui il web server si accorga che il client non è in grado di gestire i cookie, può essere configurato in modo da appendere l'identificativo di sessione ad ogni URL richiamata nel sito. Ecco alcuni esempi di session ID generata in Java:
http://www.sito.com/pagina.jsp;jsessionid=7E8C3C2594D3CFB297CF75218E3537B5.acaps1
Ed ecco un esempio per PHP:
http://www.sito.com/pagina.php?PHPSESSID=062b4f2d4dcb85d7dd56f09c3e809f9f
Problema risolto? Al contrario! Passare la Session ID via querystring è uno degli errori più grandi che possono penalizzare un sito web nella fase di indicizzazione. Vediamo perché.
Passare l'ID di sessione in querystring è pericoloso!
La SessionID è univoca per ogni sessione utente, giusto? Quindi se io mi connetto 5 volte in 5 giorni avrò 5 session ID differenti. Se un crawler si connette 10 volte a questo indirizzo
http://www.sito.com/pagina.php
gli verranno assegnate 10 session ID differenti, a meno di non conservarne una arrivando da un link con una session ID in querystring. Andiamo avanti nel ragionamento.
I crawler supportano il multi threading. Ovvero, potreste trovarvi sul vostro sito un singolo crawler così come 15 crawler contemporaneamente che analizzano 15 aree differenti.
Ora è il momento dei conti. Se io ho 15 istanze di GoogleBot contemporaneamente sul mio sito, ognuna delle quali genera una media di 10 sessioni id differenti ipotizzando che non arrivi da una pagina con id di sessione, avrò che il web server genererà ben 150 id di sessione differenti solo per Google e solo in pochi minuti.
Ma a questo punto, ecco che la mia pagina
http://www.sito.com/pagina.php
se io passo in querystring il valore della sessione potrebbe trasformarsi in
http://www.sito.com/pagina.php?PHPSESSID=835564f65c7df92e0d2eb667168c82f9
http://www.sito.com/pagina.php?PHPSESSID=062b4f2d4dcb85d7dd56f09c3e809f9f
http://www.sito.com/pagina.php?PHPSESSID=91a78f9969da61bd991a78f9969da61d
http://www.sito.com/pagina.php?PHPSESSID=3ef1d9428cf275202016b31c23545ffa
http://www.sito.com/pagina.php?PHPSESSID=2015ca2f2b2235e6090c9007aa281f62
ed altre 145 versioni differenti! Una pagina per 145 (ed oltre) indirizzi: è un attimo che un crawler non evoluto identifichi (erroneamente) il sito come contenuti duplicati ed escluda le pagine dal processo di indicizzazione.
Potrei portarvi almeno una decina di esempi che vi dimostrano quest'affermazione ma trattandosi di clienti ho qualche limitazione. Ad ogni modo fate una prova. Scegliete dei siti che passano la session id in querystring e dei quali conoscete precisamente il numero di pagine da cui sono composti. Eseguite una ricerca in Google per identificare il numero di pagine indicizzate e confrontatelo con il numero di pagine totali. Quasi sicuramente sarà minore!
In Sintesi
Nella quasi totalità dei casi, per un motivo o per l'altro, i crawler non supportano le sessioni e dunque qualsiasi valore salvato in una sessione precedente viene perso È bene non affidare alle sessioni, così come ai cookie, elementi determinanti per la navigazione del sito.
Ad esempio, salvare la lingua scelta in una sessione e portare l'utente sempre sulla stessa pagina modellandola in base alle preferenze è un comportamento che può causare l'impossibilità del crawler di analizzare la pagina.
Interpretare JavaScript
Arriviamo alla fatidica domanda: i crawler leggono JavaScript?
Consapevole che generalizzare è difficile, ad ogni modo la risposta è SI. Avete letto bene, la risposta è sì soprattutto se si parla di crawler più evoluti come quello di Google. Attenzione bene però, ho scritto che i crawler leggono JavaScript ma questo non significa che lo interpretino e lo eseguano.
Sebbene questi 3 termini vengano usati troppo spesso come sinonimi, in realtà non lo sono per nulla. Chiariamo dunque una volta per tutte la questione, ripeto, consapevoli che ogni crawer ha nel suo piccolo caratteristiche differenti.
I crawler leggono JavaScript
I crawler, in particolare quelli più evoluti come Google, leggono JavaScript molto spesso appositamente. Sono in grado di leggere i file JavaScript e seguire le relazioni esterne indicate nel tag
Sebbene questi elementi siano in realtà la sostanza di un corretto posizionamento, è bene considerare che si tratta del risultato dell'interpretazione delle capacità dei crawler dei motori di ricerca. Mi spiego meglio.
Si sente spesso che è importante limitare il numero di parametri in querystring al fine di garantire la corretta indicizzazione della pagina web. Perchè? La risposta è tutto sommato semplice e deriva da alcune limitazioni dei crawler meno evoluti che potrebbero incappare in loop o duplicazioni automatiche a causa di eccessivi parametri o una configurazione errata del sito web. Risultato? Le pagine non verranno indicizzate.
Insomma, praticamente ogni buona regola per una corretta indicizzazione deriva da quello che i crawler dei motori di ricerca sanno e non sanno fare. Giusto! Ma allora, cosa non sanno fare i motori di ricerca, oggi? Andiamo a scoprire alcune limitazioni, desiderate o indesiderate, dei crawler. Conoscerle ci aiuterà a progettare meglio un sito web ed agevolare l'indicizzazione.
Gestire i Cookie
I motori di ricerca non sanno gestire i cookie o, più semplicemente, gestirli potrebbe non risultare così interessante agli occhi dei motori di ricerca.
Ogni qual volta che il crawler accede ad una pagina del vostro sito ogni cookie inviato scade nell'esatto momento in cui termina la richiesta del crawler, indipendentemente che si tratti di un cookie di sessione o di un cookie datato. Ogni successiva richiesta del crawler non conterrà traccia dei cookie precedentemente inviati e quindi sono sarà possibile risalire a proprietà precedentemente impostate.
In pratica, i crawler non potranno quindi portare avanti un processo di acquisto in un e-commerse se il carrello è gestito via cookie (beh, dubito comunque che sia di vostro interesse un acquisto da GoogleBot), così come non potranno seguire percorsi di navigazione alternativi basati sull'ultima connessione dell'utente, ovviamente se salvata nei cookie.
In sintesi
Data questa limitazione è bene non affidare ai cookie dati che possano limitare la navigazione del sito. Ad esempio, implementare un controllo sulla capacità di gestire i cookie ed inviare il client ad una pagina di errore se il controllo fallisce non è certo una soluzione utile. Qualsiasi crawler di un motore di ricerca finirà sempre, inesorabilmente, nella pagina di errore ed il vostro fantastico sito da 10.000.000 di pagine non verrà neanche visto di striscio!
Gestire le Sessioni
L'argomento sessioni è tutt'altro che banale. Prima di procedere è bene chiarire brevemente il valore delle sessioni ed il loro funzionamento.
Il funzionamento della sessione
Poiché il protocollo HTTP è senza stato, ovvero non conserva alcuna informazione tra una richiesta e l'altra, per poter garantire interazioni avanzate tra utenti e siti web, come una transazione di commercio elettronico, è stato neceessario introdurre il concetto di sessione. Ogni qual volta vi connettete ad un sito web, il web server che lo gestisce genera un identificativo univoco chiamato ID di sessione che vi rappresenterà per un limitato periodo di tempo. In questo modo, sarà possibile associare alla vostra sessione una serie di dati caratterizzanti, come ad esempio il vostro nome utente se siete autenticati nel sito, oppure la lingua preferita per permettervi di navigare agevolmente su un sito tradotto in più versioni.
Ora arriviamo al punto cruciale: nella maggior parte dei casi, anzi praticamente sempre, i crawler non sanno gestire le sessioni. Il motivo è sostanzialmente una conseguenza dell'incapacità di usare i cookie e della natura multi-threading dei crawler. Vediamo insieme cosa significa.
L'ID di sessione, generato dal server, deve essere salvato dal client in qualche modo. Il modo predefinito è un cookie, un semplice cookie che contiene l'ID univoco e scade al termine della sessione stessa, in genere 20 minuti. Poiché abbiamo appena visto che i crawler non sanno gestire i cookie, la sessione non può essere salvata e di conseguenza i crawler non sanno gestire le sessioni.
Esiste un'alternativa. Nel caso in cui il web server si accorga che il client non è in grado di gestire i cookie, può essere configurato in modo da appendere l'identificativo di sessione ad ogni URL richiamata nel sito. Ecco alcuni esempi di session ID generata in Java:
http://www.sito.com/pagina.jsp;jsessionid=7E8C3C2594D3CFB297CF75218E3537B5.acaps1
Ed ecco un esempio per PHP:
http://www.sito.com/pagina.php?PHPSESSID=062b4f2d4dcb85d7dd56f09c3e809f9f
Problema risolto? Al contrario! Passare la Session ID via querystring è uno degli errori più grandi che possono penalizzare un sito web nella fase di indicizzazione. Vediamo perché.
Passare l'ID di sessione in querystring è pericoloso!
La SessionID è univoca per ogni sessione utente, giusto? Quindi se io mi connetto 5 volte in 5 giorni avrò 5 session ID differenti. Se un crawler si connette 10 volte a questo indirizzo
http://www.sito.com/pagina.php
gli verranno assegnate 10 session ID differenti, a meno di non conservarne una arrivando da un link con una session ID in querystring. Andiamo avanti nel ragionamento.
I crawler supportano il multi threading. Ovvero, potreste trovarvi sul vostro sito un singolo crawler così come 15 crawler contemporaneamente che analizzano 15 aree differenti.
Ora è il momento dei conti. Se io ho 15 istanze di GoogleBot contemporaneamente sul mio sito, ognuna delle quali genera una media di 10 sessioni id differenti ipotizzando che non arrivi da una pagina con id di sessione, avrò che il web server genererà ben 150 id di sessione differenti solo per Google e solo in pochi minuti.
Ma a questo punto, ecco che la mia pagina
http://www.sito.com/pagina.php
se io passo in querystring il valore della sessione potrebbe trasformarsi in
http://www.sito.com/pagina.php?PHPSESSID=835564f65c7df92e0d2eb667168c82f9
http://www.sito.com/pagina.php?PHPSESSID=062b4f2d4dcb85d7dd56f09c3e809f9f
http://www.sito.com/pagina.php?PHPSESSID=91a78f9969da61bd991a78f9969da61d
http://www.sito.com/pagina.php?PHPSESSID=3ef1d9428cf275202016b31c23545ffa
http://www.sito.com/pagina.php?PHPSESSID=2015ca2f2b2235e6090c9007aa281f62
ed altre 145 versioni differenti! Una pagina per 145 (ed oltre) indirizzi: è un attimo che un crawler non evoluto identifichi (erroneamente) il sito come contenuti duplicati ed escluda le pagine dal processo di indicizzazione.
Potrei portarvi almeno una decina di esempi che vi dimostrano quest'affermazione ma trattandosi di clienti ho qualche limitazione. Ad ogni modo fate una prova. Scegliete dei siti che passano la session id in querystring e dei quali conoscete precisamente il numero di pagine da cui sono composti. Eseguite una ricerca in Google per identificare il numero di pagine indicizzate e confrontatelo con il numero di pagine totali. Quasi sicuramente sarà minore!
In Sintesi
Nella quasi totalità dei casi, per un motivo o per l'altro, i crawler non supportano le sessioni e dunque qualsiasi valore salvato in una sessione precedente viene perso È bene non affidare alle sessioni, così come ai cookie, elementi determinanti per la navigazione del sito.
Ad esempio, salvare la lingua scelta in una sessione e portare l'utente sempre sulla stessa pagina modellandola in base alle preferenze è un comportamento che può causare l'impossibilità del crawler di analizzare la pagina.
Interpretare JavaScript
Arriviamo alla fatidica domanda: i crawler leggono JavaScript?
Consapevole che generalizzare è difficile, ad ogni modo la risposta è SI. Avete letto bene, la risposta è sì soprattutto se si parla di crawler più evoluti come quello di Google. Attenzione bene però, ho scritto che i crawler leggono JavaScript ma questo non significa che lo interpretino e lo eseguano.
Sebbene questi 3 termini vengano usati troppo spesso come sinonimi, in realtà non lo sono per nulla. Chiariamo dunque una volta per tutte la questione, ripeto, consapevoli che ogni crawer ha nel suo piccolo caratteristiche differenti.
I crawler leggono JavaScript
I crawler, in particolare quelli più evoluti come Google, leggono JavaScript molto spesso appositamente. Sono in grado di leggere i file JavaScript e seguire le relazioni esterne indicate nel tag