¿Qué es el SSR (renderizado del lado del servidor)?

Cuando alguien, o algo, pide la página de un producto, la tienda responde con un documento HTML. La pregunta que decide este término es qué lleva ese primer documento: el nombre, el precio y los datos del producto ya escritos, o una página casi vacía y un archivo de JavaScript que los monta después en el navegador. Aquí SSR no es la rareza «SSR» de los juegos gacha: es server-side rendering, el renderizado en el servidor. Te importa porque no todos los que leen tu tienda ejecutan JavaScript, y lo que no está en la primera respuesta puede no llegar a leerlo nadie más que una persona con un navegador.

Cómo funciona

La guía de referencia de web.dev, escrita por Addy Osmani y Jason Miller y actualizada el 5 de enero de 2026, distingue estas formas de producir una página:⁠^{[1]web.dev (Addy Osmani y Jason Miller). Rendering on the Web}

Web.dev define el SSR como renderizar una aplicación en el servidor para enviar HTML, en lugar de JavaScript, al cliente, y el renderizado en el cliente como renderizarla en el navegador, usando JavaScript para modificar el DOM.⁠^{[1]web.dev (Addy Osmani y Jason Miller). Rendering on the Web} La diferencia práctica está en la primera respuesta: con SSR, quien la descarga ya tiene el contenido; con renderizado en el cliente, tiene que ejecutar el JavaScript para verlo.

Google sí ejecuta JavaScript, pero en una segunda fase. Procesa las páginas en tres pasos: rastreo, renderizado e indexación. Googlebot pone en cola de renderizado las páginas que responden con un código 200, y una página puede pasar en esa cola unos segundos o más tiempo. Aun así, la documentación de Google dice que el renderizado en el servidor o el prerrenderizado siguen siendo una gran idea, porque hacen la web más rápida para usuarios y rastreadores, y porque no todos los bots pueden ejecutar JavaScript.⁠^{[2]Google Search Central. Understand JavaScript SEO basics}

Durante años, una salida fue el renderizado dinámico: servir a los bots una versión ya renderizada y a las personas la de siempre. Google lo describe hoy como una solución provisional que no recomienda, porque añade complejidad y consume recursos, y propone en su lugar el renderizado en el servidor, el renderizado estático o la hidratación.⁠^{[3]Google Search Central. Dynamic rendering as a workaround}

Los rastreadores de IA y el HTML inicial

La parte de «no todos los bots» se ha vuelto concreta con los rastreadores de las empresas de IA. Vercel, con la consultora MERJ, analizó durante varios meses el tráfico de su red y de nextjs.org, y publicó el 17 de diciembre de 2024 que ninguno de los grandes rastreadores de IA renderizaba JavaScript: entre ellos, los de OpenAI (OAI-SearchBot, ChatGPT-User y GPTBot) y el de Anthropic (ClaudeBot). Descargaban archivos de JavaScript, pero no los ejecutaban. Las excepciones que señalaba eran Gemini, que usa la infraestructura de Googlebot, y AppleBot, que renderiza con un navegador.⁠^{[4]Vercel, con MERJ. The rise of the AI crawler}

Lee ese dato con su fecha y su alcance: es una medición de una empresa sobre su propia red, de finales de 2024, y los rastreadores cambian. Lo que no cambia es la conclusión práctica, que coincide con la de Google: si un dato tiene que leerlo cualquier rastreador, tiene que estar en el HTML inicial.

En una tienda

Ejemplo ficticio. La misma ficha de una mochila, servida de dos maneras. Con renderizado en el cliente, la primera respuesta de la tienda es esto:

<body>
  <div id="app"></div>
  <script src="/assets/tienda.js"></script>
</body>

El nombre, el precio y los datos estructurados existen, pero dentro de tienda.js, y solo aparecen cuando alguien lo ejecuta. Con renderizado en el servidor, la primera respuesta ya los trae:

<body>
  <h1>Mochila de senderismo 30 l</h1>
  <p class="precio">89,00 €</p>
  <script type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "Product",
      "name": "Mochila de senderismo 30 l"
    }
  </script>
</body>

En Shopify, los temas se escriben en Liquid, que se resuelve en el servidor, y Shopify recomienda pintar así el contenido esencial, con Liquid y HTML, en lugar de con frameworks de JavaScript en el navegador: el HTML inicial funciona sin JavaScript.⁠^{[5]Shopify.dev. Render essential content server-side} Por eso un dato guardado en metafields y pintado por el tema llega en la primera respuesta. Clione publica sus datos estructurados por las vías nativas de cada plataforma, renderizados en el servidor: un widget de BigCommerce en BigCommerce, y metafields con un app embed de Shopify en Shopify, sin inyectarlos con JavaScript en el navegador.

Cómo comprobarlo

1. Abre la ficha y mira el código fuente (en la mayoría de navegadores, Ctrl+U o Cmd+Opción+U). Eso es la respuesta inicial. Busca el nombre del producto, el precio y application/ld+json.
2. Compáralo con el inspector. Lo que aparece en el inspector y no en el código fuente lo ha añadido JavaScript después.
3. Descárgala desde la terminal, sin navegador: curl -s https://tu-tienda.example/products/mochila | grep "ld+json". Si no devuelve nada, los datos estructurados no van en el HTML inicial.
4. Desactiva JavaScript en el navegador y recarga la ficha. Lo que desaparece depende de JavaScript para mostrarse.
5. Mira lo que renderizó Google. La herramienta de inspección de URLs de Search Console y la que Google ofrece para comprobar los resultados enriquecidos, la prueba de resultados enriquecidos, muestran el HTML renderizado.⁠^{[2]Google Search Central. Understand JavaScript SEO basics} Recuerda que eso es lo que ve Google después de ejecutar JavaScript, no lo que ve un bot que no lo ejecuta.

Concepto cercano: renderizado de JavaScript

El renderizado de JavaScript es el paso en el que un navegador, o un rastreador como Googlebot, ejecuta los scripts de una página para obtener su contenido final. El SSR busca que ese paso no sea necesario para leer lo esencial: el contenido ya llega escrito, y JavaScript solo añade interactividad encima, como en la hidratación.⁠^{[1]web.dev (Addy Osmani y Jason Miller). Rendering on the Web} Una tienda headless puede usar cualquiera de las dos técnicas, y por eso conviene preguntar cuál usa antes de dar por hecho que sus fichas se leen.

Para seguir, la ruta de lectura de publicación por plataforma explica cómo llega cada dato a la tienda en Shopify y en BigCommerce.