What our website rebuild fixed, and what we’re working on.

Lucy has already told the story of why we rebuilt bloomtransitions.co, and how it went live before I’d finished checking it, in We broke our own rules so you don’t have to. This is the other half: what changed under the hood, what the data says now, and what we’re still fixing. If you’re weighing up the same move, this is the bit you’ll want.

What actually moved?

Only the website. Our front end is now Next.js, hosted on Vercel and built with Claude Code by an experienced and talented developer, who is now part of our team. HubSpot still runs everything behind it: our CRM, marketing, email and reporting. We’re still a HubSpot Gold Partner, and we’re still 100% Team HubSpot.

HubSpot is still doing plenty on the site, too. It handles:

• visitor tracking and analytics
• embedded HubSpot forms, so every enquiry lands straight in the CRM
• live chat
• the cookie banner
• pop-ups and other web interactives.

Same CRM, same reporting, new front end. For anyone worried about losing their HubSpot setup, that’s the headline.

Did we have to redirect anything?

No. Every URL stayed exactly the same, and if you take one thing from this post, make it this.

A URL is the address Google, AI tools and other websites use to find a page. Over time, each page builds up rankings, links from other sites and a place in AI answers, all tied to that address. Change the URL and you’re asking all of them to find you again.

A permanent redirect can carry that across, but every one has to be mapped, tested and kept in place. Miss one and it’s a dead end for visitors and a lost signal for search engines. Keep the URL and there’s nothing to carry across. Google sees the same page at the same address, just built differently.

The move also cleared out the redirects that had built up on the old site over the years. Semrush counted 76 temporary redirects and 59 permanent ones on the old site. On the new one: zero temporary, four permanent.

What did the rebuild fix?

Semrush crawled the old site on 27 August and the new one on 15 October, five weeks after launch. To compare like with like, these figures cover our main New Zealand site.

Most of these are the kind of thing that piles up quietly on a site lots of people have edited over the years. A rebuild in code is a clean slate, and it showed.

What didn’t get better?

Three things, and we’d rather tell you than have you find them.

• Text-to-HTML ratio. Semrush flags many of our pages for a low text-to-HTML ratio. That comes from how Next.js works: on our homepage, about half the HTML is a copy of the page that makes clicking between pages instant. Google has said the ratio plays no part in rankings, so we’ve left it alone and put the effort into speed instead.
• Duplicate H1s and page titles. 33 pages use the same wording for both, up from 25. That one’s a content fix, and it’s on my list.
• llms.txt. Missing on the old site, and still missing when the new one launched. For an agency that talks about AI visibility for a living, we were aware of the irony. It’s live now.

What happened to our schema?

On the old site, 8 pages had no schema at all, including our HubSpot CRM page, our Services page and two case studies. Now every page has it.

Everything the old site used came across (Organization, Service, BlogPosting, Article, Person, FAQPage and ContactPage), and the new site adds WebSite, breadcrumbs on every page except the homepage, and ItemList, CollectionPage, AboutPage and VideoObject where they apply.

The one thing we dropped was FAQ markup for questions that weren’t visible on the page, because Google only uses FAQ markup when people can see the questions.

Google’s Rich Results Test, run on 12 October, found valid structured data on our homepage, blog posts and contact page. Semrush flagged one error: the contact page describes BLOOM as a local business but doesn’t give an address. That one came across from the old site too, and it’s an easy fix, so we’re making it.

And did our AI visibility survive the switch? Yes, and our US visibility grew. The numbers are in the case study.

Where did Claude Code come in?

Claude Code wrote the code for the new site: 58 pages in Next.js (174 with the US and Australian versions), the move of our blog off HubSpot, and the schema on every page.

The judgement calls were about what not to break. One example: every image in our old blog lived at a bloomtransitions.co/hubfs/ address on HubSpot, so the day the site moved, all of those image links would have broken. We forwarded those addresses to HubSpot’s own file storage, so old links and Google image results kept working. All 54 page addresses we listed from the old site still work too.

So why did the site get slower?

In the case study, we said we’d report back on page speed. Here it is.

Our homepage’s GTmetrix Performance score slipped after launch. The main content took 3.6 seconds to appear (Largest Contentful Paint), where Google counts 2.5 seconds or less as good.

The site itself isn’t the slow part. Our server delivers each page’s HTML in under a tenth of a second. The delay comes from what loads after that, and when we looked, we found three things:

• a Google Tag Manager container with nothing in it, loading 116KB of nothing
• the same Google Ads tag loading twice, through HubSpot’s ad tracking
• the chat widget loading straight away, before anyone needed it

We’re fixing all three: removing the empty container, sorting out the double tag, and holding back the chat widget and our new homepage animation until the page has loaded. The cookie banner stays as it is, because it has to ask for consent before any tracking runs.

Update, 18 October: the score is back up to 60%, and the main content now appears in 0.6 seconds, well inside Google’s 2.5-second mark. Blocking time hasn’t moved yet (still 1.7 seconds), so the script clean-up is next. We’ll update this post again once it’s done.

The lesson: audit your scripts before launch, not after. Every tag should earn its place.

What would we tell anyone planning the same move?

Keep your URLs

If you can’t, map every redirect before launch and test them.

Crawl your old site before you switch

Lucy has already admitted we didn’t benchmark properly. We got lucky: a routine Semrush audit from 27 August gave this post its before column. Don’t rely on luck.

Audit your scripts before launch, not after

Every tag should earn its place.

Build schema into your templates

Then test it in Google’s Rich Results Test and the schema.org validator.

Re-crawl a few weeks after launch

Launch day is when the measuring starts.

Want the rebuild without the homework?

We tested it on our own site first, so you get the road-tested version, with HubSpot behind it if you want it. Explore custom website builds.

The results, the before and after, and what happened to our AI visibility: How we rebuilt our website in a week.