Tu contenido merece el mismo control de versiones que tu código

Publicar una entrada en un CMS se siente tan delicado por una razón: si algo sale mal, volver al punto de partida no siempre es sencillo. Algunas plataformas te dan una pila de deshacer muy limitada. Otras restringen el historial a un número fijo de revisiones o a una ventana móvil de 30 días. Varias tratan el historial completo de versiones como una función empresarial que pagas aparte para desbloquear.

El resultado es un equipo de contenido que publica con mucha cautela — no porque sea disciplinado, sino porque está nervioso. Ese no es el tipo de prudencia correcto.

b10cks guarda todas las versiones para siempre, en todos los planes. Experimenta libremente. Vuelve atrás con confianza.

Cada vez que se guarda contenido en b10cks — borrador, guardado automático, publicación o edición — se crea y almacena una nueva versión. No hay límite de retención. No hay tope en el número de revisiones. No existe eso de “las versiones antiguas se purgan después de 30 días”.

• Registro completo de cambios: ve cada versión, quién la creó y cuándo
• Restauración con un clic: vuelve a poner cualquier versión anterior como borrador o en vivo
• Historial por campo: inspecciona exactamente qué campos cambiaron entre dos versiones cualesquiera
• Registro de auditoría: un historial apto para cumplimiento sobre quién cambió qué y cuándo, en todo tu espacio de contenido

El historial de versiones de tu contenido dura tanto como el proyecto. Si necesitas ver cómo se veía tu página de inicio seis meses antes de un rebranding, ahí está.

Una rama de contenido es una copia de trabajo aislada de tu espacio de contenido. Los editores trabajan con libertad — reordenando estructuras, redactando nuevas páginas, probando nuevos tipos de contenido — sin riesgo de afectar al sitio en vivo.

Cómo funcionan las ramas en b10cks:

• Crea una rama desde cualquier punto del historial de contenido — desde el estado actual en vivo, desde una etiqueta o desde otra rama
• Edita de forma independiente: los cambios en una rama no afectan a ninguna otra rama ni al espacio principal
• Fusiona cuando esté listo: lleva los cambios de la rama de vuelta al espacio principal, con detección de conflictos y resolución de fusiones a nivel de campo
• Elimina con seguridad: las ramas que no funcionaron se pueden descartar sin consecuencias

Este es el flujo de trabajo que permite a un desarrollador reconstruir el modelo de contenido de un sitio en staging mientras los editores siguen publicando en producción. Sin congelaciones. Sin “por favor, no toquéis el CMS esta semana”.

No todas las versiones son iguales. Algunas representan un hito: un lanzamiento de producto, una campaña estacional, una captura previa al rediseño, una revisión de texto aprobada.

Las etiquetas de versión te permiten marcar cualquier versión de cualquier contenido con un nombre significativo:

• v2.-launch · black-friday-2025 · pre-rebrand-snapshot · legal-approved-Q1
• Las etiquetas se pueden buscar y filtrar en todo tu historial de versiones
• Restaura o crea una rama desde una etiqueta en cualquier momento — sin buscar entre marcas de tiempo
• Usa las etiquetas como puntos de referencia estables en traspasos entre varios equipos

Cuando el CEO pregunta “¿qué estaba exactamente en vivo el día del lanzamiento?” — tienes la respuesta, al instante.

Un lanzamiento en b10cks es una colección nombrada de cambios de contenido — repartidos entre varias entradas, tipos de bloque y configuraciones regionales — que se preparan juntos y se publican como un único evento coordinado.

• Agrupa cambios: reúne en un solo lanzamiento una actualización de la página de inicio, una revisión de la página de producto y una nueva entrada del blog
• Previsualiza el lanzamiento antes de que salga en vivo — ve el conjunto completo de cambios tal como lo verá tu audiencia
• Programarlo es fácil: fija una hora de salida y olvídate; b10cks publica todo del lanzamiento de forma atómica

Así se ve lanzar una campaña cuando tu CMS realmente lo permite.

Cada versión en el historial de b10cks se puede publicar — no solo el borrador actual. Si necesitas devolver una página en vivo a un estado anterior, no hace falta deshacer cambios manualmente ni pegar contenido desde una copia de seguridad. Promueves la versión que quieres y pasa a estar en vivo.

• Reversión instantánea: promociona una versión anterior a publicada con una sola acción
• Reversión selectiva: revierte una sola entrada sin tocar nada más del sitio
• Control multilingüe: revierte de forma independiente el contenido de una configuración regional concreta; tus otras versiones de idioma no se ven afectadas
• Publica desde una rama: fusiona y publica el estado de una rama sin pasar por la copia de trabajo principal

Sin proceso de “restaurar desde copia de seguridad”. Sin necesidad de desarrollador. Solo elige la versión que quieres en vivo y publícala.

Vista previa en vivo de cualquier versión Apunta la URL de vista previa de tu frontend a cualquier versión histórica, etiqueta o rama — no solo al borrador actual. Ve exactamente cómo se renderizaba un estado pasado del contenido en tu sitio real, con el diseño real, antes de decidir restaurarlo o descartarlo. Funciona con cualquier framework frontend mediante la API del token de vista previa de b10cks.

Diff lado a lado Selecciona dos versiones cualesquiera de una entrada y obtén un diff a nivel de campo — qué se añadió, qué cambió y qué se eliminó. Se muestra en una salida limpia y legible: no JSON en bruto, ni un muro de líneas rojas y verdes.

• Compara borrador vs. publicado
• Compara una rama con la principal
• Compara dos versiones cualesquiera del historial
• Compara un solo campo o la entrada completa

Cuando alguien del equipo te pregunte “¿qué cambió desde el martes pasado?” tendrás la respuesta exacta en tres clics.

Para desarrolladores
Ramifica el propio modelo de contenido — no solo las entradas. Prueba nuevos tipos de bloque y cambios de esquema en una rama aislada antes de promocionarlos a tu espacio en vivo. Las ramas de esquema se reflejan al instante en la API, así que tu rama de frontend puede construir en paralelo sobre la nueva estructura de contenido.

Para equipos de contenido
Las campañas estacionales, las pruebas A/B de textos y los relanzamientos del sitio se benefician de las ramas. Redacta en aislamiento, previsualiza en contexto, fusiona cuando esté aprobado. Se acabaron los hilos de correo de “no publiquéis nada hasta el lanzamiento”.

Para agencias
Crea una rama por cada entrega de cliente. Construye y revisa en aislamiento. Fusiona a la principal cuando esté aprobado. El trabajo en curso de cada cliente permanece invisible para producción hasta que esté listo.