seo javascript
Principios de SEO técnico para Angular JS y otras webs JavaScript

 

El salto al Crawleo e indexación de Javascript sin duda es uno de los retos más grandes a los que se ha enfrentado el SEO técnico en estos últimos años, sin embargo la verdad es que no se habla mucho sobre ello, y yo por mi parte me he comprometido a crear algunos contenidos sobre él. Normalmente cuando un SEO se enfrenta por primera vez a una web en Angular JS, lo primero que experimenta es confusión, para dejar paso luego a un sudor frío que baja por su frente hasta convertirse en pánico.

 Imagínate ver a un coche zumbando a 300kms/hora (o 0,8 segundos de carga), levantar el capó, y ver que no hay nada dentro de él.

codigo fuente angular js

Si has llegado aquí a través de una búsqueda… Bienvenido a una nueva pesadilla, gracias Google

Este artículo puede ser un poco difícil de seguir para aquellos que no estéis familiarizados con el funcionamiento y la lógica de Javascript, sin embargo yo tampoco estaba muy familiarizado no hace tanto, así que lo único que pretendo aquí es asentar un marco a partir del cual iré desarrollando en varios artículos más todos los aspectos técnicos a tener en cuenta.

El objetivo de tener una web en Javascript, es mejorar la experiencia de usuario

Al final, lo que vamos a conseguir con una web en Angular JS (u otro framework) es contar con una carga y experiencia de uso de la web, brutal, 100% adaptada para una experiencia móvil. Debemos animar a los programadores a lanzarse con el proyecto, con la documentación y asesoramiento adecuado, debería poder llevarse a cabo la migración a Angular JS de una forma eficaz, sin perder tráfico. Sin embargo a nosotros nos toca la parte complicada; conseguir que una web programada con un comportamiento que históricamente el motor de búsqueda no ha sido capaz de resolver, rankee bien.

¿Pueden los motores de búsqueda / Google crawlear Javascript?

Esta me la sé, .

Sin embargo esto es muy peligroso, todo diseñador o programador que lee esta respuesta, se anima a ello sin comprender primero los matices… Google ha comunicado que es capaz de crawlear e indexar código Javascript, sin embargo se deja la puerta abierta diciendo que tiene algunas excepciones y limitaciones. Al final, el crawler de Google no está tan entrenado en rastrear Javascript cómo HTML. Es muy probable que existan muchos fragmentos de la web que no funcionen del todo. Por ello deberemos llevar a cabo, para cada una de las distintas pantallas de la web, una auditoría SEO Técnica para Webs en Javascript o Angular (perdón por el mazacote, pero es que aquí pondré un enlace al nuevo artículo en breves)

Es importante recordar que el resto de bots de crawleo, cómo Baidu, Bing o los bots sociales, en su mayoría no crawlean Javascript. Y de los que sí que lo consiguen, ninguno iguala a Google en sus capacidades.

¿Qué dicen las pruebas de crawleo?

Flirteando con Google, podemos encontrar muchos artículos en los que se muestran resultados brillantes en pruebas de crawleo. Si leemos cualquiera de estos artículos, podemos acabar teniendo una falsa sensación de confianza en que “todo va a salir bien”. Personalmente jamás aceptaría ninguna de estas pruebas cómo una demostración categórica de las capacidades de Google de interpretar de forma eficaz el contenido Javascript. Google indexa el contenido servido a través de Javascript, pero a veces no, y todavía no he encontrado posts centrados en por qué Google no indexa algo, más allá de cosas específicas en webmaster forum.

Es muy probable que nuestro sitio web no tenga exactamente el mismo comportamiento que las webs que se utilizan para los tests, por lo que de poder, os recomendaría realizar el cambio primero en un set de pantallas antes de lanzarlo en toda la web, por aquello de minimizar riesgos.

Lo que dice Google

Si entramos en el blog de Google, y leemos cualquier post sobre crawleo de Javascript, nos dirán que el bot de Google lo zampa todo. No nos está mintiendo, pero los disclaimers de responsabilidad tampoco es que los pongan en negrita (eso se les da muy bien).

Resumiendo: Google dice que “generalmente son capaces de renderizar y entender todo el contenido en Javascript, y que te animes a dar el salto”

Si le damos la vuelta a esto… “Generalmente” significa que no son capaces de entender ni renderizar todo el contenido que depende de Javascript.

Frameworks para webs en JavaScript

Normalmente se suele tratar el SEO en Javascript, comentando los Frameworks que funcionan mejor… Esto es cómo cualquier discusión en la que se compara WordPress contra Drupal o cualquier otro CMS: ¿Cuál la tiene más larga? ¿Cuál de ellos le gusta más a Google?. 

Las preguntas que debemos hacernos para decidirnos por uno u otro, son las mismas que deberíamos plantearnos cuando vamos a escoger un CMS:

  • ¿Con cuál nos es más fácil trabajar?
  • ¿Qué características ya optimizadas tiene?

Sin embargo todos los Frameworks Javascript pueden ser optimizados para SEO, igual que un CMS. En el caso de los CMS lo importante es lo que aparece en el HTML, no que plugin has usado para ello;  en cuanto a indexación y eficacia de crawleo en Frameworks de JavaScript, lo importante es el contenido que se renderiza en el load event y las posibilidades que tenemos con este. (más adelante lo comentaremos)

Eficiencia de rastreo y Recursos bloqueados

Parsear (analizar) contenido que requiere un navegador sin interfaz gráfica y que además ejecuta y utiliza Javascript, requiere más recursos que ir a buscar un código HTML; desde más tiempo de carga hasta CPU, o incluso consumo de electricidad en realidad.  Por tanto, crawlear páginas montadas en Javascript (por ejemplo con Screaming Frog) nos va a llevar más tiempo y eso repercutirá en indexación. de hecho los motores de búsqueda se apoyan en métodos de rastreo más tradicionales para soportar el JIT, core y otras funcionalidades a gran escala, pudiendo así navegar de una forma más o menos ágil por este tipo de web..

Las webs en Angular JS o Javascript en general, son geniales para velocidad de carga, UX y en general para el usuario, sin embargo, lo  que nos tiene que quedar claro es que  si lo que buscamos es una indexación rápida, crawleo en profundidad o lidiar con problemas de eficiencia (contenidos duplicados, parámetros…), Javascript no va a ser nuestro mejor amigo. Sin embargo podemos apoyarnos en herramientas de pre-renderización cómo prerender.io para “aliviar” estos problemas.

 

Fundamentos de crawleo de Javascript

A priori, todo lo que os he contado sobre las webs hechas con Frameworks basados en Javascript, puede parecer complicado… Pero en realidad, todo lo que debe saber un SEO sobre ello, es fácil, ¡Vamos a por ello!

¿Que proceso hace Googlebot Javascript?

Esto es, simplificada y generalmente, lo que ocurre cuando un navegador (o Googlebot Javascript) hace una petición a un contenido renderizado con Javascript:

  1. Petición inicial: El navegadot (y Googlebot Javascript) ejecutan un GET para el HTML y sus los archivos asociados
  2. Renderizando el DOM: El navegador (y Googlebot Javascript) empiezan a renderizar el DOM (Document Object Model); el DOM vendría a ser el nombre que le da el navegador (search bot) al contenido en la página para luego interpretarlo y convertirlo en algo visual.
  3. Carga del DOM: Mientras va trabajando en la página, el navegador (o search bot), va desencadenando eventos, siendo uno de ellos el DOMContentLoaded. Este evento signigica que el documento inicial HTML ha sido cargado y parseado. Básicamente que el navegador ha resuelto y descargado todo, y que está listo para que el Javascript empiece a hacer su carga en la página.
  4. Javascript ejecuta los cambios: Una vez se ha ejecutado el DOMContentLoaded, el Javascript puede hacer cambios en la página; empieza a añadir, eliminar o modificar el contenido en el HTML fuente. Puedes comparar los cambios que ha llevado a cabo, comparando el contenido que aparece si utilizas la función “ver código fuente” versus “inspeccionar elemento” (con el botón derecho del mouse).
  5. Load Event: El Load event lo activa el navegador cuando los el recurso Javascript y sus recursos dependientes han finalizado su carga. Es el evento más importante, vendría a ser un “listo, ya lo tienes en pantalla”
  6. Eventos Post-Load y User Events: La página puede seguir ejecutando cambios a través de acciones del usuario (onClick) o por contenidos activados más adelante. Estos cambios son los que ocurren después del Load Event.

Headless Browsers (navegadores sin encabezado)

Un Headless Browser es un navegador web sin una interfaz gráfica de usuario (Se ejecuta en memoria). En otras palabras, es un navegador, una pieza de software, que accede a las páginas web, pero no se las muestra a nadie. Entiende a las páginas web como un navegador común lo haría y puede interactuar con ellas de la misma forma.

Describe a la perfección las funcionalidades de Googlebot Javascript. Sirve para representar que Googlebot es un navegador que navega sin el componente visual. Al final, todos los crawlers hacen lo mismo que Chrome o Firefox, solo que en lugar de generar un output visual y permitir la interacción del usuario, extrae código e interactúa a través de los comandos y líneas de código.

Los motores de búsqueda (y en este caso especialmente Googlebot Javascript) utilizan esta función para replicar el comportamiento de un navegador  y así obtener el código resultante en el Load Event.

El proceso que sigue un Headless Browser, sería el siguiente (simplificado):

  1. Googlebot visita una URL cómo un navegador
  2. Al finalizar el Load Event aprieta botón derecho y selecciona “inspeccionar elemento”
  3. Selecciona el tag HTML que aparece en la sección superior
  4. Hace clic en el botón derecho -> Copiar -> Copiar OuterHTML
  5. Utiliza el código HTML copiado (el contenido renderizado) para extraer los datos.

Bien, el último paso es el importante; una vez el Googlebot ha renderizado el contenido (inspeccionando elemento y la fuente HTML), lo utiliza igual que en el HTML tradicional.  ¡Bienvenido de nuevo a tu zona de comfort con tus HTML y CSS!

inspeccionar elemento angular JS

El proceso anterior es también la forma de auditar una web en Javascript. 

Esto le proporciona a Google dos versiones de la página, la versión pre-DOM (con el contenido HTML inicial y los recursos JS mínimos enlazados) y la post-DOM (Load Event). Generalmente Google devolverá e interpretará correctamente la versión renderizada, pero es posible que tengamos que integrar señales entre ambas o depurar contradicciones.

Cuando analizamos la captura de pantalla que hace Google con la función Fetch & Render de Search Console, estaremos viendo la versión renderizada en el Load Event, utilizando el HTML renderizado y no el HTML inicial.

 

La importancia de trackear los eventos (y resolución de problemas SEO con Angular JS)

Principalmente hay dos eventos que debemos tener en cuenta cuando hacemos SEO para Javascript:

Análisis de Load Event para SEO

El Load Event se activa cuando la página ha sido cargada completamente y Google toma una captura de la página (podemos encontrarnos comportamientos distintos entre motores de búsqueda, dependiendo dependiendo de cada contexto).

El contenido que se renderiza después del evento Load Event, no aparecerá en la captura ni se indexará en la página. Esta captura es fundamenta para entender cómo indexa Google el Javascript, el contenido que detecta y la optimización SEO de este.

Aquí os dejo una captura de un proyecto en el que podemos ver cómo ocurre una incidencia relacionada con esto; el contenido principal se carga tras el Load Event (en un evento Post Load):

screenshot load event

Una página modificada por Javascript, puede cambiar continuamente  con los eventos Post Load y de usuario, para adaptarse a la respuesta de la sesión; un ejemplo sería por ejemplo un Inbox de usuario, feeds de twitter o contenidos dinámicos que se carguen en función de las preferencias de un usuario o cookies previamente instaladas. Debemos definir correctamente el contenido inicial que se va a cargar y que queremos enviarle a los motores de búsqueda y acotarlo dentro del Load Event.

Podemos inspeccionar este evento con el clásico Network Performance checker de Chrome Developer Tools (o el que prefiráis):

loadevent

Con esta herramienta obtendremos el timeline de la carga del contenido cargado por el navegador (Chrome). La línea azul indica el indica la carga del contenido del DOM (DOMContentLoaded Event) y la línea roja el Load Event.

En resumen, el contenido renderizado en una página, cuando Googlebot Javascript hace una captura, es lo que se indexa. Consideraremos cómo no indexable, todo el contenido que no se cargue antes del Load Event, así de sencillo.

Con la herramienta de Fetch and Render (captura previa donde mostraba una incidencia) podréis tener un vistazo rápido del contenido que indexa o no.

Análisis de User Event para SEO

Tras el Load Event, hay más eventos que pueden activar nuevos contenidos y provocar cambios en la página; normalmente engagements para usuarios, navegaciones interactivas, etc… El típico onClick event: cuando un usuario hace clic en alguna parte de la web, y activa un evento en el navegador, llamado onClick.

El Javascript reacciona a estos eventos y modifica el comportamiento y contenido de la página en base a ese clic.

En general, sobre estos eventos, lo que tendremos que tener en cuenta es que todo el contenido que depende de una actuación por parte del usuario, no podrá ser indexado. Este contenido no deja de ser una modificación de la página y deberemos considerarlo cómo no-canónico.

 

Una web en JavaScript no tiene por que posicionar mal  en SEO

En mi experiencia os diría que generalmente una web en Angular JS o cualquier otro Framework, dónde todo el contenido aparezca bien en la captura de Google, debería rankear generalmente mejor. Por supuesto hay “peros”, pero aunque enfrentarse a Javascript conlleve sus penurias, y Google lo lleve mejor o peor, practicamente todos los problemas relacionados con ello son provocados por un mal desarrollo web, no por la culpa de Google.

Es muy habitual que los programadores no apliquen las técnicas SEO “tradicionales” a las webs construídas con JavaScript. De hecho, en una reunión, un programador llegó a decirme “pero cómo te has dado cuenta”, cuando le comenté que todo el contenido de la página estaba dentro de un H1. En muy breves prepararé un post dedicado a auditar URLs en Javascript para que podáis resolver este tipo de incidencias, pero por ahora quedaos con que el contenido que obtenemos en el Load Event, debería seguir las mismas reglas que un HTML clásico.

Estos serían los errores más clásicos que podemos encontrarnos (dalealike anda 🙂 ):

 

Con esto, debería haber sido capaz de resolveros todas vuestras dudas y daros las pistas para hacer que vuestras webs consigan rankear de una forma eficaz en Google. ¡Espero que os haya servido!

Las implementaciones de JavaScript tienen su riesgo, normalmente acabarás encontrándote con algo que no funciona del todo bien, y las pasarás canutas revisando e implementando cambios hasta que funcionen las cosas, así que ten paciencia! Migrar un sitio web de HTML a JS y mantener el tráfico es posible, tómate tu tiempo, analiza, testea, rankea y mide!

Este artículo no deja de ser un mix de experiencias y contenidos que he ido encontrando, fruto de investigación y anotaciones que en lugar de dejarlos en una nota, pues aprovecho para publicar con el objetivo de ayudar a quien pueda servirle. En breves sacaré algunos post más sobre SEO para JavaScript 🙂