Saltar al contenido

Contenido que solo se ve con JavaScript: lo que Google renderiza y los rastreadores de IA no leen

Publicado el 07-10-20268 min de lecturaPor la redacción de SmoothSeen

Google renderiza JavaScript: rastrea la página, la pinta con un Chromium sin interfaz y después la indexa. La mayoría de rastreadores de IA no lo hacen. En la medición de Vercel y MERJ de diciembre de 2024, los de OpenAI, Anthropic, Meta, ByteDance y Perplexity leían solo el HTML del servidor: lo que pinta JavaScript después no existe para ellos.

Lo esencial

  • Google procesa las páginas en tres fases, rastreo, renderizado e indexación, y ejecuta el JavaScript con un Chromium sin interfaz antes de indexar.
  • En la medición de Vercel y MERJ publicada el 17-12-2024, ninguno de los rastreadores de IA de OpenAI, Anthropic, Meta, ByteDance y Perplexity ejecutaba JavaScript.
  • Una aplicación de una sola página que se pinta en el navegador llega a esos rastreadores casi vacía, aunque en Google se vea bien.
  • El renderizado en servidor, el estático y la hidratación entregan el texto en el HTML; Google considera el renderizado dinámico un apaño, no una solución.
  • Se comprueba en minutos con el código fuente, con curl y con la inspección de URL de Search Console.

Para comprobarlo en tu web: Auditoría de visibilidad en IA

En esta página

Este problema no se ve en el navegador, que ejecuta todo, ni casi nunca en Google, que también lo hace. Por eso se escapa en tantas auditorías. Es uno de los bloques de acceso del posicionamiento en IA: de poco sirve una respuesta bien escrita si el rastreador que debería citarla recibe un <div> vacío.

¿Cómo procesa Google una página con JavaScript?

Renderizar es ejecutar el JavaScript de una página para obtener el HTML final que ve el usuario. Google lo hace en tres fases, según su guía de JavaScript para SEO1:

  1. Rastreo. Googlebot descarga la URL, comprueba que robots.txt la permite y extrae los enlaces del HTML que recibe.
  2. Renderizado. Las páginas que responden con un código 200 entran en una cola. Cuando hay recursos, un Chromium sin interfaz ejecuta el JavaScript. Google dice que una página puede pasar unos segundos en esa cola, pero que puede tardar más.
  3. Indexación. Google usa el HTML renderizado para descubrir más enlaces y para indexar el contenido.

Aun así, la misma guía recomienda el renderizado en servidor o el prerenderizado: hace la web más rápida para usuarios y rastreadores, y no todos los bots pueden ejecutar JavaScript1. Añade un aviso que conviene leer dos veces: si Google encuentra noindex en el HTML original, puede saltarse el renderizado. Quitar esa etiqueta con JavaScript no sirve.

¿Ejecutan JavaScript los rastreadores de IA?

La fuente pública más citada es «The rise of the AI crawler», que Vercel publicó el 17-12-2024 con datos de la consultora MERJ2. Conviene saber exactamente qué midió:

  • Qué datos. Un mes de tráfico de rastreadores en la red de Vercel, que incluye nextjs.org y varios sitios con tecnologías distintas.
  • Cuánto tráfico. En ese mes, GPTBot hizo 569 millones de peticiones, Claude 370 millones, AppleBot 314 millones y PerplexityBot 24,4 millones, frente a 4.500 millones de Googlebot.
  • Qué concluyó. Ninguno de los grandes rastreadores de IA de OpenAI (OAI-SearchBot, ChatGPT-User, GPTBot), Anthropic (ClaudeBot), Meta (Meta-ExternalAgent), ByteDance (Bytespider) y Perplexity (PerplexityBot) ejecutaba JavaScript. ChatGPT descargaba ficheros JavaScript en el 11,50 % de sus peticiones y Claude en el 23,84 %, pero no los ejecutaban.
  • Quién sí. Gemini se apoya en la infraestructura de Googlebot y renderiza; AppleBot también, con un rastreador basado en un navegador.
  • Qué dejó fuera. Microsoft Copilot, porque no tiene un user-agent propio que permita seguirlo.

Dos límites que el propio estudio no esconde, o que conviene añadir. No detalla cómo distinguió entre descargar y ejecutar un fichero. Y tiene casi dos años: los rastreadores cambian y alguno puede haber empezado a renderizar desde entonces. Las páginas de rastreadores de OpenAI, Anthropic y Perplexity explican para qué sirve cada uno, pero no dicen si ejecutan JavaScript345. La conclusión prudente sigue siendo la misma que da Vercel: lo importante tiene que llegar en el HTML del servidor.

¿Qué recibe un rastreador sin JavaScript de una SPA?

Una aplicación de una sola página (SPA) construida con renderizado en el cliente manda un HTML casi vacío y un fichero JavaScript que lo rellena en el navegador. Esto es lo que recibe un rastreador que no ejecuta JavaScript al pedir una ficha de servicio:

<!-- Renderizado en el cliente: lo que llega del servidor -->
<!doctype html>
<html lang="es">
<head>
  <title>Cargando…</title>
  <script type="module" src="/assets/app.4f9c.js"></script>
</head>
<body>
  <div id="root"></div>
  <!-- Todo el texto lo inserta app.4f9c.js en el navegador -->
</body>
</html>

Y esto es lo que recibe el mismo rastreador si la página se renderiza en el servidor o se genera como HTML estático:

<!-- Renderizado en el servidor o estático: el texto ya viene dentro -->
<!doctype html>
<html lang="es">
<head>
  <title>Reformas de cocina en Valencia: precios y plazos</title>
  <meta name="description" content="Qué incluye una reforma de cocina, cuánto cuesta y cuánto tarda.">
</head>
<body>
  <main>
    <h1>Reformas de cocina en Valencia</h1>
    <p>Reformamos cocinas completas con presupuesto cerrado y plazo por escrito…</p>
  </main>
  <!-- El JavaScript llega después y solo añade interactividad -->
  <script type="module" src="/assets/app.4f9c.js"></script>
</body>
</html>

En el primer caso, OAI-SearchBot o PerplexityBot no tienen título, ni encabezado, ni una frase que citar. En el segundo, el texto está ahí aunque el JavaScript no llegue a ejecutarse.

Renderizado en servidor, estático e hidratación: qué elegir

web.dev, el sitio de Google para desarrolladores web, define cada técnica así6:

Técnica
Renderizado en el cliente (CSR)
Qué es
La página se monta en el navegador con JavaScript que modifica el DOM
Qué recibe un rastreador sin JavaScript
Un HTML casi vacío
Técnica
Renderizado en el servidor (SSR)
Qué es
El servidor genera el HTML de cada petición y lo envía en lugar de JavaScript
Qué recibe un rastreador sin JavaScript
El contenido completo
Técnica
Renderizado estático
Qué es
El HTML de cada URL se genera por adelantado, al compilar el sitio
Qué recibe un rastreador sin JavaScript
El contenido completo
Técnica
Prerenderizado
Qué es
Se ejecuta la aplicación al compilar para guardar su estado inicial como HTML
Qué recibe un rastreador sin JavaScript
El contenido del estado inicial
Técnica
Hidratación
Qué es
El JavaScript del cliente añade estado e interactividad a un HTML ya renderizado en el servidor
Qué recibe un rastreador sin JavaScript
El contenido completo; el JavaScript solo añade comportamiento

La regla práctica: si el texto que quieres que te citen está en el HTML antes de ejecutar nada, da igual qué rastreador llegue. Los frameworks actuales (Next.js, Nuxt, Astro, SvelteKit, Angular con SSR) ofrecen renderizado en servidor o estático; el trabajo suele ser activarlo en las plantillas que importan, no rehacer la web.

Hay una cuarta vía que conviene evitar: el renderizado dinámico, que sirve HTML renderizado a los bots y la versión con JavaScript a las personas. Google dice que fue un apaño y no una solución a largo plazo, y recomienda en su lugar el renderizado en servidor, el estático o la hidratación7. Además, solo funciona con los bots que tu lista reconozca, y los rastreadores de IA nuevos aparecen cada pocos meses, como se ve en la guía de rastreadores de IA y robots.txt.

Cómo comprobar lo que ve un rastreador

Tres pruebas, de la más rápida a la más completa.

1. Ver el código fuente. En el navegador, Ctrl+U (o view-source: delante de la URL) enseña el HTML tal como llega del servidor. Busca con Ctrl+F una frase de tu texto principal. Ojo: «Inspeccionar elemento» enseña el DOM después de ejecutar JavaScript, que es justo lo que no quieres mirar.

2. Pedir la página con curl. Sirve para automatizarlo y para usar el user-agent de un rastreador:

# ¿Está la frase en el HTML servido? 1 o más = sí; 0 = solo la pinta JavaScript
curl -s -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0)" https://www.example.com/servicios/ \
  | grep -c "presupuesto cerrado"

# ¿Cuántas palabras de texto llegan sin JavaScript? Compara con lo que ves en pantalla
curl -s https://www.example.com/servicios/ \
  | sed -e 's/<script[^>]*>.*<\/script>//g' -e 's/<[^>]*>/ /g' | wc -w

El recuento de palabras es aproximado (los scripts de varias líneas se cuelan), pero basta para ver la diferencia entre 40 y 900 palabras.

3. La inspección de URL de Search Console. Te dice cómo ve Google la página: la prueba en directo muestra una captura de la página renderizada tal como la ve su herramienta de inspección, junto con el HTML, las cabeceras HTTP y los mensajes de la consola de JavaScript8. Si la captura sale vacía o a medias, Google tampoco ve tu contenido. Si la captura está bien, recuerda que eso dice algo de Google, no de los rastreadores de IA.

Fallos habituales que solo se ven sin JavaScript

  • Pestañas y acordeones que cargan su contenido al hacer clic. Si el texto no está en el HTML hasta que alguien pulsa, ningún rastreador lo ve. Si está en el HTML y solo se oculta con CSS, no hay problema de acceso.
  • Preguntas frecuentes montadas con JavaScript. Es justo el formato que más se cita, y el que más a menudo llega desde una API.
  • Precio y disponibilidad pedidos a una API. Google avisa de que los datos estructurados generados con JavaScript pueden hacer que sus rastreos de Shopping sean menos frecuentes y menos fiables9. Un rastreador de IA, directamente, no los verá.
  • URL con #. Google dice que no puede resolver de forma fiable las URL que cargan contenido con fragmentos y pide usar la History API1.
  • noindex en el HTML inicial que JavaScript quita después: Google puede no llegar a renderizar la página1.

Lo que se cita, además de accesible, tiene que ser extraíble; cómo escribirlo está en la guía de contenido citable por la IA.

Qué comprueba SmoothSeen

SmoothSeen cuenta las palabras del HTML que manda el servidor y las de la misma página después de ejecutar el JavaScript en un navegador, y te avisa cuando buena parte del texto depende del navegador. Lo verás en la mitad de Posicionamiento IA del análisis, junto al acceso de los rastreadores en robots.txt. También avisa si marcas preguntas frecuentes con FAQPage y no aparecen en el HTML.

Preguntas frecuentes

¿Google indexa el contenido generado con JavaScript?

Sí. Google rastrea la página, la pone en una cola de renderizado, ejecuta el JavaScript con un Chromium sin interfaz e indexa el HTML resultante. Aun así, recomienda el renderizado en servidor o el prerenderizado porque la página es más rápida y porque no todos los bots ejecutan JavaScript. Ten en cuenta que el renderizado puede retrasarse y que un noindex inicial puede impedirlo.

¿ChatGPT lee el contenido que carga JavaScript?

Según la medición que Vercel publicó en diciembre de 2024, no: OAI-SearchBot, ChatGPT-User y GPTBot descargaban a veces ficheros JavaScript, pero no los ejecutaban. OpenAI no documenta cómo procesan sus rastreadores las páginas, así que lo prudente es que el texto que quieres que cite ChatGPT llegue en el HTML del servidor y no dependa del navegador.

¿Tengo que rehacer mi web si es una SPA?

Normalmente no. La mayoría de frameworks actuales permiten renderizar en el servidor o generar HTML estático por página, y basta con activarlo en las plantillas que quieres que te citen: servicios, fichas, artículos y preguntas frecuentes. Las zonas privadas, como el panel de usuario o el carrito, pueden seguir pintándose en el navegador sin que eso afecte a tu visibilidad.

¿El renderizado dinámico es una buena solución?

Google ya no lo recomienda: lo describe como un apaño, no como una solución a largo plazo, y propone el renderizado en servidor, el estático o la hidratación. Además depende de reconocer a cada bot por su user-agent, y la lista de rastreadores de IA cambia cada pocos meses. Si un rastreador nuevo no está en tu lista, recibirá la página vacía.

Qué hacer ahora

Abre el código fuente de tu página más importante y busca una frase del texto principal. Si no está, activa el renderizado en servidor o el estático en esa plantilla antes de tocar nada más. Cuando el texto ya llegue en el HTML, sigue con el resto de bloques de la guía de posicionamiento en IA.

Fuentes

  1. 1Understand JavaScript SEO Basics, Google Search Central, actualizada el 04-03-2026.
  2. 2The rise of the AI crawler, Giacomo Zecchini, Alice Alexandra Moore, Malte Ubl y Ryan Siddle, Vercel, publicada el 17-12-2024, consultada el 07-10-2026.
  3. 3Overview of OpenAI Crawlers, OpenAI, consultada el 07-10-2026.
  4. 4Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic (Claude Help Center), actualizada el 07-04-2026.
  5. 5Perplexity Crawlers, Perplexity, consultada el 07-10-2026.
  6. 6Rendering on the Web, Addy Osmani y Jason Miller, web.dev, actualizada el 05-01-2026.
  7. 7Dynamic Rendering as a workaround, Google Search Central, actualizada el 10-12-2025.
  8. 8URL Inspection tool, Ayuda de Search Console, consultada el 07-10-2026.
  9. 9Generate structured data with JavaScript, Google Search Central, actualizada el 10-12-2025.

Cómo citar este artículo

SmoothSeen. (2026, 7 de octubre). Contenido que solo se ve con JavaScript: lo que Google renderiza y los rastreadores de IA no leen. https://smoothseen.com/es/blog/contenido-javascript-ia/

Quién lo escribe

SmoothSeen es una herramienta de auditoría web que mide el posicionamiento en buscadores y en asistentes de IA y entrega informes con la marca de la agencia.

Este blog es de SmoothSeen: cuando un artículo habla del producto, lo hace sabiendo que es el nuestro. Las cifras de terceros enlazan a su fuente original.

Historial de cambios

  • Primera versión.

Sigue leyendo

JavaScript SEO: lo que Google renderiza y la IA no lee