A replatform puts existing search performance at risk, and it is the one point where URL and template decisions can still be changed cheaply. This sets out where we can help before, during and after the move.
Organic search brought 933,693 clicks to the three storefronts over the last 12 months. That is what the migration puts at risk. Google Search Console, August 2025 to July 2026
Three things need deciding before templates are written: collection taxonomy and URL structure, pagination, and the redirect map.
Most of what follows is optional, and most of it is after launch. What we’re asking for now is a short session on the migration timeline.
Varley is moving from Hydrogen back to Liquid. That decision creates a window where a number of things become cheap to fix — and, if they’re missed, expensive to retrofit once the new templates are live.
This is a plain list of what we can take on, where we’d add most value, and what we’d recommend happens in what order. It’s meant as a reference rather than a proposal.
Organic clicks over the 12 months to July 2026. This is the traffic the new build has to carry across intact.
The three storefronts don’t move as one. Each has its own URL patterns and its own hreflang relationships with the other two, and Liquid hands that routing to Shopify Markets rather than handling it in code. All three have to survive the move together.
Source: Google Search Console · August 2025 to July 2026
Anything unresolved when the build starts gets carried into the new templates and has to be fixed twice. Most of the URL change is set by the platform rather than chosen — Liquid serves collections, products, pages and articles at fixed paths. The choice is whether that change is designed once, now, or discovered during build and redirected twice.
This is the part that decides whether organic performance holds. We run this as a governed checklist rather than a review at the end, because most migration losses are only visible weeks later.
A cleaner template layer makes a lot of previously awkward work straightforward.
The three windows above are where we sit relative to your build. These five phases are how we run our side of it — 01 and 02 sit in Before, 03 and 04 in During, 05 in After. Nothing progresses to the next stage until the previous one is signed off. At launch we give a clear go or no-go against the checklist. The call is yours — our job is to make sure it’s made with the risks written down rather than discovered afterwards.
We’re part-way through a replatform for another ecommerce client on exactly this process. It runs to 120+ tracked tasks across 15 workstreams, each with an owner, a priority and a launch dependency. The workstreams cover redirects, on-page parity, structured data, content migration, image hosting, rendering, performance, apps and integrations, tracking and consent.
That project runs in the opposite direction to yours — into headless rather than out of it. The platforms differ; the places a migration loses traffic don’t. We can share the redacted task register and a signed-off gate document if that’s useful.
Source: Searchflex migration programme, live engagement 2026 · client anonymised
We’re not looking to duplicate whatever your development team is already doing. Their job is to build the platform; ours is to make sure the build doesn’t cost visibility and that the commercial opportunities get designed in rather than bolted on.
In practice that means we specify, they implement, and we verify. Where it’s more useful for us to build a piece ourselves, we can do that instead.
Your build team owns the platform. This section only applies where you tell us there’s a gap. A replatform is a design and front-end project as much as a technical one, and these are the pieces of it we can take on. Recent examples of each are available on request.
A UX, SEO and CRO review of the current templates with a prioritised list of what to fix and why.
Low-fidelity, greyscale layouts of the key templates. Hierarchy, content order and components resolved before any visual design.
Full, on-brand visual designs in Figma. Responsive across breakpoints, real content, every state considered.
A clickable prototype of a key flow — checkout, a product finder, faceted browsing — that stakeholders can sign off and that can be user-tested before we build.
We build the templates and sections in Liquid, either handing your developers a production-ready front end or pairing with them to move faster.
A reusable component library and design tokens, documented so your team can extend the site consistently long after launch.
Not all of it is needed, and not all of it is needed now.
Protecting what the site already earns.
Covering demand the current structure can’t reach.
Turning the traffic into revenue — and building it if you want us to.
Knowing what actually happened, before and after launch.