SSR, SSG o SPA: cómo elegir la arquitectura de tu web sin equivocarte

Qué son SSR, SSG y SPA (sin tecnicismos)

Las tres siglas hablan de lo mismo: en qué momento y en qué sitio se construye el HTML que ve tu visitante. Ese detalle, que parece de programadores, es el que decide si tu web tarda medio segundo o cuatro en mostrar algo, y si Google entiende tu contenido a la primera o se queda mirando una página en blanco.

SPA (Single Page Application): todo se monta en el navegador

El servidor envía un HTML prácticamente vacío y un paquete de JavaScript. Es el navegador del usuario el que, ya con la web abierta, pide los datos y pinta el contenido. A partir de ahí la navegación es instantánea porque no se recarga la página entera, solo cambia lo que hace falta. El precio es la primera visita: hasta que ese JavaScript no se descarga y se ejecuta, ahí no hay nada que ver ni que leer.

SSR (Server-Side Rendering): el servidor monta el HTML en cada visita

Cuando alguien pide una página, el servidor la genera al momento con los datos actualizados y la envía ya montada. El visitante ve contenido real desde el primer instante y Google también. A cambio necesitas un servidor que ejecute ese trabajo en cada petición: más infraestructura, más mantenimiento y algo más de coste.

SSG (Static Site Generation): las páginas se generan una vez, antes de publicar

Aquí el HTML se construye una sola vez, durante el despliegue, y queda guardado como ficheros estáticos. Cuando un usuario entra, el servidor solo tiene que entregar un fichero que ya existía. Es lo más rápido, lo más barato de alojar y lo más difícil de tumbar. El límite es obvio: si el contenido cambia, hay que volver a generar las páginas.

SSR, SSG o SPA: tabla comparativa

Puesto uno al lado del otro se ve mucho más claro dónde gana cada modelo:

Ninguna columna es la buena en abstracto. La pregunta correcta no es cuál es mejor, sino cuál encaja con la frecuencia con la que cambia tu contenido y con lo que te juegas en Google.

Cómo afecta al SEO elegir SSR, SSG o SPA

Google es capaz de ejecutar JavaScript y rastrear una SPA, pero lo hace en una segunda pasada y con menos prioridad. En una web pequeña puede que no lo notes. En un catálogo de trescientas referencias, esa segunda pasada se traduce en páginas que tardan semanas en indexarse o que directamente se quedan fuera.

Los puntos donde más se nota la diferencia son estos:

• Indexación: con SSR y SSG el HTML ya viene con el texto, los enlaces y las metaetiquetas. No hay nada que esperar.
• Metadatos por página: en una SPA mal montada todas las URLs acaban compartiendo el mismo title y la misma meta description, y eso es un problema serio.
• Datos estructurados: el JSON-LD debe llegar en el HTML del servidor. Si se inyecta por JavaScript, te arriesgas a que no se lea y a perder los resultados enriquecidos.
• Enlaces internos: si tus enlaces se generan por JavaScript y no son etiquetas <a> reales con href, el rastreador no los sigue y tu arquitectura interna se rompe.
• Compartir en redes: las previsualizaciones de WhatsApp, LinkedIn o Facebook no ejecutan JavaScript. Si el contenido no está en el HTML, se comparte una tarjeta vacía.

La regla práctica es sencilla: todo lo que quieras que posicione debería llegar renderizado desde el servidor. Lo que vive detrás de un login puede ser una SPA sin ningún problema, porque Google no va a entrar ahí de todos modos.

Velocidad y Core Web Vitals: qué cambia en cada caso

Las métricas que Google mide como experiencia de usuario reaccionan de forma muy distinta según el modelo que elijas:

• LCP (cuánto tarda en aparecer el elemento principal): SSG gana casi siempre, porque el HTML ya está hecho. La SPA es la que más sufre, porque el contenido principal no existe hasta que el JavaScript termina.
• INP (cómo de rápido responde la web a un clic): aquí la SPA puede ir muy bien una vez cargada, pero solo si el paquete de JavaScript no es enorme.
• CLS (cuánto se mueven las cosas mientras carga): los saltos de maquetación son típicos de webs que pintan contenido en cliente sin reservar el espacio antes.

Ojo con una trampa habitual: el SSR entrega el HTML rápido, pero si después envías medio megabyte de JavaScript para hidratar la página, el usuario ve la web antes de poder usarla. Es un fallo muy frecuente y arruina buena parte de la ventaja. Si quieres profundizar en cómo se miden estas métricas y cómo mejorarlas, lo desarrollamos en nuestra guía sobre Core Web Vitals.

Qué arquitectura elegir según tu tipo de negocio

Web corporativa o de servicios de una pyme

SSG, casi sin dudarlo. Diez o treinta páginas que cambian tres veces al año no necesitan un servidor renderizando en cada visita. Tendrás la web más rápida posible, un hosting barato y muy poco que se pueda romper. Es lo que recomendamos a la mayoría de negocios de Yecla y el Altiplano que nos piden una web de presencia y captación.

Tienda online

SSR o un modelo híbrido. El stock, los precios y las promociones cambian a diario, y las fichas de producto son justo las páginas que tienen que posicionar. Muchas tiendas funcionan muy bien generando de forma estática las categorías y las páginas de contenido, y dejando en SSR solo lo que depende de datos en tiempo real.

Blog, revista o portal de contenidos

SSG con regeneración. Publicas, se regeneran las páginas afectadas y el resto del sitio sigue servido como ficheros estáticos. Es el modelo que mejor aguanta un pico de tráfico si un artículo se te dispara.

Panel de cliente, intranet o herramienta interna

SPA sin complejos. Nadie tiene que encontrarte por Google dentro de un área privada, así que todas las pegas de SEO desaparecen y te quedas con lo bueno: una interfaz fluida, sin recargas, que se siente como una aplicación de escritorio.

Catálogo B2B o web con área pública y área privada

Híbrido. La parte pública en SSR o SSG para que Google la rastree y la indexe, y el área de cliente como SPA. Es el escenario más habitual en fabricantes y distribuidores, y hoy no supone montar dos proyectos distintos: se resuelve dentro del mismo framework.

Errores frecuentes al elegir la arquitectura

1. Elegir SPA por defecto porque el equipo de desarrollo está cómodo con ella, sin preguntarse si esa web depende del tráfico orgánico.
2. Montar SSR sin necesidad real: pagas más servidor y añades complejidad para servir un contenido que no cambia nunca.
3. Confiar en que Google ya renderiza JavaScript y descubrir seis meses después que media web no está indexada.
4. Olvidar que Bing, las redes sociales y los buscadores con IA no rastrean como Google. Si el contenido no está en el HTML, para ellos no existe.
5. Decidir la arquitectura al final del proyecto. Cambiarla después es prácticamente rehacer la web.
6. Ignorar el coste operativo: un SSR mal dimensionado se cae justo el día que te llega tráfico de verdad.

Cómo decidir en cinco preguntas

Si no quieres entrar en detalles técnicos, respóndete a esto y tendrás la decisión tomada:

1. ¿Necesitas que estas páginas aparezcan en Google? Si la respuesta es no, la SPA es perfectamente válida.
2. ¿Cada cuánto cambia el contenido? Si es cuestión de semanas o meses, SSG. Si cambia varias veces al día, SSR.
3. ¿Cuántas páginas tienes? Con miles de URLs que se generan solas, regenerar todo el sitio en cada cambio deja de ser práctico y el SSR gana.
4. ¿El contenido es distinto para cada usuario? Precios personalizados, stock por cliente o áreas privadas empujan hacia SSR o SPA.
5. ¿Quién va a mantener esto dentro de dos años? Una arquitectura sencilla que tu equipo entiende vale más que una elegante que nadie sabe tocar.