Renderizado JavaScript y motores generativos: lo que los robots de IA ven realmente.

Un robot de IA lee el HTML inicial, no la página renderizada

Los robots de búsqueda de IA leen el documento HTML que devuelve su servidor y se detienen ahí. Que sepamos, ni OpenAI, ni Anthropic, ni Perplexity documentan la ejecución de JavaScript por parte de sus agentes, y las observaciones disponibles apuntan en la misma dirección: un análisis publicado a finales de 2024 por Vercel, a partir de los logs de su red, concluía que los robots de estos tres proveedores descargaban a veces los archivos de script sin ejecutarlos. Nuestras propias pruebas, página por página, no contradicen esta constatación. Puede cambiar; hasta que se demuestre lo contrario, la regla de trabajo es sencilla: lo que no está en el HTML inicial no existe para un motor generativo.

Google es la excepción. Googlebot dispone de un servicio de renderizado basado en una versión reciente de Chromium, que ejecuta el JavaScript en una segunda pasada, después del rastreo, con un retraso variable. Bingbot también renderiza las páginas. Esto explica el caso típico con el que nos encontramos: una aplicación de página única bien presente en el índice de Google, y en los AI Overviews que se apoyan en él, pero ausente de ChatGPT, de Claude y de Perplexity.

La consecuencia va más allá de las aplicaciones de página única. Muchos sitios clásicos, construidos sobre un CMS que devuelve un HTML completo, inyectan después en JavaScript precisamente los elementos que dan valor a una fuente: los precios, las reseñas, las respuestas de una FAQ en acordeón, los datos estructurados. La página parece completa y falta la parte citable.

El test en diez minutos

El test consiste en recuperar la página como lo hace un robot de búsqueda de IA y comprobar después que el contenido que debe citarse está ahí. No requiere ninguna herramienta de pago ni acceso al servidor, solo una línea de comandos. El primer comando guarda el HTML inicial presentándose como OAI-SearchBot; el segundo busca una frase que usted sabe que aparece en pantalla; el tercero da un orden de magnitud del texto recibido, para compararlo con el texto visible.

# 1. El HTML inicial, tal como lo recibe un robot de búsqueda de IA
curl -s -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot" \
  https://www.exemple.fr/guide/delais-de-livraison/ -o initial.html

# 2. ¿Figura en él una frase visible en pantalla? (0 = ausente)
grep -c "livraison sous 48 heures" initial.html

# 3. Orden de magnitud del texto recibido, sin etiquetas
sed 's/<[^>]*>//g' initial.html | tr -s ' \n' | wc -w

# 4. ¿Están los datos estructurados en el documento?
grep -c 'application/ld+json' initial.html

La misma comprobación puede hacerse sin línea de comandos: en el navegador, «ver código fuente» muestra el HTML inicial, mientras que el inspector muestra el documento tras la ejecución. Desactivar el JavaScript en las herramientas de desarrollo y recargar la página ofrece una vista cercana a la de un robot de IA. En cambio, la herramienta de inspección de URL de Search Console muestra la página renderizada por Googlebot; tranquiliza erróneamente respecto a los demás motores.

Lo que se comprueba, por orden: el texto principal, los títulos de sección, las respuestas de las FAQ, los precios y la disponibilidad, las tablas y listas, los datos estructurados. Para cada elemento, la respuesta es binaria: presente en initial.html o ausente. En una muestra de veinte páginas representativas, el resultado señala por lo general una o dos plantillas defectuosas, rara vez todo el sitio.

Los ocho patrones que vacían una página

Las causas de ausencia se repiten de un sitio a otro. No todas están ligadas a la elección de un framework: varias afectan a sitios construidos sobre CMS clásicos, por acumulación de módulos y de scripts de terceros.

Tabla: desplácese horizontalmente.

El caso de los datos estructurados merece insistencia. Muchos equipos han adquirido la costumbre de añadir el JSON-LD mediante un gestor de etiquetas, porque es rápido y Google lo lee tras el renderizado. Para un robot que no ejecuta nada, ese bloque no existe: la entidad, el autor y la FAQ marcada desaparecen de golpe. El remedio es sencillo, y suele ser la primera corrección que pedimos: escribir el JSON-LD en la plantilla, en el servidor.

Por qué Google se las arregla, y por qué eso no le protege

Google renderiza las páginas porque tiene los medios y la antigüedad: su servicio de renderizado ejecuta el JavaScript a escala de la web, en una cola distinta de la del rastreo. Aun así, el renderizado no es gratuito. Se produce con retraso, falla cuando un recurso está bloqueado o es demasiado lento, y consume un presupuesto que Google asigna según la importancia que atribuye al sitio. Una página renderizada en el cliente se indexa, por tanto, más tarde, y a veces de forma incompleta, incluso en Google.

En los demás motores, la cuestión ni se plantea: sin renderizado, la página se lee tal cual. Y las cuatro condiciones descritas en nuestro método para ser citado se encadenan; una página inaccesible nunca se evalúa por su calidad. Un sitio puede así cumplir la primera condición para Google y fallarla para todos los demás, con el mismo código y el mismo robots.txt. Es uno de los casos en los que la cuota de citación, medida motor por motor, revela un problema que el posicionamiento clásico no muestra: buena presencia en AI Overviews, ausencia en el resto.

Añadamos un matiz sobre los agentes de consulta a petición del usuario. ChatGPT-User, Claude-User y Perplexity-User visitan una página cuando un usuario la solicita; nada indica que rendericen el JavaScript más que los robots de índice. El enlace que usted pega en una conversación para que el modelo «lea» su página sufre la misma limitación.

Las soluciones, de la más ligera a la más estructural

El principio común a todas las soluciones es el mismo: entregar el contenido citable en el HTML inicial y reservar el JavaScript para la interactividad. La forma de conseguirlo depende de la pila tecnológica y de lo que se pueda cambiar.

Los frameworks habituales ofrecen estos modos de forma nativa: Next.js, Nuxt, SvelteKit y Angular disponen de renderizado en el servidor y de generación estática; Astro está construido en torno a las islas. La migración no obliga a cambiar de framework; obliga a decidir, plantilla por plantilla, qué modo de renderizado se aplica, y a trasladar al servidor las llamadas de datos que alimentan el contenido citable.

Queda el renderizado dinámico: servir a los robots una versión prerrenderizada por un navegador sin interfaz, y a los usuarios la aplicación tal cual. Google lo describe como una solución provisional, aceptable mientras el contenido servido sea idéntico. Tiene dos debilidades propias de los motores generativos. La lista de agentes que hay que reconocer debe actualizarse con cada nuevo agente, y el renderizado sigue a las páginas con retraso. Sigue siendo una opción razonable para ganar tiempo en una aplicación que no se puede rehacer a corto plazo.

Priorizar: qué páginas primero

No todo el sitio necesita ser legible para un motor generativo. Una aplicación de negocio, un área de cliente o un configurador nunca serán citados, y no tienen por qué serlo. Las páginas que hay que tratar son las que responden a las preguntas de sus compradores: guías, comparativas, FAQ, fichas de producto con sus características, páginas de tarifas, páginas locales. El panel de prompts que sirve para medir la cuota de citación da la lista: cada pregunta designa la página que debería responderla, y esa página pasa el test.

La medición valida cada fase. Tras las correcciones, los logs deben mostrar a los robots de búsqueda de IA volviendo a las páginas corregidas con respuestas 200 de tamaño normal; unas semanas después, la cuota de citación en las preguntas correspondientes debe moverse, motor por motor. Si los logs no muestran ningún paso, el problema no es el renderizado sino el acceso, y hay que mirar del lado del robots.txt o de una regla del cortafuegos, lo que cubre nuestro artículo sobre los bloqueos involuntarios.

Las trampas tras la migración

Pasar al renderizado en el servidor no garantiza nada mientras no se haya validado con el test del HTML inicial. Los errores siguientes se repiten en nuestras auditorías de sitios migrados recientemente.

• Una plantilla renderizada en el servidor cuyo componente principal sigue cargando su texto mediante una llamada a la API al montarse: el cascarón está completo, el cuerpo llega después.
• Bloques «esqueleto» de carga servidos en el HTML inicial en lugar del contenido, y sustituidos después en la ejecución.
• Una hidratación que sustituye el contenido renderizado por una versión distinta, y un HTML inicial que ya no se corresponde con lo que ve el usuario.
• Una caché de CDN que sigue sirviendo el antiguo cascarón vacío a las peticiones sin cabeceras de navegador.
• Un renderizado dinámico cuya lista de agentes ignora OAI-SearchBot, Claude-SearchBot o PerplexityBot, más recientes que la lista.
• Un desafío JavaScript impuesto por el cortafuegos a las peticiones no humanas: un robot que no ejecuta nada nunca lo superará, y recibe una página de desafío en lugar del contenido.
• Un tiempo de respuesta del servidor degradado por el renderizado, que lleva a los robots a abandonar las páginas lentas.

Qué recordar