Archivos

Cómo usar el marcado schema.org para vídeos


Los vídeos son uno de los tipos de resultados más habituales de Google, por lo que queremos asegurarnos de que tus vídeos se indexen correctamente. A partir de ahora admitimos el marcado schema.org para los vídeos. El sitio schema.org es fruto de la colaboración entre Google, Microsoft, Yahoo! y Yandex, y ahora es el formato recomendado para describir vídeos en Internet. Se trata de un marcado muy sencillo que se puede añadir fácilmente a la mayoría de los sitios web.

Se puede incluir el marcado schema.org para vídeos de la misma forma que se añade cualquier otro atributo de schema.org. Solo tienes que definir un atributo itemscope y un atributo itemtype="http://schema.org/VideoObject" y asegurarte de especificar las propiedades de nombre, de descripción y de thumbnailUrl (URL de imagen en miniatura). También deberás definir la embedURL (ubicación del reproductor de vídeo), o la contentURL (ubicación del archivo de vídeo). El marcado normal de un reproductor de vídeo puede tener este aspecto:

<div itemscope itemtype="http://schema.org/VideoObject">
 <h2>Vídeo: <span itemprop="name">Título</span></h2>
 <meta itemprop="duration" content="T1M33S" />
 <meta itemprop="thumbnailUrl" content="thumbnail.jpg" />
 <meta itemprop="embedURL" content="http://www.example.com/videoplayer.swf?video=123" />
 <object ...>
   <embed type="application/x-shockwave-flash" ...>
 </object>
 <span itemprop="description">Descripción del vídeo</span>
</div>


Puedes usar el marcado schema.org sin que se vean afectados ni los sitemaps de vídeos ni los feeds mRSS que estés utilizando. De hecho, te recomendamos que utilices también un sitemap de vídeos, ya que nos avisa más rápido de cualquier videos nuevos o actualizados, y ofrece funcionalidades avanzadas tales como las restricciones de países o plataforma.

Como ahora hay varios métodos disponibles para informar a Google de tus vídeos, seleccionar el formato adecuado puede parecer difícil. Así pues, para que el proceso de indexación de los vídeos sea lo más sencillo posible, hemos reunido una serie de vídeos y artículos relacionados con este proceso en el nuevo micrositio de Webmasters EDU.

Para obtener más información, consulta los artículos de vídeo de Webmasters EDU, lee la especificación completa del objeto "VideoObject" de schema.org o publica tus preguntas en el foro de ayuda para webmasters. Esperamos ver más de tu contenido de vídeo en la Búsqueda de Google.

Por Henry Zhang, director de producto. Editado y publicado por Miguel Silva Rodrigues.

Presentación de Googlebot-Mobile de smartphones

El número de usuarios de smartphones crece rápidamente y cada vez son más los sitios web que ofrecen contenido diseñado específicamente para este tipo de dispositivos. Hoy estamos encantados de anunciar que ahora Googlebot-Mobile utiliza un user-agent de smartphones además de los user-agents anteriores de teléfonos tradicionales para rastrear contenido. De esta forma, podemos aumentar nuestra cobertura de contenido de smartphones y ofrecer una mejor experiencia de búsqueda a los usuarios de este tipo de dispositivos. A continuación, se indican las principales cadenas de user-agent que utiliza ahora Googlebot-Mobile.

  • Googlebot-Mobile de teléfonos tradicionales:
  • SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 
  • DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

  • Googlebot-Mobile de smartphones:
  • Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
El contenido que rastrea Googlebot-Mobile de smartphones se utilizará principalmente para mejorar la experiencia de usuario al realizar búsquedas móviles. Por ejemplo, el nuevo rastreador puede encontrar contenido optimizado específicamente para smartphones, así como redireccionamientos específicos para este tipo de dispositivos.

Asimismo, presentamos una nueva función que permite ignorar los redireccionamientos de las páginas optimizadas para smartphones y que utiliza estas indicaciones. Cuando encontramos una URL en los resultados de búsqueda que redirige a los usuarios de smartphones a otra URL con contenido optimizado para este tipo de dispositivos, modificamos el enlace que aparece en los resultados de búsqueda para que el usuario acceda directamente a la URL de destino final. De esta forma, se elimina la latencia adicional del redireccionamiento y permite ahorrar una media de entre 0,5 y 1 segundos al visitar la página de destino de esos resultados de búsqueda.

Los user-agents de Googlebot-Mobile se identifican a sí mismos como un tipo específico de dispositivo móvil. Por tanto, las solicitudes de Googlebot-Mobile deben recibir el mismo tratamiento que cualquier usuario con el mismo user-agent de teléfono. Tanto esta como otras directrices se describen en la entrada de blog anterior y aún se aplican, excepto las que se refieren a smartphones que se actualizan con esta información. Si tu sitio ha tratado a Googlebot-Mobile basándose en el hecho de que solo rastrea contenido con user-agents de teléfonos tradicionales, te recomendamos que revises esta política y que ofrezcas el contenido adecuado basado en el user-agent de Googlebot-Mobile, para que tanto el contenido destinado a teléfonos tradicionales como el que va destinado a los smartphones se indexe correctamente.

Si tienes más preguntas, no dudes en consultar en el  Foro de ayuda para webmasters.

Nuevo marcado para contenido multilingüe

Muchos sitios web se dirigen a usuarios de todo el mundo. Existen varias formas de ofrecer un contenido adaptado al idioma o a la región de los usuarios. El año pasado ofrecimos la posibilidad de añadir anotaciones explícitas a páginas web que mostraran el mismo contenido con varias plantillas de idioma.

Hoy damos un paso más y mejoramos la gestión del contenido multilingüe en estos dos casos:
  • En sitios web que se orienten a varias regiones y que usen prácticamente el mismo contenido (por ejemplo, páginas web en inglés que se orienten a Australia, a Canadá y a EE.UU. y que solo se diferencien en los precios)
  • En sitios web orientados a varias regiones que incluyan contenido completamente traducido o que muestren un contenido monolingüe con diferencias notables enfocado a varias regiones (por ejemplo, la página web de un producto en alemán, en francés y en inglés).

Cómo especificar el idioma y la ubicación

Hemos ampliado la compatibilidad del elemento de enlace rel="alternate" hreflang para gestionar el contenido que esté traducido o adaptado a varias regiones geográficas. El atributo hreflang permite especificar el idioma u, optativamente, el país, así como URL de contenido equivalente. Las URL alternativas nos permiten consolidar los indicadores de estas páginas y ofrecer la URL adecuada a los usuarios que hagan una búsqueda. Estas URL pueden pertenecer al mismo sitio o a otro dominio.

Cómo anotar páginas con un contenido prácticamente idéntico

En lo que respecta a las páginas que tengan un contenido prácticamente idéntico en el mismo idioma y que se orienten a varios países, también puedes usar el elemento de enlace rel="canonical" para indicar la versión preferida. Este indicador nos permitirá dar prioridad a esa versión en la Búsqueda y mostrar las URL locales a los usuarios cuando sea conveniente. Por ejemplo, podrías usar este elemento de enlace si tienes una página de producto en alemán y quieres orientarla a usuarios que hagan búsquedas en los sitios de Google de Alemania, de Austria y de Suiza de forma específica.

Ejemplo de uso

Para explicar el funcionamiento del elemento, usaremos las siguientes URL de ejemplo:
  • http://www.example.com/ (URL de la página principal general de un sitio web que está en español),
  • http://es-es.example.com/ (URL de la versión en español para los usuarios de España),
  • http://es-mx.example.com/ (URL de la versión en español para los usuarios de México),
  • http://en.example.com/ (URL de la versión en inglés genérico).
En todas estas páginas, podríamos usar los siguientes marcados para especificar el idioma y, en su caso, la región:

<link rel="alternate" hreflang="es" href="http://www.example.com/" />
<link rel="alternate" hreflang="es-ES" href="http://es-es.example.com/" />
<link rel="alternate" hreflang="es-MX" href="http://es-mx.example.com/" />
<link rel="alternate" hreflang="en" href="http://en.example.com/" />

Si incluyes una subetiqueta regional, lo interpretaremos como que quieres orientar la página a la región especificada.

Ten en cuenta que todas estas anotaciones se deben usar en cada URL. Procura usar URL específicas para ambos elementos de enlace en lugar de la correspondiente a la página principal.

Asistencia adicional

Como siempre, si necesitas ayuda adicional para implementar sitios web multilingües u orientados a varias regiones, consulta el artículo del Centro de asistencia sobre este tema o publica tu consulta en el Foro de ayuda para webmasters.

Paginación con rel="next" y rel="prev"

De forma similar a como rel=”canonical” indica claramente el contenido duplicado, ahora puedes utilizar los elementos de vinculación HTML rel="next" y rel="prev" [inglés] para indicar la relación entre las direcciones URL de los componentes de una serie paginada. En un sitio web, una serie paginada de contenido puede tener muchas formas, desde un artículo dividido en varias páginas de componentes, hasta una categoría de productos con elementos repartidos a lo largo de varias páginas o un hilo de un foro dividido en una secuencia de direcciones URL. Ahora, si incluyes los elementos de marcado rel="next" y rel="prev" en las páginas de los componentes de una serie, estarás indicando a Google claramente que quieres que:
  • Consolidemos las propiedades de indexación, como los enlaces, desde las direcciones URL o las páginas de los componentes hasta la serie como conjunto (es decir, que los enlaces no deben estar dispersos entre página-1.html, página-2.html, etc., sino que deben estar agrupados con la secuencia).
  • Enviemos a los usuarios a la página o a la URL más relevante, normalmente la primera página de la serie.
Ahora es posible indicar a Google la relación entre las URL de los componentes de una serie mediante rel="next" y rel="prev".

Existe una excepción en la implementación de rel="prev" y rel="next": si a lo largo de la serie de contenido también ofreces a los usuarios una página que muestre todo el contenido o si estás considerando incluir una, consulta esta entrada del blog para obtener más información. Los usuarios suelen preferir las páginas en las que puedan ver todo el contenido, por lo que tratamos de incluir estas páginas en los resultados de las búsquedas en lugar de las páginas de componentes (las páginas de componentes tienen más opciones de aparecer en los resultados si incluyen rel="next" y rel="prev").

Si no dispones de una página que incluya todo el contenido o quieres evitar que Google la muestre, puedes utilizar rel="next" y rel="prev" como se describe en esta entrada.


Para obtener información sobre configuraciones paginadas que incluyan una página que muestre todo el contenido, consulta esta entrada del blog.

Opciones disponibles

Si tienes una serie, dispones de tres opciones:
  1. Deja lo que tienes exactamente como está. Existe contenido paginado por toda La Web y seguiremos intentando ofrecer a los usuarios el mejor resultado, independientemente de si se han incluido o no los elementos de marcado HTML rel="next" y rel="prev".
  2. Si dispones de una página donde se muestra todo el contenido, o si estás considerando incluir una, consulta esta entrada del blog.
  3. Indica a Google la relación entre las URL de los componentes de tu serie con rel="next" y rel="prev". Esto nos ayudará a indexar tu contenido de una forma más precisa y a mostrar a los usuarios la página más relevante (normalmente la primera). A continuación te indicamos de forma detallada cómo implementar estos elementos.
Implementación de rel="next" y rel="prev"

Si optas por la opción 3 para tu sitio, a continuación te explicamos cómo hacerlo. Supongamos que tienes contenido paginado en estas direcciones URL:

http://www.example.com/article?story=abc&page=1
http://www.example.com/article?story=abc&page=2
http://www.example.com/article?story=abc&page=3
http://www.example.com/article?story=abc&page=4

En la primera página, http://www.example.com/article?story=abc&page=1, se incluye la sección <head>:
<link rel="next" href="http://www.example.com/article?story=abc&page=2" />

En la segunda página, http://www.example.com/article?story=abc&page=2:
<link rel="prev" href="http://www.example.com/article?story=abc&page=1" />
<link rel="next" href="http://www.example.com/article?story=abc&page=3" />

En la tercera página, http://www.example.com/article?story=abc&page=3:
<link rel="prev" href="http://www.example.com/article?story=abc&page=2" />
<link rel="next" href="http://www.example.com/article?story=abc&page=4" />

Y en la última página, http://www.example.com/article?story=abc&page=4:
<link rel="prev" href="http://www.example.com/article?story=abc&page=3" />

Varios puntos que hay que mencionar:
  • La primera página solo contiene el elemento de marcado rel="next", no rel="prev".
  • Las páginas comprendidas entre la segunda y la penúltima deben disponer de vinculación doble con rel="next" y rel="prev".
  • La última página solo contiene el elemento de marcado rel="prev", no rel="next".
  • Los valores de rel="next" y rel="prev" pueden ser URL relativas o absolutas (según permita la etiqueta <link>). Y si se incluye un enlace <base> en el documento, las rutas relativas se resolverán según la URL base.
  • Solo es necesario declarar rel="next" y rel="prev" en la sección <head>, no en el documento <body>. Se permite el uso de rel="previous" como variante sintáctica de los enlaces rel="prev".
  • rel="next" y rel="previous" por un lado y rel="canonical" por otro constituyen conceptos independientes.
  • Se pueden incluir ambas declaraciones en la misma página. Por ejemplo, http://www.example.com/article?story=abc&page=2&sessionid=123 puede contener:
<link rel="canonical" href="http://www.example.com/article?story=abc&page=2”/><link rel="prev" href="http://www.example.com/article?story=abc&page=1&sessionid=123" /><link rel="next" href="http://www.example.com/article?story=abc&page=3&sessionid=123" />
  • rel=”prev” y rel=”next” actúan como sugerencias para Google, no como directivas absolutas.
  • Si se implementan de forma incorrecta, por ejemplo, si se omite una designación rel="prev" o rel="next" en la serie, seguiremos indexando las páginas y nos basaremos en nuestra heurística para comprender el contenido.
¿Alguna pregunta?

Si necesitas más información, consulta el Centro de asistencia o únete a la conversación en el Foro de ayuda para webmasters.

Benjia Li y Joachim Kupke, Ingenieros de software del equipo de indexación

Visualización de todo el contenido en los resultados de búsqueda

Gracias a las pruebas que hacemos con los usuarios, hemos detectado que los usuarios que realizan búsquedas prefieren ver todo el contenido en una sola página en lugar de que se muestren páginas de componentes que incluyen únicamente una parte de la información con saltos de página arbitrarios (y que les obligan a hacer clic en "Siguiente" y a cargar otra URL).

Con frecuencia, los usuarios que realizan búsquedas prefieren ver todo el contenido en lugar de que este aparezca paginado con saltos arbitrarios y un mayor tiempo de espera.

Por tanto, para mejorar la experiencia de usuario, nos estamos esforzando por mostrar versiones de una sola página en los resultados de búsqueda cuando detectamos que una serie de contenido (por ejemplo, página-1.html, página-2.html, etc.) también incluye una versión de una sola página (por ejemplo, página-todas.html). Si tu sitio ofrece la posibilidad de ver todo el contenido, no es necesario que hagas nada; nosotros haremos el trabajo por ti. Además, consolidaremos las propiedades de indexación de las páginas de componentes de la serie como, por ejemplo, los enlaces, en la página de visualización de todo el contenido.

No obstante, la visualización de todo el contenido puede ser poco recomendable si el tiempo de espera es elevado

No deja de ser interesante que los usuarios no mostraran preferencia por la página de visualización de todo el contenido si esta conllevaba un mayor tiempo de espera (por ejemplo, páginas de visualización de todo el contenido que tardaran más en cargarse por contener muchas imágenes). Esta situación tiene una razón de ser, ya que los usuarios suelen sentirse menos satisfechos cuando los resultados son lentos [inglés]. Así pues, a pesar de que normalmente se prefieren las páginas de visualización de todo el contenido, es importante que los webmasters hallen el equilibrio entre esta preferencia y el tiempo de carga de la página y la experiencia de usuario en general.

Prácticas recomendadas relacionadas con las series de contenido
1. Si tu sitio incluye páginas de visualización de todo el contenido:
Intentaremos detectar la versión de visualización de todo tu contenido y las páginas de componentes asociadas, si hay alguna disponible. No es necesario que hagas nada más. Sin embargo, puedes incluir etiquetas rel="canonical" que dirijan a la página de visualización de todo el contenido en las páginas de componentes para que resulte más explícito y para que haya más probabilidades de que detectemos la serie de páginas correctamente.


La etiqueta rel="canonical" permite especificar el superconjunto de contenido (es decir, la página de visualización de todo el contenido, en este caso página-todas.html) de la misma información en una serie de URL.

¿En qué se basa su funcionamiento?
Como se ve en el diagrama, se puede especificar que la URL canónica de la page-2.html es page-all.html, ya que esta URL es un superconjunto del contenido de page-2.html. Si un usuario busca un término de consulta y selecciona page-all.html en los resultados de búsqueda, aunque su consulta esté principalmente relacionada con la información de page-2.html, sabemos que el usuario podrá consultar la información relevante de page-2.html en page-all.html.
No obstante, page-1.html no debería ser la URL canónica designada de page-2.html, ya que el contenido de la segunda no está incluido en la primera. La consulta de búsqueda de un usuario puede hacer referencia al contenido incluido en page-2.html, por lo que al seleccionar page-1.html en los resultados de búsqueda, si esta se ha configurado como página canónica de page-2.html, el usuario puede verse obligado a continuar navegando para acceder a la página en la que se encuentra la información deseada. Esta experiencia será negativa para el usuario, ya que el resultado de Google distará de ser óptimo, y es posible que el tráfico de orientación de tu sitio sea mediocre.
Sin embargo, si estás seguro de que no quieres que la página de visualización de todo tu contenido aparezca en los resultados de búsqueda, debes realizar lo siguiente: 1) asegurarte de que las páginas de componentes de la serie no incluyan una etiqueta rel="canonical" que dirija a la página de visualización de todo el contenido y 2) utilizar uno de los métodos habituales para marcar la página de visualización de todo el contenido como "noindex".
2. Si quieres que se muestren páginas de componentes individuales (o si no hay ninguna versión que muestre todo el contenido disponible):
Puede darse el caso de que tu sitio se encuentre en una de las situaciones que se indican a continuación, si no en ambas.
  • No es recomendable que la página de visualización de todo el contenido aparezca en los resultados de búsqueda, debido a que el tiempo de carga es demasiado elevado o a que dificulta la navegación para los usuarios. 
  • Los usuarios de tu sitio prefieren navegar por varias páginas y acceder a una página de componentes a través de los resultados de búsqueda en lugar de ver una página de visualización de todo el contenido.
En tales situaciones, puedes utilizar los elementos HTML rel="next" y rel="prev" estándares para especificar la relación entre las páginas de componentes de la serie de contenido. Si se utilizan correctamente, Google tratará de realizar lo siguiente en la mayoría de los casos:
  • Consolidar las propiedades de indexación (por ejemplo, los enlaces) de las URL o de las páginas de componentes.
  • Dirigir a los usuarios a la página o a la URL de las páginas de componentes que sea más relevante. Por lo general, la primera página del contenido suele ser la más relevante, pero nuestros algoritmos pueden dirigir a los usuarios a una de las páginas de componentes de la serie.
Con frecuencia, los webmasters utilizan la etiqueta rel="canonical" incorrectamente para dirigir a los usuarios que accedan a las páginas de componentes a la primera página de su serie (por ejemplo, incluyen una etiqueta rel="canonical" que dirige a página-1.html en página-2.html). Esta implementación no es recomendable, ya que las páginas de componentes no incluyen contenido duplicado. Lo más adecuado es utilizar las etiquetas rel="next" y rel="prev".

Resumen

Debido a que los usuarios suelen preferir que la opción disponible en los resultados de búsqueda sea la visualización de todo el contenido, nos estamos esforzando por detectar esta versión correctamente para mostrársela a los usuarios que realicen búsquedas. Si tienes una serie de contenido, no es necesario que hagas nada más. Sin embargo, puedes ayudar a que Google muestre mejor tu información a los usuarios realizando lo siguiente:

  1. Para optimizar la página de visualización de todo el contenido, puedes incluir etiquetas rel="canonical" que dirijan a la versión de una sola página en las páginas de componentes.
  2. Si la página de visualización de todo el contenido de tu sitio empeora la experiencia de usuario, puedes utilizar los atributos rel="next" y rel="prev" para ayudar a que Google identifique la serie de páginas y muestre una página de componentes en los resultados.
¿Alguna pregunta?

Como siempre, puedes publicar tu pregunta en el Foro de ayuda para webmasters.

Solicitudes GET y POST y cómo mostrar de forma segura más información de la Web

A medida que evoluciona la Web, las capacidades de rastreo e indexación de Google también deben progresar. Hemos mejorado la indexación de Flash, hemos creado una infraestructura más sólida denominada Caffeine e, incluso, hemos empezado a rastrear formularios cuando lo consideramos oportuno. Ahora, especialmente con el aumento de la popularidad de JavaScript y, con él, AJAX, estamos encontrando cada vez más páginas web que requieren solicitudes POST, bien para todo el contenido de la página, bien porque a las páginas les falta información o porque parecen completamente dañadas sin los recursos que se obtienen a través de POST. Para la Búsqueda de Google esto no es lo ideal, debido a que si no descubrimos e indexamos contenido de forma adecuada, los usuarios no pueden acceder al conjunto de resultados más completo y relevante.

Normalmente, recomendamos utilizar GET para recuperar recursos necesarios para una página y este es, con diferencia, nuestro método de rastreo preferido. Hemos iniciado experimentos para reescribir las solicitudes POST como GET y, aunque este sistema es válido en algunos casos, frecuentemente el contenido que devuelve un servidor web para GET y para POST es completamente diferente. Además, existen razones de peso para utilizar POST (por ejemplo, a las solicitudes POST se les puede adjuntar una mayor cantidad de datos que a las solicitudes GET). Por ello, aunque las solicitudes GET siguen siendo mucho más habituales, para mostrar más contenido en la Web, es posible que ahora Googlebot ejecute solicitudes POST cuando lo consideremos seguro y apropiado.

Tomamos las precauciones necesarias para evitar que se lleven a cabo cualquier tipo de tarea en un sitio que pueda dar lugar a una acción no intencionada por parte del usuario. Nuestras solicitudes POST se utilizan fundamentalmente para rastrear recursos que las páginas solicitan de forma automática, imitando lo que visualizaría un usuario normal cuando abre una URL en su navegador. Esto evolucionará con el tiempo a medida que descubramos heurísticas más adecuadas, pero por el momento este es el sistema que estamos utilizando.

Analicemos algunas situaciones relacionadas con las solicitudes POST que demuestran de qué forma estamos mejorando nuestros procesos de rastreo e indexación para evolucionar con la Web.

Ejemplos de solicitudes POST de Googlebot
  • Cómo rastrear una página a través de un redireccionamiento POST
<html>
  <body onload="document.foo.submit();">
   <form name="foo" action="request.php" method="post">
    <input type="hidden" name="bar" value="234"/>
  </form>
 </body>
</html>
  • Cómo rastrear un recurso a través de la solicitud XMLHttpRequest de POST
En este ejemplo con instrucciones "paso a paso", mejoramos tanto la indexación de una página como la Vista previa instantánea de esta siguiendo la solicitud XMLHttpRequest automática generada a medida que se muestra la página. 
1. Google rastrea la URL, yummy-sundae.html.
2. Google comienza a indexar yummy-sundae.html y, como parte de este proceso, decide intentar mostrar la página para entender mejor su contenido o generar la Vista previa instantánea.
3. Durante la representación, yummy-sundae.html envía automáticamente una solicitud XMLHttpRequest de un recurso, hot-fudge-info.html, utilizando el método POST.
<html>
  <head>
    <title>Yummy Sundae</title>
    <script src="jquery.js"></script>
  </head>
  <body>
    This page is about a yummy sundae.
    <div id="content"></div>
    <script type="text/javascript">
      $(document).ready(function() {
        $.post('hot-fudge-info.html', function(data)         
          {$('#content').html(data);});
      });
    </script>
  </body>
</html>
4. La URL solicitada a través de POST, hot-fudge-info.html, se añade  junto con su carga útil de datos, a la cola de rastreo de Googlebot.
5. Googlebot ejecuta una solicitud POST para rastrear hot-fudge-info.html.
6. Ahora, Google tiene una representación exacta de yummy-sundae.html para la Vista previa instantánea. En algunos casos, también podemos incorporar el contenido de hot-fudge-info.html a yummy-sundae.html.
7. Google completa la indexación de yummy-sundae.html.
8. El usuario busca [hot fudge sundae].
9. Ahora, los algoritmos de Google pueden determinar de forma más adecuada la relevancia de yummy-sundae.html para esta consulta y pueden mostrar correctamente una captura de pantalla de la página para la Vista previa instantánea.
Cómo mejorar la capacidad de rastreo e indexación de tu sitio
En nuestro Centro de asistencia podrás encontrar consejos generales para crear sitios que se puedan rastrear. Para los webmasters que quieran ayudar a Google a rastrear e indexar su contenido o a generar la Vista previa instantánea, a continuación proporcionamos algunas indicaciones sencillas que se deben recordar:
  • Utiliza GET para recuperar recursos a menos que tengas un motivo concreto para utilizar POST.
  • Asegúrate de que Google pueda rastrear los recursos necesarios para la presentación de tu página. En el ejemplo anterior, si robots.txt no permite acceder a hot-fudge-info.html, Googlebot no podrá recuperar la página. De forma más específica, si el código de JavaScript que inicia la solicitud XMLHttpRequest se encuentra en un archivo .js externo al que robots.txt no permite el acceso, no podremos encontrar la relación entre yummy-sundae.html y hot-fudge-info.html; por tanto, aunque se pueda acceder a esta última URL, esto tampoco nos sirve de mucha ayuda. Hemos visto cadenas de dependencias aún más complicadas en la Web. Para ayudar a Google a entender mejor tu sitio, casi siempre es mejor permitir que Googlebot rastree todos los recursos.
Puedes probar si los recursos están bloqueados en las Herramientas para webmasters  mediante las opciones "Labs -> Vista previa instantánea".
  • Asegúrate de enviar el contenido a Googlebot tal y como lo muestre el navegador web del usuario. El encubrimiento (técnica consistente en enviar a Googlebot contenido diferente del que se muestra al usuario) constituye una infracción de nuestras Directrices para webmasters ya que, entre otras cosas, puede hacer que proporcionemos un resultado irrelevante al usuario (el contenido que el usuario visualiza en su navegador puede ser totalmente distinto del que hemos rastreado e indexado nosotros). Hemos visto numerosos ejemplos de solicitudes POST en las que los webmasters habían encubierto contenido sin querer (lo que sigue siendo una infracción). Esos encubrimientos, incluso con los cambios más insignificantes, produjeron errores de JavaScript que impidieron indexar correctamente el sitio y acabaron por completo con la idea de utilizar el encubrimiento en primer lugar. En resumen, si quieres que tu sitio sea fácil de buscar, el encubrimiento provoca situaciones complicadas a nivel general que es mejor evitar.
Para verificar que no has encubierto contenido accidentalmente, puedes utilizar la Vista previa instantánea de las Herramientas para webmasters o probar a configurar la cadena del user-agent en tu navegador de la siguiente forma:
Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)
Tu sitio no debe mostrar un aspecto diferente después de esta modificación. Si ves una página en blanco o un error de JavaScript o si hay partes de la página que faltan o aparecen cambiadas, significa que algo está mal.
  • Recuerda que debes incluir el contenido importante (es decir, el contenido que quieres que se indexe) como texto. Este debe ser visible directamente en la página, sin que sea necesaria ninguna acción por parte del usuario para que se muestre. La mayoría de los motores de búsqueda se basan en texto y, generalmente, funcionan mejor con contenido basado en texto. Por nuestra parte, mejoramos continuamente nuestra capacidad de rastrear e indexar contenido publicado de diferentes formas, pero sigue siendo recomendable utilizar texto para la información importante.
Cómo controlar tu contenido
Si quieres evitar que tu contenido se rastree o se indexe para la Búsqueda Web de Google, el mejor método siguen siendo las directivas de robots.txt tradicionales. Para evitar que se realice una Vista previa instantánea de tus páginas, consulta las Preguntas frecuentes sobre la Vista previa instantánea [inglés] en las que se describen el user-agent "Google Web Preview" y la metaetiqueta "nosnippet".

Previsiones para el futuro
Continuaremos esforzándonos para aumentar la exhaustividad de nuestros procesos de indexación de forma que los usuarios puedan encontrar información más relevante. Asimismo, esperamos que nuestra capacidad de rastreo e indexación mejore y evolucione con el tiempo, al ritmo de la propia Web. Si tienes alguna duda o pregunta, ponte en contacto con nosotros.