Cómo gestiona Google el JavaScript durante el proceso de indexación

Comprender cómo rastrean, procesan e indexan los motores de búsqueda las páginas web es fundamental para optimizar los sitios para los motores de búsqueda. Con el paso de los años, a medida que los motores de búsqueda como Google cambian sus procesos, resulta difícil hacer un seguimiento de lo que funciona y lo que no, especialmente con JavaScript del lado del cliente.

Hemos notado que persisten varias creencias antiguas que mantienen a la comunidad insegura sobre las mejores prácticas para el SEO de aplicaciones:

1. “Google no puede renderizar JavaScript del lado del cliente”.
2. “Google trata las páginas JavaScript de forma diferente”.
3. “La cola de renderizado y el tiempo inciden significativamente en el SEO”.
4. “Los sitios que utilizan mucho JavaScript tienen un descubrimiento de páginas más lento”.

Para abordar estas creencias, nos asociamos con MERJ , una consultora líder en ingeniería de datos y optimización de motores de búsqueda, para realizar nuevos experimentos sobre el comportamiento de rastreo de Google. Analizamos más de 100 000 búsquedas de Googlebot en varios sitios para probar y validar las capacidades de optimización de motores de búsqueda de Google.

Veamos cómo ha evolucionado la representación de Google. Luego, exploraremos nuestros hallazgos y su impacto en el mundo real en las aplicaciones web modernas.

La evolución de las capacidades de renderizado de Google

Con el paso de los años, la capacidad de Google para rastrear e indexar contenido web ha cambiado significativamente. Ver esta evolución es importante para comprender el estado actual del SEO para las aplicaciones web modernas.

Antes de 2009: compatibilidad limitada con JavaScript

En los primeros días de las búsquedas, Google indexaba principalmente contenido HTML estático. El contenido generado con JavaScript era prácticamente invisible para los motores de búsqueda, lo que llevó al uso generalizado de HTML estático para fines de SEO.

2009–2015: esquema de rastreo AJAX

Google introdujo el esquema de rastreo AJAX, que permite a los sitios web proporcionar capturas de pantalla HTML de contenido generado dinámicamente. Se trataba de una solución provisional que requería que los desarrolladores crearan versiones independientes y rastreables de sus páginas.

2015–2018: Representación temprana de JavaScript

Google comenzó a renderizar páginas usando un navegador Chrome sin interfaz gráfica, lo que marcó un avance significativo. Sin embargo, esta versión anterior del navegador aún tenía limitaciones para procesar las funciones modernas de JS.

2018-presente: Capacidades de renderizado modernas

En la actualidad, Google utiliza una versión actualizada de Chrome para la renderización, que se mantiene al día con las últimas tecnologías web. Los aspectos clave del sistema actual incluyen:

1. Representación universal: Google ahora intenta representar todas las páginas HTML, no solo un subconjunto.
2. Navegador actualizado: Googlebot utiliza la última versión estable de Chrome/Chromium, compatible con las funciones JS modernas.
3. Representación sin estado: cada representación de página se realiza en una nueva sesión del navegador, sin conservar las cookies ni el estado de las representaciones anteriores. Por lo general, Google no hará clic en elementos de la página, como contenido con pestañas o banners de cookies.
4. Enmascaramiento : Google prohíbe mostrar contenido diferente a los usuarios y a los motores de búsqueda para manipular las clasificaciones. Evite el código que altere el contenido en función de User-Agent. En su lugar, optimice la representación sin estado de su aplicación para Google e implemente la personalización a través de métodos con estado.
5. Almacenamiento en caché de activos: Google acelera la representación de páginas web mediante el almacenamiento en caché de activos, lo que resulta útil para páginas que comparten recursos y para la representación repetida de la misma página. En lugar de utilizar Cache-Controlencabezados HTTP, el Servicio de representación web de Google emplea su propia heurística interna para determinar cuándo los activos almacenados en caché siguen siendo nuevos y cuándo es necesario volver a descargarlos.

Hoy en día, el proceso de indexación de Google se parece a esto.

Con una mejor comprensión de lo que Google es capaz de hacer, veamos algunos mitos comunes y cómo impactan en el SEO.

Metodología

Para investigar los siguientes mitos, realizamos un estudio utilizando la infraestructura de Vercel y la tecnología Web Rendering Monitor (WRM) de MERJ. Nuestra investigación se centró en nextjs.org, con datos complementarios de monogram.io y basement.io, que abarcan desde el 1 de abril hasta el 30 de abril de 2024.

Recopilación de datos

Colocamos un middleware Edge personalizado en estos sitios para interceptar y analizar las solicitudes de los robots de los motores de búsqueda. Este middleware nos permitió:

1. Identificar y realizar un seguimiento de las solicitudes de varios motores de búsqueda y rastreadores de inteligencia artificial. (No se incluyeron datos de usuario en esta consulta).
2. Inyectar una biblioteca JavaScript ligera en las respuestas HTML para bots.

La biblioteca de JavaScript, que se activa cuando una página termina de renderizarse, envía datos a un servidor de larga duración, incluidos:

• La URL de la página.
• El identificador de solicitud único (para hacer coincidir la representación de la página con los registros de acceso regulares al servidor).
• La marca de tiempo de la finalización de la representación (esto se calcula utilizando el tiempo de recepción de la solicitud de la biblioteca JavaScript en el servidor).

Análisis de los datos

Al comparar la solicitud inicial presente en los registros de acceso al servidor con los datos enviados desde nuestro middleware a un servidor de baliza externo, pudimos:

1. Confirme qué páginas fueron renderizadas exitosamente por los motores de búsqueda.
2. Calcular la diferencia de tiempo entre el rastreo inicial y la representación completa.
3. Analizar patrones en cómo se procesaron diferentes tipos de contenido y URL.

Alcance de los datos

Para este artículo, nos centramos principalmente en los datos de Googlebot, que nos proporcionó el conjunto de datos más grande y confiable. Nuestro análisis incluyó más de 37 000 páginas HTML renderizadas que coincidieron con pares de balizas de servidor, lo que nos proporcionó una muestra sólida de la que extraer conclusiones.

Todavía estamos recopilando datos sobre otros motores de búsqueda, incluidos proveedores de IA como OpenAI y Anthropic, y esperamos hablar más sobre nuestros hallazgos en el futuro.

En las siguientes secciones, profundizaremos en cada mito, proporcionando una metodología más relevante según sea necesario.

Mito 1: “Google no puede mostrar contenido JavaScript”

Este mito ha llevado a muchos desarrolladores a evitar los frameworks JS o recurrir a soluciones alternativas complejas para el SEO.

La prueba

Para probar la capacidad de Google para representar contenido JavaScript, nos centramos en tres aspectos clave:

1. Compatibilidad del marco JS: analizamos las interacciones de Googlebot con Next.js utilizando datos de nextjs.org, que utiliza una combinación de prerenderizado estático, renderizado del lado del servidor y renderizado del lado del cliente.
2. Indexación de contenido dinámico : examinamos páginas que nextjs.orgcargan contenido de forma asincrónica mediante llamadas a la API. Esto nos permitió determinar si Googlebot podía procesar e indexar contenido que no estaba presente en la respuesta HTML inicial.
3. Contenido transmitido a través de componentes de servidor React (RSC): de manera similar a lo anterior, gran parte de nextjs.orgestá creado con Next.js App Router y RSC. Pudimos ver cómo Googlebot procesaba e indexaba el contenido transmitido de manera incremental a la página.
4. Tasa de éxito de renderizado : comparamos la cantidad de solicitudes de Googlebot en los registros de nuestro servidor con la cantidad de señales de renderizado exitosas recibidas. Esto nos dio una idea de qué porcentaje de páginas rastreadas se renderizaron por completo.

Nuestros hallazgos

1. De más de 100 000 recuperaciones de Googlebot analizadas en nextjs.org, excluyendo errores de código de estado y páginas no indexables, el 100 % de las páginas HTML dieron como resultado representaciones de página completa, incluidas páginas con interacciones JS complejas.
2. Todo el contenido cargado de forma asincrónica a través de llamadas API se indexó correctamente, lo que demuestra la capacidad de Googlebot para procesar contenido cargado dinámicamente.
3. Next.js, un marco basado en React, fue renderizado completamente por Googlebot, lo que confirma la compatibilidad con los marcos de JavaScript modernos.
4. El contenido transmitido a través de RSC también se procesó en su totalidad, lo que confirma que la transmisión no afecta negativamente al SEO .
5. Google intenta representar prácticamente todas las páginas HTML que rastrea, no solo un subconjunto de páginas con mucho JavaScript.

Mito 2: “Google trata las páginas JavaScript de forma diferente”

Un error muy común es creer que Google tiene un proceso o criterio independiente para las páginas que utilizan mucho JavaScript. Nuestra investigación, combinada con declaraciones oficiales de Google, desmiente este mito.

La prueba

Para probar en qué casos Google trata de forma diferente las páginas con mucho contenido JavaScript, adoptamos varios enfoques específicos:

1. Prueba CSS : creamos una página de prueba sin JavaScript, pero con un archivo CSS que contenía un segundo archivo CSS (que solo se descargaría y aparecería en los registros del servidor al renderizar el primer archivo CSS). Al comparar este comportamiento con el de una página con JavaScript habilitado, pudimos verificar si el renderizador de Google procesa el CSS de manera diferente con JavaScript habilitado y sin él.@import@imports
2. Manejo de códigos de estado y metaetiquetas: desarrollamos una aplicación Next.js con middleware para probar varios códigos de estado HTTP con Google. Nuestro análisis se centró en cómo Google procesa las páginas con diferentes códigos de estado (200, 304, 3xx, 4xx, 5xx) y aquellas con noindexmetaetiquetas. Esto nos ayudó a comprender si las páginas con mucho código JavaScript se tratan de manera diferente en estos escenarios.
3. Análisis de la complejidad de JavaScript : comparamos el comportamiento de renderizado de Google en páginas con distintos niveles de complejidad de JS en nextjs.org. Esto incluía páginas con un mínimo de JS, aquellas con interactividad moderada y páginas altamente dinámicas con un renderizado extenso del lado del cliente. También calculamos y comparamos el tiempo entre el rastreo inicial y el renderizado completo para ver si un JS más complejo generaba colas de renderizado o tiempos de procesamiento más largos.

Nuestros hallazgos

1. Nuestra @importprueba CSS confirmó que Google renderiza con éxito páginas con o sin JS.
2. Google muestra todas las páginas HTML con estado 200, independientemente del contenido JS. Las páginas con estado 304 se muestran utilizando el contenido de la página de estado 200 original. Las páginas con otros errores 3xx, 4xx y 5xx no se muestran.
3. Las páginas con noindexmetaetiquetas en la respuesta HTML inicial no se procesaron, independientemente del contenido de JS. La eliminación de etiquetas del lado del cliente no es eficaz para fines de SEO; si una página contiene la etiqueta en la respuesta HTML inicial, no se procesará y el código JavaScript que elimina la etiqueta no se ejecutará.noindexnoindex
4. No encontramos diferencias significativas en la tasa de éxito de Google al renderizar páginas con distintos niveles de complejidad de JavaScript. En nextjs.orgla escala de , tampoco encontramos correlación entre la complejidad de JavaScript y el retraso en la renderización. Sin embargo, un código JS más complejo en un sitio mucho más grande puede afectar la eficiencia del rastreo.

Mito 3: “La cola de renderizado y el tiempo afectan significativamente el SEO”

Muchos profesionales de SEO creen que las páginas con mucho código JavaScript sufren retrasos significativos en la indexación debido a una cola de renderización. Nuestra investigación proporciona una visión más clara de este proceso.

La prueba

Para abordar el impacto de la cola de renderización y el tiempo en el SEO, investigamos:

1. Retrasos en la representación: examinamos la diferencia de tiempo entre el rastreo inicial de una página por parte de Google y su finalización, utilizando datos de más de 37 000 pares de servidor-baliza coincidentes en nextjs.org.
2. Tipos de URL: analizamos los tiempos de representación de URL con y sin cadenas de consulta, así como para diferentes secciones de nextjs.org(por ejemplo, /docs, /learn, /showcase).
3. Patrones de frecuencia: analizamos la frecuencia con la que Google vuelve a renderizar las páginas y si había patrones en la frecuencia de renderización para diferentes tipos de contenido.

Nuestros hallazgos

La distribución del retardo de renderizado fue la siguiente:

• Percentil 50 (mediana): 10 segundos.
• Percentil 75: 26 segundos
• Percentil 90: ~3 horas
• Percentil 95: ~6 horas
• Percentil 99: ~18 horas

Sorprendentemente, el percentil 25 de las páginas se procesaron dentro de los 4 segundos posteriores al rastreo inicial, lo que pone en tela de juicio la noción de una “cola” larga.

Si bien algunas páginas enfrentaron retrasos importantes (hasta aproximadamente 18 horas en el percentil 99), estas fueron la excepción y no la regla.

También observamos patrones interesantes relacionados con la rapidez con la que Google procesa las URL con cadenas de consulta (?param=xyz):

Tipo de URL	Percentil 50	Percentil 75	Percentil 90
Todas las URL URL con cadena de consulta	10 segundos	26 segundos	~3 horas
URL sin cadena de consulta	10 segundos	22 segundos	~2,5 horas
URL con cadena de consulta	13 segundos	31 minutos	~8,5 horas

Estos datos sugieren que Google trata las URL de forma diferente si tienen cadenas de consulta que no afectan al contenido. Por ejemplo, en nextjs.org, las páginas con ?ref=parámetros experimentaron demoras de representación más prolongadas, especialmente en percentiles más altos.

Además, notamos que las secciones que se actualizaban con frecuencia /docstenían tiempos de renderización promedio más cortos en comparación con las secciones más estáticas. Por ejemplo, la /showcasepágina, a pesar de estar vinculada con frecuencia, mostraba tiempos de renderización más largos, lo que sugiere que Google puede ralentizar la nueva renderización de las páginas que no cambian significativamente.

Mito 4: “Los sitios que utilizan JavaScript de forma intensiva tienen un descubrimiento de páginas más lento”

Una creencia persistente en la comunidad de SEO es que los sitios que utilizan mucho JavaScript, especialmente aquellos que dependen de la representación del lado del cliente (CSR), como las aplicaciones de una sola página (SPA), sufren una detección de páginas más lenta por parte de Google. Nuestra investigación proporciona nuevos conocimientos al respecto.

La prueba

Para investigar el impacto de JavaScript en el descubrimiento de páginas, hicimos lo siguiente:

1. Analizamos el descubrimiento de enlaces en diferentes escenarios de renderizado: comparamos la rapidez con la que Google descubrió y rastreó enlaces en páginas renderizadas por el servidor, generadas estáticamente y renderizadas por el lado del cliente en nextjs.org .
2. Cargas útiles de JavaScript no renderizadas probadas: agregamos un objeto JSON similar a una carga útil de React Server Component (RSC) a la /showcasepágina de nextjs.org , que contiene enlaces a páginas nuevas que no se habían descubierto anteriormente. Esto nos permitió probar si Google podía descubrir enlaces en datos de JavaScript que no se habían renderizado.
3. Tiempos de descubrimiento comparados: monitoreamos la rapidez con la que Google descubrió y rastreó nuevas páginas vinculadas de diferentes maneras: enlaces HTML estándar, enlaces en contenido renderizado del lado del cliente y enlaces en cargas útiles de JavaScript no renderizadas.

Nuestros hallazgos

1. Google descubrió y rastreó con éxito enlaces en páginas completamente renderizadas, independientemente del método de renderización.
2. Google puede descubrir enlaces en cargas útiles de JavaScript no renderizadas en la página, como aquellas en React Server Components o estructuras similares.
3. Tanto en el HTML inicial como en el HTML renderizado, Google procesa el contenido identificando cadenas que parecen URL, utilizando el host y el puerto actuales como base para las URL relativas. (Google no descubrió una URL codificada, es decir, https%3A%2F%2Fwebsite.com—en nuestra carga útil similar a RSC, lo que sugiere que su análisis de enlaces es muy estricto).
4. La fuente y el formato de un enlace (por ejemplo, en una <a>etiqueta o incrustado en una carga útil JSON) no afectaron la forma en que Google priorizó su rastreo. La prioridad de rastreo se mantuvo constante independientemente de si se encontró una URL en el rastreo inicial o después de la representación.
5. Si bien Google detecta correctamente los enlaces en las páginas CSR, es necesario renderizarlas primero. Las páginas renderizadas en servidor o las páginas pre-renderizadas parcialmente tienen una ligera ventaja en el descubrimiento inmediato de enlaces.
6. Google diferencia entre descubrimiento de enlaces y evaluación del valor de los enlaces. La evaluación del valor de un enlace para la arquitectura del sitio y la priorización del rastreo se produce después de la visualización de la página completa.
7. Tener una versión actualizada sitemap.xmlreduce significativamente, si no elimina, las diferencias en el tiempo de descubrimiento entre los diferentes patrones de representación.

Implicaciones generales y recomendaciones

Nuestra investigación ha desmentido varios mitos comunes sobre el manejo que hace Google de los sitios web con mucho JavaScript. A continuación, se presentan las conclusiones clave y las recomendaciones prácticas:

Trascendencia

1. Compatibilidad con JavaScript: Google puede representar e indexar de manera eficaz contenido JavaScript, incluidas SPA complejas, contenido cargado dinámicamente y contenido transmitido en tiempo real.
2. Paridad de representación: no existe una diferencia fundamental en la forma en que Google procesa las páginas con mucho contenido de JavaScript en comparación con las páginas HTML estáticas. Se representan todas las páginas.
3. La realidad de la cola de renderizado: si bien existe una cola de renderizado, su impacto es menos significativo de lo que se creía anteriormente. La mayoría de las páginas se renderizan en cuestión de minutos, no de días o semanas.
4. Descubrimiento de páginas: los sitios que utilizan mucho JavaScript, incluidas las SPA, no tienen desventajas inherentes en el descubrimiento de páginas por parte de Google.
5. Sincronización del contenido:noindex el momento en que se agregan determinados elementos (como etiquetas) a la página es crucial, ya que es posible que Google no procese los cambios del lado del cliente.
6. Evaluación del valor del enlace: Google distingue entre descubrimiento de enlaces y evaluación del valor del enlace. Esta última se produce después de la visualización de la página completa.
7. Priorización de la representación: el proceso de representación de Google no es estrictamente del tipo “primero en entrar, primero en salir”. Factores como la frescura del contenido y la frecuencia de actualización influyen en la priorización más que la complejidad de JavaScript.
8. Rendimiento de renderizado y presupuesto de rastreo: si bien Google puede renderizar de manera eficaz páginas con mucho código JavaScript, el proceso consume más recursos en comparación con el HTML estático, tanto para usted como para Google. En el caso de sitios grandes (más de 10 000 páginas únicas que cambian con frecuencia), esto puede afectar el presupuesto de rastreo del sitio . Optimizar el rendimiento de la aplicación y minimizar el código JavaScript innecesario puede ayudar a acelerar el proceso de renderizado, mejorar la eficiencia del rastreo y, potencialmente, permitir que se rastreen, rendericen e indexen más páginas.

Recomendaciones

1. Adopte JavaScript: aproveche libremente los marcos de JavaScript para mejorar las experiencias de los usuarios y desarrolladores, pero priorice el rendimiento y respete las mejores prácticas de Google para la carga diferida .
2. Manejo de errores: implemente límites de error en las aplicaciones React para evitar fallas totales de representación debido a errores de componentes individuales.
3. Elementos críticos de SEO: utilice la representación del lado del servidor o la generación estática para etiquetas de SEO críticas y contenido importante para garantizar que estén presentes en la respuesta HTML inicial.
4. Gestión de recursos: asegúrese de que los recursos críticos para la representación (API, archivos JavaScript, archivos CSS) no estén bloqueados por robots.txt.
5. Actualizaciones de contenido: en el caso de contenido que se deba volver a indexar rápidamente, asegúrese de que los cambios se reflejen en el HTML generado por el servidor, no solo en el JavaScript del lado del cliente. Considere estrategias como la regeneración estática incremental para equilibrar la actualización del contenido con el SEO y el rendimiento.
6. Enlaces internos y estructura de URL: cree una estructura de enlaces internos clara y lógica. Implemente enlaces de navegación importantes como etiquetas de anclaje HTML reales ( <a href="...">) en lugar de una navegación basada en JavaScript. Este enfoque mejora la navegación del usuario y la eficiencia del rastreo del motor de búsqueda, al tiempo que reduce potencialmente los retrasos en la representación.
7. Sitemaps: utilice y actualice periódicamente los sitemaps . En el caso de sitios grandes o con actualizaciones frecuentes, utilice la <lastmod>etiqueta en los sitemaps XML para guiar los procesos de rastreo e indexación de Google. Recuerde actualizarlos <lastmod>solo cuando se produzca una actualización de contenido significativa.
8. Monitoreo: usa la herramienta de inspección de URL o la herramienta de resultados enriquecidos de Google Search Console para verificar cómo ve Googlebot tus páginas. Monitorea las estadísticas de rastreo para asegurarte de que la estrategia de renderizado que elegiste no esté causando problemas inesperados.

Avanzando con nueva información

Como hemos explorado, existen algunas diferencias entre las estrategias de renderizado cuando se trata de las capacidades de Google:

Característica	Generación de sitios estáticos (SSG)	Regeneración estática incremental (ISR)	Representación del lado del servidor (SSR)	Representación del lado del cliente (CSR)
Eficiencia de rastreo: con qué rapidez y eficacia Google puede acceder, renderizar y recuperar páginas web.	Excelente	Excelente	Muy bien	Pobre
Descubrimiento: El proceso de encontrar nuevas URL para rastrear.*	Excelente	Excelente	Excelente	Promedio
Completitud de la representación (errores, fallos, etc.): con qué precisión y exhaustividad Google puede cargar y procesar tus páginas web sin errores.	Robusto	Robusto	Robusto	Puede fallar**
Tiempo de renderizado: el tiempo que tarda Google en renderizar y procesar por completo las páginas web.	Excelente	Excelente	Excelente	Pobre
Evaluación de la estructura de enlaces: cómo Google evalúa los enlaces para comprender la arquitectura del sitio web y la importancia de las páginas.	Después de renderizar	Después de renderizar	Después de renderizar	Después de la renderización, es posible que falten enlaces si la renderización falla
Indexación: El proceso mediante el cual Google almacena y organiza el contenido de su sitio.	Robusto	Robusto	Robusto	Es posible que no se indexe si falla la representación

* Tener una versión actualizada sitemap.xmlreduce significativamente, si no elimina, las diferencias en el tiempo de descubrimiento entre diferentes patrones de renderizado.

** La renderización en Google generalmente no falla, como lo demuestra nuestra investigación; cuando lo hace, a menudo se debe a recursos bloqueados robots.txto casos extremos específicos.

Estas diferencias sutiles existen, pero Google descubrirá e indexará rápidamente su sitio independientemente de la estrategia de renderización. Concéntrese en crear aplicaciones web de alto rendimiento que beneficien a los usuarios más que en preocuparse por adaptaciones especiales para el proceso de renderización de Google.

Después de todo, la velocidad de la página sigue siendo un factor de clasificación, ya que el sistema de clasificación de experiencia de página de Google evalúa el rendimiento de su sitio en función de las métricas Core Web Vitals de Google .

Además, la velocidad de la página está vinculada a una buena experiencia del usuario: cada 100 ms de tiempo de carga ahorrado se correlaciona con un aumento del 8 % en la conversión del sitio web . Menos usuarios que abandonan la página significa que Google la trata como más relevante. El rendimiento es importante; los milisegundos importan.

Más recursos

Para conocer más sobre estos temas te recomendamos:

• Cómo afectan los Core Web Vitals a tu SEO : proporciona una descripción general completa de cómo los Core Web Vitals (CWV) afectan al SEO, explicando el sistema de clasificación de la experiencia de página de Google y la diferencia entre los datos de campo (usados ​​para la clasificación) y los datos de laboratorio (puntajes Lighthouse).
• Cómo elegir la estrategia de renderizado correcta : guía a los desarrolladores en la elección de estrategias de renderizado óptimas para aplicaciones web, explicando varios métodos como SSG, ISR, SSR y CSR, sus casos de uso y consideraciones de implementación utilizando Next.js.
• La experiencia del usuario de Frontend Cloud : explica cómo Frontend Cloud de Vercel permite experiencias web rápidas y personalizadas al combinar estrategias de almacenamiento en caché avanzadas, capacidades de red Edge y opciones de renderizado flexibles para optimizar tanto la experiencia del usuario como la productividad del desarrollador.

Fuente: Vercel.com