The WooCommerce Build Standard: Twelve Questions to Ask Before You Commission a Store

“We build WooCommerce sites” is very close to saying nothing. According to W3Techs, WooCommerce is used by 47.8% of all e-commerce systems and 8.0% of all websites — so almost every agency you speak to builds WooCommerce sites, and the phrase tells you nothing about whether the result will be fast, maintainable, or yours.

What separates a good WooCommerce build from a bad one is a set of specific engineering decisions, most of which are invisible in a proposal and all of which you live with for years.

So here is the standard we build to, published in full. Use it to interrogate any quote you receive, including ours.

First: what “custom” usually means

The word is used to describe three very different things. Worth separating them, because the price difference is large and the word is not.

Route 1 — A bought multipurpose theme, configured

A commercial theme with a page builder and a stack of plugins to fill the gaps. This is how most WooCommerce stores are built and it is often sold as “custom” because the colours and content are yours.

When it is right: a modest catalogue, standard selling, a tight budget, and a need to be trading quickly. It is a perfectly legitimate route and we would recommend it over an unnecessary bespoke build.

What you accept: the theme loads everything it can do, not what your store does. Its update path is controlled by a third party. Deep changes fight the theme rather than extend it.

Route 2 — A child theme with custom templates

A lightweight, well-maintained parent theme, with a child theme carrying your own templates and code. Most well-built stores sit here, and this is where the standard below mostly applies.

Route 3 — A bespoke theme

Built from nothing for this store. Justified by genuinely unusual requirements, a large catalogue, or an operation with rules that no theme anticipates. Rarely justified by aesthetics alone.

An honest supplier will tell you which of these three you actually need. A less honest one sells route 3, delivers route 1, and calls it bespoke.

A. Structure — the decisions that determine whether it survives

1. A child theme, always

Customisations live in a child theme, never in the parent theme and never in WooCommerce itself. Edit a parent theme and the first update overwrites your work — so either the store breaks or nobody dares update it, which is worse, because an unupdated commerce site is a security problem rather than a cosmetic one.

Ask: “Where does custom code live, and what happens to it when the theme updates?”

2. Template overrides through WooCommerce’s own hierarchy

WooCommerce provides a documented template structure precisely so a build can replace individual templates without touching the plugin. Changing product or checkout layout means overriding the relevant template in the child theme — not editing plugin files, and not bolting a page builder over the top.

Ask: “Which WooCommerce templates are you overriding, and are any plugin files modified?” The correct answer to the second half is none.

3. Hooks and filters instead of rewrites

WooCommerce exposes hooks at nearly every meaningful point. Adding a field, changing an email, altering how a price displays — all of that attaches to a hook. Code that hooks in survives updates. Code that replaces core does not.

This is the single largest determinant of what your store costs to own over five years, and it is invisible at launch. Both approaches look identical on day one.

4. Version control, and a way back

The site is in version control, changes are reviewable, and there is a route to undo a bad deployment. If your developer’s backup strategy is the hosting company’s nightly snapshot, that is a restore plan, not a development process.

Ask: “Is the site in version control, and can I have access to the repository?”

B. Performance — with numbers attached

Commerce is where slowness is most directly expensive, and the targets are not a matter of opinion. Google’s Core Web Vitals define three thresholds, assessed at the 75th percentile of page loads and segmented by mobile and desktop:

• Largest Contentful Paint (LCP) — 2.5 seconds or less. How long until the main content appears.
• Interaction to Next Paint (INP) — 200 milliseconds or less. How quickly the page responds when someone taps.
• Cumulative Layout Shift (CLS) — 0.1 or less. How much the layout moves while loading.

Those are the numbers a build should be held to. Note the 75th percentile: passing on your own laptop is not passing.

5. The checkout is not a page builder layout

Of everything here, this is the one we would argue hardest. Checkout is the highest-stakes page on the site and the one most sensitive to interaction delay. Building it out of page-builder components loads a rendering framework into the exact place where responsiveness converts to money.

Checkout should be a template, styled properly, with fields controlled in code.

6. Load what the page needs, and nothing else

The characteristic failure of the theme-plus-plugins route is that every page loads every library. A slider script on a page with no slider. Product gallery scripts on the basket. Individually trivial, collectively the difference between passing INP and failing it.

Ask: “How do you control which scripts and styles load on which templates?”

7. Images treated as a build concern

Correct sizes generated for the places they are actually displayed, modern formats, compression, dimensions set to prevent layout shift, and lazy loading below the fold — but never on the main product image, which is usually your LCP element.

8. Catalogue queries that scale

A store with 80 products and one with 8,000 are different engineering problems. Filtered category pages, faceted search and variation-heavy products all generate expensive queries. This is worth raising before the build rather than after the catalogue grows.

Ask: “What happens to page speed when the catalogue is ten times bigger?”

C. Commerce — modelling how you actually sell

9. The product data model matches the business

The most consequential decision in a WooCommerce build, and it is made early and quietly: what is a product, what is a variation, and what is an attribute.

Get it wrong and everything downstream suffers — stock becomes inaccurate, filtering does not work as customers expect, reporting is unusable, and fixing it later means migrating data rather than changing a setting. Get it right and a lot of apparent complexity disappears.

10. Delivery and pricing rules in code, not in ten plugins

Rules like delivery by postcode radius, surcharges for bulky items, trade pricing for account customers, lead times that vary by option. Each is available as a plugin; installing six of them produces a store where nobody can predict what the basket will do.

Where rules are specific to your business, implementing them deliberately is usually cheaper over time than assembling them from plugins that were not written to work together.

11. Checkout field discipline

Every field is friction. The build should collect what is genuinely needed to fulfil and account for the order, and nothing gathered because it might be interesting later.

D. Ownership

12. It is yours, and someone else could work on it

Standard WordPress and WooCommerce practice, documented customisations, no proprietary framework only your agency understands, and full administrator and hosting access from day one.

The test is simple: could a competent developer who has never met your agency pick this up? If the honest answer is no, you do not own your store in any meaningful sense — which is the same ownership argument that applies when choosing between WooCommerce and a hosted platform in the first place.

The twelve questions, in one place

Take these to any developer quoting for a WooCommerce build, ours included. The answers separate suppliers far more reliably than a portfolio does.

• 1. Where does custom code live, and what happens to it when the theme updates?
• 2. Which WooCommerce templates will you override, and will any plugin files be modified?
• 3. Will customisations use hooks and filters, or replace core behaviour?
• 4. Is the site in version control, and can I have access?
• 5. What LCP, INP and CLS figures are you targeting, and measured how?
• 6. Is the checkout a template or a page-builder layout?
• 7. How do you control which scripts and styles load on which pages?
• 8. How are product images sized, compressed and served?
• 9. What happens to performance if my catalogue grows tenfold?
• 10. How will you model my products, variations and attributes — and why that way?
• 11. Are my delivery and pricing rules implemented deliberately, or assembled from plugins?
• 12. Could another developer take this over without retraining?

A good supplier will enjoy these questions. A supplier who becomes vague around numbers 3, 6 and 12 is telling you how the build will actually be done.

What this standard will not do for you

• It will not make a bought theme wrong. Plenty of successful stores run on commercial themes. If your selling model is standard and budget is the binding constraint, that is the correct decision and this standard mostly does not apply.
• It will not sell anything on its own. A technically excellent store with unclear product photography, thin descriptions and no delivery information will underperform a mediocre store that gets those right. Build quality is a floor, not a growth strategy.
• It will not survive neglect. WooCommerce and WordPress both update frequently. A store built to this standard and then left alone for two years is still a store left alone for two years.
• It will not guarantee the Core Web Vitals thresholds. Those are field measurements taken from real visitors on real devices and networks. A build can be designed to hit them and should be measured against them — it cannot promise them, and anyone who does is describing a lab result.

What we build

We build WooCommerce stores to the standard above — usually route 2, occasionally route 3 where the operation genuinely warrants it, and we will say so when route 1 would serve you better and cost you less.

Our website builds that include e-commerce start at £7,995, quoted against an agreed scope, built in WordPress and handed over with full administrator access. Where a store already exists and the problem is performance or structure rather than appearance, that is often a rebuild of what is there rather than a fresh start — and sometimes it is just the things making it slow, which is a smaller piece of work.

Sources and method

• WooCommerce usage share: W3Techs, retrieved 10 September 2026 — 47.8% of all e-commerce systems, 11.7% of sites with a known CMS, 8.0% of all websites. W3Techs surveys the top 10 million sites; treat it as a well-established indicator rather than a census.
• Core Web Vitals metrics and thresholds: web.dev — LCP 2.5s, INP 200ms, CLS 0.1, assessed at the 75th percentile segmented by mobile and desktop. These are Google’s published definitions and they have changed before; INP replaced First Input Delay as a Core Web Vital.
• The build standard itself is ours, based on our own WooCommerce work. It is opinionated, and points 3, 6 and 9 are the ones other developers most often disagree with. Reuse it, adapt it, argue with it.
• No performance, conversion or revenue figures are claimed here. We have not measured a representative sample of stores and are not going to publish numbers we cannot stand behind.

Common questions

Is a custom WooCommerce build always better than a theme? No. It is better when your selling model is unusual, your catalogue is large, or you intend to keep the store for years and change it often. For a standard catalogue on a tight budget, a good commercial theme is the sensible answer.

Can you work on a store somebody else built? Usually, and the first job is establishing what was done to it — whether core files were edited, whether there is version control, what the update path looks like. Occasionally that assessment concludes that rebuilding is cheaper than untangling.

Does a page builder mean the store is badly built? Not by itself. Using one for marketing pages is reasonable. Using one for the checkout and product templates is where it becomes a performance and maintainability problem.

How many plugins is too many? The count is the wrong measure. Overlap is the problem — two plugins doing similar jobs, or six assembled to produce one behaviour. One well-chosen plugin beats three that nearly work.

What about headless WooCommerce? A legitimate architecture for a minority of stores and considerable added complexity for most. If it comes up in a proposal, ask what specific problem it solves for your store. If the answer is speed, there are usually cheaper routes to speed first.

Will this hurt my SEO if we rebuild? It can, if URLs change without redirects, or if content is dropped in the move. A rebuild should include a URL map and redirects as a matter of course — ask whether that is in scope, because it is a common omission.

The short version

WooCommerce runs nearly half the e-commerce sites on the web, so the platform tells you nothing about the quality of what you are buying. The build decisions do — child theme, template overrides, hooks rather than rewrites, a checkout that is not a page-builder layout, a product model that matches how you sell, and code another developer could take over.

Ask the twelve questions. The answers will tell you more than any portfolio.