How to Export a Webflow CMS Site to Static HTML

If you built a marketing site in Webflow, the design work is only part of what you own. Your CMS pages, images, scripts, fonts, and redirects still need a plan when you want a backup, a client handoff, or static hosting. This guide walks through exporting a published Webflow CMS site to static HTML and preparing it for GitHub Pages. You need the public Webflow site URL, access to its domain settings, and a GitHub repository.

1. Decide what the static copy must preserve

Start with the live site, not the export tool. List the routes that matter: the home page, key landing pages, collection templates, several real CMS entries, the 404 page, and any campaign URLs. Then note features that need a different destination after a static export: forms, gated content, ecommerce checkout, and server-side search. A static copy can preserve pages and front-end behavior; it cannot create a new server-side service by itself.

For CMS sites, include both the collection template and representative entries. A template that looks correct at /blog/example-post is more useful evidence than a perfect-looking home page. This same inventory is useful for a Webflow restore-ready backup, because it tells you what to test before you need the copy.

2. Export the published Webflow URL with a platform-specific tool

Open the ExFlow Webflow exporter and enter the published URL. ExFlow is designed to collect the public site as static HTML, CSS, JavaScript, images, and CMS pages, then provide a ZIP or deployment/sync options. A generic downloader can be fine for a one-page brochure, but Webflow sites often depend on routed CMS pages, interaction scripts, lazy-loaded media, and linked assets that deserve a platform-aware export pass.

Choose the option to retain all pages and assets. If your destination benefits from explicit page filenames, enable .html extensions. When the export finishes, download the ZIP and keep it unchanged as your rollback artifact. Do not start editing it until you have made that original copy.

The expected result is a folder with an entry page, route folders or HTML files, stylesheet and script references, and local asset paths. If a CMS route is missing here, return to the live-site inventory before deploying anything.

3. Run a local route and asset check

Unzip the export into a clean working directory and serve it locally. From the folder, run:

python3 -m http.server 8080

Then open http://localhost:8080. Check the routes from your inventory, especially a few CMS URLs. Open browser developer tools and look for failed network requests. Test navigation, images, fonts, responsive layouts, animations, metadata, canonical tags, internal links, and scripts. Treat forms separately: record their destination and replace or reconnect them before expecting submissions to work on static hosting.

4. Put the static export in a GitHub repository

Create an empty repository, copy the validated export into it, and inspect the root before committing. For a simple Pages deployment, GitHub needs an index.html at the publishing root or in the configured /docs folder. Commit the files with a clear message:

git add .
git commit -m "Add exported Webflow static site"
git push origin main

In GitHub, open Settings → Pages, choose Deploy from a branch, select main, and choose the root folder (or /docs if you placed the export there). GitHub will provide the deployed URL. Visit it and repeat the route check, because a site can work locally while an absolute asset path or base URL breaks on a project Pages URL.

For a custom domain, add the domain in GitHub Pages first, then create the DNS record GitHub specifies. Verify both the apex and www behavior you intend to use, and only then update canonical URLs or redirects.

5. Compare the live site and the deployed copy

Use your original inventory as a short acceptance test. Compare page titles and descriptions, social preview metadata, navigation, CMS pages, images, font loading, mobile breakpoints, and interactive sections. Check redirects for old high-traffic URLs and make sure no internal link points back to an unfinished preview. Keep the ZIP and the Git commit together so you can reproduce the deployment later.

If you are planning a broader move, it helps to separate the export from the migration decision. A Squarespace static self-hosting workflow has different form and checkout constraints, while a Framer-to-GitHub-Pages deployment emphasizes animation and font QA. ExFlow also offers dedicated Squarespace and Framer exporters, but use the Webflow workflow when Webflow CMS routes are the main concern.

Common pitfalls

• Testing only the homepage: Test real CMS entries and pagination-like navigation, not just the template.
• Assuming forms are portable: A static export preserves markup, not necessarily the submission backend.
• Publishing before checking asset paths: Inspect the deployed page network panel for missing CSS, JavaScript, fonts, and media.
• Skipping the backup artifact: Keep the original ZIP before edits and commits.

You now have a portable Webflow CMS copy, a versioned repository, and a repeatable verification list. Start by exporting your published site with ExFlow for Webflow, preserve the untouched ZIP, and validate one CMS route locally before you deploy the full site.