How to QA a Webflow Static Export Before You Change Hosting

Changing the host for a Webflow site is rarely the risky part. The risk is treating a downloaded folder as proof that the site is ready.

Before changing DNS, cancelling a plan, or handing files to a client, run a small static-export QA pass. It catches the annoying failures that only become obvious after launch: a CMS route that 404s, a font that silently falls back, a form that points nowhere, or a redirect that disappears with the old host.

For a published Webflow site, ExFlow’s Webflow exporter is a practical starting point: it collects the site’s pages, CSS, JavaScript, images, media, and CMS pages into static output that you can download or sync to Git, S3, or FTP. The export is the beginning of the handoff—not the final check.

1. Make a route list before you open the export

Start from the public site, not from memory. List the homepage, top navigation, footer links, campaign pages, legal pages, and a few representative CMS items. Include old URLs that should redirect.

That route list becomes your acceptance test. Open every route on the static preview and mark it as one of three things: present, intentionally retired, or broken. Do not accept a “mostly working” menu; one stale navigation target is enough to make a move feel unfinished.

This is also the point to decide whether an export is even the right scope. If you need a long-lived archive, the route list can be lean. If the new static site will become production, give it the same care you would give any release. Our guide to archiving a retired Webflow CMS collection as static HTML is useful when preservation—not a host change—is the actual goal.

2. Inspect the files that make the page feel like itself

A page can load while still being wrong. Check more than HTML:

• Images and background media load at full page depth, not only above the fold.
• Fonts load without cross-origin errors or surprise substitutions.
• CSS and JavaScript requests return successfully.
• Webflow interactions, menus, sliders, and responsive states still behave as expected.
• CMS-derived pages have working images, titles, metadata, and internal links.

ExFlow is designed for the structure and assets produced by Webflow, which matters more here than it sounds. Generic downloaders may capture a simple page but miss lazy-loaded media, route variations, or supporting files that only surface in a real browse.

A useful spot-check is to test one route from each content pattern: a rich CMS article, a media-heavy landing page, a basic information page, and a page with an interaction. If those four survive, you have sampled the places static exports most often become deceptively fragile.

3. Treat forms and external scripts as separate work

Static HTML does not preserve every service behind a page. Write down every form, booking widget, analytics tag, cookie tool, map, chat button, and embed. For each one, answer a simple question: does it still have a live destination after the host changes?

Forms deserve the strictest test. Submit one harmless test entry and confirm it reaches the intended inbox or provider. Then test the thank-you state and any validation. A visually perfect form that has lost its endpoint is worse than a missing form because visitors cannot see the failure.

This is the caveat people skip when they rush a migration: exporting a page preserves the front end; it does not automatically recreate platform-connected workflows. Keep the old setup available until the replacement behavior is confirmed.

4. Test metadata, redirects, and the ugly URLs

Open page source or use your normal audit tool to confirm titles, descriptions, canonical URLs, social images, and robots directives are sensible on the static copy. Then test the URLs that are not in navigation: old campaign slugs, pages shared in sales decks, and common trailing-slash variations.

For the new host, prepare redirects before DNS changes. A small redirect map is cheaper than repairing lost links after launch. If you are moving a Framer project instead, the same discipline applies, with extra attention to animation and responsive behavior—see how to export a Framer site to GitHub Pages without breaking motion.

5. Rehearse the deployment and rollback

Deploy the static output to a staging URL first. Browse it on desktop and mobile, preferably in a private window. Keep a copy of the ZIP or Git revision you tested, and decide in advance how to roll back if a late issue appears.

ExFlow can leave you with a downloadable site or help sync the export to Git, S3, FTP, or a managed hosting path. Choose the destination that your team can maintain. A Git-backed deploy is helpful when you want reviewable changes; a simple ZIP is often enough for a client archive. If the deliverable is going to another person, pair the files with a short handoff note—the checklist in this Squarespace static HTML handoff guide transfers well.

A compact release gate

Do not change hosting until you can say yes to all of these:

1. Every planned route opens on the static preview.
2. Images, fonts, styles, scripts, and interactions load correctly.
3. Forms and embeds still have working destinations.
4. Metadata and redirects are ready.
5. A tested export or deploy revision is saved, with a rollback path.

When those answers are clear, the move becomes routine rather than hopeful. Start by exporting the published Webflow site with ExFlow, test the resulting static copy against your route list, and only then point traffic at the new host.

ExFlow also has dedicated exporters for Squarespace and Framer, but keep the first pass platform-specific: a Webflow release is safest when it is tested as a Webflow release.