Web estática, SSR o CMS: qué elegir para un pequeño negocio (mi caso real)

Cuando un negocio me pide una web, antes incluso del diseño hay una decisión que pesa durante años: web estática, renderizado en servidor (SSR) o CMS. En lugar de explicarla en abstracto, la cuento con el proyecto que mejor conozco: esta web.

Las tres opciones en dos líneas

• Web estática: las páginas son archivos HTML ya listos, generados una vez y subidos a un hosting. Rapidísima, barata, muy difícil de atacar. Pero cada cambio requiere una nueva publicación.
• SSR (server-side rendering): un servidor genera la página en cada petición, con datos siempre actualizados. Flexible y excelente para el SEO, pero necesita un servidor siempre encendido y alguien que lo mantenga.
• CMS (WordPress o un CMS headless): el propietario edita textos y artículos desde un panel, sin desarrollador. Cómodo, pero conlleva actualizaciones, plugins y una superficie de ataque que cuidar.

Mi caso: una web Angular publicada como estática

Esta web es una aplicación Angular con SSR configurado, un backend NestJS separado con MongoDB y un blog en siete idiomas cuyos artículos viven en la base de datos. Sobre el papel es el caso perfecto para el SSR. En la práctica, por coste y sencillez, el frontend se compila y se publica como archivos estáticos en un hosting Plesk, mientras que el backend funciona en un servicio aparte.

Funciona, pero descubrí por las malas lo que implica esa decisión.

1. Sin servidor, el SSR no existe

Con un despliegue estático, el renderizado en servidor nunca se ejecuta: si una página no se genera durante la build, Google solo recibe el "cascarón" vacío de la aplicación. Cuando me di cuenta, de las 32 URLs del sitemap Google había indexado 4, y ningún artículo: conté toda la investigación en este artículo. La solución fue el prerendering: generar en la build el HTML de cada página, artículo por artículo e idioma por idioma.

2. Cientos de páginas que generar en cada build

Cada artículo existe en siete idiomas, así que las páginas que prerenderizar son cientos. Las primeras builds consultaban la API de producción para cada una: saltaba el límite de peticiones y algunas páginas se generaban con el mensaje "artículo no encontrado". Lo resolví descargando todos los artículos una sola vez antes de la build, en un archivo de caché del que lee el prerendering:

// Before the build: download every published post once
const posts = await fetchAllPublishedPosts();
fs.writeFileSync('.prerender-cache/blog-posts.json', JSON.stringify({ posts }));
// The prerender reads this file instead of calling the API hundreds of times

3. Cada artículo nuevo requiere una nueva publicación

Es el compromiso más evidente: cuando publico un artículo desde el panel, el contenido está disponible al instante a través de la API, pero la página HTML que lee Google solo existe tras la siguiente build y la subida de los archivos. Para un blog que se actualiza de vez en cuando es aceptable; para una web de noticias, no.

4. Los detalles del hosting importan

Incluso con las páginas generadas, Apache respondía con una redirección 301 en cada una: cada página prerenderizada es una carpeta con un index.html dentro, y el servidor añadía la barra final a la URL. La solución fueron unas pocas líneas en el .htaccess, pero sin comprobarlo con curl -I nunca me habría dado cuenta:

<IfModule mod_dir.c>
  DirectorySlash Off
</IfModule>

Precisamente por estos compromisos estoy preparando el paso a un contenedor Node en Plesk, con SSR de verdad: la complejidad ya estaba en el proyecto, así que mejor aprovecharla hasta el final.

Qué recomiendo a un pequeño negocio

Mi web no es un caso típico: también es un laboratorio. Para un negocio real, la elección depende casi siempre de tres preguntas: con qué frecuencia cambian los contenidos, quién los actualiza y cuántas páginas hacen falta.

Para muchos negocios locales, horarios, reseñas e indicaciones importan más que la propia web: un Perfil de Empresa en Google bien cuidado vale a menudo más que una funcionalidad extra.

Las preguntas que hay que hacerse antes de elegir

1. ¿Quién actualizará los contenidos y con qué frecuencia? Si la respuesta es "el propietario, cada semana", hace falta un panel.
2. ¿Cuánto importa Google? Si la web vive de búsquedas orgánicas, cada página debe llegar al rastreador como HTML completo: estática o SSR, nunca una single page app sin prerendering.
3. ¿Quién mantendrá el servidor? Un SSR o un CMS sin actualizaciones envejece mal; una web estática puede quedarse quieta durante años.
4. ¿Cuánto puede crecer? Empezar en estático y pasar a SSR es posible, siempre que se elija una arquitectura que lo permita, como me pasó a mí con Angular.

Los errores que veo más a menudo

• Un CMS pesado para cinco páginas que nunca cambian: plugins que actualizar y riesgos de seguridad sin ninguna ventaja.
• Una single page app sin prerendering para una web que necesita que la encuentren: agradable de usar, invisible para los buscadores.
• Elegir SSR sin presupuesto para mantenerlo: un servidor hay que monitorizarlo, actualizarlo y pagarlo cada mes.

En resumen

No existe la mejor tecnología en absoluto: existe la que encaja con cómo se actualizan los contenidos y con quién los gestiona. Para la mayoría de los pequeños negocios, una web estática bien hecha es la opción más sólida; un CMS tiene sentido cuando el propietario quiere autonomía; el SSR sirve cuando los contenidos son muchos y cambian a menudo. Mi web me enseñó que cada elección tiene un coste oculto: lo importante es conocerlo antes. Si estás valorando un proyecto, escríbeme y partimos de estas preguntas.