Can You Host a Webflow Site on Netlify? What Actually Happens

You can host the static export of a Webflow-built page on Netlify, but you cannot host a live Webflow project there. Webflow’s CMS, its form backend and its site search are services that run on Webflow’s own servers, and exporting the code detaches the page from all three at the moment of export. What travels to Netlify is HTML, CSS and JavaScript, frozen as a snapshot. Every later edit inside Webflow’s designer needs a fresh export and a fresh deploy, which is the real cost of running both, and the reason most people who ask this question end up picking one platform for the long term rather than round-tripping between them.

Webflow sells its own hosting, so landing on Netlify while still thinking in Webflow’s terms means comparing two products that do different jobs. This post covers exactly what an export keeps and drops, the two setups worth considering when the CMS matters, and the DNS steps either path needs once a real domain is involved.

Table of contents

• What exporting a Webflow site actually does
• What breaks in the export: CMS, forms, search
• Keep Webflow hosting, and stop fighting the platform
• Headless Webflow CMS with a static generator, deployed to Netlify
• DNS: pointing a domain at either platform
• Which setup actually fits
• How this fits the rest of the stack
• FAQ

What exporting a Webflow site actually does

Webflow’s Export Code feature, available on paid site plans, packages the current state of a project into a zip of static HTML, CSS and JavaScript. Unzip it, and it is a folder Netlify will happily serve: drag it onto Netlify’s deploy target, or push it to a Git repository and connect that repository, and the pages render exactly as they looked in the Designer at export time. For a portfolio, a marketing page or anything that does not change often, this is a legitimate way to get Webflow’s visual design tooling with Netlify’s deploy pipeline and pricing underneath it.

The catch is in that phrase ‘at export time’. Webflow’s Designer keeps editing the live project on Webflow’s own servers. Nothing about publishing a change in the Designer touches the exported zip sitting in a Netlify deploy. Someone has to notice the project changed, run the export again, and redeploy the new folder. There is no webhook, no CMS API polling, no built-in sync between the two - it is a manual step every single time, which is fine for a site that ships once and barely changes, and a real liability for one that does not.

Webflow Designer  --(Export Code)-->  static.zip  --(deploy)-->  Netlify
     ^                                                                |
     |_________________ no connection back, ever ______________________|

What breaks in the export: CMS, forms, search

Three Webflow features are backed by Webflow’s servers rather than by markup, and all three stop working the moment the export leaves Webflow’s hosting.

• CMS Collections. Dynamic lists, filtering and pagination render at export time as static HTML for whatever items existed then. New items added in Webflow’s CMS after that point never appear on the exported copy, because there is no live connection back to Webflow’s database.
• Forms. Webflow’s native form handling posts to Webflow’s own submission endpoint, which processes, stores and can email the result. That endpoint is not part of the exported files, so a form left as-is on Netlify submits into nothing and the visitor sees an error or a silent failure.
• Site search and Ecommerce/Membership. Site search depends on Webflow’s index. Ecommerce and Membership do not export at all; they are excluded from Export Code entirely.
• Interactions. The one piece of good news: Webflow’s IX2 interactions are compiled to plain JavaScript and largely survive the export, since they do not depend on a live connection back to Webflow.

A Netlify support guide and threads across Webflow’s own community both land on the same advice: if the CMS is decorative, export and move on; if the CMS is load-bearing, plan for one of the two setups below instead of exporting.

Keep Webflow hosting, and stop fighting the platform

The plainest answer for anyone whose Webflow project still needs its CMS, forms or membership features live is to leave the site on Webflow’s own hosting. Webflow sells hosting as part of the same product that runs the Designer specifically so the CMS, forms and publishing pipeline stay connected without a manual export step. Moving to Netlify does not remove that dependency, it just adds a second platform to keep in sync with it.

This is worth stating plainly because a lot of the traffic asking this question is really asking a pricing question, not a technical one. If the actual goal is a cheaper bill rather than Netlify specifically, exporting a CMS-backed site to work around it usually creates more maintenance than it saves, because someone now owns the re-export step forever.

Headless Webflow CMS with a static generator, deployed to Netlify

The setup that keeps a working CMS and still deploys to Netlify treats Webflow purely as a content source. Webflow’s CMS has a documented API; a static site generator - Eleventy, Astro, Next.js in static export mode, Nuxt - fetches the collection items at build time and renders the pages, and that generator’s output is what deploys to Netlify. A rebuild, triggered by a webhook when the Webflow CMS content changes, replaces the manual export-and-redeploy step with an automated one.

This is real engineering work, not a toggle. It means rebuilding the Designer’s layout in code, replicating whatever interactions the generator does not already give you, and wiring the webhook so publishing in Webflow actually triggers a new Netlify deploy. It suits a team that wants Webflow’s editing experience for content owners and Netlify’s git-based deploy workflow for developers, and is overkill for a small site a single person maintains.

# rough shape of the rebuild trigger
curl -X POST -d '{}' "https://api.netlify.com/build_hooks/YOUR_HOOK_ID"
# fired by a Webflow "site publish" webhook, so editing content
# in Webflow kicks a fresh static build instead of a manual export

DNS: pointing a domain at either platform

Whichever path wins, the domain work looks similar. Both Webflow and Netlify want either an A record pointing the apex domain at their edge IP, or full nameserver delegation if you use their managed DNS, plus a CNAME for www pointing at the platform’s hostname. The certificate is issued automatically once the records resolve and validation passes - neither platform expects a certificate to be uploaded manually for a standard custom domain.

The part people get wrong is running both setups at once: pointing the apex at Webflow and a subdomain at Netlify, then forgetting which one is live. Decide which platform serves the domain that visitors actually type, update the records once, and let the losing platform’s copy live at a subdomain or not resolve publicly at all, so there is exactly one place traffic can end up.

Type    Name    Content                    Notes
A       @       <platform edge IP>         apex domain
CNAME   www     <platform hostname>        e.g. yoursite.netlify.app

Which setup actually fits

For a static marketing page, a portfolio, or a site that changes rarely: export it, host it on Netlify or on a static site host, and accept that a change means a re-export. For anything with a CMS content owners edit weekly, forms that need to actually deliver mail, or membership gating: keep the project on Webflow’s own hosting rather than exporting, or invest properly in the headless setup and treat it like the software project it is. The middle option - exporting a CMS-heavy site once and hoping nobody notices it stopped updating - is the one that quietly loses a client’s trust.

The same headless architecture question comes up with other CMS-plus-generator stacks, not just Webflow, and it always resolves the same way: the generator’s output is a static site, and a static site needs somewhere to build and serve it. That is true whether the generator pulls from Webflow’s API, a headless WordPress install (see WordPress on Netlify for the equivalent breakdown), or any other content source - the hosting side of the decision does not change with the CMS.

How this fits the rest of the stack

The honest version of this decision is rarely about Netlify versus Webflow on price - it is about who owns the re-export step and whether the CMS is load-bearing. A build pulling from an API, a webhook-triggered rebuild, and a deploy target that does not care where the content came from is the same shape whether the source is Webflow, WordPress or a flat file. The RunxBuild hosting calculator prices a static build from a repository the same way regardless of what generates it, with custom domains and certificates handled the way the DNS section above describes.

Useful related references:

• WordPress on Netlify: What Headless Actually Means, the Three Ways to Do It, and What Breaks
• Headless Architecture: When Splitting the Frontend Is Worth It
• Jamstack Website in 2026: What the Term Still Means, and Where the Backend Goes
• Custom domains and certificates on RunxBuild

FAQ

Can I host a Webflow site on Netlify for free?

You can host the static export for free on Netlify’s free tier, but that copy has no working CMS, forms or search - those are Webflow-hosted features that do not travel with an export. If the project needs them live, either keep it on Webflow’s own hosting or build a headless setup that pulls from Webflow’s CMS API at build time.

Does Webflow CMS work after exporting to Netlify?

No. CMS Collections render as static HTML frozen at the moment of export. Items added or edited in Webflow afterward never appear on the exported copy, because the exported files have no live connection back to Webflow’s database.

Why did my exported Webflow form stop working on Netlify?

Webflow’s native form handling submits to a Webflow-hosted endpoint that is not included in the exported files. Off Webflow’s hosting, that endpoint no longer exists, so the form needs a replacement submission handler before it will deliver anything.

What is the alternative to exporting a Webflow site?

Using Webflow as a headless CMS: a static site generator fetches content from Webflow’s CMS API at build time and deploys its own output, usually to Netlify or a similar platform. A webhook triggers a rebuild when content changes, replacing the manual export-and-redeploy cycle.

Do Webflow interactions survive the export to Netlify?

Mostly yes. Webflow’s IX2 interactions compile to plain JavaScript that runs client-side, so they generally keep working after export. What breaks is anything backed by a live Webflow service - the CMS, forms, search, ecommerce and membership.