Review blog post revisions

In short. Every save on a Published blog post creates a revision snapshot. Use View History (top-right of the Edit screen) to preview and restore any of the last 10 revisions. The platform keeps only 10; for anything older use the row-action Export to save a full JSON backup.

On this page: What is this for · Steps · Backup beyond the cap · Troubleshooting · FAQs

How to undo a bad edit by restoring a previous version of a post

Every time you save a change to a Published blog post, SGEN stores a revision — a snapshot of what that post looked like before the save. The View History screen lets you preview those snapshots and restore an older one.

What is this for?

Revisions are your undo tool for blog content. When you realize the published post is worse than what you had yesterday, open the revision list, find the right snapshot, and restore it — no rewriting from memory.

SGEN keeps the last 10 revisions for every Published post. Older versions fall off silently as new saves happen.

Where to find it

Revision history lives on the post Edit screen — there is no separate revisions menu.

1. Go to Dashboard → Blog and open the Published post you want to review.
2. Click Edit to open the post editor.
3. Click View History in the top-right of the Edit screen.

The revision list opens showing the last 10 snapshots, each with its save timestamp. Because history is reached through the individual post, there is no site-wide revisions page — you always start from the post itself.

Scope

The revision system covers Published blog posts only — tracking starts once a post is set to Published and a save is made. Draft, Private, Password-Protected, and trashed posts do not show View History on this version.

Each revision captures: post title and body content.

Each revision does not capture: SEO fields, Page Banner, Thumbnail, per-post Header/Footer Scripts, Category/Tag assignments, or Comments.

The 10-revision cap is platform-wide and cannot be changed from the admin.

Before you start

• The post must be Published — drafts and trashed posts do not show View History on this version.
• You are signed in to SGEN as an admin.
• Know roughly when the version you want was saved — the history table lists revisions by timestamp, author, and a content snippet.

Examples

Example 1: Recover a rewritten post. You replaced the intro paragraph of a Published post, saved, and the new version read worse than the original. Open View History, preview the revision from before the rewrite, restore it. The original intro is live again within seconds.

Example 2: Check which editor last changed the copy. Two admins share editing duties on a cornerstone post. One admin suspects the other made an unwanted change. Open View History — each row shows the author and a content snippet. Find the row where the copy changed and restore from the row above it.

Example 3: Recover after a bulk-edit mistake. Your team ran a find-and-replace across the body of a high-traffic post and corrupted some formatting. Open View History, find the last clean revision, preview it, and restore. The corrupted edit becomes a new row in the list — you can always swap back if you change your mind.

What NOT to use this for

• Do not try to view revisions on draft or trashed posts. On this version, the View History screen only works for Published posts. Opening View History on a Draft, Private, Password Protected, or trashed post shows a "Data not found" page instead of the revision table. Flip the post to Publish first, then click View History.
• Do not rely on revisions as a full backup. Only the last 10 revisions are retained. Older versions are deleted silently as new saves happen. If a version is more than 10 edits old, it is gone. For long-term backups, Export the post as JSON from the row action on the Blog list.
• Do not expect the post's URL to roll back when you restore a revision. Restore replaces the post's title and body content with the older version. The post's slug (URL) stays on whatever the current version had. If you also want the old slug back, edit the Permalink field on the Edit form after the restore.
• Do not use revisions for SEO, Page Banner, or Thumbnail changes. Revisions snapshot the post's content only. SEO fields, Page Banner settings, per-post Header/Footer Scripts, Thumbnail, Status, and Category/Tag assignments are not versioned — restoring an old revision does not roll those back.

Steps

1. Pick the revision

The history page lists revisions newest to oldest with timestamp, author, and a content snippet.

The top row is marked Current — that is what readers see right now on the public post.

2. Preview (recommended)

Click Preview on the row you are considering.

This opens the snapshot in a read-only view so you can confirm it is the version you want — without making any change.

3. Restore

Click Restore on the chosen row.

A confirmation dialog asks you to confirm before any change is made.

Confirm, and the post's content is replaced with the revision's content.

The public URL updates on the next request.

What success looks like

• The Blog list shows the post with its expected Title (unchanged by the restore).
• Opening the post's public URL in a private/incognito window shows the older content you restored.
• The history view now shows your restore as a new Current revision at the top of the list.
• The previous current content becomes the second row — so you can swap back if you change your mind.

What to do if it does not work

• The View History button is not on my Edit screen. Either the post has never been edited (zero revisions yet — make one edit + Save to create the first) OR the post is not Published. Flip to Publish first if you want revision tracking.
• I opened View History on a Draft post and got "Data not found." Known behavior on this version — View History is only accessible for Published posts. Flip to Publish, then click View History.
• I cannot find the version from last month. The 10-revision cap means older versions are deleted as new saves happen. There is no way to recover revisions beyond the 10. Going forward, use row-action Export on important posts to save JSON snapshots.
• Restore did not change the public page. Your browser or an upstream cache is serving the old content. Try a private/incognito window or append ?cb=1 to the URL.
• My Page Banner / SEO / Thumbnail did not roll back after I restored. Expected. Revisions only cover the post's content; metadata is not versioned. Use a full-post JSON from Export if you need a complete restore.

Reference

What the revision system covers, and what it does not — at a glance.

Restore replaces title and body only. Use Export then Import when you need to roll back fields outside that pair.

Backup workflow beyond the 10-revision cap

The revision system is your immediate undo tool — but it is bounded.

Ten saves and the oldest snapshot is gone.

For posts that matter (cornerstone content, launch announcements, posts you advertise), build a backup habit that lives outside the cap.

Export as JSON, regularly

Every post on the Blog list has a row-action Export that downloads a single-file JSON.

The JSON contains title, body, SEO fields, banner config, status, and category/tag assignments.

Save these in a folder you sync to cloud storage.

The shape:

When you need to restore from a JSON backup: Blog → Import, choose the file, confirm.

A new post is created with the exported content.

If the slug already exists, append a date to your filename so the importer treats the file as a fresh post.

What revisions do not capture

Revisions cover the title and body of the post.

Everything else lives outside the snapshot:

• SEO fields (meta_title, meta_description, OG image) — covered by Export, not by revisions.
• Page Banner / Header image — covered by Export, not by revisions.
• Thumbnail — covered by Export, not by revisions.
• Per-post Header/Footer Scripts — covered by Export, not by revisions.
• Category and Tag assignments — covered by Export, not by revisions.
• Comments / Discussions — not covered by either.

Comments live in Discussions and must be moderated separately.

They survive title/body edits and restores untouched, but if you delete the post they go with it.

Suggested cadence

For cornerstone content, set a calendar reminder to Export once a week.

For high-traffic posts that get edited often, Export immediately after every major change.

For evergreen posts that almost never change, an Export once at publish time is enough — keep the JSON in a "blog backups" folder organised by year.

Restore checklist when a post goes wrong

When the revision system alone is not enough, run this short checklist:

1. Identify what is wrong. Is the body content wrong? The SEO description? The banner image? Each lives in a different surface; revisions only cover content.
2. Check the revision history first. If the content is the issue and the older version is within the last 10 saves, restore it. Done.
3. If content is older than 10 saves, look for a JSON export. Check your backup folder for the most recent good export. Re-import to a temporary post name, copy the body into your live post via the Edit form, save.
4. For metadata regressions (SEO, banner, thumbnail), use the JSON export only. Revisions will not help. Read the exported JSON, copy the fields manually into the Edit form's matching sections, save.
5. Verify on the public side in an incognito window. Cache busters or ?cb=1 query parameters help bypass upstream caching.

Common mistakes operators make

• Treating revisions as a long-term archive. They are not. Ten saves is the cap. Set a recurring export job for anything you cannot afford to lose.
• Restoring without previewing. The Preview button is there for a reason. Restoring a wrong revision creates yet another save, pushing the version you wanted further down the stack — and possibly off the bottom.
• Forgetting that metadata does not version. Restoring an old revision will not bring back your old SEO description or your old hero image. Plan a separate metadata restore step.
• Saving "tweaks" while iterating. Every save consumes a revision slot. If you are iterating on copy ten times in a row, the safety net runs out fast. Save once when you are confident; preview live before each save.

Revision behaviour across common edit scenarios

The 10-revision cap is straightforward in isolation but behaves in ways operators sometimes find surprising once real edit patterns overlap.

The shapes below show what to expect.

Edits inside the same minute

If you save twice within a minute or so, SGEN writes both as separate revisions.

The cap does not deduplicate near-simultaneous saves.

Heavy click-to-save habits expire the safety net fast — slow your save cadence on important posts.

Auto-save (where enabled)

Some editor configurations auto-save in the background.

When auto-save fires, it writes a revision just like a manual save.

If your editor auto-saves every 60 seconds during a long writing session, you can burn through the entire 10-revision window in 10 minutes without realising.

Keep auto-save off for cornerstone posts, or accept the consequence: only your last 10 minutes of state is recoverable.

Bulk imports

When you re-import a post from a JSON export, the imported version becomes the current content and a single new revision is written.

The 10-revision window keeps the prior 10 saves; older revisions still get evicted from the bottom of the list.

An import is not a "reset to original" — it is one more save on top of the existing history.

Cross-author edits

Two admins editing the same post in different tabs both write revisions on Save.

SGEN does not lock the editor against concurrent edits; whoever saves second overwrites the first.

Both saves count against the revision cap.

Coordinate ownership of high-stakes posts before letting two people edit in parallel.

Restore-then-edit

Restoring an old revision creates a new Current row.

Editing immediately afterward and saving creates another.

So a "go back two saves" routine adds two revisions, not subtracts two.

The history grows as you work — it does not shrink.

Frequently asked questions

Do trashed revisions go anywhere I can recover them?

No.

Once a revision is evicted (the 11th save pushes the oldest off the end), it is gone from the database.

There is no admin recovery surface and no support recovery path.

Treat Export as the only durable backup.

Can I increase the 10-revision cap?

Not from the admin on this version.

The cap is platform-side.

If your team needs deeper history, build a JSON-export habit.

Does the revision cap apply to drafts?

Drafts do not currently expose revision history — View History only opens for Published posts.

Drafts that you save many times do not show their own history surface; once you promote a draft to Publish, revision tracking starts from that point forward.

Does restore notify anyone?

No.

Restoring a revision is a silent admin action.

No email, no toast to other admins, no audit-log row visible from the admin.

If your team needs change-tracking on cornerstone content, agree on a Slack or email convention to announce restores manually.

Will restoring affect the post's Updated timestamp?

Yes.

The Blog list's Updated column reflects the most recent save, including a restore.

After a restore, the post's Updated value moves to the restore time, not the original revision's time.

Are revisions visible to non-admins?

No.

The View History screen is admin-only.

Public readers see only the live post; they cannot view, preview, or even know about prior revisions.

How this connects to other features

• Page revisions behave the same way for Pages — see View and restore page revisions.
• Restore a post from a revision walks through the restore step in more detail.
• Clear post revisions lets an admin prune stored revisions site-wide to reclaim database space — the opposite end of the lifecycle from this guide.
• Export (the row action in View History) is the manual backup path when you need to keep more than the last 10 — see Backup workflow beyond the 10-revision cap above on this page.

Next step

• Back up important posts via the row-action Export on the Blog list — downloads a JSON of the post that can be re-imported later.
• Keep posts Published while you iterate so every save writes a revision. Switching to Draft to "work on it" disables the history safety net on this version.
• Return to the post list via Blog → All Blogs to continue editing.
• See also Create and manage blog posts and Import and export posts.