Sitio de marketing vs panel SaaS: diferencias de arquitectura, 2026
Un sitio de marketing y un panel SaaS necesitan renderizado, caché y autenticación distintos. Qué cambia y cuándo basta un solo proyecto.
Un sitio de marketing lo leen desconocidos y se juzga por su visibilidad en buscadores y su velocidad. Un panel SaaS lo usan personas con sesión iniciada y se juzga por la frescura de los datos y la seguridad de las sesiones. Un mismo framework puede servir a ambos, pero los valores por defecto de cada uno son distintos, y confundirlos es donde empieza la mayoría de los problemas.
Estas son las diferencias de arquitectura entre un sitio de marketing y una aplicación web que importan en la práctica: renderizado, autenticación y caché, indexación, uno o dos proyectos y quién cambia qué.
Renderizado: estático para el sitio de marketing, mixto para el panel
La estrategia de renderizado es la mayor división arquitectónica. Decide cuándo se genera el HTML, con qué rapidez llega y cuánto cuesta servirlo.
Páginas de marketing: SSG e ISR
Las páginas de marketing cambian poco y dependen de la visibilidad en buscadores y de cargas rápidas. La guía de Vercel para elegir una estrategia de renderizado, publicada el 23 de julio de 2024, favorece la generación estática (SSG) para ellas: ofrece las cargas más rápidas, buen SEO, poca carga de servidor y el menor coste de infraestructura. La contrapartida es que el tiempo de compilación crece con el número de páginas, y cada cambio de contenido exige recompilar y volver a desplegar.
La regeneración estática incremental (ISR) elimina ese inconveniente al actualizar páginas concretas después del lanzamiento. La misma guía recomienda activar la revalidación bajo demanda en lugar de usar un temporizador, porque el contenido suele cambiar por una razón.
El renderizado en el cliente (CSR) encaja mal aquí. El posicionamiento está influido por las Core Web Vitals, y son más difíciles de cumplir cuando el contenido depende de peticiones en el cliente y de paquetes grandes de JavaScript. Fijar presupuestos de rendimiento mantiene a raya ese peso de JavaScript.
Paneles: SSR, ISR y CSR combinados
Los paneles necesitan datos frescos y mucha interactividad, así que suelen combinar estrategias. Según la misma guía de Vercel:
- El renderizado en el servidor (SSR) entrega datos actuales, pero con cargas más lentas, peor tiempo hasta el primer byte y mayor uso del servidor. Almacenar en caché los datos de acceso frecuente, el streaming y React Suspense lo atenúan.
- El CSR funciona bien para filtrar, ordenar y explorar datos, porque el navegador responde sin viajar al servidor. El coste es una primera carga más lenta mientras se descarga el paquete.
- La ISR encaja en secciones que se actualizan con un calendario, como resúmenes diarios, ajustes y páginas de facturación.
Su panel de ejemplo usa SSR para el diseño y los datos en tiempo real, ISR para los widgets de resumen y CSR para las herramientas de exploración interactiva.
Una comparación rápida
| Tipo de página | Renderizado habitual | Por qué |
|---|---|---|
| Inicio, servicios, precios, blog | SSG o ISR | Indexable, cambia poco, la velocidad importa |
| Estructura del panel y datos en vivo | SSR | Necesita datos actuales por usuario |
| Widgets de resumen, facturación, ajustes | ISR o SSR | Se actualiza con un calendario |
| Filtros, gráficos, exploración de datos | CSR | Interactivo, no necesita indexarse |
Autenticación y caché
Un sitio de marketing no tiene sesiones. Un panel se construye alrededor de ellas, y eso cambia cómo se gestionan las peticiones y las cachés.
Dónde se renuevan las sesiones
La guía de autenticación del lado del servidor de Supabase para Next.js expone la restricción central: los Server Components no pueden escribir cookies, así que un token de sesión caducado no se puede renovar durante un renderizado en el servidor. La respuesta de la guía es un proxy, que en versiones anteriores de Next.js era middleware.ts y se renombró en la versión 16. Renueva el token en cada petición y pasa el nuevo tanto a los Server Components como al navegador. Sin él, los usuarios pierden la sesión.
Los tokens de renovación suelen ser de un solo uso, así que renovarlos en dos sitios puede revocar toda la sesión. Los usuarios informan entonces de cierres de sesión aleatorios, difíciles de rastrear. Elige un solo lugar para renovar y mantén la renovación ahí.
Mantén las respuestas autenticadas fuera de las cachés compartidas
La misma guía hace que su ayudante de cookies aplique las cabeceras Cache-Control, Expires y Pragma para que una CDN no almacene una respuesta y filtre la sesión de un usuario a otro. Esa es la regla que conviene trasladar: una estructura estática puede vivir en una CDN, pero ninguna respuesta que establezca o dependa de una cookie de sesión debe compartirse.
El código del servidor también debe verificar los tokens en lugar de fiarse de ellos. La guía advierte de que las cookies se pueden falsificar y indica usar getClaims(), que comprueba la firma del token, en lugar de getSession() en el código del servidor.
SEO y necesidades de indexación
Las dos mitades de un producto tienen necesidades de indexación opuestas. La guía de SEO y renderizado de Next.js enuncia el principio con claridad: los datos y los metadatos de la página deben estar disponibles al cargarla, sin JavaScript. Por eso señala SSG o SSR como las mejores opciones para páginas que necesitan posicionarse, y dice que el CSR no se recomienda para un SEO óptimo.
La misma guía describe el CSR como "perfecto para paneles con muchos datos, páginas de cuenta o cualquier página que no necesites que aparezca en un buscador". Su ejemplo de combinación son entradas de blog como páginas estáticas, un panel de cuenta de cliente renderizado en el cliente y un feed de noticias renderizado en el servidor.
En la práctica, eso significa que el contenido indexable pertenece al lado del marketing. Las rutas del panel no deben formar parte de tu sitemap, y una directiva robots sobre ellas es una protección adicional razonable.
Uno o dos proyectos
Next.js permite elegir el método de renderizado por página, así que un solo proyecto puede contener rutas de marketing estáticas y rutas de aplicación dinámicas. La pregunta es si debería.
La comparación de Next.js y Astro de Vercel, actualizada por última vez el 12 de octubre de 2026, describe la forma habitual de cada lado. Un sitio de marketing es en su mayoría estático, con unas pocas piezas interactivas. Un panel autenticado necesita comprobaciones de inicio de sesión, datos frescos en cada petición y navegación compartida entre muchas rutas. Vercel aloja ambos frameworks y afirma que Next.js recibe una integración más profunda con la plataforma, así que conviene tomar su inclinación hacia Next.js como la opinión de un proveedor.
Dividir tiene contrapartidas claras:
- Un proyecto: sistema de diseño y navegación compartidos, una sola cadena de despliegue y ningún cambio de framework si el sitio evoluciona hacia un producto.
- Dos despliegues: un sitio de marketing más ligero y un código de autenticación aislado, a cambio de una segunda cadena de despliegue y una navegación compartida más difícil.
Las fuentes no resuelven esta elección. Una regla razonable: empieza con un solo proyecto cuando un equipo pequeño se encarga de ambos, y divide cuando el riesgo de publicación del panel o su superficie de autenticación empiece a frenar los cambios de marketing.
Cadencia de publicación y responsabilidades
Las páginas de marketing se editan a menudo, por personas que no son ingenieras, y corregir una errata no debería esperar a una batería de pruebas de regresión. Los cambios del panel afectan a datos y permisos, y deben publicarse con pruebas y revisión. Esa diferencia de cadencia suele importar más que cualquier característica del framework. Si los editores son dueños del contenido, consulta cómo elegir un CMS para un sitio de marketing en Next.js.
Conclusión
Asigna a cada ruta lo que necesita en frescura, interactividad e indexación. Estático o ISR para todo lo que deban encontrar los desconocidos, renderizado en servidor o en cliente tras sesiones verificadas para todo lo que requiera iniciar sesión, y ninguna caché compartida para respuestas personalizadas. Que todo viva en un repositorio o en dos es una decisión de equipo, no técnica. Si lo estás valorando para una obra real, Kallos Labs cubre ambos lados en su trabajo de desarrollo web.
Preguntas frecuentes
¿Pueden un sitio de marketing y un panel SaaS vivir en un mismo código?
Sí. Next.js permite elegir el método de renderizado por página, así que las rutas de marketing pueden ser estáticas mientras las del panel se renderizan por petición o en el navegador. Separarlos en dos despliegues también es habitual, y las fuentes no zanjan la cuestión, así que decide según el tamaño del equipo y la cadencia de publicación.
¿Debe un panel SaaS indexarse en los buscadores?
Normalmente no. La guía de Next.js describe el renderizado en el cliente como adecuado para paneles con muchos datos y páginas de cuenta que no necesitas en un índice de búsqueda. Mantén el contenido indexable en el lado del marketing.
¿Por qué el renderizado en el cliente encaja mal en un sitio de marketing?
El contenido que depende de peticiones en el cliente y de paquetes grandes de JavaScript dificulta cumplir las Core Web Vitals. El principio clave del SEO es que los datos y los metadatos de la página estén disponibles al cargarla, sin JavaScript.
¿Puede una CDN almacenar en caché las páginas del panel?
Solo la estructura estática. Las respuestas que establecen o dependen de cookies de sesión no deben almacenarse en caché de forma pública, o la sesión de un usuario puede filtrarse a otro. La documentación de Supabase hace que su ayudante de autenticación aplique las cabeceras Cache-Control, Expires y Pragma por este motivo.