Quando viene annunciata una novità rilevante, possiamo noi SEO esimerci dal fare dei test? No di certo. 
Eccovi allora uno specchietto riassuntivo di ciò che avviene sulle versioni HTTP ed HTTPS di www.google.com e su encrypted.google.com quando si clicca su un link verso una risorsa sui due protocolli, con e senza Google Instant attivo:
I test sono stati effettuati con Firefox 7.0.1 e supporto JavaScript attivo. Ringrazio Martino Mosna per l’aiuto.
{ 3 trackbacks }
{ 22 comments… read them below or add one }
Interessante, ma devo ammettere che ci ho messo una ventina di minuti per decifrare la tua analisi!
Infatti non è un’analisi, ma solo un riassunto schematico dei risultati del test. Per una volta l’analisi/sintesi la lascio a chi legge.
Salve,
mi potete fare un sunto di quanto illustrato?
In pratica con HTTPs quindi utente loggato non viene passato il refer
mentre con google encrypted.google.com se la risorsa è in https viene passato è corretto?
Questo cosa implica a livello di ripercussioni negli strumenti di analisi?
Salve Carla,
Dalla versione HTTPS di www.google.com viene passato un Referer depurato della query di ricerca (parametro querystring “q”).
Sì, è corretto. O almeno, per ora, encrypted.google.com si comporta ancora così.
Implica che gli strumenti di web analytics, incluso Google Analytics, continueranno a vedere tutte le visite provenienti da Google (attribuite grazie al Referer), ma non le parole chiave usate dagli utenti autenticati, i quali saranno rediretti alla versione SSL del motore. In questo post trovi maggiori dettagli.
Ottimo specchietto riassuntivo! Ci hai fatto risparmiare tempo.
Grazie Marco, sono contento che tu l’abbia trovato utile.
Visto che qualcuno m’ha posto questa domanda, ne approfitto per specificare che i controlli sono stati effettuati esclusivamente sui link dei risultati organici: in nessun caso ho verificato che cosa succede cliccando sugli annunci AdWords.
Test devo dire interessante, a guardare i referrer è proprio palese che la cosa *NON* è legata al protocollo usato, ma ad una scelta deliberatamente protezionistica da parte di G.
Questa e’ la dimostrazione lampante della differenza che passa tra:
- ingegneria
- marketing.
In pratica, mentre gli ingegneri sono abituati ad avere dati al 100% esatti in tutte le circostanze (per es. si lamentano se i cookies possono essere cancellati), il marketing e’ interessato a statistiche approssimative che gli consentano di effettuare decisioni veloci anche se i dati sono approssimativi (o parzialmente incerti).
@Martino M.: Si tratta di un’evidente soluzione di compromesso (che io ho definito un “pastrocchio”) mirata a conciliare, per quanto possibile, gli interessi contrapposti dei vari stakeholder, inclusi ovviamente anche quelli “protezionistici” dello stesso Google.
Come alcuni hanno correttamente osservato, Google ha un grande interesse a proteggere i propri asset strategici (“strategici” in quanto gli garantiscono un vantaggio competitivo); uno dei più importanti, e probabilmente il più importante in assoluto, è costituito dalle informazioni sull’attività di ricerca (e non solo) degli utenti. Di conseguenza, Google ha ritenuto opportuno limitare la tipologia e quantità di informazioni potenzialmente pubbliche, quindi accessibili anche a competitor attuali o futuri nel settore dell’advertising contestuale, sulle ricerche dei propri utenti, intervenendo per ora solo su quelle effettuate dagli utenti autenticati.
Credo che le implicazioni, anche di sicurezza, di questa modifica debbano ancora essere studiate bene, complice il fatto che non tutti ancora hanno chiaro il meccanismo sopra evidenziato. Inizialmente la maggior parte di noi aveva inteso che fosse stato rimosso il Referer, ma così non è, come abbiamo poi appurato: è stato solo sostituito con un Referer “filtrato”, nel quale il parametro “q” è vuoto. Questo è possibile grazie alla redirezione intermedia, da HTTPS ad HTTP, che –su www.google.com– si verifica anche nel caso in cui la risorsa di destinazione è su protocollo HTTPS, forzando di fatto il client a inviare una richiesta su connessione non-SSL (cosa che non avviene invece su encrypted.google.com).
Dal punto di vista meramente tecnico non è stato lasciato nulla al caso; è anzi evidente che la cosa è stata progettata fin nei minimi dettagli, e dal punto di vista strategico è stata una mossa assolutamente impeccabile. L’errore di Google è stato, a mio avviso, sul piano della comunicazione: far passare un piccolo effetto collaterale, ossia un parziale miglioramento della privacy degli utenti autenticati, come la motivazione principale, se non l’unica, quando basta fare un minimo di analisi per capire come stanno realmente le cose.
L’argomento principale addotto da chi sostiene che questa giustificazione, usata strumentalmente da Google, non stia in piedi è il fatto che i dati delle ricerche degli utenti autenticati continueranno ad essere passati agli inserzionisti, e –si badi bene– non mi riferisco solo alle query che si traducono in un clic sui propri annunci: infatti, come sappiamo, nel pannello AdWords è possibile vedere tutte le ricerche esatte, digitate dagli utenti, che hanno generato impression sui propri annunci, con buona pace della riservatezza.
Resta infine da verificare se, dopo il rollout, gli utenti autenticati potranno continuare ad utilizzare encrypted.google.com per le loro ricerche, oppure no.
Mi hai risparmiato un po’ di tempo … grazie.
Hai per caso provato anche con una VPN collegandoti a Google.com?
Perche’ tuttavia i conti non mi tornano.
@Andrea Moro:
No. Perché avrei dovuto usare una VPN?
In che senso? Spiegati meglio.
Perche’ non espandi quella textbox del tuo servizio e la trasformi in una textarea per una piu’ immediata comprensione del risultato?
No. Perché avrei dovuto usare una VPN?
Perche’ tuttavia i conti non mi tornano.
Spiegati meglio
Perche’ non fa senso che encrypted.google.com che e’ nato come SSL nativo passi ancora la query nella stringa di ricerca.
Stando a quel che dicono … non dovrebbe. Per questo i conti non mi tornano e cercavo una VPN per fare delle prove.
@Andrea Moro:
A quale “textbox” ti riferisci? Se stai parlando dello specchietto che riassume i risultati del test, si tratta di un iframe che ho usato per incorporare nel post questo documento Google Docs.
Rileggi con più attenzione il post sul blog ufficiale di Google: la modifica è riferita a www.google.com, non a encrypted.google.com.
No, mi riferisco alla textbox di derefer.it (che non conoscevo prima). Molto utile, e visto che il servizio e’ tuo mi chiedevo se non sarebbe utile per tutti espandere il textbox che mostra la URL defererata
Quanto al post … tutto chiaro … non faceva senso la logica. Tutto la. E mi chiedevo se un test fatto pero’ con un IP americano avesse risultati diversi. Magari avessero fatto un po’ di cloacking magari lo fanno pure loro.
@Andrea Moro: Ah, scusa, non avevo capito che ti stessi riferendo a derefer.it.
Trasformerò in una textarea il tag input che mostra il Referer corrente; grazie del suggerimento.
Per quanto riguarda il testing con un indirizzo IP americano, non l’ho ritenuto necessario.
Ok. Grazie cmq per il tempo che hai speso a condividere la cosa con tutti.
P.S. cmq i penultimi due link dove dici nessuno, non danno riscontro. Io la query la vedo in chiaro lo stesso.
@Andrea Moro:
Da encrypted.google.com verso http://www.whatismyreferer.com/ io vedo tuttora “No referer / Hidden”.
Aggiornamento al volo: Google ha annunciato che ci sono novità in arrivo…
Ci leveranno anche le mutande a questo giro
Eh si … vediamo cosa accade!
Segnalo che Enrico Altavilla ha appena pubblicato un eccellente articolo sull’implementazione del meta tag
referrerrecentemente annunciata da Google e sulle sue possibili implicazioni per gli strumenti di tracciamento: Arriva il meta referrer: conseguenze per la web analytics.