←  All terms
P
Webflow

Page Branching

Page branching creates isolated page versions so teams can prepare changes in parallel and merge them in a controlled way.

Page branching creates isolated page versions so teams can prepare changes in parallel and merge them in a controlled way. In Webflow, the solution should align CMS structure, components, permissions, and ongoing editorial maintenance. The concept is closely related to Staging Environment and Content Approval.

Read more

Staging Environment

Content Approval

Deployment

Webflow Enterprise

FAQ

Page Branching

Who should be allowed to use page branching, and who should approve?
Designers and editors with editing rights can create branches, while merging and publishing should sit with a named approver. That protects the live site without slowing parallel work. How finely this can be controlled through roles depends on the plan and the permission concept.
What conflicts can arise when merging branches?
Conflicts arise when the same page or a dependent element was changed differently in the live version and in the branch, for example components or CMS bindings. Short branch lifetimes, clear ownership per page, and a four-eyes principle at merge time reduce the risk. Before merging, the branch should be checked against the current live state.
How does page branching differ from a staging environment?
Page branching isolates individual pages within the same site, while a staging environment tests the site as a whole before going live. Branching fits parallel page changes; staging fits release checks of structure, integrations, and deployment. The two can be combined but do not replace each other.
What is page branching suited for, and what not?
Page branching suits larger changes to individual pages that should be reviewed before publishing, such as reworking a landing page. For small text corrections the effort is too high. Changes to elements shared across many pages, such as components, should be coordinated separately.