Webflow CMS Backup: What to Capture, How Often

Webflow doesn't have a real backup product. The Designer has version history for the visual structure of the site, and there's a CSV-per-collection export buried in the CMS panel — but neither of those is a backup in the sense a database engineer would use the word. Neither captures references, asset binaries, or the rich-text formatting that's actually doing the work.

This is the playbook we use, refined from watching people lose CMS data they assumed Webflow was keeping safe.

What a CMS backup actually has to include

The lazy version of “back up the CMS” is “export every collection to CSV.” That captures somewhere between 40 and 60 percent of the actual content, depending on the site. Here's what the CSV export misses:

Layer	In CSV export	Why it matters
Plain text fields	Yes	—
Slug field	Yes	—
Number / date / boolean	Yes	—
Rich-text formatting	No	Just gets the text, no headings/lists
Inline images in rich text	No	URLs only, and they may rot
Reference fields	Partial	Stored as item IDs, not slugs
Multi-reference fields	Partial	Same — IDs, no human meaning
Image fields (asset binaries)	No	URLs only — fine until the CDN moves
Draft / archived items	No	Only published items
Custom field option values	Partial	Sometimes IDs, not labels

A real backup captures all of these. The point of backing up isn't to have a CSV — it's to be able to reconstruct the CMS somewhere else, including the binary assets, in a form you can actually use.

What we capture, concretely

Our exporter handles this, but you can replicate the shape manually if you'd rather wire it up yourself. The minimal set:

1. One folder per collection. Each item as a separate file named after its slug.
2. YAML front-matter for structured fields. Strings, numbers, dates, booleans, references-as-slug.
3. Markdown body for the rich-text field. Headings, lists, blockquotes, code blocks, tables, inline formatting.
4. A local assets/ folder. Every image referenced by a CMS field, every inline image in rich text, every file upload — downloaded once, deduplicated by content hash, paths in the Markdown rewritten to relative.
5. A cms.json index. All collections and items in one structured file. Handy for sitemaps, search indexes, and feeds.
6. Drafts and archives, optionally. Off by default; toggled when you want the full work-in-progress state.

That set is restorable, portable, and outlives any specific CMS. The exact thing Webflow doesn't give you in any plan.

How often

The right answer is “before any non-trivial change.” In practice, here's what we suggest based on team size:

Team shape	Cadence	Trigger
One marketer publishing 1–2 posts/week	Weekly	Sunday night
Agency with multiple clients	Weekly per client	After publish day
Marketing team with daily updates	Daily	Cron job, off-hours
Pre-redesign or migration in progress	Every day	Before any work resumes
Pre-export migration	Once, the day before	Locked baseline to compare against

For automated cadence: hit our API on a Cloudflare Worker, push the resulting ZIP into S3 or R2 with date-based naming. Twenty lines of code, $0/month for any normal-volume site.

The three failure modes a backup actually prevents

This is the part nobody mentions in CMS backup tutorials because they read like fire-drill panic. They're also the only reason backups matter:

1. Accidental delete of a collection. Webflow does not undelete collections. If someone clicks the wrong button, the entire structure (fields, items, references) is gone. We've seen this twice. The CSV export, even if you have one, doesn't reconstruct the schema — only a content-shaped backup can.

2. Vendor migration. “We're moving off Webflow” rarely happens with two weeks of clean planning. Usually it happens because pricing changed, an integration broke, or leadership decided. Having a current backup means the migration starts from a known state instead of a frantic export attempt against an active site.

3. Quiet asset rot. Webflow CDN URLs sometimes change shape during platform updates. The URLs in old rich-text fields keep working today; nobody promises they will five years from now. A backup with downloaded asset binaries is immune.

What we don't bother backing up

A few things people sometimes ask about that aren't worth the effort:

• The Designer's visual structure. Webflow's built-in version history covers this. You can't practically reconstruct the Designer file from a backup anyway.
• E-commerce orders and customers. Operational data, not content. Use Webflow's e-commerce export for those — it's purpose-built.
• Site analytics. Live in Webflow Analytics or your GA/PostHog/Plausible — not in the CMS.
• Form submissions. Same — operational data. Pipe them to a real database from day one.

A minimal restore plan

The backup is only useful if you've thought about how to use it. The cheap version:

1. Today: export a backup. Check it deserializes — i.e. open a few .md files, follow a reference, verify the inline images render against the local assets/ paths.
2. Once a quarter: spin up a throwaway static site reading the backup folder. Astro or Eleventy will read the front-matter and content directly. Five minutes of work, full restore confidence.
3. In an actual disaster: the backup is the source. Either re-import into Webflow (item-by-item via the CMS panel — slow, but possible), or pivot to building elsewhere directly from the backup. Most teams that hit this point choose option 2.

How to back up with Webflow Export

The flow is:

1. Generate a Webflow API token (read-only, takes 30 seconds)
2. Paste into webflowexport.com
3. Scan — confirm collection counts, item counts, asset count
4. Download — receive a ZIP with the full structure described above
5. Store the ZIP somewhere durable (S3, R2, Backblaze, even Dropbox)

For automated cadence: same flow, but trigger via the API on a schedule. We re-export for free for 30 days after the initial paid export, so a weekly or daily cron is cheap.

For the full feature breakdown, see Export Webflow CMS. For the broader story on what survives a Webflow CMS export, the existing post on CMS export content walks through the gotchas.

The 30-second version

• CSV export = not a backup.
• A real backup = collections + references-by-slug + asset binaries + drafts.
• Cadence = weekly for most teams, daily for high-velocity ones.
• The point isn't the file — it's being able to reconstruct.

If you don't have one running today, the exporter gets you the first one in about ten minutes. The hard part is remembering to run it; the easy part is what it produces.