eCommerce Rebuild for Growth

This page describes a representative web shop rebuild. The client is not named, and we do not publish a before-and-after sales figure. The useful part is the shape of the work: an aging WooCommerce store that staff could no longer keep, rebuilt so a small team could run products, orders, and content without a developer on every change.

The situation

The shop was already taking orders. That is why a rebuild is harder than a new store. Customers had accounts, old orders, and product URLs that other sites and emails still pointed at. The theme had been edited by more than one person. Checkout worked on a desktop and broke in small ways on a phone. Stock lived in WooCommerce and also in a spreadsheet the warehouse trusted more. When those two disagreed, staff corrected the shop by hand.

The brief was not "make it faster." Speed mattered, but the owner could not say what a good page load was, and we will not invent one. The brief was that a product change took too many steps, mobile checkout lost people for reasons nobody had written down, and the next festival sale could not depend on the person who last touched the theme.

What we took on

We kept WooCommerce. Replacing the cart because the theme was tired would have thrown away order history and the payment setup that already worked. The web development work was a new theme, a cleaner product structure, and a checkout path that a phone could finish.

We listed every URL that already ranked or appeared in customer email, and we kept those paths. A rebuild that changes /product/name into a new pattern looks fresh in a design file and then loses the pages Google already knew. Where a path had to change, we added a redirect. We did not treat the redirect list as optional cleanup.

Product data moved in a defined order: categories, then products, then variations, then the images that belonged to them. We did not import the whole catalog on the last Friday before a sale. A sample of orders was checked against the old shop so totals, tax, and shipping lines still made sense. Payment and shipping plugins were tested with a real small order, then refunded, before the DNS cutover.

What shipped

The storefront is mobile-first. Product pages lead with the price, the variant, and the add-to-cart action. The old page led with a banner and a long description the buyer had to scroll past. Category pages show stock state in plain language. Checkout asks for the address once. Account pages let a customer see an order without calling the shop.

Staff editing is the other half of the launch. Product copy, a banner, and a category description can be changed in WooCommerce without opening the theme. The theme does not contain a one-off price or a festival date. Those live in the catalog, where the next person can find them.

What we refused

We did not add a second app for the warehouse in the same release. The spreadsheet stayed until the shop stock was trusted. We did not promise a conversion rate. We did not install a pile of plugins to recreate the old homepage animation. Each plugin is another update that can break checkout, and checkout was the page that had to stay boring.

What a similar project needs from you

A list of the URLs you cannot lose. Access to the current WordPress admin, the host, and the payment account. One person who can confirm a product, a price, and a shipping rule. A date that is not inside a sale week. If you want this kind of rebuild, start from the web development page or message us on WhatsApp. We will tell you if the shop should be rebuilt or only repaired.