HTTPS como señal del ranking


La seguridad es una de las principales prioridades de Google. Invertimos muchos recursos en garantizar que nuestros servicios utilicen opciones de seguridad líderes en el sector, como el potente cifrado HTTPS predeterminado. Esto implica que los usuarios que utilizan, por ejemplo, el buscador, Gmail y Drive tienen automáticamente una conexión segura a Google.

Además de trabajar en nuestros propios productos, también lo estamos haciendo para conseguir que Internet sea un lugar más seguro en general. Una buena parte de nuestros esfuerzos se centran en garantizar que los sitios web a los que acceden los usuarios a través Google sean seguros. Por ejemplo, hemos creado recursos que permiten a los webmasters evitar y solucionar las fisuras de seguridad de sus sitios.

Pero queremos ir más allá. Durante el último Google I/O algunos meses atrás, hicimos un llamamiento para instaurar el HTTPS en todos los sitios de la Web.

También estamos viendo que cada vez más webmasters utilizan HTTPS (también conocido como HTTP sobre TLS o seguridad de la capa de transporte) en sus sitios web, lo que resulta muy alentador.

Por estos motivos, durante los últimos meses hemos estado haciendo pruebas teniendo en cuenta si los sitios utilizan conexiones seguras cifradas como señal para nuestros algoritmos de ranking. Los resultados han sido positivos, de modo que empezaremos a utilizar HTTPS como señal del ranking. Por ahora solo se trata de una señal muy ligera (afecta a menos del 1% de consultas globales y tiene menos peso que otras señales, como el contenido de alta calidad), mientras dejamos que los webmasters pasen a utilizar HTTPS. Con el tiempo, es posible que decidamos reforzarla, porque queremos animar a todos los propietarios de sitios web a cambiar de HTTP a HTTPS para que todos los usuarios estén protegidos en la Web.


Durante las próximas semanas, publicaremos las prácticas recomendadas detalladas (ahora en el centro de ayuda) para que el paso hacia TLS sea más fácil y para evitar los errores más comunes. A continuación, hay algunos consejos básicos para empezar:

  • Debes decidir qué tipo de certificado necesitas: único, para varios dominios o un certificado comodín.
  • Debes utilizar certificados de clave de 2.048 bits.
  • Debes utilizar URL relativas para los recursos que se alojan en el mismo dominio seguro.
  • Debes utilizar URL relativas de protocolo para el resto de dominios.
  • Consulta nuestro artículo sobre el cambio de sitio para obtener más directrices para realizar el cambio de la dirección del sitio web.

No bloquees el rastreo del sitio HTTPS mediante un archivo robots.txt.
Debes permitir que los motores de búsqueda indexen tus páginas siempre que sea posible.Evita el uso de la metaetiqueta "noindex".


Si tu sitio web ya está publicando en HTTPS, puedes comprobar su nivel de seguridad y su configuración con la herramienta Qualys Lab. Si te preocupa cómo afectará el protocolo TLS al rendimiento del sitio, puedes echarle un vistazo a la entrada sobre la rapidez de TLS. Y, por supuesto, si tienes alguna pregunta o consulta, no dudes en publicarla en nuestro foro de ayuda para webmasters.

Esperamos ver que cada vez más sitios web utilicen HTTPS en el futuro. Hagamos que la Web sea más segura entre todos.

Escrito por Zineb Ait Bahajji and Gary Illyes, Webmaster Trends Analysts, Publicado por Javier Pérez equipo de calidad de búsqueda


jueves, 7 de agosto de 2014

La indexación de aplicaciones para Android ya está disponible para todo el mundo


¿Tienes una aplicación para Android además de tu sitio web? Ahora puedes conectar los dos para que los usuarios que efectúen búsquedas desde sus smartphones y tablets puedan encontrar fácilmente el contenido de tu aplicación y acceder a él.

Los enlaces profundos de aplicaciones en los resultados de búsqueda ayudan a tus usuarios a encontrar tu contenido con más facilidad, así como a volver a interactuar con la aplicación después de instalarla.  Como propietario de un sitio, puedes mostrar a tus usuarios el contenido adecuado en el momento justo: al conectar páginas de tu sitio web a partes relevantes de la aplicación, puedes controlar cuándo se dirige a tus usuarios a la aplicación y cuándo visitan tu sitio web.






Cientos de aplicaciones ya han implementado la indexación. Esta semana anunciaremos en Google I/O un conjunto de características nuevas que facilitarán aún más la configuración de enlaces profundos en tu aplicación, la conexión de tu sitio a tu aplicación y el seguimiento del rendimiento y de los posibles errores.

Es fácil comenzar

Hemos simplificado en gran medida el proceso de indexación de enlaces profundos de tu aplicación. Si tu aplicación admite esquemas de enlaces profundos HTTP, tienes que hacer lo siguiente:

  1. Admite los enlaces profundos en tu aplicación
  2. Conecta tu sitio y tu aplicación. 
  3. No hay paso 3 (:


Cuando indexemos tus URL, descubriremos e indexaremos las conexiones aplicación/sitio y los enlaces profundos de la aplicación pueden empezar a surgir en los resultados de búsqueda.

Podemos descubrir e indexar los enlaces profundos de tu aplicación por nuestra cuenta, pero te recomendamos que los publiques, especialmente si tu aplicación solo admite un esquema de enlaces profundos personalizado. Puedes publicarlos de dos formas:



Hay algo más: hemos añadido una nueva característica a Herramientas para webmasters de Google que te ayudará a depurar los problemas que puedan surgir durante la indexación de páginas de aplicaciones. Te mostrará qué tipo de errores hemos detectado para los pares de página de aplicación-página web, junto con ejemplos de URIs de aplicación, para poder depurarlos:





También te daremos instrucciones detalladas acerca de cómo depurar cada problema, incluido un código QR para los enlaces profundos de la aplicación, de modo que puedas abrirlos fácilmente en tu teléfono o tablet. También te enviaremos notificaciones de errores de Herramientas para webmasters de Google para que puedas estar al día.



Prueba la indexación de aplicaciones y, como siempre, si necesitas ayuda, haz preguntas en el Foro de ayuda para webmasters.


Escrito por Mariya Moeva, Webmaster Trends Analyst. Publicado por Javier Pérez equipo de calidad de búsqueda


viernes, 27 de junio de 2014

Cómo crear la página de inicio adecuada para usuarios internacionales


Si tienes un negocio en más de un país o segmentas tu contenido en distintos idiomas, te recomendamos que tengas sitios o secciones independientes con contenido específico en cada URL, segmentado para países o idiomas concretos. Por ejemplo, una página para visitantes de EE. UU. y anglófonos y otra página para usuarios de Francia y francófonos.Aunque disponemos de información sobre la administración de sitios multirregionales y multilingües, la página de inicio puede ser un poco especial. Esta entrada te ayudará a crear la página de inicio adecuada en tu sitio web para publicar el contenido correcto para los usuarios en función de su idioma y ubicación.

Hay tres formas de configurar la página de inicio o la página de destino para cuando los usuarios acceden a ella:
  • mostrar el mismo contenido para todos los usuarios,
  • permitirles escoger,
  • publicar contenido en función de la localización y del idioma de los usuarios.
Echemos un vistazo a los detalles de cada opción.

Mostrar el mismo contenido a los usuarios de todo el mundo

Con esta opción, tú decides publicar contenido específico para un país y un idioma determinados en la página de inicio o en la URL genérica (http://www.example.com). Este contenido estará disponible para cualquier usuario que haya accedido a esta URL directamente en el navegador o para aquellos que busquen específicamente esa URL. Tal como se indica más arriba, se debería poder acceder a todas las versiones de país e idioma en sus URL únicas.


Nota: Puedes mostrar un banner en la página para sugerir una versión más adecuada a los usuarios de otras ubicaciones o con una configuración de idioma distinta.

Permitir a los usuarios elegir la versión local y el idioma que quieren

Con esta configuración, publicas una página de selección de país en la página de inicio o en la URL genérica para que los usuarios puedan escoger qué contenido quieren ver en función del país y del idioma. Todos los usuarios que escriban esta URL accederán a la misma página.

Si implementas esta opción en el sitio internacional, recuerda utilizar la anotación x-default rel-alternate-hreflang para la página de selección de país, que se ha creado específicamente para este tipo de páginas. El valor x-default nos ayuda a reconocer las páginas que no son específicas de un idioma ni de una región.

Redirigir automáticamente a los usuarios o publicar de forma dinámica el contenido HTML adecuado en función de su configuración de ubicación y de idioma

Una tercera opción consiste en publicar automáticamente el contenido HTML adecuado para los usuarios en función de su configuración de ubicación y de idioma. Para ello, debes utilizar redireccionamientos 302 del entorno del servidor o publicar de forma dinámica el contenido HTML adecuado.

Recuerda utilizar la anotación x-default rel-alternate-hreflang en la página de inicio o en la página genérica, aunque esta última sea una página de redireccionamiento a la que los usuarios no pueden acceder directamente.

Nota: Piensa en la opción de redirigir a los usuarios para los que no tienes una versión específica. Por ejemplo, usuarios francófonos en un sitio web que tiene versiones en inglés, español y chino. Muéstrales el contenido que consideres más adecuado.
Sea cual sea la configuración que escojas, debes asegurarte de que todas las páginas, incluidas las páginas de selección de país e idioma, cumplen lo siguiente:
  • Tienen anotaciones rel-alternate-hreflang.
  • Se encuentran accesibles para el rastreo y la indexación de Googlebot: no bloquees el rastreo ni la indexación de las páginas localizadas.
  • Permite siempre que los usuarios cambien a la versión o al idioma local. Para ello, puedes utilizar un menú desplegable.
Recordatorio: Tal como se indica al principio, recuerda que debes tener URL distintas para cada versión de país y de idioma.

Acerca de las anotaciones rel-alternate-hreflang

Recuerda anotar todas tus páginas, sea cual sea el método que utilices. Ello permitirá que los motores de búsqueda muestren los resultados adecuados a tus usuarios fácilmente.

Todas las páginas de selección de país y las páginas de inicio de publicación dinámica o que redirigen deberían utilizar x-default hreflang, que se ha diseñado específicamente para las páginas de inicio y las páginas de selección de país de redireccionamiento automático.

Por último, aquí tienes algunos recordatorios generales sobre las anotaciones rel-alternate-hreflang:
  • Tus anotaciones deben confirmarse desde las otras páginas. Si la página A enlaza con la página B, la página B tiene que volver a enlazar con la página A. De lo contrario, es posible que las anotaciones no se interpreten correctamente.
  • Las anotaciones deben hacer referencia a sí mismas. La página A debería utilizar los enlaces de la anotación rel-alternate-hreflang para sí misma.
  • Puedes especificar las anotaciones rel-alternate-hreflang en el encabezado de HTTP, en la sección del encabezado del HTML o en un archivo de sitemap. Es muy recomendable que elijas solo una forma de implementar las anotaciones para evitar incoherencias y errores.
  • El valor del atributo hreflang debe estar en formato ISO 639-1 para el idioma y en ISO 3166-1 Alpha 2 para la región. No puedes especificar solo la región. Si deseas configurar tu sitio solo para un país, utiliza la función de orientación geográfica en Herramientas para webmasters de Google.
Si sigues estas recomendaciones, podremos entender mejor tu contenido localizado y ofrecer resultados más relevantes a tus usuarios en los resultados de búsqueda. Como siempre, si tienes preguntas o comentarios, háznoslos llegar en el Foro de ayuda para webmasters.

Escrito por Zineb Ait Bahajji webmaster trend analysits. Publicado por Javier Pérez equipo de calidad de búsqueda.



lunes, 16 de junio de 2014

Campaña #NoHacked, ayuda a prevenir vulnerabilidades en tu sitio web


Esta semana comenzamos nuestra campaña #NoHacked.

Tiene como objetivo concienciar a los webmasters de la existencia de ataques hackers en sus sitios web y ofrecer consejos para ayudar con la prevención para ayudar a mantener tus sitios a salvo de los hackers informáticos.

Seria muy bueno que este tipo de ataques no ocurrieran a nadie pero desgraciadamente hay muchos sitios con vulnerabilidades que los hackers aprovechan, y sorprendentemente es bastante común para muchos sitios web el haber sido atacados sin que los propios webmasters lo sepan.





Es hora de hacer tu sitio menos vulnerable a los piratas informáticos.

Y la parte divertida es, tu puedes ayudar participando!
compartiendo tus propios consejos de prevención con el hashtag #NoHacked.

Anímate a compartir este post tus consejos !!

Publicado por Javier Pérez equipo de calidad de búsqueda.

martes, 10 de junio de 2014

Simplificar los movimientos de sitio


Hay pocas cuestiones que confundan y asusten más a los webmasters que los movimientos de sitio. Para ayudarte a evitar sorpresas, hemos creado una guía detallada sobre cómo gestionar los movimientos de sitio de modo que Googlebot los acepte. Así pues, ¿qué es un movimiento de sitio exactamente y cómo se actúa para mover un sitio correctamente?

Aspectos básicos de los movimientos de sitio

En términos generales, un movimiento de sitio es uno de los dos tipos de migración de contenidos:
  • Movimientos de sitio sin cambios de URL. Solo se cambia la infraestructura subyacente del sitio web sin ningún cambio visible en la estructura de la URL. Por ejemplo, puedes mover www.example.com a un proveedor de host diferente y mantener al mismo tiempo las mismas URL y la misma estructura de sitio que en www.example.com.
  • Movimientos de sitio con cambios de URL. En este caso, las URL del sitio web cambian de muchos modos:
    • El protocolo: de http://www.example.com a https://www.example.com
    • El nombre del dominio: de example.com a example.net
    • Las rutas de la URL: de http://example.com/page.php?id=1 a http://example.com/widget
Hemos visto casos en que los webmasters implementaban movimientos de sitio de modo incorrecto o bien omitían pasos que hubieran aumentado considerablemente las posibilidades de que este se completara correctamente. Para ayudar a los webmasters a diseñar y a implementar movimientos de sitio correctamente, hemos actualizado las directrices de movimientos de sitio de nuestro Centro de ayuda. Además, seguimos mejorando los sistemas de rastreo e indexación para detectar y gestionar los movimientos de sitio siguiendo las directrices.

Mover el sitio y cambiar a un diseño web adaptativo

Una cuestión relacionada cada vez más habitual con que nos encontramos es cómo se puede mover un sitio web y pasar de tener URL independientes para móviles o una publicación dinámica a usar un diseño web adaptativo. Para ayudarte a implementar este cambio de configuración, consulta esta página nueva en nuestro sitio de recomendaciones para smartphones.

Además, como siempre, pregunta en nuestros Foros de ayuda para webmasters si tienes más preguntas.

Escrito por Pierre Far y Zineb Ait Bahajji webmaster trend analysits. Publicado por Javier Pérez equipo de calidad de búsqueda.


viernes, 6 de junio de 2014

Procesar páginas con Explorar como Google


La función Explorar como Google de las Herramientas para webmasters ofrece a los webmasters los resultados que obtiene el robot de Google al intentar explorar sus páginas. El código HTML y los encabezados del servidor que se muestran son útiles para diagnosticar problemas técnicos y efectos secundarios derivados del pirateo, pero a veces hacen que comprobar la respuesta sea difícil: ¡Socorro! ¿Qué significan todos estos códigos? ¿Seguro que esta es la misma página que la que estaba viendo en el navegador? ¿Dónde comemos? No podemos darte una respuesta a esta última pregunta, pero, para el resto, hace poco hemos ampliado esta herramienta para que también muestre cómo el robot de Google podría procesar la página.

Ver la página procesada

Para procesar la página, el robot de Google intenta buscar todos los archivos externos involucrados y también los explora. Entre esos archivos normalmente hay imágenes, archivos de JavaScript y CSS, así como otros archivos que es posible que se hayan insertado indirectamente mediante CSS o JavaScript. A continuación, se usan para procesar una vista previa que muestra la visualización de la página que genera el robot de Google.

Puedes encontrar la función Explorar como Google en la sección Rastreo de las Herramientas para webmasters de Google. Después de enviar una dirección URL con "Obtener y procesar", espera a que se procese (para algunas páginas puede tardar un poco). Cuando esté listo, simplemente haz clic en la fila de respuesta para ver los resultados.
fetch-as-google-rendered-analytics-Screenshot from 2014-05-15 10:39:21.png

Administración de recursos bloqueados por robots.txt

El robot de Google sigue las directivas del archivo robots.txt para todos los archivos que explora. Si no quieres permitir el rastreo de alguno de estos archivos (o si se han insertado desde un servidor de terceros que no permite que el robot de Google los rastree), no te los mostraremos en la vista de elementos procesados. Además, si el servidor no responde o se produce algún error, tampoco podremos usarlos (encontrarás problemas similares en la sección Errores de rastreo de las Herramientas para webmasters). Si se produce alguno de estos problemas, se mostrarán debajo de la vista previa.

Te recomendamos que te asegures de que el robot de Google pueda acceder a cualquier recurso insertado que afecte de forma significativa al contenido visible o al diseño de tu sitio. De esta manera harás que Explorar como Google sea más fácil de usar y permitirás que el robot de Google también pueda buscar e indexar este contenido. Algunos tipos de contenido, como los botones de los medios sociales, las fuentes o las secuencias de comandos de análisis de sitios web, normalmente no afectan de forma significativa al contenido visible o al diseño, por lo que en estos casos se puede no autorizar el rastreo. Para más información, consulta nuestra entrada anterior del blog sobre qué hace Google para entender mejor la Web.

Esperamos que con esta actualización te resulte más fácil diagnosticar este tipo de problemas y averiguar qué contenido se ha bloqueado del rastreo por error. Si tienes alguna duda o algún comentario, háznoslo saber aquí o pásate por el foro de ayuda para webmasters.

Escrito por Shimi Salant Webmaster Tools teams. Publicado por Javier Pérez equipo de calidad de búsqueda.

martes, 27 de mayo de 2014

Comprender mejor las páginas web


En 1998, cuando nuestros servidores funcionaban desde el garaje de Susan Wojcicki, no nos preocupábamos para nada de JavaScript ni de CSS. Estos recursos se utilizaban poco, y JavaScript servía para hacer que los elementos de las páginas... parpadearan. Las cosas han cambiado mucho desde entonces. La Web está repleta de sitios web increíbles, dinámicos y sofisticados que usan mucho JavaScript. Hoy nos centraremos en nuestra capacidad de procesar sitios web más sofisticados, es decir, de ver tu contenido de una forma más parecida a cómo lo hacen los navegadores web modernos, de incluir recursos externos, de ejecutar JavaScript y de aplicar CSS.

Hasta ahora solo nos fijábamos en el contenido textual sin editar procedente del cuerpo de respuesta de HTTP, y no interpretábamos lo que veía un navegador normal que ejecutara JavaScript. Cuando empezaron a aparecer páginas con valioso contenido procesado por JavaScript, los usuarios que hacían búsquedas no podían acceder a ese contenido, lo cual era muy negativo tanto para los usuarios como para los webmasters.

Para solucionar ese problema, decidimos intentar comprender las páginas mediante la ejecución de JavaScript. No era tarea fácil, dada la envergadura de la Web actual, pero pensamos que valía la pena intentarlo. Poco a poco hemos ido mejorando la forma de hacerlo. Durante los últimos meses, nuestro sistema de indexación ha procesado un número sustancial de páginas web de forma más parecida a cómo lo haría el navegador de un usuario normal con JavaScript activado.

Hay algunas cosas que a veces fallan durante el procesamiento, lo que puede afectar negativamente a los resultados de búsqueda de tu sitio. A continuación detallamos algunos problemas potenciales y, siempre que sea posible, la forma de evitar que se produzcan:
  • 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.

Para facilitar la depuración, estamos trabajando en una herramienta para ayudar a los webmasters a comprender mejor cómo procesa Google su sitio. Esperamos ponerla a tu disposición dentro de unos días en Herramientas para webmasters.

Si tienes alguna pregunta, visita nuestro 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.

viernes, 23 de mayo de 2014