DEV Community: Steve Smith

Everything that breaks when you mirror a Webflow site (and the fixes)

Steve Smith — Thu, 11 Jun 2026 00:13:09 +0000

Webflow's code export has two problems. It is only available on paid Workspace plans, and even when you pay, it does not include your CMS content: collection lists export as empty states, collection pages export with nothing in them. If your site has a blog, the export gives you a site without a blog. Forms and search are disabled in exported code too, per Webflow's own docs.

Meanwhile, the published site is sitting on a CDN, fully rendered. Every CMS page is real HTML. wget --mirror will happily fetch all of it.

What wget gives you, though, is not deployable. I migrated a production Webflow site this way and hit the same five breakages everyone hits, so I turned the fixes into a Claude Code skill that runs the whole workflow. This post is the five breakages, because they are useful whether or not you use the skill, and they apply to Framer, Squarespace, and friends with different domain names.

Setup: the mirror itself

The one wget incantation that matters, because Webflow serves assets from a separate CDN domain and you have to tell wget to follow it:

wget --mirror --convert-links --adjust-extension \
  --page-requisites --span-hosts \
  --domains=yourdomain.com,cdn.prod.website-files.com \
  --no-parent https://yourdomain.com/

This downloads every page plus the CSS, JS, images, and fonts they reference, and rewrites URLs to relative paths. It looks complete. It is about 90% complete, and the missing 10% is invisible until the page renders blank.

Breakage 1: the page renders blank, console says "integrity"

The symptom: your mirrored page shows raw unstyled text or nothing at all, and the console says Failed to find a valid digest in the 'integrity' attribute.

The cause is subtle. Webflow ships its <link> and <script> tags with SHA-384 SRI hashes. wget's --convert-links rewrites URLs inside the downloaded CSS files, which changes their bytes, which means the SRI hash no longer matches, which means the browser silently refuses to apply the stylesheet. The file is right there. The browser will not touch it.

The fix is to strip the integrity attributes (and crossorigin, which travels with them):

sed -i '' -E 's/ integrity="[^"]*"//g; s/ crossorigin="[^"]*"//g' *.html

This is the single most common cause of a "broken" migration, and no static file check will ever catch it, because every file exists and every reference resolves.

Breakage 2: the page still renders blank (webpack chunks)

Webflow's runtime is webpack-built and lazy-loads chunks named webflow.achunk.<hash>.js for sliders, animations, and interactions. wget never sees them, because they are loaded dynamically at runtime, not referenced in any HTML. When the entry bundle throws on the missing import, you get a blank page with a clean asset check. Again.

Each entry bundle embeds a chunk-id-to-hash map. Extract the hashes, fetch the chunks from the same CDN path, and drop them next to the entry bundles (webpack derives its public path from the entry script location, so no config needed). The skill does this with a small regex pass over the entry bundles; doing it by hand means searching for achunk in the runtime JS and pulling out the hash map object.

Breakage 3: zero-byte images with weird filenames

Webflow double-encodes special characters in CMS asset filenames. A file with a space ships as %2520 (the percent sign itself encoded), a plus as %252B, an ampersand as %2526. Decode once before fetching and the CDN 404s, and wget writes a zero-byte file without complaining.

Find them and re-fetch with the double-encoded URL:

find site/assets/images -empty -type f

Breakage 4: missing hero images (inline background-image)

--page-requisites follows src and href attributes. It does not parse inline styles, so every background-image:url(...) asset, which on a typical Webflow marketing site includes the hero, is simply not downloaded. Grep the HTML for background-image:url( references to the CDN, extract, fetch. Bonus breakage inside the breakage: --convert-links mangles these same inline URLs into nested-quote garbage that needs its own sed pass.

Breakage 5: fonts 404 after you reorganize

Webflow's CSS references fonts as url(../font.ttf), assuming Webflow's directory layout. The moment you consolidate into a sane assets/css/, assets/js/, assets/images/ structure, that relative path points at the wrong directory. One regex pass over the CSS rewrites them.

The skill that runs all of this

I packaged the whole thing, mirror, consolidate, rewrite, the five fixes, an in-browser verification pass, and deploy, as an open-source Claude Code skill:

npx skills add stevysmith/website-builder-migrate-skill

Then /website-builder-migrate https://yourdomain.com/ runs the seven-phase workflow. It is platform-agnostic with per-platform notes: Framer (React SPA, verify hydration), Squarespace (server-side image transforms), Carrd (trivial, single file), and Wix, which I will be honest about: heavily client-rendered Wix sites mirror badly, treat it as static-template-only.

Repo: https://github.com/stevysmith/website-builder-migrate-skill

Verify on a private URL before DNS moves

A migrated site needs checking against the original before anything public changes. Disclosure: I build Stacktree, which is the deploy target I added for exactly this step, because it is the only one that needs no account. The migrated folder publishes to a private, unguessable preview URL in one line:

(cd site && zip -qr ../site.zip .) && curl -F "file=@site.zip" https://api.stacktr.ee/sites

That preview lives 24 hours, which is enough to click through every page next to the original. When it checks out, deploy wherever you like; the skill's docs cover Render, Netlify, and Vercel too, and keeping the Stacktree one is a free tier away.

What stays broken, on every path

Forms (they need Webflow's backend; swap in Formspree or Basin), native site search (Pagefind is the static-friendly answer), and live CMS updates (the mirror is a snapshot; re-run the skill when content changes). Worth repeating: Webflow's official paid export disables forms and search as well, and does not give you the CMS pages at all. The mirror is not a downgrade. For static sites it is the more complete copy.

If you hit a breakage not on this list, open an issue on the repo. The list grew to five by exactly that process.

Give your AI coding agent a publish-HTML button (with MCP)

Steve Smith — Sat, 06 Jun 2026 22:22:54 +0000

Your coding agent writes HTML all day. A quick dashboard to eyeball some data. A PR writeup with a rendered diff. A status report, a Mermaid diagram, a one-off internal tool. Then what? You screenshot it into Slack, paste it into a gist, or spin up a Vercel project for a file you will delete tomorrow.

There is a verb missing from the agent toolbox: publish. Not deploy. Publish. One file in, one private URL out.

This post is about how to add that verb to any MCP-compatible agent, why "private by default" matters more than it sounds, and what the publish primitive looks like in practice.

The shape of the problem

A deploy is a project. It expects a repo, a build, a config, a domain. That is the right amount of ceremony for a product and far too much for the artifact-shaped output an agent emits dozens of times a session.

What an agent actually needs is closer to a paste-bin with teeth:

It writes a file. It gets back a URL. No project, no build step.
The URL is private by default, because agent output routinely embeds real data: API responses, customer rows, the prompt context itself.
When the agent revises the artifact, the same URL updates in place. You do not want 30 links from 30 iterations.

The Model Context Protocol (MCP) is the clean way to expose exactly this. If you have not used MCP, the one-line version: it is the standard every major AI assistant now speaks for calling tools, so a tool you expose once works in Claude Code, Cursor, Codex, Claude.ai, and the rest. (Longer primer: https://stacktr.ee/blog/mcp-servers-explained-for-developers)

The publish tool, conceptually

A publish-oriented MCP server needs one core tool and a few supporting ones. In MCP terms the action is a tool (model-controlled), the list of what you have published is a resource (the client reads it), and a saved "publish this privately" flow is a prompt (the user invokes it). If that tools/resources/prompts split is new to you, here is the breakdown: https://stacktr.ee/blog/mcp-resources-vs-tools-vs-prompts

The tool call itself is mundane, which is the point:

// the agent calls:
publish_html({ file: "dashboard.html" })

// it gets back:
{ "url": "https://stacktr.ee/p/3f9a2c7b1e", "expires": "24h" }

That is the whole interaction. The agent hands you a link. You send it to a teammate, who opens it with no account and no login.

Why "private by default" is the real feature

Public-by-default hosting made sense when humans hand-published finished pages. It is the wrong default for machine-generated HTML, because the agent does not pause to ask whether this particular file contains anything sensitive. It usually does.

Private by default flips the burden. The URL is unguessable, so the link itself is the credential. There is no directory listing, no search indexing, no crawl. If you need more, you add a layer: a shared password, or an email-domain gate so only @yourco.com addresses can open it. For the genuinely sensitive case, end-to-end encryption keeps the host from ever seeing plaintext.

None of that requires the agent to make a judgment call. The safe thing is the default thing.

Try it in one command

I build Stacktree, which is one implementation of this primitive: an MCP server for publishing HTML, private by default. Wiring it into your agent is a single command:

npx stacktree-install

It detects Claude Code, Cursor, Codex, OpenCode, and Amp, writes the MCP config for each, and the publish tools show up in your agent automatically. The first publish is anonymous and the link lives 24 hours, so you can prove it out before you even make an account.

It is MIT-licensed on the client side and listed in the official MCP registry as ee.stacktr/publish. Source for the server package: https://github.com/stevysmith/stacktree-mcp

The broader point

Whether or not you use Stacktree, the pattern is worth internalizing: as agents generate more artifacts, the missing infrastructure is not more compute or a fancier framework. It is small, sharp primitives that fit the agent loop. Publish is one of them. A file goes in, a private link comes out, and the agent can replace it in place when it iterates.

Happy Building!