Recover a Webflow website by reviewing authorized native backups and CMS sources before rebuilding from public archives. A saved site version, a Collection export and a captured dynamic page preserve different kinds of evidence. The recovery must verify both what visitors see and the Collection relationships that make the pages work.
Do not assume every backup restore changes CMS IDs, or that none ever does. Webflow’s current documentation distinguishes backup dates, so the actual restore point matters to connected systems and import matching.
Choose a restore point against the loss you need to repair
Identify the last correct page or record, the changes that went wrong and newer approved work that must remain. Inspect the actual account’s available backups and permissions. Do not infer a recovery option from another site’s plan or a screenshot of someone else’s dashboard.
Webflow’s backup guidance describes plan-dependent restore availability and site-manager access. Review the relevant backup before restoring and preserve a current baseline through the authorized process.
A restore affects more than the particular item you noticed. Inventory dynamic pages, Collection data, scheduled content and integrations before approving a rollback. Recovery should not quietly replace unrelated current work.
Check ID behavior using the backup date
The documentation states that restores from backups created after March 25, 2024 retain Collection and item IDs. Backups created before that date reset them, affecting integrations that use those identifiers. Record the exact backup date and verify the resulting relationships rather than applying a timeless rule.
A visible page may look correct while an external connection still references an old item ID. Review the relevant authorized API or integration mapping independently. Do not publish private keys or diagnostic payloads as evidence.
Keep the original exported identifiers and the post-restore identifiers together when a mapping is needed. Do not replace the historical source file with a new export and lose the record of what changed.
CMS recovery is also a schema problem
List the Collection fields and their types, required values, reference relationships and dynamic page template. Record where actual content survives. A captured page shows a rendered combination of template and record; it does not necessarily expose the full Collection schema or hidden values.
Inspect relationships between items, such as an article and its author or a project and its category. Recovered text alone cannot establish every original reference. Keep unverified relationships unresolved until an authorized export or owner review supports them.
Webflow’s CMS import documentation explains matching regular CMS items using exported Item IDs. It distinguishes updating matching items from importing them as new and notes that Ecommerce items use a different route. Do not apply regular CMS update behavior to every record type.
A three-way Collection reconciliation
- Source record: export, native backup or owner-supplied content with its date and identifier.
- Destination record: actual Collection, item ID, slug and restored reference relationships.
- Public page: intended content rendered through the correct template at the approved URL.
Use these three checks together for representative records. A successful import log does not establish that the public page uses the intended field or linked item. A correct public title does not establish that a missing required field was recovered.
Watch scheduled content before publishing
Webflow says previously scheduled Collection items become queued to publish after a backup restore. Review the queue before site publication so restoration does not inadvertently release content earlier than intended.
Keep the owner-approved publication schedule separate from the recovered historical dates. Do not make an old article look newly authored merely because its record was reconstructed. Preserve supported date information and disclose new replacement content appropriately.
When public captures are the remaining source
Use archive evidence to recover readable public text, images and layout references. Map each capture to the intended record and URL. Record missing fields, media and behavior instead of filling them with generic text to make the Collection appear complete.
Reconstruction on Webflow or another agreed CMS requires a reviewed schema and editing workflow. A public archive does not recover private form submissions, member records, integration secrets or unexposed database contents.
Preserve useful original addresses and review genuine platform constraints before approving an exception. Confirm dynamic pages directly, including representative links and mobile layouts, rather than checking only the homepage.
Define acceptance before the rebuild
The handoff should identify the chosen native route or reconstruction source, backup dates, ID consequences, verified Collection relationships, scheduled-content decisions and unresolved gaps. Use actual review evidence before claiming the CMS is operational.
The website recovery review can assess available sources under an explicitly agreed Webflow scope. For supplementary public and owner-held material, the source-mapping guide helps distinguish evidence from new reconstruction.
Webflow recovery questions
Does a restore always reset Collection IDs?
No. Check the backup creation date against the current Webflow guidance and verify the actual result, particularly for historical backups.
Can an archived dynamic page recreate the entire Collection?
It may support the visible content for that page. It does not establish every field, original ID, reference relationship or private record in the underlying Collection.
