# Versionado de contenido: qué es y para qué sirve > Qué es el versionado de contenido, en qué se distinguen historial, borrador y versión publicada, y cómo comprobar que puedes volver atrás en tu tienda. URL: https://clione.ai/es/glosario/versionado-de-contenido/ Lang: es Aquí versionado no es el control de versiones del código de un programa, ni la versión de un tema, ni una de las [variantes de producto](/es/glosario/variantes-de-producto/): es **guardar fechadas las versiones de lo que publicas** en la tienda. Una descripción, una [meta description](/es/glosario/meta-description/), el bloque [JSON-LD](/es/glosario/json-ld/) de una ficha, sus preguntas frecuentes. Importa por dos preguntas que tarde o temprano alguien hace. La primera, después de un cambio masivo que salió mal: ¿podemos volver a lo de antes? La segunda, cuando un cliente, un proveedor o un asistente de IA repite algo que ya no dices: **¿qué ponía exactamente la ficha en esa fecha?** Sin versiones, las dos se responden de memoria. ## Cómo funciona Un sistema con versiones distingue tres estados de un mismo contenido, y el IETF les puso nombre en abril de 2010, en el RFC 5829, al definir los tipos de enlace para navegar entre versiones de un recurso web. **El historial de versiones** (_version-history_) reúne todas las versiones guardadas. **La última versión** (_latest-version_) es la actual. **La copia de trabajo** (_working-copy_) es la que se edita, y apunta a la versión de la que salió. Y cada versión puede enlazar a su predecesora y a su sucesora en el historial.[^rfc5829] Esa separación es la que importa en una tienda: **el historial guarda, el borrador se edita y la publicación es lo que ve el público**. Restaurar una versión antigua la trae de vuelta como borrador; la página pública no cambia hasta que se publica. Un buen sistema guarda, con cada versión, cuándo se hizo, quién la hizo, qué campos cambió y por qué. El otro uso es la auditoría: saber qué estaba publicado en un momento dado. El RFC 7089, de diciembre de 2013, define para la web un marco de acceso por fecha a los estados anteriores de un recurso: llama _Memento_ a un recurso que **encapsula un estado anterior del recurso original**, y _TimeMap_ a la lista de esos estados.[^rfc7089] Es la misma idea aplicada a una página entera: una versión fechada que se puede consultar después. Las fechas también se publican. Google recomienda mostrar en la página cuándo se publicó y cuándo se actualizó, y que esas fechas coincidan con las de `datePublished` y `dateModified` de los [datos estructurados](/es/glosario/datos-estructurados/).[^google-dates] Y entre las señales de contenido hecho para buscadores y no para personas, pregunta si **cambias la fecha de las páginas para que parezcan recientes cuando el contenido no ha cambiado de verdad**.[^google-helpful] Un historial con lo que cambió en cada versión es lo que permite mover la fecha solo cuando toca. Las plataformas versionan unas cosas y otras no. En Shopify, el editor de código del tema guarda una línea de tiempo por archivo y permite restaurar un archivo a una versión anterior, con tres límites que su ayuda deja escritos: restaura un archivo cada vez, no recupera archivos borrados ni el tema entero, y **la historia es finita, así que las versiones antiguas pueden no estar**. Restaurar sustituye el contenido completo del archivo, incluidos los cambios que quizá quieras conservar, y Shopify aconseja duplicar el tema como copia antes de editarlo.[^shopify-theme-code] Esa historia es la del código del tema. Para las fichas y sus datos, conviene comprobar qué guarda tu plataforma o la herramienta que escribe en ella. ## En una tienda Un **ejemplo ficticio**: el historial de la descripción de una cafetera en una tienda que reescribió su catálogo en marzo. | Versión | Fecha | Quién | Qué cambió | Estado | | ------- | ----------- | ---------------------------- | ------------------------------------------------------------ | --------- | | 1 | 10 de enero | Importación del fabricante | Texto original del fabricante | Archivada | | 2 | 12 de marzo | Reescritura masiva | Texto nuevo; la capacidad pasa de 1,2 a 1,5 litros por error | Archivada | | 3 | 20 de marzo | Restauración de la versión 1 | Vuelve el texto original, con la capacidad correcta | Publicada | | 4 | 2 de abril | Edición manual | Añade el uso con placas de inducción | Borrador | Tres detalles hacen útil esta tabla. **Restaurar no borra la versión 2**: crea una versión nueva, la 3, así que el error queda documentado y la restauración también se puede deshacer. **La versión publicada y la última no son la misma**: la 4 existe, pero el público sigue viendo la 3 hasta que alguien la publique. Y la columna «Qué cambió» es la que responde a la pregunta de la auditoría sin abrir cuatro textos y compararlos a ojo. Clione funciona así con lo que escribe en la tienda: guarda una versión de cada enriquecimiento y de cada edición manual, conserva las tres más recientes de cada producto con sus notas y los elementos que cambiaron, y restaurar una crea una versión nueva; lo restaurado llega a la tienda con el siguiente Push. Que restaurar una versión en el panel deshace el cambio en la tienda. Restaurar devuelve la versión al borrador o al dato guardado; **la página pública cambia cuando se publica**, y solo una comprobación de la página en vivo dice que el cambio llegó. Y el historial de una herramienta recoge lo que se cambió en esa herramienta: si después la plataforma, un [PIM](/es/glosario/pim/) o una aplicación reescriben el campo, ese cambio no está en el historial. ## Cómo comprobarlo 1. **Busca dónde guarda tu tienda el historial** de una ficha: en la plataforma, en el PIM o en la herramienta que escribe los datos. Comprueba que cada versión tiene fecha, autor y qué cambió. 2. **Restaura una versión en un producto de pruebas** y abre el código fuente de la ficha (Ctrl+U) antes de publicar: si la página ya cambió, el sistema no distingue borrador y publicación. 3. **Compara la página publicada con la última versión publicada** del historial. Si no coinciden, algo escribió encima después; es un caso de [verificación de publicación](/es/glosario/verificacion-de-publicacion/). 4. **Revisa las fechas**: la fecha visible y `dateModified` tienen que coincidir y moverse solo con un cambio real del contenido.[^google-dates][^google-helpful] 5. **Antes de un cambio masivo, haz una copia** de lo que vas a tocar. En el código de un tema de Shopify, duplica el tema antes de editarlo.[^shopify-theme-code] ## Concepto cercano: sobrescritura de campos La [sobrescritura de campos](/es/glosario/sobrescritura-de-campos/) es el problema, y el versionado es una parte de la defensa. Cuando un sistema escribe un valor encima del que había guardado otro, el anterior se pierde sin aviso. Con versiones, **el valor anterior no se pierde: está en el historial y se puede restaurar**. Pero el historial solo recoge los cambios que pasan por el sistema que lo guarda; lo que reescribe otro sistema después no queda registrado, y para descubrirlo hace falta mirar la página publicada y vigilar la [deriva de datos](/es/glosario/deriva-de-datos/). Tampoco es lo mismo que una copia de seguridad: la copia guarda todo de golpe para recuperarse de un desastre, y el historial guarda cada cambio de cada elemento para responder qué cambió, cuándo y quién lo hizo. Para seguir, la [ruta de lectura de publicación por plataforma](/es/aprender/publicacion-por-plataforma/) ordena el resto de términos.