SEO para JavaScript: un experimento para probar motores de búsqueda

Este artículo examina los mejores recursos de SEO para JavaScript y una prueba para comprender cómo se comportan los motores de búsqueda (Google, Bing y Yandex) cuando tienen que rastrear e indexar páginas procesadas a través de JS. También veremos algunas consideraciones dedicadas a los expertos y desarrolladores de SEO.

JavaScript es un jugador importante en la web actual y, como dijo John Mueller, “ No desaparecerá fácilmente. ”

El tema de JavaScript a menudo es vilipendiado por la comunidad de SEO, pero creo que se debe a la falta de habilidades técnicas en el desarrollo de JavaScript y la representación de páginas web . Pero esto también depende de la dificultad de comunicación entre los expertos en SEO y los equipos de desarrollo.

Esta publicación se divide en dos partes: la primera (breve) ofrece algunos recursos para ver el tema con más detalle; en el segundo (más en profundidad) observamos un experimento muy simple que prueba los motores de búsqueda en una página web renderizada usando JavaScript.

Algunos recursos que introducen SEO para JavaScript

En el siguiente video Martin Splitt , refiriéndose a Google, introduce el tema, explicando la importancia de pensar desde una perspectiva SEO al desarrollar proyectos en JavaScript. En particular, se refiere a las páginas que presentan contenido crítico en JS y a las aplicaciones de una sola página .

"Si desea que los activos se indexen lo antes posible, asegúrese de que el contenido más importante esté en la fuente de la página (lado del servidor representado)".

¿Cual es la razón? Porque siempre debemos tener presente el siguiente esquema, que son las dos ondas de indexación .

El flujo de rastreo, indexación, representación y reconsideración. Y las dos oleadas de procesamiento.

El contenido generado por JavaScript se considera en la segunda ola de indexación, porque tiene que esperar a la fase de renderizado .

En el siguiente vídeo, sin embargo, se explican consejos básicos de SEO sobre proyectos desarrollados en JavaScript.

“Nos estamos moviendo hacia experiencias de usuario extraordinarias, pero también nos dirigimos hacia la necesidad de habilidades técnicas cada vez mayores”.

Una prueba simple para aclarar cómo los motores de búsqueda tratan JavaScript

Describiré una prueba que realicé solo para volver sobre los pasos descritos en la documentación de Google ( rastreo, indexación, procesamiento, reconsideración ). Una prueba, sin embargo, que también se extiende más allá del buscador de Mountain View.

Nota: es una prueba bastante “extrema” en cuanto a la solución técnica aplicada, y se realizó utilizando funciones simples de JavaScript, sin el uso de marcos particulares. El objetivo es únicamente entender la dinámica del motor de búsqueda, no un ejercicio de estilo.

1) La página web

Primero creé una página web con las siguientes características:

• Una página HTML que contiene las principales etiquetas estructurales, sin texto, excepto el contenido de la etiqueta <title>, un subtítulo en una etiqueta <h4> y una cadena en el pie de página.
• El contenido, disponible en el HTML fuente, tiene un propósito específico: proporcionar datos a los motores de búsqueda inmediatamente después del primer procesamiento.
• Una función de JavaScript, una vez que se completa el DOM ( Document Object Model ) , se encarga de representar todo el contenido ( una publicación completa generada con GPT-3 ).

 $(documento).listo( función () {
  hidratación();
});

• El contenido representado por la función no está presente en la página en cadenas JavaScript o JSON, sino que se obtiene a través de llamadas remotas (AJAX).
• Los datos estructurados también se “ inyectan ” a través de JavaScript obteniendo la cadena JSON a través de una llamada remota.
• Me aseguré deliberadamente de que la función de JavaScript invalide el contenido de la etiqueta <title>, genere el contenido de la etiqueta <h1> y cree la descripción. La razón es la siguiente: si se hubieran tenido en cuenta los datos generados por JS, el fragmento del resultado en SERP habría cambiado por completo.
• Una de las dos imágenes que se procesan a través de JS se ha indicado en el encabezado de la página en una etiqueta <link> ( rel = "preload" ) para comprender si esta acción puede acelerar la indexación del recurso.

2) Envío de la página a motores de búsqueda y pruebas

Después de publicar la página, la informé a los motores de búsqueda y, en particular, a Google (a través de la " comprobación de URL " de Search Console), a Bing (a través de " Enviar URL " de Webmaster Tool) y a Yandex (a través de " Reindexar páginas "). ” de la Herramienta para webmasters de Google).

En esta etapa, realicé algunas pruebas.

• La herramienta "Buscar y renderizar" de Merkle que suelo usar para hacer pruebas de renderizado generó la página correctamente. La herramienta simula Googlebot usando Chromium 79 sin cabeza.
  Nota: entre las herramientas de Merkle también hay un Pre-rendering Tester , que le permite verificar la respuesta HTML en función del agente de usuario que realiza la solicitud.

Merkle Fetch & Render: herramienta de prueba de renderizado

• La prueba de resultados enriquecidos de Google generó con éxito el DOM y la captura de pantalla de la página. La herramienta también detectó correctamente los datos estructurados, identificando la entidad de tipo “ Artículo ”.

El DOM generado por Google Rich Results Tes

• La herramienta de verificación de URL de Search Console inicialmente mostró una representación imperfecta a veces. Pero creo que la razón fue el tiempo de ejecución.

3) Indexación

En esta etapa, todos los motores de búsqueda se comportaron igual: después de unas horas, el resultado estaba presente en todos los SERP.

El fragmento generado en la primera fase en Bing, Yandex y Google

Los snippets, como se ve en las imágenes, están compuestos por el contenido de la etiqueta <title> y una descripción obtenida a partir de los datos disponibles en el contenido principal.

Ninguna imagen de la página ha sido indexada.

4) Operaciones de edición, mapa del sitio, API de indexación de Google

Al día siguiente, los fragmentos eran los mismos. He completado algunas acciones para enviar señales a los motores de búsqueda.

• Cambié el HTML de la página, agregando el favicon, el nombre del autor del post y la fecha de publicación. El objetivo era averiguar si los motores de búsqueda actualizarían el fragmento antes de un análisis potencial del contenido presentado.
• Al mismo tiempo actualicé el JSON de los datos estructurados actualizando la fecha de modificación (“dateModified”).
• Envié el mapa del sitio que contenía la URL de la página web a las herramientas para webmasters de los diferentes motores de búsqueda.
• Informé a los buscadores que la página ha sido modificada, y en particular, a Google, a través de la API de indexación.

[Estudio de caso] Evite que su rediseño penalice su SEO

Un año después del rediseño de su sitio web, EasyCash pronto se dio cuenta de que el rendimiento que esperaban no estaba allí. Identificaron y resolvieron varios obstáculos de SEO.

Lea el estudio de caso

Los resultados

¿Qué pasó después de unos días?

Google renderizó y reelaboró ​​el fragmento

1) Google procesó el contenido mediante el procesamiento de JavaScript, luego modificó el resultado en SERP usando el contenido correctamente.

Google ha indexado el contenido renderizado usando JavaScript

2) La primera imagen de la publicación también se indexó y apareció en Google Images.

La imagen de la publicación, renderizada a través de JavaScript, aparece en Google Images.

3) Los fragmentos de Bing y Yandex no han cambiado. Esto quiere decir que en los días siguientes a la publicación no consideraron el DOM definitivo.

4) La imagen que se muestra en el enlace para la precarga no recibió un trato favorable en comparación con la otra.

Representación de página de JavaScript (β) por Yandex

En las herramientas para webmasters de Yandex hay una función "beta" que le permite especificar el comportamiento del robot cuando rastrea páginas.

El panel de configuración de representación de Yandex

Puede sugerir ejecutar JavaScript para completar la representación o no ejecutarlo. La opción predeterminada le da al algoritmo la "libertad" para elegir la mejor acción.

En el caso específico donde casi todo el contenido se genera en el lado del cliente, pero más generalmente, por ejemplo para un marco de JavaScript, es recomendable forzar la representación.

Representación dinámica

En la última fase de prueba, implementé una solución de renderizado dinámico para Bing y Yandex. Esta solución permite diferenciar la respuesta que se envía al cliente para que:

• Los navegadores de los usuarios reciben la respuesta que contiene el HTML y el JavaScript necesarios para completar la representación;
• El rastreador recibe una versión estática de la página, que contiene todo el contenido crítico en la fuente.

Cómo funciona el renderizado dinámico

Después de completar la implementación, solicité indexación nuevamente a través de las herramientas Bing y Yandex.

Yandex, en unas pocas horas, reconstruyó el fragmento en SERP de la siguiente manera. Así que Yandex consideró la nueva versión renderizada del lado del servidor.

El fragmento de Yandex después de la representación dinámica

Bing no cambió el resultado en el tiempo disponible para la prueba, pero ciertamente ( ehm.. al menos eso espero ) lo habría integrado en los siguientes días.

Conclusiones

Esta sencilla prueba demuestra que Google funciona tal y como especifica la documentación, respetando las dos fases del esquema visto en la parte inicial del post. En la primera fase, de hecho, indexó el contenido presente en la fuente de la página casi instantáneamente (el HTML generado en el lado del servidor); en el segundo, en un par de días, indexó las partes renderizadas a través de JavaScript.

Bing y Yandex, por otro lado, no parecen detectar contenido generado a través de JavaScript... al menos en los días posteriores a la publicación.

Estos elementos resaltan algunos aspectos relacionados con JavaScript que intentaré explicar con un poco más de detalle a continuación.

• Hay que mantener el foco en los mercados de referencia para la comunicación: si nos dirigimos a un público que utiliza buscadores distintos a Google, corremos el riesgo de no ser tan visibles como nos gustaría.
• Incluso si los usuarios usan Google, debemos considerar el tiempo que se tarda en obtener la información completa en la SERP. La fase de renderizado, de hecho, es muy costosa en términos de recursos: en el caso de la prueba, con solo una página en línea, el fragmento se obtuvo correctamente en pocos días. Pero, ¿qué pasaría si trabajamos en un sitio web muy grande? El “presupuesto” que el buscador pone a nuestra disposición y el rendimiento de la web se vuelven determinantes.
• Creo que JavaScript nos permite ofrecer a los usuarios experiencias de usuario superiores, pero las habilidades necesarias para lograrlo son muchas y costosas. Como expertos en SEO, necesitamos evolucionar para proponer las mejores soluciones. El renderizado previo o el renderizado dinámico siguen siendo técnicas útiles para generar contenido crítico en proyectos que necesitan garantizar una visibilidad global.
• Todos los marcos JavaScript modernos, que se basan en la arquitectura JAMstack, como Astro, Gatsby, Jekyll, Hugo, NuxtJS y Next.JS, ofrecen la posibilidad de representar el contenido en el lado del servidor, para proporcionar la versión estática de Las paginas. Además, Next.JS, que en mi opinión es el más avanzado, permite un modo de renderizado “híbrido”, llamado “Regeneración Estática Incremental” (ISR). ISR permite la generación de páginas estáticas de forma incremental, con un procesamiento en segundo plano constante. Esta técnica permite un rendimiento de navegación muy alto.

“La pregunta es… ¿merece la pena introducir tanta “complejidad” en un proyecto? La respuesta es simple: ¡sí, si vamos a producir una experiencia de usuario increíble!”

Notas adicionales

• Debemos fijarnos en la diferencia entre los eventos “document ready” y “window loading”: el primero surte efecto después de que se haya generado el DOM, mientras que el segundo cuando se haya generado el DOM y se hayan cargado los recursos.
• Claramente, para pruebas como esta, no tiene sentido analizar la copia de caché de Google, porque al abrir las páginas se volvería a ejecutar el JS, no dando la percepción del contenido que Google tiene en cuenta.

¡Buen JavaScript y buen SEO!