La segunda ola de indexación y cómo saber qué renderiza Google

Publicado por Lino Uruñuela el 23 de julio del 2018

Desde hace ya unos años venimos viendo cómo Google es capaz de cargar e indexar ciertos contenidos via javascript, en este blog hemos hecho muchos experimentos sobre  cómo Google rastrea e indexa el contenido cargado mediante JavaScript.

Los últimos experimentos sobre Google e indexación de javascript fueron encaminados a intentar saber si Google era capaz de ejecutar funciones javascript "complejas" y si era capaz de acceder e indexar el contenido cargado mediante llamadas Ajax y hemos comprobado cómo Google accedía e indexaba estos contenidos por muy ofuscados que hiciéramos esas llamadas JavaScript, siempre y cuándo este código se ejecutara automáticamente sin interacción del usuario, por ejemplo en contenido cargado en el onReady o onLoad

Los resultados y las conclusiones de este experimento los podéis ver con más detalle en este post sobre cómo ejecuta, rastrea e indexa el contenido cargado mediante javascript.

A tener en cuenta: cuando hablo de JavaScript hablo de las versiones compatibles con Google Chrome 41, que no es totalmente compativle con la versión ECMAScript 6 de JavaScrtipt

Analizando cuándo y qué urls renderiza Google

Cuando analizamos los logs del servidor generados por Google podemos observar algo muy importante, y que a todos se nos había pasado por alto, cuándo Google carga recursos como ficheros javaScript, hojas de estilo css o urls de contenido cargadas mediante ajax en todos estos casos lleva en el campo referer la url de origen, y esta es la url que está siendo renderizada!.

En este ejemplo podemos ver en el campo "URL" la URL de origen, con fondo verde, /Posicionamiento/interpreta-google-el-javascript.php, y en rojo las urls de contenido cargadas por javascript como por ejemplo /metodos-javascript-cargaContenido.php y también urls de hojas de estilos css o urls de recursos js. 


Segunda oleada Google

 

No me había dado cuenta de la importancia de esto hasta que escuché la famosa presentación que Tom Greenaway y John Mueller dieron en el Google I/O de este 2018, dónde explicó cómo Google procesa los contenidos cargados mediante javascript.

Resumiendo podemos decir que Google procesa el contenido de una url en dos procesos / fases / olas. En una primera ola Google funciona cómo siempre lo hemos entendido.

Primera ola de indexación

  1. Accede a la url que tiene en su lista de urls a rastrear.
  2. Obtiene el HTML de esa url, sin ejecutar JavaScript. Es lo que vemos cuándo le damos al botón dercho del ratón y seleccionamos "Ver código fuente de la página").
  3. Evalua en base a multitud de variables ese HTML obtenido y decide si la indexa y qué imporancia da al contenido de esa url.

Pero John Mueller nos aclaró un tema muy importante, si en la url a la que accede Googlebot se carga contenido mediante javascript, Google volverá a acceder a esa url cuándo tenga recursos disponibles, y esta vez renderizando el DOM y ejecutando JavaScript, concretamente el navegador Chrome41, a esto lo ha denominado "la segunda ola".

En esta segunda ola Google realizará los siguientes pasos

Segunda ola de indexación

  1. Accede a la url que tiene en su "lista de espera" por renderizar
  2. Obtiene el HTML de esa url.
  3. Evalua en base a multitud de variables el HTML de la url de origen renderizado, es decir evaluará el contenido y recursos cargados en la rederización

Esta gran pista me sirvió de inspiración... ¡eureka!, me di cuenta de que muchos de los resultados que estábamos viendo en los experimentos con JavaScript antes mencionados se podrían explicar perfectamente si tenemos en cuanta esta nueva información sobre este renderizado que hace Googlebot en la segunda ola de indexación.

Cuándo dije que "Google indexa lo que permanece", era cierto! y ahora sabemos el por qué. Google en una segunda ola, entrará en la url del experimento y  obtendrá el HTML, pero renderizará el DOM y ejecutará JavaScript, por lo que cargará el contenido de cada uno de los diferentes escenarios planteados en el experimento, recordamos cuáles eran:

  1. Carga de contenido tras pasar entre uno y cinco segundos
  2. Carga de otro contenido tras pasar entre 5 y 10 segundos
  3. Carga de otro contenido diferente al trasnscurrir al menos 10 segundos).

Ahora podemos entender mejor por qué Google solo indexaba el contenido cargado tras más de 10 segundos, porque es el HTML resultado del renderiazado completo del DOM. El HTML renderizado es lo que vemos cuando hacemos click en botón derecho del navegador y seleccionamos "Inspeccionar elemento". Este código HTML generado tras la renderización es el HTML final que Google valorará en esta segunda ola.

Una vez renderizado el documento por parte de Googlebot, el contenido que en él haya será el contenido que se indexe, y aquel contenido que no esté, no se indexará.


¿Cómo podemos saber que urls esta renderizando?

Un tema muy importante es saber qué urls está renderizando Google y cada cuánto tiempo lo hace. Esto se convierte en algo crítico para el SEO en aquellas páginas webs basadas en JavaScript, sobretodo si no se realiza un prerenderizado desde el servidor para servir el HTML ya renderizado a Googlebot en la primera ola.

En el SEO para webs en JavaScript conocer a qué contenido es capaz de acceder Google es indispensable para saber si está teniendo problemas a la hora de cargar ese contenido, también para saber cada cuánto renderiza las urls, y cuánto tiempo tarda desde que accede en la primera ola hasta que lo hace en la segunda ya que durante ese intervalo de tiempo Google solo indexará el contenido obtenido sin renderizar durante la primera ola.

Analizando los logs del servidor podemos sacar algunos puntos que se dan en  todos los casos;

  1. Cuando Google accede a la url de origen, lo hace con el campo referer vacío.



  2. Los recursos cargados desde esa url de origen por parte del navegador, ya sean urls de contenido ajax, hojas de estilo o ficheros js llevan todas en el campo referer la url de origen.



  3. Los accesos a la url de origen y a las urls o recusos cargados en el renderizado se dan en un pequeño periodo de tiempo, podemos decir casi al 100% que en un periodo de tiempo menor a  un minuto.



  4. El User Agent con el que accede contiene "Googlebot", tanto para la url de origen como para las urls javascript o recursos cargados. Aquí la lista completa de las distintas versiones de Googlebot según su User Agent para hacer las comprobaciones del tipo de Bot

Y de forma menos general, pero que se suele dar cuándo Google renderiza una url

  1. Google a veces espera el tiempo definido en el setTimeout de JavaScript, pero a veces se salta ese tiempo de espera y ejecuta el javascript casi inmediantemanete.
  2. No siempre que accede a una url de origen la renderiza, la mayoría de las veces accede a la url pero no hay un renderizado posterior. 
  3. No siempre carga todos los recursos o urls de contenido, a veces carga solo un css, a veces carga todos los recursos, a veces solo una url de contenido... deberemos investigar mejor este comportamiento y saber que no siempre carga todo ni siempre lo mismo.

Ejemplo SQL para saber las urls que Google renderiza

Si tenemos los logs en una base de datos con los siguientes campos, Fecha, path, Status, Referer, User Agent podriamos obtener las urls que han sido renderizadas obteniendo el valor del campo referer de las urls que cumplen estas dos condiciones;

  1. El User Agent contiene "Googlebot", por supuesto debemos comprobar que realmente sea Google, esto se puede hacer con un reverse DNS.
  2. El campo referer no está vacío, esto querrá decir que la url de este log ha sido cargada desde la url que aparece en e campo referer. En nuesto caso el valor de este campo es https://www.mecagoenlos.com/Posicionamiento/interpreta-google-el-javascript.php

Representando esto en SQL sería:

SELECT 
fecha, 
referer
FROM Logs 
WHERE (UA LIKE '%Googlebot%') AND ((fecha >= '2018-03-01') 
AND (fecha <= '2018-07-01')) AND (referer != '-')
GROUP BY 
fecha, 
referer

Y nos devolvería los siguientes resultados, dónde el campo "Referer" es la url de origen, es decir, la url que ha sido renderizada.


Segunda ola Google referr


Con esto ya podemos saber qué y cuántas urls están siendo renederizadas diariamente  por Google, y añadir a nuestro dashboard un dato cada vez más importante.

Además podremos saber qué recursos están dando error 404, que tamaño tienen los recursos descargados y cuánto tiempo tarda Google en descargarlo. Sin duda se puede rascar mucho para merjorar la velocidad de carga y saber cuáles son los recursos que debemos revisar.

Si quieremos ir un poco más allá y saber cuántas y qué urls están siendo cargadas desde cada url de origen también podemos conocerlo.

Hay un dato que TODAVÍA no he sido capaz de sacar y es cuántas veces ha sido renderizada una url. Este problema me lo planteó Iñaki Huerta, al que también le gustan bastante estos retos. Iñaki ideó un método que podría ser el más cercano al número de cuántas veces al día renderiza Google una url, pero esto ya os lo contará él y muchas más cosas relacionadas en el seoPlus del fin de semana que viene en Alicante.

 


César Apariciohace Hace más de 1 años y 57 días

Hola Lino,

Nos conocemos de películas como: Los de Google son muy frikis o Pasodobles y SEO.

Mi cuestión es la siguiente: entiendo que con una función setInterval() en la segunda ola renderice el contenido porque será el mismo pero saltarse el setTImeout () me parece "regular" porque podemos ir invocando cosas diferentes. ¿Qué opinas?

Un placer leerte y, como siempre, gran post.

Lino Uruñuelahace Hace más de 1 años y 57 días

@Cesar saltarse alguna orden del código es un falta de respeto!, que para algo lo hice :D

No se les da muy bien esperar, su tiempo es oro parece... Pero muchas veces sí espera el tiempo del Timeout. Pero pensando que, en tiempo de computación 10 segundos es una burrada, multiplica eso por la cantidad de urls que hay en internet

FDMhace Hace más de 1 años y 57 días

Hola, Lino:

Genial el post, como siempre. Es genial contar con personas tan curiosas y que investigan al detalle el funcionamiento de Google.

Quería lanzarte una pregunta. ¿Cómo se puede ver el onLoad y el onReady? ¿Son eventos que aprecen en la consola de Chrome/Mozilla? Agradecería que me pudieras explicar esto, o bien si lo prefieres escribir un post con este detalle.

Gracias de antemano


Contacta

Lánzate y pregunta!


He leído y acepto la política de privacidad

Mecagoenlos.com te informa que los datos de carácter personal que nos proporciones rellenando el presente formulario serán tratados por Lino Uruñuela. como responsable de esta web.

La finalidad de la recogida y tratamiento de los datos personales que te solicitamos es para enviar un correo con los datos que introduzcas, sin guardarse en ninguna base de datos.

Legitimación: Al marcar la casilla de aceptación, estás dando tu legítimo consentimiento para que tus datos sean tratados conforme a las finalidades de este formulario descritas en la política de privacidad.

Como usuario e interesado te informamos que los datos que nos facilitas estarán ubicados en los servidores de Linode.com (proveedor de hosting de Mecagoenlos.com) cumpliendo la ley de protección de datos. Ver política de privacidad de Linode.com.

Podrás ejercer tus derechos de acceso, rectificación, limitación y suprimir los datos en info@mecagoenlos.com, así como el derecho a presentar una reclamación ante una autoridad de control. Más información aquí.

Últimos posts

Últimos comentarios


Javier

Buenas Lino, ¿Alguna novedad sobre cómo considera Google los links en PDFs? Se me ocurre que, siguiendo con este experimento, se po
Post: Link building con PDF

Francisco

Flaco. Por lo general, no dejo comentarios pero, en tu caso, voy a hacer una excepción pues, sencillamente... ¡sos un genio!, Gracias.
Post: Cómo cargar css y js y no bloquear la carga de contenido

Juan Francisco Gancia

Excelente artículo, gracias! Te encuentro de casualidad por un post de hace 10 años.
Post: Diferencias entre url indexada y url accesible

Lino Urnuela

@Emirodgar gracias! Pero parece que en tema de imágenes las pilla lo hagas cómo lo hagas parece, eso sí, siempre que no tengas un fall
Post: Indexar imágenes en Google usando Lazy Load

Emirodgar

Muy interesante el experimento. Yo estaba probando con los nuevos formatos webp y pero al final, como eran pocas imágenes y usaba Masonry,
Post: Indexar imágenes en Google usando Lazy Load

Lino Uruñuela

Completamente de acuerdo :) Pero en este experimento solo quería comprobar el método usado para hacer lazy load, en este caso con xmlht
Post: Indexar imágenes en Google usando Lazy Load

Francisco Morales

Lino muy interesante las distintas formas de cargar la imagen. Pero no crees que lo realmente interesante de aplicar Lazy Loading es cargar
Post: Indexar imágenes en Google usando Lazy Load

javier

Buenas , esto del onclik ha cambiado actuamente en algunas web que tengo las lee y sigue enlaces
Post: ¿Cómo ejecuta, interpreta e indexa Google el contenido cargado mediante javascript?

David Girona

Antes de Nada muchas gracias por la aportación. Estoy probando de poner en marcha este procedimiento y me surgen un par de dudas. En
Post: Cómo añadir el valor del meta Robots a Google Analytics via Google Tag Manager

Javier Espinoza

Gracias por la informacion!! Este tipo de blogs me parecen muy importantes, esto lo estudio en la universidad. gracias por la informacion. h
Post: Atacados por los .cn .cz .pl