An ecommerce website redesign judged on orders, not on looking new

Owners rarely call because of a design opinion. They call because something started costing money and the site is the visible suspect. The common triggers are a theme that has drifted three or four years behind how phones actually render, a mobile experience that converts far worse than desktop on the same traffic, a catalogue that outgrew the navigation it launched with, or a stack of plugins added one problem at a time that now fight each other. Each of those has a different correct fix, and only some of them are a redesign. Naming the trigger precisely matters more than picking a style direction, because the trigger decides the scope, the budget, and whether design is the lever at all. A project that starts with a moodboard instead of a diagnosis usually ends as an expensive repaint.

• The theme is old enough that mobile layout fights the content
• Mobile converts far worse than desktop on identical traffic
• The catalogue outgrew the navigation and filtering it launched with
• Years of plugins, added one at a time, now compete with each other

These words get used interchangeably and they are not the same purchase. A restyle keeps the current theme and templates and changes the surface: type, spacing, color, imagery, a cleaner header. It is the cheapest option and it will not fix speed, because the page weight underneath is untouched. A redesign changes the templates and the buying path — what a category page shows, in what order a product page argues, what the cart admits — while the platform stays as it is. A rebuild replaces the delivery layer entirely: the storefront becomes a Next.js application reading from WooCommerce, which is where the large speed and control gains come from and where most of the cost sits. Many stores need the middle option and assume they need the third. Our pricing starts at $1,999 and scales with catalogue size and template count, so the scope conversation happens before the invoice, not after.

Almost every fear about redesigning a store reduces to two: the search traffic disappears, and the orders stop. Both are real, both are preventable, and neither is prevented by taste. Traffic is lost when URLs change without redirects, when new templates quietly drop the internal linking and structured data the old ones carried, or when a staging site gets indexed alongside the live one. Orders break when checkout, payment gateways, tax and shipping rules, or a subscription plugin get rewritten as part of what was sold as a visual project. The default answer to the second risk is to not touch it at all: checkout stays native WooCommerce, so the payment stack behaves on launch day exactly as it did the day before. The first risk is handled by treating URLs and markup as inventory to be preserved rather than as design decisions.

• Map every existing URL before anything is rebuilt
• Preserve titles, headings, structured data and internal links per template
• Keep staging noindexed and out of the sitemap
• Leave checkout, payment, tax and shipping rules untouched by default

The boundary is firmer than most owners expect. WooCommerce and WordPress stay the system of record: products, variations, stock, pricing, coupons, orders, refunds, customer accounts, payment gateways, and the operational plugins your team depends on. Staff keep logging into the same admin and doing the same work in the same places, so there is no retraining line item. What changes is the layer the customer sees — templates, navigation, filtering, image delivery, cart — rebuilt as a separate frontend that reads from WooCommerce over its API. Nothing here requires exporting a catalogue or migrating a database. It also means a disappointing outcome stays recoverable: the data never moved, so reversing course is a frontend decision rather than a migration to undo under pressure.

• Stays: products, stock, pricing, coupons, orders and refunds
• Stays: payment gateways, tax and shipping rules, the WordPress admin
• Rebuilt: category, product, cart and content templates
• Rebuilt: navigation, filtering, image delivery and page performance

Visual work that does not change behaviour is decoration. The parts of a store that move orders are unglamorous: whether a shopper landing on a category from Google can narrow forty products to four without a full page reload; whether price, variant, stock and the buy action are visible on a phone without scrolling; whether shipping cost and return terms appear before the shopper has to guess at them; whether the cart shows a total that survives the next step. Baymard Institute's long-running checkout research keeps finding unexpected extra costs to be the most cited reason people abandon a cart, which is a content and sequencing problem inside the design rather than a payment problem. So the redesign gets drafted as the sequence of decisions a customer actually makes, and the visual language is chosen to serve that sequence. Attractive is a constraint on the work, not the brief.

Nothing gets rebuilt before the current site is recorded. We baseline the templates that carry revenue — category, product, cart, the top organic landing pages — for Core Web Vitals and for funnel behaviour, and export the URL and ranking picture from Search Console so there is a factual before. Then the work proceeds template by template rather than as one dramatic switch, starting with whichever template carries the most traffic or the worst numbers. Launch is a cutover with redirects already in place and every old path resolving. Afterwards the comparison is like-for-like: same templates, same journeys, real traffic, and enough weeks that field data outweighs seasonality. Google's published Core Web Vitals thresholds give one half of the verdict; add-to-cart rate and completed orders give the half that pays for the project.

• Baseline speed, funnel and rankings before a single template changes
• Ship template by template, heaviest traffic or worst numbers first
• Cut over with redirects live and old paths still resolving
• Compare the same journeys after launch, over weeks rather than days

There are stores we tell to spend the money elsewhere. Under a few thousand sessions a month there is not enough signal to know whether design is the problem, and the same budget put into acquisition or product will teach you more. If drop-off is driven by price, availability or shipping terms, a new layout will not repair it. If the site is structurally sound but slow, targeted WooCommerce speed optimization — image handling, caching, removing two plugins that duplicate each other — often recovers most of the performance for a fraction of the cost, and it is the honest first step. And if the store was rebuilt within the last eighteen months, the likelier fault is a handful of templates rather than the whole site. An audit that concludes with do not redesign is a good outcome, not a lost sale.

The deliverable is a storefront that a new visitor reads as current and a returning customer navigates without relearning it, built on templates you can extend instead of a theme you are afraid to touch. Concretely: rebuilt category, product and cart experiences; a navigation and filtering model sized for your real catalogue; performance and image work applied per template; redirects and markup preserved so the search footprint carries over; and a written handover of what changed and why. WooCommerce is still where the business runs, with the same admin and the same order flow. The measurement plan set up before launch stays in place afterwards, because the question a redesign has to answer is not whether it looks better — everyone agrees it does on day one — but whether the store sells more three months later.