How a headless rebuild of a WooCommerce store works

# TagsWooCommerceHeadlessMigration

The WPhost team11 Oct 202615 min read

Your WooCommerce store loads slowly, PageSpeed Insights shows red numbers, and the server barely copes with every campaign. A headless rebuild of a WooCommerce store replaces the storefront shoppers see, while the products, the orders and the admin stay the same.

Here we describe the rebuild step by step as the owner sees it, from the first measurement to the handover and the maintenance afterwards. We do not write about timelines or prices, because they depend on the store and are set out in the quote. At the end there is a checklist to go through before you accept the work.

How a headless WooCommerce rebuild starts

The rebuild starts with an audit, a review of the current store. We look at which plugins it has and what each one does, which services take part in the checkout, such as couriers, payments and invoices, and where the visitors come from. That shows what has to be built into the storefront and what keeps working in WooCommerce. On your side, it helps to tell us which features shoppers use most and what gets in your way in the current store.

Not every slow store needs a rebuild. Sometimes the cause is one heavy plugin, the hosting or the images, and it can be fixed without a new storefront. If the audit finds a cause like that, it makes more sense to fix it first. The most common causes are covered in our guide on why a WooCommerce store is slow and how to fix it.

Then we measure the speed in PageSpeed Insights on mobile on three pages: the home page, a category page and a product page. They bring the most visits, and each loads differently. The lab test gives a slightly different result on every run, so we run it several times. If the store has enough visits, PageSpeed Insights also shows data from real visitors over the last 28 days. These numbers are the baseline we compare against at handover. Our guide on how to measure site speed with PageSpeed Insights shows how to check them yourself.

What stays in WooCommerce

Products, orders and customer accounts stay in WooCommerce. You run the store from the same admin, add products, change prices and stock and process orders as before. There is no new system to learn, and your team keeps working the same way.

This is the big difference from moving a store to another platform. The data is not transferred to a new system, so the risk that comes with any such transfer falls away. What changes is the way shoppers see the store.

The WordPress theme and the plugins that shape the public site are no longer seen by shoppers. Plugins that work with orders in the admin usually stay, as long as the storefront gives them the data they need. Which ones stay and which features are rebuilt in the storefront becomes clear during the audit.

What the new store looks like inside

Shoppers open a storefront built with Next.js. It takes the products, categories and prices through the WooCommerce APIs. Pages are prepared in advance and refreshed in the background, so the shopper does not wait for WooCommerce every time a page opens.

The finished pages are kept in a cache and delivered through a CDN, a network of servers that keep copies close to the visitors. According to web.dev, this means the request does not have to travel to the origin server, and the time to first byte can improve significantly. Browsing products and categories puts no load on WooCommerce. It steps in when the storefront needs data it cannot prepare in advance, such as when an order is placed.

For shoppers this means a fast store. For you it means WooCommerce does far less work than when it served every visit on its own.

The checkout with Econt, Speedy and cash on delivery

The checkout page is part of the storefront. Choosing an Econt or Speedy office happens right in it, with data from the two couriers' APIs. Both publish lists of their offices and cities, as well as shipment services, so the shopper picks an office without leaving the checkout.

Cash on delivery stays, just as shoppers in Bulgaria expect. It is built into WooCommerce and needs no connection to a bank, so a cash on delivery order goes into WooCommerce as before, and the courier collects the money on delivery. According to the WooCommerce documentation, such orders stay in Processing status until the payment is collected.

Card payment is not part of the standard model. If you need it, we agree on it for the specific project, because it depends on the bank or payment provider and needs its own connection to it. If you take card payments, mention it in the first conversation so that it is in the quote.

What happens when WooCommerce does not answer

In a classic store, the order depends on the server at the moment the shopper presses the button. If WooCommerce is overloaded or briefly down, the shopper sees an error and the order may be lost, often along with the shopper.

In our headless model the order goes through a queue. The storefront accepts the order and records it in the queue, and from there it reaches WooCommerce. If WooCommerce does not answer at that moment, for example because of an update or heavy load, the order waits in the queue and goes into WooCommerce as soon as it answers again. That way no order is lost, even when WooCommerce does not answer.

For you, this means a short WooCommerce outage does not cost orders. They show up in the admin as soon as WooCommerce answers.

How Kubernetes handles traffic peaks

The storefront runs on Kubernetes, a system that manages applications across several servers. Visitors are spread across several identical copies of the storefront.

When traffic grows, for example during a campaign or a sale, Kubernetes starts more copies. When it falls, the extra ones are stopped. The Kubernetes documentation calls this horizontal scaling, where increased load is met with more copies of the application rather than more resources for the copies already running. The smallest and the largest number of copies are set in advance.

Everything runs in the cloud, in an account in your name, and the domain and the data stay yours. WooCommerce also needs a good server, but its load is much lower, because browsing is handled by the storefront and the cache.

The address map and 301 redirects

The store has rankings in Google that it has built up over time, and they are tied to the addresses of its pages. So before launch we make an address map, a list that pairs every old address with its new one. It is based on the sitemap, the products and categories in WooCommerce and the pages that bring visits according to the Performance report in Google Search Console.

It is best if addresses do not change at all. The storefront can keep the structure WooCommerce uses by default, for example /product/ for products and /product-category/ for categories. Where an address does change, the old one is permanently redirected to the new one.

A permanent redirect uses the code 301 or 308. Google treats the two codes the same way and takes the new address as the main one. Next.js, for example, returns 308 for a permanent redirect, so do not worry if a check shows that code.

Google advises keeping the redirects for as long as possible, generally at least a year, and says temporary fluctuation in rankings during the move is normal. Along with the addresses, the meta descriptions, structured data, canonical addresses, sitemap and hreflang for the languages move to the storefront. Our guide on how to redesign a site without losing your Google rankings covers the move in detail.

Building and testing in Git and staging

Everything is built in Git and in staging. Git is a system that keeps every change to the code and allows going back to an earlier version, and staging is a test environment separate from the real store. Nothing is tried out on the live store first, so shoppers never see unfinished work.

You see the new store in staging and approve it before it goes public. Look through it as a shopper, on a phone and on a computer, and go through the whole path from a product to the order.

Before launch we check the essentials:

Test orders with every delivery method and with cash on delivery reach WooCommerce with the correct data.
Every address on the map leads to the correct new page.
The titles, meta descriptions, structured data and sitemap are in place.
The speed of the home page, a category and a product is measured in PageSpeed Insights.

The launch and the rollback plan

The store launches with a rollback plan. It sets out exactly what is done if something important does not work after launch, who does it and how the store returns to its previous state. It is best to launch at a quiet time for orders and to check the first orders afterwards carefully.

Here the model has one advantage. Products, orders and customer accounts do not move out of WooCommerce, so a rollback affects only the storefront. The data stays where it was, and orders from the new storefront are recorded in the same WooCommerce.

The report at handover

On the day of handover we measure again in PageSpeed Insights on mobile, on the same pages as in the audit, and give you the report. The speed score is 90+, and for SEO we aim for 100. That gives you the before and after numbers, measured the same way.

The real-visitor data at the top of the report is collected over 28 days, so the improvement shows up there gradually. The lab test shows the new result straight away.

The result also depends on what is added later. Ad pixels, chat widgets and other third-party scripts lower it, so it is best to check them together before they go into the store.

Maintenance after launch

The store needs care after launch too. WordPress, WooCommerce and the plugins get security updates, and the Next.js application has its own dependencies that also need updating. Maintenance is not required, but without it nobody checks for vulnerabilities every day or updates in time.

With active maintenance, we check the plugins, the theme and WordPress against the known vulnerability (CVE) databases every day and update them in time, after a test in staging. What the plans include is described under monthly maintenance.

Checklist

You have a PageSpeed Insights measurement of the home page, a category and a product from before the rebuild.
You know which plugins stay in WooCommerce and which features are rebuilt in the storefront.
If you take card payments, they are agreed in the quote.
The address map is ready, and every changed address has a permanent redirect.
You have seen the store in staging and approved it.
The test orders with Econt, Speedy and cash on delivery have reached WooCommerce.
You know what the rollback plan says and who carries it out.
You have received the measurement report on the day of handover.
You know who updates WordPress, WooCommerce and the storefront after launch.

Do you have to go through all this yourself?

If your store is small and fast, classic WooCommerce is enough and you do not need a rebuild. Our guide on choosing between classic WooCommerce and a headless store helps you judge. If your store is slow and growing, the page on rebuilding a WooCommerce store describes how we do it on our headless model. Shoppers get a fast Next.js store, and you keep working the way you do now.

Frequently asked questions

What is a headless rebuild of a WooCommerce store?

A headless rebuild replaces the storefront shoppers see with a Next.js application, while products, orders, customer accounts and the admin stay in WooCommerce. The data is not transferred to a new system, so the risk that comes with any such transfer falls away. You and your team keep working in the same admin as before.

Does every slow WooCommerce store need a headless rebuild?

No. Sometimes the cause of a slow store is one heavy plugin, the hosting or the images, and it can be fixed without a new storefront. That is why the rebuild starts with an audit, and if the audit finds a cause like that, it makes more sense to fix it first.

Will I have to learn a new system after a headless rebuild?

No. Products, prices, stock and orders are managed from the same WooCommerce admin, and plugins that work with orders in the admin usually stay. Shoppers no longer see the WordPress theme and the plugins that shape the public site, and which features are rebuilt in the storefront becomes clear during the audit.

Does a headless store have Econt, Speedy and cash on delivery?

Yes. Choosing an Econt or Speedy office happens right on the checkout page, with data from the two couriers' APIs, so the shopper never leaves the checkout. Cash on delivery is built into WooCommerce and needs no bank connection, so such an order goes into WooCommerce as before. Card payment is not part of the standard model and depends on the bank or provider, so mention it in the first conversation.

What happens to orders if WooCommerce does not answer?

In WPHost's headless model the order goes through a queue. The storefront accepts the order and records it in the queue, and if WooCommerce is not answering at that moment, because of an update or heavy load for example, the order waits and goes into WooCommerce as soon as it answers again. So a short WooCommerce outage does not cost orders.

How does a headless store cope with traffic peaks?

The storefront runs on Kubernetes, and visitors are spread across several identical copies. During campaigns and sales Kubernetes starts more copies and stops the extra ones when traffic falls, with the smallest and largest number of copies set in advance. Browsing products goes through the cache and the CDN and puts no load on WooCommerce.

Will the store lose its Google rankings after the rebuild?

Before launch an address map pairs every old address with its new one, and it is best if addresses do not change at all. Where one does change, the old address gets a permanent redirect with code 301 or 308, which Google treats the same, and the meta descriptions, structured data, sitemap and hreflang move to the storefront too. Google says temporary ranking fluctuations during a move are normal and advises keeping redirects for at least a year.

What do I get when the headless store is handed over?

On handover day the speed is measured again in PageSpeed Insights on mobile, on the same pages as in the audit, and you get the report with a speed score of 90+. Real-visitor data is collected over 28 days, so the improvement shows up there gradually. Ad pixels, chat widgets and other third-party scripts added later lower the score.

Sources