Why Your Webflow Export Isn't Production-Ready

The Export Button Lie

Webflow's marketing says you can "export clean, semantic code." Let's put that claim under a microscope.

First, what the export actually contains. Webflow's own documentation lists it: HTML, CSS files, JavaScript, the images in your Assets panel, and Collection template pages with no content in them. It leaves out CMS content (Collection items and Collection lists), User Accounts, Ecommerce, password protection, form submission processing, reCAPTCHA, site search, and non-primary locales. Code export also needs a paid Workspace plan; Site plans alone don't include it.

Here's what you get when you open the files.

HTML: Div Soup

Open any exported HTML file. You'll see structures like this:

A <section> wrapping a <div class="container-2"> wrapping a <div class="div-block-47"> wrapping a <div class="w-layout-grid grid-3"> wrapping the actual content. Four levels of nesting for what should be a simple grid layout.

The class names are auto-generated and meaningless. div-block-47 tells you nothing about what the element does. A human developer can't maintain this efficiently, and an AI tool has nothing meaningful to reason about. It's technically valid HTML, but it's the HTML equivalent of spaghetti code.

CSS: Thousands of Lines of Bloat

The exported CSS is large because of how Webflow writes it:

• No tree-shaking. CSS for every page is included in a single file, even though most of it isn't used on any given page.

• Vendor prefixes everywhere. Webflow still adds -webkit- and -moz- prefixes for properties that modern browsers haven't needed for years.

• Scattered media queries. Instead of organizing responsive styles logically, each class gets its own breakpoint overrides spread through the file.

• Hardcoded values. Unless you set up Webflow variables, colors, fonts, and spacing are written out as literal values. Change your brand color and you're doing find-and-replace across the file.

JavaScript: Present, but Not Yours

The export includes Webflow's webflow.js runtime, and Interactions do run from it. That is the problem rather than the fix: every animation is stored as data inside that runtime and tied to data-w-id attributes in the HTML, so you can't edit an interaction without Webflow's Designer, and you can't safely remove the runtime without losing them all. Lottie animations need the files served from a web server, not opened locally.

What doesn't work at all once the site leaves Webflow's hosting:

• CMS content, filtering, and pagination (the Collection lists come out empty)

• Form submission handling (forms post to Webflow's endpoint)

• Site search and password-protected pages

• E-commerce (entirely server-dependent)

In other words, the export looks like your site and moves like your site, but anything that needs a server is gone.

Images: Unoptimized and Webflow-Hosted

Webflow exports images at their original upload size. No responsive variants, no WebP conversion, no lazy loading attributes. Images referenced from CMS content point at Webflow's CDN (cdn.prod.website-files.com), which belongs to your Webflow project. Don't build a new site that depends on those URLs staying up after you cancel: download every file and re-host it.

What "Production-Ready" Actually Means

A production-ready codebase has:

• Semantic HTML: meaningful tags (<nav>, <article>, <aside>) instead of generic divs

• Scoped, minimal CSS: only the styles each component needs, using modern features

• Component architecture: reusable, composable pieces with clear props and behavior

• Optimized assets: responsive images, lazy loading, modern formats

• Working interactivity: forms, animations, and dynamic content that run on your own stack

• SEO infrastructure: meta tags, structured data, sitemap, robots.txt

• Version control: Git history, meaningful commits, a review process

A Webflow export has almost none of these. It's a snapshot: a frozen picture of how your site looked, not how it works.

The Real Path to Production Code

The Webflow export is useful as a visual reference. Open it in a browser, screenshot every page, and use those screenshots as your design spec. Then close the exported code and don't build on it.

Your new codebase should be built fresh, using the design as a guide. Modern tools make this much faster than it sounds:

• AI tools like Claude Code can generate React components from screenshots and descriptions

• Tailwind CSS gives you a consistent design system without writing custom CSS

• Next.js provides the routing, rendering, and optimization layer out of the box

• Payload CMS gives you content management without vendor lock-in

• The CMS content itself comes out through the Webflow Data API as JSON, or as CSV per collection, then gets scripted into the new CMS (see the Webflow CMS content migration guide)

The build takes days, not weeks: most Webflow sites go live in 7 to 14 days. And the result is code that a developer, or an AI, can actually work with. That's the difference between an export and a migration.

Moving to GitHub Without Leaking Anything

There is no "transfer to GitHub" button. Pushing the export to a repository gives you version history for a dead snapshot. What you actually want in GitHub is the rebuilt site, and the repository should be locked down before the first real commit. The order that works:

1. Audit first. Count static pages, CMS collections and items, forms and where they submit, third-party scripts in project and page custom code, interactions, and any gated pages. This sets scope, and it tells you which secrets (form webhooks, API keys) the new code will need.

1. Pick the stack. Framework (Next.js or Astro for most marketing sites), host, and a CMS to replace Webflow's Collections.

1. Create the repository private, from the start. A public repo exposes your full source, commit messages, and any webhook URL or key that slips in.

1. Add `.gitignore` before the first commit. Exclude .env*, node_modules, build output, and OS files. Keys live in local .env files and in your host's environment variable settings, never in code.

1. Protect `main`. Require a pull request to merge, and block direct and force pushes. Note GitHub's plan gate: branch protection on a private repository needs GitHub Pro, Team, or Enterprise; on the free plan it is only available for public repositories.

1. Connect the host. Link the repo to Vercel, Netlify, or Cloudflare Pages with main as the production branch. Every push to main deploys, every pull request gets its own preview URL, and you review changes there before they go live. For a business site built by a developer or agency, Vercel's Hobby tier is not available: its terms limit it to non-commercial use, so use Vercel Pro or Cloudflare Pages.

1. Test on staging, then switch DNS. Get the preview or staging URL fully working, forms included, before the domain points at it.

Repository security checklist

1. Repository is private.

1. Branch protection is on for main: no direct pushes, pull requests required.

1. .gitignore excludes .env files, node_modules, build artifacts, and OS files.

1. No secrets in code: API keys, database URLs, and tokens are environment variables.

1. Dependabot alerts are enabled, so vulnerable dependencies get flagged.

1. Two-factor authentication is on for every account with repo access.

1. Access is minimal: collaborators get write, not admin; admin stays with the owner.

1. Production environment variables are set in the hosting dashboard, not in the repo.

The mistake that costs the most: committing a key. Once it is in Git history it stays there unless you rewrite history, and anyone who cloned the repo already has it. Rewriting is not enough on its own; rotate the key the moment you find it.