BlogContact

How I Self-Host a Webflow Site After Exporting CMS Content

I have seen Webflow projects get stuck in the same place: the design is done, but the hosting plan is either too expensive, too rigid, or owned by the wrong team. If you only need to keep the site moving and host it somewhere else, exporting it is usually the cleanest path. The part people miss is that a Webflow export is not a clone of the live CMS experience. Webflow’s own docs make the split pretty clear: code export gives you HTML, CSS, JavaScript, and assets, while CMS content is exported separately as CSV.
If you are still deciding whether export is the right move, I’d start with How I Decide When a Webflow Site Should Be Exported first. It will save you from turning a good CMS site into a bad static one.
What you’ll learn
  • What Webflow export includes and what it leaves behind
  • The checklist I use before I download anything
  • How I treat CMS content, hosting, and sync destinations
  • Where ExFlow fits when I want a static downloadable copy without rebuilding the site

What Webflow export actually gives you

The official Webflow update about exporting clean HTML5 and CSS3 says exported code contains pages, CSS, JavaScript, and images. The same docs also spell out the things that do not travel with the ZIP: CMS content, user accounts, ecommerce data and functionality, password protection, forms, site search, localization, and code components. That is not a bug. It is the boundary between Webflow’s hosted runtime and a static site bundle.
The separate Webflow update about exporting CMS content as a CSV is useful here too, because it makes the CMS split explicit. You can export Collection items as CSV to back them up or move them elsewhere, but that CSV is still just data. It is not the same thing as the live CMS running on Webflow.
If you export a site and expect dynamic Collection pages to behave exactly the same, you will end up debugging the wrong problem. On an exported site, Collection lists can fall back to an empty state because the CMS data is no longer driving them. I learned to think of export as packaging, not migration.

My export checklist before I touch hosting

I check these things in this order:
  1. Decide whether the site needs dynamic Collection pages after export. If yes, export is only step one.
  2. Clean up links, slug names, and page structure before I touch the ZIP.
  3. Audit custom code in head and body. Anything important needs to survive outside Webflow.
  4. Decide what happens to forms, search, localized pages, and password-protected areas.
  5. Confirm image handling. If I want a stable static bundle, I want all assets included and named predictably.
  6. Pick the destination before I export. Git, S3, FTP, or an ExFlow-hosted site all imply different deployment habits.
  7. If the site needs repeated exports, make the export settings repeatable instead of treating them like one-off toggles.
That is also why the ExFlow settings matter. I like the fact that it can export a Webflow site by URL, include CSS, JS, images, media, and all pages, remove the “Made with Webflow” badge, add custom script and style files, and sync to Git, S3, or FTP. When I am moving a real project, I want the checklist to be boring and complete.

How I handle the CMS piece

If the CMS matters, I treat the export CSV as a backup and a migration source, not as a finished destination. The official docs say you can export collection content to CSV and move it into other Webflow sites or other platforms. That is useful, but the target still needs a place to live.
This is the part where a lot of Webflow export tutorials get vague. A static export is great for marketing pages, but it is not a drop-in replacement for a CMS-powered publishing workflow. If your team wants a cleaner content pipeline, I’d look at How I Build a Clean Notion-to-Webflow Publishing Pipeline With SyncFlow and How I Prevent Notion-to-Webflow CMS Drift After Launch. Those posts are about Webflow as a publishing system, not just a page builder, and the distinction matters once content starts moving on schedule.
For the CMS handoff side, I wrote a separate walkthrough in How to Map Notion Fields to Webflow CMS Without Breaking Formatting. That is the more literal companion when the content model matters.

The hosting choices I use

When the site is exported, I choose the destination based on who will own updates:
  • Git if I want change history and a real deployment pipeline.
  • S3 if I want simple, cheap static hosting.
  • FTP if I am inheriting an older server and just need the files delivered.
  • ExFlow hosting if I want the export and the hosting handoff in one place.
The practical check is simple: load the exported homepage, a deep page, and any collection-style page. Then test asset paths, navigation, and any forms or search features you expected to survive. If those features matter, export may still be useful, but only with a plan for replacing the missing runtime pieces.

When I do not export

I do not export just because I can. If the site depends on live CMS behavior, memberships, ecommerce, localization, or password-protected content, the export boundary is too expensive to ignore. In those cases I either keep the site in Webflow or redesign the content model before moving.
That is why I like having a decision post next to the implementation guide. If you want the decision tree first, read How I Decide When a Webflow Site Should Be Exported. If you already know the answer is yes, export becomes a logistics problem instead of a philosophical one.

Why ExFlow fits this workflow

ExFlow is useful because it speaks the language of export rather than pretending Webflow is a generic static host. It can export a Webflow site by URL, include CSS, JS, images, media, and all pages, remove the badge, add custom script and style files, sync to Git, S3, or FTP, and host the result. That makes it a decent fit when you need a downloadable static copy and a place to put it without rebuilding everything from scratch.
I would still review the output before treating it as final. The point of the tool is to reduce the manual work, not to remove judgment from the process. For me, the best setup is: export once, verify the bundle, choose the hosting path, then automate the repeatable part.

Bottom line

If your Webflow site is ready to leave the platform, do not start with the host. Start with the export boundary. Separate the static files from the CMS data, decide what you are preserving, and then choose Git, S3, FTP, or ExFlow hosting based on how much control you want.
If you want a quick next step, export one real page, open the ZIP, and verify the assets and page links before you move the whole site. If you want the same workflow with less manual handling, start with ExFlow and use it to package the site the right way.