Este año, en Google I/O hemos hablado sobre una posible solución: el renderizado dinámico. Hay muchas formas de implementarla, pero la que tratamos en esta entrada de blog es mediante Rendertron, un proyecto de software libre disponible en una versión sin interfaz gráfica de Chromium.
No todos los robots de los buscadores y redes sociales que visitan tu sitio web pueden ejecutar JavaScript. Por ejemplo, es posible que el robot de Google tarde un poco y que tenga algunas limitaciones.
Resulta útil emplear renderizado dinámico con contenido que cambia con frecuencia y necesita JavaScript para mostrarse.
La experiencia de usuario de tu sitio web (especialmente el tiempo que tarda en haber un primer renderizado importante) puede mejorarse si se utiliza un renderizado híbrido (por ejemplo, el Angular Universal).
El renderizado dinámico es un proceso mediante el cual se puede pasar del contenido renderizado del cliente al previamente renderizado y viceversa para determinados agentes de usuario.
Deberás tener un procesador para poder ejecutar JavaScript y generar archivos HTML estáticos. Se trata de un proyecto de código abierto que renderiza mediante un Chromium sin interfaz gráfica. Las aplicaciones de página única suelen cargar datos en segundo plano o retrasar su carga para renderizar su contenido. Rendertron tiene mecanismos que determinan si se ha completado el renderizado de un sitio web y espera hasta que todas las solicitudes de red hayan finalizado y no haya ningún proceso pendiente.
Esta entrada se divide en los siguientes temas:
La aplicación web Kitten Corner usa JavaScript para cargar varias imágenes de gatos de una API y las muestra en una cuadrícula.
|
const apiUrl = ‘https://api.thecatapi.com/v1/images/search?limit=50’;
document.querySelector(‘button’).addEventListener(‘click’, init);
La aplicación web usa un tipo de JavaScript reciente (ES6) que todavía no es compatible con el robot de Google. Con la prueba de optimización para móviles se puede comprobar si el robot de Google puede ver su contenido:
En la prueba de optimización para móviles se indica que la página está optimizada para estos dispositivos, pero en la captura de pantalla no aparece ningún gato. Aunque sí aparecen el título y el botón, pero no hay ninguna imagen de gatos.
Si bien este problema es fácil de solucionar, es útil saber cómo se configura el renderizado dinámico, puesto que permitirá que el robot de Google vea las imágenes de gatos sin que tengas que editar el código de la aplicación web.
Si quieres mostrar la aplicación web, utiliza express, una biblioteca Node.js, para compilar servidores web.
El código del servidor tiene una estructura similar a la que aparece a continuación. Si quieres, consulta el código fuente completo del proyecto.
Puedes probar este ejemplo: si usas un navegador moderno, deberías ver muchas imágenes de gatos. Para ejecutar el proyecto desde el ordenador, deberás tener node.js para ejecutar estos comandos:
A continuación, dirige tu navegador a http://localhost:8080. Ahora debes configurar el renderizado dinámico.
Rendertron ejecuta un servidor que toma una URL y devuelve un archivo HTML estático de la URL mediante el navegador Chromium sin interfaz gráfica. Sigue las recomendaciones del proyecto Rendertron y usa Google Cloud Platform.
Formulario para crear un proyecto de Google Cloud Platform |
Puedes elegir el nivel gratuito, pero debes tener en cuenta que, si te decantas por esta opción, usar aplicaciones de producción puede conllevar costes tal como se indica en los precios de Google Cloud Platform.
1. Crea un proyecto en la consola de Google Cloud. Consulta el ID del proyecto que aparece bajo del campo de entrada.
2. Instala el SDK de Google Cloud tal como se describe en el documento e inicia sesión.
3. Clona el repositorio de Rendertron desde GitHub con:
git clone https://github.com/GoogleChrome/rendertron.git
4. Ejecuta en tu ordenador estos comandos para instalar dependencias y compilar Rendertron:
5. Para activar el caché de Rendertron, crea un archivo llamado config.json en el directorio de Rendertron que incluye el siguiente elemento:
7. Selecciona una región, confirma la implementación y espera hasta que finalice.
8. Introduce en tu navegador la URL ID_DE_TU_PROYECTO.appspot.com, pero sustituyendo ID_DE_TU_PROYECTO por el ID de proyecto indicado en el paso 1. A continuación, debería aparecer la interfaz de Rendertron con un campo de entrada y botones.
Interfaz de Rendertron después de la implementación en Google Cloud Platform |
Si ves la interfaz web de Rendertron, significa que has implementado correctamente tu propia instancia de Rendertron. Apúntate la URL del proyecto (ID_DE_TU_PROYECTO.appspot.com), ya que la necesitarás en la siguiente fase del proceso.
El servidor web utiliza express.js y Rendertron tiene un middleware express.js. Ejecuta este comando en el directorio del archivo server.js:
Este comando instala el middleware de Rendertron desde npm, por lo que puedes añadirlo al servidor:
const express = require(‘express’);
const app = express();
const rendertron = require(‘rendertron-middleware’);
Rendertron utiliza el encabezado HTTP del agente de usuario para determinar si una solicitud proviene de un robot o del navegador de un usuario y lo compara con una lista actualizada de agentes de usuario de robots. Dado que el robot de Google puede ejecutar JavaSrcipt, la lista no incluye el robot de Google de manera predeterminada. Para que Rendertron también procese las solicitudes del robot de Google, añádelo a la lista de agentes de usuario:
Rendertron compara el encabezado de agente de usuario con esta expresión regular más adelante.
Para enviar solicitudes de robots a la instancia de Rendertron, su middleware debe estar incluido en nuestro servidor express.js. El middleware comprueba el agente de usuario que está haciendo las solicitudes y reenvía las de robots conocidos a la instancia de Rendertron. Añade el siguiente fragmento de código a server.js, cambiando “ID_DE_TU_PROYECTO” por el ID de tu proyecto de Google Cloud Platform:
Los robots que solicitan el sitio web de muestra reciben el archivo HTML estático de Rendertron, por lo que no hace falta que ejecuten JavaScript para mostrar el contenido.
Para probar si la configuración de Rendertron se ha hecho correctamente, vuelve a ejecutar la prueba de optimización para móviles.
A diferencia de lo que pasaba en la primera prueba, ahora aparecen las imágenes de gatos. En la pestaña HTML se muestra toda la página HTML generada por código de JavaScript y se indica que Rendertron deja que JavaScript no muestre el contenido.
Has creado una configuración de renderizado dinámico sin editar la aplicación web. Con estos cambios, puedes servir una versión HTML estática de la aplicación web a los rastreadores.
Publicado por Martin Splitt, Unicornio de la Red Abierta
Source: Google Webmasters
En el Centro de editores de Google Noticias, tenemos una gran cantidad de información útil que no debes perder de vista. Consulta esta sección, incluidas las directrices técnicas y las políticas de contenido.
Google Noticias quiere recompensar el contenido periodístico original e independiente mencionando al editor original como fuente fiable para ayudar tanto a los usuarios como a los propios editores. Esto significa que no permitimos contenido duplicado, incluido el copiado o el material que se ha vuelto a escribir o publicar para mejorar los resultados del contenido original. Teniendo esto en cuenta, hemos diseñado estas directrices que los editores deben seguir:
Los editores originales que permiten que otros vuelvan a publicar su contenido pueden asegurarse de que sus versiones originales estén mejor posicionadas en Google Noticias si piden a los otros editores que bloqueen su contenido o señalen como canónico al original.
Esperamos que estos consejos ayuden a los editores a tener éxito en Google Noticias durante este año. Si tienes alguna pregunta más sobre Google Noticias, debes tener en cuenta que no disponemos de asistencia directa, pero sí supervisamos nuestro foro de editores de Google Noticias, donde intentamos solucionar las cuestiones que pueden servir de ayuda a muchos editores. Este foro, además, es un recurso muy útil en el que se pueden ver los consejos que se dan los editores entre sí.
Publicado por Danny Sullivan, Relaciones Públicas de la Búsqueda
Source: Google Webmasters
Por lo general, migramos los sitios web a la indexación centrada en los móviles una vez que hemos comprobado que están listos para el cambio. Siempre notificamos a los propietarios de los sitios web a través de Search Console antes de hacer la transición. Para comprobar si estamos llevando a cabo este proceso en tu sitio web, echa un vistazo a los registros del servidor: en ellos deberías ver que la mayoría de las solicitudes pertenecen al robot de Google para smartphones. También puedes confirmarlo de un modo más sencillo: entra en la herramienta de inspección de URLs y consulta cómo se rastreó e indexó por última vez alguna URL de tu sitio web. Por lo general, basta con comprobar la página principal.
Si en tu sitio web utilizas técnicas de diseño adaptable, no tienes que hacer nada. Sin embargo, si no usas un diseño web adaptable, es posible que debas corregir dos de los problemas que detectamos más a menudo al evaluar sitios web:
Los datos estructurados son muy útiles porque nos ayudan a comprender mejor el contenido de tus páginas web y nos permiten mostrarlas con funciones especiales en los resultados de búsqueda. Si utilizas datos estructurados en la versión para ordenadores de tus páginas web, deberías incluirlos también en la versión para móviles, ya que es la que usaremos cuando implantemos la indexación centrada en los móviles. Por tanto, si no los incluyes, no los tendremos en cuenta.
Puede resultar complicado comprobar este aspecto, por lo que te recomendamos que verifiques todos los datos estructurados en general y, a continuación, los compares con los de la versión para móviles de tus páginas web. Para hacerlo, consulta el código fuente de la versión para móviles cuando simules un dispositivo móvil o utiliza el archivo HTML que se genera con la prueba de optimización para móviles. Ten en cuenta que, aunque una página web no esté optimizada para móviles, sí se incluirá en la indexación centrada en los móviles.
El atributo “alt” de las imágenes (es decir, el texto alternativo) es una buena manera de describir las imágenes a los usuarios con lectores de pantalla, que también se pueden utilizar en dispositivos móviles, y a los rastreadores de los buscadores. En consecuencia, si no añades texto alternativo a las imágenes que utilizas en tus páginas web, nos resultará mucho más difícil comprender su contexto e incluirlas en Google Imágenes.
Comprueba las etiquetas “img” en el código fuente de la versión para móviles de páginas representativas de tu sitio web. Tal como se ha mencionado anteriormente, puedes consultarlo simulando un dispositivo móvil con un navegador o consultando la versión renderizada del robot de Google mediante la prueba de optimización para móviles. Una vez que tengas el código fuente, busca etiquetas “img” y asegúrate de que las que quieras que aparezcan en Google Imágenes incluyan atributos “alt” con descripciones adecuadas.
A continuación te mostramos un ejemplo:
Con texto alternativo (bien):
<img src=”cute-puppies.png” alt=”Una foto de cachorritos en una manta”>
Sin texto alternativo (mal):
<img src=”sad-puppies.png”>
Es fantástico ver tantos sitios web que se muestran perfectamente en dispositivos móviles. Esperamos que cada vez se incluyan más sitios web en nuestro índice siguiendo la indexación centrada en los móviles para que los usuarios puedan buscar contenido en la Web tal y como han accedido a ella: con un smartphone. Continuaremos supervisando y evaluando este cambio con detenimiento. Si tienes alguna pregunta, visita el foro para webmasters o lee sobre nuestros eventos públicos.
Publicado por John Mueller, Google Suiza
Source: Google Webmasters
Source: Google Webmasters
Experto de Producto Plata: son los miembros más nuevos que están desarrollando su conocimiento de los productos.
Experto de Producto Oro: son los miembros de confianza que conocen bien los productos y participan de manera activa.
En noviembre, invitamos a los Expertos de Producto Oro de todos nuestros foros de ayuda de Google (como Blogger o Google Mi Negocio) a un evento global celebrado en el campus de Google en Sunnyvale, California. De los casi 550 asistentes de todo el mundo, unos 70 eran Expertos Webmasters. Procedentes de 25 países distintos, el nuestro era el segundo grupo más numeroso del evento. Ese mismo mes, se celebró en Moscú otro exitoso encuentro, con 23 Expertos de Producto rusohablantes, 10 de los cuales eran Webmasters.
Webmasters Expertos de Producto Oro en el evento global de este año en Sunnyvale. |
Este grupo de superusuarios presta una ayuda inestimable en 16 idiomas a más de dos millones de usuarios cada año, en temas relacionados con la Búsqueda, los datos estructurados o Search Console.
¿Cuál es el perfil de nuestra comunidad? Muchos de nuestros Expertos de Producto, Oro y Plata, son propietarios de sitios web que empezaron en el foro para Webmasters preguntando dudas sobre sus propios sitios, algunos hace más de una década. Una vez resueltos sus problemas, la mayor parte de ellos se dieron cuenta de que sus conocimientos podían ser de ayuda a otras personas y se quedaron para devolver el favor a la comunidad. Queremos dar las gracias a todos nuestros expertos por su dedicación y por compartir siempre sus conocimientos para ayudar a otros usuarios que tienen problemas con sus sitios web.
A lo largo del año, hemos tenido más de 75 videoconferencias en directo desde nuestro canal de YouTube para Webmasters, en alemán, francés, hindi, inglés, japonés y, por primera vez, también en español. En estas conversaciones, todos los usuarios pueden hacer preguntas directamente al equipo de Google e interactuar los unos con los otros.
Si te interesa unirte a la comunidad, conocer a sus miembros y ayudar a otros usuarios en el foro para Webmasters, consulta más información al respecto en la página web del programa de Expertos de Producto. Nos encanta conocer a usuarios de procedencias y habilidades diversas.
Estamos deseando ver qué novedades llegarán a nuestra comunidad en 2019... ¡Y esperamos conocerte!
Escrito por Aurora Morales, del equipo de Confianza y Seguridad
Source: Google Webmasters
Si tienes alguna pregunta, háznosla llegar por el foro de ayuda para webmasters o por Twitter.
Publicado por Kayla Hanson, ingeniera de software
Source: Google Webmasters
PageSpeed Insights proporciona los siguientes datos:
●Datos de experimentos. PSI obtiene y analiza las páginas web mediante Lighthouse, que simula el modo en que los dispositivos móviles las cargan. Esta herramienta calcula varias métricas de rendimiento de las páginas web (como Primer renderizado con contenido y Tiempo hasta que está interactiva) y resume todos estos datos en una puntuación de rendimiento que va de 0 a 100. En estas puntuaciones, que se categorizan en tres niveles, 90 puntos o más se considera un buen resultado.
●Datos de campo. PSI también muestra métricas de rendimiento reales (como Primer renderizado con contenido y Latencia de la primera interacción) tanto de la página web como de su origen; al existir esta última posibilidad, hemos desactivado las consultas de origen en PSI. No todos los sitios web tienen datos de campo que se puedan mostrar. Este conjunto de datos se basa en versiones del informe “Experiencia de Usuario de Chrome”, que se actualiza a diario con los datos agregados de los 28 días anteriores. Estas métricas pueden ser diferentes a las descritas en el punto anterior, ya que abarcan un amplio espectro de condiciones de red y dispositivos utilizados por usuarios de Chrome.
●Oportunidades. PSI sugiere cómo mejorar las métricas de rendimiento de la página web y, con cada sugerencia, incluye una estimación de la velocidad a la que cargará esa página si se llega a implementar la mejora.
●Diagnósticos. Esta sección proporciona información adicional sobre cómo está cumpliendo una página web con las prácticas recomendadas en cuanto al desarrollo web.
La versión 5 de la API PSI muestra este nuevo análisis junto con datos del informe de Experiencia de Usuario de Chrome, además de todas las categorías de datos de Lighthouse de una URL, incluidas las de rendimiento, aplicación web progresiva, accesibilidad, prácticas recomendadas y SEO.
Consulta más información sobre estos cambios en nuestra sección Preguntas frecuentes. Si tienes alguna pregunta más, hazla en la comunidad de Stack Overflow y márcala con la etiqueta pagespeed-insights.
Publicado por Rui Chen y Paul Irish
Source: Google Webmasters
Pongamos como ejemplo que Andrea está navegando por la Web mediante una conexión móvil para acceder a una página de videojuegos en la que se le pide su número de teléfono.
Andrea introduce su número de teléfono móvil y, tras enviarlo, accede al contenido que quería.
Al mes siguiente, le llega la factura del teléfono y ve un cargo que no esperaba. ¿Era tan cara la suscripción al servicio de juegos online? ¿Aceptó pagar ese precio por el servicio? ¿Cuánto aceptó que se le cobrara para poder acceder al contenido?
Queremos que los usuarios de Chrome sepan que están en un proceso de pago y puedan confiar en que tomarán decisiones bien informadas cuando naveguen por la Web.
Para que los usuarios tengan la información necesaria, es importante facilitar todos los detalles en la página de facturación, tal y como se describe en nuestras nuevas prácticas recomendadas sobre cargos de facturación móvil. En términos generales, se considera que las páginas que responden afirmativamente a las siguientes preguntas son las que facilitan a los usuarios toda la información necesaria:
●¿Los datos de facturación se muestran claramente a los usuarios? En este caso, al responder negativamente se indica que un sitio web oculta o no cuenta con información sobre una suscripción en la página correspondiente, ya que los usuarios deben tener acceso a esos datos antes de suscribirse.
●¿Los clientes pueden ver claramente los costes que se les van a aplicar antes de aceptar las condiciones? Por ejemplo, no se considera una buena práctica que los datos de facturación se muestren en caracteres grises sobre un fondo gris, ya que a los usuarios les cuesta más leerlos.
●¿Los desgloses de las tarifas se entienden con facilidad? La fórmula presentada para explicar cómo se determina el coste del servicio debe ser lo más sencilla y directa posible.
Si Chrome detecta que en una página no se incluyen los datos de facturación que los usuarios necesitan, en los navegadores Chrome para móviles y para ordenadores, así como en WebView de Android, aparecerá esta advertencia:
Esta es la advertencia que se muestra a los usuarios que están accediendo a páginas de facturación poco claras.
Cuando detectemos este problema en alguna página, enviaremos una notificación a su webmaster a través de Search Console, donde tendrá la opción de informarnos sobre los cambios que ha hecho para hacer más claro el proceso de pago. En el caso de los sitios web que no se han verificado en Search Console, haremos todo lo posible para ponernos en contacto con los webmasters correspondientes y estaremos a su disposición para responder preguntas en nuestro foro público de ayuda, disponible en 15 idiomas. Una vez que se haya recibido una respuesta en Search Console, revisaremos los cambios y, si procede, quitaremos la advertencia.
En el caso de que tu servicio de facturación dirija a los usuarios a un proceso de pago claramente visible y comprensible, tal como se describe en nuestras prácticas recomendadas, no es necesario que hagas nada más. Además, esta nueva advertencia de Chrome no afectará al posicionamiento de tu sitio web en la Búsqueda de Google.
Si tienes alguna pregunta, ponte en contacto con nosotros a través del foro de ayuda para webmasters.
Publicado por Emily Schechter, del equipo Seguridad de Chrome, y por Giacomo Gnecchi Ruscone y Badr Salmi El Idrissi, del equipo Confianza y Seguridad
Source: Google Webmasters
La tecnología de reCAPTCHA no ha dejado de evolucionar durante esta década. En la primera versión, se pedía a los usuarios que leyeran un fragmento de texto distorsionado y lo escribieran en un cuadro de texto. Con el objetivo de mejorar tanto la experiencia de usuario como la seguridad, después presentamos reCAPTCHA v2, en la que se incluyeron muchos indicios diferentes para determinar si una respuesta procedía de personas o de robots. En esa versión, el reto en sí perdía importancia a la hora de detectar el tráfico abusivo, y aproximadamente la mitad de los usuarios pasaba con tan solo hacer un clic. Con reCAPTCHA v3, evoluciona el modo en que los sitios web comprueban si se trata de un usuario humano o de un robot, puntuando cada interacción según lo sospechosa que parece y, de esta forma, eliminando la necesidad de interrumpir con retos la experiencia de los usuarios. Esta versión realiza análisis de riesgo adaptables en segundo plano y te avisa en caso de que haya tráfico sospechoso, por lo que en todo momento tus usuarios humanos pueden disfrutar de una experiencia fluida.
En reCAPTCHA v3 hemos incluido las etiquetas “action” (acción), en las que se definen los pasos clave de la navegación de tu usuario y que facilitan contexto a reCAPTCHA antes de que haga su análisis de riesgo. Puesto que con esta versión no se interrumpe la experiencia de los usuarios, recomendamos añadirla a varias páginas. El motor de este tipo de análisis investiga la actividad que ha tenido un usuario en diferentes páginas web y puede identificar patrones de atacantes de forma más precisa. En la consola de administración de reCAPTCHA puedes ver un resumen completo de la distribución de resultados de la API y un desglose de los datos de las 10 acciones que aparecen con más frecuencia en tu sitio web. Así puedes identificar a qué páginas web concretas están atacando los robots y si el tráfico de esas páginas se consideraba sospechoso.
Otra de las principales ventajas de reCAPTCHA v3 es la flexibilidad que hay a la hora de configurar estrategias de prevención de spam y usos inadecuados de tu sitio web del modo que mejor se adapte a ti. En las versiones anteriores, el sistema de reCAPTCHA decidía qué captcha mostrar a los usuarios y cuándo, por lo que apenas podías mejorar la experiencia de los usuarios de tu sitio web. Esto ya no es así en esta nueva versión, que puntúa las actividades según lo sospechosas que parecen y te da diversas opciones. En primer lugar, puedes definir un umbral para determinar cuándo se deja entrar a un usuario o cuándo se debe hacer una verificación más exhaustiva, ya sea pidiendo una autenticación de dos factores o una verificación por teléfono, etc. La segunda opción es tener en cuenta tanto esa puntuación como indicios a los que reCAPTCHA no puede acceder, como su perfil de usuario o su historial de transacciones. Por último, puedes usar el resultado de reCAPTCHA para configurar un modelo de aprendizaje automático que proteja contra usos inadecuados. Ahora que puedes tomar medidas personalizadas según los distintos tipos de tráfico, con esta versión puedes proteger tu sitio web frente a robots y mejorar la experiencia de los usuarios según las necesidades específicas de tu sitio web.
En resumen, gracias a reCAPTCHA v3 puedes proteger tus sitios web sin interrumpir la experiencia de los usuarios y dispones de más control a la hora de decidir qué se debe hacer en situaciones de riesgo. Nuestro objetivo cada día, como siempre, es ir un paso por delante de los atacantes y lograr un Internet fácil y seguro para todos (salvo para los robots).
¿Todo listo para empezar a usar reCAPTCHA v3? Consulta más información en el sitio web para desarrolladores.
Publicado por Wei Liu, directora de producto de Google
Source: Google Webmasters
Experto de Producto Oro: son los miembros de confianza que más conocimientos tienen y más colaboran.
Experto de Producto Platino: son miembros experimentados que, además de ayudar, colaboran dando orientación, creando contenido y mucho más.
Antiguo Experto de Producto: son miembros que ya no están en activo, pero que en su día obtuvieron reconocimiento por sus contribuciones.
Más información sobre los nuevos nombres e insignias disponible aquí.
Source: Google Webmasters