Publishing changes
How to publish a page, post, form or component, what publishing copies, and how to take something back off your site.
Publishing is the action that takes the work sitting in your account and puts it on your public website. Until you publish, visitors keep seeing the previous version.
The publish action lives in the editor for whatever you are working on, and in the list views for pages and posts. Anything with a working copy can be published: pages, blog posts, forms, components, layouts, global code, blog designs and documentation pages.
Publish an edit
Make your changes, check they look right, then publish. Publishing takes effect immediately. There is no queue or approval step and no delay to wait out.
If the item was a draft, publishing also makes it public. Before you publish a brand new page, it is worth checking its address and its SEO settings, because that is the point at which search engines and visitors can first reach it.
You can publish several items at once from the page and post lists by selecting them and using the bulk publish action. This is the usual way to ship a change that touches a handful of pages together.
Know what publishing copies
Publishing copies the whole working copy of that one item to its live copy. For a page, that is the content and the page's own settings: its title, address, meta description and social image. It is not a partial update; you cannot publish the text of a page while holding back a settings change on the same page.
Publishing is scoped to the item you are publishing. It does not sweep up anything else. If your change also touched a reusable component, that component needs publishing too, or the live pages carry on using the last published version of it. This catches people out: the page looks right in the editor because the editor shows working copies, but the live site still shows the old component.
Add a change note
When you publish you can attach a short note describing what changed. The note is stored with that version in the item's history.
It is optional and takes a few seconds. It pays for itself when someone looks at the history three months later and needs to know which version to go back to. "Updated pricing to 2026 rates" is far more use than a bare timestamp. If several people edit the same site, treat notes as good manners.
Understand what visitors see
Published pages are cached so they load quickly. When you publish, BrightSite refreshes the cached copy, so visitors get the new version straight away rather than waiting for a cache to expire.
If you have published and still see the old version, your own browser is the usual culprit. Try a hard refresh or a private window before assuming the publish failed. It is also worth checking that you published the item you actually changed.
Unpublish something
Unpublishing removes the live copy so visitors can no longer reach it. The item and its content stay in your account and it becomes a draft again, a draft being anything that is not currently public, so you can keep working on it and publish it again later.
This is the right tool for a seasonal page, a job listing that has been filled, or anything you want off the site for now but not gone. Prefer it to deleting whenever you might want the content back.
Be aware of the effect on people outside your team. An unpublished address stops working, so existing links to it, from other sites, from search results, from emails you have already sent, will no longer reach a page. If the address had traffic, add a redirect pointing it somewhere sensible.
Check who can publish
Editing and publishing are separate permissions. Someone can be allowed to work on content without being allowed to put it on the public site, which is a common arrangement where a reviewer approves work before it goes out.
If the publish action is unavailable to you, your role does not include publish permission on this site. An administrator on the account can change that.
Related
Last updated August 27, 2026