GUÍA: Google, Javascript y SEO

20 mayo, 2019
SEO

El Javascript se ha convertido una parte fundamental de la web. El número de bytes de Javascript descargados aumenta de forma sustancial cada año.

Índice de contenidos

¿Cómo lee Google Javascript?

Google lee más de 160 trillones (trillones americanos xD) de documentos diarios, lo que es, incluso para Google, un gran trabajo. Leer Javascript cuesta tiempo y dinero.

Los SEOs han visto como la forma tradicional crawling-indexing ha cambiado. Google deja el renderizado de Javascript para una segunda ola de indexación. Es como si dijera, “uyy esto me va a llevar tiempo y lo dejara en un cajón para después”. Lo podemos ver en esta gráfica:

Tipos de Frameworks

Los Javascript Frameworks contienen librerías, componentes e instrucciones para crear websites. Cada una de ellas contiene sus particularidades, por lo que habrá que analizar pros y contras antes de decantarse por una de ellas.

Métodos de renderizado

SSR Server side rendering

El cliente (navegador) recibe un HTML final y que funciona sin necesidad de ejecutar y renderizar el JavaScript. El servidor se encarga de renderizar todo el Javascript.

A favor:

+ Mejor para SEO y Crawlers

+ Mejor funcionamiento

+ Más velocidad

En contra:

Más caro
Puede ser más difícil de implementar
Más carga para el servidor
Mayor tiempo de TTFB (TIME TO FIRST BYTE)

CSR – Client Side Rendering

El navegador hace una petición y se encarga de pintar la página en base a todos los recursos que recibe.

A favor:

+ Es bueno para aligerar la carga en el servidor.

En contra:

Carga la CPU y los dispositivos
Más tiempo en cargar
Malo para SEO. Muchos crawlers (Google normalmente sí) no lo siguen

DR – Dynamic Rendering

Googlebot (y otros bots) recibe una versión SSR, y el resto de User-Agents aquella que consideremos mejor (CSR o Hybrid Rendering)

A favor:

+ Bueno para SEO

+ BING lo recomienda

+ Esencial para sitios JS en los que el contenido cambie a menudo

En contra:

Los navegadores siguen teniendo que renderizar el JS
Complejidad
Carga el servidor

Pre Renderizado

Instala y configura un procesador dinámico para transformar tu contenido en código HTML estático que los rastreadores puedan consumir con mayor facilidad. Algunos procesadores dinámicos conocidos son Puppeteer, Rendertron y prerender.io. Google developers

Este procedimiento puede hacer que el servidor funcione más lento

Hybrid rendering

Hybrid Rendering es una combinación de Server-Side y Client-Side. El contenido core o esencial es renderizado en el servidor y cuando el contenido éste ha sido mostrado, más JavaScript es enviado para ser renderizado del lado del cliente para que pueda interactuar con la página.

A favor:

+ Rapidez

+ Bueno para SEO

En contra:

Todas las utilidades JavaScript no están disponibles hasta que no se ha renderizado parte del lado del cliente
Complejidad de implementación

Ejemplo: Nike

Isomorphic JavaScript

Javascript que puede ser renderizado en el lado del servidor y el lado del cliente. Se pre renderiza del lado del servidor, pero para ser interactivo requiere de renderizarse del lado del cliente.

A favor:

+ Bueno para SEO

+ Bueno para el usuario

+ Rapidez

Pocos ejemplos. AIrbnb y Twitter están haciendo pruebas.

En contra:

Servidor necesita soportar Node JS
Complejo de implementar

*Recomendado por el SEO de EA Sports

Qué ver en una Auditoría Javascript:

Hay que comprobar el HTML inicial vs el DOM renderizado. Ver qué cambia y si lo que cambia es importante.
Comprobar si Google puede acceder al contenido. Comprobar LOGS.
Comprobar si se está indexando el contenido.
Comprobar como renderiza el contenido en diferentes dispositivos.

Herramientas

Existen numerosos métodos para comprobar el renderizado JS de tu web. Destacamos estos métodos o herramientas:

Inspection Tool en Search Console

Mobile-friendly Test

El Test Mobile-friendly de Google nos devuelve el HTML renderizado

Rich Results Test

El test de formatos enriquecidos de Google nos devuelve también el html renderizado.

View Render (extensión de Chrome)

Una extensión de Chrome muy útil para ver el raw html vs el renderizado.

https://chrome.google.com/webstore/detail/view-rendered-source/ejgngohbdedoabanmclafpkoogegdpob

Chrome DevTools

Haciendo botón derecho en un elemento y dando clic a inspeccionar podemos ver el código renderizado.

Velocidad y Perfomance

WebPageTest, PageSpeed Insights y Lighthouse para auditar el funcionamiento de los archivos javascript.

Crawlers

Screaming Frog. Un crawler semi gratuito con opción de rastrear javascript.

Botify, Deepcrawl, Oncrawl, Ryte y otras herramientas crawling de pago que rastrean javascript.

Otros Apuntes JavaScript

El código JavaScript no dice nada por sí mismo. Necesita ser procesado y renderizado antes de poder tener un output.

No implementar meta tags importantes vía JS.

La etiqueta canonical debe estar siempre en el HTML inicial.

En la medida de lo posible no servir JS en el Head.

Hay que tener en cuenta que el JS puede ser válido para Google, pero el resto no para el resto de buscadores como Bing.

Google usaba Chrome 41 para renderizar, pero ahora es evergreen. Quiere decir que usa la última versión disponible de Chrome para renderizar. En la práctica no cambia mucho. Google sigue dejando el código JS para la segunda ola de indexación.

Cuando pensemos en el renderizado del lado del cliente hay que tener en cuenta todos los dispositivos disponibles en el mercado. No es lo mismo el último modelo iPhone, que un smartphone de hace 4 años (imagen).