Una tienda online perdió el 47% de su visibilidad en la búsqueda con IA después de que una actualización cambiara cómo se renderizan las páginas. Las mismas páginas de producto seguían posicionadas en Google. Pero ChatGPT, Claude y Perplexity no devolvían ningún resultado. La diferencia era el renderizado con JavaScript.
Esto le pasa a toda web que depende del renderizado en el cliente. Una landing page de un SaaS creada con un framework de JavaScript nunca aparece en las respuestas de ChatGPT. Una web de noticias que funciona sobre un framework de JavaScript no tiene presencia en Perplexity. Una base de conocimiento que renderiza el contenido con JavaScript sigue invisible para los rastreadores de IA. No son casos raros. Es el comportamiento por defecto de la mayoría de los frameworks web modernos.
La diferencia entre una web basada en JavaScript y una visible para la IA no está en la complejidad ni en el presupuesto. Está en entender qué pasa en esos primeros milisegundos cuando llega un rastreador.
Qué ven los rastreadores de IA cuando piden tu página
El rastreador de Google ejecuta JavaScript. Espera a que la página se renderice, captura el estado visual final y lo indexa. La mayoría de los rastreadores de IA no lo hacen.
Cuando el rastreador de ChatGPT (GPTBot) llega a tu web, esta es la secuencia: 1. Descarga el archivo HTML 2. Extrae el texto visible en ese HTML sin procesar 3. Pasa a la siguiente página
El JavaScript que renderiza tu titular, la descripción de tu producto y el cuerpo de tu artículo nunca se ejecuta. El rastreador ve las referencias a los archivos de JavaScript, pero las ignora. Tu página aparece como una cáscara sin contenido.
Esto pasa porque los rastreadores de IA están diseñados para la velocidad y la eficiencia. Ejecutar JavaScript es lento. Requiere arrancar un navegador, esperar a que carguen los recursos, gestionar errores y controlar los tiempos de espera. Cuando rastreas miles de millones de páginas al día, ejecutar JavaScript sale demasiado caro.
Google invierte en esa infraestructura porque sus resultados dependen de entender el renderizado visual. Los buscadores de IA priorizan la extracción de texto sin procesar. Están optimizados para sacar datos y citas directamente del HTML, no de lo que aparece después de que JavaScript lo transforma.
Qué tipos de renderizado causan problemas a los rastreadores de IA
No todos los frameworks de JavaScript causan la misma pérdida de visibilidad. El problema está sobre todo en el renderizado en el cliente (CSR), donde JavaScript se ejecuta en el navegador y construye la página después de que cargue el HTML.
Renderizado en el cliente (CSR): los frameworks de JavaScript más usados cuando están configurados como CSR. El HTML llega vacío o con marcadores de carga. JavaScript rellena el contenido después de la descarga. Los rastreadores de IA no esperan.
Renderizado en el servidor (SSR): frameworks pensados para construir la página en el servidor. El servidor arma la página con el contenido ya insertado en el HTML. El navegador recibe el HTML completo. Los rastreadores de IA lo ven todo de inmediato.
Generación estática (SSG): generadores de sitios estáticos. Las páginas se construyen de antemano y se publican como archivos HTML estáticos. No hay renderizado en el momento de la petición. Los rastreadores de IA reciben todo el contenido al instante.
Aplicaciones de una sola página (SPA): la categoría de mayor riesgo. Una SPA carga un solo archivo HTML y usa JavaScript para cambiar el contenido según la navegación. Cada ruta se ve igual para un rastreador, salvo que el servidor gestione cada ruta de forma específica.
En el momento en que eliges el CSR como estrategia de renderizado, creas una barrera invisible entre tu contenido y todos los rastreadores de IA de internet.
Por qué importa más de lo que crees
La búsqueda con IA aún es joven, pero su adopción se acelera. Los estudios muestran que las consultas en buscadores de IA crecen más rápido que las búsquedas web tradicionales. ChatGPT, Perplexity y Claude se están convirtiendo en herramientas de investigación principales para profesionales, estudiantes y personas que toman decisiones.
Cuando alguien le pregunta a ChatGPT por los "mejores creadores de webs para pequeñas empresas", la IA elige qué marcas citar. Esa decisión depende de qué contenido puede leer. Si tu página funciona con JavaScript, es invisible.
Esto no es un problema del futuro. Un análisis de 2025 de más de 500M de peticiones de GPTBot encontró que las webs que dependen de JavaScript recibían bastantes menos citas que sus competidoras renderizadas en el servidor dentro del mismo sector. La brecha fue mayor en contenido técnico, páginas de producto y guías prácticas, justo los tipos de contenido que los motores de IA priorizan.
Para las empresas B2B y de ecommerce, las citas en IA se están convirtiendo en una palanca de visibilidad frente a la competencia. Que te citen en una respuesta de ChatGPT o en un fragmento de Perplexity puede aportar tanto tráfico como una primera página de Google. Pero no pueden citarte si el rastreador no puede leer tu contenido.
Cómo decidir qué hacer al respecto
No todas las webs necesitan abandonar el renderizado en el cliente. La decisión depende de tres factores: el tipo de contenido, tu audiencia y el valor de negocio que tiene la visibilidad en IA en tu caso concreto.
Hazte primero estas preguntas:
¿Tu contenido merece una cita de IA? Noticias, guías prácticas, comparativas de productos, artículos de investigación, consejos de expertos. A estos la IA los cita. La documentación técnica, las herramientas interactivas y los paneles que existen sobre todo para usuarios con sesión iniciada, no. Si tu web es sobre todo de este segundo tipo, el renderizado con JavaScript importa menos.
¿Tu audiencia busca en motores de IA? Profesionales B2B, personas que investigan productos, estudiantes, desarrolladores. Usan mucho la búsqueda con IA. Si tu audiencia es muy de nicho y busca solo en Google, la visibilidad en IA tiene menos retorno inmediato.
¿Cuánto cuesta ser invisible? Para una web de noticias o una base de conocimiento, no tener ninguna cita de IA es una desventaja frente a la competencia. Para la intranet de una empresa o un SaaS solo para miembros, es irrelevante. Para una tienda online, depende de si tus clientes descubren productos a través de recomendaciones de compra de la IA.
Si respondiste "contenido digno de una cita de IA", "sí, mi audiencia usa la búsqueda con IA" y "perder visibilidad es un coste real", adelante. Si las respuestas están mezcladas, quizá debas priorizar de otra forma.
Renderizado en el servidor: la solución más completa
El SSR resuelve el problema de JavaScript de forma integral. El servidor construye la página completa con todo el contenido antes de enviarla al navegador. Cuando llega cualquier rastreador, el contenido ya está ahí.
Cómo funciona: cuando alguien (o un bot) pide una página, tu servidor ejecuta tu código y produce el HTML final. Ese HTML incluye tu titular, el texto de tu artículo y los detalles de tu producto. El navegador recibe una página completa y la muestra de inmediato. JavaScript todavía puede mejorar la interactividad, pero el contenido ya es accesible.
Plataformas que hacen sencillo el SSR: existen frameworks creados específicamente para que el SSR sea fácil. Escribes tus componentes una vez, el framework se encarga del renderizado en el servidor y la página llega ya construida.
La contrapartida: el SSR requiere recursos del servidor. Tu servidor procesa cada petición, construye el HTML y lo envía. Eso consume más CPU y memoria que servir archivos estáticos ya construidos. Las páginas lentas o complejas pueden aumentar el tiempo de respuesta, lo que afecta a métricas de rendimiento como el First Contentful Paint (FCP) y los Core Web Vitals.
En la mayoría de las webs, el impacto en el rendimiento es pequeño. En webs con mucho tráfico y páginas complejas, se nota. Se puede resolver con caché, computación en el borde u optimización del código, pero exige decisiones de arquitectura.
Prerenderizado: un enfoque más ligero para contenido estático
El prerenderizado construye tus páginas con antelación y las publica como archivos HTML estáticos. Cuando llega un rastreador, recibe una página completa al instante. Cuando alguien la visita, recibe un archivo estático que carga rapidísimo.
Hay servicios de prerenderizado que automatizan esto. Los apuntas a tu web, visitan cada URL de tu sitemap, renderizan cada página (ejecutando el JavaScript), capturan el HTML final y sirven esas versiones estáticas a los rastreadores, mientras los navegadores siguen recibiendo la versión interactiva.
Funciona si: tu contenido cambia poco. Entradas de blog, páginas de producto, documentación. Contenido que se actualiza, como mucho, una vez al día.
No funciona si: tu contenido es dinámico. Cifras de inventario, datos específicos de cada usuario, información en tiempo real, contenido personalizado. Si tu página se ve distinta para cada visitante, el prerenderizado no captura todas las versiones.
Coste y complejidad: estos servicios cuestan entre $99 y $499 al mes según el volumen de páginas. Mantienes dos versiones del contenido: una para el navegador (JavaScript) y otra prerenderizada para los rastreadores. Esto duplica la carga de mantenimiento. Cuando publicas un artículo nuevo, tienes que reconstruir y volver a publicar la versión estática.
Para webs con contenido estable, el prerenderizado es un punto medio práctico entre no hacer nada y migrar a SSR.
Renderizado dinámico: una opción táctica para algunas webs
El renderizado dinámico detecta qué user agent hace la petición. Si es un rastreador, sirve HTML renderizado en el servidor. Si es un navegador, sirve la versión con JavaScript. Así mantienes tu stack tecnológico actual y das a los rastreadores el contenido completo.
La idea es elegante en teoría. En la práctica, es frágil. Tienes que:
Mantener una lista de User-Agents de rastreadores de IA y actualizarla constantemente a medida que aparecen nuevos. Si se te escapa uno, ese rastreador ve la página en blanco.
Construir renderizado en el servidor solo para los rastreadores, mientras mantienes el renderizado en el cliente para los navegadores. En el fondo, es construir dos versiones de tu web.
Comprobar que ambas versiones sigan sincronizadas. Un error en la versión para rastreadores rompe en silencio tu visibilidad en la búsqueda con IA.
El renderizado dinámico funciona para webs de contenido sencillas. Para aplicaciones complejas, da más problemas que beneficios. Si vas a renderizar en el servidor para los rastreadores, es mejor renderizar para todos (eso es SSR).
Cómo saber si tu web tiene este problema ahora mismo
No hace falta adivinar. Puedes comprobarlo directamente.
Ver el código fuente de la página: haz clic derecho en tu página, elige "Ver código fuente de la página" y busca tu titular. Si tu titular no está en el HTML sin procesar, se renderiza con JavaScript. Los rastreadores de IA no lo verán.
Descargarla con curl: en tu terminal, ejecuta curl https://yoursite.com/your-page. Si el contenido no aparece, lo renderizó JavaScript.
Revisar tu robots.txt: si bloqueas a los rastreadores para que no ejecuten JavaScript, solo verán el HTML sin procesar. Revisa tu archivo robots.txt o los ajustes de rastreo de tu web.
Usar una herramienta de rastreo: una herramienta de rastreo SEO puede pedir tus páginas como lo haría un rastreador. Si el contenido aparece en el navegador pero no en el rastreador, el culpable es JavaScript.
Buscar directamente en los motores de IA: busca en ChatGPT, Perplexity o Claude frases concretas de tus páginas. Si tu contenido nunca aparece, tienes un problema de visibilidad por JavaScript.
Optimización por plataforma para los distintos rastreadores de IA
No todos los rastreadores de IA se comportan igual. Tienen distintas capacidades de renderizado, distintas frecuencias de rastreo y distintas preferencias de contenido.
ChatGPT (GPTBot): no ejecuta JavaScript. Descarga el HTML sin procesar. Usa el índice de un buscador independiente para el contenido en tiempo real. Frecuencia: más o menos semanal para contenido consolidado.
Claude (buscador independiente): no ejecuta JavaScript. Descarga el HTML sin procesar. Prioriza el contenido reciente y con autoridad. Frecuencia: varía según las señales de frescura del contenido.
Perplexity: no ejecuta JavaScript. Descarga el HTML sin procesar. Da mucho peso a la frescura. El contenido de más de 48 horas puede quedar en segundo plano. Frecuencia: alta para temas de actualidad, baja para contenido estático.
AI Overviews de Google: sí ejecuta JavaScript porque usa la misma infraestructura de renderizado que la Búsqueda de Google. Pero optimiza como si no lo hiciera: serás más visible para los demás buscadores de IA.
La conclusión práctica: no optimices para un solo rastreador. Renderiza en el servidor tu contenido clave y serás visible para todos.
En qué ayuda WEMASY
El creador de webs de WEMASY produce HTML renderizado en el servidor por defecto. Cada página que creas se construye con el contenido ya en el HTML antes de llegar al navegador. Sin renderizado con JavaScript. Tus páginas son visibles al instante para los rastreadores de IA.
Si estás evaluando un creador de webs y la visibilidad en la búsqueda con IA importa a tu negocio, el renderizado en el servidor debería ser un requisito, no algo que se añade después. Mira qué incluye cada plan de WEMASY.
Preguntas frecuentes
¿Puedo usar JavaScript para funciones interactivas sin bloquear a los rastreadores de IA?
Sí. Renderiza en el servidor el contenido principal (tu titular, el texto del artículo, los detalles del producto) y usa JavaScript para las mejoras (animaciones, validación de formularios, widgets interactivos). Esto se llama "mejora progresiva". El contenido ya está en el HTML y JavaScript añade el acabado por encima. Los rastreadores de IA ven el contenido principal. Los navegadores reciben la experiencia interactiva completa. Con el creador de webs de WEMASY, puedes configurarlo directamente en tu web.
¿Migrar al renderizado en el servidor hará más lenta mi web?
Puede, si tu servidor tiene poca potencia o tus páginas son complejas. El renderizado en el servidor moderno con capas de caché (como la caché en el borde de las plataformas de hosting modernas) puede ser incluso más rápido que el renderizado en el cliente. La diferencia es pequeña en la mayoría de las webs. Si te preocupa el rendimiento, prueba en un entorno de pruebas antes de comprometerte.
¿Tengo que cambiar todo mi stack tecnológico?
Si usas un framework de JavaScript con renderizado en el cliente, migrar a un framework con SSR significa reescribir tus componentes para que funcionen con renderizado en el servidor. No es un cambio rápido. Si tu web es nueva, elige desde el principio un framework que priorice el SSR. Si tienes una web consolidada, el prerenderizado o el renderizado dinámico pueden ser más prácticos a corto plazo.
¿Y si los rastreadores de IA acaban soportando la ejecución de JavaScript?
Es posible, pero no pronto. Ejecutar JavaScript es muy costoso en computación a gran escala. Mientras el valor de negocio de las citas en IA no justifique el coste de infraestructura, los rastreadores seguirán descargando el HTML sin procesar. Por ahora, renderiza tu contenido en el servidor y reduce tu riesgo.
¿El problema de renderizado con JavaScript de mi web perjudica mi posicionamiento en Google?
No. El rastreador de Google ejecuta JavaScript, así que tu posicionamiento en Google no se ve afectado. El problema son los buscadores de IA como ChatGPT, Claude y Perplexity. No ejecutan JavaScript. Renderiza tu contenido en el servidor si quieres visibilidad en los resultados de la búsqueda con IA, no porque Google lo exija. Es un problema distinto al del SEO.
¿Las webs de noticias tienen el mismo problema con JavaScript?
Sí, y a menudo se pasa por alto. Una web de noticias creada con un framework de JavaScript que renderiza el contenido en el cliente no recibe ninguna cita de IA, aunque el contenido esté publicado e indexado. Los medios lo han descubierto por casualidad cuando artículos posicionados en Google News no tenían ninguna mención en ChatGPT ni en Perplexity. Revisa el código fuente de la página. Si tu titular no está, arréglalo.