Webflow Exporter logo
ResourcesContact
All resources

Exporting a Webflow CMS Site: What Actually Survives

The most common question I get from people using Webflow Export is some version of: "will my CMS come with it?"

The honest answer depends entirely on which export you mean. Webflow's native export gives you rendered HTML and nothing else — no collection schema, no item data, no references. That's where the long-running internet wisdom of "you can't really export a Webflow CMS" comes from.

Our tool is structured differently: it produces the rendered HTML and the raw CMS payload alongside it. That's what makes the rest of this article worth reading, because the practical CMS migration story depends heavily on which output you're working from.

Two completely different "CMS exports"

When someone says "Webflow CMS export," they usually mean one of two things:

  1. The rendered output — the HTML page a visitor sees at /blog/my-post, with title, body, image, and author already filled in.
  2. The CMS infrastructure — the collection schema, the items, the references between them, and the field metadata that a new CMS would need to reconstruct everything.

Webflow's native export only captures #1. The export I'll describe below captures both.

That distinction is the entire story. If all you have is #1, you're rebuilding the CMS schema by reading rendered HTML — slow, error-prone, lossy. If you have #2, you're importing structured data into a new system — usually a one-day job per collection.

The actual export structure

Here's what comes out of a real export run for a CMS-driven site (paths verified against the export route — abbreviated for clarity):

/index.html
/blog/announcing-v2.html        ← rendered page
/blog/how-we-built-x.html
/blog.html                       ← collection list page
/cms/
  posts/
    _schema.json                 ← full collection schema (fields, types, references)
    items.json                   ← every item with full fieldData
    md/
      announcing-v2.md           ← each item as Markdown
      how-we-built-x.md
    mdx/
      announcing-v2.mdx          ← each item as MDX
      how-we-built-x.mdx
  authors/
    _schema.json
    items.json
    md/...
    mdx/...
/assets/
  images/...                     ← every CMS-uploaded image
/seo.json                        ← per-page SEO + OG metadata
/forms.json                      ← form schemas
/assets-manifest.json
/manifest.json

A few things worth noticing:

  • The rendered HTML lives at the zip root, so you can drop the export straight onto Netlify or Vercel and it serves immediately.
  • The cms/ directory has every collection — schema and items and converted Markdown/MDX. References between collections are preserved as item IDs inside items.json.
  • seo.json separates the SEO metadata from the HTML, which is useful when you're rebuilding the site in a new framework and want to drive <title> and <meta> from data rather than re-parsing HTML.

This matters because the migration path is completely different depending on which of these files you start from.

CMS field types: what makes it across

Here's the practical behavior for each Webflow CMS field type, given the export structure above:

Field typeIn rendered HTMLIn items.jsonNotes
Plain text✅✅Identical content
Rich text✅✅HTML in items.json, rendered HTML on the page
Image✅✅Downloaded; both HTML and JSON point at local paths
Multi-image✅✅All images downloaded
Link✅✅Both forms
Email / Phone✅✅Both forms
Number / Date / Color / Switch✅✅Both forms
Option✅✅Option value preserved in JSON
File✅✅File downloaded
Reference✅ rendered✅ as item IDThe referenced item's data lives in its collection's items.json
Multi-reference✅ rendered✅ as item IDsSame — array of IDs you can resolve to items

The key shift versus native Webflow export: reference relationships survive. With native export, a reference field renders the linked item's fields into the HTML and the relationship is gone. With items.json in hand, you can rebuild the same many-to-many structure in Sanity, Contentful, Payload, or anything else.

What still doesn't transfer

Even with the full export, a few things break in ways that aren't obvious until you're in production:

  • Filtering and sorting on collection list pages. Webflow renders the initial state into the HTML. The dropdowns still appear but don't re-query anything. Rebuild these against items.json if you need them live.
  • Pagination past the first page. Webflow paginates client-side. If your list page shows 12 posts of 50, the HTML only contains 12 — but items.json contains all 50, which is what you want to rebuild against.
  • Search. Webflow's /search route is server-side. Replace with Pagefind, Algolia, or your CMS's built-in search.
  • The Webflow Editor. In-browser editing for non-technical teammates stops working the moment you leave Webflow hosting. Plan a replacement.
  • CMS API endpoints. If your stack hits Webflow's Data API directly, those calls will need rewriting.

Preserving SEO continuity (the part most teams miss)

Here's what I see go wrong most often when teams migrate a CMS-heavy Webflow site. None of these come from the export itself — they come from migration plumbing:

  1. Trailing slash mismatch. Webflow accepts /blog/post and /blog/post/ interchangeably. Netlify and Vercel pick one by default. Decide which form is canonical, set redirects from the other, and update <link rel="canonical"> to match. Get this wrong and you split ranking signal across two URLs.
  2. Meta tags driven by CMS fields. These render correctly into the exported HTML. But if your rebuild swaps to a different templating layer, double-check that per-item meta tags didn't get replaced with site-wide defaults. The exported seo.json is the safest source of truth for this.
  3. Open Graph images on Webflow's CDN. Webflow URLs (uploads-ssl.webflow.com/...) often appear in og:image tags. The export rewrites these to local paths, but verify your social previews after deploying.
  4. Structured data (JSON-LD). If you injected article schema via custom code, check it survived export and that @id / url fields point at the new domain.
  5. sitemap.xml. Native Webflow export doesn't regenerate this for the new domain. Build one from your routes — Next.js makes this trivial with a sitemap route.

Roughly two-thirds of "we exported and lost rankings" stories I hear trace back to one of these.

The rebuild path most teams take

If you're moving off Webflow's CMS but want to keep the editing experience for marketers, the pattern that works well:

  1. Export the site to capture both HTML and the structured cms/ payload. The rendered HTML is your SEO continuity insurance; the JSON/MDX is your data.
  2. Pick a headless CMS that fits the team. Common choices: Sanity, Contentful, Strapi, or Payload. For content-light sites, the exported MDX dropped into a Git repo is often enough on its own.
  3. Import directly from items.json. This is the part native-export users dread and tool-export users skip. Map your schema, run an import script, and you have your content in the new CMS with references intact.
  4. Wire the new CMS into a frontend framework — Next.js, Astro, SvelteKit. Match the existing URL structure exactly so existing inbound links and rankings hold.
  5. Deploy alongside the existing site on a staging URL, then cut over with 301s in place for anything that moved.

If you also want to skip the CMS rebuild entirely — say, the site is low-touch and content doesn't change often — the exported MDX files can be served directly by any Markdown-aware framework. Same content, no editing UI.

When you shouldn't bother

A few situations where I'd tell someone to stay on Webflow's CMS:

  • Marketing publishes multiple times per week. The friction of a deploy-on-every-edit workflow will outweigh the cost savings.
  • The site has very few CMS items. If your "CMS" is one collection with a handful of items, just stay on the platform or migrate to MDX files in a repo — a full CMS rebuild is overkill.
  • Ecommerce or memberships are in scope. These aren't really "CMS export" problems — they're full backend replacements. Different project, much bigger.

For everything else — content libraries, blogs, case studies, directories, knowledge bases, marketing pages with editable hero blocks — exporting and rebuilding the CMS layer is a reasonable move once the team is technical enough to manage the deploy workflow.

The version most people actually want

Realistically, most people asking "can I export my Webflow CMS site" are looking for one of three outcomes:

  1. Archive. Take a low-traffic site off recurring hosting. Static export, drop on Netlify free tier, done. The cms/ payload is your safety net in case you ever need to rebuild it.
  2. Migrate. Move into a different CMS and frontend stack. Export, import items.json into the new CMS, rebuild the frontend against existing URLs.
  3. Hybrid. Keep designing in Webflow, but host elsewhere. Export, deploy the static output to your chosen host, redeploy on changes. See where to host an exported Webflow site for the comparison.

All three work. The export is the same in each case — what changes is what you do with it afterward.

Worth reading next if you haven't: Webflow export vs Webflow hosting covers the broader cost/control tradeoff.

Further reading

If you want to see exactly what your CMS export will contain before paying anything, run a free scan — you'll see every collection, every item, and every asset that will end up in the zip.