¿Qué es el renderizado de JavaScript y cómo afecta al SEO?

Una página de tienda rara vez llega terminada. El servidor envía un HTML y unos archivos de JavaScript, y el navegador ejecuta esos scripts para completar lo que falta: el selector de variantes, las estrellas de las reseñas, a veces la ficha entera. Ese paso es el renderizado de JavaScript, y la búsqueda «JavaScript SEO» existe porque un buscador no es tu navegador: decide si ejecuta tus scripts, cuándo y con qué límites. Para una tienda la pregunta útil es concreta: qué datos de tu ficha de producto dependen de ese paso, y quién se los pierde.

Cómo funciona

La guía de web.dev sobre renderizado, de Addy Osmani y Jason Miller, da el vocabulario. El renderizado en el cliente es renderizar una aplicación en el navegador, usando JavaScript para modificar el DOM. La hidratación es ejecutar scripts en el cliente para añadir estado e interactividad a un HTML que ya llegó renderizado desde el servidor. El prerrenderizado es ejecutar la aplicación en el momento de compilar el sitio para guardar su estado inicial como HTML estático.⁠^{[1]web.dev (Addy Osmani y Jason Miller). Rendering on the Web} En los tres casos hay JavaScript que se ejecuta; lo que cambia es si el contenido esencial depende de esa ejecución o ya venía escrito.

Google procesa las páginas con JavaScript en tres fases: rastreo, renderizado e indexación. Antes de pedir una URL, Googlebot comprueba en robots.txt que puede rastrearla. Después pone la página en una cola de renderizado, donde puede pasar unos segundos o bastante más. Cuando sus recursos lo permiten, un Chromium sin interfaz renderiza la página y ejecuta el JavaScript, y Google usa ese HTML renderizado para extraer enlaces y para indexar la página.⁠^{[2]Google Search Central. Understand JavaScript SEO basics} Por eso un dato que solo aparece tras el renderizado acaba en el índice más tarde que uno que viaja en el HTML inicial, y solo si nada se rompe por el camino.

En diciembre de 2025 Google añadió a su documentación tres aclaraciones que afectan a cualquier tienda.⁠^{[3]Google Search Central. Latest documentation updates}

• Códigos de estado. Si la página responde con un código distinto de 200, por ejemplo un 404, puede que el renderizado se omita.⁠^{[2]Google Search Central. Understand JavaScript SEO basics}
• noindex. Si Google encuentra un noindex en el HTML original, puede saltarse el renderizado y la ejecución del JavaScript, así que quitarlo después con un script no sirve de garantía.⁠^{[2]Google Search Central. Understand JavaScript SEO basics}
• La URL canonical. Lo mejor es declararla en el HTML; si JavaScript la toca, tiene que dejarla con el mismo valor que el HTML original, nunca cambiarla por otra.⁠^{[2]Google Search Central. Understand JavaScript SEO basics}

El renderizador de Google tampoco se comporta como una persona navegando. Rechaza las peticiones de permisos, como la cámara o la ubicación; borra el almacenamiento local, el de sesión y las cookies entre una carga y la siguiente; guarda en caché de forma agresiva y puede ignorar las cabeceras de caché; y no admite conexiones como WebSockets o WebRTC.⁠^{[4]Google Search Central. Fix Search-related JavaScript problems} Solo descubre los enlaces que son elementos <a> con un atributo href, y para la navegación en el cliente pide usar la API History en lugar de fragmentos con #.⁠^{[2]Google Search Central. Understand JavaScript SEO basics}

Los bots que no renderizan

Google lo dice en su propia guía: el renderizado en el servidor o el prerrenderizado siguen siendo una gran idea, porque hacen la web más rápida y porque no todos los bots pueden ejecutar JavaScript.⁠^{[2]Google Search Central. Understand JavaScript SEO basics} Vercel puso cifras a esa frase. En un análisis del tráfico de su red con la consultora MERJ, publicado el 17 de diciembre de 2024, ninguno de los grandes rastreadores de IA renderizaba JavaScript, entre ellos los de OpenAI, Anthropic, Meta, ByteDance y Perplexity. Sí descargaban los archivos: los de JavaScript eran el 11,50 % de las peticiones del rastreador de ChatGPT y el 23,84 % de las de Claude, pero los trataban como texto, sin ejecutarlos. Las excepciones eran Gemini, que usa la infraestructura de Google, y AppleBot.⁠^{[5]Vercel, con MERJ. The rise of the AI crawler}

Su recomendación fue renderizar en el servidor el contenido principal (artículos, información de producto, documentación), la metainformación (títulos, descripciones, categorías) y la estructura de navegación, y dejar el renderizado en el cliente para lo accesorio, como un contador de visitas o un chat.⁠^{[5]Vercel, con MERJ. The rise of the AI crawler} Lee el dato con su fecha: es una medición de una empresa sobre su red, de finales de 2024, y los rastreadores cambian.

En una tienda

Ejemplo ficticio. Una tienda Shopify vende una lámpara de mesa. Su tema escribe el nombre, el precio y la descripción con Liquid, y una aplicación de reseñas añade las estrellas y su marcado AggregateRating desde el navegador. En la primera respuesta del servidor, la parte de las reseñas es solo esto:

<div id="resenas" data-producto="8123"></div>
<script src="https://resenas.example/widget.js" defer></script>

Las estrellas y el JSON-LD de la valoración existen, pero solo después de que alguien ejecute widget.js. Así queda cada dato según quién lea la ficha:

Shopify recomienda justo esa división: pintar el contenido inicial con Liquid y HTML en lugar de con frameworks de JavaScript en el navegador, y añadir la interactividad encima, de modo que el HTML inicial funcione sin JavaScript.⁠^{[6]Shopify.dev. Render essential content server-side} Eso es renderizado del lado del servidor, y es lo que hace que los datos que publica el tema, o un app embed de Shopify escrito en Liquid, viajen en la primera respuesta.

Cómo comprobarlo

1. Mira lo que renderizó Google. En la inspección de URLs de Search Console, prueba la URL publicada y abre la página probada: verás el HTML renderizado, los recursos cargados y los mensajes y excepciones de la consola de JavaScript.⁠^{[4]Google Search Central. Fix Search-related JavaScript problems} Si un recurso necesario no se cargó, empieza por ahí.
2. Compáralo con el HTML inicial. Abre el código fuente de la ficha (no el inspector) o descárgala desde la terminal con curl. Lo que está en el renderizado y no en el código fuente depende de JavaScript.
3. Revisa el código de estado de las páginas vacías. Un producto retirado que muestra «no encontrado» con JavaScript pero responde con un 200 es un soft 404. Google propone una redirección con JavaScript a una URL que responda con un 404, o añadir un noindex con la etiqueta robots.⁠^{[2]Google Search Central. Understand JavaScript SEO basics}⁠^{[4]Google Search Central. Fix Search-related JavaScript problems}
4. Comprueba los enlaces del menú, los filtros y la paginación. Tienen que ser elementos <a> con href, no botones que cambian la página con un script, y no deben depender de fragmentos con #.⁠^{[2]Google Search Central. Understand JavaScript SEO basics}
5. Pregunta qué hace cada aplicación. Por cada aplicación instalada que añada contenido a la ficha, averigua si lo escribe en el HTML del tema o lo inyecta desde el navegador.

Concepto cercano: renderizado del lado del servidor

Los dos términos se confunden porque hablan de lo mismo desde lados opuestos. El renderizado de JavaScript es el paso en el que se ejecutan los scripts para obtener el contenido final; el renderizado del lado del servidor es una técnica que construye el HTML completo antes de enviarlo, para que ese paso no haga falta para leer lo esencial. Con hidratación conviven: el contenido llega escrito y JavaScript solo añade la interactividad.⁠^{[1]web.dev (Addy Osmani y Jason Miller). Rendering on the Web} Una tienda headless puede usar cualquiera de los dos enfoques, y por eso conviene preguntar cuál antes de dar por hecho que sus fichas se leen.

Para seguir, la guía de lo que ve un rastreador de IA en tu tienda lo comprueba paso a paso, y la ruta de lectura de publicación por plataforma ordena el resto de términos.