El Blog para Webmasters

Google mejora el algoritmo en el diseño de página

2012-01-25T10:39:00.000Z

(Publicado originariamente en Google Webmaster Central Blog, traducido y compartido aquí para todos nuestros webmasters)

Como parte de nuestro continuo esfuerzo por ayudaros a encontrar sitios web de calidad en los resultados de búsqueda, hemos realizado un cambio algorítmico que se centra específicamente en el diseño de una página web y en la cantidad de contenido que se ve en la página al hacer clic en un resultado.

Como hemos indicado en otras ocasiones [inglés], los usuarios se han quejado varias veces de que, al hacer clic en un resultado, era difícil encontrar el contenido en la página. Los usuarios quieren ver el contenido directamente sin tener que desplazarse por la página pasando por un montón de anuncios. Por eso, este cambio puede influir en los sitios que no tienen mucho contenido en la mitad superior de la página. Esto significa que, si un usuario hace clic en un sitio web y lo primero que ve no incluye mucho contenido y está dedicado en su mayor parte a anuncios, esto no es una buena experiencia para él. Este tipo de sitios puede que no se posicionen tan bien de ahora en adelante.

Sabemos que incluir anuncios en la mitad superior de la página es una práctica muy común para muchos sitios web (frecuentemente, estos anuncios dan buenos resultados y ayudan a los editores a rentabilizar el contenido online). Este cambio algorítmico no influye en los sitios que contienen una cantidad normal de anuncios en la mitad superior de la página sino principalmente en aquellos sitios que tienen una verdadera sobrecarga de anuncios ubicados en esta parte y que dificulta la localización del contenido real de la página. La mejora en el algoritmo influye en los sitios que tienen poco contenido o contenido no visible en la mitad superior de la página o en los sitios cuyo contenido relevante está oculto por anuncios de forma persistente.

Este cambio algorítmico se aplicará de una forma perceptible en menos del 1% de las búsquedas globales, lo que significa que, en menos de una de cada 100 búsquedas, un usuario estándar podría observar una reorganización de los resultados que aparecen en la página de búsqueda. Si crees que el cambio del algoritmo de diseño de página ha afectado a tu sitio web, piensa en cómo está organizado el espacio de la mitad superior de las páginas del sitio y si el contenido de las páginas está oculto o es difícil acceder a él por cualquier otro motivo. Puedes utilizar Browser Size, entre otras muchas herramientas, para ver el aspecto que podría tener tu sitio web con diferentes resoluciones de pantalla.

Si decides actualizar el diseño de la página, el algoritmo de diseño de página reflejará automáticamente los cambios cuando Google vuelva a rastrear y procesar un número de páginas del sitio que sea suficiente para evaluar los cambios. La duración de ese proceso dependerá de múltiples factores, entre los que se incluyen el número de páginas del sitio y el nivel de eficacia con el que Googlebot pueda rastrear el contenido. El tiempo de duración para un sitio web normal puede ser de varias semanas.

En general, nuestro consejo para los editores sigue siendo que se centren en ofrecer la mejor experiencia posible a los usuarios [inglés] en sus sitios web, no en mejoras algorítmicas específicas. Este cambio representa solo una de las más de 500 mejoras que esperamos llevar a cabo este año en las búsquedas. Como siempre, te agradecemos cualquier comentario o pregunta que quieras publicar en el Foro de ayuda para webmasters.

Publicado por Matt Cutts, ingeniero de software

Presentación de Googlebot-Mobile de smartphones

2011-12-26T09:00:00.000Z

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.

Publicado por Yoshikiyo Kato, ingeniero de software

Nuevo marcado para contenido multilingüe

2011-12-22T09:00:00.000Z

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.

Publicado por Christopher Semturs, ingeniero de software de infraestructura de búsquedas de Google Suiza

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

2011-12-21T09:00:00.000Z

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:

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".
Si dispones de una página donde se muestra todo el contenido, o si estás considerando incluir una, consulta esta entrada del blog.
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

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

2011-12-20T17:59:00.000Z

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:

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.
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

Vídeos de Matt Cutts: ¿Cómo asegurarte de que Google encuentra tu contenido original?

2011-12-09T16:29:00.001Z

Aunque este vídeo lleva ya un tiempo en nuestro canal para webmasters de Youtube, siempre es interesante conocer qué podemos hacer para que Google sepa de nuestro contenido original (y además con subtítulos en español).

Kunal Pradhan, el usuario que pregunta a Matt Cutts en este vídeo, plantea la situación de una página que no solo roba contenido, sino que además cambia la marca de tiempo. Sobre esto y algunos detalles más sobre el contenido nos habla Matt en este vídeo.

¿Cómo asegurarnos de que Google encuentra mi contenido original?

Transcripción de: "¿Cómo asegurarnos de que Google encuentra mi contenido original?"

La pregunta de hoy es de Kunal Pradhan. Por cierto que soy del oeste de Kentucky, así que disculpadme porque a veces soy terrible para los nombres. La pregunta es: "Google rastrea el sitio A cada hora y el sitio B una vez al día. El sitio B escribe un artículo y el sitio A lo copia, y cambia la marca de tiempo. Googlebot rastrea primero el sitio A. A los ojos de Google, ¿cuál es el contenido original y por tanto merecerá la mejor clasificación? Y si es A, entonces, ¿es eso justo para el sitio B?"

Podría hablarte de un montón de detalles interesantes sobre cómo se rastrea la Web. Si realmente quieres ver cómo es una señal, la frecuencia de Nyquist te indica que debes muestrearla por lo menos al doble de esa frecuencia. Pero la realidad es que siempre puedes cambiar una página web. Así que la idea completa, el concepto de poder rastrear toda la Web y disponer de una copia perfecta en cada instante, tiene sus inconvenientes, porque en un momento dado solo podemos ir y recoger un número finito y determinado de páginas. Si intentásemos recuperarlas todas, y nuestra arquitectura casi sería capaz de ello, entonces acabaríamos por bloquearlo todo debido a todas esas peticiones. Así que intentamos rastrear de una forma bastante respetuosa.

También intentamos priorizar, basándonos en cosas como la clasificación de una página en particular, o si un sitio tiene un PageRank muy alto. Así que la pregunta es, esencialmente, si A se rastrea a menudo pero el artículo original viene de B, ¿qué pasa si A está robando el contenido de B?

Bien: siempre hay formas de ayudarte a protegerte contra esto. Por ejemplo, si envías un Tweet, la gente puede verlo, enlazar a él, y nosotros podemos seguir esos enlaces más de prisa, antes de descubrir el contenido en el otro sitio. Otra cosa que puedes hacer es usar cosas como Pub SubHubbub, que a su vez hace ping en distintos lugares.

En muy pocos casos usamos Pub SubHubbub para ayudarnos a mejorar el rastreo, y esto puede cambiar con el tiempo. Es una forma excelente de, en algún modo, decir, de forma asíncrona: hola, aquí hay un nuevo artículo, o una nueva entrada en un post. Pero sigamos y veamos qué pasaría en este escenario hipotético. Si A ha copiado tu artículo y ha cambiado la marca de tiempo, esto es un poco fraudulento, como si dijesen que lo han escrito ellos.

En este caso, puedes hacer un par de cosas. En primer lugar, si eres el autor del artículo, siempre puedes hacer lo que se conoce como aviso de Digital Millennium Copyright Act, en que envías esta solicitud de DMCA, y puedes encontrar la información correspondiente en http://www.google.es/dmca.html. Con esto, básicamente dices que este sitio ha copiado tu contenido, pero tú eres el autor original. Este sitio puede enviar una contranotificación, lo cual significa que rechazan tal afirmación. Dicen que ellos escribieron esa página, lo cual acarrearía penalizaciones en caso de que mintiesen. O bien, pueden no discutir esa afirmación y quitar ese contenido de su sitio. Así que, si alguien te está robando el contenido, siempre puedes realizar un aviso DMCA.

También puedes, si se trata de un sitio generado automáticamente, y están robando el contenido de varias personas, hacer un informe de spam, puesto que eso no sería un sitio de alta calidad. No es el tipo de cosas que queremos en nuestro índice. Pero aclaremos el caso que nos ocupa. En teoría, es posible que encontremos un artículo en un sitio antes de encontrarlo en el otro. Así que realmente se da el caso de tener problemas para determinar quién es el creador original de una parte de contenido en particular, pero no podemos decir que somos perfectos. Hacemos todo lo que se nos ocurre para tratar de averiguar de qué modo puede indicarnos la gente que es autora de cierto contenido. De hecho, en Google News hemos introducido un par de etiquetas nuevas, casi como un experimento para ver qué tal funcionan, para indicarnos: aquí está el autor original de este contenido.

Éstas son las aproximaciones que exploramos intentando encontrar otras fórmulas para conseguirlo. Por lo menos hasta el momento, en teoría, es posible tener un artículo. En la práctica, no pasa a menudo, y existen formas de soslayarlo o de realizar alguna acción, desde una petición DMCA hasta un informe de spam. Esperamos que esto te sirva de ayuda.

Publicado por Esperanza, equipo Calidad de búsqueda

Compraventa de enlaces: Recordando nuestra posición

2011-11-21T10:43:00.001Z

De vez en cuando creemos oportuno recordar a los webmasters y/o dueños de páginas web cuál es la postura de Google ante los enlaces de pago. No solo porque cada día hay cientos, sino miles, de nuevas páginas web, cuyos webmasters empiezan a familiarizarse con Internet, los motores de búsqueda y sus políticas, sino también por las preguntas alrededor de este tema que recibimos en nuestro Foro de ayuda para webmasters.

Teniendo en cuenta que nuestro objetivo es presentar a los usuarios resultados equitativos y precisos, y que este tipo de técnicas tiene la intención de manipular los mismos, nos ustaría aclarar una vez más algunos puntos sobre este tema:

Si un webmaster decide comprar y/o vender enlaces con el objetivo de manipular la clasificación, es decir pasar PageRank, nos reservamos el derecho de proteger la calidad de nuestros resultados de búsqueda.

Somos bastantes precisos a la hora de detectar los enlaces de pago y tomar acción sobre ellos, tanto de forma algorítmica como manual, así que si sospechas que hay algún sitio web comprando y/o vendiendo enlaces siempre puedes decírnoslo a través de nuestro rediseñado informe de spam.

Google actúa sobre todos los sitios con la misma contundencia y rigor, sin importar la popularidad o el tamaño del sitio web. En algunos casos los efectos de nuestras acciones pueden que no sean visibles con efecto inmediato como explicamos en este artículo.

Así que... ¿qué hacer?

Si un webmaster decide comprar y/o vender enlaces y no quiere que esto repercuta de forma negativa en el posicionamiento de su sitio web puede utilizar el rel=“nofollow”, o bien redireccionarlos a través de una página que esté bloqueada en el archivo robots.txt, y así ceñirse a las Directrices de calidad de Google para webmasters. Por otra parte, también es un buen momento para compartir con vosotros este artículo sobre enlaces orgánicos y recordaros que existen muchas formas de conseguir enlaces de calidad para vuestros sitios web.

Así que si crees que tu web ha sido penalizada por comprar y/o vender enlaces, la mejor forma de actuar es corregir primero esta infracción para que los enlaces no pasen PageRank y luego enviar el formulario de reconsideración explicando cuál era la situación y cómo la has solucionado. Si tenéis alguna pregunta sobre ésto podéis acudir a nuestro foro para webmasters.

Publicado por Esperanza, equipo de Calidad de búsqueda

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

2011-11-16T13:00:00.000Z

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.

Publicado por Pawel Aleksander Fedorynski, ingeniero de software del equipo de indexación, y Maile Ohye, coordinador técnico de desarrollo de programas.

Vídeos de Matt Cutts: Optimización de motores de búsqueda (SEO) y spam

2011-11-14T15:18:00.001Z

En esta ocasión Matt Cutts no va a responder a una pregunta de un webmaster , sino que en en este vídeo de tres minutos y medio, nos va a hablar sobre la Optimización de motores de búsqueda (SEO) y el spam, a través de la pregunta: "¿Google considera que los SEO son spam?". La respuesta es no, pero si quieres saber más sobre esta la repuesta, solo tienes que ver el vídeo.

¿Google considera que los SEO son spam?

Transcripción de: "¿Google considera que los SEO son spam?"

Hola. Quería hablaros unos minutos sobre la optimización de motores de búsqueda y el spam a través de la pregunta ¿Google considera que los SEO son spam?

La respuesta es no. No consideramos que los SEO sean spam. Puede que un grupo de expertos en tecnología se enfaden con esta respuesta, así que voy a explicar mi respuesta con más detalle. SEO es la abreviatura de optimización de motores de búsqueda y su función es básicamente garantizar que tus páginas se representen correctamente en los motores de búsqueda.

Hay una gran enorme cantidad de prácticas de gran calidad y de sombrero blanco que puedes realizar como optimizador del motor de búsqueda. Por ejemplo, puedes asegurarte de que tus páginas sean rastreables, es decir, quieres que sean accesibles. Quieres que los usuarios puedan encontrar tus páginas con solo hacer clic en enlaces e igualmente, que los motores de búsquedas puedan encontrarlas con tan solo hacer clic en enlaces. Debes asegurarte de que los usuarios utilicen las palabras clave adecuadas. Si utilizas jerga muy técnica que nadie más utilice, un buen SEO puede ayudarte a descubrir las palabras clave que deberías considerar.

Puedes reflexionar sobre la funcionalidad e intentar asegurarte de que el diseño del sitio sea correcto, es decir, que sea adecuado para usuarios y motores de búsqueda. Puedes pensar en cómo hacer que tu sitio sea más rápido. La velocidad de tu sitio no solo se utiliza como uno de los muchos factores que Google tiene en cuenta para las clasificaciones de búsqueda, sino que si pudieses incrementar la velocidad de tu sitio, también se podría mejorar la experiencia del usuario.

Los SEO realizan un gran número de tareas, desde ayudarte con la arquitectura inicial y la apariencia de tu sitio, la estructura URL y las plantillas, etc., para garantizar que tu sitio se pueda rastrear, hasta ayudarte a mejorar tu sitio con respecto al retorno de la inversión, es decir, intentan averiguar la forma con la que puedes obtener el mejor beneficio económico, realizan pruebas A/B, intentan saber la copia que genera más conversiones, ese tipo de cosas.

No hay en absoluto nada de malo en estos métodos de sombrero blanco. Aunque, esto no quita que seguramente haya SEO que vayan más allá del límite. Por supuesto que hay algunos SEO que intentan utilizar técnicas de sombrero negro, que piratean sitios o que utilizan palabras clave de manera engañosa o que realizan redireccionamiento engañosos. No hay duda de ello.

Nuestro objetivo es garantizar que devolvemos los mejores resultados de búsqueda posibles y los optimizadores del motor de búsqueda nos ayudan a conseguirlo cooperando e intentando ayudar a los motores de búsqueda a mejorar la búsqueda de páginas. Como veis, los SEO no son spam, al contrario, pueden ser de gran utilidad. Aunque también se puede hacer un mal uso de los mismos y suponer un obstáculo. En Google creemos que, en un mundo ideal, los usuarios no tendrían que preocuparse a este respecto, pero los motores de búsqueda aún no son tan inteligentes como los humanos. Por eso, seguimos trabajando en ello. Intentamos averiguar lo que los usuarios quieren decir, intentamos utilizar sinónimos, vocabulario y análisis morfológicos para que los usuarios no tengan que conocer la palabra exacta para poder realizar la búsqueda deseada. Pero, hasta que ese día llegue, la optimización de motores de búsqueda puede ser una forma válida de ayudar a los usuarios a encontrar lo que buscan a través de los motores de búsqueda.

Google ofrece directrices para webmasters en la página google.es/webmasters, donde también podrás encontrar un foro para webmasters y herramientas para webmasters gratuitas y un motón de documentación sobre HTML. Hemos escrito una guía de introducción a los SEO en la que los usuarios pueden obtener información sobre la optimización de motores de búsqueda. En definitiva, los SEO pueden ayudarte a hacer de este mundo un lugar mejor valiéndose de muchas prácticas correctas. No es cierto eso que muchos piensan sobre los SEO, que son unos criminales, unos estafadores.

Si encuentras a una buena persona, alguien en quien puedas confiar, alguien que te cuente con todo detalle lo que hace, el tipo de persona que te ofrece buenas referencias o una persona cuyo trabajo conozcas y consideres útil y sea claro con respecto a todas sus prácticas, esa persona será sin duda de gran ayuda para tu sitio web. Mi idea era disipar esta falsa idea con este vídeo. Algunos usuarios creen que Google considera a todos los SEO como spam, pero definitivamente eso no es verdad. Hay una gran cantidad de SEO de calidad ahí fuera. Espero que este vídeo te sea de ayuda con tu sitio web.
Publicado por Esperanza, equipo de Calidad de búsqueda

Datos de consultas de búsqueda de vuestros sitios

2011-11-10T14:29:00.001Z

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

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

2011-11-01T22:15:00.000Z

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.

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".

Canonicalización, específicamente elementos rel="canonical" y redireccionamientos 301

Sitios multilingües y multirregionales y más sobre trabajar con sitios multirregionales

Acerca del atributo rel="alternate" hreflang="x"

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.

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.

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 Pierre Far, Webmaster Trends Analyst

Las solicitudes de reconsideración se vuelven más transparentes

2011-10-27T10:12:00.000+01:00

Si tu sitio no aparece en los resultados de búsqueda de Google o su clasificación es inferior a la que tenías antes (y consideras que no infringe las Directrices para webmasters), puedes enviar una solicitud a Google para que reconsidere su indexación. A lo largo del tiempo, hemos trabajado para mejorar el proceso de reconsideración para los webmasters. Hace un par de años, además de confirmar que habíamos recibido la solicitud, empezamos a enviar un segundo mensaje a los webmasters para confirmarles que se había procesado su solicitud. Esto fue un gran paso para los webmasters que esperaban con impaciencia los resultados. Desde entonces, hemos recibido comentarios sobre el interés de los webmasters en conocer el resultado de sus solicitudes. A principios de este año, empezamos a realizar pruebas enviando respuestas más detalladas a las solicitudes de reconsideración, y los comentarios recibidos han sido muy positivos.

Actualmente, si tu sitio se ha visto afectado por una acción manual antispam, podemos comunicarte si hemos podido revocar esa acción manual según tu solicitud de reconsideración o podemos decirte si tu sitio todavía infringe nuestras directrices. Esto puede parecer desalentador, pero, si sabes que aún existe una incidencia, te resultará más fácil detectarla.

Si tu sitio no se ha visto realmente afectado por una acción manual (que es la situación más habitual), también te lo haremos saber. Es posible que nuestros algoritmos no hayan otorgado una buena clasificación a tu sitio, en cuyo caso nuestros sistemas responderán a las mejoras en el sitio a medida que se vayan realizando cambios sin necesidad de que envíes una solicitud de reconsideración. O quizás tu sitio está experimentando incidencias de acceso que impiden a Googlebot rastrearlo e indexarlo. Para obtener más ayuda sobre cómo solucionar incidencias relacionadas con la clasificación, consulta nuestro artículo sobre los motivos por los que es posible que un sitio no aparezca en los resultados de búsqueda de Google.

Hemos progresado mucho en la forma de hacer que la totalidad del proceso de solicitud de reconsideración sea más transparente. No podemos responder a solicitudes individuales con comentarios específicos, pero ahora muchos webmasters podrán saber si su sitio se ha visto afectado por una acción manual y conocerán el resultado de la revisión de reconsideración. Lo ideal sería que Google pudiera ser completamente transparente en lo que respecta al funcionamiento de cada parte de nuestro proceso de clasificación. Sin embargo, debemos mantener un delicado equilibrio, es decir, proporcionar la máxima información posible a los webmasters sin permitir que los creadores de spam descubran cómo perjudicar aún más a los usuarios. Nos alegra que Google haya establecido normas sobre las herramientas, la transparencia y la comunicación con los propietarios de sitios, pero seguiremos buscando formas de mejorar este proceso.

Publicado por Michael Wyszomierski y Tiffany Oberoi, equipo de Calidad de las búsquedas

Matt Cutts: Ortografía y la gramática a la hora de evaluar el contenido y la calidad de un sitio

2011-10-24T17:25:00.000+01:00

Muchos usuarios se han estado preguntando, tanto en nuestro Foro para webmasters como fuera de él, si la ortografía y la gramática importaba a la hora de evaluar el contenido y la calidad de un sitio. Y por fin podemos traeros una respuesta clara de Google, a través de las preguntas/respuestas de Matt Cutts. Pasa y dale al vídeo.

¿Importa la ortografía y la gramática a la hora de evaluar el contenido y la calidad de un sitio?

Transcripción de:: "¿Importa la ortografía y la gramática a la hora de evaluar el contenido y la calidad de un sitio?"

La pregunta de hoy nos llega desde el blog "Blind Five Year Old" en San Francisco, California, y se trata de una pregunta interesante. "¿Importa la ortografía y la gramática a la hora de evaluar el contenido y la calidad de un sitio?".

Es una muy buena pregunta. Al menos la última vez que lo comprobé, hace ya bastante, no se utiliza directamente como indicador para la clasificación. Es decir, que no es uno de los más de 200 indicadores que usamos para evaluar la calidad de una página. Pero creo que sería justo considerar en la posibilidad de usarlo como señal. Por ejemplo, nos dimos cuenta hace ya mucho que si observas la clasificación de una página, es decir, el grado de fiabilidad que creemos que tiene un sitio, la capacidad de escribir correctamente está relacionada en parte.

Es decir, que lo sitios más fiables tienden a estar mejor escritos y, del mismo modo, los sitios con una clasificación más baja tienden a estar peor escritos, lo que resulta muy interesante, si lo piensas. También hemos investigado un poco y hemos averiguado que una persona o un equipo de personas han establecido una serie de niveles de lectura. De esta forma, un texto se podría clasificar en el nivel 3 o en el nivel 12, por ejemplo. Este es el tipo de análisis de contenido que resultaría interesante investigar como posible indicador de calidad.

Puedo decirte que siempre habrá problemas con cualquier indicador que intentes utilizar. Tomemos por ejemplo la ortografía y la gramática. En tu pregunta se supone que estás hablando de la ortografía y la gramática de un idioma en particular. Y, por tanto, para evaluar la ortografía y la gramática, antes tienes que averiguar cuál es el idioma de esa página. Y aunque dispongas de la mejor herramienta de identificación de idiomas del mundo, existen miles de millones de documentos, por lo que es probable que se te pasen algunas páginas. Entonces podrías pensar que la ortografía y la gramática de una página son horribles, pero lo que ocurre en realidad es que está escrita en húngaro y no en inglés. O quizá un párrafo o dos están en húngaro, en lugar de en inglés. Por eso no puedes saber automáticamente si un indicador funcionará a la perfección.

Por eso debemos intentar hacer una evaluación exhaustiva. Realizamos muchas pruebas para comprobar la buena calidad de los contenidos o si los sitios coinciden con nuestras intuiciones. Pero en este caso resulta que según nuestra experiencia, las páginas con mayor fiabilidad tienden a estar escritas con mayor corrección. Así que si puedes, dedícale tiempo a asegurarte de que algo está bien escrito. Comprobarás que no solo habrás creado contenido de una buena calidad, que es más probable que perdure en el tiempo, sino que probablemente los usuarios te lo agradecerán. Al acceder a una página, se puede ver si algo se ha preparado deprisa y corriendo o si alguien ha invertido mucho tiempo en hacerlo. Se puede ver si se ha revisado, si se ha contrastado la información o si se trata de un experto en la materia.

Así que siempre que es posible, intento prestar atención a la ortografía y la gramática, incluso cuando escribo en Twitter. A veces se cometen errores, pero recomiendo prestar atención a esto, quizá no necesariamente para las clasificaciones en las búsquedas, sino solo porque se mejorará la experiencia de los usuarios y estos te lo agradecerán. Es más probable que marquen tu sitio como favorito, que regresen o que les cuenten a sus amigos sobre tu sitio. Espero que estos consejos te resulten útiles.

Publicado por Esperanza, equipo de Calidad de búsqueda

Vídeo de Matt Cutts: TLD .co, ¿dominio genérico o local?

2011-10-20T11:41:00.000+01:00

¿Considera Google el TLD .co, como un dominio genérico o local? Esta pregunta ha rondado por Internet y Andrés de Costa Rica ha decidido traérsela directamente a Matt Cutts para así conocer la respuesta de primera mano y despejar dudas. ¿Sabes la respuesta? Si es que no, y te interesa conocerla, pasa a ver esta vídeo respuesta.

TLD .co, ¿dominio genérico o local?

Nota: Os recuerdo que los vídeos tienen subtítulos en español y estos deberían aparecer por defecto.

Transcripción de: TLD .co, ¿dominio genérico o local?

La pregunta de hoy llega de Costa Rica. Andrés quiere saber... Se ha hablado mucho sobre los TLD ".co", que hacen referencia a Colombia, y muchas personas están publicando que Google considerará estos TLD como el nuevo ".com", aunque se trate del TLD de Colombia. La pregunta es: ¿Google tratará el dominio ".co" como dominio genérico, similar a ".com" o ".net",·o como un TLD local específico de país?

Es una buena pregunta. La respuesta es que usuarios de todo el mundo han utilizado el dominio ".co", por lo que no lo tratamos como si fuera específico de Colombia. Al menos, las Herramientas para webmasters de Google, te permiten determinar si el dominio ".co" se refiere a un país u otro.

En cierto modo, Colombia ha decidido vender esos dominios por todo el mundo. Por tanto, aunque se trate del dominio de un país, puedes acceder a las Herramientas para webmasters y utilizar la orientación geográfica dentro de la consola para webmasters para determinar que un dominio que termine por "angel.co" o algo similar se relaciona en realidad con Estados Unidos. Espero que estos consejos te resulten útiles.

Publicado por Esperanza, equipo de Calidad de búsqueda

Derribando barreras idiomáticas en Google

2011-10-18T21:22:00.002+01:00

Los usuarios de habla inglesa dan por hecho que siempre podrán encontrar respuestas online, sea cual sea el tema de su búsqueda. Pero, ¿qué sucede si hablas hindi, catalán, galés o afrikáans? La cantidad de contenido disponible en hindi por cada hablante de esta lengua representa tan solo el 1% del amplio contenido disponible en Internet para los angloparlantes. Por ello, si hablas uno de los idiomas con menos contenido disponible, es posible que algunos de los resultados más relevantes de tu búsqueda estén en inglés.

De esta manera y para ayudarte a derribar las barreras idiomáticas de acceso a la información a partir de hoy incluiremos, además de los resultados en tu idioma, resultados relevantes en inglés con una traducción en tu lengua.

Como creemos que el idioma es una de las principales barreras que impiden que la información sea accesible universalmente, hemos estado trabajando para poder utilizar cada vez más las traducciones automáticas [inglés] con el fin de mejorar las búsquedas en una gran diversidad de lenguas.

Esta función estará disponible a partir de ahora en los siguientes 14 idiomas: afrikáans, albano, catalán, eslovaco, esloveno, galés, hindi, islandés, macedonio, malayo, maltés, noruego, serbio y suajili.

Esperamos que esta función te ayude a buscar la información que necesitas, independientemente del idioma en el que esté escrita.

Publicado por Jordan Gilliland, ingeniero de software - Equipo de búsquedas multilingües

Crear y controlar los Motores de búsqueda personalizados desde las Herramientas para webmasters

2011-10-14T13:40:00.000+01:00

Los Motores de búsqueda personalizados (Custom Search Engines, CSE) te permiten crear una búsqueda personalizada en tu sitio web con la tecnología de Google. Puedes buscar en uno o en más sitios, personalizar su aspecto para que esté en línea con el diseño de tu sitio web e incluso hacer dinero con Adsense para búsqueda. Y ahora es incluso más sencillo ya que lo puedes crear directamente desde las Herramientas para webmasters.

Si nunca has creado un CSE, solo tienes que hacer clic en el enlace de “Motores de búsqueda personalizados” en la sección Lab y crearemos automáticamente un CSE que busque en tu sitio web. Puedes hacer algunas configuraciones básicas o coger directamente el código que añadira tu nuevo CSE a tu sitio web. Siempre puedes volver al panel de control del motor de búsqueda para una configuración más avanzada.

Una vez que has creado tu motor de búsqueda personalizado (o si ya tienes uno), haz clic en el enlace de “Motores de búsqueda personalizados” en la sección Lab para controlar tu CSEs sin abandonar las Herramientas para webmasters.

Esperamos que estas nuevas características te hagan más sencillo que tus ususarios busquen en tu sitio web. Si tienes alguna pregunta, por favor publícala en nuestro Foro de ayuda para webmasters o en el Custom Search Help Forum [inglés].

Publicado por Sharon Xiao, ingeniero de software interno, y Ying Huang, ingeniero de software.

Vídeo de Matt Cutts: ¿Debería añadir "nofollow" a anuncios en banners?

2011-10-10T10:50:00.000+01:00

En esta ocasión un usuario, Damian, lanza una pregunta sobre los anuncios en banners en forma de imagen y si es necesario añadirles un "nofollow" en estos casos. ¿Te interesa la respuesta? ¿Sí? Pues entonces te aconsejamos ver la respuesta de Matt Cutts.

¿Debería añadir "nofollow" a anuncios en banners?

Nota: Os recuerdo que los vídeos tienen subtítulos en español y estos deberían aparecer por defecto.

Transcripción de: ¿Debería añadir "nofollow" a anuncios en banners?

Hemos recibido una pregunta de Damian, desde la blogosfera. Es esta: "Si alguien compra un enlace de texto desde mi sitio web, añado una etiqueta "nofollow" para que sepáis que es un enlace pagado. ¿Debo hacer lo mismo con los banners a base de imágenes?"

En general, cuando hablamos de banners publicitarios, la gran mayoría de ellos se venden mediante intercambios o en distintas redes de anuncios que ya bloquean nuestros robots rastreadores. Porque no quieren que los robots rastreen sus banners publicitarios. No quieren que los robots alteren sus impresiones ni sus recuentos de clics, ni nada por el estilo.

Así que, si estás usando algún tipo de paquete de banners publicitarios estándar, en la mayoría de los casos, los redireccionamientos irán a través de cosas que están bloqueadas por robots.txt o que, de algún modo, los motores de búsqueda no pueden rastrear. Esto es perfecto: no necesitas preocuparte en absoluto en ese caso.

Si vendes directamente el enlace por ti mismo y la única diferencia es que uno es una imagen y el otro es un enlace de texto. Si alguien ha pagado por ese enlace específicamente, entonces, sí, yo pondría nofollow en el enlace. Aunque sea un enlace en una imagen. Sin embargo, de nuevo, en la mayor parte de los casos, Google maneja los banners típicos y este tipo de cosas muy bien, de modo que no afectan a la clasificación de las páginas y todo funciona correctamente. Por lo tanto, si este es el caso, yo no me preocuparía por la situación.

Publicado por Esperanza Navas, equipo de Calidad de búsqueda

Un trabajo más eficaz y menos difícil con "estado del sitio"

2011-10-07T12:47:00.001+01:00

Los webmasters comentan sistemáticamente que tienen que priorizar su tiempo. Algunos de ellos administran decenas o cientos de sitios de clientes; otros tienen que encargarse de sus propios negocios y solo pueden dedicar una hora al mantenimiento del sitio web mientras gestionan tareas relacionadas con las finanzas y el inventario. Para ayudar a priorizar las tareas, las Herramientas para webmasters de Google van a introducir el concepto de "estado del sitio" y por ello hemos rediseñado la página principal de las Herramientas para webmasters de Google para poder resaltar los sitios que presentan incidencias de estado. De esta forma, podrás ver fácilmente las necesidades a las que debes prestar más atención sin tener que hacer clic en todos los informes de las Herramientas para webmasters de Google relativos a cada sitio que gestiones.

A continuación puedes ver la apariencia de la nueva página principal:

Como puedes comprobar, los sitios con incidencias de estado se muestran en la parte superior de la lista. (Si lo prefieres, siempre podrás volver a ordenar tus sitios alfabéticamente). Para consultar las incidencias específicas que hayamos detectado en un sitio, haz clic en el icono de estado del sitio o en el enlace "Comprobar estado del sitio" situados junto al sitio en cuestión:

Hemos decidido que esta primera versión de dicha página solo estará disponible para los usuarios que tengan 100 o menos sitios en la cuenta de las Herramientas para webmasters (verificados o sin verificar), pero ampliaremos la disponibilidad a todas las cuentas en un futuro. Si tienes más de 100 sitios, puedes ver la información de "estado de sitio" en la parte superior del panel de cada uno de tus sitios web.

En estos momentos incluimos tres tipos de incidencias en la comprobación de estado del sitio:

1.¿Hemos detectado software malintencionado en el sitio?
2.¿Se han eliminado páginas importantes a través de nuestra herramienta de solicitud de eliminación de URL?
3.¿Se ha utilizado el archivo robots.txt para impedir que se rastreen algunas de tus páginas más importantes?

Puedes hacer clic en uno de estos elementos para obtener más información sobre las incidencias detectadas en tu sitio. Si el icono de estado del sitio y el enlace "Comprobar estado del sitio" no aparecen junto a un sitio, es posible que no hayamos detectado ninguna de estas incidencias en el sitio (¡felicidades!).

Una cosa sobre las "páginas importantes": como sabes, si accedes a "Información del sitio > Acceso de rastreadores > Eliminar URL", puedes obtener una lista completa de todas las URL que se hayan eliminado. Asimismo, puedes ver todas las URL que no hemos podido rastrear porque se ha utilizado el archivo robots.txt en "Diagnóstico > Errores de rastreo > Restringida por robots.txt". Sin embargo, dado que los webmasters en ocasiones bloquean o eliminan contenido intencionadamente, solo nos interesaba indicar la posibilidad de que se produzcan incidencias de estado del sitio en los casos en los que consideremos que has bloqueado o eliminado una página de forma accidental. Por ese motivo, nos hemos centrado en las "páginas importantes". En estos momentos estamos consultando el número de clics que las páginas consiguen (que puedes ver en "Tu sitio en la Web > Consultas de búsqueda") para determinar la importancia. Además, es posible que incorporemos otros factores a medida que las comprobaciones de estado del sitio evolucionen.

Obviamente estas tres incidencias (software malintencionado, URL eliminadas y URL bloqueadas) no son las únicas cuestiones que pueden afectar al estado de un sitio web, por lo que en un futuro esperamos ampliar las comprobaciones que utilizamos para determinar el estado de un sitio. Asimismo, ten en cuenta que no hay ningún sustituto para tu propio juicio y conocimiento con relación al estado de tu sitio. No obstante, esperamos que estos cambios te ayuden a descubrir de un modo más rápido y sencillo las principales incidencias de tus sitios sin tener que examinar en profundidad todos los datos e informes.

Una vez que hayas solucionado cualquier incidencia de estado del sitio que hayamos marcado, deberán transcurrir unos días hasta que la advertencia desaparezca de tu cuenta de las Herramientas para webmasters de Google, ya que tenemos que volver a rastrear el sitio, consultar los cambios que hayas realizado y, a continuación, procesar esta información a través de la Búsqueda web de Google y las Herramientas para webmasters de Google. Si la advertencia sobre el estado del sitio sigue apareciendo tras una semana aproximadamente, es posible que la incidencia no se haya solucionado. No dudes en solicitar ayuda para localizar la incidencia en el foro de ayuda para webmasters... y envíanos tu opinión.

Publicado por Susan Moskwa, Webmaster Trends Analyst.

Los Colaboradores principales de nuestros foros son... ¡increíbles!

2011-10-06T16:43:00.002+01:00

¡El evento Global de Colaboradores principles ha sido una delicia! Como ya os comunicamos desde este blog, invitamos a más de 250 Colaboradores principales de todo el mundo a California para agradecerles que sean tan increíbles y darles también la oportunidad de conocer en persona a algunos de nuestros guías, ingenieros y jefes de producto.

Nuestras compañeras, Adrianne y Brenna, ya publicaron un artículo [inglés] en el Blog Oficial de Google. Por nuestra parte, los que trabajamos en la búsqueda en Google, no nos queda mucho más que añadir aparte de deciros que disfrutamos del evento y que nos alegramos de que por fin pudiéramos conocer a algunos de los colaboradores en persona. Tenemos la sensación de que ellos también :-). Así que aquí os dejamos algunas de las cosas que han dicho los que allí estuvieron:

Herbert Sulzer, conocido como Luzie, en Google+ (CP de webmaster en inglés, alemán y español):

“Hehehe! Fun, fun fun, this was all fun :D Huhhh”

Javier Giganto, abide en nuestro foro, en Google+ (CP de webmaster en español):

"La cumbre ha superado mis expectativas en la mayoría de los aspectos, exquisito trato de Google hacia nosotros y perfecta organización, me quedo sobre todo con la gente, tanto TCs como googlers, el ambiente ha sido espectacular."

Carlos Pablak, newrus es su alias, en Google+ (CP de webmaster en español):

"Google ha mostrado su lado humano, la calidez de su personal nos demostró que solo nos separa la pantalla de un monitor."

Por supuesto, también hemos recibido un motón de comentarios y sugerencias. Transparencia y comunicación son los primeros temas de la agenda y nos proponemos mejorarlos a través de las Herramientas para webmaster, así que estar atentos. Por otra parte, y si no lo has hecho ya, recordar usar la opción de reenvio del Centro de Mensajes en las Herramientas para webmaster para recibir estos mensajes directamente en tu bandeja de entrada. Mientras puedes seguir nuestro Blog para Webmasters y/o participar en nuestro Foro de ayuda ayuda para webmasters.

En nombre de todos los guías de Google que participaron en el evento 2011 queremos daros las gracias. ¡Sois fantasticos! :-)

Exacto, CPs y Guías de Google, de todo el mundo, llegaron para conocerse en California.

CPs y Guías de Google de los foros de webmaster y búsqueda después de una de las sesiones.

Después de un día lleno de presentaciones y sesiones...

...hicimos lo que realmente vinimos a hacer...

...disfrutar de la fiesta y celebrarlo juntos.

Publicado por Esperanza Navas, Yves Taquet, Uli Lutz, & Kaspar Szymanski, equipo de Calidad de búsqueda

Las “Consultas de búsquedas” de las Herramientas para webmasters ahora en Google Analytics

2011-10-04T21:28:00.000+01:00

Hace unos meses lanzamos un programa piloto sobre informes de Optimización en motores de búsqueda en Google Analytics, el cual estaba basado en la información de Consultas de búsqueda de las Herramientas para webmasters. Gracias a los comentarios y opiniones de nuestros usuarios del programa piloto, hemos hecho varias mejoras y estamos muy contentos de anunciar que dichos informes están ya disponibles para todo el mundo 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.

Todos estos informes de Optimización en motores de búsqueda cuentan con los filtros avanzados de Google Analytics, así como de las propiedades de visulaización para un análisis más en profundidad. Con las dimensiones secundarias, puedes ver la información sobre tu sitio web de formas que no son posibles en las Herramientas para webmasters.

Para activar estos informes de Optimización en motores de búsqueda para un determinado sitio web, debes ser tanto el propietario de la web verificada en las Herramientas para webmasters, como el administrador de la misma en Google Analytics. Una vez activados, los administradores podrán elegir qué perfiles pueden ver esos informes.

Si tienes algún comentario o sugerencia, por favor háznolo saber a través del Foro para webmasters.

Publicado por Christina Chen, Product Manager

Vídeos de Matt Cutts: ¿Cuánto tiempo dejar una redirección en un cambio de dominio?

2011-09-28T09:30:00.000+01:00

Las redirecciones 301 siempre generan muchas preguntas, así que esta vez desde Dinamarca, jacob le pregunta a Matt Cutts sobre cuánto tiempo se debe dejar una redirección 301 en un cambio de dominio. ¿Estás en el mismo caso que Jacob y no sabes la respuesta? Pues haz clic en el vídeo y escucha las recommendaciones de Matt.

¿Cuánto tiempo dejar una redirección en un cambio de dominio?

Nota: Os recuerdo que los vídeos tienen subtítulos en español y estos deberían aparecer por defecto.

Transcripción de: ¿Cuánto tiempo dejar una redirección en un cambio de dominio?

La pregunta de hoy es de Jacob, de Dinamarca. Jacob quiere saber: "Si tengo un nuevo dominio y quiero redirigir www.viejodominio.com a www.nuevodominio.com, ¿cuánto tiempo debo mantener el redireccionamiento antes de comenzar a usar el dominio antiguo para otra cosa? ¿Sólo hasta que se haya rastreado una vez?"

Bien. Esto es algo sobre lo cual las políticas de los motores de búsqueda pueden cambiar con el tiempo, puesto que vemos cómo evoluciona la Web, o vemos que los webmasters tienen problemas... y cosas por el estilo. Puedo contaros mi experiencia al trasladarme de mattcutts.com a dullest.com y de dullest.com de nuevo a mattcutts.com. Al volver, utilicé un redireccionamiento 301. Y tardó un periodo de varias semanas porque, recordad: el redireccionamiento 301 tiene lugar a nivel de página. Así que, solo porque aparezca el 301 en una página del dominio antiguo, no significa que todo el dominio se haya trasladado al completo.

Lo que hice es ejecutar el redireccionamiento de modo que todas y cada una de las páginas se redirigía de dullest.com a mattcutts.com. así que había sido una transición completa. Y realmente no me preocupé de dullest.com durante varias semanas. Tal vez un par de meses. Cuando volví a consultar Google Analytics, en esos momentos todo el tráfico había cambiado de dullest.com a mattcutts.com.

Por consiguiente, en un plazo de unas cuantas semanas, o varias semanas, tal vez alrededor de un par de meses, por ejemplo, podríamos ver que el sitio se ha movido por completo. Pero si recibimos información contradictoria, como que algunas páginas devuelven un código 200, que es un OK, mientras que otras devuelven un redireccionamiento 301 o permanente, entonces no sabemos a ciencia cierta qué significa eso.

Ciertamente, hace poco he visto algunas situaciones en que un sitio dijo: "Me he cambiado de viejodominio.com a nuevodominio.com", pero se olvidaron de añadir un subdominio. Así que se servían 200 desde el subdominio antiguo. Por consiguiente, no se puede asumir que, oh, todo va a funcionar automáticamente y mágicamente, a la perfección.

Tenemos una herramienta en las Herramientas para webmasters de Google donde es posible indicar que un sitio se ha movido de un lugar a otro. Así que es posible hacer eso para los 301 a nivel de cada página. Pero yo no asumiría que basta con que se rastree una sola vez. Realmente, el robot de Google y Google necesitan ganar la confianza suficiente como para saber que, de veras, un sitio se ha movido completamente del lugar viejo al nuevo. En definitiva, puede llevar un poco de tiempo, pero si todo va bien, al cabo de un tiempo todo acaba por ponerse al día

Publicado por Esperanza Navas, equipo de Calidad de búsqueda

El rastreo de Google Noticias ahora con Googlebot

2011-09-27T09:00:00.000+01:00

Google Noticias ha actualizado recientemente su infraestructura para poder rastrear con Googlebot, el user-agent principal de Google. ¿Qué significa esto? En realidad, este cambio apenas afecta a la mayoría de los editores. Cualquier medio de comunicación que quiera dejar de aparecer en Google Noticias, podrá hacerlo. Google Noticias seguirá respetando la entrada del archivo robots.txt para Googlebot-News, nuestro anterior user-agent, si bien esta entrada es más restrictiva que la entrada de robots.txt para Googlebot.

En nuestro Centro de asistencia, se ofrecen directrices detalladas sobre cómo utilizar el protocolo de exclusión de robots para Google Noticias. Además, los editores pueden ponerse en contacto con el equipo de asistencia de Google Noticias [inglés] si tienen preguntas, pero antes vamos a aclarar lo siguiente:

Aunque ahora solo verás el user-agent Googlebot en los registros de tu sitio, no debes preocuparte; el hecho de que aparezca Googlebot en lugar de Googlebot-News es independiente de nuestras políticas de inclusión. (Puedes comprobar en cualquier momento si tu sitio está incluido en Google Noticias realizando una búsqueda con el operador "site:". Por ejemplo, introduce "site:tusitiodenoticias.com" en el campo de búsqueda de Google Noticias y, si aparecen resultados, significa que estamos indexando tu sitio de noticias).

Tu herramienta analítica seguirá diferenciando el tráfico de los usuarios que llega a tu sitio web desde la Búsqueda de Google y el tráfico que llega desde Google Noticias, por lo que no deberías detectar ningún cambio. La principal diferencia es que ya no volverás a ver las visitas automatizadas que se realicen ocasionalmente a tu sitio desde el rastreador Googlebot-News.

Si actualmente sigues nuestras directrices para Googlebot, no será necesario que realices ningún cambio en el código de tu sitio. Los sitios que hayan implementado suscripciones mediante un modelo "medido" o los que hayan implementado First Click Free no experimentarán ningún cambio. En el caso de los sitios que requieran registro, pago o acceso a la cuenta antes de permitir la lectura de un artículo completo, Google Noticias solo podrá rastrear e indexar el título y el fragmento que se muestren a todos los usuarios que visiten la página. Las directrices para webmasters de Google ofrecen información adicional sobre el "encubrimiento o cloaking" (una práctica que consiste en mostrar a un robot una versión diferente de la que ven los usuarios). Para obtener más información sobre Google Noticias y los editores de suscripción, consulta este artículo del Centro de asistencia [inglés].

Puedes respirar tranquilo, ya que tu sitemap se seguirá rastreando. Este cambio no afecta a la forma en que rastreamos los sitemaps de noticias. Si eres editor de Google Noticias y todavía no has configurado un sitemap de noticias, haz clic en este enlace si quieres empezar a crearlo.

En el caso de los editores que quieran dejar de aparecer en Google Noticias y permanecer en la Búsqueda de Google, solo es necesario bloquear Googlebot-News y permitir el uso de Googlebot. Para obtener más información sobre cómo realizar esta acción, consulta la página del Centro de asistencia.

Al igual que ocurre con cualquier sitio web, es necesario actualizar nuestra infraestructura cada cierto tiempo. Al mismo tiempo, queremos seguir ofreciendo todo el control posible a los sitios web de noticias. Esperamos haber respondido a todas las preguntas que te hayan podido surgir con relación a esta actualización. Si tienes preguntas adicionales, consulta la página del Centro de asistencia [inglés].

(También publicado en el Blog de Google Noticias [inglés])

Publicado por David Smydra, especialista en productos de Google Noticias

Archivos PDF en los resultados de búsqueda de Google

2011-09-24T12:30:00.000+01:00

Nuestra misión consiste en organizar la información del mundo y hacer que resulte útil y accesible para todos los usuarios. En esta ambiciosa tarea, a veces nos encontramos con archivos que no son HTML, como archivos PDF, hojas de cálculo y presentaciones. Nuestros algoritmos no se detienen ante formatos de archivo diferentes; trabajamos duro para extraer el contenido relevante e indexarlo de forma adecuada para poder incluirlo en los resultados de búsqueda. Pero, si estos formatos de archivo suelen diferenciarse tanto de los archivos HTML estándar, ¿cómo indexamos realmente estos archivos y qué directrices aplicamos? ¿Y si un webmaster no quiere que los indexemos?

Google empezó a indexar archivos PDF en 2001 [inglés] y actualmente cuenta con cientos de millones de archivos PDF indexados. Hemos recopilado las preguntas más frecuentes sobre la indexación de archivos PDF y estas son las respuestas:

P: ¿Google puede indexar cualquier tipo de archivo PDF?
R: Normalmente, podemos indexar contenido textual (escrito en cualquier idioma) de los archivos PDF que utilizan diferentes tipos de codificación de caracteres, siempre que no estén cifrados ni protegidos por contraseña. Si el texto está insertado en forma de imágenes, podemos procesar las imágenes con algoritmos OCR [inglés] para extraer el texto. La norma general es que si se puede copiar el texto de un documento PDF y pegarlo en un documento de texto estándar, deberíamos ser capaces de indexarlo.

P: ¿Qué ocurre con las imágenes de los archivos PDF?
R: Actualmente, las imágenes no se indexan. Para que podamos indexarlas, deberías crear páginas HTML para las imágenes. Para aumentar las probabilidades de que podamos incluir tus imágenes en los resultados de búsqueda, consulta las sugerencias que te ofrecemos en el Centro de asistencia.

P: ¿Cómo se tratan los enlaces incluidos en los documentos PDF?
R: Normalmente, los enlaces incluidos en los documentos PDF se tratan de forma similar a los enlaces que encontramos en los archivos HTML: pueden entrar en la clasificación de PageRank y otras señales de indexación, y podemos seguirlos después de haber rastreado el archivo PDF. Actualmente, no es posible utilizar el atributo "nofollow" en los enlaces de un documento PDF.

P: ¿Cómo puedo evitar que mis archivos PDF aparezcan en los resultados de búsqueda? Y, si ya aparecen, ¿cómo puedo eliminarlos?
R: La forma más sencilla de evitar que los documentos PDF aparezcan en los resultados de búsqueda es añadir una etiqueta X-Robots "noindex" en la cabecera HTTP utilizada para mostrar el archivo. Si ya se han indexado, dejarán de aparecer con el tiempo si utilizas la etiqueta X-Robots con la directiva "noindex". Para acelerar la eliminación, puedes utilizar la herramienta de solicitud de eliminación de URL de las Herramientas para webmasters de Google.

P: ¿Pueden obtener los archivos PDF una buena clasificación en los resultados de búsqueda?
R: Por supuesto. Por lo general, estos archivos se clasifican de forma similar a otras páginas web. Por ejemplo, en el momento de esta publicación, [mortgage market review], [irs form 2011] o [paracetamol expert report] devuelven documentos PDF que obtienen una buena posición en los resultados de búsqueda gracias a su contenido y a la forma en la que están insertados y vinculados desde otras páginas web.

P: ¿Se considera contenido duplicado si tengo una copia de mis páginas en formato HTML y PDF?
R: Siempre que sea posible, te recomendamos que muestres una única copia de tu contenido. Si no es posible, asegúrate de indicar cuál es tu versión preferida. Para ello, puedes incluir la URL que prefieras en tu sitemap o especificar la versión canónica en el archivo HTML o en las cabeceras HTTP del PDF. Para obtener más sugerencias, consulta el artículo del Centro de asistencia sobre canonicalización.

P: ¿Cómo puedo influir en el título que aparece en los resultados de búsqueda de mi documento PDF?
R: Utilizamos dos elementos principales para determinar el título que mostramos: los metadatos del título que contiene el archivo y el texto de anclaje de los enlaces que dirigen al archivo PDF. Para que nuestros algoritmos capten claramente el título que deben utilizar, te recomendamos que actualices ambos elementos.

Si quieres obtener más información, ve el vídeo de Matt Cutts sobre optimización de archivos PDF para búsquedas y visita la página del Centro de asistencia para obtener información relacionada con los tipos de contenido que podemos indexar.

Si tienes comentarios o sugerencias, comunícanoslo a través del Foro de ayuda para webmasters.

Publicado por Gary Illyes, Webmaster Trends Analyst

Reorganización de enlaces de retroceso (backlinks) internos y externos

2011-09-23T02:22:00.000+01:00

Hoy queremos hablarles de los cambios que se han producido en la forma en la que categorizamos los datos de enlaces en las Herramientas para webmasters de Google. Como ya sabéis, las Herramientas para webmasters de Google incluyen enlaces dirigidos a tu sitio web en dos categorías diferentes: enlaces procedentes de otros sitios y enlaces procedentes de tu sitio. Esta actualización no cambiará tu número total de enlaces, pero intentaremos que tus enlaces de retroceso (backlinks) se muestren de una forma que se ajuste mejor a tu idea de qué enlaces proceden realmente de tu sitio y cuáles proceden de otros sitios.

Puedes administrar muchos tipos de sitios diferentes en las Herramientas para webmasters de Google: un simple nombre de dominio (example.com), un subdominio (www.example.com o gatos.example.com) o un dominio con la ruta de una subcarpeta (www.example.com/gatos/ o www.example.com/usuarios/amantegatos/). Anteriormente, solo los enlaces que empezaban por la URL exacta de tu sitio se categorizaban como enlaces internos: de esta forma, si especificabas www.example.com/usuarios/amantegatos/ como tu sitio, los enlaces procedentes de www.example.com/usuarios/amantegatos/perfil.html se categorizaban como internos, mientras que los enlaces procedentes de www.example.com/usuarios/ o www.example.com se categorizaban como externos. Esto también implicaba que si especificabas www.example.com como tu sitio, los enlaces procedentes de example.com se consideraban externos porque no empezaban por la misma URL que tu sitio (ya que no incluían el prefijo "www").

Hoy en día, la mayoría de la gente piensa que example.com y www.example.com son el mismo sitio, por lo que estamos cambiando eso ahora. Si añades example.com o www.example.com como sitio, tanto los enlaces procedentes de la versión con el prefijo "www" como los de la versión sin "www" del dominio se categorizarán como enlaces internos. También estamos ampliando esta idea para incluir otros subdominios, ya que muchos de los propietarios de un dominio también poseen sus subdominios, por lo que los enlaces procedentes de gatos.example.com o mascotas.example.com también se categorizarán como enlaces internos de www.example.com.

Enlaces for www.google.com	Enlaces externos	Enlaces internos
Anteriormente categorizados como...	www.example.com/ www.example.org/stuff.html scholar.google.com/ sketchup.google.com/ google.com/	www.google.com/ www.google.com/stuff.html www.google.com/support/webmasters/
Ahora categorizados como...	www.example.com/ www.example.org/stuff.html	scholar.google.com/ sketchup.google.com/ google.com/ www.google.com/ www.google.com/stuff.html www.google.com/support/webmasters/

Del mismo modo, si eres el propietario de un sitio incluido en un subdominio (como googlewebmaster-es.blogspot.com/) o en una subcarpeta (como www.google.com/support/webmasters/) y no posees el dominio raíz, seguirás viendo en tus enlaces internos únicamente los enlaces de las URL que empiecen por ese subdominio o esa subcarpeta, mientras que el resto se categorizará como enlaces externos. Hemos realizado algunos cambios en el servidor para que estos números sean más precisos.

Debes tener en cuenta que, si eres el propietario de un dominio raíz, como example.com o www.example.com, puede parecer que el número de enlaces externos disminuye con este cambio; esto se debe a que, como explicamos anteriormente, algunas de las URL clasificadas anteriormente como enlaces externos se incluirán ahora en el informe de enlaces internos. El número total de enlaces (internos y externos) no debería verse afectado por este cambio. Como siempre, déjanos un comentario o participa en el Foro de ayuda para webmasters si tienes alguna pregunta.

Publicado por Susan Moskwa, Webmaster Trends Analyst