Universal Search rappresenta una opportunità di visibilità davvero
importante soprattutto per chi produce video.
A differenza di quanto accade per le immagini infatti un risultato video
in Universal Search fa atterrare l’utente direttamente sul sito dove il video è pubblicato senza
gli overlay ed i frame previsti ad esempio dalle immagini. Se a questo
si aggiunge che i risultati video sembrano avere un CTR del
41% superiore
ai normali risultati web è chiaro come l’opportunità sia molto più che
ghiotta.
Ma che cosa fa scattare la presenza di un risultato video all’interno
della SERP Universal Search?
Per ora ho immaginato questi tre fattori (si tratta solo di ipotesi
eh…):
- Classificazione della query. Le query informative potrebbero avere
più probabilità di includere un risultato video. Non solo quelle però:
cercando [youtube] (query ovviamente navigazionale) guarda un po’…
Salta fuori un video.
- Disponibilità di contenuti. Più sono disponibili video indicizzati
in grado di fornire risposta ad una determinata query, più è probabile
che il motore di ricerca decida che è il caso di mostrare uno di quei
video nella SERP.
- Feedback implicito degli utenti, ovvero valutazione di quanto un
risultato sia soddisfacente sulla base del CTR.
Se qualcuno ha idee migliori si faccia avanti 
. Grazie a Deborah Del
Cortona che mi ha dato spunti utili per
questo post.
La gestione delle sessioni è uno dei meccanismi che sta alla base di moltissime
applicazioni web, ed in particolare nelle applicazioni e-commerce. Qualche
volta è anche motivo di grossi mal di testa per chi si occupa di SEO.
Sessioni HTTP
Il protocollo HTTP è un protocollo stateless: non richiede che il server si
ricordi informazioni su ciascun client per più di una richiesta. Dal punto di
vista del protocollo una sessione inizia nel momento in cui il client effettua
una richiesta e termina quando il server ha risposto a tale richiesta. Il
protocollo HTTP ha la memoria corta**.
Spesso però gli utenti hanno bisogno che l’applicazione si ricordi di loro fra
una richiesta e l’altra, per diversi motivi. L’esempio più classico che abbiamo
di fronte tutti i giorni è la gestione del carrello l’applicazione web deve
tenere memoria dei prodotti scelti dall’utente per rendere possibile il
processo d’acquisto.
Per “allungare la memoria” nella comunicazione tra client e server le
applicazioni web possono utilizzare diverse tecniche, ma la più diffusa
(almeno dal 1994 ad oggi) sono i cookie. All’interno di un cookie è possibile
memorizzare un ID che identifichi in modo univoco un certo utente e tutti i
dati relativi alla sua sessione di navigazione.
Allungare la memoria del protocollo HTTP permette anche di fare altre cose
interessanti, ad esempio consente di proporre prodotti correlati a quelli già
visti in precedenza.
Cookie e motori di ricerca
I motori di ricerca in generale e Google in particolare di norma non
accettano i cookie, ovvero si comportano come un utente qualunque il cui
browser sia impostato in modo da ignorare i cookie. Ho detto di norma perché
nulla vieta a Googlebot in particolari condizioni di fingere di essere qualcun
altro e di modificare il suo comportamento allo scopo di individuare
comportamenti scorretti.
Il mondo delle favole VS la cruda realtà
L’applicazione web ideale dovrebbe:
- Consentire l’accesso senza cookie a tutte le pagine che potrebbero
essere utili agli utenti dei motori e che potrebbero essere una buona
risposta ad un bisogno di ricerca dell’utente (es. pagine di prodotto,
categorie, offerte speciali ecc…).
- Bloccare via robots.txt l’accesso a sezioni che non sono utili agli
utenti dei motori (es. carrello, prevetivatore, ecc…)
- Generare un avviso con JavaScript se il client non supporta i
cookie invitandolo ad attivarli per non perdersi funzionalità utili.
Si tratta prima di tutto di un approccio di buon senso: se qualcuno
viaggia con i cookie disabilitati è probabilmente anche in grado di
riabilitarli se viene data una buona motivazione.
In realtà applicazioni anche piuttosto sofisticate si comportano nei
modi più vari di fronte ad un client che non accetta i cookie:
- Alcune applicazioni passano a memorizzare un id di sessione nelle URL creando
il più classico dei problemi di duplicazione.
- Altre applicazioni hanno un comportamento che tecnicamente viene definito
“andarsene a male” ovvero redirigono all’infinito il client. In generale in
questi casi lo spider è progettato per mollare il colpo dopo un certo numero
di redirezioni.
Morale della favola
Se si sta sviluppando una applicazione web è sempre bene seguire
l’approccio del progressive enhancement:
Progressive enhancement uses web technologies in a layered fashion that allows
everyone to access the basic content and functionality of a web page, using
any browser or Internet connection, while also providing those with better
bandwidth or more advanced browser software an enhanced version of the page (Wikipedia)
Se invece si deve ottimizzare una piattaforma esistente:
- Spiegare al responsabile marketing che è meglio rischiare di
perdere l’improbabile acquisto di due utenti con i cookie disabilitati
piuttosto che avere gravi problemi di duplicazione.
- Spiegare al responsabile IT che no, fare cloaking basandosi sullo user
agent del client non è un buon modo di risolvere il problema.
- Spiegare agli sviluppatori che si, l’accessibilità senza cookie è un
requisito indispensabile, anche se la loro super piattaforma avanzata
che costa migliaia di euro non lo prevede.
- Pregare il proprio dio.
Photo credit: Kicki
