Important changes to CMS publishing

Hey there Devs :waving_hand:t5:!

Sharing a quick update on upcoming changes to the Data API v2 on July 7th, 2025. We’re enhancing the API to align with recent UI improvements and provide more flexibility for the Webflow CMS. These changes affect how you manage live items and publish CMS content with the API.

Below is an overview of the changes, key actions you may need to take, testing guidance, and the timeline for when these updates will go live. If you have any questions, feel free to drop them below!

Key Changes

1. Draft Management Improvements

The Webflow UI now supports saving draft changes to published CMS items without affecting live content. To maintain consistency between the UI and API, we’re introducing the following change:

Unpublishing Live Items - Breaking Change

Previously, updating a live item’s isDraft property to true would unpublish a live item from the site. This behavior is changing to support improved draft management:

  • Setting isDraft: true on a live CMS item will no longer unpublish it
  • The item will remain live while draft updates can be made using the staged item endpoints.

Required Action: Update your code to use the dedicated unpublish endpoints:

Affected endpoints:

Understanding Item Status

In the Webflow UI, CMS items have a status field that maps to the item’s isDraft and lastPublished properties. Here’s how these properties determine an item’s status:

Status isDraft lastPublished Description
Draft true null Never published or previously unpublished item
Published false timestamp Item is live on the site
Changes in draft true timestamp Published item with pending changes in the staged item
Queued to publish false < lastUpdated Changes will publish on next site publish. This is the default status for newly created items, as well as for updates to items that have already been published.

Note: The Unpublish Live Item endpoint sets isDraft: true and lastPublished: null.

2. Enhanced Publishing Flexibility :tada:

Here’s a change you’ll really like. You can now publish CMS items with the API even when site domains are out of sync. For example, if you’ve published to staging but not to production. This removes the previous limitation that caused 409 errors in these scenarios. No changes needed here - instead, we expect that you’ll see less errors!

Affected endpoints:


Required Actions

  1. Review Integrations

    • Identify code using isDraft: true for unpublishing
    • Test with beta APIs in development environment
  2. Update Code

    • Replace isDraft unpublishing with proper endpoints
    • Test and verify changes in your development environment

How to test your changes

All functionality described above is available now through the Beta APIs under the /beta namespace. To test, replace /v2 with /beta in your API calls within a testing environment to see the new behavior in action. Unfortunately, the Webflow SDK does not support the beta namespace at this time.


Timeline

  1. Now - July 7, 2025: Testing period

  2. July 7, 2025: Changes go live

    • Breaking changes take effect in v2

We’re here to help!

We genuinely hope these updates make it easier for you to build and move faster in Webflow. If anything’s unclear, or if you run into issues while testing, don’t hesitate to ask — I’m here and happy to help.

Thanks so much for being part of this community and for everything you’re building with us.

2 Likes

Hi @victoriaplummer!

Is there an isIndexable field coming with this change as well so that the CMS item’s indexing state can by synced and controlled?

Hey @memetican - not included in this change, but we can raise this as a request for our teams internally. What does your workflow look like today for this?

Hey @zachplata,

Currently it’s painfully manual- the new Indexing/Sitemap control is very useful, but we are unable to mass-change that setting or to sync or transfer the CMS data to other sites even through CSV import/export.

In the designer, we can control sitemap/noindex at the static page level and at the collection item level, but not at the collection page level.

Our most common build requirement is that we have a collection that needs to be published but where the collection pages cannot appear in the sitemap or SERPs. They’re either used by scripts ( commonly in flashcard and quiz systems ) or are gated by a membership system like Memberstack and we can’t expose them to bots or snooping through the sitemap.

With this current limitation, we’re either forced to use a manual META noindex and a manually-edited sitemap.xml ( which clients dislike ), or we can use the new feature at the CMS item level but we need to manually edit 1,000+ items, and train clients to include it in their new-item-create workflows.

It breaks automations as well - when something is created through the API ( sync data, or e.g. an RSS-triggered item create automation ), someone has to manually go in and then hide that item, hopefully before a bot discovers it.

I think I would have built it differently, so that;

  • The collection page has the sitemap/noindex setting, identical to static pages, and that acts as a “default” setting for the items
  • The collection items then have individual sitemap/noindex settings, which are tristate - default / index / noindex.

That way the designer can easily setup any configuration they need- noindex by default but index selected items. Index by default but noindex selected items. Or our most common one, noindex everything including newly added items.

But since none of that’s built yet, as a triage, we were waiting for this to be added to the API so that we could setup automations properly, and;

  • Circumvent the CSV import/export problem by using the API instead
  • Make a script that we can run to turn off all items-level indexing in a particular table
  • Possibly setup an individual item automation so that when a CMS item is added/edited, the webhook checks the Indexing/Sitemap setting for the item and updates it if necessary.

Does that help?

That totally makes sense, appreciate outlining your workflows here :webflow_heart: will make sure this gets some eyes.