Cómo añadir un blog a tu app SaaS (sin construir un CMS)

Toda empresa SaaS acaba necesitando un blog: para anunciar novedades del producto, publicar guías y captar la cola larga de tráfico de búsqueda, que se acumula con los años. El error de la mayoría de los equipos de ingeniería es tratar «añadir un blog» o como una instalación de WordPress de fin de semana o como un proyecto interno de CMS que dura un trimestre. Hay un tercer camino que te da un blog listo para producción en tu propio dominio en una tarde.

Decide dónde vive el blog: subdominio o subdirectorio

Antes de escribir código, decide la URL. Tienes tres opciones:

• blog.yourapp.com: un subdominio, que normalmente apunta a una plataforma alojada aparte.

• yourapp.com/blog: un subdirectorio de tu sitio principal, renderizado por tu propio frontend.

• Un dominio de terceros: publicar en Medium o algo parecido.

El subdirectorio es la opción más fuerte para el SEO: cada artículo suma autoridad al dominio donde vive tu producto, los enlaces internos fluyen con naturalidad entre las páginas de marketing y los artículos, y la analítica se queda en una sola propiedad. Un subdominio es viable; con un dominio de terceros, la autoridad se la lleva otro.

Elegir el subdirectorio impone una restricción de arquitectura: tu propia aplicación tiene que renderizar los artículos. Eso descarta las plataformas acopladas que insisten en servir las páginas ellas mismas y apunta a una configuración API-first: el contenido se escribe en un panel, se obtiene como JSON y lo renderiza tu frontend.

La arquitectura de tres capas

Un blog SaaS necesita exactamente tres capas, y solo una de ellas es tu código:

1. Edición: un panel donde se escriben los artículos, con editor de texto enriquecido, etiquetas, categorías, borradores, metadatos SEO (título, descripción, imagen Open Graph) y publicación programada.

2. Entrega: una API que sirve los artículos publicados como JSON, con paginación, filtro por etiquetas y búsqueda.

3. Renderizado: dos rutas en tu app, una página de listado y una página de artículo.

Construir tú mismo las capas 1 y 2 es donde mueren los proyectos internos de blog: solo el editor lleva semanas de trabajo, y después vienen la subida de imágenes, los borradores, los permisos y los slugs. Un backend de contenido te da las dos capas como servicio, así que todo tu proyecto es la capa 3.

Renderizado: dos rutas y una petición

Con un SDK tipado, la capa de renderizado es pequeña. La página de listado obtiene una página de artículos:

const { data: posts } = await kookee.blog.list({ page: 1, limit: 10 });

La página de artículo lo obtiene por su slug:

const post = await kookee.blog.getBySlug(params.slug);

Renderiza el cuerpo con tus propios componentes y tu sistema de diseño. En React te ahorras aún más trabajo: hooks como useBlogPosts y useBlogPost gestionan los estados de carga y la paginación, y un componente de contenido renderiza por ti el HTML del cuerpo del artículo. O sáltate el marcado por completo: unos componentes renderizados en el servidor muestran la lista de artículos, el filtro por etiquetas, la paginación y la página del artículo a partir de los datos que obtienes; consulta Crea un blog con los componentes de React.

Dos reglas mantienen la calidad:

• Renderiza en el servidor. Usa SSR o generación estática para que los rastreadores y los lectores reciban HTML terminado. El renderizado solo en el cliente funciona, pero renuncias al SEO por el que elegiste el subdirectorio.

• Devuelve 404 reales. Cuando un slug no existe, responde con el estado 404, no con una página «no encontrado» con estilo y estado 200. Los soft 404 ensucian el índice.

La lista de metadatos

Cada página de artículo debería emitir, a partir de datos que el CMS ya guarda:

• <title> y la meta descripción, desde los campos SEO del artículo.

• Una URL canónica que apunte a la ruta del propio artículo.

• Las etiquetas Open Graph y Twitter Card, con la imagen del artículo.

• article:published_time y article:modified_time.

• Datos estructurados JSON-LD de tipo Article.

Como todo sale de una misma respuesta de la API, cabe en una sola función auxiliar. Añade un feed RSS y una entrada en el sitemap por artículo: los dos se generan sin complicaciones desde el mismo endpoint list al que ya llama tu página del blog.

Etiquetas, búsqueda y las funciones que te llevas gratis

Cuando los artículos son datos estructurados, funciones que serían proyectos enteros en un sistema casero se convierten en parámetros de consulta:

• Páginas de etiquetas: kookee.blog.list({ tags: ['engineering'] }) detrás de una ruta /blog/tags/:tag.

• Búsqueda: kookee.blog.list({ search: query }) detrás de un cuadro de búsqueda.

• Comentarios y reacciones: los sirve la misma API si quieres que los lectores participen en los artículos.

• Traducciones: obtén las versiones de un artículo en otros idiomas cuando te expandas a otros mercados.

Ninguna de ellas requiere cambios de esquema ni migraciones por tu parte: el backend ya las modela.

Lo que te cuesta

Las cuentas honestas del camino API-first:

• Tu código: dos rutas, una función de metadatos y un feed. Un día de trabajo en la mayoría de los frameworks, menos si partes de tus plantillas de página actuales.

• Gasto recurrente: una suscripción a una plataforma de contenido. Con planes gratuitos basados en el uso (el de Kookee incluye 100 000 peticiones a la API al mes), un blog típico funciona en el plan gratuito durante mucho tiempo.

• Lo que te ahorras: construir y mantener un editor, el almacenamiento de archivos multimedia, un flujo de publicación y una segunda aplicación desplegada.

Compáralo con la vía autoalojada: una construcción inicial que se mide en semanas y, después, ocuparte para siempre de los parches de seguridad y las actualizaciones de dependencias de un sistema que no es tu producto.

Un orden de construcción concreto

1. Crea un proyecto en tu backend de contenido y escribe un artículo de prueba.

2. Añade las rutas /blog y /blog/:slug, que lo obtienen y lo renderizan en el servidor.

3. Conecta la función de metadatos: título, descripción, URL canónica, etiquetas OG, JSON-LD.

4. Añade el filtro por etiquetas y el feed RSS.

5. Manda a tu equipo al panel y borra «construir un blog» del backlog de ingeniería.

El blog en sí nunca es la parte difícil. Lo difícil es que el esfuerzo de ingeniería vaya a tu producto mientras marketing sigue teniendo una publicación rápida, con tu marca y en tu dominio, y eso es justo lo que te da separar un backend de contenido de una capa de renderizado fina.