Ayer mirando el tema de not-provided junto con Natzir de Analista SEO y Web nos dimos cuenta a raiz de ciertos posts por la blogesfera que dicen como sacar la posición de las keywords “not-provided” en base a filtros en nuestro Google Analytics, que el búscador de Google envía el tráfico a nuestra web de forma diferente desde su versión HTTPS dependiendo el navegador del usuario.
Al parecer si se está navegando desde Chrome, el comportamiento es el adecuado y no se envía los datos completos del referrer , tan sólo el dominio, pero si se trata de un FireFox o un Internet Explorer, Google nos haré llegar el tráfico a través de un enlace http ( con su referer ), pero eliminando el parámetro “q”, correspondiente a la palabra clave que ha utilizado el usuario para encontrarnos.
Asi que actualmente tenemos 2 tipos de “not-provided” , de los que podemos sacar la posición en el SERP y de los que no podemos hacerlo. Por lo tanto los filtros y perfiles que existen por internet, no son ciertos al 100% , aquí abajo está la tabla donde se ve el comportamiento de la SERP de Google en base al Navegador, http o https, y si se está logeado o no:
* Internet Explorer los mismos resultados que Firefox
Desde la cuenta oficial de Google Analytics proclamaban que no se iba a información del referer desde las búsquedas de Google:
Esto actualmente no está siendo así, pero bueno, también solo iba a afectar a un pequeño porcentaje de búsquedas y desde luego cualquiera puede ver que actualmente el not-provided en la keyword más utilizada en casi todas las cuentas 😉
Tal vez esto sea la solución parcial que piensa proponer Google para minimizar el problema que ha generado con su decisión de forzar el tráfico de su buscador a https, así como la decision de Mozilla Fundation de poner por defecto la búsqueda por HTTPS en las cajas de búsqueda de Firefox.
Una de las cosas con las que no hemos podido hacer pruebas es con los enlaces desde https://www.google.es a una página segura, donde se debería mantener la keyword y si se sigue el comportamiento actual, se estaría perdiendo sin justificación alguna.
Desconozco realmente si esta manera de enviar el tráfico por parte del buscador está documentado en algún sitio ( al menos no lo he encontrado ) o simplemente están haciendo pruebas con ello, de ser así el juego de Google sería unfair , dado que sus justificaciones para utilizar https por defecto era para proteger al usuario y de esta manera lo único que está consiguiendo es esconder la keyword, tal como vez como se ha comentado por algunos sitios para que luego sólo Google Premium pudiera ser capaz de ver todos los datos, esperemos que no sea el caso
Viendo el histórico de logs y tal y como comento en la actualización de abajo, no es que estén cambiando el juego para diferentes navegadores, si no que parece ser que hasta ahora no se había realizado una transición real al https y que está empezando a través de Chrome.
De todas formas para ayudar realmente a la tarea de medición por parte de los analistas o SEO’s, Google debería unificar este comportamiento en vez de cambiar las reglas cuando se trata de su navegador Chrome.
Actualización:
Revisando los logs de este dominio, hasta el 12 de Abril Chrome ha estado funcionando como lo hace actualmente Firefox, es decir usando una redirección a través de un enlace http eliminando la keyword en vez de https y a partir de ese día, es cuando los usuarios de Chrome se han empezado a enviar a través de una redirección realmente segura.
Es de supone que Google esté haciendo pruebas con su navegador para luego hacer lo mismo con el resto. En definitiva los trucos actuales para saber las posiciones de los not-provided seguramente terminarán dejando de ser válidos.
Logs
GOOGLE.ES HTTPS ( Logged ) | CHROME XX.XX.XX.XX – – [21/Apr/2012:16:14:27 +0200] “GET / HTTP/1.1” 200 15734 “https://www.google.es/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19”
GOOGLE.ES HTTP ( UNLOGGED ) | CHROME XX.XX.XX.XX – – [21/Apr/2012:16:15:54 +0200] “GET / HTTP/1.1” 200 15736 “http://www.google.es/url?sa=t&rct=j&q=thyngster&source=web&cd=1&sqi=2&ved=0CCQQFjAA&url=http%3A%2F%2Fwww.thyngster.com%2F&ei=_sCST-
C7GMnHtAbuqYWbBA&usg=AFQjCNHUpdbVqs7WbvshVeprOigcCoFK5w” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.19
(KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19″
GOOGLE.COM HTTPS ( UNLOGGED ) | CHROME XX.XX.XX.XX – – [21/Apr/2012:16:18:14 +0200] “GET / HTTP/1.1” 200 15734 “https://www.google.com/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19”
GOOGLE.ES HTTPS ( Logged ) | FIREFOX XX.XX.XX.XX – – [21/Apr/2012:16:19:31 +0200] “GET / HTTP/1.1” 200 15736 “http://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CCYQFjAA&url=http%3A%2F%2Fwww.thyngster.com%2F&ei=
wsGST6rBFc3zsgab57DSBA&usg=AFQjCNHUpdbVqs7WbvshVeprOigcCoFK5w” “Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firef ox/11.0”
GOOGLE.ES HTTPS ( Unlogged ) | FIREFOX XX.XX.XX.XX – – [21/Apr/2012:16:21:21 +0200] “GET / HTTP/1.1” 200 15735 “http://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CCQQFjAA&url=http%3A%2F%2Fwww.thyngster.com%2F&ei=R8KST_ijBdDIswbs5KjZBA&usg=AFQjCNHUpdbVqs7WbvshVeprOigcCoFK5w” “Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0”
GOOGLE.ES HTTP ( Unlogged ) | FIREFOX XX.XX.XX.XX – – [21/Apr/2012:16:25:38 +0200] “GET / HTTP/1.1” 200 15736 “http://www.google.es/url?sa=t&rct=j&q=thyngster&source=web&cd=1&ved=0CCQQFjAA&url=http%3A%2F%2Fwww.thyngster.com%2F&ei=SMOST5e_KcfMswby5
ICHBA&usg=AFQjCNHUpdbVqs7WbvshVeprOigcCoFK5w” “Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0”
GOOGLE.ES HTTPS ( Unlogged ) | INTERNET EXPLORER XX.XX.XX.XX – – [21/Apr/2012:17:05:29 +0200] “GET / HTTP/1.1” 200 16810 “http://www.google.es/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=1&ved=0CCQQFjAA&url=http%3A%2F%2Fwww.thyngster.com%2F&ei=pcyST8
CeCtHLswb36OnGBA&usg=AFQjCNHUpdbVqs7WbvshVeprOigcCoFK5w” “Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)”