Como renderiza Google una web
Cuando tienes una web, el HTML que se escribe, no es el HTML que termina viendo el usuario, ya que puede haber un CDN, un CMS, o cualquier tecnología que acabe produciendo que haya esa diferencia entre el código y lo que se muestra.
El renderizado es el proceso de convertir el HTML en pixeles.
Esto quiere decir que el renderizado es el proceso de transformar en pixeles (lo que se ve en pantalla) el HTML que se envía. Y este resultado en la pantalla suele ser interactivo, por ejemplo, puedes hacer scroll o clic.
Para entender cómo afecta al SEO, hay que entender cómo funciona paso a paso el proceso que hay entre el servidor y el usuario.
Los navegadores y Google, no leen exactamente el HTML, sino el DOM tree.
Con este esquema, es mucho más sencillo entender el proceso con el que un navegador lee realmente el código y entender como se hace esa categorización que realmente acaba permitiendo la interacción.
El DOM por tanto no tiene por qué ser estático. Puede haber un elemento, que al hacer clic cree otros elementos que acaban haciendo un cambio en la estructura de ese DOM. Y estos cambios se suelen hacer con JavaScript, ya que es el lenguaje que interactúa con el usuario (los navegadores), es decir, a diferencia de con otros lenguajes, los navegadores son capaces de leer el JavaScript y procesarlo.
Esto suele ocurrir con casi todas las webs. Que ocurra esto, no supone en absoluto ningún problema a nivel de SEO. Aunque cambie un 100% de la página no debería suponer un problema. De hecho, un concepto que suele preocupar a cualquier SEO que trabaja con un Framework de JavaScript es la renderización de cara a Google.
Google cuando rastrea con JavaScript hace el mismo proceso y hace un Snapshot (captura de pantalla) que es la que se tomará en cuenta para la indexación. Siempre y cuando el JavaScript transforme el DOM antes de que se produzca dicho Snapshot de Google, no debería haber problema. En teoría Google suele acertar bastante en decidir cuál es el momento adecuado para hacer la captura del contenido.
El DOM sirve también para hacer un esquema de distribución de los elementos, y entender dónde va cada uno de ellos (aunque se pueda alterar visualmente por medio de CSS).
En la ponencia explica este ejemplo de cómo el JavaScript afecta en una página. Podemos apreciar en esta secuencia de descarga (en la foto), cómo el JavaScript (amarillo) modifica el HTML (el azul que se ve después del amarillo) y cómo después aparece mucho CSS (lila) en el ejemplo que tarda más de 1 segundo en la descarga. Esto puede ocurrir tanto en webs que utilicen JS para la creación del DOM como en webs que no, ya que es simplemente un código mal hecho o no optimizado.
Como consecuencia, puede ser que el contenido renderizado por Google, no corresponda con lo que queremos que se muestre al usuario y, por tanto, tener un problema en la indexación y posicionamiento de nuestra página.
Google no necesita los pixeles ni la transformación al renderizado, porque no la utiliza. Según Martin Splitt, no se necesita una captura de pantalla más larga en la Search Console, ya que lo que usa Google como referencia es el código fuente del URL Inspection Tools, lo que aparece en el DOM cuando hace la captura.
El sistema de indexación es un conjunto de microservicios hablando entre ellos.
Google envía solicitudes a distintas páginas y espera una respuesta de ellas. Dependiendo de la interacción y cómo actúen, decidirá un momento u otro para realizar la captura (Snapshot) si procede.
No es un robot físico, por lo que analiza diferentes páginas y diferentes webs al mismo tiempo. Por ejemplo, una página puede ser que acabe recibiendo un código de respuesta de error y decida ignorar la página, mientras que en otra que está rastreando a la vez, puede ser que traiga toda la información de forma correcta y se procese bien para el indexado.
Los microservicios son un conjunto de procesos que realiza Google antes de llevar a cabo la indexación de una página. Con estos microservicios comprueba si una página es interesante para ser indexada o no. Este es el listado de microservicios en el que Google ramifica la tarea de indexación:
El Web Rendering Service (WRS) es uno de los microservicios que forman parte de esas "preguntitas" que hace Googlebot a una página antes de proceder a su indexación. Se podría decir que el Web Rendering Service es la "magia" que hace que funcione y se entienda el Javascript. Esto es más fácil de entender para quien ha probado headless Chrome.
Cuando se ha rastreado la página, pasa por el servicio de renderizado web, y acaba creando ese DOM que es el que Google capturará, y lo que se verá en los resultados del URL inspector de la Search Console.
No importa si una web tiene JavaScript o no, pasará por el servicio de renderizado y acabará utilizando lo que salga en la captura de ese DOM Tree.
Actualmente Google no tardará más o menos en indexar por tener o no tener JavaScript, sino por otros motivos. Es decir, que JavaScript no afecta en el tiempo de indexado.
Se podría dividir en el propio core del WSR y el cacheo. El Cacheo es importante, ya que esperar a la respuesta continua de otros servidores en internet consumía muchos recursos y tiempo. Por medio del caché Google consigue manejar el volumen enorme de webs que rastrea a diario.
Cuando se utiliza la herramienta de Search Console para hacer un live test, va directamente al procesamiento del servidor. No a lo que tiene Google en ese momento en caché (si no, no sería un testeo en vivo). Pero eso no quiere decir que Google lo tendrá en cuenta en ese mismo instante, se podría ver lo que está teniendo en cuenta Google con el cacheo, ya que tiene que rastrear todo internet, así que tomará el tiempo que necesite para los cambios pertinentes de cara a la indexación o el ranking. Aunque al usuario le salga ya la corrección en el live testing tool.
Básicamente, esto quiere decir que Google tiene en cuenta la versión que tiene en caché de cada página y, lo que vemos en la Search Console (cuando le damos a Captura de pantalla), es una versión actual de la web, no la que tiene en caché. Así que Google pone en cola la tarea de revisarlo cuando hacemos ese live test. Por lo tanto, el live test es para nosotros y Google tiene en cuenta lo que haya guardado en caché.
Google utiliza todos los procesos de la imagen para el renderizado correcto de una página. Si por algún motivo, le falla un navegador al cargar la página, va probando con otros varias veces para asegurarse de que es correcto (por ejemplo también es una forma de prevenir el cloaking).
En cualquier caso, esto último es trabajo de Google, por lo cual no es información tan relevante para el SEO. Simplemente quiere decir que prueba varias veces el rastreo con el navegador, para tener un resultado objetivo.
Esta pregunta se refiere a las webs que por optimización de caché emplea archivos temporales como como "/232498r32d.js".
Estos archivos se van reconvirtiendo y teniendo otro nombre con el tiempo por una cuestión de rendimiento. En el caso de la renderización, el caché de ese archivo almacenado por Google se invalida cuando cambia el archivo, pero no empeora el rendimiento.
Si la página está bien desarrollada, no debería haber problema alguno, y el híbrido tiene sentido, en el caso de que tenga sentido para la web, pero no con el propósito de SEO. (Revisar Renderizado de JavaScript para entender esta pregunta)
Como me quedó la duda con el renderizado dinámico, le pregunté a Martin Splitt después por Twitter y su respuesta fue bastante categórica:
Google ya es capaz de renderizar el JavaScript de una forma correcta, por el tiempo que tarda en hacer la captura del Snapshot. Esto no quiere decir que Google no tenga problema con los lazy loadings o que cualquier página se renderice para Google de forma correcta.
En cualquier caso lo podemos auditar comprobando el código que sale cuando le damos a comprobar el código en el inspector de URLs de la Search Console
Te falta mi máster. Accede a una formación avanzada que te permitirá aplicar e implementar SEO en cualquier tipo de WEB
¡Accede al Máster de SEO Técnico!Si te ha gustado esta publicación, siempre me lo puedes agradecer dándome like en esta publicación de LinkedIn sobre este mismo artículo.
