Sin JavaScript: lo que un agente de IA recibe realmente al solicitar tu sitio

Tu ves una pagina completa. El agente recibe un archivo HTML crudo. Si tu contenido se ensambla en el navegador con JavaScript, hay una posibilidad real de que lo que llego al otro lado fuera un cascaron vacio. La unica medicion publica que encontre sobre esto, de Vercel y MERJ en diciembre de 2024, concluyo que ninguno de los grandes rastreadores de IA ejecuta JavaScript: si descargan los archivos JS (el 11,50% de las solicitudes de ChatGPT, el 23,84% de las de Claude) pero nunca los ejecutan. Google es la excepcion: renderiza con una version evergreen de Chromium, aunque tambien se detiene a los 2MB. La prueba en si toma dos minutos y una linea de curl.

La unica pregunta que importa: que hay en el HTML inicial

Hay una diferencia entre lo que tu sitio muestra y lo que tu sitio envia. El navegador recibe un documento HTML, descarga los archivos JavaScript, los ejecuta, hace mas llamadas a APIs y ensambla con todo eso la pagina que ves. Toda esa cadena ocurre en la maquina del usuario, no en tu servidor. Un agente que solicita la URL y se detiene ahi recibe unicamente el primer paso.

En la mayoria de los gestores de contenido clasicos esto no es un problema, porque el HTML llega del servidor ya formado. La dificultad empieza cuando el sitio esta construido como una aplicacion de lado del cliente: React, Vue o Angular generando el contenido despues de la carga. En ese caso el documento que sale de tu servidor pueden ser tres kilobytes de etiquetas vacias con un <div id=»root»></div> en medio, y todo lo demas se construye solo en el navegador.

Que se ha medido realmente y que no

Este tema exige cuidado, porque esta lleno de numeros que circulan sin fuente. Lo que si existe: un estudio conjunto de Vercel y MERJ publicado el 17 de diciembre de 2024, que analiza registros reales de sitios grandes. Su hallazgo central es que ninguno de los grandes rastreadores de IA (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot y otros) ejecuta JavaScript. Descargan los archivos JS pero no los ejecutan. La excepcion en su lista es AppleBot, que si renderiza a traves de un navegador.

El mismo estudio tambien da una idea del volumen: unos 569 millones de solicitudes mensuales de GPTBot y alrededor de 370 millones de Claude, en conjunto cerca de una quinta parte del volumen de solicitudes de Googlebot en ese periodo.

Una advertencia que estoy obligado a hacer: esa medicion es de diciembre de 2024, sobre una muestra limitada de sitios. No es una medicion de toda la web ni una cifra de 2026. Revise la documentacion oficial de OpenAI, Anthropic y Perplexity: ninguna de las tres documenta si sus bots renderizan JavaScript. Esa ausencia es un hallazgo en si misma: no puedes apoyarte en una promesa que nunca se hizo, asi que la unica suposicion segura es que el contenido tiene que estar en el HTML.

Google es la excepcion, no la regla

Google Search Central afirma de forma explicita, en una pagina actualizada por ultima vez el 4 de marzo de 2026, que el Buscador de Google ejecuta JavaScript con una version evergreen de Chromium, y que Googlebot pone en cola para renderizado todas las paginas que devuelven un codigo de estado 200. En el mismo documento Google agrega la advertencia mas relevante aqui: no todos los bots pueden ejecutar JavaScript.

Vale la pena conocer dos limites practicos de Google. Primero, segun la documentacion de Googlebot, el rastreador descarga los primeros 2MB de un tipo de archivo soportado y se detiene ahi. Si tu HTML pesa mas que eso, todo lo que quede despues del corte simplemente no se lee. Segundo, sobre las funciones basadas en IA, Google declara que no hay requisitos tecnicos adicionales mas alla de que la pagina este indexada y sea elegible para aparecer con un fragmento. No hay archivo especial ni marcado dedicado: lo que se lee bien en el Buscador se lee bien alli tambien.

Tres patrones que vacian la pagina

Renderizado del lado del cliente. El caso clasico. El documento que llega del servidor contiene un cascaron y el contenido se carga despues. Facil de detectar: el codigo fuente de la pagina es mucho mas corto que lo que ve el ojo.

Contenido que solo se abre al interactuar. Acordeones, pestanas, «cargar mas», scroll infinito. Si el contenido se inyecta en el DOM solo despues de un clic, no existe en el documento. Si existe en el HTML y solo esta oculto con CSS, si esta ahi, y eso es perfectamente valido.

Capas que bloquean el contenido. Un banner de cookies que exige consentimiento antes de cargar el contenido, un muro de pago, un modal de inicio de sesion o una capa de gestion de bots que devuelve un desafio. En esos casos el bot si recibe una pagina, pero no la tuya.

Como comprobarlo en dos minutos

No hace falta ninguna herramienta externa. Con tres lineas basta para saber exactamente que sale de tu servidor:

La interpretacion es sencilla. Si la linea 2 devuelve un numero cercano al recuento de palabras que ves en la pagina, todo esta bien. Si devuelve 40 palabras para una pagina de 1.200, el contenido se esta construyendo en el navegador. Si la linea 3 devuelve 0, tu frase central no existe en ninguna respuesta que se genere jamas a partir de esa pagina. Tambien vale la pena ejecutar la misma comprobacion con un user-agent de navegador normal y comparar: una diferencia grande entre ambos indica un servidor que entrega contenido distinto a los bots.

Como confirmar que el bot es autentico

Antes de sacar conclusiones de tu registro, asegurate de que quien dijo ser GPTBot realmente lo sea. Todos los grandes proveedores publican listas oficiales de direcciones IP, y Google publica ademas un metodo de verificacion por DNS inverso:

Google es el unico de los cuatro que ofrece verificacion por DNS inverso. Con los demas, comparar la IP con la lista oficial es la unica comprobacion disponible. Conviene descargar estos archivos de forma automatica en lugar de copiar rangos a mano: cambian.

Que hacer cuando la respuesta es «la pagina esta vacia»

La solucion depende de la arquitectura, pero la direccion es la misma en todos los casos: mover el ensamblaje del contenido del navegador al servidor.

Renderizado del lado del servidor o generacion estatica. En los frameworks modernos esto es una configuracion por pagina, no una reescritura. El resultado es HTML completo en la primera respuesta, lo que ademas mejora el tiempo de carga para los usuarios humanos.

Asegurate de que el contenido central no dependa de una interaccion. Un acordeon cuyo contenido esta en el HTML y se oculta con CSS es una solucion perfectamente valida. Un acordeon que descarga su contenido al hacer clic, no.

Comprueba que pasa antes del consentimiento. Si el banner de cookies bloquea el contenido hasta que haya un clic, el bot no ve nada. El contenido tiene que estar en el documento incluso cuando no se ha hecho clic en nada.

Vuelve a medir, no supongas. Despues de cada cambio, la misma linea de curl. La comprobacion toma segundos, y dar por hecho que funciono es exactamente lo que creo el problema en primer lugar.

Un orden de prioridades practico

Si tienes una hora, este es el orden que recomiendo. Primero, ejecuta la comprobacion con curl en las tres paginas mas importantes del sitio: la portada, la pagina principal de servicio y el articulo con mas trafico. Luego compara el recuento de palabras con lo que realmente se ve. Solo si hay una diferencia deberias abrir la pregunta de arquitectura. En la mayoria de los sitios WordPress y de marketing la respuesta sera que todo esta bien, y ese es un resultado perfectamente bueno: mejor saberlo que pasar un mes resolviendo un problema que no tienes.

Preguntas frecuentes