Publish changes
Review a draft, publish under the project policy, or submit it for approval.
Editing saves content to the working branch. Publish promotes that work through the project's GitHub workflow; Request review submits it for approval. Neither saving a field nor seeing it in Preview makes it public.
Publish a draft
- Wait for pending saves to finish and preview the pages affected by your change.
- Open Publish in the Site Editor header.
- Review the changed items and add a note describing the change. Discard an unwanted item from this surface before continuing if needed.
- Follow the action allowed by the project: publish directly or request approval.
- After completion, verify the live site. Studio starts a fresh editable draft after publication.
The current publish sequence pushes the branch, synchronizes it with the base branch, opens or updates a pull request, and squash-merges it. Your deployment integration then applies that merged change. Deployment timing depends on the site's infrastructure.
Review and conflicts
Project publishing policy and repository checks can require approval. Request review opens or updates the PR and leaves it unmerged. A human review step is not mandatory for every edit: use the policy configured for the project.
If another change moves the branch after the change list was read, reopen and review the updated list. If synchronization encounters a conflict, resolve it before publishing. If merging fails after the PR opens, the work remains available in that PR.
Undoing published work
For an unpublished draft, discard the unwanted change. For published work, revert the relevant change in the repository and deploy the resulting version according to your site's workflow. The former admin's Releases → Revert screen is documented only in the legacy archive.
Implementation reference: Studio Site Editor. Reviewed 2026-10-05.