Guide

Webflow CMS fields in Spectersync

By Axel Antas-Bergkvist Published June 3, 2026

Spectersync’s job is to keep your Webflow CMS and a clean, editable copy in your workspace perfectly in sync. That works because most of the Webflow CMS maps cleanly — but not all of it. This guide is the honest map of what round-trips losslessly, what round-trips with a known projection, and where Spectersync intentionally treats something as opaque so you don’t lose data on a publish. Webflow support is in beta, and this page is the detail behind that label. Subscribe now for 500 free credits when your workspace opens.

If you’re about to run a bulk edit and want to know what’s safe to touch and what to leave alone, this is the page.

How Spectersync represents an item

Each CMS item opens as one piece of clean, editable content. The structured fields — anything that isn’t the rich-text body — sit alongside the body, which is the item’s rich-text body converted to plain prose. Under the hood that’s a markdown file with frontmatter; in the workspace it’s just the item’s fields and its text. Here’s the shape:

---
collection: blog
itemId: 6512a0...
slug: launching-specter-for-webflow
name: "Launching Specter for Webflow"
draft: false
archived: false
publishedOn: 2026-05-28T11:17:37+02:00
author: 6471f3...           # reference field (item id)
tags: [launch, webflow]      # multi-reference field (item ids)
featuredImage: https://...   # image field (URL)
seoTitle: "Launching Specter for Webflow — CMS sync without the Designer"
seoMetaDescription: "..."
ogImage: https://...
---

# Launching Specter for Webflow

The rich-text body lives down here as standard markdown.

The field keys mirror the field slugs in your collection — if you renamed a field in Webflow, the corresponding key changes on the next sync.

What round-trips losslessly

These field types pull and push without information loss:

  • Plain text — name, summary, short text fields.
  • Slug — the item slug.
  • Switch (boolean) — draft, archived, and any custom switch fields.
  • Number — integers and decimals.
  • Date / DateTime — ISO-8601 strings.
  • Link — URL strings.
  • Color — hex strings.
  • Option — the option name as a string.
  • Reference — the referenced item’s id as a string. Multi-reference fields become an array of ids.

For these field types, “what you see in the Editor” and “what’s in your workspace” are equivalent. Bulk-editing them is safe.

What round-trips as a known projection

These field types are richer than plain fields, so Spectersync uses a defined projection in both directions:

  • Rich text — converted to plain prose on pull, converted back to Webflow rich text on publish. Headings, paragraphs, lists, bold, italic, links, code blocks, inline code, blockquotes, and images all round-trip cleanly. Tables round-trip as standard tables. The conversion is deterministic, so editing the text and publishing back will not produce a different rich-text body than the one you started with.
  • Image — Spectersync stores the image URL (featuredImage: https://...). Uploading a new local image file isn’t supported yet; you can swap the URL to one you’ve already uploaded to Webflow’s asset hosting.
  • File — same as image: stored by URL, swapped by URL.

For these, “what you see in the Editor” and “what’s in your workspace” are equivalent for the cases the projection covers. If your rich-text body uses a feature outside the projection (see the next section), Spectersync falls back to opaque handling rather than losing data.

What’s treated as opaque (safe by default)

These cases can’t be cleanly represented as plain text, so Spectersync doesn’t try — it preserves them verbatim and round-trips them as opaque blocks so you don’t lose data on a publish:

  • Embedded components inside rich text. Webflow lets you drop a component instance into a rich-text body. The component’s data is held as an opaque block. You can leave it alone, delete it, or replace it; you can’t edit the component’s internals here — that’s a Designer-side job.
  • Custom HTML blocks inside rich text. Same shape — preserved verbatim as a fenced block.
  • Custom code (head, body, footer) attached to an item — preserved verbatim under a customCode key.

These are the “if you touch them, you do it on purpose” parts. A bulk find-and-replace over text bodies won’t accidentally rewrite an embedded component, because the component lives in a fenced block.

What’s not in scope at all

Some Webflow concepts aren’t fields on a CMS item, so Spectersync doesn’t represent them:

  • The Designer — page structure, layouts, components, interactions, custom code at the site level. Out of scope. The Designer remains the Designer’s job.
  • Site SEO outside what each collection exposes — Spectersync syncs the per-item SEO fields the collection defines, not site-level meta.
  • Forms — submissions and form definitions are out of scope.
  • Memberships — membership records and access rules are out of scope.
  • Webflow Ecommerce — products, variants, orders, customers, inventory are out of scope.

If you need to touch any of those, you’re back in Webflow.

Pre-bulk-edit checklist

Before you run a bulk edit on a Webflow collection, the three things to check:

  1. Are the fields you’re editing in the “lossless” or “projection” categories? If yes, the bulk edit is safe. If you’re targeting an opaque block (an embedded component), don’t — handle those one at a time in the Designer.
  2. Is the item’s id preserved? That’s how Spectersync knows an edit maps to an existing CMS item. The workspace keeps it for you, so the only way to lose it is to delete it on purpose.
  3. Is Preview Sync showing the diffs you expected? If the diff is larger than you thought (touched fields you didn’t mean to touch), send it back and re-run — don’t publish. The whole point of the review step is to catch the surprise.

The pattern that holds: lossless fields and the projection cases are great for bulk. Opaque blocks and Designer-side concerns are not.

Prefer the desktop edition?

The same field mapping runs in the desktop and open-source edition, where each CMS item is a plain .md file on your Mac — frontmatter for the fields, body for the rich text — with nothing routed through our servers. The hosted webapp is the fastest way in. Subscribe now →