# Content Versioning: What It Is and What It's For

> What content versioning is, how history, draft and published version differ, and how to check that you can roll back on your store.

URL: https://clione.ai/glossary/content-versioning/
Lang: en

Versioning here is not the version control of a program's code, or a theme's version number, or one of the [product variants](/glossary/product-variants/): it is **keeping dated versions of what you publish** on the store. A description, a [meta description](/glossary/meta-description/), a [product page](/glossary/product-page/)'s [JSON-LD](/glossary/json-ld/) block, its FAQs. It matters because of two questions someone will eventually ask. The first, after a bulk change that went wrong: can we go back to what we had? The second, when a customer, a supplier or an AI assistant repeats something you no longer say: **what exactly did the product page say on that date?** Without versions, both get answered from memory.

## How it works

A system with versions tells apart three states of the same content, and the IETF named them in April 2010, in RFC 5829, when it defined the link types for navigating between versions of a web resource. **The version history** (_version-history_) gathers all the saved versions. **The latest version** (_latest-version_) is the current one. **The working copy** (_working-copy_) is the one being edited, and it points to the version it came from. And each version can link to its predecessor and its successor in the history.[^rfc5829]

That separation is what matters in a store: **the history saves, the draft is edited and the publication is what the public sees**. Restoring an old version brings it back as a draft; the public page does not change until it is published. A good system saves, with each version, when it was made, who made it, which fields it changed and why.

The other use is auditing: knowing what was published at a given moment. RFC 7089, from December 2013, defines for the web a framework for date-based access to a resource's earlier states: it calls a _Memento_ a resource that **encapsulates a prior state of the original resource**, and a _TimeMap_ the list of those states.[^rfc7089] It is the same idea applied to a whole page: a dated version that can be consulted later.

Dates get published too. Google recommends showing on the page when it was published and when it was updated, and that those dates match the `datePublished` and `dateModified` in the [structured data](/glossary/structured-data/).[^google-dates] And among the signals of content made for search engines and not for people, it asks whether you **change the date of pages to make them look recent when the content has not really changed**.[^google-helpful] A history that records what changed in each version is what lets you move the date only when it should move.

Platforms version some things and not others. In Shopify, the theme code editor keeps a timeline per file and lets you restore a file to an earlier version, with three limits its help spells out: it restores one file at a time, it does not recover deleted files or the whole theme, and **the history is finite, so old versions may not be there**. Restoring replaces the file's whole content, including changes you may want to keep, and Shopify advises duplicating the theme as a copy before editing it.[^shopify-theme-code] That history is the theme code's. For product pages and their data, it pays to check what your platform or the tool that writes to it keeps.

## In a store

A **fictional example**: the history of a coffee maker's description in a store that rewrote its catalog in March.

| Version | Date       | Who                  | What changed                                              | Status    |
| ------- | ---------- | -------------------- | --------------------------------------------------------- | --------- |
| 1       | January 10 | Manufacturer import  | The manufacturer's original text                          | Archived  |
| 2       | March 12   | Bulk rewrite         | New text; capacity goes from 1.2 to 1.5 liters by mistake | Archived  |
| 3       | March 20   | Restore of version 1 | The original text returns, with the correct capacity      | Published |
| 4       | April 2    | Manual edit          | Adds use on induction cooktops                            | Draft     |

Three details make this table useful. **Restoring does not delete version 2**: it creates a new version, number 3, so the mistake stays documented and the restore can also be undone. **The published version and the latest are not the same**: version 4 exists, but the public keeps seeing version 3 until someone publishes it. And the "What changed" column is the one that answers the audit question without opening four texts and comparing them by eye.

Clione works this way with what it writes to the store: it saves a version of every enrichment and every manual edit, keeps the three most recent for each product with their notes and the elements that changed, and restoring one creates a new version; what was restored reaches the store with the next Push.


That restoring a version in the dashboard undoes the change in the store. Restoring puts the version back as the draft or the saved data; **the public page changes when it is published**, and only a check of the live page says the change arrived. And a tool's history records what was changed in that tool: if the platform, a [PIM](/glossary/pim/) or an app later rewrites the field, that change is not in the history.


## How to check it

1. **Find where your store keeps the history** of a product page: in the platform, in the PIM or in the tool that writes the data. Check that each version has a date, an author and what changed.
2. **Restore a version on a test product** and open the page's source code (Ctrl+U) before publishing: if the page has already changed, the system does not tell draft and publication apart.
3. **Compare the published page with the latest published version** in the history. If they do not match, something wrote over it afterward; it is a case for [publication verification](/glossary/publication-verification/).
4. **Review the dates**: the visible date and `dateModified` have to match and move only with a real change to the content.[^google-dates][^google-helpful]
5. **Before a bulk change, make a copy** of what you are about to touch. In a Shopify theme's code, duplicate the theme before editing it.[^shopify-theme-code]

## Related concept: field overwrite

[Field overwrite](/glossary/field-overwrite/) is the problem, and versioning is part of the defense. When one system writes a value over the one another had saved, the earlier one is lost without warning. With versions, **the earlier value is not lost: it is in the history and can be restored**. But the history only records the changes that pass through the system that keeps it; what another system rewrites afterward is not recorded, and to find out you need to look at the published page and watch for [data drift](/glossary/data-drift/). It is not the same as a backup either: a backup saves everything at once to recover from a disaster, and the history saves every change to every element to answer what changed, when and who did it.

To keep going, the [publishing by platform reading path](/learn/publishing-by-platform/) orders the rest of the terms.