Publicado el
9 MIN DE LECTURA
Sitio web para SaaS: cómo estructurar el sitio del producto
Por:
Un sitio web para SaaS no es una landing page. Es un conjunto de páginas que necesita vender, explicar y sostener el producto al mismo tiempo: home, funcionalidades, precios, casos, documentación y registro de cambios. La landing resuelve una campaña. El sitio del producto resuelve el ciclo completo de compra.
Esa distinción casi no aparece en portugués. Busca el tema y la búsqueda devuelve plantillas de landing page o contenido sobre cómo construir el software, que son dos cosas distintas de esta. Este artículo trata la tercera: la estructura de páginas que necesita un producto vendido por suscripción, y lo que cambia en cada una a medida que el producto madura.
¿Qué es un sitio web para SaaS y por qué no es una landing page?
Una landing page existe para una única decisión, casi siempre proveniente de una campaña pagada. Tiene un argumento, una prueba y un botón. Funciona muy bien para lo que fue hecha y falla cuando alguien llega con otra pregunta.
El sitio de un SaaS recibe públicos en etapas distintas en la misma semana. Alguien que nunca oyó hablar del producto, alguien comparando tres opciones, alguien que ya es cliente buscando documentación y alguien del equipo de compras queriendo entender el modelo de cobro. Una sola página no sostiene esas cuatro conversaciones. Quien intenta resolverlo todo en una landing termina con un texto que no le sirve a ninguno de los cuatro.
Si el producto todavía no existe o no ha vendido, la conversación es otra y la página única sigue siendo la respuesta correcta. Conviene ver qué poner en el sitio antes de que exista el producto antes de invertir en una estructura completa.
Las páginas que todo sitio de SaaS necesita tener
La lista de abajo no es un techo sino un mínimo. Cada fila responde a una pregunta que alguien va a hacer, y la página existe para que la respuesta no dependa de una reunión.
Página | Pregunta que responde | Cuándo entra |
|---|---|---|
Home | Qué problema resuelve esto, y para quién | desde el primer día |
Funcionalidades | Cómo lo resuelve el producto, en la práctica | cuando hay más de un caso de uso |
Precios | Cuánto cuesta y qué limita cada plan | en cuanto haya un plan definido |
Casos o clientes | Funcionó para alguien parecido a mí | con el primer cliente que lo autorice |
Documentación | Cómo lo uso, sin hablar con nadie | cuando el producto requiere configuración |
Registro de cambios | Esto se sigue manteniendo | cuando hay entregas frecuentes |
Blog | Ustedes saben del tema | cuando hay alguien para escribir |
Las dos últimas filas son las que más separan un sitio de SaaS de un sitio institucional común. La documentación y el registro de cambios son contenido vivo, publicado cada semana, y eso es lo que determina la exigencia técnica del proyecto.
¿Cómo estructurar la página de precios?
Con el precio visible, siempre que exista. Esconder el valor detrás de un formulario solo funciona cuando el ticket es alto y la venta es de verdad consultiva. En todos los demás casos, el visitante interpreta la ausencia como demasiado caro o desorganizado, y se va a comparar con quien sí lo publica.
La estructura que funciona tiene cuatro partes: los planes lado a lado con lo que limita a cada uno, la unidad de cobro dicha sin ambigüedad, lo que pasa al superar el límite, y un bloque de preguntas frecuentes que trate las objeciones comerciales reales. La duda más frecuente en una página de precios no es cuánto cuesta. Es qué pasa si crezco.
La construcción del propio producto cambia lo que cabe en esa página. Sobre esto, conviene entender el producto detrás de la página de precios, porque el límite de un plan es una decisión de arquitectura antes de ser una decisión de marketing.
Prueba, demo o formulario: ¿qué pedirle al visitante?
Depende del ticket y de cuánto se explica solo el producto. Un producto simple y barato pide prueba inmediata. Un producto caro y configurable pide conversación. El error común es copiar el modelo de una empresa con un ticket completamente distinto al tuyo.
Hay datos públicos que ayudan a decidir. Según el informe de conversión de ChartMogul con ProductLed, de enero de 2026, que analizó 200 productos B2B, la mediana de conversión de gratuito a pago fue del 8%. El recorte más interesante es otro: las pruebas que exigen tarjeta de crédito convierten alrededor del 30%, más de cinco veces el resultado de las que no la exigen.
Eso no significa que pedir tarjeta sea siempre mejor. Significa que pedir tarjeta filtra, y filtrar temprano suele valer más que el volumen de registros. La decisión sobre qué pedido poner en la página es la misma discusión de decidir cuál es el siguiente paso del visitante, aplicada a un producto de suscripción.
Sea cual sea el pedido, el producto necesita aparecer funcionando antes. Un video corto de la interfaz real convence más que cualquier descripción, y conviene grabar la demo del producto con calidad de pieza de marketing en lugar de improvisar una captura de pantalla.
Docs, changelog y blog: lo que el CMS necesita aguantar
Aquí está la exigencia técnica que define el proyecto. La documentación crece sin parar, el registro de cambios se publica en cada entrega y el blog se acumula. En poco tiempo, el sitio de un SaaS activo tiene más páginas generadas por contenido que páginas diseñadas a mano.
En la práctica eso significa elegir una plataforma que aguante colecciones de contenido de verdad y permitir que el equipo publique sin depender de un desarrollador. La página oficial de planes de Framer, consultada en septiembre de 2026, da la medida de este tipo de exigencia: el plan intermedio cubre 10 colecciones y 2.500 ítems, con excedente vendido aparte hasta 40.000 ítems.
Dos puntos suelen olvidarse en el presupuesto. El primero es quién escribe: la documentación sin dueño envejece rápido y se convierte en un pasivo. El segundo es la plataforma que da CMS para docs y changelog sin convertirse en un proyecto de ingeniería. Y está la cuenta recurrente de quién actualiza el changelog y las docs cada semana, que rara vez entra en la conversación antes de que el sitio exista.
Sitio del producto y app: ¿dónde termina uno y empieza el otro?
Termina en el login. Todo lo que existe antes de entrar a la cuenta es sitio web: público, indexable, hecho para convencer. Todo lo que viene después es producto: privado, funcional, hecho para usarse. Mezclar los dos es el origen de la mitad de los problemas de sitios de SaaS que nos llegan.
Cuando la frontera se vuelve confusa, aparecen síntomas conocidos: páginas de marketing dentro de la aplicación, datos sensibles en una página pública, o un sitio que solo el equipo de ingeniería puede modificar, lo que traba al marketing. Definir la frontera temprano evita retrabajo caro después, y la discusión completa está en la frontera entre el sitio web y el sistema.
Errores comunes en el sitio de un SaaS
Los cinco de abajo aparecen con frecuencia en los productos que nos llegan, y todos tienen la misma raíz: tratar el sitio como una pieza de lanzamiento y no como parte de la operación. Corregirlo después cuesta más que estructurarlo bien desde el principio.
Describir funcionalidades en lugar de resultados. La lista de recursos no dice qué cambia en la vida de quien compra. El recurso es el medio; el resultado es lo que se vende.
Esconder el precio sin motivo. Solo tiene sentido en una venta consultiva de ticket alto. En el resto, aleja a quien estaba listo para comprar.
La documentación como anexo. Tratada como un sobrante del proyecto, envejece y se vuelve el principal motivo de tickets de soporte.
Registro de cambios abandonado. Un changelog detenido hace ocho meses comunica exactamente lo contrario de lo que existe para comunicar.
Un sitio que solo el desarrollador edita. Si publicar un texto exige abrir una tarea de ingeniería, el contenido simplemente se detiene.
Cuánto cuesta un sitio de SaaS y qué cambia según la etapa
Un sitio de producto con estructura completa queda en el rango de US$ 2.000 a US$ 8.000, y lo que mueve el valor dentro de él es el número de páginas con layout propio, quién escribe los textos y cuánto del movimiento se hace a medida. Un producto con área con login e integraciones es otra cuenta, en el rango de US$ 4.000 a US$ 20.000.
El camino más económico es construir por capas, siguiendo la madurez del producto. Home y precios primero, funcionalidades cuando haya más de un caso de uso, documentación cuando la configuración lo exija, registro de cambios cuando la frecuencia de entregas lo justifique. La medida completa por tipo de proyecto está en el presupuesto de un sitio con muchas páginas e integraciones.
Preguntas frecuentes
¿Debo mostrar el precio en el sitio de mi SaaS?
Sí, siempre que exista un plan definido. Esconder el valor solo se justifica en una venta consultiva con ticket alto y alcance variable. En los demás casos, el visitante interpreta la ausencia como precio alto o falta de claridad y se va a comparar con quien lo publica.
¿Cuál es la diferencia entre una landing page y un sitio de SaaS?
La landing sirve a una única decisión, casi siempre proveniente de una campaña pagada. El sitio del producto atiende públicos en etapas distintas al mismo tiempo, del curioso al cliente que busca documentación. Uno no reemplaza al otro y muchas empresas mantienen los dos.
¿Necesito un blog en el sitio del producto?
Solo si hay quien escriba con constancia. Un blog detenido comunica abandono y juega en contra. Si la elección es entre un blog irregular y una documentación bien mantenida, la documentación entrega más, porque atiende al cliente y además atrae búsquedas de quien busca una solución.
¿El sitio del SaaS debe estar en el mismo dominio que la aplicación?
Normalmente sí, con el producto en un subdominio o en una ruta después del login. Los dominios separados fragmentan la autoridad de búsqueda y confunden a quien ya es cliente. Lo importante es que la frontera sea clara: público antes del login, privado después.
¿Cuánto tiempo lleva hacer un sitio de SaaS?
De 4 a 6 semanas para la estructura inicial con home, funcionalidades y precios. La documentación y el registro de cambios suelen entrar en una segunda fase, porque dependen de contenido que el equipo del producto necesita producir y mantener. Lo que más alarga el plazo no es la construcción de las páginas, es la definición de lo que cada una va a decir.
Si estás estructurando el sitio de tu producto ahora, conviene conversar sobre el sitio de tu producto con Wama. Buena parte de nuestro portafolio es SaaS, con sitio web, sistema y aplicación conviviendo en el mismo proyecto.
