You work on a copy instead of the real thing. Webflow now has a built-in way to do that called page branching, where you branch a page, edit it in isolation, and merge it back when it is approved. If your plan does not include branching, you build the new version on a hidden page and swap it in.
This used to be the scariest part of working in Webflow. The Designer edits the live site's staging state, so two people touching the same site at the same time could easily publish something half-finished. Everyone we know had a workaround, and none of the workarounds were good.
Branching fixed the workflow problem for the teams that can get it. The catch is who those teams are, and that is the part most articles about this feature get wrong.
Page branching lets you create a copy of a page, edit that copy independently, and merge it back into the original when you are ready. The live page stays untouched the whole time. Webflow University describes a branch as "essentially a copy of an existing page that you can edit independently without affecting the original".
Webflow announced it as a collaboration feature. Its own update post calls it "a new feature that allows multiple designers to work on separate pages at the same time", which is the real problem it solves. Before branching, parallel work on one Webflow site meant coordinating by message and hoping nobody hit publish.
If you have used Git, the mental model transfers cleanly. You branch, you work, you review, you merge. The difference is that Webflow scopes a branch to a single page rather than the whole site, so it is closer to editing one file than to forking a repository.
Enterprise only. Webflow's own announcement states that "page branching is available today for Webflow Enterprise customers and Enterprise Partners", and the Webflow University lesson on page branching and approvals is labelled "Available on Enterprise plans". If you are on a standard Site plan or a paid Workspace plan, you do not have it.
We are being blunt about this because a lot of secondhand coverage says otherwise. We found several posts claiming branching had rolled out to all paid Workspace plans. Webflow's own documentation does not say that, and Webflow's documentation is the only source that counts here.
So before you plan a workflow around branching, open your workspace and check. If the branch option is not in your Pages panel, the answer is not that you configured something wrong. The answer is that the feature is not on your plan. Our post on whether you should use Webflow for an enterprise website goes into what else sits behind that tier.
Branch staging lets you publish a single branch to its own staging environment, separate from the site's main staging URL. That means a reviewer can look at the real, rendered page rather than a Designer preview. Webflow says it lets you "test new designs much faster, review custom code fully rendered, and catch issues earlier in the process".
That phrase about custom code is the important one. Designer preview does not run everything the published site runs. Custom scripts, third-party embeds, and anything that depends on the real page environment only behave properly once the page is actually published somewhere.
In our experience this is where most review cycles fall apart. A stakeholder approves a design in preview, the page goes live, and then an embed loads slowly or a script fights the layout. Reviewing on a published branch closes that gap. Branch staging is also Enterprise, since Webflow announced it as giving "Enterprise customers and Enterprise Partners" the ability to speed up branch testing.
Approvals turn branching from a convenience into a control. A designer or editor submits a branch for review, a designated approver looks at it, and only approved branches can be merged and published. Webflow University states that "only after a branch is approved can it be merged back into the main site and published".
This is what makes branching interesting to larger organisations rather than just to designers. Webflow describes the combination as creating "a clear audit trail" and preventing unapproved changes from accidentally going live. For a regulated business, an audit trail is not a nice extra. It is the reason the platform gets approved at all.
Approvals also pair with Webflow's granular access controls, so you can define who creates branches, who approves them, and who can publish to staging versus production. That separation of duties is the standard ask from any security review we have sat through.
Build the new version as a separate page, keep it out of the index, and swap the slugs when it is approved. Give the draft a temporary slug, set it to noindex in page settings, share the staging URL for review, and only rename it to the real slug once everyone has signed off.
This is the pattern we use on most client work, and it covers the majority of the risk. The live page never changes while the new one is being built. Reviewers see a genuinely published page rather than a preview, so custom code and embeds behave correctly. The swap itself takes under a minute.
The default staging subdomain does the heavy lifting here. Every Webflow site publishes to a webflow.io address alongside your production domain, which gives you a real environment to point stakeholders at. Enterprise teams can replace that with a custom staging domain, and Webflow notes you can have "one custom staging domain per site", but the free subdomain works fine for review.
Take a backup before the swap. Webflow keeps site versions you can restore, and a restore point taken just before a structural change has saved us more than once. We cover that habit in our guide to backing up and restoring a Webflow site.
Yes, when the change is bigger than a page. Branching is scoped to a single page, so a rebrand, a navigation overhaul, or a change to shared components or global styles cannot be safely isolated in a branch. For those, a duplicated site is still the honest answer.
The rule we use is about blast radius. If the change touches one page and nothing global, branch it or build a hidden twin. If the change touches classes, symbols, global custom code, or the CMS structure that other pages depend on, duplicate the whole site and work there.
Duplicating has a real cost, and we want to be fair about it. You now have two sites drifting apart, and any content the client edits on the live site during the project has to be re-entered or re-synced later. That is why we keep duplication for genuinely site-wide work and never use it as the default.
Single-page publishing lets you push one page live without publishing the whole site. It reduces the risk of an unrelated half-finished change going out with your fix. It is also an Enterprise feature, and Webflow lists two other prerequisites: the site must have been published at least once, and you need the publish permission for your role.
What travels with a single page matters as much as the feature itself. Webflow University says a single page publish includes all page content, page level settings, Webflow Optimize variations, and every localized version of that page.
What it leaves behind is the part that catches people out. CMS item data, site-wide fonts, global custom code, and 301 redirects are not included, so those still require a full site publish. If your new page depends on a new CMS field or a new redirect, publishing just the page will not be enough.
Branching covers pages, not everything a page depends on. Global styles, shared components, CMS structure, and site-wide code live outside the branch, so a branch is only truly isolated when your change is truly local. Plan around that before you promise a client a risk-free redesign.
Our honest take is that branching is a collaboration feature that happens to reduce risk, rather than a safety feature. It solves "two designers cannot work on this site at once" beautifully. It does not solve "we are changing the design system and hoping nothing breaks", and no page-level tool will.
Whatever workflow you land on, keep a real test pass before anything merges. Check the page on actual devices, run it through a performance tool, and confirm the metadata and redirects are right. Our pre-launch website testing checklist is the same list we run whether the change came from a branch or a hidden page.
If you are on Enterprise, use branching with approvals for page-level work and duplicate the site for site-wide work. If you are not, use a hidden page with a temporary slug for page-level work and duplicate the site for the big stuff. The plan decides the tool, and the size of the change decides the rest.
What we would not do is upgrade to Enterprise purely to get branching. Enterprise brings a lot of other things, including custom staging domains, granular roles, and single-page publishing, and branching makes sense as part of that package. On its own it is a workflow improvement, not a reason to change your contract.
If you are trying to work out which of these fits your team, or you have a redesign coming up and you are nervous about the swap, we are happy to walk through the options with you. This comes up on client work often. Let's talk, and you can find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.