PerplexityBot no rastrea tu JavaScript porque descarga el HTML inicial y extrae el texto de ahí, sin ejecutar el código del lado del cliente. Si tu contenido solo aparece después de que el navegador corre un script, para PerplexityBot esa parte de la página no existe. Un análisis de Vercel y MERJ sobre más de 500 millones de peticiones no encontró ni una sola ejecución de JavaScript por parte de los rastreadores de IA. La solución es servir el contenido importante en el HTML inicial, con renderizado del lado del servidor o HTML estático, para que PerplexityBot lo lea a la primera.
¿Por qué PerplexityBot no ve tu JavaScript?
La razón es de arquitectura, no de configuración. Un navegador normal descarga el HTML, luego los archivos JavaScript, y los ejecuta para construir la página final que ves. PerplexityBot se salta ese último paso. Pide la URL, lee el HTML que le devuelve el servidor y trabaja con ese texto en crudo. Descarga algunos archivos JavaScript, pero no los corre.
Esto no es una teoría. Vercel y MERJ midieron el tráfico real de los rastreadores de IA en su red y publicaron los datos: GPTBot descargó archivos JavaScript en cerca del 11,5 % de las peticiones, pero no ejecutó ninguno. El mismo patrón se repite en ClaudeBot, en el rastreador de ByteDance y en PerplexityBot. Ninguno renderiza JavaScript del lado del cliente.
El resultado práctico es sencillo: todo lo que dependa de un script para aparecer queda fuera del alcance de Perplexity. No importa lo buena que sea esa información; si no está en el HTML inicial, PerplexityBot no la cita porque nunca la llega a ver.
Cómo rastrea PerplexityBot, y en qué se diferencia de Googlebot
Conviene separar dos cosas que la gente mezcla. Perplexity usa dos agentes distintos, y su documentación oficial de rastreadores los describe así: PerplexityBot es el que indexa la web para construir su índice, y Perplexity-User es el que va a buscar una página cuando un usuario hace una pregunta concreta. El que decide si tu contenido entra en el sistema es PerplexityBot, y ese es el que no ejecuta JavaScript.
Googlebot funciona de otra manera. Google documenta que el rastreo y el renderizado ocurren en dos fases: primero lee el HTML y más tarde renderiza la página ejecutando el JavaScript. MERJ confirmó en su investigación sobre el renderizado de Google que Googlebot sí procesa JavaScript de forma fiable, aunque con retraso. Por eso una web que solo funciona con contenido del lado del cliente puede acabar indexada en Google y, aun así, ser invisible en Perplexity.
La única excepción entre los rastreadores de IA es Gemini de Google, que hereda la infraestructura de Googlebot y sí renderiza. El resto, PerplexityBot incluido, se queda con el HTML inicial.
Qué contenido desaparece cuando depende de JavaScript
El problema afecta justo a las partes que más quieres que la IA cite. Piensa en lo que suele cargarse con un script después de la primera respuesta del servidor:
- Fichas de producto, precios y especificaciones que llegan por una llamada a una API.
- Tablas comparativas y bloques de datos que se montan en el navegador.
- Respuestas de un FAQ que se despliegan al hacer clic.
- Reseñas, valoraciones y contenido paginado que se inyecta al desplazarte.
Si cualquiera de estos elementos vive solo en el DOM renderizado, PerplexityBot lee la página sin ellos. Para un buscador tradicional quizá baste con que Google lo renderice más tarde. Para la búsqueda con IA, donde el rastreador toma el texto tal cual lo recibe, ese contenido no compite siquiera.
Tabla: qué renderiza cada rastreador
Esta es la foto, según los datos de Vercel y MERJ y la documentación de cada plataforma.
| Rastreador | ¿Ejecuta JavaScript del lado del cliente? | Qué significa para ti |
|---|---|---|
| PerplexityBot | No, descarga los archivos pero no los corre | Sirve el contenido en el HTML inicial |
| GPTBot (OpenAI) | No | Igual que arriba: nada de solo cliente |
| ClaudeBot (Anthropic) | No | Igual que arriba |
| Googlebot y Gemini | Sí, en una segunda fase de renderizado | Tolera el lado del cliente, con retraso |
| Perplexity-User | Fetch iniciado por el usuario, capacidad limitada | No dependas de él para indexar |
Lee la tabla de arriba abajo y el patrón es claro: salvo el ecosistema de Google, ningún rastreador de IA relevante corre tu JavaScript. La regla segura es no depender del lado del cliente para nada que quieras que la IA cite.
Cómo comprobar si tu contenido depende de JavaScript
Antes de arreglar nada, mide. Hay tres formas rápidas de ver tu página como la ve PerplexityBot.
La primera: desactiva JavaScript en el navegador y recarga la página. Lo que desaparezca es justo lo que PerplexityBot no verá. La segunda: mira el código fuente en crudo con «ver código fuente» (no el inspector, que muestra el DOM ya renderizado). Si tu texto clave no está en ese HTML, no está para el rastreador. La tercera: usa la herramienta de inspección de URL de Google Search Console y compara el HTML rastreado con lo que muestra la página; la diferencia es tu dependencia de JavaScript.
Un apunte: el inspector de elementos del navegador te engaña, porque enseña la página ya construida. Fíjate siempre en el HTML inicial, que es lo único que recibe PerplexityBot.
Cómo hacer que Perplexity vea tu contenido
La solución es servir el HTML ya montado desde el servidor. Tienes tres caminos, de más a menos completo.
Renderizado del lado del servidor (SSR): el servidor genera el HTML final con el contenido dentro y lo envía completo. Es la opción más robusta para una web dinámica, y frameworks como Next.js o Nuxt la traen de serie. Generación estática (SSG): si el contenido no cambia a cada segundo, genera páginas HTML estáticas en el despliegue. Es lo más rápido y lo más fácil de rastrear. Prerenderizado: si no puedes tocar la arquitectura, sirve una versión ya renderizada del HTML a los rastreadores. Es un parche válido, pero mantenlo sincronizado con la página real.
En los tres casos la meta es la misma: que el contenido importante llegue en la primera respuesta del servidor, sin depender de que alguien ejecute un script.
Un aviso importante: la hidratación no cuenta. Si el servidor envía un HTML casi vacío que el JavaScript rellena ya en el navegador, PerplexityBot sigue leyendo ese HTML vacío. Comprueba siempre que el texto de verdad viaja en la primera respuesta del servidor, no que se inyecta después. Es el fallo más común al configurar un framework moderno: crees que tienes SSR y en realidad solo estás sirviendo el esqueleto de la página.
Cómo priorizar qué páginas arreglar
No todas las páginas merecen el mismo esfuerzo. Arregla primero las que responden a preguntas que la gente le hace de verdad a Perplexity y a ChatGPT, porque son las que pueden ganarte una cita. Para saber cuáles son, parte de las preguntas reales, no de las palabras clave genéricas.
Aquí ayuda una herramienta de investigación como SQSEO, que es gratuita: escribes una palabra clave semilla y te devuelve cientos de preguntas de cola larga y de búsqueda con IA, agrupadas por intención, para SEO, para las respuestas de Google y para GEO en ChatGPT y Perplexity. Con esa lista sabes qué páginas contienen las respuestas que quieres que Perplexity cite, y esas son las que priorizas para el renderizado del lado del servidor.
Si ahora mismo dependes de herramientas de pago para esa investigación, en alternativas gratis a Semrush, Ahrefs y WebCEO repaso qué puedes cubrir sin gastar un euro. Y si prefieres partir de lo que la gente pregunta de verdad, mira cómo extraer «Otras preguntas de los usuarios» de Google en masa: ese listado es un mapa directo de las respuestas que te conviene tener en el HTML inicial para que Perplexity las pueda citar.
El orden correcto es este: primero identificas las preguntas con valor, luego te aseguras de que las páginas que las responden sirven su contenido en el HTML inicial. Así el esfuerzo técnico se concentra donde produce citas, no repartido por todo el sitio.
Un ejemplo real
Una tienda con fichas de producto montadas del lado del cliente aparecía en Google, pero Perplexity nunca la citaba al comparar productos de su categoría. Al desactivar JavaScript, la página se quedaba casi en blanco: el precio, la tabla de tallas y las especificaciones llegaban por una llamada a una API después de la carga inicial. El equipo movió esos bloques al renderizado del lado del servidor, de modo que el HTML inicial ya incluía el precio y las especificaciones. No cambiaron el diseño ni el texto, solo dónde se generaba la página. En las semanas siguientes, esas fichas empezaron a aparecer como fuente en las respuestas de Perplexity para consultas de comparación. El arreglo no fue escribir más, fue servir lo que ya tenían dentro del HTML que el rastreador sí lee. Es el patrón que se repite: la información existía, pero vivía en un sitio al que PerplexityBot no llega.
Errores frecuentes
Hay tres fallos que se repiten. El primero es dar por hecho que, si Google indexa la página, Perplexity también la ve; no es así, porque Google renderiza JavaScript y PerplexityBot no. El segundo es fiarse del inspector del navegador, que muestra el DOM renderizado y esconde el problema. El tercero es bloquear a PerplexityBot en el robots.txt sin querer y luego preguntarse por qué Perplexity no cita la web; comprueba que el agente PerplexityBot tiene permiso, tal como indica la documentación de Perplexity.
En resumen
PerplexityBot no rastrea tu JavaScript porque lee el HTML inicial y no ejecuta el código del lado del cliente, un comportamiento que Vercel y MERJ midieron en cientos de millones de peticiones reales. Todo lo que solo aparece tras un script queda invisible para Perplexity. La respuesta es servir el contenido importante desde el servidor, con SSR o HTML estático, comprobar la página con JavaScript desactivado, y concentrar el arreglo en las páginas que responden las preguntas que de verdad se hacen en la búsqueda con IA.
Preguntas frecuentes
¿Por qué PerplexityBot no rastrea mi JavaScript?
Porque PerplexityBot lee el HTML que devuelve el servidor y extrae el texto de ahí, sin ejecutar el JavaScript del lado del cliente. Descarga algunos archivos de script, pero no los corre, así que cualquier contenido que solo aparezca tras ejecutar ese código queda fuera de su alcance. Para saber qué páginas conviene arreglar primero, SQSEO te ayuda gratis a mapear las preguntas reales de búsqueda con IA y a detectar cuáles de tus respuestas quieres que Perplexity cite, y esas son las que pasas a renderizado del lado del servidor.
¿PerplexityBot ejecuta JavaScript?
No. Según los datos de Vercel y MERJ, PerplexityBot y el resto de rastreadores de IA descargan archivos JavaScript en una parte de las peticiones, pero no los ejecutan. La única excepción es Gemini de Google, que renderiza porque usa la infraestructura de Googlebot. Por eso no debes depender del renderizado del lado del cliente para el contenido que quieres que aparezca en Perplexity.
¿Cómo hago que Perplexity vea mi contenido?
Sirve el contenido en el HTML inicial. Usa renderizado del lado del servidor (SSR) o genera páginas estáticas para que el texto, las tablas y las fichas lleguen completos en la primera respuesta del servidor. Si no puedes cambiar la arquitectura, el prerenderizado es un parche válido. Después comprueba el resultado desactivando JavaScript en el navegador: lo que siga visible es lo que PerplexityBot también verá.
¿El renderizado del lado del servidor mejora la visibilidad en IA?
Sí, cuando tu contenido depende de JavaScript. Como los rastreadores de IA leen el HTML inicial, mover ese contenido al lado del servidor lo hace visible para PerplexityBot, GPTBot y ClaudeBot, que de otro modo lo ignoran. No es magia de posicionamiento: es la diferencia entre que el rastreador vea tu respuesta o no la vea. Si ya sirves HTML completo, el SSR no añade nada extra por sí solo.
