What Actually Happens When You Hit Publish in Webflow?

What actually happens when you hit Publish in Webflow?

Two separate things get pushed live, and most people only think about one of them. Your site's structure and design go out to the domains you selected. Your CMS content moves live on its own track, item by item, according to each item's own draft status. Understanding that split explains almost every confusing publish you have ever had.

Webflow's own publishing API describes a site publish as publishing the entire site by default, making the latest changes live on the specified domains, with the Webflow subdomain and your custom domains as separate targets. That is the part people picture. It is the CMS half that produces the surprises.

I spend a lot of my week publishing through that API rather than through the Designer, and reading the specification carefully changed how I think about the button. The mental model most people carry is that publishing takes a snapshot of everything and pushes it. It does not quite work that way.

Why is CMS content published separately from the site?

Because a CMS item has its own lifecycle. In Webflow's API, a newly created collection item is staged, with its draft flag defaulting to true, and it becomes live through a separate publish call for that item. The site and the content are two different things moving on two different clocks.

Once you see it that way, a lot of common confusion resolves. A site publish that does not make your new blog post appear is not a bug. The post was never marked ready. Equally, a post that appears without a site publish is not magic, it is an item publish that happened on its own.

This is also why a Webflow site can look inconsistent to two different people at the same moment. One person is looking at the published structure, another is looking at a collection where half the items are drafts. Both are seeing the truth, just different parts of it.

What does staged actually mean for a CMS item?

It means the item exists in the CMS but not on the live site. Webflow's API is explicit about the states: on update, true means Draft, false means Ready to Publish, and omitting the flag preserves whatever status the item already had. That last part matters more than it sounds.

Omitting the flag preserving status is the detail that saves you. If you are updating a batch of items for some other reason, a typo, a schema change, a bulk correction, you do not accidentally push a pile of unfinished drafts live just because your update did not mention their status. The system leaves them where they were.

It also means that draft status is a real editorial tool rather than a technicality. A writer can leave three posts in draft indefinitely, a designer can publish the site fifteen times, and those three posts stay invisible. If you are building an editorial process on Webflow, that behaviour is the foundation to build on.

What does single page publishing change?

It narrows the blast radius, with conditions. Webflow's API documents that passing a page ID publishes only that page, and that in that case CMS items are not published. It also documents that this requires an Enterprise site with single-page publishing enabled and at least one prior full-site publish on the main branch.

The CMS caveat is the important half. If your fix is on a template page and you publish only that page, the collection items rendered through it are not pushed by that call. People reach for single page publishing precisely when they are nervous, and then get confused when the content they expected to move did not move.

My honest view is that single page publishing solves a real problem for large teams and creates a new one for small ones. On a site with several people working in parallel, limiting a publish to one page is genuinely valuable. On a site with one or two people, it adds a state to reason about in exchange for a risk you did not really have.

What does unpublishing do that deleting does not?

Unpublishing takes an item off the live site and reverts it to draft, which Webflow's API states directly, and it does that for up to a hundred live items in one call. The item and all its content survive. Deleting removes it. That difference is the whole reason to prefer unpublish when something goes wrong.

This is the single most useful thing to know before an emergency, because emergencies are where people delete things. A post goes out with a client's name in it that should not have been there, somebody panics, and the fastest-looking option is to delete the item. Then the correct version has to be rebuilt from memory.

Unpublish gives you the same outward result, the page is gone from the live site, while keeping the content intact so you can fix and republish. I treat delete as reserved for things that were never meant to exist. Everything else gets unpublished. I wrote about the wider version of that reflex in the piece on publishing something wrong.

Why does publishing feel risky on a shared site?

Because a default site publish pushes the entire site, not just your change. Whatever anybody else has left half-finished in the Designer goes out with your small copy fix. The risk is not your edit, it is everything sitting beside your edit that you never looked at.

This is why teams end up with informal publishing rituals, the message in a channel asking whether anybody is mid-change, the unofficial rule that only one person publishes. Those rituals exist because the tool publishes the whole state of the site, and the whole state of the site is not something one person can hold in their head.

The structural answer is to use staging deliberately rather than as an afterthought. Webflow's own targets separate the staging subdomain from your custom domains, so the discipline of reviewing there first is available to everybody, not just to enterprise teams. I set out a workable version of that in the article on setting up a staging workflow, and Webflow has also shipped an update for custom staging domains if you want that separation on your own domain.

How do branches change the picture?

They add a rule you need to know before you rely on them. Webflow's API documents that site-branch pages cannot be published to production, and that you merge into main first, or stage the site branch for preview. A branch is a place to work, not a second live site.

That constraint is sensible and it catches people out anyway, usually at the worst moment. Somebody builds a redesign on a branch, gets approval on the preview, and then discovers that going live is a merge rather than a publish. It is a five minute surprise if you knew, and an hour of confusion if you did not.

The practical takeaway is to rehearse the merge before you need it. Whatever your process, the step that moves work from a branch into production should have been done once already on something low stakes, so that the first time is not also the launch.

What should you check before you press the button?

Three things, quickly. Whether anyone else has unfinished work in the site, since a default publish takes all of it. Which domains the publish is going to, since staging and production are separate targets. And whether the content you expect to appear is actually marked ready rather than sitting in draft.

The third one catches even experienced people, because the Designer and the CMS feel like one system and behave like two. Before a launch I open the collection and look at the status column, every time, rather than trusting my memory of what I marked ready an hour ago.

After publishing, check the live URL rather than the Designer preview. Preview shows you intent. The live URL shows you what a visitor gets, including anything the publish did not carry. It takes ten seconds and it is the difference between knowing and assuming.

What does all this mean if you publish through the API?

It means your automation has to do both halves explicitly. Creating an item stages it. Publishing the site does not push it live. Your script has to create the item and then publish that item, and it has to confirm the item ID came back in the published list rather than assuming success.

I build every content automation this way now: create, publish, verify, then record the result. The verify step is not paranoia. Partial successes are normal in any system that publishes many items at once, and a script that assumes a call worked will happily report a clean run while three posts sit in draft.

If you want to react to these changes elsewhere, the events are available to listen to, which is a cleaner pattern than polling. I went through that setup in the tutorial on CMS webhooks for content changes, and it pairs well with an automation that publishes on a schedule.

What should you do next?

Open your own site and look at the collection status column alongside your last publish date. If there are items marked ready that are not live, or items live that you thought were drafts, you have found a gap between your mental model and the system, and that gap is where future incidents come from.

Then agree one rule with whoever else touches the site: who publishes, and what they check first. It does not need to be a process document. One sentence in a shared channel prevents most of the accidental launches I get called about.

If you are running a Webflow site where publishing has become something people are nervous about, reach out. That nervousness is usually a sign that the workflow needs one small structural change rather than more care from everybody.