Cómo crear una página de novedades (changelog): entradas, etiquetas, RSS y "Novedades"

Una página de changelog es una lista con fecha de los cambios de tu producto, las novedades primero, escrita para las personas que lo usan. Para crear una necesitas entradas con fecha, un título claro, una explicación breve y una etiqueta (Nuevo, Mejorado, Corregido), una página que las liste, una URL separada para cada entrada y, idealmente, un feed RSS y una forma de avisar a los usuarios de que hay novedades. Es una de las cosas más sencillas que puedes construir, y la decisión principal es dónde viven las entradas: como archivos en tu sitio, o en una base de datos con una página de administración.

Por qué merece la pena tener un changelog

Un changelog muestra a clientes y posibles clientes que el producto se mantiene. Ofrece a soporte y ventas un enlace que enviar cuando alguien pregunta "¿ya hace X?". También es un lugar para cerrar el ciclo con las sugerencias: cuando se publica una función pedida, la entrada del changelog es a lo que diriges a la gente. Si gestionas un portal de comentarios de clientes, enlaza las peticiones publicadas directamente con sus entradas.

Un changelog no es tu historial interno de commits. "Refactorizado el servicio de facturación" no significa nada para un usuario. "Las facturas ya muestran el número de IVA de tu empresa" sí.

Lo que necesita la página

Contenido de cada entrada

Páginas

• Índice del changelog: las más recientes primero, con filtros por etiqueta y paginación sencilla o un botón de "cargar más".
• Página de entrada: una entrada por URL, para poder enlazarla y compartirla.
• Feed RSS o Atom: permite a las personas y a las herramientas seguir las novedades sin correo electrónico.
• Página de administración (solo en la versión con base de datos): escribir, previsualizar, programar y publicar entradas.

Extras dentro de la app

• Distintivo de "Novedades": un punto en un elemento del menú cuando hay entradas que el usuario no ha visto. Guarda la fecha de la última entrada que abrió, por usuario o en el navegador.
• Resumen por correo: un resumen enviado a los usuarios que se suscriben. Esto necesita un proveedor de envío; consulta cómo enviar correos desde tu app.

La decisión principal: archivos o base de datos

Entradas como archivos en el sitio

Cada entrada es un archivo Markdown en el proyecto. Publicar una entrada significa añadir un archivo y volver a desplegar. Es el enfoque más sencillo y robusto: sin base de datos, sin inicio de sesión de administración, nada que asegurar, y las páginas pueden pre-renderizarse para cargar rápido y ser fáciles de leer para los buscadores.

Es adecuado para equipos en los que quienes escriben las entradas se sienten cómodos pidiéndoselo a un creador con IA o editando un archivo.

Entradas en una base de datos con página de administración

Las entradas viven en una tabla, y una página de administración privada permite a cualquiera del equipo escribir, previsualizar, programar y publicar. Es adecuado para equipos en los que marketing o soporte escriben las novedades, o cuando quieres publicación programada o entradas por audiencia (por ejemplo, mostrar las funciones empresariales solo a los clientes empresariales).

El coste es más trabajo de construcción y mantenimiento: un inicio de sesión de administración, subida de imágenes y asegurarte de que las páginas públicas sigan siendo legibles para los buscadores, algo que una página que solo carga las entradas en el navegador puede no cumplir.

Escribir entradas que la gente lea

• Empieza por el beneficio. "Exporta informes a Excel" es mejor que "nuevo módulo de exportación".
• Di a quién le afecta. Todos los planes, solo Pro, se despliega esta semana.
• Muéstralo. Una captura o un clip corto.
• Agrupa las correcciones pequeñas. Una entrada semanal de "Correcciones y mejoras" con viñetas evita saturar la página.
• Sé honesto con las eliminaciones. Si algo va a desaparecer, di cuándo y qué usar en su lugar.

Un primer prompt que funciona

Añade un changelog público a nuestro sitio en /es/changelog. Cada entrada es un archivo Markdown con título, fecha, etiqueta (Nuevo, Mejorado o Corregido), imagen de portada opcional y cuerpo. La página índice lista las entradas más recientes primero con la fecha, la etiqueta y el primer párrafo, tiene botones de filtro por etiqueta y muestra 10 entradas por página. Cada entrada tiene su propia página en /es/changelog/<slug> con un título de página y una descripción adecuados para los buscadores. Añade un feed RSS en /es/changelog/rss.xml. Crea tres entradas de ejemplo. Respeta el diseño actual del sitio, que sea legible en el móvil y pre-renderiza las páginas para que carguen rápido.

Para la versión con base de datos, cambia la primera frase por "Guarda las entradas en una base de datos con estado de borrador o publicada y una fecha de publicación, y añade una página de administración protegida con contraseña para escribir, previsualizar y publicarlas."

Pasos de construcción

1. Decide archivos o base de datos con la tabla de arriba.
2. Construye las páginas de índice y de entrada con unas pocas entradas de ejemplo.
3. Añade etiquetas y filtros.
4. Añade el feed RSS y enlázalo desde la página.
5. Añade títulos de página, descripciones y una entrada en el mapa del sitio para cada entrada. Nuestra guía sobre SEO para sitios web creados con IA cubre lo básico.
6. Página de administración e inicio de sesión, si elegiste la ruta de la base de datos.
7. Distintivo de "Novedades" en tu app.
8. Escribe entradas reales de los últimos meses para que la página no se lance vacía.

Errores comunes

• Copiar los mensajes de commit. Escribe para los usuarios, no para los desarrolladores.
• Una página gigante sin URL por entrada. Nadie puede enlazar a un cambio concreto, y los buscadores ven una página en lugar de muchas.
• Las actualizaciones se detienen tras un mes. Un changelog que se actualizó por última vez hace un año sugiere un producto abandonado. Define un ritmo que puedas mantener.
• Cargar las entradas solo en el navegador. Los buscadores y las vistas previas de enlaces pueden ver una página vacía. Pre-renderiza o renderiza en el servidor.
• Mezclar incidencias. Las caídas pertenecen a una página de estado, no al changelog.

Cuándo es mejor una herramienta de changelog alojada

Existen herramientas alojadas de changelog y de novedades de producto, y algunas vienen incluidas con tableros de comentarios o widgets dentro de la app. Merecen la pena si quieres una ventana emergente dentro de la app, segmentación por audiencia y analítica sin construirlas, o si tu equipo ya paga una herramienta que lo incluye. El software de tu blog o de tu centro de ayuda también puede tener un formato adecuado.

Crear el tuyo tiene sentido cuando quieres el changelog en tu propio dominio, con tu propio diseño y totalmente indexable, lo que para una lista sencilla de publicaciones con fecha no supone mucho trabajo.

Crearlo con Mythex

En Mythex puedes pedirle al agente que añada un changelog a un proyecto existente o que lo construya como un pequeño sitio propio, y verlo en la vista previa en directo mientras se crea. La versión basada en archivos no necesita base de datos. Si eliges la versión con administración, el agente añade una base de datos Postgres dedicada cuando las entradas necesitan guardarse (o escribe /database), y las capturas van al almacenamiento de archivos del proyecto. El inicio de sesión de administración lo añades con tu propio enfoque de autenticación (receta de inicio de sesión).

Las apps nuevas de Mythex suelen ser aplicaciones de una sola página renderizadas en el cliente, que la receta de SEO señala como menos favorables para la búsqueda; así que pide páginas de changelog estáticas o pre-renderizadas si quieres que las entradas aparezcan en los buscadores. La misma receta cubre títulos, descripciones y mapas del sitio. Como punto de partida con un changelog integrado, consulta la plantilla centro de conocimiento del producto.

Preguntas