How to Change Your HubSpot Theme Without Breaking Your Live Site

<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >How to Change Your HubSpot Theme Without Breaking Your Live Site</span>

Changing the theme on a HubSpot site that already has a few hundred pages feels risky, mostly because people picture flipping one switch and watching the whole site change at once. You don't have to do it that way. With a bit of planning you can rebuild everything in the background while your current site stays exactly as it is, then go live in one clean step.

This guide covers three ways to change your HubSpot theme, when each one makes sense, and the steps to do it without taking your site offline or losing your search rankings. It applies whether you are moving to one of our themes or any other HubSpot CMS theme.

First, do you need to clone the theme?

Short answer: only if you want to change the theme's code. A marketplace theme installs as read-only, so if you need custom modules, new templates, or layouts the built-in modules don't cover, you clone it in Design Manager to get a copy you can edit.

If you are mainly applying your branding and rewriting copy, you don't need to clone anything. The look and feel is controlled from the theme settings, and copy is edited on each page in the editor. Most theme changes fall into this second group, so don't clone out of habit. It just leaves you maintaining a separate copy for no reason.

Before you start: a few things that save you pain later

  • Set your theme settings once. Colours, fonts, and spacing are global. Get them right at the start and every page you build inherits the same look automatically.
  • Make a list of your current URLs. Export your pages so you know exactly what you have. This is your checklist and your redirect reference.
  • Keep your slugs the same where you can. If a URL has to change, plan a 301 redirect for it so you keep the search ranking and don't send visitors to a dead page.
  • Pick a go-live date. A fixed date keeps the project moving and tells you what has to be ready and when.

Approach 1: Build in draft, then swap

This is the approach I use most for a full redesign where the copy is changing too. It is simple, it is safe, and it works on any HubSpot tier.

  1. Build each new page (landing pages and website pages) on the new theme as a draft. Work through them at your own pace. Nothing is live yet, so there is no pressure and no risk to the current site.
  2. When a batch is ready, unpublish the old page and publish the new one in its place. If you kept the same slug, the URL carries straight over. If the slug changed, add the redirect.
  3. Once your pages are switched, go to your blog settings and update the blog template to the new theme. That moves your blog over without rebuilding every post by hand.

The nice thing here is you control the pace. You can switch a handful of pages at a time and check each one, or hold everything as drafts and publish them all on your launch day. For a site of a couple hundred pages with a fixed go-live date, this is usually the cleanest path.

Approach 2: HubSpot Content Staging

HubSpot has a built-in tool made for exactly this job. You find it under Settings, Website, Pages, Content Staging.

Content Staging lets you redesign your existing website pages in a separate staging area while the live versions keep running untouched. You rebuild and rewrite as many pages as you want, then publish them all together in one move when you are ready. It is a good fit when you are redesigning a lot of existing website pages and want them to go live at the same moment.

The thing to know is that Content Staging is for website pages. Landing pages and blog posts are handled outside of it, so if your site is a mix you will still use the draft-and-swap method for those parts. Many migrations end up using Content Staging for the main site pages and drafts for everything else.

Approach 3: Swap the template in place

If you are not rewriting much and you just want existing pages on the new theme, you can change the template on a page directly from its settings, without creating a new page at all. The URL, the analytics history, and the page stay the same. You point it at the new theme's template and then tidy up the content.

This is the fastest option for a smaller site or for pages that are staying largely the same. The trade-off is that you are editing live pages, and modules from the old theme don't always map one to one onto the new theme, so you need to check each page after the swap. For a big redesign with new copy, the draft-and-swap approach gives you more room to work without that pressure.

Which one should you use?

  • Full redesign with new copy and a launch date: build in draft and swap. Most flexible, works for pages, landing pages, and blog.
  • Lots of existing website pages going live together: Content Staging for those, drafts for landing pages and blog.
  • Smaller site or light changes: swap the template in place and clean up as you go.

You can mix them. A real migration often uses Content Staging or drafts for the main pages, the in-place swap for a few simple ones, and a blog template update at the end.

On launch day

  • Publish the staged pages or your drafts.
  • Update the blog template in blog settings.
  • Check your redirects are live for any URLs that changed.
  • Click through your main pages and forms on desktop and mobile.
  • Resubmit your sitemap so search engines pick up the new pages.

Because you built everything ahead of time, launch day is mostly publishing and checking, not building.

Choosing the theme itself

All of the above assumes you have picked a theme you actually want to live with for the next few years. If you are still deciding, our themes are built so the styling lives in the theme settings and the copy stays editable per page, which is what makes a migration like this straightforward. You can see them on the demo site and read the documentation to see how the settings and modules work before you commit.

However you do it, the rule is the same: build in the background, keep the live site running, and switch over once everything is ready.