Backups and Recovery

This content was generated with the assistance of AI and should be verified against the official Webflow documentation before being relied on in production.

This sub-section’s Webflow bibliography lists the reference material consulted while preparing these pages.

This page describes Webflow backups as they were on 2026-10-28, the date on which the facts below were checked against the official Help Center article on saving and restoring backups. Backups are a Designer and Site settings feature, not a versioned API, so everything is dated rather than versioned. Plans are named by tier only (Starter, Basic, CMS, Business, Enterprise, and the Ecommerce tiers); no prices are quoted. The Plans, Workspaces, Seats and Roles page explains which tier unlocks what.

A backup is the answer to the question "can we get the site back the way it was on Tuesday?". It is deliberately a blunt tool: it captures the whole site and restores the whole site. This page explains what a backup contains, how Webflow creates restore points on its own, how to create one by hand, what a restore changes beyond the design, and which situations need a different tool: a Release, a branch, an export or a copy of the CMS data.

The running example is Fernbrook Gardens. The team is about to replace the Plants template page and to import several hundred plants from the nursery feed with the fernbrook-sync script. Both are changes that are easy to make and hard to undo by hand, so the team takes a named backup first.

What a backup is

A backup is a snapshot of the whole site at one moment: pages, styles, classes, variables, components, interactions, CMS collections and items, images and other assets, Ecommerce products, site settings and comments. Webflow’s documentation states that images and assets are included in every backup, so a restored site does not end up with broken image references.

Backups are not a copy of everything that surrounds the site. They do not contain:

the published state of any other copy of the site (a restore changes the working design; it is published, or not, by you afterwards)
form submissions that visitors already sent, which belong to the live site rather than to the design
the account itself: Workspace membership, billing and domains are not part of a snapshot
anything stored outside Webflow, such as the fernbrook-sync repository, a Webflow Cloud database or a DevLink export

For off-platform copies of content, see CSV Import and Export and Code Export and Portability.

Where backups live

Backups are opened from Site settings and then the Backups tab. They can also be reached from inside the Designer, in the Settings panel, with the Backups button, so a designer does not have to leave the canvas to restore. The tab lists every restore point with its date and, for manual backups, the description the author typed.

The Help Center article restricts access to site managers: a role that can open Site settings can see the tab, while a role limited to editing content or designing pages cannot restore the whole site. Which Workspace roles map to that permission is covered in Plans, Workspaces, Seats and Roles.

Plan limits

Restore points are created on every site plan. The Help Center article says that sites on the Starter plan can restore only from the two most recent backups unless the Workspace has a paid plan, while sites on a paid site plan can restore any backup. Treat the retention of very old backups on a free site as something to confirm in the Workspace you use; the safe working assumption is that older restore points on a free site may not be reachable.

Automatic restore points

Webflow saves the Designer continuously. Each edit triggers an autosave, and Webflow keeps a restore point on every 50th autosave. It also creates a restore point when you restore a previous version, so the state you restored away from is not lost. Two consequences follow.

There is no schedule. Webflow does not offer nightly or hourly backups, and a quiet site that nobody edits accumulates no new restore points. A site that was last edited six months ago has restore points from six months ago.
The granularity depends on how busy the Designer is. A heavy editing session produces many restore points close together; a few small edits may produce none, because the 50-autosave threshold was never crossed.

For Fernbrook Gardens this means that the automatic restore points around a long redesign session are useful for "undo the last hour", but are not a substitute for a deliberate backup taken before a risky change.

Manual backups

A manual backup is a restore point that someone chose to create, with a description. It is the tool to use before any change whose failure would be expensive.

Wait until the Changes saved checkmark appears in the Designer toolbar. A backup captures what has been saved, so unsaved canvas edits would otherwise be left out.
Press Cmd/Ctrl+Shift+S, or use the Backups panel, to create a backup.
Type a description that says why the backup exists, for example before plants template redesign, and save.

The description is the only metadata. Because the list is sorted by date and the automatic points have no description, a descriptive name is what lets someone find the right point three months later. Use the three-dot menu on a backup to rename it afterwards.

A manual backup is the right first step for each of these Fernbrook Gardens operations:

replacing a template page that dozens of collection items depend on
changing the structure of a collection (removing a field, changing a field type), which also changes the items
a bulk import or update through the Data API, covered in Data API: CMS
publishing a large batch of changes after a content freeze

Previewing and restoring

Webflow lets you look at a backup before committing to it.

In the Backups tab, hover over a backup and click the eye icon to open a preview of that version. The preview does not change the live design.
If it is the right version, open its three-dot menu and choose to restore it.
Confirm. Webflow first saves the current version as a new restore point, then replaces the design with the chosen backup.

Because the current version is saved before a restore, a restore is reversible: if the old version turns out to be wrong, restore the point that Webflow created a moment earlier. A restore applies to the working copy in the Designer; the published site changes only when you publish, which is why previewing the result and then publishing deliberately is the safe sequence. See Publishing and Scheduling.

What a restore changes

A restore is not limited to pages and styles. Several other parts of the site are affected, and each is a pitfall when unexpected.

Area	Effect of restoring a backup
CMS items	Collections and items return to their state in the backup. The Published on date of items is updated to the time of the restore, so sorting by publish date on a collection list can change.
CMS and collection IDs	Backups made after 25 March 2024 keep collection and item IDs. Backups made before that date reset them. See the next section.
Ecommerce	The same ID rule applies. Webflow asks whether to include inventory levels; declining resets inventory and turns off inventory tracking.
Forms and reCAPTCHA	reCAPTCHA keys are reset. Add them again under Site settings, Forms. If the backup predates your reCAPTCHA elements, add those elements to the forms again.
Comments	Comments persist. Comments attached to elements that no longer exist move to the parent element or the body.
Locales	If the backup contains more locales than are active now, publishing is disabled for all locales and must be enabled again for the ones you need, within the limits of your Localization plan.
Scheduled CMS items	Scheduled items are moved to a publish queue and need to be scheduled again.

Area

Effect of restoring a backup

CMS items

Collections and items return to their state in the backup. The Published on date of items is updated to the time of the restore, so sorting by publish date on a collection list can change.

CMS and collection IDs

Backups made after 25 March 2024 keep collection and item IDs. Backups made before that date reset them. See the next section.

Ecommerce

The same ID rule applies. Webflow asks whether to include inventory levels; declining resets inventory and turns off inventory tracking.

Forms and reCAPTCHA

reCAPTCHA keys are reset. Add them again under Site settings, Forms. If the backup predates your reCAPTCHA elements, add those elements to the forms again.

Comments

Comments persist. Comments attached to elements that no longer exist move to the parent element or the body.

Locales

If the backup contains more locales than are active now, publishing is disabled for all locales and must be enabled again for the ones you need, within the limits of your Localization plan.

Scheduled CMS items

Scheduled items are moved to a publish queue and need to be scheduled again.

The practical rule is to treat a restore as a change that needs a short checklist afterwards: check the Forms settings, check Localization, review scheduled items, and test any integration that stores a Webflow ID.

The CMS ID reset pitfall

Every collection and every collection item has a stable identifier that the Data API, webhooks, Zapier-style automations and apps use. Before 25 March 2024 a restore generated new identifiers for all of them. Webflow’s article states that a backup created before 25 March 2024 resets collection and item IDs when restored, which breaks every API connection and third-party link built on the old IDs, and that those connections must then be reconnected.

For a site whose backups are all more recent than that date the problem does not arise, but two situations keep it alive:

an old manual backup that someone wants to go back to, for example a backup of a site that was relaunched years ago
documentation, tutorials or books written before the change, which warn that restores always break integrations or, conversely, that they never do; the accurate statement is that the behaviour depends on the backup’s date. See Where Older Books and Tutorials Are Outdated.

At Fernbrook Gardens the fernbrook-sync script stores the Webflow item ID of every plant in its mapping file. A restore from a backup after the cut-off keeps those IDs valid. A restore from an older point would orphan the whole mapping, so the team keeps the script’s mapping file in version control and would rebuild it from the CMS (by matching the unique slug) after any restore of an old backup.

Recovering a deleted page

Webflow restores a backup as a whole; it does not offer restoring a single page, a single collection or a single item from a backup. To get one deleted page back without losing the work done since, there are three options, in order of preference.

Undo, if the session is still open. In the Designer, undo reverts recent deletions, including a page deletion, for as long as the session history is available.
Recover from a copy. Duplicate the site, restore the old backup in the copy, then copy the page’s elements from the copy to the live site. Wrapping the page’s content in a single container div first lets one copy-and-paste carry every child element. Classes, components and variables that no longer exist in the live site are created again by the paste, so review them for duplicates afterwards.
Restore the whole site and re-apply the newer work. This is a last resort, because everything made after the backup is replaced. Take a manual backup first so the newer state can be restored back.

CMS content is better protected by an independent export than by a backup. A CSV export of a collection, or a Data API read that writes the items to a file, is a copy you control and can import again.

Backups, Releases and branches

Webflow has three mechanisms that sound alike. They solve different problems.

	Backup	Release	Branch
Purpose	Return the whole site to an earlier state	Bundle approved page changes and publish them together	Work on a page separately and merge it back
Scope	Entire site, including CMS and settings	A set of page changes	A single page’s design
Created by	Webflow automatically, or by hand	People with the right role, on the Enterprise tier	A designer, from the page
Undoes a mistake?	Yes, by restoring	Only by publishing a corrective release	Only by not merging

Backup

Release

Branch

Purpose

Return the whole site to an earlier state

Bundle approved page changes and publish them together

Work on a page separately and merge it back

Scope

Entire site, including CMS and settings

A set of page changes

A single page’s design

Created by

Webflow automatically, or by hand

People with the right role, on the Enterprise tier

A designer, from the page

Undoes a mistake?

Yes, by restoring

Only by publishing a corrective release

Only by not merging

Releases and branching are documented in Page Branching, Releases and Approvals. They give you review and a controlled publish; they are not a safety net for site-wide mistakes. Conversely, a backup is not a review tool: it cannot show what changed between two points or merge two people’s work.

At Fernbrook Gardens the rule is: branch when redesigning a page, release when several pages must go live together, and back up before anything that touches the CMS structure or runs in bulk.

A pre-change checklist

Before a risky change, the Fernbrook team follows the same short sequence.

Make sure the Changes saved checkmark is showing.
Create a manual backup with a description naming the change and the date.
Export the affected collections (CSV, or a Data API read) to a file stored outside Webflow.
Make the change.
Preview the result and publish deliberately; see Publishing and Scheduling.
If a restore was needed, run the after-restore checks from the table above.

The export step can be scripted. This example reads the Plants collection and stores the response in a dated file before a bulk update; the token and collection ID are placeholders.

export WEBFLOW_TOKEN="YOUR_SITE_TOKEN"
export PLANTS_COLLECTION_ID="PLANTS_COLLECTION_ID"

curl -s "https://api.webflow.com/v2/collections/${PLANTS_COLLECTION_ID}/items?limit=100" \
  -H "Authorization: Bearer ${WEBFLOW_TOKEN}" \
  -H "accept: application/json" \
  -o "plants-$(date +%F).json"

Source: the Webflow Data API documentation, https://developers.webflow.com/data/. The endpoint returns a page of items at a time, so a script copying a large collection continues until all pages are read; see Data API: SDKs, Limits and Errors for pagination and rate limits.

Pitfalls

Trusting the automatic points. They depend on the number of autosaves, not on time, and do not carry a description.
Backing up with unsaved changes. A backup is taken from the saved state; wait for the checkmark.
Restoring an old backup and breaking integrations. Check the date against 25 March 2024 before restoring.
Forgetting reCAPTCHA. Forms silently stop accepting spam protection until the keys are entered again.
Declining the inventory prompt in a shop. Inventory tracking is turned off and must be set up again.
Expecting a per-page restore. Use undo or the duplicate-site route instead.
Treating a backup as the only copy of the content. Keep an export of the CMS outside Webflow.

Security and governance

Backups contain the whole site, including content that is not published, such as draft CMS items and comments, so access to the Backups tab is access to unpublished content. Limit the roles that can open it, review who has them when staff leave the team, and avoid pasting secrets into custom code or embeds, which would be preserved in every restore point. For governance across many sites, see Enterprise APIs and Governance.

References

Webflow Help Center, "Save and restore backups": https://help.webflow.com/hc/en-us/articles/33961244069395
Webflow Developer documentation, Data API: https://developers.webflow.com/data/
Webflow updates: https://webflow.com/updates