Entries Tagged 'Motori di ricerca' ↓

La memoria corta

finally... Spring!
Creative Commons License

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

Video SEO: Youtube e Sitemap video

Joy & Mya  - Steel non se la sentiva...
Creative Commons License

Alla fine di settembre Google è tornato a fare formazione sul tema dell’ottimizzazione dei contenuti video con webinar dove vengono ribadite alcune informazioni di base. Niente di nuovo, ma nelle FAQ pubblicate il giorno di Natale spunta fuori una affermazione che chiarisce un punto caldo.

Q: Can the source/content of the video (perhaps a third-party vendor) be hosted on another site? For example, can I host my videos on YouTube and still be eligible for Video Search traffic?

A: Yes, you can use a third party to host videos. Only the play page–the URL within the tag–needs to be on your site. and can list URLs on a different site or subdomain.

Maile Ohye dice quindi a chiare lettere che è possibile usare Youtube anche solo come sitema di hosting video beneficiando ugualmente del traffico proveniente dai risultati video. Per ottenre questo riusultato è comunque necessario creare e inviare una sitemap XML così come se il video fosse ospitato sul propro sito.

Non dubito che l’affermazione di Maile sia vera, ma non mi è mai capitato di vedere nelle SERP un risultato video che mi facesse atterrare su una play page non di Youtube quando il file è caricato su Youtube. Se a qualcuno è capitato mi faccia sapere.

Altre informazioni interessati che ho trovato nelle FAQ sono:

  1. Tag e categorie al momento non servono a nulla (l’affermazione di Maile è più morbida, ma il succo è questo).
  2. Evitare effetti speciali ed altre amenità come Lightbox per la visualizzazione del video. Questo almeno da concretezza alla nebulosa epressione “overly complex JavaScript” contenuta nella documentazione ufficiale.
  3. Il supporto per i sottotitoli o la trascrizione testuale del contenuto potrebbe essere disponibile in futuro. Mi sembra una naturale evoluzione del servizio offerto ora da Google. I formati di specifica dei sottotitoli (es. .srt) sono piuttosto semplici e potrebbero dare la possibilità al motore di ricerca di portare l’utente direttamente al punto in cui un certo termine viene pronunciato un po’ come succede con il le ancore per i contenuti HTML.
  4. Non usare l’elemento iframe per inserire i video nelle pagine. Ah bene. Questa non l’avevo mai sentita, nella documentazione ufficiale sui contenuti non mi pare ci sia.

Qui il post originale, mentre per chi si volesse sciroppare 87 minuti di video (pare faccia bene contro l’insonnia) eccolo qui:

Photo credit: Funky64 (www.lucarossato.com)