Overview
The fear that stops teams letting anything near their website is simple: what if it goes wrong in public? A broken layout on a pricing page at 4pm on a Friday is not a technical problem, it is a commercial one.
So nothing goes straight to production. Changes are built on a staging environment with a shareable preview link, automated checks run against them, and you look at the result before deciding. Your live site carries on untouched the entire time.
Previews are proper URLs, not screenshots in a chat window. You can click through the staging site, test a form, check a page on your own phone and send the link to a colleague or client who has never logged into the portal. Approval becomes a decision based on the real thing.
How it works
- The change is built on staging — content, code or both.
- Automated checks run: build success, broken links, layout and accessibility basics.
- Mobile and desktop previews are captured so obvious breakages surface immediately.
- You get the preview link to click through and share.
- On approval the change is promoted to production; otherwise it is amended or discarded.
What the checks catch
- Builds that fail — a change that cannot compile never gets promoted.
- Broken internal links and missing images introduced by the change.
- Layout breakage at mobile and desktop breakpoints.
- Missing metadata — absent title tags, meta descriptions or alt text.
- Accessibility basics such as contrast failures and unlabelled controls.
Why teams use it
- Isolated environments — production is never touched until you say so.
- Shareable previews — send a link to stakeholders for sign-off, no login required.
- Automated testing — broken links and layout checks run every single time.
- Confidence to move faster — reversible, previewable changes are far less frightening to approve.
Staying in control
Staging is the default, not an option someone has to remember to choose. Promotion to production requires an explicit approval from someone whose role allows publishing, and the agent will tell you when a request exceeds the asker’s permissions rather than finding a way around it.
If something does reach production and you change your mind, rollback is one request and the whole sequence stays in the audit log.
Availability
Preview-before-publish is on every plan. A separate staging environment (content and code) is included on Growth, Scale and Enterprise.
Frequently asked questions
What if we do not have a staging environment?
You still get preview-before-publish on every plan: content changes are held as drafts and design changes can be rendered as a standalone preview you view before anything is committed. A full separate staging environment for content and code comes with Growth and above.
Can we share a preview with someone outside the team?
Yes. Preview links work for anyone you send them to and need no portal account, which makes them ideal for client sign-off or a quick opinion from a colleague. Staging is kept out of search engines so a preview never competes with your live pages.
How long does a change take to appear on staging?
Typically under a minute. Code commits rebuild in roughly 30 to 60 seconds and content changes in one to two minutes, and the agent confirms the build succeeded before telling you the preview is ready.
Does staging content get mixed up with live content?
No — they are separate environments. Work on staging has no effect on production until it is explicitly promoted, so an unfinished campaign page cannot leak onto your live site or into a search index.
Can we skip staging for something urgent?
If your role allows publishing, you can ask for a change to go straight to production — useful for a typo in a headline during a launch. It is a deliberate instruction rather than the default, and it is recorded in the audit log like any other change.
