Never lose your content: protecting the editorial work behind an SME website

Content is the real capital

An SME in French-speaking Switzerland redesigns its website. Six months of editorial work: thirty service pages rewritten, forty journal articles, the product sheets, the case studies drafted with the boss on the corner of a desk. One morning, an unfortunate slip in the CMS overwrites half the texts. The version displayed online was already the new one. Nobody has a recent export. Six months of work start again from scratch.

This scenario happens more often than a technical incident. A site’s code can be rebuilt quickly. The content, on the other hand, carries hours of writing, decisions on tone, carefully worked keywords and a company’s memory, and that is what takes time to recreate.

At Voren, we protect this application layer (the texts, the CMS history, the site’s database, the exports) on one principle: every version of the content must be retrievable, calmly and in a controlled way, without depending on a single person or a single tool.

The four layers of content to protect

An SME website rarely contains only one kind of content. Telling the layers apart tells you what to protect, and how often.

Editorial content: the pages, the articles, the product sheets. These are the texts the client proofreads, approves and changes over the months, and the layer that costs the most to rebuild.

The CMS history: drafts, intermediate versions, revisions. A good CMS keeps a record of who changed what and when. That history is worth its weight in gold the day you need to go back to the wording from three weeks ago.

The application database: the structured entries managed by the site, such as a catalogue of services, a list of client references, saved forms or moderated comments. The client entered this data, and it exists nowhere else.

The associated media: the photos, visuals and PDF documents uploaded to the CMS. Often forgotten because they seem “obvious”, even though the optimised, cropped version exists only there.

Versioning content as you go

The first protection comes from the way the content is produced. At Voren, pages and articles are written as text files versioned in Git. Every change is time-stamped, attributed to its author and reversible. Finding the wording of a page as it stood on 3 March takes a few seconds. Restoring an earlier version is like undoing a correction in a word processor, but across the site’s entire history.

A writing error therefore destroys nothing permanently, and an accidental deletion can be recovered. When two people work on the same text, their contributions merge cleanly instead of overwriting each other.

For content the client manages directly in a CMS, the same logic applies. We switch on the revision history, document who is allowed to publish, and set up a review before anything goes live. Content never jumps from a draft to the live version without a recorded intermediate step.

Regular CMS exports

A CMS’s internal history protects against human error. It does not protect against losing the tool itself: a suspended account, a corrupted database, a provider that closes down.

The answer is the export: the content must leave the CMS at regular intervals, in a readable, independent form.

In practice, a scheduled export collects all the structured content and places it in storage separate from the production tool. Depending on the CMS, this takes the form of a complete data file, a database export or a folder of files. Whatever the form, the day the CMS becomes inaccessible, the content exists elsewhere, in a format you can read and re-import.

The frequency depends on how often things change:

Business website that rarely changes: a weekly export is enough. At worst you lose a week’s changes, which remain rare on this type of site.

Site with an active blog: a daily export. The content moves enough to justify a fresh copy every day.

Site with content entered by the client (catalogue, references, forms): at least a daily export, keeping successive versions for thirty to ninety days.

Retention: keeping several versions over time

A single export that overwrites the previous one offers poor protection. It assumes you will notice a problem within twenty-four hours. Yet silent damage happens in content too.

Say a clumsy edit changes the tone of ten product sheets. Nobody sees it straight away because the pages display normally. Three weeks later, the client notices. If the only export available dates from yesterday, it already contains the error. You need to be able to go back to the version from before the change.

The retention rule follows from this: keep several generations of exports, over thirty days for a business website and ninety days for a site where the content is a business asset. That depth of history covers the errors nobody notices immediately.

The same logic applies to the CMS history. Keeping revisions for too short a time amounts to wiping the texts’ memory. We set it wide enough to cover a complete review cycle.

The tested restore: the part everyone skips

An export you have never re-imported remains an assumption. The file may be truncated, unreadable or incompatible with the current version of the CMS. A media folder may have lost the paths that link images to pages. You only find out when you put it back in place, in other words at the worst moment if you have never checked it in calm conditions.

The remedy is a quarterly habit:

1. Retrieve the latest content export.
2. Re-import it into a separate review environment.
3. Check that the pages, articles and product sheets display with their text intact.
4. Make sure the media are properly linked to their content.
5. Record the result: duration, friction points, corrections to make.

If the restore fails, the export was useless, and it is better to find that out during a quiet test than during an incident. You fix the process straight away.

The example of the Voren journal

The journal you are reading has more than a hundred articles, each one a versioned text file, and the full history of every page goes back to its first line. A rewrite like this one leaves an attributed, reversible trace.

Alongside this, the site’s structured content is exported every day to storage separate from the production tool, with ninety days of rolling retention. A test restore is carried out every quarter in a review environment. The last one took eleven minutes and confirmed the integrity of the whole.

Once in place, this set-up costs almost nothing to run. What it mostly costs is rigour when it is installed. That is the role of maintenance: turning a good intention into a routine that holds.

Common mistakes

Relying only on the CMS history. The tool keeps an internal memory, very useful against human error. The day the tool itself goes down or becomes inaccessible, that memory goes with it. You need a copy of the content outside the tool.

Forgetting the media. The text is exported, the images are not. The cropped, optimised version of the visuals exists only in the CMS. Include it in the scope of the content to protect.

Keeping only the latest version. Without depth of history, an error noticed three weeks later becomes irreparable. Keep several generations of exports.

Never testing the re-import. An export that has never been replayed remains a hypothesis, which the quarterly check turns into a certainty.

Letting the process fail silently. A scheduled export that crashes without warning for two months gives a false sense of security. Set up an alert for failures, and keep an eye on it.

Going further

See our Maintenance plan: content versioning, scheduled exports and tested restores included, with a quarterly check on the Pro and Premium plans.

Read our article on the editorial calendar: it helps you build the content that deserves protecting.