Planes para el 2009 en el equipo de Webspam

Hace unos meses os preguntamos en qué os gustaría que trabajase el equipo de Webspam de Google durante este año 2009. Pues bien, no sólo hemos preguntado en el blog en español, sino en blogs y foros en otras lenguas a las que damos soporte, y estos son algunos de los temas que nos habéis enviado:
  • Contenido duplicado en los resultados de búsqueda
  • Páginas de resultados vacías en nuestros resultados de búsqueda
  • Enlaces de pago
  • Programas de intercambio de enlaces
  • Dar a los usuarios más responsabilidad para ayudarnos a acabar con el spam
  • Más comunicación con webmasters
Sabemos que son temas complicados y no siempre es fácil encontrar una solución a corto plazo. Sin embargo, ya llevamos tiempo trabajando en algunos de estos temas y ofreciendo mejoras, que esperamos continuen en un futuro. Por otra parte, también hemos escrito sobre algunos de estos temas en nuestros blogs, os pasamos aquí un pequeño resumen:

El año pasado hablamos sobre cómo desmitificar la "penalización por contenido duplicado", y en lo que va del año hemos hablado de sobre cómo evitar problemas de contenido duplicado interno (con vídeo incluido) y sobre el problema del contenido duplicado debido a scrapers. Respecto a las páginas de resultados vacías, Matt Cutts hizo un llamamiento para recopilar ejemplos [inglés] que nos han ayudado a entender mejor el problema; estamos trabajando en ello. Los enlaces de pago también han sido tratados últimamente, concretamente en esta entrada. Y en cuanto a los intercambios de enlaces, hemos querido explicarlo usando el sentido común. Por supuesto, estamos encantados de recibir informes de spam o spam reports, lo cual enlaza con el tema de dar a los usuarios más responsabilidad para ayudarnos a acabar con el spam. ¡Seguid enviando vuestros informes!

Por último, en cuanto a comunicación con webmasters, tenemos este blog, el foro de ayuda a webmasters, que ha sido completamente renovado hace poco y un nuevo canal de YouTube para temas de webmasters con listas de reproducción de vídeos en español y algunos con subtítulos en español. Además podemos adelantar que Esperanza, Rebecca y yo (Alvar) estaremos en SMX Madrid de Junio, esperamos ver a tanta gente como en nuestro Search Masters en México. Para dudas sobre cómo contactar con Google, no dudéis en echar un vistazo a la entrada ¿Cómo contactar con Google?

Seguiremos actualizando este blog con más novedades respecto a estos temas.

¡Saludos!



jueves, 30 de abril de 2009

Enlaces de sitio en una línea

Quizás estes familiarizado con los enlaces de sitio que se muestran debajo del primer resultado de búsqueda y los cuales llevan a una página interna del sitio web. Los enlaces de sitio permiten a los usuarios saltar directamente a partes importantes del mismo y los cuales, a menudo, son útiles para sitios web grandes y complejos. Los enlaces de sitio tienen la ventaja adicional de dar a los usuarios un vistazo general del contenido de un sitio web resaltando algunas de las partes más populares de este. Para los webmasters, los enlaces de sitio son además beneficiosos porque ayudan a mostrar partes de la página web que los usuarios podrían no conocer. Por ejemplo, la búsqueda NASA ofrece enlaces a galería de imágenes, una página sobre el transbordador espacial (Space Shuttle) y las misiones ISS, y así sucesivamente:



Hasta ahora, los enlaces de sitio habían aparecido sólo en el primer resultado de búsqueda, y como máximo un solo sitio web podía tener enlaces de sitio para cada búsqueda. Ahora hemos lanzado una extensión: ahora puede aparecer una línea simple de enlaces en los resultados que no mostraban enlaces de sitio antes, incluso para los que no están en la primera posición. Esto significa que varios resultados en una búsqueda pueden tener enlaces de sitio. Hasta cuatro enlaces de sitio pueden aparecer justo encima de la URL de la página, en lugar de las dos columnas debajo de la URL del primer resultado. Aquí hay un ejemplo donde cada uno de los tres primeros resultados tiene una línea de enlaces de sitio:



Esta línea de enlaces de sitio tiene los mismos beneficios que los enlaces de sitio en dos columnas, pero a menor escala: enseñan a los usuarios algunas páginas secundarias relevantes del sitio web y da una idea sobre qué trata. Comparando los enlaces de sitio que aparecen por cada resultado podemos incluso ilustrar la diferencia entre los diferentes sitios web. Como los enlaces de sitio normales, los enlaces de sitio en una línea se generan algorítmicamente y la decisión de cuándo enseñarlos y qué enlaces se van a mostrar se basa por completo en beneficiar a los usuarios.

Para los webmasters, esta nueva característica significa que es posible que sus sitios web empiecen a mostrar enlaces de sitio para un cierto número de palabras clave cuando antes no lo hacían. Esperamos que esto incremente la visibilidad y el tráfico de tu sitio web, a la vez que se mejora la experiencia de los usuarios. Sin embargo, si estás seguro de que prefieres que no se muestre un determinado enlace de sitio, recuerda que siempre puedes bloquear una página para que no aparezca como un enlace de sitio durante 90 días a través de las Herramientas para webmasters. De hecho, como parte de nuestros esfuerzos para mejorar la experiencia con las Herramientas para webmasters, estamos acelerando nuestro tiempo de respuesta para bloquear páginas, así que podrías ver como una página bloqueada desaparece de los enlaces de sitio aún más rápido. Si necesitas recordar cómo se usa la herramienta de bloqueo de enlaces de sitio, échale un vistazo a esta entrada de nuestro blog [inglés]. Por ahora sólo puedes bloquear enlaces de sitio de tu página de inicio de tu sitio web, pero estamos trabajando para expandir esta prestación, así que pronto serás capaz de quitarlas de otras páginas también.

¡Esperamos que encuentres estas mejoras de los enlaces de sitio y de las Herramientas para webmasters útiles tanto para ti como para tus usuarios!

martes, 28 de abril de 2009

Cómo Google define el envío de IP, la localización geográfica y el encubrimiento

Muchos de vosotros habéis pedido más información sobre las técnicas de webserving (especialmente relacionadas con Googlebot), así que hemos hecho un pequeño glosario con algunos de los métodos menos comunes.
  • Localización geográfica: Servir contenido personalizado a los usuarios basándonos en su localización. Como webmaster, puedes ser capaz de determinar la localización del usuario por las preferencias almacenadas en sus cookies, información correspondiente a sus inicios de sesión o sus direcciones de IP. Por ejemplo, si tu sitio web es sobre béisbol, puedes usar técnicas de localización geográficas para destacar los Yankees a tus usuarios en Nueva York.
La clave es tratar a Googlebot como harías con un usuario normal con localización similar, rango de IP, etc. (por ejemplo, no trates a Googlebot como si viniese de un zona independiente, eso es encubrimiento, cloaking).
  • Envío de IP (IP delivery): Servir contenido personalizado a los usuarios basándonos en su dirección de IP, a menudo porque la dirección IP ofrece información geográfica. Y porque el envío de IP puede ser visto como un tipo específico de localización geográfica se aplican también reglas parecidas. Googlebot debería ver el mismo contenido que un usuario normal vería desde la misma dirección IP.




(Aviso del autor: Este video de 7,5 minutos puede causar somnolencia. Incluso si estás realmente interesado en el envío de IP o en los sitios con múltiples lenguajes, no contiene grandes sorpresas.) El video cuenta con subtítulos en español.
  • Encubrimiento (Cloaking): Servir contenido diferente a los usuarios que a Googlebot. Esta técnica no respeta nuestras directrices para webmasters. Si el archivo que Googlebot ve no es idéntico al archivo que ve un usuario normal y corriente, entonces estas en la categoría de alto riesgo. Un programa como md5sum o diff puede generar un hash para verificar si dos archivos son idénticos.
  • Primer clic gratis: Implementar Google News' First click free policy [inglés] para tu contenido te permite incluir contenido premium o basado en suscripciones en el índice de búsqueda de Google sin dejar de respetar nuestra directrices de calidad. Permites así a todos los usuarios que encuentran tu página mediante la búsqueda de Google que vean todo el contenido de un documento, incluso si no están suscritos. El primer clic del usuario a tu área de contenido es gratuito. Sin embargo puedes bloquear al usuario con un inicio de sesión o petición de pago cuando haga clic en otra sección de tu sitio web.
Si estas usando el Primer clic gratis (First click free), la página que se muestra a los usuarios que llegan desde Google debe ser idéntica al contenido que se enseña a Googlebot.

¿Todavía tienes preguntas? Nos vemos en nuestro forum para webmasters.

viernes, 24 de abril de 2009

Mejora del protocolo de exclusión de robots

Los editores web nos preguntan a menudo cómo aumentar la visibilidad en la web. Gran parte de esto tiene que ver con la optimización para motores de búsqueda, es decir, asegurarse de que su contenido aparece en todos los motores de búsqueda.

Sin embargo, hay algunos casos en los que los editores necesitan comunicar más información a los motores de búsqueda, como por ejemplo qué contenido no quieren que aparezca en los resultados de búsqueda. Y con este fin se utiliza el protocolo de exclusión de robots [inglés], que permite a los editores controlar la manera en la que los motores de búsqueda acceden a su sitio: ya sea controlando la visibilidad del contenido de su sitio (a través de robots.txt) o a nivel mucho más detallado, para páginas específicas (a través de meta etiquetas).

Desde que se introdujo a principios de los años 90, el protocolo de exclusión de robots se ha convertido en el estándar para que los editores web especifiquen qué partes de su web quieren mantener públicas y qué partes quieren mantener privadas. Hoy en día, millones de editores lo utilizan para comunicarse con los motores de búsqueda de manera fácil y eficiente. Su fuerza reside en su flexibilidad para evolucionar en paralelo con la web, su aplicación universal por parte de los principales robots y motores de búsqueda, así como en la forma en la que funciona para cualquier editor, sin importar si se trata de un editor grande o pequeño.

Aunque prácticamente todos los motores de búsqueda siguen el protocolo de exclusión de robots, nunca hemos llegado a poner juntas y en detalle las diferentes interpretaciones para las etiquetas. Durante los últimos años, hemos trabajado con Microsoft y Yahoo! para sacar adelante normas como Sitemaps [inglés] y para ofrecer herramientas adicionales a los webmasters. Desde el anuncio inicial, hemos ofrecido y seguiremos ofreciendo nuevas mejoras basadas en los comentarios de la comunidad.

Hoy, con el mismo propósito de hacer más sencilla la vida a los webmasters, publicamos documentación detallada sobre la mejora del protocolo de exclusión de robots. Esto hará que todos los webmasters lo apliquen de manera similar y también servirá de ayuda a los editores el hecho de conocer cómo los tres principales proveedores de búsqueda tratan las directivas para el protocolo de exclusión de robots, haciendo así que éste sea más intuitivo y fácil de usar para todos aquellos que publican en la web.

Entonces, sin más demora...

Directivas comunes del protocolo de exclusión de robots


La siguiente lista contiene las principales funciones del protocolo de exclusión llevadas a cabo por Google, Microsoft y Yahoo!. Con cada función, se indica qué hace y cómo se debe comunicar.

Cada una de estas directivas se puede especificar para que se aplique a todos los rastreadores o a algunos de ellos en concreto, apuntando a un agente de usuario específico, que es su modo de identificación. Cada uno de nuestros rastreadores también admite la autenticación por DNS inversa para verificar la identidad del rastreador.

1. 1. Directivas de Robots.txt


2. 2. Meta directivas HTML


Estas directrices se aplican a todo tipo de contenidos. Las puedes poner tanto en el código HTML de una página como en el encabezado HTTP para contenidos que no son HTML, tales como PDF, vídeo, etc, usando la etiqueta X-Robots. Aquí tienes más información: Artículo sobre la etiqueta X-Robots [inglés] o en nuestra serie de entradas [inglés] sobre el uso de robots y las meta etiquetas.

Otras directivas del protocolo de exclusión de robots


Microsoft, Google y Yahoo! utilizan las directivas que hemos mencionado, pero puede que éstas no sean válidas para otros motores de búsqueda. Además, existen las siguientes directivas que sólo ofrece Google:

UNAVAILABLE_AFTER Meta Tag
- Indica al robot cuando debe caducar una página [inglés], es decir, la fecha tras la cual no debe aparecer en los resultados de búsqueda.

NOIMAGEINDEX Meta Tag
- Indica al rastreador que no indexe las imágenes de una página determinada en los resultados de búsqueda.

NOTRANSLATE Meta Tag
- Indica al rastreador que no traduzca el contenido de una página a otros idiomas [inglés] para los resultados de búsqueda.

De cara al futuro, tenemos previsto seguir trabajando para que, cada vez que surjan nuevas directivas de protocolo de exclusión de robots, los webmasters puedan usarlas con facilidad. ¡Así que no olvides visitarnos con frecuencia!

Información adicional


Puedes encontrar más información acerca de robots.txt en http://www.robotstxt.org/ [inglés] y en el Centro de Asistencia para Webmasters de Google, que contiene una gran cantidad de información útil, que incluye:
También se han publicado varias entradas acerca de robots.txt en el Blog para webmasters inglés, como:
También hay una lista útil de robots [inglés] utilizados por los principales motores de búsqueda.

Para ver lo que nuestros colegas dicen al respecto, también puedes visitar los blogs de Yahoo! [inglés] y Microsoft [inglés].

miércoles, 22 de abril de 2009

Tendencia al alza de casos de hacking en el mercado latinoamericano

¿No te parecería un poco sospechoso encontrar páginas con texto como "Canada Mail Order Pharmacy Viagra Levitra" o "Buying Viagra In UK" en los sitios oficiales de los gobiernos latinoamericanos, de las fuerzas militares o de las instituciones universitarias? ¿Por qué razón el sitio oficial de una capital enlazaría, desde la mayoría de sus páginas, a una tienda farmacéutica de dudosa calidad? La explicación más probable es que el webmaster no haya publicado estos contenidos y que un tercero sea el responsable de haber insertado estos enlaces de manera maliciosa; es decir, lo más probable es que el sitio haya sido hackeado. Una tendencia que nuestro equipo de Calidad de búsqueda ha observado durante los últimos meses es que cada vez hay más casos de sitios importantes .gov, .mil y .edu en Latinoamérica, pero también casos de pequeñas compañías y blogs, que han sido hackeados.



El objetivo de esta entrada es ayudar a la comunidad de webmasters a prevenir que sus sitios sean atacados, ayudar a determinar cuándo el sitio se ha visto comprometido y dar consejos de cómo corregir el problema y solicitar una reconsideración si esto fuera necesario.

Hacking: ¿Qué, por qué y cómo?

Es probable que hayas escuchado anteriormente el término hacking en distintas áreas de la informática, a veces con connotaciones positivas (por ejemplo expertos en arreglar problemas de sistemas a través de soluciones ingeniosas) y en otras ocasiones con un significado negativo (por ejemplo, piratas informáticos que esquivan los sistemas de protección de un sistema informático y lo atacan para su propio beneficio). Cuando hablamos de un sitio web hackeado, nos estamos refiriendo precisamente a este último caso: personas sin escrúpulos que deciden aprovechar las vulnerabilidades de los sitios web para modificar su contenido, insertando código que en ningún caso sería aprobado por su webmaster.

Ahora, la siguiente pregunta es cómo lo hacen, ¿van los hackers manualmente examinando cada dominio para ver si encuentran alguna nueva vulnerabilidad? No precisamente. Una estrategia más efectiva es utilizar programas que identifiquen automáticamente sitios web con sistemas de gestión de contenidos (CMS) desactualizados (versiones antiguas con fallos conocidos) e insertar el contenido deseado a través de técnicas de hacking conocidas como una inyección SQL o el cross-site scripting (XSS).

El primer caso consiste en insertar trozos de código SQL en los formularios de las páginas que se utilizan para enviar información a la aplicación web (registro, inicio de sesión, comentarios, etc.), con el objetivo de modificar la sentencia SQL y esquivar el sistema de autenticación o introducir información no deseada en la base de datos. El segundo consiste en insertar en los campos del formulario un script que en el momento de ser interpretado por el navegador, redirige al usuario a otra pagina o intenta robar la información almacenada en las cookies para enviarla a un servidor externo. En nuestra entrada Prácticas recomendadas contra el hacking este tema se discute más a fondo y enlazamos hacia algunos artículos interesantes del Web Application Security Consortium donde se discuten los temas de inyección SQL [inglés] y cross-site scripting (XSS) [inglés].

¿Como prevenir y dectectar el ataque?

Una de las ventajas del movimiento de código abierto es que ha traído consigo un número considerable de aplicaciones para la publicación y administración de blogs como WordPress, sistemas de gestión de contenidos como Joomla y PHP Nuke, o sistemas de gestión de cursos como Moodle, que se pueden descargar e instalar fácilmente. Sin embargo, es muy importante que los webmasters mantengan al día las versiones de sus aplicaciones. Dado que existe una amplia comunidad de usuarios y desarrolladores de estos paquetes, es común que se descubran fallos y que se corrijan en las nuevas versiones. Si tienes instalada una versión antigua de un sistema de gestión que tiene un fallo conocido, es posible que un hacker consiga acceder al sitio y modificar el contenido, por lo tanto es conveniente estar al corriente de las últimas versiones y informarse acerca de las vulnerabilidades conocidas. El sitio BlogSecurity mantiene una lista con los fallos conocidos en las diferentes versiones de WordPress [inglés] o Linux Security ofrece un informe sobre las vulnerabilidades encontradas en Moodle [inglés] y recomienda actualizar el paquete a la última versión.

El uso de un paquete desactualizado es una de las causas más comunes del hacking, pero a su vez es una de las más fáciles de prevenir. Por ejemplo recientemente encontramos un caso de hacking en el sitio oficial de una capital sudamericana y la causa de este problema fue una versión antigua de Moodle en un sistema de enseñanza. Ahora si no utilizas un paquete de código abierto y codificas tu mismo las páginas dinámicas de tu sitio web en lenguajes como PHP o Python, es muy importante que tus scripts eviten la inyección de SQL o el cross-site scripting descritos previamente: Toda la información enviada en los formularios que ofrezca tu sitio debe ser tratada como texto, debes asegurarte de escapar los caracteres especiales como las comillas y debes evitar que ciertas etiquetas HTML puedan ser embebidas dentro de la información enviada (por ejemplo SCRIPT, META, IFRAME, DIV o SPAN). Finalmente es importante que nunca confíes ciegamente en la información enviada en los formularios y prepares tus scripts para el peor de los escenarios posibles en caso de un ataque. El manual oficial de PHP ofrece una buena descripción en castellano sobre en qué consiste y cómo puedes prevenir el ataque.

Ahora, ¿cómo puedes saber si tu sitio ha sido atacado? A veces es evidente dado que el hacker cambia el contenido de la página principal e inserta mensajes como "este sitio ha sido hackeado por tal grupo" o en el peor de los casos puede borrar todos los archivos del sitio a través de sentencias SQL, drop tables. Sin embargo, en los casos que hemos observado en los sitios latinoamericanos el ataque es más discreto dado que los hackers combinan dos técnicas distintas: hacking y encubrimiento (cloaking). Esta última técnica hace referencia a la práctica de presentar a los usuarios y motores de búsquedas contenido distinto. En estos casos los hackers modifican el código de tal forma que se muestra el contenido normal a los usuarios, pero cuando el Googlebot o algún otro robot visitan tu sitio, muestran una versión ligeramente distinta que contiene un sin número de enlaces escondidos.

Lo que hace difícil detectar esta técnica es que, al revisar tu sitio en un navegador como FireFox o Chrome, no encuentras ninguna anomalía. Sin embargo, el Googlebot rastrea e indexa el contenido hackeado. Una manera muy sencilla de detectar este problema es comparar el código de la última versión de tu página que Google almacenó en cache con el código de la versión que aparece en el navegador. Para hacerlo, agrega en el campo de búsqueda de Google el operador "cache:" y la página que deseas revisar (por ejemplo cache:www.google.com) y como resultado obtendrás la versión cache de la página. Si en la versión cache aparecen muchos enlaces hacia sitios no deseados acompañados de palabras comerciales, es muy probable que tu sitio haya sido hackeado.

Otro operador muy útil para detectar si tu sitio se ha visto comprometido es el operador "site:" el cual restringe los resultados de acuerdo al dominio especificado. Puedes combinar este operador con una consulta no relacionada con tu sitio, por ejemplo site:http://example.com viagra or site:example.com cialis. Si tu sitio no tiene ningún contenido relacionado con fármacos y esta consulta te devuelve resultados, de nuevo es probable que tu sitio haya sido hackeado. Ahora, si tienes una cuenta de Herramientas para webmasters, puedes mirar cuáles son las palabras principales por las que tu sitio aparece en los resultados de búsqueda y recibir potenciales notificaciones en el Centro de mensajes.

Mi sitio ha sido hackeado ¿y ahora qué hago?

Una vez has identificado que tu sitio web ha sido atacado, lo más importante es implementar las medidas necesarias tanto para corregir el problema como para evitar que ocurra nuevamente. En enero pasado publicamos en este blog una entrada sobre cómo puedes corregir el problema. En resumidas cuentas, consiste en desactivar el sitio mientras se implementan los correctivos (devolviendo una respuesta 503), buscar qué archivos se han visto comprometidos y revertirlos a su estado original, eliminar los directorios o páginas creadas por el hacker, actualizar las últimas versiones del sistema de gestión de contenidos, cambiar las contraseñas y, si fuera necesario, utilizar la herramienta de solicitud de eliminación de URL.

Finalmente, si el hacker modificó tu sitio incluyendo código que viola nuestras Directrices para webmasters, una vez se haya solucionado el problema, puedes solicitar la reconsideración de tu sitio desde las Herramientas para webmasters.

Esperamos que esta entrada sea útil para los webmasters latinoamericanos que administran sitios que pueden ser o que han sido víctimas del hacking. Si tienes cualquier comentario no dudes en dejarlo aquí o enviar la pregunta a nuestro Foro de ayuda para los webmasters.



viernes, 17 de abril de 2009

La búsqueda se hace un hueco en la conferencia para desarrolladores Google I/O

Queremos comentaros que los días 27 y 28 de mayo de 2009 se celebrará el Google I/O [inglés], un evento para desarrolladores que tendrá lugar en San Francisco y quizás sea de vuestro interés, especialmente para todos aquellos webmasters que residan o se encuentren en Estados Unidos en esas fechas.



Esta conferencia para desarrolladores tiene la intención de crear un espacio relacionado con las aplicaciones web, utilizando Google y las tecnologías open web. Así que recordamos este interesante evento a todos aquellos que tengan interés en temas como AJAX y JavaScript, Maps y Geo, aplicaciones sociales, APIs y herramientas o aplicaciones móviles, etc.

Durante estos dos días se realizarán diferentes sesiones para exponer las últimas novedades, con turno de preguntas y respuestas incluido. Y cómo no, también habrá un espacio para hablar de resultados de búsqueda. Por ejemplo, podréis encontrar sesiones como "Search Friendly Development" (algo así como "desarrollo compatible con la búsqueda") por Maile Ohye, ingeniera de Google, donde podréis aprender técnicas para atraer más usuarios a vuestros sitios mediante el tráfico de los motores de búsqueda. O la sesión "Site review by the experts" por Matt Cutts [inglés], ingeniero de Google, donde tendréis la oportunidad de que los expertos revisen vuestros sitios, con la intención de tratar problemas reales que afectan a los desarolladores a la hora de optimizar aplicaciones para la búsqueda.

Aquí tenéis el programa [inglés], por si queréis echarle un vistazo más detalladamente. Y para esos webmasters interesados, no os perdáis el descuento [inglés] en la entrada si os registráis antes del 1 de mayo. O, si estáis relacionados con el mundo académico, tendréis un precio más que especial.

Esperamos que alguno de vosotros pueda asistir y que nos contéis cómo os fue. ¡No olvidéis volver y dejar vuestros comentarios sobre la conferencia!



miércoles, 15 de abril de 2009

Dos nuevas mejoras en las páginas de resultados de Google

Hemos desarrollado dos nuevas mejoras para la Búsqueda de Google. La primera de ellas ofrece una amplia lista de búsquedas relacionadas y útiles. Y la segunda se trata de la adición de descripciones más extensas en los resultados de búsqueda. Las dos intentan guiar a los usuarios de una manera más eficaz hacia la información que necesitan.

Búsquedas más refinadas

Hemos lanzado una nueva tecnología para entender mejor las asociaciones y los conceptos relacionados con tus búsquedas, y una de las primeras aplicaciones nos permite ofrecerte búsquedas relacionadas aún más útiles (los términos que se encuentran en la parte inferior y, a veces, en la parte superior de la página de resultados de búsqueda).

Por ejemplo, si buscas [principles of physics] (principios de la física), nuestros algoritmos entienden que "angular momentum," "special relativity," "big bang" y "quantum mechanic" son términos relacionados que pueden ayudarte a encontrar lo que necesitas. He aquí un ejemplo (haz clic en las imágenes para verlas más grandes):




Veamos un par de ejemplos en otros idiomas. En ruso, para la consulta [гадание на картах] (predicción de futuro con cartas), los algoritmos encuentran los términos relacionados "таро" (tarot), "ленорман" (lenormand) y "тибетское гадание мо" (adivinación tibetana). En italiano, si buscas [surf alle canarie] (surf en las Islas Canarias), ahora se nos ofrecen sugerencias basadas en tres de las islas más famosas de las Canarias: "lanzarote," "gran canaria," y "fuerteventura":



Ahora somos capaces de dirigir más consultas, más idiomas, y hacer más relevantes nuestras sugerencias con respecto a lo que realmente quieres saber. Además, ahora también ofrecemos mejoras para consultas de cierta extensión, algo que suele ser una tarea difícil. Podrás ver nuestra nuevas búsquedas relacionadas en 37 idiomas en todo el mundo.

Y hablando de consultas largas, esto nos lleva a comentar nuestra siguente mejora ...

Descripciones más largas


Cuando realizas una búsqueda en Google, cada uno de los resultados tiene un título de color azul oscuro al que le siguen unas cuantas líneas de texto (lo que llamamos "descripción"), que dan una idea del contenido de cada página. Para dar más contexto, las palabras de tu búsqueda aparecen destacadas en negrita.

Si se realiza una búsqueda con más de tres palabras, las descripciones con una longitud estándar no te darían suficiente información ni suficiente contexto. En una situación así, el hecho de aumentar el número de líneas de la descripción proporciona más información ya que se muestran más palabras en el contexto de la página. Ofrecemos un par de ejemplos a continuación:

Supongamos que estás buscando información acerca de la rotación de la Tierra alrededor del sol, y, concretamente, querías saber sobre la inclinación y la distancia con respecto al sol. Así que escribes todo esto en Google: [earth's rotation axis tilt and distance from sun] (inclinación del eje de rotación de la tierra y distancia del sol). Una descripción de longitud estándar no sería capaz de mostrar todas esas palabras en contexto, pero ahora con las nuevas descripciones puedes estar seguro de que el primer resultado se referirá a todos estos temas. Además, la línea adicional en la descripción del tercer resultado muestra la palabra "sol" en su contexto, lo que sugiere que la página no habla de la distancia de la Tierra del sol:



Del mismo modo, si estás buscando críticas de restaurantes que hablen de un menú completo, las descripciones más largas también pueden ayudarte:



¡Pruébalo tú mismo con una consulta de varias palabras!

Estos son sólo dos ejemplos de mejoras que hemos realizado. Buscamos constantemente maneras de llegar lo antes posible a la página web que deseas. Incluso si no te das cuenta de todos los cambios, podéis estar seguros de que estamos trabajando duro para ofrecer la mejor calidad posible en tu experiencia de búsqueda.



jueves, 9 de abril de 2009

Ayuda para que tu sitio se muestre bien en Google Chrome

Desde que lanzamos Google Chrome el pasado septiembre, hemos recibido un cierto número de preguntas de webmasters y desarrolladores web sobre cómo hacer que sus sitios web se muestren bien en Google Chrome. Las preguntas fueron muy perspicaces y esclarecedoras para el equipo de Google Chrome, y ahora yo quiero responder con algunos trucos que harán que tu sitio web brille en Google Chrome.

Detectando Google Chrome

La mayoría de sitios se renderizan igual tanto en Safari como en Google Chrome, porque ambos son navegadores basados en WebKit [inglés]. Si tu sitio se muestra bien en Safari, entonces debería mostrarse también bien en Google Chrome.

Teniendo en cuenta que Chrome es bastante nuevo, muchos sitios web confunden Google Chrome con otro navegador. Si tu sitio web no se muestra bien en Chrome pero sí en Safari, es posible que tu sitio no reconozca la cadena de caracteres del agente de usuario (user-agent string) de Chrome.

Según las plataformas y navegadores van utilizando WebKit como su motor de renderizado, tu sitio web puede detectarlos y darles soporte automáticamente usando JavaScripts. Normalmente las páginas web usan JavaScript para “olfatear” la propiedad navigator.userAgent para Chrome o Safari, pero deberías usar el Object detection [inglés] correcto si es posible. De hecho, Gmail detectó correctamente Webkit en Chrome desde el principio.

Si tienes que detectar el tipo de agente de usuario, puedes usar este simple JavaScript para detectar WebKit:

var isWebkit =
navigator.userAgent.indexOf("AppleWebKit") > -1;


o quieres comprobar qué versión tienes de Webkit, porque lo que tú quieres es la última versión:

var webkitVersion =
parseFloat(navigator.userAgent.split("AppleWebKit/")[1]) ||
undefined;
if (webkitVersion && webkitVersion > 500 ) {
// use spiffy WebKit feature here
}


Te dejamos aquí algunas versiones de navegadores y la versión de WebKit que ellos envían:



No recomendamos añadir "Google" o "Apple" a tus navigator.vendor para detectar WebKit o Google Chrome, ya que éste no detectará otros WebKit o navegadores basados en Chrome.

Puedes encontrar más información sobre cómo detectar WebKit en webkit.org [inglés].

Otros consejos útiles:
  • Google Chrome no da soporte a los plug-ins ActiveX, pero sí lo da para los plug-ins NPAPI. Esto significa que puedes mostrar los plug-ins de contenido como Flash y Java en Google Chrome de la misma forma que lo haces para Firefox y Safari.
  • Si el texto de tu sitio aparece un poco mal, asegúrate de que ofreces el tipo de contenido adecuado y la información de codificación de caracteres en los encabezados de respuesta http, es decir, al principio de tus páginas, preferiblemente cerca del comienzo de la sección <head>.
  • No pongas elementos bloque dentro de elementos inline.
Mal: <a><div>This will look wrong.</div></a>

Bien: <div><a>This will look right!</a></div>
  • Si tu JavaScript no funciona en Google Chrome, puedes depurarlo usando el Depurador de JavaScript de Chrome, que se encuentra en el menú "página" -> Opciones para desarrolladores -> Depurar JavaScript.

Para ayudar a webmasters y a desarrolladores web a encontrar más respuestas, hemos creado un Centro de ayuda [inglés] y un foro [inglés] para dar respuesta a vuestras preguntas. Por supuesto, si encuentras algo que crees que es un error en Chrome, por favor, háznoslo saber.

¡Ayúdanos a mejorar Google Chrome!

Si quieres ayudar incluso más, estamos buscando webmasters que estén interesados en permitir a Google usar sus sitios para comparar nuestras mediciones internas de compatibilidad y rendimiento. Si estas interesado en comparar el desarrollo optimizado de Google Chrome contra la versión cache de tu sitio web, por favor contáctanos para más información a través de chrome-webmasters@google.com.

Sigue enviándonos más opiniones y seguiremos trabajando para mejorar Google Chrome.



martes, 7 de abril de 2009

Más herramientas disponibles con un solo clic

El pasado mes de Julio, lanzamos nuestro programa de acceso a las herramientas para webmasters para proveedores de Internet [inglés] y ha sido un gran éxito. Cientos de proveedores de Internet se han registrado y miles de usuarios tienen ahora acceso a las Herramientas para webmasters de Google a través del panel de sus proveedores.

Hoy, lanzamos el programa de acceso a proveedores de los servicios de Google para páginas web [inglés], el cual permite ofrecer las siguientes características a los dueños de sitios web:
  • Mejorar sus sitios web con Google búsqueda personalizada o Google Site search
  • Sacarles provecho económico con Adsense
  • Optimizarlos para la búsqueda con las Herramientas para webmasters




¿Cómo puedes apuntarte a esto?


Webmasters: Estad atentos, a ver si vuestro proveedor se registra en este programa, y así la próxima vez que entres a gestionar tu sitio web, tendrás todo listo para ti. O aún mejor, envía a tu proveedor un enlace a este artículo y dile que estamos aquí para ayudarles a ellos a que te ayuden.

Proveedores: Entrad al sitio Servicios de Google para sitios web [inglés] y ¡registraos hoy!

Y, en caso de que te lo preguntes, los proveedores que ya se habían registrado en el programa para proveedores de acceso a las Herramientas para webmasters serán actualizados al nuevo programa de manera automática.

Por otra parte, los desarrolladores no deben preocuparse: la parte final (el back-end) de las APIs de las Herramientas para webmasters permanece sin cambios.



viernes, 3 de abril de 2009