How to Back Up a Webflow Site and Verify a Restore

TL;DR

• Create a named recovery point before a risky website change and keep a separate record of what you changed.
• A Webflow site backup and a CMS content export solve different recovery problems; keep both when the change touches content.
• Preview the restoration, check scheduled content and integrations, and verify the public site after publishing.
• Preserve important URLs, original article dates and image files when moving content between systems.

Start with the change you need to undo

A backup is useful when you can connect it to a known working state. “Yesterday afternoon” is less helpful than “Before replacing the article template, with the contact form and three sample articles checked.” Write the reason for the recovery point before editing. Record the person making the change, the affected pages and the result you expect.

For example, a marketing team might change the blog template to add author biographies. If the release accidentally hides article images, restoring the entire site could also undo a colleague's new landing page. A precise record helps you decide whether to repair the template or restore a wider state. Recovery should have a defined scope, just like the original change.

This guide is an operator checklist, not a claim that every external service is included in a Webflow backup. Your mailing service, domain registrar and separate content platform may each own information that requires its own recovery process.

Create and identify a Webflow recovery point

Webflow documents automatic restore points after 50 autosaves and a manual save shortcut after the saved indicator appears. Its Backups area in Site settings lets authorized site managers inspect available versions. Retention differs by plan, so check which versions your site can access before relying on an older point. Preview the candidate before restoring it. These are platform behaviors, not proof that a particular third-party integration has been backed up. Webflow backup documentation.

Use a short change note beside your project record:

• Working state: article template version before the biography update.
• Planned change: add a biography component and adjust the article footer.
• Sample URLs: one short article, one long article and one article containing a table.
• Separate records: current CMS export, integration settings inventory and image ownership notes.
• Recovery owner: the person who can access the backup and approve the corrected release.

Do not paste passwords or service keys into this record. Identify the secure location and responsible owner instead.

Keep content exports separate from site backups

A content export is useful for inspecting and transferring records even when you do not want to roll back the site's layout. Webflow supports importing and exporting CMS Collection content through CSV. Review field mappings and identifiers before an import; a spreadsheet that looks correct can still create unwanted records if identifiers or mappings are wrong. Webflow CMS import and export guidance.

Open an exported file and inspect representative rows. Check the title, slug, body, dates, image references and any relationship fields your templates use. Save the file with a date and Collection name. Keep the untouched export as evidence; make a separate working copy if you need to edit values.

A CSV containing an image URL is not the same as an independently stored image file. Determine who owns the image host and what happens when the old site or account closes. Check that the destination actually stores or intentionally continues to serve each asset.

Use this recovery checklist

Webflow specifically warns that restoring scheduled items changes them to a queue for publication. Review that queue before publishing the restored site. Its documentation also distinguishes older backups whose CMS identifiers can change on restoration. Treat these as release checks, especially if another system stores Collection or item IDs. Webflow restoration behavior.

Verify before declaring the recovery complete

Test the same sample URLs you recorded before the change. Read a paragraph, inspect a table, follow a link and open an image. Submit a form only in an approved test workflow; do not trigger a customer email or business process merely to prove that a button works. Confirm the public output from a signed-out session as well as the editor.

For an article migration, compare the old and new page's canonical URL, publication date and body structure. A successful import count does not establish that readers can see the article. Keep a small exceptions list with a responsible person and a concrete fix for every failed check.

If your site receives articles from RankWin CMS, the site and its CMS are separate parts of the publishing chain. Preserve the authenticated blog path, keep the delivery credential on the server, and verify that the public article reflects the intended CMS version. The website URL structure guide explains the page-level decisions to preserve.

Frequently asked questions

Is a CMS export a complete website backup?

No. Treat it as a content transfer and inspection artifact. Layout, configuration, media ownership and external integrations need their own checks.

Should I restore immediately after discovering a mistake?

First establish what changed and what else happened afterward. A small repair may preserve valid work that a broad rollback would undo. If you restore, inspect the candidate version and the publishing queue before releasing it.

How often should a team make a recovery point?

Tie deliberate recovery points to meaningful changes: bulk imports, template updates, migrations and integration changes. The right frequency depends on how much work could be lost and how quickly you need to recover.