El Blog para Webmasters de Google: accesibilidad

Ayudar a los usuarios a rellenar formularios online

martes, 17 de marzo de 2015

Para muchos usuarios, rellenar formularios online implica tener que introducir de forma repetitiva información común, como su nombre, su correo electrónico, su número de teléfono o su dirección en distintos sitios de la Web. Además de resultar aburrida, esta tarea se presta a cometer errores, lo que puede provocar que muchos usuarios abandonen definitivamente el flujo. Actualmente, los usuarios tienden a utilizar más sus dispositivos móviles que sus portátiles u ordenadores para navegar por Internet, por lo que resulta crucial disponer de formularios que se puedan rellenar de manera rápida y sencilla.

Hace tres años, anunciamos que íbamos a proporcionar compatibilidad con el nuevo atributo “Autocompletar” de Chrome, cuya finalidad es facilitar y agilizar la forma de rellenar formularios. Actualmente, Chrome es totalmente compatible con el atributo "Autocompletar" para los campos de formularios, siguiendo las especificaciones vigentes del estándar WHATWG de HTML. De esta forma, los webmasters y los desarrolladores web pueden etiquetar campos de elementos de entrada con tipos de datos comunes, como "name" o "street-address", sin tener que cambiar la interfaz de usuario ni el backend. Muchos webmasters han aumentado la velocidad con la que se rellenan los formularios de sus sitios marcando los formularios con este atributo.

Por ejemplo, un campo de dirección de correo electrónico de un formulario marcado de modo que permita la función de completado automático tendría el siguiente aspecto (puedes ver el f ormulario de ejemplo completo):

<input type="email" name="customerEmail" autocomplete="email"/>

Es muy importante que los usuarios puedan consultar sitios web de forma rápida y fácil desde sus dispositivos móviles. Esperamos que, en el futuro, podamos ver muchos formularios marcados con el atributo “Autocompletar”. Para obtener más información, puedes consultar nuestras especificaciones sobre Entradas de etiquetas y de nombres en Web Fundamentals. Como siempre, si tienes alguna duda, no dudes en publicarla en nuestros foros de ayuda para webmasters.

Escrito por Mathieu Perreault, Chrome Software Engineer, and Zineb Ait Bahajji, Webmaster Trends Analyst, Publicado por Javier Pérez equipo de calidad de búsqueda

Comprender mejor las páginas web

viernes, 23 de mayo de 2014

1998Susan Wojcicki

Si se bloquean recursos como JavaScript o CSS en diferentes archivos (por ejemplo, con robots.txt) y Googlebot no puede recuperarlos, nuestros sistemas de indexación no podrán ver tu sitio como un usuario común. Te recomendamos que permitas que Googlebot recupere datos en JavaScript y CSS para que tu contenido se pueda indexar mejor. Esto es especialmente importante en sitios web para móviles, en los que los recursos externos como CSS y JavaScript contribuyen a que nuestros algoritmos comprendan que las páginas están optimizadas para móviles.

Si nuestro servidor web no puede gestionar el volumen de solicitudes de rastreo de recursos, nuestra capacidad de procesar tus páginas se puede ver afectada negativamente. Si quieres asegurarte de que Google pueda procesar tus páginas, comprueba que los servidores puedan gestionar las solicitudes de rastreo de los recursos.

Siempre es recomendable que tu sitio tenga una degradación elegante. Esto permite que los usuarios disfruten de tu contenido aunque su navegador no disponga de las implementaciones de JavaScript compatibles. También es útil para los visitantes que tienen JavaScript inhabilitado o desactivado, así como para los motores de búsqueda que aún no pueden ejecutar JavaScript.

A veces, ejecutar JavaScript puede ser un proceso demasiado opaco o complejo para nosotros, en cuyo caso no podremos procesar la página por completo ni de la forma adecuada.

Algunos recursos de JavaScript eliminan contenido de la página en vez de añadirlo, lo que nos impide indexar dicho contenido.

Herramientas para webmastersnuestro foro de ayuda Escrito por Michael Xu, Ingeniero de Software, y Kazushi Nagayama, Analista de Tendencias de Webmasters, Publicado por Javier Pérez equipo de calidad de búsqueda.

Errores de rastreo de smartphones en Herramientas para webmasters de Google

jueves, 20 de marzo de 2014

configurados de forma incorrectacambios de clasificaciónErrores de rastreo

Algunos de los errores que compartimos son:

Errores de servidor: cuando el robot de Google obtiene un código de estado de error HTTP al rastrear la página.

Errores de página no encontrada y errores 404 leves: una página puede mostrar un mensaje "no encontrado" al robot de Google, bien cuando ofrece un código de estado 404 HTTP o cuando se detecta que la página es una página de error leve.

Redireccionamientos defectuosos: un redireccionamiento defectuoso es un error específico de smartphones que se produce cuando una página para ordenadores redirige a los usuarios de smartphones a una página que no guarda relación con su consulta. Un ejemplo típico de este tipo de error es cuando todas las páginas de un sitio para ordenadores redirigen a los usuarios de smartphones a la página principal del sitio optimizado para smartphones.

URL bloqueadas: una URL bloqueada es aquella en la que el archivo robots.txt del sitio no permite de forma explícita que el robot de Google lleve a cabo el rastreo para smartphones. Por lo general, estas directivas de inhabilitación de robots.txt específicas para smartphones son erróneas. Debes investigar la configuración del servidor si ves URL bloqueadas identificadas en Herramientas para webmasters de Google.

Si solucionas los problemas que se muestran en Herramientas para webmasters de Google, puedes mejorar tu sitio para los usuarios y permitir que los algoritmos indexen mejor el contenido. Puedes obtener más información sobre cómo crear sitios web para smartphones y cómo solucionar los errores más frecuentes. Como siempre, si tienes cualquier duda, pregunta en nuestros foros.

Escrito por Pierre Far, Webmaster Trends Analyst, Publicado por Javier Pérez equipo de calidad de búsqueda de Google.

Indexación de aplicaciones igual que en los sitios web

jueves, 13 de marzo de 2014

Comunícanos que estás interesado.Estamos trabajando al máximo para ofrecer esta función en más sitios web y aplicaciones en un futuro próximo.

Habilita los enlaces profundos dentro de tu aplicación.

Proporciona información sobre URIs de aplicaciones alternativas, en un archivo de Sitemaps o con un elemento de enlace en las páginas de tu sitio.

visita nuestro sitio para desarrolladoresnuestro foro para webmastersEscrito por Lawrence Chang, Product Manager. Publicado por Javier Pérez equipo de calidad de búsqueda de Google.

Video: Expandiendo tu sitio web a otros idiomas

martes, 11 de febrero de 2014

Hemos grabado un vídeo para ayudar a los webmasters a expandir sus sitio a otros idiomas o variaciones de lenguaje basadas en el país. En este vídeo se habla de temas como el rel=”alternate” hreflang y como aplicarlo en un sitio multilingüe y / o multinacional.

Video and diapositivas, como expander tu sitio web a otros idiomas

Puedes ver el vídeo de principio a fin o saltar a la sección que te interese:

Buena suerte expandiendo tu sitio web a más idiomas

Escrito por Maile Ohye, Developer Programs Tech Lead. Publicado por Javier Pérez equipo de calidad de búsqueda de Google.

6 consejos para internacionalización de sitios web

jueves, 20 de junio de 2013

Nota de los editores: Tras previamente estudiado diversas maneras de manejar la internacionalización de sitios multirregionales y multilingües, hoy presentamos este post de los miembros del equipo de Google Web Studio con consejos para los desarrolladores web.

Existen muchos sitios web multilingües y cada vez más y más sitios web están disponibles para más de un idioma. Sin embargo, la construcción de un sitio web multilingüe no significa simplemente traducir o localizar. Se requiere un par de cosas más, todas ellas están relacionadas con la internacionalización. En este artículo compartimos algunos consejos para los sitios web internacionales.

1. Haz que las páginas internacionalizacionales estén preparadas para el markup, no en hojas de estilo

El idioma y direccionalidad son inherentes a los contenidos del documento. Si es posible, por lo tanto, cuando internacionalización se refiere se debería utilizar el markup adecuado, y no hojas de estilo. Utiliza @lang y @dir, al menos en el elemento html:

<html lang="ar" dir="rtl">

Es aconsejable evitar soluciones propias como clases especiales o IDs.

En cuanto a internacionalización en las hojas de estilo, no se puede depender siempre de CSS: El CSS espec define que según los user agents se podria ignorar propiedades como direction o unicode-bidi. (Para XML, la situación cambia de nuevo. XML no ofrece un markup especial para internacionalización, así que aquí es recomendable utilizar CSS.)

2. Usa una hoja de estilos para todos las regiones

En lugar de crear hojas de estilos diferentes para LTR y RTL texto bidireccional, o incluso para cada idioma, es recomendable empaquetar todo en una hoja de estilos. Eso hace que la internacionalización se maneje mejor y sea mucho más fácil de entender y mantener.

Así que en lugar de usar una hoja de estilos alternativa como

<link href="default.rtl.css" rel="stylesheet">

sólo tienes que utilizar la ya existente

<link href="default.css" rel="stylesheet">

Al tomar este enfoque tendrás que complementar las reglas CSS existentes por parte de sus homólogos internacionales:

3. Utiliza los botones `[dir='rtl']` selector de atributos

Dado que se recomienda seguir con la hoja de estilo (consejo n º 2), se necesita una forma diferente de seleccionar los elementos que se necesitan para dar un estilo diferente a la otra direccionalidad. Como contenido RTL requieren markup específico (consejo nº 1), esto debería ser fácil: Para los navegadores más modernos, se puede simplemente utilizar [dir='rtl'].

He aquí un ejemplo:

aside {
 float: right;
 margin: 0 0 1em 1em;
}

[dir='rtl'] aside {
 float: left;
 margin: 0 1em 1em 0; 
}

4. Utiliza: `:lang()`pseudo clase

Para hacer referencia a los documentos de un idioma en particular, usa el :lang()pseudo clase. (Ten en cuenta que estamos hablando de los documentos, no de fragmentos de texto, ya la orientación de fragmentos de un idioma en particular hace las cosas un poco más complejo.)

Por ejemplo, si se descubre que el formato en negrita no funciona muy bien para los documentos en chino (que de hecho no lo hace), puedes utilizar lo siguiente:

:lang(zh) strong,
:lang(zh) b {
 font-weight: normal;
 color: #900;
}

5. refleja los valores izquierda (left-) y derecha (rigth-related)

Cuando se trabaja con dos LTR y RTL contenido que es importante para reflejar todos los valores que cambian la direccionalidad. Entre las características a tener en cuenta esta todo lo relacionado con los bordes, márgenes y rellenos (paddings), y también las propiedades relacionadas con la posición, float o text-align.

Por ejemplo, el text-align: left en la LTR que tiene que ser text-align: right en RTL.

Existen herramientas para hacer más fácil el cambio de la direccionalidad. Una de ellas es CSSJanus, aunque esta escrito para el campo “separate style sheet” y no la “same style sheet”.

6. Ten cuidado con los detalles

Cuidado con los siguientes elementos:

Imágenes diseñadas para derecha e izquierda como flechas o fondos, " light sources" en los box-shadow y text-shadow values y el posicionamiento y animaciones en JavaScript: Ya que pueden requerir intercambios y "acomodaciones" para la direccionalidad contraria.
Tamaños de fuentes, y tipos de fuentes, especialmente para los alfabetos no latinos: Dependiendo del script, y la fuente, el tamaño de fuente por defecto puede ser demasiado pequeño. Es recomendable considerar la posibilidad de ajustar el tamaño y, si es necesario, el tipo de letra.
CSS specificity: Cuando se utiliza el [dir='rtl'] (o [dir='ltr']) (consejo nº 2), se está utilizando un selector de mayor especificidad. Esto puede llevar a problemas y a ajustes en consecuencia.

Si tienes alguna pregunta o comentario, pásate por el Foro de ayuda para webmasters.

Escrito por Jens O. Meiert and Tony Ruscoe, Tech Leads, Google Web Studio, Publicado por Javier Pérez, equipo de Calidad de búsqueda.

Cambios en el ranking de resultados de búsqueda para teléfonos inteligentes (smartphones)

martes, 11 de junio de 2013

Los usuarios de smartphones son un segmento importante y en rápido crecimiento en Internet, y en Google queremos que estos usuarios puedan experimentar la riqueza total de la web. Como parte de nuestros esfuerzos para mejorar la web móvil, hemos publicado nuestras recomendaciones y de los errores más comunes de configuración.

Evitar estos errores ayuda a tus usuarios de smartphones se "engancharse" con tu sitio y ayuda a los usuarios a encontrar lo que están buscando más rápidamente. Para mejorar la experiencia de búsqueda para los usuarios de smartphones y atajar algunos de los "puntos débiles", tenemos la intención de lanzar varios cambios de clasificación en un futuro próximo para los sitios web con configuraciones no optimizadas para los usuarios de smartphones.

Ahora vamos a echar un vistazo a dos de los errores más comunes y cómo solucionarlos.

Redirecciones erróneas

Algunos sitios web utilizan URLs separadas para los usuarios de escritorio y de smartphones. Un fallo al redireccionar es cuando una página de escritorio redirige a los usuarios de smartphones a una página web irrelevante en el sitio web optimizado para smartphones. Un ejemplo típico es cuando todas las páginas en el sitio para usuarios escritorio redirige a los usuarios de smartphones a la página principal del sitio optimizado para smartphone . En el ejemplo siguiente, las redirecciones con flechas rojas se consideran defectuosas:

Este tipo de redirección interrumpe el flujo de navegación del usuario y puede llevar al usuario a dejar de utilizar el sitio y que se dirijan a otra parte. Incluso si el usuario no abandona el sitio, redirecciones irrelevantes añaden más trabajo y tiempo para llegar a lo que se esta buscando, y esto es particularmente molesto cuando se navega por redes móviles lentas. Estas redirecciones erróneas frustrar a los usuarios que están buscando una página web, video, o algo en concreto, y nuestros cambios de clasificación afectarán muchos tipos de búsquedas.

Evitar redirecciones irrelevantes es muy fácil: simplemente redirige a tus usuarios de optimizado a una página para escritorio a la página para smartphone equivalente. Si el contenido no existe en un formato compatible con optimizado, mostrar el contenido para escritorio es mejor que redirigir a una página de irrelevante.

Tenemos más consejos acerca de redirecciones, asegúrate de leer nuestras recomendaciones para separar URLs para los usuarios de escritorio y de optimizado.

Errores de Smartphone específicos

Algunos sitios proporcionan contenido a los usuarios que acceden a una URL desde un ordenado de escritorio, pero muestran una página de error a los usuarios que acceden desde smartphones. Hay muchas situaciones en las que se ven sólo errores en smartphones. Entre los más comunes estan:

Si se identifica a un usuario que visita una página de escritorio desde un dispositivo móvil y existe una página equivalente para smartphones, redirigirlo a la URL equivalente para smartphones en lugar de servir a un 404 o un "soft 404".
Asegúrate de que la URL para smartphones en sí no da un error. Si el contenido no está disponible en un formato compatible con smartphones serve la página para escritorio en su lugar. Mostrar el contenido que el usuario estaba buscando aunque no en un formato ideal da una experiencia mucho mejor de lo que mostrar una página de error.
Manejo incorrecto de Googlebot-Mobile. Un error típico es cuando Googlebot-Mobile para smartphones se redirige incorrectamente a la página web optimizada para smartphones que, a su vez, redirige Googlebot-Mobile para smartphones de nuevo al sitio de escritorio. Esto da como resultado bucle infinito de redireccionamientos, que reconocemos como error.

Evitar este error es fácil: Todos los agentes de usuario Googlebot-Mobile se identifican como dispositivos móviles específicos, y se deben tratar a estos Googlebot user-agents exactamente igual que lo se haría con los dispositivos móviles Por ejemplo, Googlebot-Mobile para teléfonos inteligentes actualmente se identifica como un iPhone y se debe servir la misma respuesta que un usuario de iPhone recibiría.
Vídeos que no se pueden reproducir en dispositivos smartphone. Muchos sitios web insertan vídeos de una manera que funciona bien en equipos de sobremesa, pero no se puede reproducir en los dispositivos móviles. Por ejemplo, si el contenido requiere Adobe Flash, no se puede reproducir en un iPhone o en las versiones de Android 4.1 y superiores.

Aunque hemos cubierto sólo dos tipos de errores en este tema, es importante que los webmasters se centren en evitar todos los errores de configuración comunes sitio web para dispositivos móviles. Trata de probar su sitio en tantos dispositivos móviles diferentes y sistemas operativos, o sus emuladores, como te sea posible, incluyendo pruebas de los vídeos en tu sitio. Si lo haces, mejoraras la web móvil, harás que tus usuarios estén satisfechos, y permitirás que tus usuarios tengan una experiencia completa y positiva.

Como siempre, por favor si tienes alguna pregunta pásate por el foro.

Escrito Yoshikiyo Kato, Software Engineer, en nombre del equipo de Mobile Search, y Pierre Far, Webmaster Tendencias Analyst, Publicado por Javier Pérez, equipo de Calidad de búsqueda.

Google+: recomendaciones de contenido para tu sitio web para móviles

viernes, 7 de junio de 2013

Cuando ayudas a alguien a encontrar un artículo fantástico en tu sitio, no solo le haces tener una buena experiencia, sino que también fomentas la fidelización. Por este motivo, hoy presentamos la interaccionón entre elementos de de búsqueda y Google+ para sugerir más contenido de tu sitio web para móviles en el momento preciso.

Por ejemplo, ahora los visitantes de Forbes pueden descubrir más fácilmente otros artículos de Forbes en en base a las señales de búsqueda de Autoría y a otros artículos que tengan una gran actividad en Google+ (lo cual incluye los +1 y los usos compartidos). En todos los casos, la relevancia de las recomendaciones del contenido recomendado se basa en la página específica que está visualizando el usuario, y solo aparece cuando el usuario toca la pantalla para obtener más información, de modo que no se interrumpe la experiencia de navegación. Así es como funciona:

Las recomendaciones pueden aparecer aunque no se hayan iniciado sesión en Google, pero si se han iniciado se verá el contenido en el cual las personas de sus círculos han compartido o han hecho +1:

También facilitamos la posibilidad de añadir y configurar estas recomendaciones de contenido. Solo necesitas añadir una línea de JavaScript a tu sitio web para móviles y, a partir de ahí, puedes realizar cambios en la sección "Para tu sitio" del Panel de control de tu página de Google+, sin necesidad de editores web.

Si quieres probar las funciones que te presentamos hoy, puedes visitar cualquier página del artículo de Forbes desde cualquier dispositivo con iOS o Android. También encontrarás más detalles en la documentación para desarrolladores: developers.google.com/+/features/recommendations.

Tenemos muchas más novedades previstas para las recomendaciones de contenido en Google + y para el Inicio de sesión con Google en general, además esperamos contar con más de 50 empresas que han integrado el Inicio de sesión con Google+ nos cuenten sus experiencias (verás algunos ejemplos a continuación) en Google I/O.

"El Inicio de sesión de Google+ es el método de inicio de sesión social más popular en nuestra aplicación para Android, y ya lo usan un 41% de nuestros usuarios con inicio de sesión social."

- Tom Grinstead, Director de Producto, Guardian News

"Estamos encantados con los resultados iniciales de la integración del Inicio de sesión de Google+. Nuestros análisis nos indican una tasa de conversiones de inicio de sesión enorme desde Google, que ya supera la de otras redes sociales en la Web, en Android e incluso en iOS. Como está teniendo tanto éxito, estamos valorando la posibilidad de eliminar otras fuentes de inicio de sesión para dar una mayor preeminencia a este nuevo canal en crecimiento."

- Haisoo Shin, Director de Ingeniería, Fancy

Posted by Mario Anima, Product Manager, Google+, Publicado por Javier Pérez, equipo de Calidad de búsqueda.

Primeros pasos con datos estructurados

jueves, 30 de mayo de 2013

Si Google entiende el contenido de tu sitio web de una manera estructurada, podemos presentar ese contenido con más precisión y de forma más atractiva a los usuarios de Google. Por ejemplo, nuestros algoritmos pueden mejorar los resultados de búsqueda con “fragmentos enriquecidos” si entendemos que la página es una ficha de producto estructurada, un evento, una receta, una reseña o cualquier otro elemento similar. También podemos destacar los datos en los paneles del Gráfico de conocimiento o en las tarjetas de Google Now para dar a conocer tu contenido.

Hoy estamos encantados de anunciar dos funciones que facilitan más que nunca la participación en las funciones de datos estructurados. La primera es una expansión del Marcador de datos para siete tipos nuevos de datos estructurados. La segunda es una nueva herramienta de marcado: el Asistente para el marcado de datos estructurados.

Compatibilidad con datos de productos, empresas, reseñas y mucho más del Marcador de datos

El Marcador de datos se lanzó en diciembre de 2012 como una herramienta de señalar y hacer clic para enseñar a Google el patrón de los datos estructurados sobre los eventos de tu sitio web. Todo ello sin tener que editar el código HTML del sitio. Ahora también puedes usar el Marcador de datos para enseñarnos muchas otras clases de datos estructurados en tu sitio: productos, empresas locales, artículos, aplicaciones de software, películas, restaurantes y episodios de TV.

Para empezar a usar el Marcador de datos, visita Herramientas para webmasters de Google, selecciona tu sitio, haz clic en el enlace "Optimización" de la barra lateral izquierda y, a continuación, haz clic en "Marcador de datos". Se te pedirá que indiques la URL de una página normalmente estructurada de tu sitio (por ejemplo, una página detallada de un producto o de un evento) y que "etiquetes" sus campos clave con el ratón.

El proceso de etiquetado tarda unos 5 minutos para una sola página, o aproximadamente 15 minutos para un patrón de páginas con formato coherente. Al final del proceso podrás verificar si Google ha entendido los datos estructurados y, en caso de ser correctos, “publicarlos” en Google. A continuación, cuando el sitio se vuelva a rastrear pasado cierto tiempo, ya será apto para mostrar información mejorada como precios, reseñas y valoraciones en los resultados de búsqueda de Google.

Una nueva herramienta: el Asistente para el marcado de datos estructurados

Aunque el Marcador de datos permite mostrar rápidamente a Google cuáles son los datos estructurados sin tener que editar el HTML, es preferible insertar el marcado de los datos estructurados directamente en las páginas web para que todos los motores de búsqueda puedan entender el contenido estructurado. Para ayudar a los autores de las web a realizar esta tarea, nos complace anunciar una nueva herramienta: el Asistente para el marcado de datos estructurados.

Al igual que con el Marcador de datos, comienzas enviando una página (URL o código fuente HTML) y utilizando el ratón para "etiquetar" las propiedades clave de los tipos de datos relevantes. Cuando terminas, el Asistente para el marcado de datos estructurados genera un código HTML de muestra con el marcado de microdatos incluido. Puedes descargar y usar este código como guía mientras implementas los datos estructurados en tu sitio web.

El Asistente para el marcado de datos estructurado admite un subconjunto de tipos de datos, incluidos todos los tipos que admite el Marcador de datos, además de varios tipos más que se usan para insertar datos estructurados en Gmail. Consulta schema.org para obtener la documentación completa acerca de los esquemas.

Esperamos que estas dos herramientas faciliten la participación de todos los sitios web en el creciente conjunto de aplicaciones de las funciones de datos estructurados de Google. Como siempre, te invitamos a publicar en nuestro foro cualquier pregunta o comentario que tengas.

Escrito por Justin Boyan, Product Manager, Publicado por Javier Pérez, equipo de Calidad de búsqueda.

Uso del marcado schema.org para los logotipos de organización

martes, 21 de mayo de 2013

Hoy presentamos la compatibilidad con el marcado schema.org para los logotipos de organizaciones, una forma de conectar tu sitio con una imagen icónica. Queremos que puedas especificar la imagen que debemos usar como tu logotipo en los resultados de búsqueda de Google.

Mediante la Organization markup, de schema.org, puedes indicar a nuestros algoritmos la ubicación de tu logotipo preferido. Por ejemplo, una empresa cuya página principal sea www.example.com puede agregar el siguiente marcado con los elementos de página visibles de dicha página principal:



<div itemscope itemtype="http://schema.org/Organization">
  <a itemprop="url" href="http://www.example.com/">Home</a>
  <img itemprop="logo" src="http://www.example.com/logo.png" />
</div>

Actualización 21 de octubre 2014: También puedes utilizar cualquier otra sintaxis compatible como el código JSON-LD:

<script type="application/ld+json">
      {
      "@context": "http://schema.org/",
      "@type": "Organization",
      "url": "http://www.example.com/",
      "logo": "http://www.example.com/logo.png"
      }
    </script>

Este ejemplo indica a Google que esta imagen corresponde al logotipo de organización de la página principal que también se incluye en el marcado y que, siempre que sea posible, se debe usar en los resultados de búsqueda de Google. Este tipo de marcado es una señal muy potente para ayudar a que nuestros algoritmos muestren esta imagen de forma preferencial por encima de otras, por ejemplo al mostrar el Knowledge Graph a la derecha basado en las consultas de los usuarios.

Y como siempre, no dudes en exponernos tus preguntas en el Foro de ayuda para webmasters.

Escrito por RJ Ryan, Google Engineer Publicado por Javier Pérez, equipo de Calidad de búsqueda.

Presentamos el "x-default hreflang" para páginas de destino internacionales

miércoles, 10 de abril de 2013

Las páginas principales de los sitios web multinacionales y multilingües a veces están configuradas para dirigir los usuarios a páginas localizadas, ya sea a través de redirecciones o cambiando el contenido para reflejar el idioma del usuario.
Hoy vamos a presentar una nueva anotación rel-alternate-hreflang compatible con Google y Yandex que el webmaster puede utilizar para especificar dichas páginas web

Para ver esto en acción, vamos a ver un ejemplo. El sitio web example.com tiene contenido dirigido a usuarios de todo el mundo de la siguiente manera:

http://example.com/en-gb: Para los usuarios de habla Inglesa en el Reino Unido
http://example.com/en-us: Para los usuarios de habla Inglesa usuarios de EE.UU.

http://example.com/en-au: Para los usuarios de habla Inglesa en Australia
http://example.com/: La página de inicio que por defecto se muestra para los usuarios en todo el mundo.

En este caso, el webmaster puede anotar este grupo de páginas con rel-alternate-hreflang utilizando sitemaps o con el uso de etiquetas HTML como estas:

<link rel="alternate" href="http://example.com/en-gb" hreflang="en-gb" />
<link rel="alternate" href="http://example.com/en-us" hreflang="en-us" />
<link rel="alternate" href="http://example.com/en-au" hreflang="en-au" />
<link rel="alternate" href="http://example.com/" hreflang="x-default" />

El nuevo atributo x-default hreflang indica a nuestros algoritmos que esta página no esta dirigida a ningún idioma o configuración regional y que es la página usada por defecto cuando no hay otra página más adecuada.
En el ejemplo, sería la página que nuestros algoritmos tratarían de mostrar en los motores de búsqueda francófonos de todo el mundo o en algunos de habla Inglesa como google.ca.

La misma anotación se aplica a las páginas principales que dinámicamente alterar su contenido basado en la geolocalización del usuario o el "Accept-Language headers".
El valor x-default hreflang señala a nuestros algoritmos que esa página no esta dirigida a un determinado idioma o configuración regional.

Como siempre, si tienes alguna pregunta o comentario, por favor pásate por el foro para Webmaster de Google.

Escrito por Pierre Far, Webmaster Trends Analyst, Publicado por Javier Pérez, equipo de Calidad de búsqueda.

5 errores comunes con rel = canonical

martes, 9 de abril de 2013

Implementando el elemento <link> con el atributo rel = canonical en tu sitio web proporciona una fuerte señal a los motores de búsqueda para indicar cual es la versión preferida para ser indexada entre varias páginas duplicadas en tu sitio web.

rel = canonical está soportado por varios motores de búsqueda, como Yahoo!, Bing y Google. El elemento <link> con el atributo rel = canonical consolida propiedades de indexación de los elementos duplicados, como tus enlaces entrantes, así como especifica la URL preferida en los resultados de búsqueda. Sin embargo, rel = canonical puede ser un poco complicado porque no es muy obvio cuando hay un error de configuración.

Mientras que el webmaster ve el “red velvet” de la página de la izquierda en su navegador, los motores de búsqueda ven el no intencionado "Blue Velvet" rel = canonical de la derecha.

Se recomienda las siguientes prácticas para el uso de rel = canonical:

Una gran parte del contenido duplicado de la página debe estar presente en la versión canónica

Una de las comprobaciones que se pueden hacer, es la de imaginar que no entiendes el idioma en que el contenido esta escrito, si colocas el contenido duplicado al lado del canónico, ¿hay un porcentaje muy elevado de las palabras de la página duplicada en la página canónica?
Si necesitas hablar el idioma para entender si las páginas son similares, por ejemplo, si son sólo sobre temas similares, pero no usan palabras exactas, la designación canónica puede llegar a ser ignorada por los motores de búsqueda.

Revisar que la URL objetivo del rel = canonical existe (no es un error o "404 soft")
Verificar que el objetivo del rel = canonical no contiene una meta etiqueta noindex
Asegurarse de que preferires que la rel = URL canónica se muestre en los resultados de búsqueda (en lugar de la URL duplicada)
Incluir el enlace rel = canonical en la cabecera de la página o el encabezado HTTP
Asegurarse de que no hay más de un rel = canonical para cada página. Cuando hay más de un rel = canonical, todos rel = canonical serán ignorados.

Error 1. rel = canonical en la primera página de una serie paginada

Imagina que tienes un artículo que abarca varias páginas:

example.com / articulo? story = cupcake-news & page = 1
example.com / articulo? story = cupcake-news & page = 2
... etcétera

Especificar un rel = canonical de la página 2 (o cualquier otra página posterior) a la página 1 no es correcto uso de rel = canonical, ya que no son páginas duplicadas. El uso del rel = canonical aquí causaría que el contenido de las páginas 2 y más adelante no se indexen en absoluto.

El contenido (por ejemplo,“cookies are superior nutrition” and “to vegetables”) se pierde cuando se especifica rel = canonical de la segunda y tercera páginas a la primera página de la serie.

En los casos de contenido paginado, se recomienda o que el rel = canonical en las páginas de la serie apunten a una versión en una sola página del artículo, o utilizar el marcado paginación rel = "prev" y rel = "next".

rel = canonical en páginas de una serie apuntando a la vista única de las páginas

Si rel = canonical para vista única de las todas las páginas no se designa, se puede utilizar el contenido paginado rel = "prev" y rel = markup "siguiente".

Error 2. URL absolutas escritas erróneamente como direcciones URL relativas

La etiqueta <link>, al igual que muchas etiquetas HTML, acepta tanto URLs relativas como absolutas . URLs relativas incluyen una ruta "relativa" a la página en concreto. Por ejemplo, "images / cupcake.png" indica como ir "desde el directorio actual al subdirectorio "images" , y luego a "cupcake.png". URL absolutas especificar la ruta completa, incluyendo el http://.

Especificando <link rel=canonical href="example.com/cupcake.html" /> (URL relativa, ya que no tiene "http://") implica que la URL canónica elegida es http://example.com/example.com/cupcake.html a pesar de que es casi seguro que no era esa la intención. En estos casos, los algoritmos pueden ignorar el rel = canonical especificado. En última instancia, esto significa que lo que esperabas lograr con el rel = canonical no funcionará.

Error 3. Designaciones no intencionadas o múltiples designaciones del rel = canonical

De vez en cuando, vemos designaciones rel = canonical que creemos que no son intencionadas. En casos muy raros, vemos algún error tipográfico, pero más comúnmente vemos que algún webmaster con poco tiempo o algo de prisa copia una plantilla de una página web sin cambiar el objetivo del rel = canonical. Lo que hace que las páginas del sitio con el rel = canonical de esos webmasters apunten al sitio del autor plantilla.

Si utilizas una plantilla, asegúrete de que no copias también la especificación rel = canonical.

Otro problema puede ocurrir cuando las páginas incluyen varios enlaces rel = canónica a diferentes URL. Esto ocurre con frecuencia cuando se combinan plugins SEO que a menudo insertan un enlace rel = canonical predeterminado, posiblemente sin el conocimiento del webmaster que ha instalado el plugin. En los casos al haber múltiples declaraciones de rel = canonical, Google probablemente ignorará todos los rel = canonical causando que cualquier beneficio que un legítimo rel = canonical podría haber ofrecido se pierda.

En ambos tipos de casos, revisar el código fuente de la página te ayudará a corregir el problema. Asegúrate de revisar toda la sección de la cabecera ya que los enlaces rel = canonical pueden encontrarse dispersos.

Comprueba el comportamiento de plugins revisando el código fuente de la página.

Error 4. Categoría o página de destino especifica con un rel = canonical a un artículo destacado

Supongamos que un webmaster tiene un sitio sobre postres. El sitio web tiene páginas con categorías útiles como "pastry" y "gelato". Cada día las páginas de estas categorías cuentan con un artículo destacado único. Por ejemplo, la página de destino de la categoria "pastry" pudo desplegar el artículo de la página "red velvet cupcakes". Debido a que la página de categoría "pastry" tiene casi el mismo contenido que la página "red velvet cupcake”, el webmaster agrega un rel = canonical desde la página de la categoría a la página del artículo individual.

Si aceptáramos esta rel = canonical, entonces la página de la categoría "pastry" no aparecería en los resultados de búsqueda.
Esto debido a que las señales rel = canonical indican a los motores de búsqueda que se prefiere mostrar la URL canónica de la página del artículo individual en lugar del duplicado. Sin embargo, si se desea que los usuarios puedan encontrar tanto la página de la categoría como el artículo destacado, lo mejor es tener sólo una auto-referencia rel = canonical a la página de la categoría, o ninguna en absoluto.

Recuerda que la designación canónica también implica la URL preferida para ser mostrada. Evita agregar un rel = canonical de una página de categoría o el aterrizaje de un artículo destacado.

Error 5. rel = canonical en el <body>

La etiqueta de enlace rel = canonical sólo debería aparecer en el "<head>" (cabecera) de un documento HTML. Además, para facilitar el análisis del HTML, es bueno incluir el atributo rel = canonical tan pronto como sea posible en el <head>. Cuando nos encontramos con una designación rel = canonical en el <body>, no se tiene en cuenta.

Esto es un error fácil de corregir. Simplemente revisa que tus enlaces rel = canonical están siempre en el <head> de tu página, y tan pronto como sea posible.

Las designaciones rel = canonical en el <head> son procesados, en el <body> no.

Conclusión

Para crear buenas designaciones rel=canonical :

Comprueba que la mayor parte del contenido del texto principal de la página duplicada también aparece en la página canónica.
Comprueba que el rel = canonical sólo se especifica una vez y se encuentra en el <head> de la página.
Comprueba que el rel = canonical apunta a una URL existente y con buen contenido (es decir, no es un 404, o peor aún, un "soft" 404).
Evita el uso del rel = canonical en las páginas de destino o categorías con artículos destacados ya que hará que el artículo destacado sea la URL preferida en los resultados de búsqueda.

Y, como siempre, por favor ante cualquier duda, pregunta en nuestro foro de ayuda para webmasters.

Escrito por Allan Scott, Software Engineer, Indexing Team, Publicado por Javier Pérez, equipo de Calidad de búsqueda.

Construir Sitios Web optimizados para dispositivos móviles

miércoles, 20 de marzo de 2013

Cada vez más y más usuarios en todo el mundo utilizan dispositivos móviles para navegar en Internet, y el entorno para acceder a tu sitio web está cambiando.

Google ha estado publicando varios artículos acerca de cómo optimizar tu sitio web para dispositivos móviles y hoy para ayudar a los webmasters a optimizar sus sitios webs nos gustaría presentar la edición en castellano de la web "Creación de sitios web optimizados para móviles".

Ahora en un sitio web único podrás encontrar recursos para la construcción de sitios web optimizados para smartphones, donde también encontrarás algunos consejos útiles con respecto a las tabletas.
Si estas pensando en construir o adaptar tu sitios web para usuarios de smartphones o tabletas, este sitio web puede ser de gran utilidad.

Si tienes alguna pregunta, por favor, pásate por nuestro foro de ayuda para webmasters.

El equipo de Calidad de búsqueda.

Primera hoja de referencia para todos los públicos con los pasos básicos para optimizar tu sitio web

jueves, 14 de marzo de 2013

Todo el mundo conoce a alguien que acaba de crear su primer blog en Blogger, acaba de instalar WordPress por primera vez o se esta iniciando en el mundo de la creación de sitios web.

Especialmente para ellos hemos creado una hoja de referencia con unos primeros pasos de optimización básicos.

Esta hoja contiene una breve lista con consejos básicos para implementar en los sitios web, que puede ayudar a Google y a otros motores de búsqueda a entender mejor el contenido y aumentar la visibilidad de tu sitio.

Por favor no dudes en imprimir, copiar, distribuir y compartir esta hoja con todo aquel al que creas que puede ser de ayuda

Esperamos que este material sea de utilidad a los que están a punto de iniciar su aventura en el mundo webmaster o a los que hasta ahora no han prestado demasiada atención a los motores de búsqueda.

Con el tiempo, a medida que vayas adquiriendo experiencia es posible que te interese echar un vistazo a nuestra más avanzada Guía para principiantes sobre optimizaciónpara motores de búsqueda.

Y como siempre invitamos tanto, los nuevos webmasters y propietarios de sitios web,como a los más experimentados a compartir sus experiencia y conocimiento en el Foro de ayuda para webmasters de Google.

Búsqueda por imágenes más rápida

jueves, 24 de enero de 2013

La gente que busca imágenes en Google a menudo quieren poder navegar a través de muchas imágenes, viendo tanto las imágenes como sus metadatos (información detallada acerca de las imágenes). En base a las sugerencias de los usuarios y webmasters, hemos rediseñado Google Imágenes para proporcionar una mejor experiencia de búsqueda. Los resultados de imágenes se muestran ahora en un panel en la misma pantalla por lo que es más rápido, más estético y más fidedigno. Ahora puedes navegar rápidamentea través de un conjunto de imágenes utilizando el teclado. Si quieres volver a los otros resultados de búsqueda, simplemente desplázate hacia abajo y continua justo donde lo dejaste.

Como afecta este cambio a los webmasters:

Ahora se muestra la información detallada acerca de la imagen (los metadatos) justo debajo de la misma imagen en los resultados de búsqueda, en lugar de redirigir a los usuarios a una página de destino diferente.

La información clave aparece mucho más prominente junto a la imagen: el título de la página que aloja la imagen, el nombre de dominio, y el tamaño de la imagen.

Ahora se puede hacer clic en el nombre de dominio, y también hemos añadido un nuevo botón para poder visitar la página donde está alojada la imagen. Esto significa que ahora hay cuatro puntos donde se puede hacer clic en lugar de sólo dos. En nuestras pruebas, hemos visto un incremento neto en el de porcentaje de clics.

La página de origen dejará de cargarse complatemente cada vez que quieres echar un vistazo a los detalles de imagen. Esto mejora la experiencia de los usuarios, se reduce la carga en los servidores del sitio web de origen, y aumenta la precisión en las métricas de visita en la página. Y Como es habitual, los datos relacionados con la consulta de búsqueda la imagen están disponible en las consultas de búsqueda en las Herramientas para webmasters.

Como siempre, si tienes cualquier duda, por favor visita nuestro foro de ayuda para webmasters
Escrito por Hongyi Li, Associate Product Manager, Publicado por Javier Pérez, equipo de Calidad de búsqueda.

Cómo ofrecer a los usuarios de tablets la Web a tamaño completo

jueves, 22 de noviembre de 2012

Desde que presentamos las recomendaciones de Google para la creación de sitios web optimizados para smartphones, los webmasters han mostrado su interés por saber cómo abordar este tema en otro tipo de dispositivos: los tablets.

Se trata de una cuestión similar a la que los desarrolladores de aplicaciones Android deben hacer frente, y para la que la guía Creación de aplicaciones de calidad para tablets representa un buen punto de partida.

Aunque no disponemos de recomendaciones específicas para crear sitios web optimizados para tablets con un buen rendimiento en los motores de búsqueda, sí podemos proporcionarte algunos consejos sobre cómo crear sitios web que satisfagan tanto las necesidades de los usuarios de smartphones como las de los usuarios de tablets.

Si nos centramos en los usuarios que visitan tu sitio desde un tablet, es importante pensar tanto en los dispositivos que usan como en las expectativas que tienen.

En comparación con los smartphones, los tablets tienen pantallas táctiles de mayor tamaño y normalmente se usan en conexiones Wi-Fi. Además, los tablets ofrecen una experiencia de navegación que puede ser tan positiva como la de cualquier ordenador de escritorio o portátil, pero en un dispositivo con mayor movilidad, más ligero y, por lo general, más cómodo.

Esto significa que, a menos que ofrezcas contenido optimizado para tablets, los usuarios esperan ver el sitio para ordenadores de escritorio y no la versión adaptada para smartphones.

Lo que te recomendaríamos para los sitios optimizados para smartphones es que uses un diseño web receptivo, es decir, que tengas un sitio para todos los dispositivos.

Si tu sitio web, siguiendo nuestra recomendación, usa un diseño web receptivo, asegúrate de probarlo en distintos tipos de tablets para comprobar que también ofrezca un buen rendimiento en estos dispositivos.

Recuerda que, al igual que con los smartphones, hay una gran variedad de tamaños y de resoluciones de pantalla que debes probar.

Otra configuración frecuente consiste en tener sitios separados para ordenadores de escritorio y para smartphones, y redireccionar a los usuarios a la versión que les corresponda. Si usas esta configuración, comprueba que no estés redireccionando, por error, a los usuarios de tablets al sitio optimizado para smartphones.

Cómo distinguir entre los smartphones y los tablets Android

En los dispositivos Android, es fácil distinguir entre los smartphones y los tablets con la cadena user-agent que proporcionan los navegadores. Aunque tanto los smartphones como los tablets Android incluyen la palabra "Android" en la cadena user-agent, solo el user-agent de los teléfonos contiene el término "Mobile".

En resumen, cualquier dispositivo Android que no incluya el término "Mobile" en el user-agent es un tablet (u otro dispositivo con una pantalla grande) que usa el sitio para ordenadores de escritorio.

Por ejemplo, este es el user-agent de Chrome en un smartphone Galaxy Nexus:

Mozilla/5.0 (Linux; Android 4.1.1; Galaxy Nexus Build/JRO03O) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19

Y este es el de Firefox en el Galaxy Nexus:

Mozilla/5.0 (Android; Mobile; rv:16.0) Gecko/16.0 Firefox/16.0

Compáralos con el user-agent de Chrome en Nexus 7:

Mozilla/5.0 (Linux; Android 4.1.1; Nexus 7 Build/JRO03S) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Safari/535.19

O con el de Firefox en Nexus 7:

Mozilla/5.0 (Android; Tablet; rv:16.0) Gecko/16.0 Firefox/16.0

Como el user-agent de Galaxy Nexus incluye el término "Mobile", debería usar la versión de tu sitio web optimizada para smartphones, mientras que el Nexus 7 debería ver la versión completa del sitio.

Esperamos que estas indicaciones te ayuden a crear sitios web optimizados para tablets que ofrezcan un mejor rendimiento.

Como siempre, no dudes en consultar nuestro foro de ayuda para webmasters si tienes más preguntas.

Escrito por Pierre Far, Webmaster Trends Analyst, y Scott Main, lead tech writer for developer.android.com , Publicado por Javier Pérez, equipo de Calidad de búsqueda.