Category

Resultados-de-busqueda

Archivos

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.

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

Read More

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.

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

Read More

Datos de consultas de búsqueda de vuestros sitios

El uso de la encriptación SSL en Internet ha ido aumentando a una gran velocidad [inglés]. Como parte de nuestro compromiso para proporcionar una experiencia online más segura, la búsqueda SSL en https://www.google.com se convertirá en la experiencia predeterminada para los usuarios que inicien sesión [inglés] en google.com.

 ¿Cómo afectará el cambio a los webmasters? Hoy en día, los sitios web a los que se accede a través de resultados de búsquedas orgánicas de http://www.google.com (que no utilizan SSL) pueden saber que el usuario hizo su búsqueda en google.com y ver la consulta realizada. (Técnicamente hablando, el navegador del usuario transfiere esta información a través del campo de remitente HTTP [inglés]). Sin embargo, los resultados de búsquedas orgánicas que utilizan SSL tan solo permiten que los sitios web sepan que el usuario ha hecho su búsqueda en google.com.

Los webmasters siguen teniendo acceso a una gran cantidad de datos de consultas de búsqueda de sus sitios mediante las Herramientas para webmasters de Google. En el caso de los sitios añadidos y verificados en las Herramientas para webmasters de Google, los webmasters pueden:

  • ver las 1.000 consultas diarias principales y las 1.000 páginas de destino principales de los últimos 30 días,
  • ver las impresiones, los clics, el porcentaje de clics (CTR) y la posición media en los resultados de búsqueda de cada consulta y comparar los resultados con los 30 días anteriores,
  • descargar estos datos en formato CSV.
Además, los usuarios de los informes de optimización de motores de búsqueda (SEO) de Google Analytics pueden acceder a los mismos datos sobre consultas de búsqueda que se encuentran disponibles en las Herramientas para webmaster de Google y utilizar sus completas funciones de generación de informes.

Seguiremos investigando nuevos sistemas para mejorar la forma en que aparecen los datos de las consultas de búsqueda en las Herramientas para webmasters de Google. Si tienes preguntas, comentarios o sugerencias, no dudes en participar en el foro de ayuda de las Herramientas para webmasters de Google.

Nota: Estos cambios se lanzaron el mes pasado, sin embargo creemos importante tener los detalles del cambio en nuestro blog para webmasters de habla hispana.


Publicado por Anthony Chavez, Product Manager

Read More

Información sobre la selección de URL entre dominios

A menudo se puede acceder a un determinado contenido a través de varias URL, aunque es posible que no todas ellas estén ubicadas en el mismo dominio. Un ejemplo habitual que hemos comentado a lo largo de los años está relacionado con la publicación del mismo contenido en varias URL, una incidencia que se conoce como "contenido duplicado". Cuando detectamos un grupo de páginas con contenido duplicado, Google utiliza algoritmos para seleccionar una URL representativa de ese contenido. Un grupo de páginas puede contener URL del mismo sitio o de sitios diferentes. Si la URL representativa procede de un grupo que contiene diferentes sitios, la selección se denomina "selección de URL de varios dominios". Para explicar este fenómeno de forma sencilla, si el grupo de URL contiene una URL del sitio "a.com" y otra del sitio "b.com" y nuestro algoritmo selecciona la URL de "b.com", es posible que la URL de "a.com" ya no aparezca en los resultados de búsqueda y se produzca un descenso en el tráfico de búsqueda.

Los webmasters pueden ejercer una gran influencia en las selecciones de nuestros algoritmos utilizando uno de los mecanismos admitidos actualmente para indicar la URL preferida (por ejemplo, a través del elemento rel="canonical" o de redireccionamientos 301). En la mayoría de los casos, las decisiones tomadas por nuestros algoritmos a este respecto reflejan de forma correcta la intención del webmaster. No obstante, en casos puntuales, también hemos observado que un gran número de webmasters no entendían por qué no se había seleccionado su URL y querían saber lo que podían hacer si consideraban que la selección no era correcta.

Para explicar de forma clara las decisiones a la hora de seleccionar URL de varios dominios, vamos a publicar nuevos mensajes de las Herramientas para webmasters de Google con la intención de informar a los webmasters cuando nuestros algoritmos seleccionen una URL externa en lugar de una dirección de su sitio web. La información detallada sobre el funcionamiento de estos mensajes está disponible en el artículo del Centro de asistencia sobre este tema. No obstante, en esta entrada de blog trataremos las diferentes situaciones en las que es posible que aparezca una selección de URL de varios dominios, así como los pasos que puedes seguir para solucionar las selecciones que consideres que no son correctas.

Causas habituales de la selección de URL de varios dominios

Existe un gran número de situaciones que pueden dar lugar a una selección de URL de varios dominios por parte de nuestros algoritmos.

En la mayoría de los casos, nuestros algoritmos seleccionan una URL en función de las indicaciones implementadas por el webmaster para influir en la decisión. Por ejemplo, un webmaster que siga nuestras directrices y prácticas recomendadas relacionadas con la transferencia de sitios web estará indicando de forma eficaz que las URL de su nuevo sitio web son las que prefiere que seleccione Google. Si vas a transferir tu sitio web y aparecen estos mensajes, puedes interpretarlos como una confirmación de que nuestros algoritmos han entendido tus indicaciones.

No obstante, normalmente somos testigos de las quejas de los webmasters cuando nuestros algoritmos seleccionan una URL no deseada. Si tu sitio web se ve afectado por una selección de URL de varios dominios que consideras incorrecta, es decir, si crees que no se han seguido tus indicaciones, puedes aplicar varias estrategias para solucionar la incidencia según el caso. A continuación, se indican algunos de los motivos habituales de la selección inesperada de URL de varios dominios que hemos detectado y la forma de solucionar esta incidencia.
  1. Contenido duplicado, incluidos sitios web multirregionales: solemos observar que los webmasters utilizan básicamente el mismo contenido en el mismo idioma en varios dominios, en algunas ocasiones de forma accidental y, en otras, para orientar geográficamente el contenido. Por ejemplo, es habitual que un webmaster configure el mismo sitio web en inglés en los sitios "example.com" y "example.net" o un sitio web en alemán que esté alojado en dominios "a.de", "a.at" y "a.ch".

    2. En función de tu sitio web y de los usuarios, puedes utilizar una de las técnicas de canonicalización admitidas actualmente para indicar a nuestros algoritmos las URL que quieras que se seleccionen. Consulta los siguientes artículos relacionados con este tema:
2. Errores de configuración: determinados tipos de configuraciones incorrectas pueden hacer que nuestros algoritmos tomen una decisión equivocada. A continuación, se indican algunos ejemplos de errores de configuración.
  1. Canonicalización incorrecta: el uso incorrecto de las técnicas de canonicalización que dirigen a URL ubicadas en un sitio web externo puede dar lugar a que nuestros algoritmos seleccionen las URL externas para que se muestren en los resultados de búsqueda. Hemos detectado este tipo de errores en sistemas de administración de contenido (CMS) configurados incorrectamente o en complementos de CMS instalados por el webmaster de forma inadecuada.

    Para resolver este tipo de situaciones, debes averiguar cómo erróneamente tu sitio web está indicando la preferencia de URL canónica (por ejemplo, a través del uso incorrecto de un elemento rel="canonical" o de un redireccionamiento 301) y solucionar el error.

  2. Servidores configurados de forma incorrecta: en ocasiones, detectamos errores de configuración de alojamiento en los que el contenido del sitio "a.com" se devuelve para URL ubicadas en "b.com". Algo similar ocurre cuando dos servidores web que no están relacionados devuelven páginas 404 leves que puede que no hayamos detectado como páginas de error. En ambas situaciones, podemos asumir que se ha devuelto el mismo contenido desde dos sitios diferentes, y es posible que nuestros algoritmos seleccionen de forma incorrecta la URL del sitio "a.com" como la URL canónica del sitio "b.com".

    En ese caso, deberás investigar la parte de la infraestructura de publicación de tu sitio web que no está configurada correctamente. Por ejemplo, es posible que tu servidor devuelva códigos de estado HTTP 200 (correcto) para páginas de error o que confunda solicitudes en diferentes dominios alojados en él. Una vez que hayas encontrado la causa principal de la incidencia, ponte en contacto con los administradores de tu servidor para corregir la configuración.
3. Ataques de sitios web malintencionados: algunos ataques hacia sitios web introducen código que puede dar lugar a una canonicalización no deseada. Por ejemplo, el código malintencionado puede hacer que el sitio web devuelva un redireccionamiento 301 HTTP o inserte un elemento de enlace rel="canonical" entre dominios en el encabezado HTTP o HTML <head> que dirija normalmente a una URL externa en la que se aloje el contenido malintencionado. En estos casos, nuestros algoritmos pueden seleccionar la URL malintencionada o con spam en lugar de la URL del sitio web afectado por el error.

En esta situación, te recomendamos que sigas nuestras sugerencias relacionadas con la limpieza de tu sitio y que envíes una solicitud de reconsideración de inclusión cuando hayas terminado. Para identificar ataques encubiertos, puedes utilizar la función Explorar como Googlebot de las Herramientas para webmasters de Google para ver el contenido de tu página de la misma forma que lo hace Googlebot.
En ocasiones puntuales, nuestros algoritmos pueden seleccionar una URL de un sitio externo que aloje tu contenido sin tu permiso. Si consideras que otro sitio está duplicando tu contenido infringiendo de esta forma la ley de derechos de autor, puedes ponerte en contacto con el host del sitio para solicitar la eliminación del contenido. Asimismo, puedes solicitar que Google elimine la página infractora de los resultados de búsqueda presentando una solicitud basada en la ley estadounidense de protección de los derechos de autor (Digital Millennium Copyright Act, DMCA).

Y, como siempre, si necesitas ayuda para identificar la causa de una decisión incorrecta o para saber cómo solucionar esta incidencia, puedes consultar el artículo del Centro de asistencia sobre este tema y publicar una pregunta en el Foro de ayuda para webmasters.

Publicado por , Webmaster Trends Analyst

Read More

 
 View New Entries