You restore a backup, and it usually takes about two minutes. Webflow keeps restore points of your site and lets you roll back to any of them from Site settings. The problem is almost never the tool. It is that nobody made a named backup before the risky change.
We have watched this play out on plenty of projects. Someone deletes a class that turns out to be used on nine pages, or reorganises a Collection and loses a field. The panic lasts about thirty seconds, which is how long it takes to remember the Backups tab exists.
Backups are the least interesting feature in Webflow and one of the most valuable. Here is how they actually work, what they include, the one detail that catches teams out on restore, and how we handle it on client work.
A Webflow backup is a saved restore point of your site at a moment in time. You find them in Site settings under the Backups tab. Each entry can be previewed before you commit to it, so you can check you are restoring the version you think you are.
Preview before restore is the feature worth knowing about. It turns a nervous decision into a verified one, and it costs nothing. If you have ever hesitated over a list of timestamps wondering which one was before the mistake, that is what it is for.
Webflow's Help Center states that all site plans include unlimited backups. There is no allowance to ration and no reason to be sparing. If you are wondering whether to make one, make one.
Webflow creates restore points on its own as you work. According to Webflow's documentation, restore points are created automatically on every 50th auto-save, and also when you restore to a previous version.
That second trigger is quietly reassuring. Restoring is not a one-way door. Webflow saves the current state of your site before it rolls you back, so if you restore the wrong version you can return to where you were.
The automatic points are a safety net rather than a system. They fire on a counter, not on intent, so the nearest automatic backup might be from just after you made the change you now regret. That is exactly why manual backups matter.
Use the keyboard shortcut in the Designer. Webflow's documentation gives it as Command plus Shift plus S on a Mac, or Control plus Shift plus S on Windows. That creates a restore point immediately, at a moment you chose rather than one a counter chose for you.
Then name it. Webflow lets you rename a backup from the three dot menu next to it, and a named backup is worth ten unnamed ones. "Before nav rebuild" tells you something six weeks later. A bare timestamp tells you nothing.
Our habit is to make a named backup before four specific things: restructuring the CMS, changing global classes or a design system, adding custom code that touches the whole site, and any handover to another person. Those four cover almost every situation where we have wanted one.
None of that takes more than five seconds. The whole practice is a keyboard shortcut and a short sentence, which is why it is worth building into how a team works rather than leaving it to whoever remembers.
Yes to both. Webflow's Help Center states that images and other assets are saved and restored with a backup, and that CMS content is included as well. A restore is not just the design, it is the content sitting inside it.
This cuts both ways and people miss the second edge. If you restore a version from last Tuesday, CMS items added since then are affected too. A rollback intended to undo a design change can also undo a week of content work.
So a restore is a whole-site decision, not a targeted fix. Before rolling back, ask what has been published since that point. If a lot of content has been added, it is often cheaper to fix the design problem by hand than to restore and reconstruct the content.
This is one more reason to model your content properly in the first place, so a restore touches structure rather than a pile of duplicated text. We wrote about that in our guide to how Webflow reference fields work.
This is the detail that catches integrations out, and Webflow draws a clear line by date. Restoring a backup created after 25 March 2024 will not reset your Collection and Collection item IDs, and will not affect API calls or third-party connections that use those IDs.
Restoring a backup created before that date behaves differently. Webflow states that it will reset your Collection and Collection item IDs, and will affect API calls and third-party connections relying on them.
If your site is connected to anything, this matters more than the design does. Automations, external apps, and custom integrations often store Webflow item IDs on their side. When those IDs change, the connection breaks silently and keeps looking fine until someone checks.
In practice this only affects sites with very old restore points, which is a shrinking group. But if you are restoring something ancient on a site with integrations, check the backup's date before you commit and warn whoever owns those connections.
Preview first, then restore, then check the things a restore is most likely to disturb. Open the Backups tab, preview the version you think you want, and confirm the specific thing you are trying to recover is actually present in it.
After restoring, work through a short verification pass. Check that your custom code is still in place, that any integrations still fire, that recently added CMS items are where you expect, and that the site publishes cleanly rather than sitting in a half-saved state.
Custom code deserves particular attention, because it lives in several places and is easy to lose track of. Site-wide code, page-level code, and embeds inside components can all be affected by a rollback. We covered where it all lives in our guide to using custom code in Webflow without breaking your site.
Then publish. A restore changes the Designer state, and the live site keeps serving the previously published version until you publish again. Teams occasionally restore, see no change on the live site, and restore again, which only makes the situation more confusing.
Because backups protect the site, not the process. The common failures are two people editing at once, someone publishing an unfinished section to the live site, or a change made directly in the Editor that nobody else knows about. No restore point prevents any of those.
The most expensive version of this is publishing when you meant to save. Webflow makes publishing a single button, and on a busy site that button is one click away from putting work in progress in front of customers.
The fix is a habit rather than a feature. Agree who publishes, agree that big changes get a named backup first, and keep a staging version of anything experimental. Process removes the situations where you would need a restore at all.
It is not an offsite copy of your business. Backups live inside Webflow and depend on your access to that Webflow account. They protect you from mistakes. They do not protect you from losing access to the account itself.
For anything you genuinely could not rebuild, keep a copy outside the platform. Exporting your CMS content to a spreadsheet on a schedule takes minutes and means your actual words and images exist somewhere you control, independent of any single tool.
Assets deserve the same treatment. The original photography, logos, and video that make up your site should live in your own storage, not only inside a website builder. This is not a criticism of Webflow. It is the same advice we would give about any platform.
We treat backups as part of the build, not as a personal habit. A named restore point goes in before any structural change, and the naming convention is plain English so that someone who was not there can read the list and understand it.
At handover we walk the client through the Backups tab directly. Knowing where restore points live, and that previewing is safe, is the difference between a client who calls in a panic and one who fixes their own mistake in a minute.
We also make clear who is allowed to publish. Most of the incidents we have been called in to fix were not technical failures. They were two people with the same permissions and no agreement about who does what. We go deeper on this in our notes on handing off a Webflow site to a client.
Make a named backup right now, before you read anything else. Open your site in the Designer, press the shortcut, and call it something descriptive. It takes five seconds and it removes the only real reason this topic ever becomes stressful.
Then decide two things as a team: who publishes, and what triggers a named backup. Those two agreements prevent more lost work than any feature does, because most Webflow disasters are coordination failures wearing a technical costume.
If you want help setting up a sane workflow on a Webflow site, or you are staring at a site somebody broke and are not sure what to restore, we are happy to walk through it with you. Let's talk. You can find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.