Managing a live website involves a constant risk: every update, no matter how small, has the potential to introduce errors, break layouts, or disrupt the user experience. HubSpot's content staging environment is the platform's native solution to this problem. It provides a private, unpublished copy of your website pages where you can build, test, and review changes without affecting what your visitors see. This tool is fundamental for any team that wants to maintain a professional and stable web presence while continuously improving it.
Unlike a full development environment or a sandbox, which copies your entire portal, content staging is focused specifically on your CMS Hub assets: website pages and landing pages. It creates a parallel version of a page that can be modified independently. You can change content, swap out modules, adjust styling, and even build entirely new pages from scratch. Once the changes are reviewed and approved, you can deploy them to the live domain with a single click, either replacing the old page or publishing a new one.
This guide provides a practical, step-by-step walkthrough of the HubSpot content staging process. We will cover how to access the tool, the difference between staging a single page versus an entire site, the core actions you can perform, and the correct procedure for publishing changes. We will also explore common limitations and best practices that HubStack uses to ensure smooth, error-free deployments for clients undergoing a HubSpot website design & development project or receiving ongoing HubSpot support & maintenance.
What is HubSpot Content Staging?
HubSpot content staging is a feature within CMS Hub Professional and Enterprise that creates a testing area for your website. It is not a separate server or a complete clone of your portal. Instead, it generates a private, unpublished version of a page or group of pages. This staged version exists on a separate, non-indexed URL, typically with 'hs-sites' in the domain, allowing you and your team to see exactly how changes will look before they are made public. The core purpose is to separate the development and review process from the live visitor experience.
The staged environment mirrors your live site's design templates, themes, and modules. When you 'stage' a live page, HubSpot creates a copy of it in this private area. From there, you can edit the staged copy without any impact on the original live page. This is essential for tasks like testing a new hero banner, experimenting with a new call-to-action module, or rewriting body copy. You can also create brand new pages directly in staging, which is the standard workflow for building out a new section of your website before its official launch.
It is critical to understand that content staging is distinct from HubSpot Sandboxes. A sandbox is a complete copy of your HubSpot portal, including CRM data, workflows, and settings, designed for testing complex automations and integrations. Content staging, by contrast, is purely for your website's front-end content and design. It will not stage changes to HubDB tables, blog posts, or knowledge base articles. Knowing this distinction helps you choose the right tool for the job and manage your team's expectations.
Accessing and Using the Staging Environment
To access content staging, navigate to your HubSpot portal and go to Content > Website Pages or Content > Landing Pages. In the top right corner of the page listing, you will see a button labeled 'More tools'. Clicking this reveals a dropdown menu, where you will find the 'Content Staging' option. This takes you to the main staging dashboard, which is your control center for all staged content. The interface looks similar to the standard page editor but is clearly marked with banners and indicators to remind you that you are not working on the live site.
From the staging dashboard, you have two primary options. You can stage a single page by selecting 'Stage a page' and choosing from a list of your existing live pages. This is the most common workflow for making targeted updates. Alternatively, you can choose 'Stage a domain,' which creates a staged version of every page on a selected subdomain. This is typically used for larger projects like a site-wide redesign or a major navigation overhaul, allowing you to review the entire site experience holistically before publishing all changes at once.
Once a page is in staging, you can edit it just like any other HubSpot page. You can share the private staging URL with stakeholders for review. This link is automatically password-protected if you have that setting enabled in your portal, ensuring only authorized individuals can view the work in progress. This review step is a crucial part of the process and helps catch issues before they reach your public audience. For complex projects, a clear review protocol is essential, something we define in detail during our HubStack HubSpot website launch process.
The Core Actions: Stage, Edit, and Publish
The content staging workflow revolves around three main actions: staging a page, editing it, and publishing it. The first step, 'staging,' creates the editable copy. Once a page is staged, a new version appears in your content staging dashboard, and the original live page is locked from editing to prevent conflicting changes. This lock is a safety mechanism ensuring that no one on your team can accidentally modify the live page while a new version is being prepared.
Editing in the staging environment is identical to the standard page editing experience. You have access to the same drag-and-drop editor, modules, and settings. You can modify content, change layouts, and adjust page-level settings like the URL slug or meta description. All these changes are saved exclusively to the staged version. If at any point you decide to discard the changes, you can 'unstage' the page. This action deletes the staged copy and unlocks the original live page, leaving it untouched.
The final and most critical step is 'publishing'. When you are ready to deploy your changes, you click the 'Publish' button within the staged page's editor. HubSpot presents a confirmation screen showing a side-by-side comparison of the staged and live pages, highlighting what will be replaced. This is your final chance to review. Upon confirming, HubSpot replaces the live page's content with the staged version's content. The process is nearly instantaneous, and your new page is immediately visible to the public. For brand new pages created in staging, the process is similar, but it publishes the page to its designated live URL for the first time.
Common Use Cases for Content Staging
Content staging is not just for fixing typos; it's a versatile tool that supports a wide range of marketing and development activities. One of the most common use cases is a website redesign. By staging the entire domain, your team can work on a new look and feel across all pages, ensuring consistency and functionality before the big reveal. This allows for thorough testing of the new HubSpot theme customization on different devices and browsers without disrupting the current site.
Marketing teams frequently use staging to prepare for campaign launches. You can build a suite of new HubSpot landing pages in the staging environment, get approval from all stakeholders, and then publish them all simultaneously when the campaign goes live. This coordinated approach ensures all marketing materials are ready and consistent from day one. It also allows you to perfect on-page elements and test tracking scripts in a safe setting before they need to start collecting data.
Staging is also invaluable for technical updates. For example, if you need to test a new custom module or implement significant changes to a page template, doing so in staging is the only safe way. It allows a developer to experiment and debug without the risk of bringing down a critical page. This process de-risks development and empowers teams to innovate faster, knowing they have a safety net. At HubStack, we mandate the use of staging for any significant module or template change we perform for our clients.
| Use Case | Staging Action | Key Consideration |
|---|---|---|
| Full Website Redesign | Stage the entire domain. | Ensures design consistency across all pages before a single one goes live. |
| New Landing Page Campaign | Create new pages directly in staging. | Allows for review and approval of all campaign assets before launch. |
| Updating a Core Page (e.g., Homepage) | Stage the single page. | Isolates changes to a critical page, preventing accidental site-wide issues. |
| Testing a New Page Template | Create a new test page in staging using the new template. | Validates template functionality without assigning it to a live page. |
| Minor Content or Image Update | Stage the single page. | Provides a final visual check before publishing, preventing formatting errors. |
Limitations: What Content Staging Doesn't Do
While powerful for CMS content, content staging has clear limitations. It's crucial to understand that it does not stage your entire HubSpot portal. CRM data, such as contacts and deals, is not part of the staging environment. This means you cannot test how a form submission on a staged page interacts with your live contact database or triggers a live workflow. Any form submission on a staged page will still be processed by your live portal, which can lead to confusing test data in your CRM if not managed carefully.
Similarly, other data-driven HubSpot tools are not included in staging. HubDB tables, the blog platform, and knowledge base articles cannot be staged. If you update a HubDB table, the change is live immediately and will be reflected on any page using that data, including staged pages. Blog posts are published directly and do not have a staging step. This is a key reason why teams must have a separate review process for blog content and HubDB updates, as staging cannot serve as a safety net for them.
The tool is also not designed for testing complex integrations or API connections. Since the staging environment is not a true server clone, it doesn't replicate the backend configurations needed to test how HubSpot connects with platforms like Salesforce or other third-party services. For this level of technical testing, you must use a HubSpot Sandbox, which is the appropriate environment for development work that goes beyond front-end content changes. Understanding this boundary is key to using both tools effectively and avoiding frustration.
Best Practices for a Smooth Staging Workflow
To maximize the effectiveness of content staging, establishing a clear and consistent workflow is paramount. First, designate a gatekeeper. One person, typically a marketing manager or lead developer, should be responsible for the final 'publish' action. This prevents situations where multiple team members push conflicting changes live. This individual is responsible for running through a final pre-publish checklist, which might include checks for mobile responsiveness, broken links, and console errors.
Second, maintain a clean staging environment. Over time, the staging area can become cluttered with old, abandoned page drafts. This creates confusion and makes it difficult to find active projects. Institute a policy to 'unstage' pages once a project is complete or cancelled. A regular monthly or quarterly cleanup of the staging environment will keep it organized and efficient for the entire team. This digital hygiene is a small step that pays significant dividends in productivity.
Finally, use the proofing and commenting tools built into HubSpot. When you share a staged page link, reviewers can leave comments tied to specific elements on the page. This is far more efficient than sending feedback via email or Slack messages. It keeps all change requests centralized and provides a clear to-do list for the editor. Adopting these best practices, as we do at HubStack, transforms content staging from a simple feature into a robust collaboration and quality assurance system for your entire HubSpot CMS investment.