Website Redesigns Built Around Conversion, Not Decoration
Most redesigns are judged on how the new site looks and discovered, months later, to convert worse than the old one. A conversion-led redesign starts somewhere else: with what your current site is already doing well, what your customers are actually trying to do, and what the data says is stopping them. The visual work happens after those answers exist, and the rebuild is measured against the site it replaced rather than against taste.
CRO strategy, design and development across Shopify, WordPress, Convert, Optimizely, VWO and Adobe Target.
Does this sound familiar?
These are the situations teams actually describe when they get in touch about this, not a generic list of pain points.
The last redesign made the numbers worse
The site looks current and converts less. Nobody can say which change caused it, because everything changed at once and there was no baseline worth comparing against.
The site was built for the business, not the buyer
Navigation mirrors the org chart, the page order reflects internal politics, and the thing a customer came to do takes four clicks to find.
Search traffic falls off a cliff at launch
URLs change without redirects, headings are rewritten by a designer, structured data is dropped and page speed regresses. The rankings go with them, and it takes months to notice and longer to recover.
Analytics does not survive the move
New templates, new markup, old tags. The events either stop firing or start meaning something different, so the first three months of the new site cannot be compared with anything.
The content was never rewritten
Old copy poured into new layouts. The site looks different and makes exactly the same argument it was making when the conversion rate was already disappointing.
Nobody can update it afterwards
The new site is beautiful and rigid. Six weeks in, marketing needs a page the templates do not support, and the developer queue starts again.
What changes when this works
Stated as the position you end up in. No percentages: we do not publish outcome figures without the measurement conditions and the client’s agreement to it.
- A site organised around what customers are trying to do, evidenced rather than assumed
- Conversion paths that are deliberate: every template has a job and a next step
- Search visibility carried across the move rather than rebuilt from scratch afterwards
- Analytics that still works on day one, so the new site can be compared with the old one
- Templates your marketing team can actually build pages with
- A measured answer to whether the redesign helped, instead of an opinion
What is included
Scope stated as specific outputs rather than as adjectives.
- Business and customer discovery: what the site has to achieve commercially, and for whom
- Analytics review of the existing site: which pages earn, which pages leak, which templates matter
- Voice-of-customer research: surveys, existing support and sales conversations, and reviews, read for the language customers use
- A sitemap and information architecture based on the tasks people arrive to do
- Conversion copywriting across the templates and key pages, not only the homepage
- UX wireframes for every template type before any visual design begins
- Visual design in Figma, responsive, as a component system rather than a set of page pictures
- Shopify, Shopify Plus or WordPress development, built for editors as well as visitors
- Technical SEO preservation: URL mapping, redirect plan, heading and metadata migration, structured data, internal linking
- Analytics migration: event and ecommerce tracking rebuilt and verified against the new markup
- Responsive and accessibility QA across templates, states and real devices
- Launch support, including a rollback plan and a monitored release window
- Post-launch conversion monitoring against the pre-launch baseline
How the work runs
- 1
Baseline the site you already have
Before anything is designed we record what the current site does: conversion rate by template, entry pages, revenue by page, search visibility, Core Web Vitals. You cannot tell whether a redesign worked without this, and it cannot be reconstructed afterwards.
- 2
Discovery and customer research
What the business needs the site to do, and what customers are actually trying to do on it. Surveys, existing conversations, reviews, and the behaviour already visible in analytics and recordings.
- 3
Architecture before aesthetics
Sitemap and information architecture built around those tasks, with the conversion path through each template made explicit. This is where most of the conversion difference is decided.
- 4
Write the site
Conversion copy for each template and key page, in the customer’s language, so the layout has an argument to carry.
- 5
Wireframe, then design
Wireframes per template type, reviewed against the conversion path, then visual design in Figma as a component system with every state defined.
- 6
Build, with SEO and analytics in scope from the start
Development on Shopify or WordPress, with the URL map, redirects, metadata, structured data and tracking treated as build tasks rather than launch-week discoveries.
- 7
QA, then a monitored launch
Responsive, cross-browser, accessibility and performance passes across templates. Launch with redirects verified, analytics verified, and a rollback path that has been tested rather than assumed.
- 8
Measure against the baseline, then optimise
Post-launch monitoring against the numbers recorded in step one, and the first round of the ongoing programme aimed at whatever the new site turns out to do worse.
What you receive
The artefacts that exist at the end, all of them yours to keep and to hand to somebody else.
- The pre-launch baseline document — the numbers the redesign will be judged against
- Discovery and customer research findings
- Sitemap and information architecture
- Final copy as editable documents
- Wireframes and the full Figma design system, with components and responsive frames
- The built site in a theme or repository you own
- The URL map and redirect list, plus a technical SEO migration record
- A tracking plan and verified analytics implementation
- QA records across templates, devices and accessibility
- A post-launch report comparing the new site with the baseline
What we need from you
Listed up front because these are what actually move a delivery date, not development time.
- Access to analytics, tag manager, Search Console and the current hosting or theme
- Brand assets and any brand guidelines that constrain the design
- Product, service and pricing information, and anything legally required alongside it
- Access to customers or to existing customer conversations for the research phase
- A named decision-maker per stage, and consolidated feedback rather than serial rounds
- Any proof you are permitted to publish, and confirmation of what you are not
Who this is for
Businesses whose site is now the constraint
Marketing, sales and support all work around the site rather than through it, and every campaign starts with a workaround.
Brands who have outgrown a template theme
The store was launched on a bought theme with a dozen apps bolted on. It works, slowly, and nobody wants to touch it.
Teams replatforming
A move between platforms is the one moment when conversion decisions are cheap to implement, and the one moment search traffic is most easily lost.
Companies who have already had a redesign go wrong
You have done this before and the numbers went down. You want the process to have evidence in it this time.
Who this is not for
Saying this up front saves both of us a call. If you are on this list, the right next step is usually elsewhere on this site rather than nowhere.
- Anyone who wants a visual refresh on the existing structure. That is a legitimate thing to buy and this is not it
- Teams who need the site live in a few weeks. Research, copy, design, build, migration and QA do not compress into that without dropping the parts that make it work
- Businesses unwilling to change navigation or messaging. If the architecture is fixed, most of the conversion upside is fixed with it
- Sites where the real problem is one template. Fix that one — usually as a landing page or a CRO programme — before replacing everything around it
An engagement of this kind
The problem, the hypothesis and what was actually engineered. We do not publish outcome percentages until the measurement conditions can be published alongside them and the client has agreed.
Theme rebuild: removing app bloat from a Plus storefront
- Problem:
- A large installed-app footprint, a mobile Largest Contentful Paint well outside the good threshold, and a legacy theme no developer wanted to touch.
- Hypothesis:
- A clean Online Store 2.0 Liquid rebuild with app-logic consolidation will recover the speed-driven losses.
- Execution:
- Custom design system into a clean Liquid architecture, redundant snippets removed, and a full Google Tag Manager datalayer schema.
Why us rather than the alternatives
Every one of these is a legitimate way to get the work done. Here is where each of them tends to break, so you can decide honestly.
Instead of a design studio
A studio will produce a better-looking site than most agencies can. What it will not usually do is baseline the old one, carry the search equity across, rebuild the tracking, or be accountable for the conversion rate afterwards.
Instead of a development shop
A build shop will implement whatever design arrives. If the architecture and the copy were never interrogated, a faithful build of a weak plan is exactly what you get.
Instead of a theme and an app stack
Fast to launch and it accumulates. Every app adds script weight to the templates that carry your revenue, and the total is nobody’s job. A built theme means the functionality you need and nothing running that you do not.
What a normal redesign does that this does not
A normal redesign starts with moodboards and ends at launch. This starts with the numbers the current site produces, treats search and analytics migration as build work rather than launch-week panic, and does not finish until the new site has been compared with the old one.
Platforms and technical scope
Named specifically, because “modern tooling” tells a buyer nothing.
- Shopify and Shopify Plus (Online Store 2.0 sections, blocks, metafields)
- WordPress with custom Gutenberg blocks, patterns and theme.json
- WooCommerce
- Next.js and React front ends, including headless and Hydrogen storefronts
- Figma component systems and design tokens
- Google Search Console, redirect mapping and structured data
- Google Tag Manager and GA4, including ecommerce event schemas
- Convert Experiences, Optimizely, VWO and Adobe Target for post-launch testing
How this gets checked
Every engagement carries a QA pass. It is written down so that “QA done” means something specific.
- Every template rendered and checked in every state it has, not only the pages in the design file
- Redirect map tested URL by URL before launch, and re-crawled after
- Headings, titles, metadata and structured data compared old against new, page type by page type
- Analytics and ecommerce events verified in GA4 DebugView on the new markup before release
- Core Web Vitals measured on the new templates against the recorded baseline
- Accessibility pass: heading order, labels, keyboard operation, focus visibility, contrast
- Editor experience checked — can a non-developer build the pages the marketing plan needs
- Rollback path tested rather than assumed
The full pass, including the post-launch checks, is described on our CRO and experiment QA service. It is also available on its own, on experiments somebody else built.
Ways to work together
The commercial shape is chosen after we know the scope, not before.
Dedicated partnership
Reserved capacity for a steady pipeline of work.
Flexible hours
Draw down specialist time as the work arrives.
Project engagement
A defined scope, owned end to end.
All three are described in full under engagement models.
Questions people ask before buying this
Related services
Experimentation platforms we build on
Further reading
Discuss My Website Redesign
Send us the current site and what you need it to do that it currently does not. We will come back with what we would keep, what we would change, and how the search and analytics migration would be handled.