La guía tiene la versión 3.18 y es de 30 de marzo de 2011, o sea, posterior a los cambios de Google Panda.

Search Engine Land publicó la guía en su blog (Download The Latest Google Search Quality Rating Guidelines) y hubo muchas dudas acerca de la autenticidad del documento, ya que en el mismo no se hacía ninguna referencia a Google y solo se incluía el siguiente pié de página: “Proprietary and Confidential – Copyright 2011″.

No obstante la autenticidad fue confirmada de forma implícita por Google al requerir a Search Engine Land que dejasen de enlazar a un documento con copyright suyo, si no querían recibir una petición legal formal. Asimismo Pot Pie Girl también fue contactada por Google para retirar el documento y así lo hizo (10-18-2011 8:57 pm EST).

No obstante el documento sigue disponible en varias páginas web, solo hay que hacer una búsqueda en Google por: 2011 Google Quality Raters Handbook. Hay varios resultados que enlazan al documento o que directamente lo han subido a Google Docs (por ejemplo: Download The Latest Google Search Quality Rating Guidelines).

Lo interesante del documento es que contiene muchos consejos sobre lo que Google considera calidad y lo que no considera calidad. Lo que se puede aprender es como Google clasifica el contenido y páginas.

Recomendable descargarlo y leer tranquilamente sus 125 páginas.

Si está información te ha parecido interesante, mira también:

1. La calidad de la página de destino todavía será más relevante
2. 7 mitos acerca del PPC
3. Google muestra a los autores de los blogs en los resultados de búsqueda

La semana pasada Google anunció que iba a ocultar a Google Analytics las palabras clave utilizadas en las búsquedas de los usuarios logueados en alguno de sus servicios

Todo empezaba con una entrada que parecía inocente en el Webmaster Central Blog llamado “Accessing search query data for your sites” en el que explicaba que para ofrecer una experiencia de búsqueda más segura a sus usuarios, a partir de ahora los usuarios logueados en google.com automáticamente serían redirigidos a https://www.google.com para realizar sus búsquedas.

En la práctica, cualquier usuario que consulte con frecuencia su cuenta de correo GMail, sea usuario de Google+, de Google Analytics, Google AdWords, Google Docs o cualquier otro servicio que presta Google, realizará sus búsquedas mientras mantiene una sesión abierta como usuario registrado en Google y por tanto será redirigido a las búsquedas a través de https://www.google.com.

El redirigir las búsquedas de los usuarios logueados a una página segura en principio nos parece acertado, pero no se queda ahí el tema.

La polémica viene con el impacto que tiene este cambio en los webmasters, ya que en las búsquedas realizadas a través de la página de Google con encriptación SSL no pasarán la información de las palabras clave utilizadas para la búsqueda orgánica (HTTP REFERRER) a Google Analytics.

Por lo que para una búsqueda orgánica en Google solo estará disponible la información que el usuario venía de google.com, pero no con que palabras clave ha encontrado la web (en el apartado Palabras clave no habrá contenido para esos accesos, aparecerá “not provided”).

Según Google, han tomado esta medida para proteger la privacidad en las búsquedas que hacen los usuarios autenticados en su sistema.

Eso si, en el caso de los anuncios de Google AdWords si que se seguirá obteniendo esta información. Coincido con la apreciación de Danny Sullivan de Search Engine Land acerca del tema: 

The new referrer blocking change doesn’t just discriminate against the SEO side of the search marketing family. It also sends a terrible signal to consumers. It says that referrer data is important enough to protect, but not important enough when advertiser interests are at stake.

Traducido viene a significar que: Este bloqueo no solo discrimina a todos aquellos que hacen SEO, sino también es una terrible señal para los consumidores de que estos datos son lo suficientemente importantes para ser protegidos, pero no cuando hay intereses de los anunciantes por en medio.

La única forma que existirá de acceder a los datos sobre palabras clave de las personas logueadas en Google serán las Consultas de búsqueda de Google Webmaster Tools, también disponibles en la sección de Fuentes de tráfico de Google Analytics:

• Palabras clave: impresiones, clics, posición e información de CTR diario de las 1000 primeras palabras de búsqueda
• Página de destino: impresiones, clics, posición e información de CTR diario de las 1000 primeras páginas de destino
• Resumen por ubicación: impresiones, clics y CTR por país.

Según Matt Cutts, responsable del equipo de lucha contra el SPAM en Google, el impacto estará en un porcentaje de un solo dígito (inferior por tanto al 10%). Después de publicar esta cifra y por todos los comentarios recibidos, Danny Sullivan de Search Engine Land ha vuelto a confirmar con Matt Cutts de que estamos hablando de esas cifras.

Resumiendo: Según las informaciones de Google vamos a seguir teniendo suficientes datos para realiar nuestros análisis, ya que este cambio solo va a afectar a un número reducido de personas.

Aunque lo que parece que está claro es que en el futuro el uso de estos datos va a ir desapareciendo y que por tanto perderemos unos datos muy valiosos para nuestro trabajo.

Si está información te ha parecido interesante, mira también:

1. ¿Se debería de pujar por una palabra clave en la que estamos posicionados?
2. Seguimiento de búsquedas en WordPress en Google Analytics

Estos contenidos paginados puede ser desde un artículo dividido en varias páginas, una categoría de producta con artículos distribuidos en varias páginas o una publicación en un foro dividida en varias URLs. Si en estos contenidos se incluyen rel=”next” y rel=”prev” se dará a Google una pista importante de lo que queremos que haga con esas páginas, por ejemplo enviar a los usuarios a la página más relevante de la serie, normalmente la primera.

No obstante hay una excepción aluso de rel=”next” y rel=”prev”: Si además del contenido paginado el mismo contenido existe en una sola página que lo muestre todo. Hay más información aquí. Básicamente si Google detecta que hay una página que agrupa contenido paginado siempre intentará mostrar esa como resultado en las búsquedas que se hagan. Se puede por ejemplo incluir un enlaze rel=”canonical” desde las páginas individuales a la que contiene todo el contenido. Si por otro lado no se quiere que la página que argupa el contenido aparezca en los resultados de búsqueda, se puede marcar con noindex.

¿Como se implementa el rel=”next” y rel=”prev”?

Si tenemos por ejemplo las siguientes URLS con contenido paginado:

1. http://www.ej.es/art?story=abc&p=1
2. http://www.ej.es/art?story=abc&p=2
3. http://www.ej.es/art?story=abc&p=3
4. http://www.ej.es/art?story=abc&p=4

En la primera página, http://www.ej.es/art?story=abc&p=1, incluiríamos en la sección del encabezado <head> lo siguiente:

• <link rel=”next” href=”http://www.ej.es/art?story=abc&p=2″ />

En la segunda página, http://www.ej.es/art?story=abc&p=2:

• <link rel=”prev” href=”http://www.ej.es/art?story=abc&p=1″ />
• <link rel=”next” href=”http://www.ej.es/art?story=abc&p=3″ />

En la tercera página, http://www.ej.es/art?story=abc&p=3:

• <link rel=”prev” href=”http://www.ej.es/art?story=abc&p=2″ />
• <link rel=”next” href=”http://www.ej.es/art?story=abc&p=4″ />

Y en la última página, http://www.ej.es/art?story=abc&p=4:

• <link rel=”prev” href=”http://www.ej.es/art?story=abc&p=3″ />

Unos cuantos puntos a tener en cuenta:

• La primera página solo contiene rel=”next” y no rel=”prev”.
• Desde la segunda la penúltima página deben tener ambos enlaces rel=”next” y rel=”prev”.
• La última página solo tiene rel=”prev” y no rel=”next”.
• rel=”next” y rel=”prev” pueden ser URLs relativas o absolutas. Si se usa un enlace <base> también se tnedrá en cuenta.
• rel=”next” y rel=”prev” solo se tendrán en cuenta en el encabezado HTML <head>, no dentro del cuerpo <body>.
• También se permite un rel=”previous” como variante de rel=”prev”.
• rel=”next” y rel=”prev” por un lado y rel=”canonical” por el otro constituyen conceptos independientes. Ambos pueden ser incluidos en la misma página.
• rel=”next” y rel=”prev” dan pistas a Google, no es algo obligatorio para el buscador.
• Cuando estén incorrectamente implementados, Google seguirá sus propios algoritmos para la indexación.

Si está información te ha parecido interesante, mira también:

1. Google introduce la etiqueta rel=”author”
2. Factores de éxito para el posicionamiento: Tabla periódica SEO
3. Evento Google Inside Search

Optimizaciones de las páginas (parte 2/2):

9) Las imágenes se pueden agregar, para evitar peticiones HTTP de descarga de las mismas. Esto no tiene mucho sentido para las imágenes que van cambiando frecuentemente, pero si las imágenes estáticas del diseño que no varían. LA herramienta para ello son los CSS Sprites, que combina varias imágenes en una grande. Muchas webs con muchos visitantes los usan (Google, Apple, Amazon), etc. Estas imágenes se pueden generar con CSS Sprites Generator http://csssprites.com.

10) El formato de las imágenes también influye en la velocidad de carga de la páginas web. JPG tiene las mejores tasas de compresión, pero la calidad de imagen sufre. Todas las imágenes que puedan tener una calidad inferior, deberían ser JPG. Si hace falta más calidad hay que utilizar PNG, que comprime sin pérdida de calidad.

11) En las imágenes PNG es muy importante convertirlas en una imagen indexada con una paleta de colores optimizada para web. Solo de esta forma se puede conseguir una buena compresión.

12) Las imágenes siempre deben de estar enlazadas en el tamaño en el que se van a mostrar  y usar los atributos width y height.. No es nada recomendable utilizar el escalado por HTML.

13) Los navegadores pueden almacenar temporalmente contenidos, guardándolos en la caché. Cuando se accede por primera vez a una web el navegador descarga toda la página web completa. Si se vuelve a cargar la misma página posteriormente, aunque haya cambiado parte del contenido, suele haber elementos que no cambian (botones de navegación, diseño del fondo, etc). En cada carga de una página web, el navegador puede enviar recomendaciones a través del encabezado HTTP de cuanto tiempo deben conservarse que elementos en la caché sin actualizarlos. En Apache tiene que estar disponible el módulo mod_expires, además de tener acceso al archivo .htaccess. En el archivo .htaccess es donde se definen los elementos de la página y su caducidad. Para establecer el tiempo de la caché hace falta probar, con un tiempo demasiado corto perdemos optimización, con un tiempo demasiado largo pueden mostrarse contenidos antiguos. La experiencia nos demuestra q ue los archivos Javascript, CSS e imágenes cambian mucho menos que los archivos HTML.

14) Las empresas de gran envergadura emplean en muchos casos Proxies con caché para el acceso a internet de sus empleados. Estos guardan las webs recibidas como copia local, no teniendo que contactarse cada vez al servidor externo. Esta posibilidad se activa mediante el encabezado HTTP (Cache-Control: Public) y el archivo .htaccess junto con el modelo mod_expires.

15) El uso del ETag dentro del encabezado HTTP. Esto es un checksum del contenido de la página web, que el navegador puede comprar con la del contenido archivados en Caché para ver si ha habido cambios. De esta forma el navegador solo carga la página de nuevo si ha cambiado.

16) El uso de Content Delivery Networds (CDN) también pueden influir positivamente en la velocidad de carga de las páginas. Los contenidos siempre se entregan del servidor geográficamente más cercano al usuario. El servicio Amazon S3 hoy en día es asequible a todos los bolsillos. Muy recomendable para páginas estáticas muy visitadas, descargas gratuitas, etc.

17) Por otro lado, Google ofrece la Google Libraries API en su CDN en el cual están alojadas todas las versiones de las bibliotecas Javascript como jQuery, Prototype o Dojo, que pueden enlazarse directamente desde la web.

18) En el caso de blogs para WordPress es recomendable utilizar un plugin para cachear los contenidos y reducir los accesos a las bases de datos. Uno que funciona muy bien es W3 Total Cache y con el cual se puede conseguir un incremento de velocidad en factor 10 si está completamente configurado.

Teniendo en cuenta estos 18 factores, conseguiremos un incremento importante de velocidad. Ahora os toca experimentar.

Si está información te ha parecido interesante, mira también:

1. Optimización de velocidad de páginas web (2/3)
2. Optimización de velocidad de páginas web (1/3)
3. Google: La velocidad solo afecta a un 1% de las búsquedas

Una forma sencilla es mediante un servicio de monitorización que vaya midiendo regularmente la velocidad de carga. Keynote Systems ofrece gratuitamente (para uso privado) el software Kite. Una monitorización de varios días puede darnos una idea muy buena de la velocidad de carga de la web y de si hay fluctuaciones durante el día. Si hubiese muchas fluctuaciones, sería recomendable contactar con el proveedor del alojamiento para buscar alternativas (cambio de la web de servidor, incremento del paquete contratado, etc).

Una vez tenemos una presencia online estable, ya podemos pasar a analizar la velocidad de carga de las páginas en si. Para ello hay varias herramientas, destacar los add-ons YSlow y Google Page Speed que están disponibles para varios navegadores, que analizan la páginas web y dan consejos de optimización de la misma.

Google incluso ofrece desde hace algunos días un servicio para realizar esa optimización en sus servidores. Este servicio funciona redireccionando los contenidos de la web a los servidores de Google, donde el servicio Google Page Speed Online incrementa la velocidad de carga. De momento es gratuito, pero en el futuro habrá que pagar por este servicio. Otro punto negativo es que se depende de Google, por lo que mejor optimizar las páginas web en los servidores de uno mismo.

Optimizaciones de las páginas:

1) Reducir el número de componentes de una página web. En vez de usar varios archivos Javascript o CSS externos, habría que intentar reducirlos al máximo. Cada archivo externo que se carga necesita peticiones de DNS y HTTP, respuestas del servidor y finalmente el tiempo de descarga de los archivos.

2) Enlazar siempre el archivo CSS antes de los archivos Javascript. Los navegadores no ejecutan el código Javascript hasta que no están completamente cargados los archivos CSS. Este funcionamiento es debido a que el Javascript puede necesitar información de estilos.

3) Vigilar las dependencias de bibliotecas como jQuery, jQUery UI, etc. En este caso jQUery UI solo funciona correctamente si se enlaza después de jQuery.

4) De todas las bibliotecas Javascript hay versiones minimizadas para los servidores productivos. Siempre se deberían de utilizar estas versiones. En el caso de jQuery el archivo ocupa 232 KB y la versión minimizada 92 KB.

5) Todas las funciones Javascript personalizadas también deberían comprimirse. Hay distintas herramientas como Closure Compiler, JSMin y YUI Compressor.

6) La optimización del código propio Javascript también es muy relevante, pudiendo alcanzarse fácilmente incrementos de velocidad al doble. Para detectar el potencial de optimización se puede usar la extensión de FIrefox Firebug. Si se hace click sobre “Medición de tiempo”, Firebug mide los tiempos de ejecución de los scripts de Javascript y da los resultados en ms.

7) El funcionamiento normal de Javascript también tiene influencia directa sobre la velocidad. La página web no se muestra hasta que el código Javascript no se ha cargado completamente. Esto se puede evitar incluyendo el código al final de la página.

Al igual que los archivos Javascript, los archivos CSS también se pueden comprimir. Existen herramientas como Minify CSS o Google Minify (que también existe como plugin de WordPress).

Y continuará mañana con los 9 factores que faltan en la lista.

Si está información te ha parecido interesante, mira también:

1. Optimización de velocidad de páginas web (3/3)
2. Optimización de velocidad de páginas web (1/3)
3. Google: La velocidad solo afecta a un 1% de las búsquedas

Por estas razones cualquier administrador de páginas web tiene que prestar mucha atención sobre la velocidad de las mismas. Hay muchas teclas que tocar. Os las iremos resumiendo en tres entregas. 

Una página web demasiado lenta hacer perder usuarios e ingresos. Bing ha comprando esta incidencia y ha publicado datos concretos:

• Una velocidad de carga incrementada en 2 segundos disminuye los ingresos de ese usuario en 4,3%.
• En la tienda online de Amazon un tiempo de carga incrementado en 100 ms lleva a una disminución de los ingresos en un 1%.
• Un incremento de 400 ms en la velocidad de carga de Yahoo! lleva a una disminución del tráfico de entre el 5 y el 9%.

Finalmente no hay que olvidar tampoco la apuesta de Google por la velocidad: Las webs lentas tienen peor posicionamiento.

También hay ejemplos de la influencia positiva de reducir la velocidad de carga de las páginas:

• Mozilla redujo la velocidad de carga de la home en 2 s y aumentó en un 15% las descargas.
• Google redujo el volumen de datos de Google Maps en un 30% y obtuvo un incremento de los mapas visualizados en también un 30%.

El éxito de una web está por tanto ligado a su velocidad de carga, lo cual hace interesante que los desarrolladores se dediquen al WPO (Web Performance Optimization).

No hay una receta única, pero si varios factores que influyen directamente en la velocidad de carga de las páginas web. En los próximos dos días iremos detallando algunos factores sobre los que se puede trabajar.

Si está información te ha parecido interesante, mira también:

1. Optimización de velocidad de páginas web (2/3)
2. Optimización de velocidad de páginas web (3/3)
3. Google: La velocidad solo afecta a un 1% de las búsquedas

Google ha decidido compartir con nosotros cual es el trabajo que se realiza en el buscador de Google cada día, incluyendo sus cambios y mejoras.

Una mejora del algoritmo de búsqueda puede empezar con una idea creativa, pero a continuación pasa un rigurosos proceso de comprobación científica. Básicamente: Si los datos de los experimentos no ayudan a los usuarios, no se lanzará.

http://youtu.be/J5RZOU6vK4Q

Google siempre quiere dar al usuario las respuestas a preguntas por las que busca.

Si está información te ha parecido interesante, mira también:

1. ¿Cuál es el mejor buscador: Google, Bing o Yahoo?
2. Google ha publicado 10 vídeos sobre los Rich Snippets (fragmentos de búsqueda)

Google es el buscador líder con un 27,57% del tráfico que llega a las 1000 páginas con más de 10.000 fans analizadas.

Los datos completos están aquí:

La mediana es algo menor que la media de los buscadores. Esto demuestra que a un número reducido de las páginas se deriva un número mucho mayor de tráfico, subiendo la media de la muestra entera.

Es curioso el tema de YouTube que nos muestra que lleva más tráfico a las páginas de Facebook que el buscador Bing. YouTube tiene la diferencia mayor entre la media y la mediana, que puede ser debida a la falta de presencia en YouTube de algunas de las empresas o a la falta de URLs de Facebook en los vídeos.

Todos los detalles del estudio se pueden encontrar en: SEO for Facebook Fan Pages–Does it work?

Si está información te ha parecido interesante, mira también:

1. Páginas de Facebook: ¿Qué nos aportan las solapas IFRAME?
2. Usos para los IFRAMES dentro de las páginas de Facebook
3. Facebook URL Linter: Indexa tus páginas en Facebook

Una buena forma de aumentar las búsquedas locales es a través de imágenes.

Existen distintas maneras de geolocalizar imágenes, pero si incluimos metadatos geográficos en las mismas, los buscadores podrán hacerse una idea mucho mejor del lugar que muestran.

Geolocalizar imágenes con portales para compartir fotos

• Una de las formas sencillas de geolocalizar una imagen es utilizar uno de los portales para compartir imágenes (Picasa/Google Photos, Panoramio o Flickr).
  Cuando subimos una foto a uno de estos portales nos permite asociar las mismas a lugares en un mapa; al geolocalizar una imagen en uno de estos servicios, se guardan su geocoordenadas (longitud y latitud).
  ¿Pero como se asocian esas imágenes a una empresa? Al mostrar esas imágenes de esos portales en nuestra página web o al enlazar desde ese servicio a la página web de la empresa. Los dos son válidos y más efectivo usados conjuntamente.

Usar cámaras con GPS y datos EXIF

• Además de usar portales para compartir fotos, es una buena idea utilizar una cámara de fotos con GPS que guarde las coordenadas GPS en los datos EXIF de la imagen.
  Los tres portales mencionados (Picasa/Google Photos, Panoramio o Flickr) leen los datos EXIF y los usan. Tener los geodatos en la imagen tiene ventajas, por ejemplo en FLICKR que publica los datos EXIF en formato HTML junto con la imagen.

Utilizar un mapa de sitio de imagenes (Image Sitemap)

• Otra forma es guardar las imágenes directamente en la página web y añadirle un mapa de sitio de imágenes que incluya la geolocalización de cada imagen.
  No obstante no está claro como usa Google esos datos. Parece que sobre todo tiene influencia en la búsqueda de imágenes de Google.

Añadir manualmente los datos de localización

• Otra técnica para geolocalizar las imágenes es añadir los datos a las mismas con un editor EXIF. Google sugiere este método para añadir imágenes geolocalizadas a Panoramio.
  Hay bastantes programas que permiten editar los datos EXIF, Panoramio recomienda Exifer (no actualizado desde 2002), pero hay otras aplicaciones gratuitas como por ejemplo: Zoner Photo Studio.
  Después de haber añadido manualmente estos datos hay que comprobar si el portal al que subimos la foto los interpreta correctamente.

Usar Schema.org como técnica de geolocalización

• Para el futuro el uso del protocolo de schema.org  junto con ImageObject type y contentLocation son una buena solución para indicar un lugar exacto. No obstante actualmente ningún de los buscadores lo soporta.

Más información en: A Guide To Geocoding Images For Local SEO y How To Geocode An Address & Optimize Location Pages.

Si está información te ha parecido interesante, mira también:

1. Cómo realizan los usuarios búsquedas locales en Google
2. Cómo crear una galería de fotos creativa en Facebook
3. Análisis de datos de Google Analytics en Excel

HTTPS Everywhere es una extensión que tiene un listado de más de 1000 páginas web que permite el uso de HTTP y HTTPS. Cuando un usuario accede a la web sin encriptación, la extensión automáticamente lo redirige a la página con encriptada (HTPPS). De esta forma evitamos que se puedan robar las contraseñas no encriptadas con extensiones como Firesheep.

De paso y junto con la publicación de la última versión, EFF pide que todas las webs tengan la posibilidad de conectar por HTTPS, para evitar así el robo de identidades y proteger de virus y otros peligros.

Nuestra extensión protege a los usuarios de Google, DuckDuckGo o StartingPage, pero no puede hacer nada por los usuarios de Bing y Yahoo, ya que estas no tienen soporte de HTTPS.

No hay que olvidar nunca que cualquier web con un formulario para introducir un usuario y contraseña que no está encriptada con SSL (acceso a través de HTTPS), envía esa contraseña en formato texto al servidor….

Si está información te ha parecido interesante, mira también:

1. URLs HTTPS para aplicaciones de Facebook en solapas
2. Las grandes marcas en Facebook y la navegación segura HTTPS
3. Facebook empieza a recomendar la navegación segura