Why HTTrack Breaks on Framer, Webflow and Wix Sites

HTTrack is a genuinely good piece of software. It has been mirroring websites since 1998, it is free, and on a site built the way sites were built in 1998 it works perfectly.

Modern no-code platforms are not built that way. If you have pointed HTTrack at a Framer, Webflow, Wix or Squarespace URL and got back a folder that renders as a blank page, a wall of unstyled text, or a layout with every breakpoint stacked on top of itself — this explains why, and it is not something you can fix with a different flag.

The one-sentence version

HTTrack saves the HTML the server sent. Your browser shows the HTML that JavaScript built afterwards. On a no-code site those are two different documents, and the interesting one only exists in memory.

What HTTrack actually does

HTTrack is an HTTP client with a link parser. For each URL it:

1. Requests the URL and saves the response body
2. Scans that body for href and src attributes
3. Queues anything it finds and repeats

That is the whole model. It never executes a line of JavaScript, because it does not contain a browser. It has no DOM, no layout engine, and no idea what the page looks like.

For a static site that is fine — the server's response is the page. For a React-rendered site it is not even close.

What that costs you, concretely

The layout CSS is missing

This is the one that produces "all my breakpoints are showing at once."

Framer ships responsive variants as separate DOM subtrees, hidden and revealed by @media rules that live in a <script id="__framer__breakpoints"> block or inside a data-framer-hydrate-v2 attribute — as JSON, not as CSS. A browser runs that script and the correct rules get injected. HTTrack copies the script tag as text and stops.

The result is a page where the mobile layout, the tablet layout and the desktop layout all render simultaneously, stacked. Nothing is broken in the file; the rules that would hide four of the five variants were never generated.

Computed styles never resolve

Framer applies a lot of visual styling at runtime — background colours, border radii, box shadows, backdrop filters, typography. Those values are computed by the framework as it hydrates, not written into the HTML the server sends.

HTTrack captures the pre-hydration markup, so those elements arrive with no styling at all. You get correct content in roughly the right order, looking nothing like the site.

Anything below the fold is missing

Most no-code platforms lazy-load images, and many load entire sections on scroll. HTTrack does not scroll, because HTTrack does not have a viewport. Images that were waiting on an IntersectionObserver never get requested, so they are never discovered, so they are never downloaded.

The same applies to anything behind a Load More button, a tab, or an accordion. If a click reveals it, HTTrack will not find it.

The platform's own junk comes along

HTTrack copies faithfully — including the "Made in Webflow" badge, the Wix Thunderbolt runtime, analytics beacons, and the tracking scripts the platform injected. You keep every kilobyte of overhead you were trying to leave behind.

There is a second-order problem here. The Wix runtime boots a Worker from the original site's origin. Once you host the copy somewhere else that request is cross-origin, so it fails with a SecurityError before the page hydrates. The copied file is not merely bloated; the leftover runtime actively breaks it.

Links still point at the old domain

HTTrack rewrites the URLs it discovered. Anything constructed in JavaScript — router links, dynamically built image sources, anything assembled from a template string — keeps pointing at the domain you copied from. The mirror looks self-contained until you click something and land back on the original site.

Why "just use a bigger flag" does not help

The usual advice is --mirror, deeper recursion, or a longer timeout. None of it changes the outcome, because the limitation is architectural rather than configurable. No depth setting makes an HTTP client execute React. wget --mirror, curl, Save Page As and browser extensions that dump document.documentElement.outerHTML all hit some version of the same wall.

Save Page As gets closest — it does have a real browser behind it — but it captures a single page, keeps the platform runtime, and does not rewrite internal links for offline use.

What a rendering exporter does instead

The alternative is to drive an actual browser and save what it drew. That is the approach NoCodeExport takes:

1. Load the page in a real browser, then wait for the platform's own hydration signal rather than a fixed timer
2. Scroll the full viewport height, which fires the lazy-loaders and trips the IntersectionObservers, and click through Load More controls
3. Wait for fonts, images and video to finish decoding
4. Read back the computed styles and inline them onto the elements that need them, so they survive the runtime being stripped
5. Reconstruct the breakpoint CSS as real @media rules, so only one variant shows at a time
6. Then serialise the DOM — the one the browser built, not the one the server sent

After that it is a normal static-site problem: rewrite the links to relative paths, strip the trackers and badges, download the assets, and package the result.

The interactive parts are handled separately. Sliders, tabs, accordions and scroll animations depend on the platform runtime that just got removed, so they are re-implemented in a few kilobytes of plain JavaScript instead. That is why an export can drop the Webflow runtime and still have working tabs.

When HTTrack is still the right tool

It has not stopped being useful:

• Server-rendered sites — WordPress without a heavy page builder, plain HTML, most documentation sites. The server's response is the page, so HTTrack gets it all.
• Archival crawls where you want the raw responses rather than a working copy.
• Anything you need to run offline, scripted, at scale, on sites you know are static.

If the site was built in Framer, Webflow, Wix or Squarespace, it is the wrong tool — not because it is old, but because it is solving a different problem.

Copying it properly, step by step

1. Confirm the page is built in the browser. Open the site, right-click, choose View Page Source, and search for a heading you can see on screen. If it is not in the source, JavaScript put it there — and HTTrack will not find it either.
2. Export from the published URL. Paste the live URL into a rendering exporter. It loads the page in a real browser, waits for hydration, scrolls to trip the lazy-loaders, and serialises the DOM the browser built.
3. Decide how assets are handled. Downloaded assets go inside the ZIP, so the copy is self-contained. Hotlinked assets stay on the original CDN and need the source site to remain online.
4. Serve the folder and check it. Do not double-click index.html — browsers block module scripts over file://. Run npx serve in the folder, then watch the console for errors, the Network tab for 404s, and resize the window to confirm only one breakpoint renders. Full instructions here.

Try it on your own site

The quickest way to see the difference is to run both against the same URL and open each result. Paste your site into the website code exporter and compare it to your HTTrack mirror.

If you are coming from a specific platform, these go deeper on what survives an export and what does not:

• Export Webflow to HTML
• Export Framer to HTML
• Export a Wix site to HTML
• What actually breaks when you export a Webflow site