Webflow Export Code: What You Actually Get (And What You'll Rebuild)

1. "Can we just export the code?"

2. "Will the export give us a real codebase we can ship?"

Yes to the first. No to the second. Here is what you actually get, what you don't, and how to think about the move if Webflow has stopped being enough.

What Webflow's export includes

On a paid Site plan, Webflow lets you export a ZIP containing:

• Static HTML for every static page

• Compiled CSS (Webflow's utility-style output)

• JavaScript for interactions, animations, and lightbox behaviour

• Images and assets referenced in the site

That is a working static website. Drop it on any host and it renders.

What Webflow's export does not include

This is the part that catches teams out:

• CMS content does not export. If you have Collections powering blog posts, case studies, team pages, product listings, or anything dynamic, the exported HTML captures a snapshot only. New posts do not appear. Editors have nowhere to log in.

• Forms stop working. Webflow's form handler lives on Webflow's servers. Exported forms POST to a URL that no longer accepts you.

• Ecommerce does not export at all. If you use Webflow Ecommerce, the cart, checkout, and product management are Webflow-only.

• Memberships, user auth, and gated content do not export.

• CMS hosting features like scheduled publishing, content localisation, and the editor UI are gone.

You get a snapshot of the marketing site. You do not get a system.

When exporting Webflow code is the right move

Three scenarios where the export ZIP is genuinely useful:

1. Archiving a site you're retiring. You want the HTML on record.

2. Handing static pages to a developer to integrate into a larger app. Common for teams whose landing page lives in Webflow but whose product is a React app.

3. A brochure site that will never need dynamic content again. Rare, but real.

For everything else (a marketing site with a blog, a site with lead-gen forms, a site with any editor workflow), the export is a false economy. You will spend more rebuilding the missing pieces than you saved.

When exporting is the wrong move

If any of these are true, exporting is not your answer:

• You have a CMS Collection with more than 20 items

• Editors add content weekly and cannot lose the editor UI

• The site has forms that route to CRM or email

• You have SEO you cannot risk breaking

• You need custom logic Webflow won't let you write (typed data, complex conditionals, API integrations, private routes)

At that point you are not exporting. You are rebuilding in a real codebase. Usually Next.js with a headless CMS like Sanity behind it, so editors keep their editing experience and engineering gets a proper development environment. (If you're on Framer rather than Webflow, the same logic applies. See Framer to code.)

What "moving to code" actually looks like

For most sites we migrate off Webflow, the target stack is:

• Next.js for the front end (React, TypeScript, deployed to Vercel or similar)

• Sanity or Contentful as the headless CMS (editors keep a UI, content becomes structured data)

• Vercel or Netlify for hosting, previews, and deploys

• Existing forms re-pointed to the CRM directly or to a form service (HubSpot forms, Formspree, custom API route)

You get:

• A codebase your engineers can work in

• Type safety on your content

• Faster performance (Next.js static generation runs circles around Webflow hosting on TTFB)

• No monthly Webflow ceiling

• Full control of routing, redirects, middleware, and analytics

The honest cost picture

An export ZIP is free. A proper migration to Next.js plus a headless CMS is not. For a typical funded team with a marketing site plus a blog plus a few dynamic pages, the rebuild sits in a defined range and takes a few weeks, not a few months. What you save monthly on Webflow adds up, but the real ROI is that you stop hitting the ceiling every time marketing wants something new.