Case study Healthcare, Australia and New Zealand
Reusable Shopify sections in place of a page builder
The group's Shopify pages leaned on a legacy page builder, so routine changes needed builder work and builder pages carried its code. Updates were slow and costly, and the extra weight risked losing phone visitors before they acted.
- Client
- A multi-clinic healthcare group
- My role
- Theme architecture and the move off the page builder, through to release
- Disciplines
- Shopify theme architecture, Frontend implementation, Web performance, CMS architecture
Client anonymised. Details are generalised and contain no confidential figures.
Context
The group's Shopify site had grown in two layers: the theme, and a legacy page builder that pages had come to depend on. The two had drifted apart, so the same kind of content existed in several versions with different markup and settings. The work was to give the theme enough reusable sections to carry those pages itself, and to decide page by page what should move across.
Constraints
- The site stayed live, so pages moved across one at a time with no break in service.
- Page addresses had to survive the move, or redirect, so search visibility and inbound links carried over.
- People without code skills had to keep building and editing pages in the theme editor.
- A builder page was only retired once the theme could do everything it did.
- Reporting had to survive each page's move, so before and after could still be compared.
Diagnosis
I started by listing every page and whether it was built in the theme or the page builder. Then I broke the builder pages into the patterns they were made of and compared those with what the theme already offered. GA4 showed which pages carried traffic and led to enquiries or sales. That set the order for the rest of the work.
The inventory turned up these problems:
- The same content, built many times. A banner with a button or a set of FAQs had been rebuilt by hand on each page, each with its own spacing and markup. A wording or style change meant finding every copy.
- Two sources of styling. The builder kept its own type and colour settings, so a brand change had to be made in the theme and then again in the builder.
- Code that loaded regardless. Builder pages carried the builder’s styles and scripts on top of the theme’s, adding weight on the devices where people have the least patience.
- Structure chosen for looks. Heading levels were picked for size rather than meaning, which muddies a page for screen readers and search engines.
- Content locked in. Builder pages were stored in the builder’s own format, so leaving it meant rebuilding each page rather than exporting it.
Most of the cost was time. Every new page or campaign waited on someone comfortable in the builder, and the extra weight landed on phone visitors before they reached the point of acting.
Approach
The theme became the product, and the pages became content arranged inside it. The aim was a small library of sections that could rebuild the builder pages, without recreating the builder’s freedom to make every page different.
A section has to earn its place
A pattern became a section only if it appeared on more than one page or was clearly going to be needed again. Each section got blocks for the parts that repeat and a short list of settings with fixed options, such as a background chosen from the theme’s palette instead of a free colour picker. Fewer choices kept pages consistent and made the theme editor easier to use.
One source for styling
Type and colour moved into theme settings, exposed to the stylesheet as CSS custom properties. Sections read from those, so a brand change happens once.
Performance as a build rule
Each section loads only its own CSS, and JavaScript only when it needs interaction. Images carry explicit dimensions so pages don’t shift while they load.
Move pages on evidence
Pages were rebuilt in order of traffic and commercial weight. Each builder page got a decision: rebuild it from the library, or retire it and redirect its URL. A page the library couldn’t yet cover stayed on the builder for now rather than getting a one-off section.
Implementation
The theme
I built the sections in Liquid with schema settings and blocks, sharing snippets for buttons, headings, links and images so those details are written once. Pages use JSON templates, so people arrange and edit sections in Shopify’s theme editor without touching code.
A heading setting separates the level from the visual size, so structure and appearance no longer pull against each other. Interactive pieces such as FAQs use native HTML elements wherever possible, which keeps script to a minimum.
The migration
I worked on an unpublished copy of the theme and checked each rebuilt page against the original before release:
- the content and links match
- the URL is unchanged, or a redirect is in place
- GA4 events fire as before, checked in Google Tag Manager preview
- the page works with a keyboard and at phone width
As pages came off the builder, I removed its leftover snippets and scripts from the theme so they stopped loading where nothing used them.
Handover
Each section carries a note on what it is for and where it should not be used. Adding a new one follows the same pattern as those already in the theme.
Outcome
Structural outcome: what changed in how the site works
Rebuilt pages are now assembled in Shopify's theme editor from a shared library of theme sections, with no dependency on the page builder. A change to a section's markup or styling flows to every page that uses it, instead of being repeated by hand on each one. New pages can be put together from existing sections by the people who run the site, without a separate tool or a developer for each layout.