Renderizado de JavaScript y SEO: qué ve Google, qué ven las IA y cómo auditarlo

Google renderiza JavaScript, pero no hace clic ni scroll, y los crawlers de IA no pueden renderizarlo. Cómo revisarlo y qué corregir, con casos reales.

¿El JavaScript es malo para el SEO? No. Google lo lee, lo lee bien, y la mayoría de los sitios modernos no podría funcionar sin él. El renderizado de JavaScript, que es el proceso en el que un navegador o un buscador ejecuta el código de una página para armar lo que finalmente se ve, dejó hace años de ser el obstáculo que fue.

Pero que Google pueda renderizar no significa que el JavaScript no tenga costo. Lo he visto en sitios que llevaban meses optimizando contenido y metadatos sin resultados, cuando el problema real estaba en cómo se entregaba ese contenido. Google renderiza, sí, pero lo hace más tarde que cuando lee HTML, y nunca hace clic, nunca abre una pestaña ni baja por la página. Y los crawlers de ChatGPT, Claude o Perplexity directamente no tienen la capacidad de renderizar JavaScript: leen el HTML de la primera respuesta del servidor y con eso se quedan.

Las tres versiones de una página web: la que ven Google, la IA y las personas

Para entender cualquier problema de renderizado sirve partir por algo simple: una misma URL existe, en la práctica, en tres versiones distintas.

La primera es el HTML que entrega el servidor, lo que se ve con "Ver código fuente". La segunda es la página después de que se ejecuta el JavaScript, sin tocar nada, que técnicamente se llama el DOM renderizado. Y la tercera es lo que aparece cuando una persona interactúa: cuando abre una pestaña, aprieta "ver más" o baja hasta el final de un listado.

Cada visitante se queda con una de esas versiones. Google indexa la segunda; los crawlers de IA, la primera; y las personas, que sí hacen clic y bajan por la página, ven la tercera. Casi todos los problemas de JavaScript que he encontrado en auditorías vienen de lo mismo: alguien revisó la página en su navegador, la vio completa y dio por hecho que Google veía lo mismo.

En frameworks como Next.js o Nuxt también se habla de hidratación, que a veces se confunde con el renderizado. En la hidratación el servidor ya entregó el HTML completo y el JavaScript solo se "engancha" a esa página para volverla interactiva. Un sitio bien hidratado entrega todo en la primera respuesta, así que en general no tiene problemas de renderizado para SEO.

Tres formas de perder visibilidad cuando un sitio depende de JavaScript

Cuando un sitio depende de JavaScript, la visibilidad se puede perder de tres formas distintas, y cada una se diagnostica y se corrige de manera diferente.

Cuando Google ve demasiado tarde el contenido que carga JavaScript

Google renderiza, pero no al mismo ritmo con que lee HTML. Entre que rastrea una página y termina de renderizarla hay una cola: en la mediana son unos pocos segundos, pero el 10% más lento espera cerca de 3 horas y el 1% más lento, cerca de 18, según la medición de Vercel y MERJ sobre más de 100.000 visitas de Googlebot en 2024. Y cuando es el JavaScript el que crea los enlaces, todo el sitio se descubre más lento: en un experimento de Onely, Googlebot tardó 313 horas en llegar a la última de una cadena de páginas enlazadas con JavaScript, contra 36 horas en la cadena equivalente enlazada en HTML.

Para un blog de veinte artículos, esa demora da lo mismo. El problema aparece cuando el contenido vive poco, y el caso más claro que me ha tocado fue el de un portal de empleo.

Era un sitio con miles de ofertas de trabajo que se publicaban, se editaban y se daban de baja todos los días, y todo su contenido se entregaba desde JavaScript. Cuando Google por fin llegaba a renderizar una oferta, muchas veces esa oferta ya no existía o había cambiado. El tiempo de vida de esas páginas no alcanzaba para que fueran rastreadas, renderizadas, indexadas y posicionadas, así que el SEO funcionaba muy mal, y no por falta de trabajo: el equipo llevaba meses optimizando metadatos y contenido.

La solución no tuvo nada que ver con el contenido. Pasamos el sitio a un renderizado híbrido, en el que el servidor entrega el HTML de cada oferta y el JavaScript queda para la interacción, y el cambio se notó casi de inmediato: el sitio empezó a posicionarse y a generar más sesiones y más leads. El problema había estado todo el tiempo frente a los ojos del equipo, pero escondido en una capa que nadie estaba revisando.

Ese caso resume bien por qué no comparto del todo la idea de que el JavaScript ya no es un problema. El rastreo, la clasificación, la indexación y el ranking ya son procesos lentos, y el renderizado les suma una capa más. Para contenido que dura meses puede no importar; para contenido que dura días, o para precios y stock que cambian varias veces al día, sí importa.

Cuando Google no ve nunca el contenido que depende de un clic o un scroll

La segunda forma es más grave, porque no se resuelve con tiempo. Google ejecuta el JavaScript que corre cuando la página carga, pero no interactúa con ella: no hace clic, no abre pestañas, no completa formularios y no hace scroll como lo haría una persona. Su propia documentación sobre carga diferida lo dice textual: "Google Search does not interact with your page".

La distinción que importa acá no es entre contenido visible y oculto, sino entre contenido que está y contenido que no está. Un texto dentro de una pestaña cerrada o de un acordeón plegado ya está en el DOM cuando carga la página, y el JavaScript solo decide si se muestra; ese texto Google lo indexa sin problema. Pero si la pestaña le pide su contenido al servidor recién cuando alguien hace clic, antes de ese clic el texto no existe en ninguna parte, y como Google nunca hace el clic, indexa la pestaña vacía.

Lo mismo pasa con los botones de "cargar más" que no tienen una URL propia, con los listados de scroll infinito, con las reseñas que se cargan al bajar, con los filtros que cambian el listado sin cambiar la URL y con los menús cuyos enlaces aparecen recién al pasar el mouse. Todo eso funciona perfecto para una persona y queda fuera del índice.

Un caso que me tocó en un sitio del rubro médico muestra otra variante del mismo problema. Un grupo de páginas mostraba su contenido principal dentro de iframes, cargados desde otra fuente, y esas páginas no lograban posicionarse: rendían muy por debajo del resto del sitio, que entregaba su contenido de forma estática. Para Google, el contenido de un iframe pertenece a otra URL, y aunque a veces lo asocia con la página que lo contiene, no es algo con lo que se pueda contar. En la práctica, esas páginas competían casi sin contenido propio.

Cuando los crawlers de IA no ven el contenido que arma JavaScript

La tercera forma de perder visibilidad es la más nueva, y crece rápido. Los crawlers de OpenAI, Anthropic, Perplexity y Meta no pueden ejecutar JavaScript, así que leen el HTML de la primera respuesta del servidor y nada más. Si el contenido se arma en el navegador, para ellos esa página está vacía o a medias.

La consecuencia no es solo aparecer menos en las respuestas de ChatGPT o Perplexity: también se pierde el control sobre los propios datos. Cuando un modelo busca el precio de un producto y no lo encuentra en la página oficial porque se carga con JavaScript, lo saca de otro lado, de un comparador, de un marketplace o de un sitio de reseñas, y cita esa fuente en lugar de la marca. Por eso el precio, las especificaciones y la información de contacto tienen que estar en el HTML como texto visible, y no solo dentro del JSON-LD, que varios sistemas de IA ignoran al leer una página.

Hay una excepción que conviene tener presente. Las funciones de IA de Google, como AI Overviews y el Modo IA, no tienen un crawler propio: trabajan sobre el índice de Google, así que heredan el renderizado de Googlebot, con su demora y sus límites. Y los navegadores con agentes, como Comet o el navegador de ChatGPT, sí ejecutan JavaScript porque son navegadores completos; para ellos el desafío es poder operar la página, que es el tema de la guía de web agéntica y WebMCP.

Cómo auditar el renderizado de JavaScript de un sitio, paso a paso

Esta es la secuencia que sigo cuando audito el renderizado de un sitio. Los primeros pasos toman minutos y ya dicen bastante; los últimos sirven para confirmar y medir a escala. Lo ideal es hacerla con al menos una URL de cada plantilla importante, como la home, una categoría, una ficha de producto o servicio y un artículo de blog, porque el renderizado casi nunca es igual en todo el sitio.

Paso 1: revisar el código fuente y desactivar JavaScript para ver qué depende de él

Lo primero es abrir "Ver código fuente" y buscar con Ctrl+F lo que tiene que estar sí o sí: el H1, el title, la canonical, la meta robots, el primer párrafo del contenido principal, el precio si es una ficha, y los enlaces a categorías o a productos. Si algo de eso no aparece en el código fuente, ese elemento depende de JavaScript.

Después desactivo el JavaScript y recargo la página. En Chrome se hace desde DevTools: se abre el menú de comandos, se escribe "Disable JavaScript" y se recarga; también se puede usar la extensión Web Developer, que lo tiene en su menú "Disable". Lo que desaparece de la pantalla es lo que depende del JavaScript, y en diez segundos queda claro si el sitio entrega su contenido desde el servidor o lo arma en el navegador.

Si la página queda en blanco o con un mensaje del tipo "necesitas activar JavaScript", el sitio se renderiza por completo en el cliente, y ese es el escenario que más cuidado requiere. Igual conviene hacer la prueba incluso en sitios que parecen sanos: en este mismo sitio, el H1 de la portada dependía de JavaScript y tardaba 2,4 segundos en aparecer, sin que nada se viera roto.

Paso 2: comparar el HTML crudo con el renderizado en View Rendered Source

La extensión View Rendered Source muestra lado a lado el HTML que entrega el servidor y el que queda después de ejecutar el JavaScript, con las diferencias marcadas línea por línea. Es la forma más rápida de ver exactamente qué agrega o cambia el JavaScript en una página.

Lo que busco en esas diferencias es bastante concreto. Si el JavaScript agrega o cambia el title, la canonical o la meta robots, hay un problema serio, porque Google recibe una señal en el HTML y otra después del render. Si el JavaScript agrega bloques completos de contenido o de enlaces, esos bloques los ve Google con demora y los crawlers de IA no los ven nunca. Y si solo agrega elementos de interfaz, como el carrito, un chat o un banner, en general no importa.

Hay que tener en cuenta que la extensión renderiza con el navegador de quien la usa, con su sesión, sus cookies y su caché. El renderizador de Google, en cambio, entra sin sesión y sin cookies guardadas, así que si el sitio le muestra cosas distintas a un usuario conectado o a uno que ya aceptó un aviso, lo que ve Google puede no ser lo mismo.

Paso 3: ver cómo renderiza Google una página en la Inspección de URL de Search Console

La Inspección de URL de Search Console es lo más cercano a ver una página como la ve Google. Con "Probar URL publicada" y después "Ver página probada" aparecen tres pestañas: el HTML renderizado, una captura de pantalla y "Más información", donde están los recursos que no se pudieron cargar y los errores de la consola de JavaScript.

En la pestaña HTML busco con Ctrl+F los textos y enlaces que tienen que estar. En "Más información" reviso si hay recursos bloqueados por robots.txt o que no cargaron, porque un archivo JavaScript que Google no puede descargar deja la página a medias. La captura es útil para una mirada rápida, pero solo muestra la parte superior de la página, así que nunca la uso como prueba de que el contenido completo está.

Hay dos errores de lectura muy comunes. El primero es confundir la prueba en vivo con la versión indexada: la prueba muestra lo que Google ve ahora, mientras que "Ver página rastreada" muestra la versión que realmente está usando en los resultados. El segundo es dar por hecho que la prueba en vivo replica exactamente la indexación, cuando usa tiempos de espera distintos y puede cargar más de lo que se carga en el rastreo real.

Para hacer esta revisión más rápido uso Advanced GSC Visualizer, una extensión de Chrome que le agrega funciones a la propia interfaz de Search Console. En la Inspección de URL suma varias vistas: lo que vio Google, la comparación con la página en vivo, la legibilidad del texto para la IA y, la que más uso para renderizado, Render Analysis. Esa vista compara la versión que Google indexó con la página en vivo y calcula qué parte del contenido estaba en la versión indexada y qué parte quedó fuera, además de revisar uno por uno el title, la meta description, la canonical, el H1 y la cantidad de encabezados.

Cuando una página depende de JavaScript, ahí aparece de inmediato: el porcentaje de contenido que falta en la versión indexada sube, y los elementos que no coinciden quedan marcados.

Para revisar un sitio sin tener acceso a su Search Console, como el de un competidor o el de un cliente antes de empezar, la Prueba de resultados enriquecidos de Google muestra el mismo HTML renderizado, la captura y la consola, sin necesidad de tener la propiedad verificada. El paso a paso de la inspección está en la guía de Google Search Console.

Paso 4: rastrear el sitio con y sin JavaScript en Screaming Frog

Los pasos anteriores sirven para una URL a la vez. Para entender cuánto depende del JavaScript un sitio completo, el método que más pistas me da es rastrearlo dos veces en Screaming Frog: una en modo "Text Only", que lee solo el HTML como lo haría un crawler de IA, y otra en modo "JavaScript", que renderiza cada página. Antes del rastreo con renderizado hay que activar "Store HTML" y "Store Rendered HTML" en la configuración de extracción, porque sin eso no se puede comparar después.

Con los dos rastreos listos, la comparación se puede hacer de dos maneras. Una es el modo Compare, que pone los dos rastreos frente a frente y marca qué cambió en cantidad de palabras, títulos, encabezados, canonical, directivas y enlaces internos. La otra es la pestaña JavaScript del rastreo con renderizado, que ya trae filtros para los casos más críticos: noindex o canonical que solo están en uno de los dos HTML, títulos y H1 que aparecen o cambian con el JavaScript, enlaces que solo existen después del render y recursos bloqueados.

Esa comparación resolvió una vez una discusión que llevaba semanas en un retailer grande. El equipo veía los títulos de un grupo de fichas perfectos en el navegador y yo los veía vacíos en el crawl. No era un error de la herramienta ni del equipo: el HTML del servidor llegaba sin ese dato y el JavaScript lo completaba después. Con las dos columnas lado a lado, dejó de ser una opinión contra otra y pasó a ser un hallazgo con evidencia.

El filtro que más uso es "Contains JavaScript Content", que trae el recuento de palabras en el HTML, en el renderizado y el porcentaje que aporta el JavaScript. Ordenando por ese porcentaje aparecen de inmediato las plantillas que más dependen del render. Como referencia, en el estudio que hicimos sobre 103 ecommerce chilenos la tienda típica tenía cerca de un 20% de contenido que solo aparecía con JavaScript, y por encima del 50% ya hablamos de una dependencia alta.

Igual, el porcentaje solo no alcanza para priorizar. Una plantilla con 40% de dependencia en la que todo lo que agrega el JavaScript son reseñas es menos urgente que una con 10% en la que el JavaScript es el que pone el H1 o los enlaces a las categorías. Por eso, después de ordenar, reviso qué elementos son los que cambian. La configuración completa del modo JavaScript está en la guía de Screaming Frog.

Paso 5: buscar el contenido que depende de una interacción y que Google no ve

Ningún rastreador detecta solo el contenido que depende de un clic, porque ninguno hace clic. Esta parte se revisa a mano, y es la que más me ha servido para encontrar problemas que nadie había visto.

Lo que hago es listar los componentes de cada plantilla que esconden contenido: pestañas, acordeones, botones de "ver más" o "cargar más", listados con scroll infinito, reseñas, preguntas frecuentes desplegables, filtros, megamenús y ventanas emergentes. Para cada uno copio un texto que solo se ve después de interactuar y lo busco en el HTML renderizado, el de la Inspección de URL o el de View Rendered Source, sin haber hecho clic. Si el texto está, Google lo puede indexar aunque esté oculto. Si no está, ese contenido no existe para Google.

En los listados hago además una prueba de scroll: anoto cuántos productos o artículos muestra la página al cargar y cuántos aparecen después de bajar hasta el final. Si la diferencia es grande y no hay una paginación con URL propia, todo lo que aparece al bajar depende de que alguien haga scroll, y Google no lo hace.

Paso 6: revisar qué texto lee un crawler de IA en el HTML del servidor

Para ver una página como la ve un crawler de IA basta con pedirla sin ejecutar JavaScript y mirar qué texto trae. Un rastreo "Text Only" en Screaming Frog lo hace a escala, pero para una URL puntual uso la terminal:

curl -s -A "Mozilla/5.0 (compatible; GPTBot/1.3; +https://openai.com/gptbot)" https://www.ejemplo.cl/producto-x \
  | sed -e 's/<script[^>]*>.*<\/script>//g' -e 's/<[^>]*>/ /g' \
  | grep -i -E "precio|\\$ ?[0-9]{1,3}(\.[0-9]{3})+" | head

La pregunta que me hago en este paso es si un sistema que solo lee ese HTML podría responder bien sobre el producto o el servicio: si encuentra el nombre, el precio, las características principales y la información de contacto como texto, y no solo dentro de un bloque de datos estructurados. Si la respuesta es no, ese es el contenido que hay que mover al HTML del servidor.

En sitios con Next.js reviso además que el title y la descripción lleguen en el <head> cuando se pide la página con el user-agent de un bot de IA, porque en las rutas dinámicas el framework puede entregárselos fuera de lugar.

Paso 7: confirmar que Google indexó el contenido que carga JavaScript

El último paso es confirmar que lo que debería estar indexado efectivamente lo está. Para un texto puntual que carga con JavaScript sirve una búsqueda con comillas: site:dominio.cl "frase exacta". Si aparece, Google lo indexó; si no aparece, no es una prueba definitiva, porque el operador site: no es exhaustivo, así que lo confirmo buscando la frase en la versión indexada de la Inspección de URL.

En sitios grandes, los logs del servidor agregan una capa más: muestran si Googlebot de verdad pidió los archivos JavaScript y las APIs que la página necesita para renderizarse, y cuánto tiempo pasó entre el HTML y esos recursos. Antes de sacar conclusiones de los logs hay que verificar con una búsqueda DNS inversa que las peticiones sean realmente de Google, porque muchos bots se hacen pasar por Googlebot.

Los problemas de renderizado de JavaScript más comunes en SEO y cómo se corrigen

La mayoría de los problemas que encuentro en las auditorías se repiten de un sitio a otro, y casi siempre se confirman con las mismas herramientas.

Qué pasa cuando JavaScript cambia el noindex o la canonical de una página

Un error frecuente es que la plantilla nazca con un noindex en el HTML y que el JavaScript lo quite cuando la página tiene contenido suficiente. Parece razonable, pero no funciona: cuando Google encuentra un noindex en el HTML inicial puede saltarse el renderizado, así que nunca llega a ejecutar el JavaScript que lo quita. Con la canonical pasa algo parecido. Google canonicaliza antes y después del render, y si el JavaScript cambia la canonical, recibe dos señales para la misma página y termina eligiendo él. La regla práctica es simple: ni el noindex ni la canonical se manejan con JavaScript, salvo que el valor final sea el mismo que ya trae el HTML.

Esto aparece muy seguido en sitios que publican etiquetas de SEO a través de Google Tag Manager, que es cómodo para el equipo de marketing pero inyecta todo con JavaScript.

Next.js y los metadatos que no llegan en el head a los bots de IA

En Next.js hay un detalle que afecta directamente a los bots de IA. Desde la versión 15, cuando los metadatos de una página se generan en cada petición, el framework los envía en streaming y los agrega al <body> en vez del <head>, salvo para una lista de bots llamada htmlLimitedBots. En esa lista están Googlebot y los bots de redes sociales, pero no GPTBot, ClaudeBot ni PerplexityBot, que reciben la página con los metadatos fuera de lugar.

La lista se puede ampliar en la configuración:

// next.config.js
module.exports = {
  htmlLimitedBots:
    /Googlebot|Bingbot|Applebot|GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|PerplexityBot|facebookexternalhit|LinkedInBot|Twitterbot/i,
};

Solo afecta a las rutas que se renderizan en cada petición. En este sitio, que genera los artículos de forma estática, lo comprobé pidiendo una guía con el user-agent de GPTBot y de ClaudeBot, y el title, la descripción y la canonical llegan en el <head> igual que para Googlebot.

Las páginas HTML de más de 2 MB que Googlebot no procesa completas

Googlebot procesa solo los primeros 2 MB de cada archivo HTML, y lo que queda después no se renderiza ni se indexa. Para una página normal, que suele pesar entre 100 y 300 KB, es un límite lejano. Pero en el ecommerce aparece más de lo que uno pensaría, sobre todo en categorías largas de plataformas que incrustan en el HTML todo el estado de la aplicación como JSON. En el estudio de Milimetrix, 36 de 286 páginas superaban ese tamaño, y en 9 de ellas parte del contenido visible, incluidos los productos del final del listado, quedaba después del corte.

Se revisa fácil: en el panel Network de DevTools se mira el tamaño del documento principal sin comprimir. Si pasa de 2 MB, hay que buscar en qué parte del archivo están el contenido y los enlaces que importan, y si el estado JSON se puede aligerar o mover a un archivo aparte.

Qué revisar del renderizado según la plataforma de ecommerce o el CMS

Algo que se repite mucho en auditorías es que la dependencia de JavaScript no nace de una decisión de arquitectura. Nadie decidió que las fichas iban a cargar el precio en el cliente; venía así en la configuración por defecto, en el tema o en el plugin que alguien instaló hace años. Saber dónde suele estar el problema en cada plataforma ahorra bastante tiempo.

Qué revisar en una tienda sobre VTEX

VTEX Store Framework fue la plataforma más dependiente de JavaScript en nuestro estudio, y tiene sentido: renderiza en el cliente los componentes bajo el pliegue y ofrece opciones para diferir el renderizado de submenús, resultados de búsqueda, filtros y pie de página. La propia documentación de VTEX advierte que, si se difieren los submenús, Google no va a poder rastrear esos enlaces. En una tienda sobre VTEX reviso siempre qué opciones de rendimiento están activas, si el bloque __fold__ deja algo importante bajo el pliegue y si el precio aparece en el texto del HTML o solo en el estado de la aplicación. En un ecommerce sobre VTEX que audité, un rastreo sin renderizado encontraba dos enlaces en un sitio que tenía miles de URL.

En FastStore, la versión de VTEX sobre Next.js, las secciones con carga diferida no van en el HTML inicial, y para el contenido crítico, como el H1 de una categoría, hay que marcarlas con skipLazyLoadingSection: true.

Qué revisar en Shopify: las aplicaciones que agregan contenido

Los temas de Shopify entregan el HTML desde el servidor, así que en Shopify el riesgo casi siempre está en las aplicaciones: reseñas, preguntas frecuentes, recomendaciones de productos y traductores que se insertan con JavaScript. Antes de instalar una aplicación conviene revisar si lo que agrega llega en el HTML o se inserta después, y en una auditoría reviso una por una las que agregan contenido visible a las fichas.

Qué revisar en Salesforce Commerce Cloud y en los storefront headless

En los storefront headless la pregunta clave es qué rutas se renderizan en el servidor y cuáles solo en el cliente, y esa respuesta está en la configuración del build, no mirando el sitio. En el PWA Kit de Salesforce hay un atajo útil: agregar ?__server_only a una URL muestra la versión que entrega el servidor, que es la que lee un crawler sin JavaScript.

Qué revisar en WordPress: plugins de traducción y constructores visuales

En WordPress el riesgo viene de los plugins y de los constructores visuales. Los plugins de traducción que funcionan con JavaScript son el ejemplo más claro: Weglot, por ejemplo, advierte que su integración por JavaScript no tiene beneficio SEO, porque las traducciones se renderizan en el navegador. Los constructores también dejan rastros; Elementor generaba enlaces sin href en sus acordeones hasta la versión 3.14, y un sitio que no ha actualizado puede seguir arrastrándolo.

Qué revisar en Google Tag Manager: las etiquetas de SEO inyectadas

Google Tag Manager merece mención aparte porque es, probablemente, la puerta por la que más SEO se publica sin pasar por desarrollo. Datos estructurados, canonical, meta robots, textos: todo lo que se inyecta por GTM depende de JavaScript. Funciona para Google, con demora, pero no para los crawlers de IA, y en el caso de la canonical y del noindex choca con la forma en que Google procesa esas etiquetas antes del render. Cuando audito un sitio, reviso siempre qué etiquetas de SEO están publicadas en el contenedor.

Qué pedirle al equipo de desarrollo para resolver el renderizado

Una vez que el diagnóstico está claro, lo que más ayuda es traducirlo en pedidos concretos, que el equipo de desarrollo pueda verificar. Estos son los criterios que suelo dejar escritos:

• Que las rutas indexables se rendericen en el servidor o se generen de forma estática. El contenido principal, el H1, el title, la canonical y los enlaces internos tienen que venir en el HTML de la respuesta. El JavaScript queda para la interacción.
• Que el contenido oculto esté en el DOM desde el inicio. Pestañas, acordeones y "ver más" pueden ocultar el texto, pero no pedirlo al servidor recién con el clic.
• Que la paginación tenga URL propias. Un botón de "cargar más" puede seguir existiendo, siempre que también exista un enlace a ?page=2 que funcione sin JavaScript.
• Que todos los enlaces sean <a href>. Nada de navegación con onclick ni componentes sin href.
• Que el noindex y la canonical no dependan de JavaScript.
• Que los datos clave estén como texto visible. Precio, características y contacto, además de en los datos estructurados.
• Que el HTML no pase de 2 MB y que los metadatos vayan al principio del documento.
• Que los archivos tengan nombres con versión y que los de la versión anterior se mantengan disponibles un tiempo después de cada deploy, para que Google no renderice con archivos que ya no existen.
• Que antes de cada deploy se rastree staging sin JavaScript. Es la prueba de aceptación más simple: si el contenido no está en ese rastreo, el cambio no sale.

La objeción más común de desarrollo: que el sitio va a quedar más lento

Cuando se le pide a un equipo de desarrollo que mueva el contenido al HTML que entrega el servidor, la respuesta más frecuente es que el sitio va a quedar más lento. Me pasó con un retail que armaba sus páginas del lado del cliente: el pedido era simple, que el contenido estuviera en el DOM inicial, y la preocupación del equipo era que las páginas iban a cargar más lento.

La discusión, en realidad, no es de velocidad. Lo que está en juego es si un rastreador ve el contenido o no lo ve. Y la idea de que renderizar en el cliente es más rápido tampoco se sostiene del todo, porque lo único que cambia es quién hace el trabajo: en vez del servidor, lo hace el dispositivo de cada usuario, con su procesador y su conexión. Un sitio bien construido sigue siendo rápido con el contenido en el HTML, y uno mal construido sigue siendo lento aunque lo arme el navegador.

Finalmente el equipo hizo el cambio, y los resultados se vieron en el orgánico: Google empezó a indexar productos y páginas nuevas que antes no llegaba a ver, mejoró la rastreabilidad del sitio y el contenido empezó a indexarse y a posicionarse mejor.

Qué estrategia de renderizado de JavaScript conviene según el tipo de sitio

Para la conversación con desarrollo también sirve tener claro qué estrategia de renderizado conviene en cada caso:

El renderizado dinámico, que consiste en servirles a los bots una versión prerenderizada distinta de la que reciben las personas, ya no lo recomiendo. Google dejó de recomendarlo hace años, y tiene un problema práctico que cada vez pesa más: depende de una lista de bots que nunca está completa, así que cualquier crawler de IA nuevo recibe la versión que no sirve.

Cuánto depende de JavaScript el ecommerce chileno

Para tener datos locales, en octubre de 2026 medimos en Milimetrix 103 ecommerce chilenos. En cada tienda comparamos la home, una categoría y una ficha de producto en sus tres versiones: el HTML de la respuesta, la página renderizada y la página después de recorrerla hasta el final. La muestra combina tiendas reconocidas con las que aparecen en el top 10 de Google Chile para 78 búsquedas de compra.

La tienda típica entrega en el HTML el 80% de su contenido visible, lo que de entrada no está mal. El problema está en los extremos: 24 de las 103 tiendas entregan menos de la mitad, y ocho tienen al menos una plantilla sin una sola palabra en el HTML. La plataforma marca bastante la tendencia, porque en VTEX Store Framework la mediana de contenido que aparece solo con JavaScript llega a 41,8%, mientras que en Shopify es de 11,5%.

El dato que más me llamó la atención fue el del precio. En las fichas sobre VTEX Store Framework, el precio aparece como texto en el HTML en apenas 1 de 14; en las otras 13 viaja dentro del estado de la aplicación y de los datos estructurados, que es justo la parte que un crawler de IA suele descartar.

La metodología, el detalle por plataforma y los hallazgos sobre datos estructurados, encabezados y contenido que solo aparece con scroll están en el estudio de renderizado de JavaScript en 103 ecommerce chilenos.

Preguntas frecuentes sobre renderizado de JavaScript y SEO

El renderizado de JavaScript, un problema de SEO que se esconde a simple vista

Lo que más me enseñó el caso del portal de empleo es que los problemas de renderizado casi nunca se ven. La página carga bien, se ve completa en el navegador, y el equipo sigue optimizando contenido y metadatos convencido de que el problema está ahí. Mientras tanto, Google ve el contenido tarde o no lo ve, y los crawlers de IA no lo pueden leer.

Por eso el renderizado es de las primeras cosas que reviso cuando un sitio no rinde como debería, y la revisión inicial no requiere ninguna herramienta cara: abrir el código fuente y desactivar el JavaScript toma diez segundos. Muchas veces, con eso ya aparece la pista que meses de optimización no habían encontrado.

Si el sitio depende de JavaScript y no está claro qué está viendo Google ni qué leen los crawlers de IA, en Milimetrix somos una agencia experta en SEO técnico que audita el renderizado plantilla por plantilla y lo corrige junto al equipo de desarrollo.