Online Marketing Blog | Web Marketing 

Dirò una cosa impopolare: ogni vero SEO specialist ha dentro di sè un piccolo seme di male che lo porta ad avere pensieri “black hat”… ci prova sempre a a fare pubbliche relazioni, ad essere un markettaro, un “social media fuffaro” (e a volte gli riesce pure bene) ma i pensieri black hat, per quanto repressi, tornano insistenti e lo ossessionano.

Certo, se glielo chiederete in pubblico vi dirà che “content is king” e che bisogna lavorare pensando prima di tutto al navigatore. “When Google Was not yet Evil” queste affermazioni erano utili per essere ammessi nei “salotti buoni”)
Poi scoprirete che lo stesso SEO nella sua vita professionale ha collezionato una sfilza di siti spam o “made for adsense”, o addirittura aggretatori che “rubano” e mescolano i contenuti altrui (quest’ultima è l’unica pratica che non ho mai attuato e che ritengo esecrabile, NdR).

Il sogno SEO

Il vero SEO specialist però agisce non tanto (o non solo) per il guadagno, quanto per il gusto di sperimentare: infatti si ritrova in testa una vocina assillante che gli sussura di mettere il suo ingegno al servizio del male più puro e disinteressato. E allora cercherà di capire quel che piace e non piace agli spider e di filtrare tra le pieghe di un algoritmo che cerca ogni giorno di avvicinarsi alle umane capacità di discernimento ma che, proprio per questa sua palese intenzione, è in parte prevedibile.

Uno dei molti sogni ricorrenti di ogni vero SEO è quello di poter attingere a una sorgente infinita di contenuti originali costantemente aggiornati e poterne disporre a piacimento, quello che però molti ancora non considerano è che lo stesso Google ci mette a disposizione strumenti utili a questo scopo, e  il primo e più importante tra questi è Google Translate.

Google Translate (e altre fonti) per creare contenuti originali

Le traduzioni generate da GT sono davvero eccellenti e la loro qualità migliora di mese in mese (al contrario del glorioso Babelfish, oggi marchiato Yahoo), quindi un SEO Specialist accorto oggi ne può fare decisamente buon uso: non staremo qui a descrivere per filo e per segno tutti gli ambiti di applicazione più o meno “black hat” ma ci limiteremo a fornire alcuni indizi.

Partiamo quindi dalla considerazione, per ora ovvia, che un contenuto tradotto in un altra lingua, agli occhi di Google è un contenuto originale: a questo scopo Google Translate può essere utilizzato manualmente oppure attraverso uno script.

I più spregiudicati tra voi ovviamente punteranno alla seconda soluzione, tuttavia Google non è l’ultimo arrivato, le ha pensate tutte e ha ritenuto opportuno inserire alcuni ostacoli e limitazioni.

Limitazioni imposte da Google

1. Il primo tra questi è l’abbandono, qualche anno fa, della Google SOAP API (Application Programming Interface) utilizzabile server-side, abbandonata a favore delle API Ajax (Javascript/Client quindi). Quindi oggi chi vuole fare request HTTP a Google (sia per la verifica dei ranking che per altri scopi meno facilmente intuibili ma altrettanto ragionevoli)  deve necessariamente passare per Javascript/Ajax (e non otterà quindi dei contenuti indicizzabili dagli spider) oppure violare le linee guida e fare grabbing.
2. Proprio per mettere i bastoni tra le ruote ai grabbers il codice sorgente di qualsiasi risultato restituito da qualsiasi servizio Google, se richiamato in modo non compatibile con le linee guida, è abbastanza confuso e muta con una certa frequenza (per impedire che l’estrazione di puro testo sia troppo semplice).
3. In modo particolare è difficile estrarre contenuto utile richiamando via script lato server Google Translate: infatti bisogna prima aggirare un frameset, raggiungere un url che verificherà se la precedente richiesta è passata dal frameset…e così via. Come se non bastasse il codice sorgente comprende la versione nascosta nella lingua originale…il tutto ovviamente mascherato da funzionalità utile per l’utente (come evidenziato nelle immagini 1, 2 e 3)

Insomma, provare per credere… (traduzione automatica di un post di OMB).

Riassumiamo brevemente

API Ajax per evitare di “regalare” contenuti indicizzabili e limitare le richieste dei software di ranking; frameset, codice sporco e contenuto nascosto per limitare l’estrazione di testo utile; modifiche frequenti al sorgente generato per rendere obsolete le procedure di grabbing.

Nella seconda parte di questo lungo intervento, che verrà pubblicata in settimana, vedremo che in realtà esiste anche una REST Google API (poco conosciuta) e come sia possibile utilizzare concretamente Google Translate per ricavarne contenuti utili ai fini SEO.

Per maggiori informazioni sull’abbandono delle SOAP API segnalo anche un mio vecchio articolo sul blog di HTML.it: Abbandonata la SOAP Search API: l’ennesimo “dispetto” ai SEO?

MoreVisibility.com ha di recente pubblicato un interessante post di web analysis che spiega come alcuni cambiamenti in Google Analytics determineranno un probabile incremento delle metriche del bounce rate (Why your Bounce Rate may start to go up from now on): questa segnalazione ci fornisce (abbiamo scritto l’articolo a quattro mani con Fabio ) anche l’occasione per parlare dell’interpretazione di questo dato ritenuto, giustamente, importante e significativo.

La teoria del bounce

I bounces (o “rimbalzi”) sono le visite che contano una sola pageview, o in altre parole le sessioni di navigazione del sito che consistono in una sola pagina vista.

Di conseguenza il “bounce rate” (o “tasso di rimbalzo”)  dovrebbe rappresentare la percentuale di navigatori che, raggiunto il sito, lo abbandonano immediatamente. Il bounce rate complessivo di un sito è dato dalla percentuale di visite che terminano già dopo la visualizzazione della prima pagina vista:  un alto bounce rate è comunemente un dato negativo che va interpretato come scarsa soddisfazione da parte dell’utente nei confronti dei contenuti trovati nel sito in cui si è imbattuto durante la navigazione.

Questo dato però va preso con la dovuta cautela: vediamo perché.

Una questione di definizioni

Che cos’è una visita ad un sito web? Secondo la definizione corrente una visita è una sequenza di richieste http proveniente dallo stesso ip e agente, ovvero una serie di pagine web visualizzate dallo stesso utente, ove fra l’una e l’altra non ci sia una pausa più lunga di 30 minuti. Chiaramente questa è una definizione puramente arbitraria, anche se largamente accettata nell’uso comune. La maggior parte dei moderni sistemi di statistiche si basano su questo concetto, e soffrono di conseguenza di alcune limitazioni rispetto ad alcuni punti chiave dell’analisi. Qualche esempio per spiegarci meglio:

• se un utente si allontana dal pc e poi riprende la navigazione (dello stesso sito) dopo 30 minuti, le due sessioni vengono considerate due visite separate; questo vale anche quando la pagina viene lasciata in un’altra finestra, e consultata più tardi (basti pensare quanto spesso lasciamo dei tab aperti nel browser, anche per alcune ore);
• se un utente interagisce in qualche modo con il sito senza lasciare la pagina per più di 30 minuti, e poi continua la navigazione (ad esempio nell’interazione con un oggetto flash o ajax, anche complesso: si pensi all’interfaccia della webmail o ad un gioco online), vengono di nuovo considerate due visite separate;
• inoltre in entrambi i casi sopra esposti la durata della visita viene conteggiata fino all’arrivo all’ultima pagina prima della “pausa”, mentre è chiaro che nel secondo caso è durata molto più a lungo.

L’interpretazione di dati dai molti significati

In questo scenario appare chiaro che i risultati delle analisi, basate su assunti e standard condivisi, possono variare se cambiano le definizioni. Tornando al bounce rate, per i motivi esposti non è così facile stabilire con certezza quali siano effettivamente le “visite che consistono in una sola pagina vista”.

Ma un problema ancor più grave insito nella definizione stessa è la determinazione di quali tra le visite di una sola pagina siano effettivamente visite abbandonate (= utente insoddisfatto ) e quali siano invece visite che si sono concluse con successo, per le quali l’utente ha trovato subito quello stava cercando, senza bisogno di navigare il sito (= utente soddisfatto ). Le limitazioni tecniche del protocollo http implicano che l’unico modo per capire se una pagina sia stata effettivamente abbandonata o meno, dipende esclusivamente dalla possibilità di tracciare una qualsiasi azione del navigatore dopo l’arrivo sulla pagina. Insomma non c’è modo, utilizzando il solo criterio delle pagine viste, di distinguere il navigatore che abbandona immediatamente una pagina, in quanto non soddisfatto, da quello che non dà più notizie di sé perché proprio in quella pagina ha trovato tutto ciò che desiderava dalla vita

Si pensi banalmente ad utenti provenienti dai motori di ricerca, che atterrano nella pagina di un post specifico del nostro blog, per una ricerca rilevante. Leggono il post, magari ci salvano pure nei bookmark o nell’aggregatore dei feed… e se ne vanno. Il sistema di analytics conta un bounce, ma in realtà può essere una visita valida e di buon successo. Lo stesso vale per siti di news (quello che conta è la notizia in sè), forum, siti informativi o che forniscono contenuti multimediali o giochi in flash, insomma in tutti i casi in cui il contenuto del sito può essere goduto con la visita di una sola pagina. Molto spesso le visite a questi contenuti cominciano dal motore di ricerca, e terminano non appena il bisogno è stato soddisfatto. In alcuni casi addirittura un bounce rate troppo basso (ed un elevat media di pagine viste per visita) può essere preoccupante e sintomo di un problema: si pensi al sito di supporto tecnico per un prodotto, vogliamo che gli utenti trovino quello che cercano più velocemente possibile.

D’altro canto il bounce rate è un parametro affidabile nel valutare l’efficacia di un sito di e-commerce (dove si auspica che il navigatore non si fermi alla prima pagina), o comunque in tutti i casi in cui ci sia una ben precisa “azione attesa” da parte degli utenti, in altre parole una conversione.

In conclusione, nel caso del bounce rate come della maggior parte delle metriche di web analytics, per stabilire se un valore sia buono o meno è necessario valutare nello specifico la tipologia del sito e del modello di business sotteso. Solo confrontando i parametri con gli obiettivi che ci si è posti sarà possibile decidere se il 70% di bounce rate sia un dato allarmante o il segnale che abbiamo degli ottimi contenuti!

Gli ultimi sviluppi tecnologici

Ultimamente anche Google Analytics, come altri sistemi di tracking a pagamento, ha introdotto il tracciamento nativo per oggetti dinamici, come il flash. Tracciare le interazioni con le pagine che non comportano il caricamento di una nuova pagina è già un ottimo modo per risolvere il problema per i siti con questo tipo di contenuti.

La questione riguardo invece ai siti informativi, blog e affini invece rimane aperta.

[EDIT] Carlo (che ringraziamo) nei commenti ha fatto notare come attualmente quasi tutti i sistemi di web analysis moderni utilizzo tecnologie lato client basate su cookie temporanei first party, che permettono un notevole miglioramento nel tracciamento delle azioni e nella loro correlazione; il risultato è che ormai il concetto di “visita” è stato sostituito dalla “sessione”, più preciso. Nell’articolo originale non si è fatto menzione di questa differenza per non aggiungere (ulteriore) complessità all’argomento, ma mi sembra ora utile integrare questa precisazione nel testo. Ad ogni modo le considerazioni ed osservazioni presenti in questo post rimangono ugualmente valide.

Fonti per l’approfondimento:

• Morevisibility.com – Why your Bounce Rate may start to go up from now on
• Occam’s Razor by Avinash Kaushik – Standard Metrics Revisited: #3: Bounce Rate
• Dosh Dosh – How to Analyze and Improve the ‘Bounce Rate’ for Your Website
• Jakob Nielsen’s Alertbox – Reduce Bounce Rates: Fight for the Second Click

L’argomento non è originale, anzi è uno di quelli che occupa da più tempo i pensieri di SEO e Webmaster, ma è stato riportato in auge qualche tempo fa dalla notizia che Adobe sta sviluppando soluzioni in collaborazione con Google e Yahoo per rendere i file SWF maggiormente “permeabili” agli spider.

Purtroppo questo accordo ha avuto un risalto maggiore di quanto meritasse, tanto che l’entusiasmo eccessivo di quasi tutti coloro che ne hanno parlato, rischia di minare l’attività di sensibilizzazione che i SEO stanno portando avanti da anni sull’argomento.

Le cose da dire sarebbero davvero molte, quindi per ragioni di spazio fornirò una serie di indicazioni sotto forma di FAQ, con l’obiettivo di provare a fare chiarezza su quali siano le reali implicazioni di questa “novità”

In definitiva Flash non è necessariamente nemico dei SEO ma se riteniamo la visibilità nei motori di ricerca un obiettivo importante, il SEO deve essere coinvolto sin dalle prime fasi di progettazione di un sito.

Troppo spesso invece il SEO viene chiamato ad intervenire solo a cose fatte, e notizie come quella in questione rischiano di far prendere alla leggera le questioni legate alla visibilità:

“utilizzo Flash perchè è veloce in fase di sviluppo e il cliente vuole un sito accattivante, tanto ormai tutti dicono che i motori di ricerca indicizzano i file SWF. Poi quando il SEO prenderà in mano la cosa, se c’è da fare qualche aggiustamento, se ne occuperà lui…”