Webflow export to Astro: what moves and what must be rebuilt

A Webflow code export gives you files from the current build. It does not give you an Astro project with its content, services and publishing workflow already connected.

The distinction matters before you estimate the migration. The ZIP is one input to the work, not the inventory of everything that has to move.

What is in the export

Webflow documents exported HTML, three CSS files, JavaScript and uploaded image assets. The JavaScript supports behavior such as interactions and standard site components. Code export is a paid Workspace feature, separate from buying a Site plan.

Those files can help you inspect the current markup, styling and behavior. They can also be a reference when checking the rebuilt version.

What happens to CMS pages

A CMS Collection export is not the same as a code export. Webflow's code ZIP does not include a working CMS or populated Collection pages: Collection Lists are empty and CMS-bound template content is missing.

Export the content separately and document the model behind it. The CMS API provides a separate route to collection and item data.

For planning, keep four things together: each source item, its identifier, its relationships and its intended URL. A list of titles is not enough to reconstruct references or confirm that the right pages were created.

What happens to interactions and integrations

Some existing behavior can run with the exported JavaScript. A deliberate Astro rebuild may instead recreate that behavior in a different implementation. That is a choice about dependencies and maintainability, not proof that interactions cannot export.

Treat connected services separately. Native form processing, search and other hosted functionality do not become independent services just because the site's files have moved.

List the destination for each important operation. For a form, that includes validation, submission, the receiving system, field values and notifications. For analytics, it includes event names, consent behavior and the reporting destination.

How the export becomes an Astro project

The useful question is not whether exported code can be edited. It can. The question is whether carrying the current structure forward is the best foundation for the work your team needs to do.

A rebuild can separate repeated layouts into components, define routes intentionally, and give content a model and an editing workflow. It should also decide which existing scripts are retained, replaced or removed.

Keep those decisions visible in the scope. An export-assisted rebuild, a visual redesign and a content-platform migration are not interchangeable jobs.

What to collect before rebuilding

Keep a source package alongside the export. It should contain the CMS data and field map, the URL inventory and redirect history, the assets and their references, the integration list, and examples of responsive behavior that need to survive.

Include published and unpublished states where they matter. Record content changes that happen during the rebuild so a later import does not overwrite newer work.

A small mapping sheet is more useful than an unannotated folder:

This is a proposed working artifact, not a claim that the ZIP contains each source above.

Separate four different source packages

The phrase Webflow export can refer to different things. Before estimating a migration, identify which source material is actually available and what each part proves.

The code package describes the current implementation of exportable pages and behavior. Collection data describes content records and fields. A route inventory describes public addresses and their intended outcomes. An integration inventory describes services and operations that do not become portable just because files were downloaded.

Keep those packages connected. A collection item without its intended route is difficult to reconcile against the website. A form element without its receiving service describes appearance but not the business function. An image file without the record or page that uses it can be copied successfully and still disappear from the migrated site.

Audit dependencies before deciding what to reuse

Some exported code may be worth retaining temporarily. Some may be a useful reference but a poor long-term structure. Make that decision at the level of the feature or component rather than declaring the entire export either valuable or useless.

For each script, identify what it provides, where it runs and what other code it expects. For each style group, identify the layout or visual pattern it supports. If a feature depends on a runtime, document that dependency and test the behavior in the intended destination environment.

A deliberate rebuild can reduce duplication and make future changes clearer. It can also introduce regressions if the original behavior is not understood. Keep screenshots, interaction notes and representative content as evidence while the implementation changes.

The question is not whether the new source looks cleaner in isolation. It is whether the team can maintain the site and preserve the behavior the business still needs.

Walk one collection item through the move

Take a hypothetical article with a title, slug, author reference, hero image, body and publication state. Export the record and identify the author's source ID. Map both records into the destination model so the relationship remains explicit.

Convert the body into the format the new renderer supports. Check inline images, links and any unusual blocks. Move or deliberately retain assets according to the storage plan, then update the relevant references. Generate the article at its intended URL and compare the result with the source.

Finally, have an editor change the article through the proposed publishing workflow. A record that renders once is not the same as content the team can comfortably maintain. This complete path is a better proof of the migration approach than opening the downloaded ZIP.

Use the sample to discover exceptions before processing every record. If the article includes an unsupported table, agree its destination representation and renderer instead of letting the conversion silently discard it.

Preserve behavior without importing every historical workaround

Custom code often contains both useful business logic and compensations for earlier constraints. A migration is a chance to separate them. A form-field transformation may still be required by the CRM. A script that rearranges markup after load may no longer be needed when the component renders the intended structure directly.

For each piece, record keep, adapt, replace or retire, with a reason. Retiring behavior should be a conscious product decision. Replacing an implementation should retain the expected outcome unless the scope explicitly changes it.

Test the destination of important actions. A contact form needs a complete receiving record, not merely an animated confirmation. A search control needs relevant results from the intended index. An analytics event needs the agreed name and values in the reporting system.

Decide when it is safe to retire the old setup

Do not use an assumed CDN expiry date as the retirement plan. Verify whether the new pages still depend on source assets or services. Request important images and downloads from the deployed destination and inspect where their references point.

Keep the source material and recovery path available for the agreed transition period. Confirm that the final content changes were captured, the new publishing workflow is in use and the business-critical integrations have been checked. Then make subscription changes according to the account and service requirements involved.

The export reduces uncertainty about what exists. The migration process decides what the new site should contain and proves that it arrived. For an implementation view of the same work, read the migration in code.

Can the export be the final production site?

An exported site and an Astro rebuild are different deliverables. If the requirement is simply to host eligible static files elsewhere, assess that narrower option on its own terms, including the hosted features that need replacement. If the requirement includes reusable components, an editorial model and a maintainable development workflow, scope those outcomes explicitly. Choosing Astro should follow those requirements rather than turning a file download into an assumed framework migration.

The export is the starting point

Use the files to understand what exists. Use the inventory to decide what moves. Use explicit checks to confirm what arrived.

See what a Webflow to Astro migration includes, including the work around the code export.

Sources

• Webflow: Export site code. Checked September 18, 2026.
• Webflow: CMS API. Checked September 18, 2026.