Publishing and Scheduling

The Publish button in the Designer’s top bar opens a menu that lists the domains the site can be published to, each with a check box, and a Publish to selected domains button. Typical choices are:

The Help Center article on publishing and unpublishing a site lists a few rules worth knowing before the first publish.

Source: Webflow Help Center: How do I publish or unpublish a Webflow site?

Treat the webflow.io build as a dress rehearsal. It is generated by the same publish, from the same staged site, with the same hosting stack, so what the reviewer sees there is what production will show. For Fernbrook Gardens the usual flow is:

Staging is not access-controlled by default. Anyone who knows or guesses the subdomain can open it, and it contains the draft-free published CMS content, not draft items. A site that must not be public before launch should use password protection on the staging build (see Password Protection and Site Search).

On Workspace plans that include page branching and a publishing workflow, a further layer exists above the staging-to-production step: changes made on a branch publish to a branch-specific staging URL, and a prepublish summary lists what a publish will release. That model is explained in Page Branching, Releases and Approvals. The rest of this page describes the plain model, which applies to every site.

A full site publish regenerates and uploads:

What it does not do is publish a CMS item that is in draft, and it does not publish a scheduled item before its time. Those two exceptions are the subject of the next sections.

The Data API does not have a status property. A Collection item carries these properties, and the Webflow UI derives its status from them:

The Create Live Items reference states that isDraft together with lastPublished determines the status shown in the Webflow UI. A mapping that matches the Help Center table is:

Queued and Scheduled are states of the workflow rather than of the item’s data; the Help Center describes them as options of the item’s publish menu. The Data API reference pages for items and for publishing document no property that creates a scheduled publication, which matters for automation (see the section on automating publishing).

Source: Data API: Create Live Items

The diagram shows the transitions described in the Help Center table and the Data API reference. Edits to a published item move it to Changes in draft; publishing from any live-capable state moves it to Published; archiving takes the item off the live site from any state; and unpublishing returns an item to Draft.

The "Delete" transition is a permanent removal; it is shown once, from Archived, for readability. The Scheduled to Draft path is described by the Help Center as unscheduling by saving the item as a draft or by queuing it.

The editor writes the entry for the Japanese maple plant:

Because no site publish was needed, the designer’s half-finished layout experiments, which are staged but not live, did not go out with the typo fix.

Source: Webflow Help Center: Save and publish Collection items

Queue for next site publish is for content that must go out together with a design change. The botanical garden renames the family field on the plant template and also rewrites 40 plant descriptions to match. The editor queues the descriptions, the designer publishes the site, and the new layout and the new content go live in the same publish, so visitors never see the old layout with the new text.

The Help Center states that, when a manual site-wide publish is triggered, only the items that are queued or not explicitly scheduled are published, which is why the queue exists: it makes the intention explicit.

At the chosen time Webflow publishes the item and the status becomes Published. If an item needs a changed time, the Help Center describes Save and reschedule for an item that is scheduled but not yet live.

The Help Center article and the Webflow updates entry give these rules. They are the ones that explain almost every surprise.

Because the schedule is per item, a launch made of one new event, three new plants and a changed home page cannot be scheduled as a unit. The page changes are a site publish, which cannot be scheduled natively; the typical pattern is to publish the site shortly before the scheduled items are due, so that the layout is ready when the items appear.

The scheduled item publishes as an item: when the time arrives, the item and the pages that depend on it become live, and Collection lists that include it render it. If the Events template page was redesigned and the designer has not published the site yet, the scheduled item is shown in the old layout, exactly as a single-item publish would. The Fernbrook rule is therefore: publish the site no later than the evening before a scheduled launch.

The Help Center page does not mention a native "Schedule an unpublish" option. Third-party tools that fill that gap exist in the Webflow Marketplace; they use the Data API calls shown later on this page.

Source: Webflow Help Center: Scheduled publishing

During the beta, in May 2020, some sites saw every existing item switch to Staged for publish after the feature was released, which Webflow fixed shortly afterwards. Tutorials from that period describe the schedule button as living under an arrow next to a Generate button, a layout that no longer exists. The current UI has the Schedule to publish later entry in the item’s publish menu.

Source: Webflow updates: Scheduled publishing for collection items is now in beta

Source: Webflow updates: CMS draft and publishing improvements

The Help Center article Publish a single page gives these rules, checked on 2026-10-28.

The Data API changelog entry of 2026-04-08 describes what an API single-page publish includes.

The same entry states that changes to global resources since the last publish do not reach the page: the page keeps showing the version of the global resources that was in the Designer when the page was last published. For a designer this is the most important sentence on the topic. If you changed a shared symbol, a global class, a variable or the navigation component, publishing one page does not update the other pages, and the single page does not receive the global change either.

Page-level approvals and branching, which control who may release a page, are covered in Page Branching, Releases and Approvals.

Source: Webflow Help Center: Publish a single page

For an item the two verbs are easy to confuse.

For Fernbrook Gardens, an expired event is archived so that it stays available for reuse (events repeat annually), and an item pulled for a factual error is unpublished so that it can be corrected and republished.

Deleting an item is separate from unpublishing and archiving, and it removes the item for good. Items that referenced it lose the reference, and its URL no longer resolves. Prefer archiving unless the item is truly obsolete.

The endpoint publishes a site, or a single page, to one or more domains. The body must contain at least one of customDomains (an array of custom domain IDs obtained from the Get Custom Domains endpoint) or publishToWebflowSubdomain (a boolean that defaults to false). An optional pageId restricts the publish to one page. The call is queued: it answers 202 Accepted and the publish happens asynchronously.

Source: Data API: Publish Site

Publish to production and staging together:

The response body repeats the destinations and says what was published.

Source: Data API: Publish Site

Notes that apply to every call of this endpoint:

The pageId parameter, added to this endpoint on 2026-04-08, publishes one page instead of the site.

The response has publishScope set to page. The Data API reference notes that if several individual pages are published to staging, publishing from staging to production releases all staged changes.

Source: Data API changelog: Publishing individual pages

POST /v2/collections/{collection_id}/items/publish publishes staged items. The body has one of two shapes: itemIds, a list of IDs published in the primary locale, or items, a list of objects each with an id and optional cmsLocaleIds naming the locales to publish. The success status is 202, and the response holds publishedItemIds and an errors list, so that a request with several IDs can succeed partly.

Source: Data API: Publish Collection Item(s)

A partly successful answer looks like this.

Source: Data API: Publish Collection Item(s)

Rules from the reference page:

The same endpoint exists in JavaScript through the official SDK, which handles authentication and retries.

Source: Data API: Publish Collection Item(s)

The live items endpoints write directly to the live site. POST /v2/collections/{collection_id}/items/live creates items and publishes them immediately; the response is 202. The body is either one item (fieldData at the top level) or many (items), and each item takes isDraft (default false), isArchived (default false) and, optionally, cmsLocaleId. Sending both fieldData and items returns 400.

Source: Data API: Create Live Collection Item

To create items in several locales, the reference recommends Create Items followed by Publish Collection Item(s), because Create Items writes staged content only. The default of the staged Create Items endpoint changed on 2024-12-17: new items are now created with isDraft set to true.

DELETE /v2/collections/{collection_id}/items/live unpublishes up to 100 items and sets their isDraft property to true. The body is a list of objects with the item id and optional cmsLocaleIds; without locale IDs, items are unpublished only in the primary locale. The success status is 204 with no body.

Source: Data API: Unpublish Live Collection Item(s)

The reference text mentions a cmsLocaleId parameter in its description while its schema lists cmsLocaleIds for each item; use the schema’s plural form, which is the one the examples show.

Because the Data API has no documented property that schedules an item, a developer who wants a scheduled republish (or a scheduled unpublish) combines a trigger with these endpoints. A small Node script run by a scheduler such as a GitHub Actions cron job implements the Fernbrook marketing manager’s request: archive last year’s event at midnight and publish this year’s at 08:00.

Source: Data API: Publish Collection Item(s)

The script must run on a schedule you provide; Webflow does not run it. For items that were never published, the native Schedule to publish later option is simpler and needs no infrastructure. Use the script only for what the native feature cannot do: scheduled unpublish, scheduled republish of a live item, and scheduled site publishes.

To report the state of every Fernbrook plant, list the items and derive the status from isDraft, isArchived and lastPublished, as in the mapping table earlier.

Source: Data API: List Collection Items

The function cannot return Queued or Scheduled, because those states are not exposed by the item properties; treat the Designer’s status column as the authority for them.