When should I save a Webflow backup before a big change?

Save a named restore point before risky work

Large layout changes, Collection template edits, and unfamiliar custom code are good moments for a manual backup. Wait until the green Changes saved checkmark appears so the latest canvas work is included. Then press Command + Shift + S on Mac or Control + Shift + S on Windows, write a clear description such as Before pricing redesign, and save.

Automatic backups still help day to day. A named restore point makes the right version easier to find when several people are publishing. If two people might edit the same template in the same week, agree who creates the restore point and what description naming you will use.

Know the limits for your plan

Paid Site plans (Basic, CMS, Business, and Enterprise) have unlimited backups and can restore any backup. Free Starter Site plans can restore only from one of the two most recent backups unless the site sits in a paid Workspace. Only Site managers can open backups.

Preview a backup before you restore. Webflow also saves the current version when you restore to an older one, which gives you a path back if the wrong point was chosen. Confirm Site manager access before a deadline night, not after something breaks.

Read restore side effects first

A restore is not always a quiet undo. Scheduled Collection items can move to Queue to publish. reCAPTCHA keys may need to be re-entered. Bot blocking can turn off. Locales and comments can behave differently depending on what existed in the backup. Historical backups from before Webflow's March 2024 CMS ID changes can affect API connections.

Treat restore as a controlled recovery: confirm the preview, note integrations that might need reconnecting, then restore and retest forms and critical journeys.

Checklist before you click restore

Work through a short written list so the restore is intentional:

• Confirm the backup description and timestamp match the version you want.
• Preview the backup in a new tab and spot-check the pages you plan to recover.
• Note whether forms use reCAPTCHA or bot blocking so you can re-enable settings afterward.
• List third-party connections that may rely on CMS item IDs if you are restoring a very old backup.
• Tell the team not to publish new Designer work until the restore and retest finish.

Skipping this list is how a rushed restore becomes a second incident.

Retest after restore and publish

After restore, publish only when you mean to, then verify the paths that earn money or leads:

• Open primary forms and send a labeled test submission.
• Walk the main service or pricing journey on mobile and desktop.
• Open a representative CMS item and a Collection list card for layout regressions.
• Confirm notification email settings and spam protection toggles still match your live needs.
• Record pass or fail next to each check so the next person is not guessing.

For example: Backup Before blog template v2 restored at 14:10. Retest: /contact form OK, /blog list OK, reCAPTCHA keys re-added, bot blocking turned on again.

Put backups on the change brief

Example brief line: Before editing the shared blog template, save backup Before blog template v2, confirm Site manager access, and list forms to retest after any restore. Pair this with your monthly maintenance review so backups are not only discussed during emergencies. When big changes arrive often, written ongoing support helps one person track restore points and the publish checklist.