Renderizado de JavaScript y crawlers de IA: la brecha de visibilidad

Por qué el renderizado de JavaScript se ha convertido en una cuestión de visibilidad

Durante años, el renderizado de JavaScript se consideró un tema puramente de rendimiento. Quien renderizaba en el cliente arriesgaba tiempos de carga más lentos, pero apenas perdía visibilidad, porque Googlebot ejecuta JavaScript. En la era de la búsqueda con IA, esa suposición se queda corta. Una nueva clase de crawlers lee páginas web sin ejecutar una sola línea de JavaScript: los crawlers que hay detrás de ChatGPT, Claude, Perplexity y otros sistemas de IA.

El análisis conjunto de Vercel y MERJ sobre el comportamiento de los crawlers en la red de Vercel documentó esta brecha a gran escala por primera vez. Según el análisis de diciembre de 2024, ningún crawler de IA importante renderiza JavaScript, entre ellos los de OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User), Anthropic (ClaudeBot), ByteDance (Bytespider), Meta y Perplexity (PerplexityBot). Con ello cambia la lógica: el Server-Side Rendering ya no es una optimización para entregar más rápido, sino un requisito básico para que el contenido exista siquiera para una parte creciente del tráfico de crawlers.

La magnitud de este tráfico importa. En un solo mes, GPTBot generó 569 millones de solicitudes y ClaudeBot 370 millones de solicitudes en la red de Vercel, en conjunto alrededor del 20 % del volumen de Googlebot, de 4,5 mil millones de solicitudes. Para las citas en ChatGPT o Perplexity cuentan sus crawlers de búsqueda, OAI-SearchBot y PerplexityBot. Según el mismo análisis, tampoco estos renderizan JavaScript. El contenido renderizado en el cliente sigue siendo invisible para ellos.

La causa técnica de la brecha de visibilidad

En principio, un crawler pasa por dos pasos: obtiene el documento HTML (rastreo) y después procesa su contenido. La diferencia decisiva está en si entre ambos pasos se intercala un proceso de renderizado, en el que un motor de navegador ejecuta el JavaScript, construye el DOM e inserta el contenido cargado posteriormente.

Googlebot renderiza, los crawlers de IA no: Googlebot, Google Gemini y AppleBot utilizan una fase de renderizado basada en navegador y por eso ven también el contenido que solo surge mediante JavaScript. Los crawlers de IA prescinden de ella. Procesan exclusivamente el HTML en bruto que entrega el servidor. Lo curioso es que sí descargan JavaScript: los crawlers de ChatGPT descargan archivos JS en el 11,50 % de sus peticiones y ClaudeBot en el 23,84 %, pero no los ejecutan. Descargar sin ejecutar significa que todo lo que se monta en el navegador sigue siendo invisible.

Lo que cuesta técnicamente el renderizado: renderizar consume muchos recursos. Requiere un entorno de navegador por página, tiempo de cálculo y memoria. Para un crawler que procesa miles de millones de páginas, es un factor de coste considerable. Los crawlers de IA están diseñados sobre todo para construir conjuntos de datos de entrenamiento y de recuperación. En el momento del análisis de Vercel prescindían de esta fase, probablemente por costes. Está por ver si eso cambiará.

La consecuencia práctica: en una prueba real documentada, ChatGPT, Perplexity y Claude no pudieron leer el contenido de una página renderizada en el cliente, porque dependía del renderizado de JavaScript. Además, las páginas afectadas solo aparecían en zonas secundarias, como la sección «More» de ChatGPT, en lugar de como fuente principal de citas. La visibilidad en la búsqueda con IA se decide, por tanto, en algo tan básico como si el contenido principal está en el HTML entregado por el servidor.

Comparativa de estrategias de renderizado

La elección de la estrategia de renderizado es la palanca central. Dominan cuatro enfoques, con consecuencias claramente distintas para la visibilidad en IA y ante los crawlers.

Client-Side Rendering (CSR): el servidor entrega un esqueleto HTML mínimo y todo el contenido se genera en el navegador mediante JavaScript. Para los crawlers de IA, ese contenido no existe. Las arquitecturas CSR puras son la variante más problemática para la visibilidad en IA.

Server-Side Rendering (SSR): el servidor genera el HTML completo en cada petición y lo entrega listo. El contenido principal, los metadatos y los datos estructurados están de inmediato en el código fuente y cualquier crawler puede leerlos. El SSR es el enfoque más seguro para lograr la máxima visibilidad ante crawlers y sistemas de IA.

Static Site Generation (SSG) y prerenderizado: las páginas se prerenderizan en el momento del build y se entregan como HTML estático. Esto combina visibilidad total con una entrega muy rápida. Para contenidos que cambian poco, como artículos de conocimiento o páginas de servicios, suele ser la solución ideal.

Incremental Static Regeneration (ISR): una forma mixta que regenera las páginas estáticas en segundo plano a intervalos definidos. Combina las ventajas del SSG con la actualidad del contenido dinámico y también entrega HTML ya listo.

En el contexto de Next.js, el App Router cubre estas estrategias. Los React Server Components se renderizan por defecto en el servidor, de modo que su salida acaba directamente en el HTML. El streaming entrega el contenido de forma progresiva sin poner en riesgo que los crawlers puedan leer el contenido principal, siempre que el contenido central no quede oculto tras un componente puramente de cliente. Lo decisivo sigue siendo la regla general: lo que está en la respuesta HTML inicial es visible. Lo que monta el navegador después, no.

La tendencia hacia el renderizado en el servidor también se aprecia en los datos. Al comparar el número de palabras renderizado con el del HTML en bruto en páginas de inicio aparece una diferencia mediana del 13,6 % (móvil) y del 17,5 % (escritorio), y la distancia se reduce en los textos más largos, lo que apunta a un uso relativamente mayor de tecnologías de servidor en los contenidos extensos. Sin embargo, en el percentil 10 la diferencia en escritorio llega hasta el 32 %, una señal clara de que una parte considerable de las páginas sigue cargando posteriormente contenido que se les escapa a los crawlers de IA.

Buenas prácticas para una arquitectura a prueba de crawlers

Servir el contenido principal desde el servidor: el contenido de texto principal, el title y la meta description, los datos estructurados de Schema.org, el enlazado interno, las anotaciones hreflang y la etiqueta canonical tienen que estar en la respuesta HTML inicial. Estos elementos controlan la indexación, la asignación de idioma y región y la evaluación por parte de los sistemas de IA. Si solo están en el DOM renderizado, se pierden para los crawlers que leen HTML en bruto.

Incrustar los datos estructurados en el servidor: el JSON-LD debería estar directamente en el HTML entregado por el servidor, no inyectarse mediante JavaScript. De lo contrario, a los crawlers de IA les falta el contexto legible por máquinas que resulta valioso para el reconocimiento de entidades y la citabilidad.

Enlazado interno con enlaces HTML reales: la navegación y los enlaces internos tienen que estar en el código fuente como elementos de anclaje normales. Los crawlers de IA no siguen los enlaces generados por JavaScript, e incluso Googlebot tarda bastante más en hacerlo. Que la estructura de enlaces sea rastreable es la base para que las subpáginas se encuentren siquiera.

Entrega rápida mediante edge y CDN: HTTP/3, el edge caching y una CDN acortan los tiempos de respuesta y reducen la carga cuando el rastreo es frecuente. Esto es especialmente relevante porque los crawlers de IA trabajan de forma ineficiente. En ChatGPT, el 34,82 % de las peticiones acaba en páginas 404; en Claude, el 34,16 %; en Googlebot, solo el 8,22 %. Unos sitemaps XML limpios e IndexNow ayudan a señalar de forma específica las URL nuevas y modificadas y a reducir el desperdicio de recursos de rastreo en rutas muertas.

Desacoplar la gestión del consentimiento de los crawlers: los banners de cookies y las zonas sujetas a consentimiento no deben ocultar el contenido real a los crawlers. Si el contenido principal se carga mediante JavaScript solo después del consentimiento, los crawlers de IA solo ven el banner. La vía conforme al RGPD consiste en servir desde el servidor los contenidos sin datos personales y limitar la gestión del consentimiento a lo que realmente le corresponde: el tracking y las cookies no necesarias. Bloquear contenidos detrás de un consentimiento perjudica la visibilidad sin que lo exija la normativa de protección de datos.

Errores frecuentes

Malinterpretar el Dynamic Rendering como solución: Google ha calificado de solución provisional obsoleta el hecho de servir contenidos distintos a bots y usuarios. Aumenta la complejidad, es propenso a errores y no sustituye una arquitectura de servidor limpia. Quien construya hoy desde cero debería apostar directamente por SSR, SSG o ISR.

Usar frameworks CSR sin renderizado en el servidor: una Single Page Application sin renderizado en el servidor produce un documento HTML casi vacío. Para los usuarios funciona; para los crawlers de IA, la página no tiene contenido. El error suele pasar desapercibido en el día a día, porque la página se ve perfecta en el navegador.

Suponer que basta con la visibilidad en Googlebot: aunque Googlebot renderice una página JavaScript, eso no vale para los crawlers de IA. Quien optimiza solo para el comportamiento de Googlebot ignora la creciente cuota de tráfico procedente de ChatGPT, Perplexity y sistemas similares.

Bloquear crawlers de forma generalizada sin sopesar las consecuencias: en el robots.txt se pueden permitir o bloquear uno a uno GPTBot, ClaudeBot, PerplexityBot, Google-Extended y otros crawlers de IA. Lo decisivo es la diferencia entre crawlers de entrenamiento y de búsqueda. Bloquear GPTBot o ClaudeBot indica sobre todo que los contenidos no deben usarse para entrenar modelos. Google-Extended controla el entrenamiento y el grounding de Gemini, no la Búsqueda de Google. Para la visibilidad en la búsqueda de ChatGPT cuenta OAI-SearchBot; en Claude, Claude-SearchBot; en Perplexity, PerplexityBot. ChatGPT-User y Claude-User solo acceden a páginas cuando lo pide un usuario; para ChatGPT-User, puede que el robots.txt no se aplique, según OpenAI. Los AI Overviews de Google requieren que una página esté en el índice de Google y pueda mostrarse con snippet; esto se controla con el acceso de Googlebot en el robots.txt y con noindex, nosnippet, data-nosnippet y max-snippet. Quien quiera aparecer citado en respuestas de IA permite como mínimo los crawlers de búsqueda. Esta decisión entre control y visibilidad debería tomarse de forma consciente, no por accidente a través de una configuración demasiado restrictiva.

Subestimar la carga de JavaScript: los bundles de cliente grandes empeoran la visibilidad en IA y el rendimiento. El payload mediano de JavaScript es de 558 kilobytes en móvil y 613 kilobytes en escritorio, y alrededor del 44 % (206 kilobytes) de los bytes entregados queda sin usar durante la carga. Ese lastre sin usar perjudica sobre todo al Largest Contentful Paint y al Interaction to Next Paint.

Métricas y medición

Comparar el HTML puro con el DOM renderizado: la prueba más rápida consiste en comparar el HTML en bruto con el DOM renderizado. Con el código fuente de la página o una simple petición del HTML se puede comprobar si el contenido principal ya está presente sin JavaScript. Si el texto falta en el código fuente pero aparece en la versión renderizada, hay un problema de CSR. La prueba de resultados enriquecidos de Google y el informe de inspección de URLs de Search Console muestran lo que Google ve tras el renderizado. Un crawler como Screaming Frog, con el renderizado de JavaScript activado, puede hacer visible de forma sistemática la diferencia entre la versión en bruto y la renderizada.

Analizar los bots de IA en los logs del servidor: el análisis de logs del servidor muestra qué crawlers de IA acceden realmente a la página, a qué URL se dirigen y cuál es su tasa de 404. Las tasas de error elevadas apuntan a enlaces obsoletos en los sitemaps o a una estructura ineficiente. Estos datos son la prueba más directa de cómo perciben los sistemas de IA tu propio dominio.

Tener en cuenta el retraso en la indexación: incluso en Google, JavaScript provoca una pérdida de tiempo medible. En un experimento, Googlebot necesitó unas nueve veces más tiempo para rastrear páginas JavaScript que páginas HTML puras, en concreto 313 horas frente a 36 horas para el mismo número de páginas. También siguió con bastante más lentitud un enlace interno insertado mediante JavaScript: 52 horas frente a 25 horas con un enlace HTML. Este retraso del modelo de dos oleadas alarga el tiempo hasta la indexación y, con contenidos de actualidad, cuesta alcance.

No perder de vista las Core Web Vitals: el rendimiento sigue siendo una señal de calidad propia. Actualmente, el 48 % de las páginas móviles y el 56 % de las de escritorio superan las tres Core Web Vitals, y solo el 62 % de las páginas móviles alcanza un buen Largest Contentful Paint, frente al 74 % en escritorio. El code splitting, aplazar el JavaScript no crítico y una estrategia de hidratación ligera reducen la carga en el cliente y mejoran a la vez el LCP y el INP.

Consecuencias para el GEO en el mercado austriaco

Para el mercado B2B austriaco, la brecha de visibilidad tiene un significado concreto. El alcance de los canales digitales es alto: en enero de 2025, Austria tenía alrededor de 8,69 millones de usuarios de internet, con una penetración del 95,3 %. Al mismo tiempo, la búsqueda clásica sigue dominando. En mayo de 2026, Google tiene en Austria una cuota de mercado de alrededor del 82 %, seguido de Bing con alrededor del 9 %. Como Bing alimenta las respuestas de IA de Microsoft Copilot y Google muestra AI Overviews, el contenido servido desde el servidor y bien estructurado llega a ambos mundos: la búsqueda clásica y los sistemas de respuesta generativa.

Quien optimiza para la visibilidad en ChatGPT, Perplexity, Gemini y los AI Overviews de Google hace al mismo tiempo un SEO técnico sólido. Los requisitos se solapan: HTML legible, datos estructurados incrustados, entrega rápida y una estructura de enlaces rastreable. El Server-Side Rendering es el denominador común. Garantiza que el contenido exista tanto para Googlebot, que renderiza, como para los crawlers de IA, que no renderizan y que cada vez influyen más en qué marcas aparecen en las respuestas de IA.

Para profundizar

El renderizado de JavaScript no es, por tanto, un tema aislado de frontend, sino una palanca central para que te encuentren. Para profundizar, merece la pena fijarse en la arquitectura SEO de Next.js con App Router y Server Components, en la gestión específica de los crawlers de IA mediante robots.txt y en IndexNow y los sitemaps XML como aceleradores de un rastreo eficiente. Quien asienta estas piezas sobre una base de renderizado en el servidor cierra la brecha de visibilidad en lugar de ampliarla.