# Qué es SSR (renderizado del lado del servidor)
> Qué es el SSR o renderizado del lado del servidor, en qué se diferencia del renderizado en el navegador y por qué decide qué leen Google y los bots de IA.
URL: https://clione.ai/es/glosario/ssr/
Lang: es
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:[^webdev-rendering]
| Técnica | Dónde se construye el HTML | Qué trae la primera respuesta |
| -------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------ |
| Renderizado en el servidor (SSR) | En el servidor, en cada petición | El HTML con el contenido |
| Renderizado en el cliente | En el navegador, con JavaScript que modifica el DOM | Una página casi vacía y los scripts |
| Renderizado estático | En el momento de compilar el sitio, un archivo por URL | El HTML con el contenido, preparado de antemano |
| Hidratación | En el servidor, y luego JavaScript añade estado e interactividad | El HTML con el contenido, que después cobra vida |
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.[^webdev-rendering] 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](/es/glosario/indexacion/). [Googlebot](/es/glosario/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.[^google-js-seo]
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**.[^google-dynamic-rendering]
## Los rastreadores de IA y el HTML inicial
La parte de «no todos los bots» se ha vuelto concreta con los [rastreadores](/es/glosario/rastreador/) 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](/es/glosario/oai-searchbot/), [ChatGPT-User](/es/glosario/chatgpt-user/) y [GPTBot](/es/glosario/gptbot/)) y el de Anthropic ([ClaudeBot](/es/glosario/claudebot/)). Descargaban archivos de JavaScript, pero no los ejecutaban. Las excepciones que señalaba eran [Gemini](/es/glosario/gemini/), que usa la infraestructura de Googlebot, y AppleBot, que renderiza con un navegador.[^vercel-ai-crawlers]
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](/es/glosario/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:
```html
```
El nombre, el precio y los [datos estructurados](/es/glosario/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:
```html
Mochila de senderismo 30 l
89,00 €
```
En Shopify, los temas se escriben en [Liquid](/es/glosario/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.[^shopify-render-server] Por eso un dato guardado en [metafields](/es/glosario/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](/es/glosario/widget-bigcommerce/) en BigCommerce, y metafields con un [app embed de Shopify](/es/glosario/app-embed-shopify/) en Shopify, sin inyectarlos con JavaScript en el navegador.
El inspector del navegador no enseña el HTML inicial. Muestra el DOM, es decir, la página después de que JavaScript la haya modificado, así que ver ahí el precio o el [JSON-LD](/es/glosario/json-ld/) no prueba que estén en la primera respuesta.[^webdev-rendering] Para eso está el código fuente de la página.
## 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](/es/glosario/search-console/) y la que Google ofrece para comprobar los [resultados enriquecidos](/es/glosario/resultados-enriquecidos/), la [prueba de resultados enriquecidos](/es/glosario/prueba-de-resultados-enriquecidos/), muestran el HTML renderizado.[^google-js-seo] 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/glosario/renderizado-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.[^webdev-rendering] Una tienda [_headless_](/es/glosario/headless-commerce/) 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](/es/aprender/publicacion-por-plataforma/) explica cómo llega cada dato a la tienda en Shopify y en BigCommerce.