What Actually Breaks When You Export a Webflow Site (Measured on Real Sites)

Most "how to export Webflow" guides describe the happy path: click export, download ZIP, upload somewhere. That path exists. It is also not where the time goes. The time goes into the things that look fine in the ZIP and turn out to be broken when a real visitor lands on the real page.

We build an export engine, so we see this at volume. Below are six failures we found on real Webflow sites — not hypotheticals, each one traced to a specific page, with what it looked like, why it happened, and what a correct export has to do about it. If you're exporting Webflow yourself, this is the checklist. If you're evaluating a tool, these are the questions to ask it.

1. Forms ship pre-disabled by Cloudflare Turnstile — and stay dead

Webflow's form spam protection uses Cloudflare Turnstile. When a Webflow page loads, the submit button is rendered disabled, and Webflow's runtime re-enables it only after Turnstile hands back a token.

We saw a real export ship this exactly:

<input type="submit" value="SUBMIT INQUIRY" disabled="">

The form looked perfect. It was also permanently dead. A Turnstile sitekey is bound to the domain that issued it, so on a self-hosted copy the challenge can never return a valid token — the button never re-enables. Nothing in the visual export tells you this. The visitor clicks; nothing happens.

Worse, simply removing disabled from the HTML is not enough. If Webflow's runtime is still present, it reads the data-turnstile-sitekey attribute off the form, puts the wrapper into a loading state, and disables the button again on load. The attribute is the trigger. A correct export has to strip the Turnstile residue document-wide — the sitekey attribute, the .cf-turnstile widget, the hidden cf-turnstile-response input, and the loader script — before anything else touches the form. Then re-enable the submit control. Only then does the form work.

2. Every form is stamped method="get", so it silently never wires up

This one hides behind the first one. Webflow ships every form block with method="get", because its own runtime intercepts submit and POSTs over AJAX. The attribute is a leftover from the builder, not intent.

But if your export tool treats form attributes as meaningful — which any tool has to, because a genuine GET search form must not be hijacked — it will read method="get" and conclude "this is a search form, leave it alone." We had exactly this: a real export with two forms, both method="get", and our own second-phase form wiring skipped both. The destination the user picked in the wizard — Formspree, Netlify, a hosted endpoint — was silently never applied. No warning anywhere in the ZIP.

The fix is to force POST on Webflow forms unconditionally, then distinguish a real GET form (one whose action points at an actual endpoint) from residue (an action that's empty or #). Webflow's residue has no endpoint; submitting it just reloads the page with the fields appended.

3. An export can "succeed" with every page degraded

Our worst finding, and the one that changed how we report results.

A ten-page Webflow export finished, reported Pages: 10, and delivered a ZIP. Every one of the ten pages had fallen back to raw captured DOM — the pipeline had hit an error on each and, rather than fail, written the unprocessed HTML and moved on. Ten out of ten degraded. Status: success.

The rule we took from it: a fallback that still writes a file must never report success on its own. A degraded page is written, yes — a raw page beats no page — but it is counted separately, the ZIP's README grows a Warnings block naming every one, and if every page degraded, the export fails outright. "It downloaded fine" must never again be able to mean "every page is raw captured DOM."

If you're evaluating an exporter, ask it: what happens when the pipeline can't process a page? If the answer is "it still succeeds," find out how you'd know.

4. Webflow's badge is injected at runtime, not served

If you're building or auditing an exporter, this one matters. The "Made in Webflow" badge is not in the HTML Webflow serves. It's added by Webflow's JavaScript after load. So:

• A tool that fetches the raw HTML and strips the badge finds nothing to strip, and the badge reappears the moment the runtime runs on the exported page.
• A tool that detects Webflow by looking for the badge in the served HTML — a common shortcut — doesn't find it either.

Which leads to the next one.

5. Webflow's detection signals have quietly moved

Three things that used to identify a Webflow site have changed underneath everyone:

• The badge is runtime-injected (above).
• The CDN moved. Assets used to come from assets.website-files.com; current sites serve from cdn.prod.website-files.com.
• webflow.js was split into hashed chunks — webflow.schunk.<hash>.js — so a check for webflow.js in a script src finds nothing.

We measured a real, current Webflow site against a detector built on the classic signals and it scored exactly 30 — the bare minimum threshold — on the generator meta tag alone. Strip that one <meta name="generator" content="Webflow"> tag and the site reads as "not Webflow," and every Webflow-specific step (runtime handling, form rewriting, Interactions recovery) switches off silently.

The durable replacement is what Webflow's own hydration depends on: the data-wf-site and data-wf-page attributes on <html>. Webflow can't drop those without breaking itself. If your tool detects platforms, that's the signal to key on — and the lesson generalizes: platform fingerprints rot, so measure them against live sites rather than trusting a list.

6. Interactions do survive — if you keep the right runtime

Good news, and a correction to a claim we nearly made ourselves. Webflow's Interactions (IX2) — scroll-triggered reveals, hover states, click animations — do survive export, when the runtime that drives them is kept and re-initialized on the exported page. We once believed a real site's export was reproducing "1 of 27" scroll animations. It turned out the browser we were checking in was 439 pixels wide; at 1440 pixels the exported page hit exact parity with the original.

Which is its own finding: when comparing animation fidelity, control the viewport first. Most scroll and hover behaviour is breakpoint-gated, and a narrow test window makes a perfect export look broken.

The checklist

If you export a Webflow site — with any tool, including Webflow's own paid export — check these on the hosted result, not the ZIP:

1. Submit a form. Does the button respond? Does the submission arrive anywhere?
2. View source on the form. Is method still get? Is there a data-turnstile-sitekey left behind?
3. Open the README or log. Does it say how many pages were processed versus degraded — or only how many were "exported"?
4. Load the page with the network tab open. Does anything still call website-files.com or webflow.com?
5. Resize to a real desktop width before you judge animations.

Every item on that list came from a real export that looked finished and wasn't. If you'd rather not run the checklist by hand, the Webflow exporter handles all six — that's where these findings came from.

Related

• Can you export Webflow code? — the direct answer, and native export vs exporting the published site
• Webflow vs hand-coding — when leaving makes sense at all