Building a WooCommerce Store Where the Money Goes Furthest

The store went live with a page builder, an ecommerce add-on for it, five extensions and a budget spent before the product photography was done. Six weeks later the owner could describe every feature in the admin. Four orders had come in. Two came back as emails asking where the receipt went. One customer filled a cart on a phone, went to find a card, and returned to an empty cart.

None of those three failures was a missing feature. The cart was lost to a session cookie that the host's page cache served past. The receipt was filtered because the envelope sender and the From header pointed at different domains. The product page rendered slowly enough on a mid-range phone that the add-to-cart button was unusable for the first seconds. Everything installed was working. The money was somewhere else.

That is the shape of the problem. A catalogue is organised by feature, so that is how a new store owner learns to spend, and the three things that decide whether the store earns anything are not line items in that catalogue. They are configuration, infrastructure and one record in DNS.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. That does not change the price you pay, and it does not change what this piece recommends: the categories this article says not to buy yet are named below, and every paid recommendation is printed next to the free or do-without option that is genuinely enough for some stores.

The order of spending is not the order of the catalogue

Sort the spend by what it protects. Three things cost a store money in sequence, and each sits downstream of the last.

• Checkout is the last step and the only one where a failure discards every effort before it. A shopper who cannot complete an order does not come back to report a bug.
• Order mail is the only channel reaching a customer after the money has been taken. A receipt in spam becomes a support ticket, then a dispute, then a chargeback on a card the store paid to accept.
• Render time on a phone is charged on every page, in bounce and in the discount search engines apply to a slow mobile result.

The order is: money path, mail, phone render time, then features. Most new stores invert it and spend the second year buying plugins to compensate.

Checkout first, because every other fix is downstream of it

WooCommerce stores a cart against a cookie and a row in its own sessions table. Two things break that arrangement, and both are configuration. The first is a page cache that stores the cart and checkout pages, so cached HTML goes out before WooCommerce reads the session and a shopper with a valid cart sees the empty-cart notice. The second is a cookie scoped to the wrong host, which happens when a store serves both www and the apex domain, or moves to HTTPS without updating the site URL. The cart is written under one host and read under another.

Both are findable in an afternoon with a private window, a cache purge and the network panel. Add something on the phone, wait ten minutes, reload. If the cart is gone, nothing else on this list matters yet.

Then look at the free settings that are already off. Guest checkout is a checkbox, and a store demanding a password at the moment of highest intent is asking for a reason to leave. Sale price scheduling is core, so a discount starts and ends without anyone being awake. Shipping zones and classes cover most flat-rate and weight-based rate cards, and additional checkout fields are a block in the checkout editor, not a plugin. The WooCommerce documentation covers all of it without a licence.

The one thing on the checkout page worth paying for is a payment method, not a design. It is the only checkout spend with a direct causal link to revenue, because a missing method produces an abandoned cart with an obvious reason attached. It is billed per transaction rather than per year, adds no licence to renew, and shows up in the first month of orders. A store whose buyers already use the one method it accepts does not need this line item at all.

Order mail is a purchase, not a plugin setting

WordPress builds the message and hands it to PHP's mail function; the local mail transfer agent decides what happens next, and on a shared host it sits on an IP shared with hundreds of other sites, some of them sending junk. The From header is set by WooCommerce from a filter, while the envelope sender is left to PHP. SPF is checked against the envelope sender, DKIM against the domain in the d= tag, and DMARC needs one aligned with the From domain the customer sees. With nothing configured none of that aligns, and the receipt lands in spam or the promotions tab, which for a receipt is the same failure.

That is fixed with DNS records and a relay, the cheapest fix here. A transactional email service gives the store a sending domain it controls, an SPF include, a DKIM key and a bounce feed, and the confirmation, shipping notice and password reset then arrive. Free tiers exist and are measured in messages per month; check the current allowance, since vendors revise it. For a few dozen orders a month a free tier with correct DNS is genuinely enough.

What is not enough is the pattern most stores land on: an SMTP plugin pointed at a mailbox on the same shared host. It repairs the mechanics, which is worth something, and leaves the reputation where it was, which is the part causing the problem. The other mistake worth naming is routing marketing mail through the receipt domain. One campaign that draws complaints drags the order confirmation down with it; separating them costs a subdomain.

Mobile render time is the third bill

A catalogue page is a query, a loop, and a card per product, each pulling an image and usually a price and a term list. That is cheap by itself. It becomes expensive when the theme, the builder and the extension stack each add a stylesheet and a script to thirty cards, and when the images served are the ones uploaded rather than the ones the browser needs. The thresholds are public: largest contentful paint under two and a half seconds, layout shift under a tenth, interaction latency under two hundred milliseconds. A product page on a mid-range Android phone is where those numbers are decided.

Two costs are worth measuring first. WooCommerce's cart fragment script makes a background request to ?wc-ajax=get_refreshed_fragments on page loads, including for visitors with an empty cart, which is overhead on a page that shows no cart; the block-based cart does not need it. And every catalogue image is generated in the sizes the theme registers, so a theme with a large hero size produces a large file on a grid card that displays at a third of that width. Correcting the sizes and letting WordPress serve the WebP version it already generates costs nothing.

The paid answer at this layer is hosting with CPU headroom and a cache the store controls, and it is right when the bottleneck is PHP time. It is wrong when the bottleneck is a four-megabyte hero image: paying for a faster server to deliver that image faster is how stores end up with a large monthly bill and an unchanged score. Measure first, then buy the layer that measured slow. A caching plugin and a CDN free tier are enough for a few hundred products.

What can stay free for a year

Most of what a new store is told it needs is already in the box. Coupons, sale price start and end dates, tax classes and rates, shipping zones and classes, stock management, guest checkout, order notes, partial refunds, customer accounts, product CSV import and export, reviews, related products, a shop archive, and reporting that answers what sold this month. The cart and checkout are blocks now, so the storefront can be built in the core block editor on a block theme, with no builder licence and no template files to maintain through a core update.

Three free substitutions are better than the paid versions for a new store, not merely cheaper. Core's image handling, which generates the sizes and the WebP copy, beats an optimisation extension that repeats the work at request time. Core analytics beat a reporting dashboard until the question stops being what sold and becomes which product has a margin problem. And block templates beat a builder's ecommerce templates because they are the markup WooCommerce tests against.

What cannot stay free is a short list, because core genuinely does not cover it: recurring billing, bookings, memberships, multi-currency selling, and shipping rates pulled live from a carrier. These are the categories where an extension is not a duplicate of a setting. The WooCommerce Marketplace extension catalogue is where WooCommerce lists the extensions it vets for compatibility with its own APIs, and it is the right place to look once a business model needs one of those five. Read the licence lines before the feature bullets: renewal terms, how many sites the licence covers, and what support stops doing if a renewal is skipped in year two.

What not to buy yet

A page builder with an ecommerce add-on. This puts a second rendering stack on the product page and a third-party cart and checkout widget on the two pages where money changes hands. The builder renders the layout and WooCommerce supplies the data, so when core changes the checkout markup it is the add-on that lags. Meanwhile the builder's stylesheets and scripts load on the cart and the checkout, where nothing needs designing and everything needs to be fast. A builder is defensible for a brochure site. For a store it makes the pages that decide revenue the slowest and least testable ones on the site, in exchange for layout control blocks already provide.

Five extensions that each promise conversion. The usual set is a countdown timer, an urgency badge, an exit-intent popup, a social proof ticker and a one-click upsell. Each ships its own JavaScript onto the checkout, several lock the scroll position, and any two can fight over the same modal layer. Each carries a renewal and is measured in a vendor dashboard with the vendor's own attribution window. None touches a session that expired or a receipt in the spam folder, which is where the orders went. Switch one off for two weeks and see whether the order count changes. Mostly it does not, and the honest conclusion is that it was decoration.

Anything that adds a licence to a plugin that does something core already does. Scheduled sales are core sale price dates. Related products are core. Filters by category and attribute are the block archive's own query controls. A PDF invoice extension does work the order email plus the browser's print dialogue already does for a shop posting a handful of parcels a day. Abandoned cart recovery is bought to fix a deliverability problem solved at the DNS level. In each case the paid version sells a nicer admin screen for a setting already in WooCommerce, and no customer sees that screen.

The rule: four payments, in this order

First the money path: cart and checkout outside the page cache, one consistent host, guest checkout on, refunds and tax configured, and a payment method the buyers actually use. Second the sending domain: SPF, DKIM, a relay that reports bounces, receipts separated from marketing. Third the render time on a mid-range phone, measured before it is paid for, with the slow layer identified first. Fourth, and only then, one paid extension for a business model core does not cover, read for its renewal terms.

The rule generalises to any future purchase. If the store has an authenticated sending domain, a checkout that survives a cache purge and a product page that renders in under three seconds on a phone that is not new, it has already collected most of the revenue available to it. Anything bought after that is optimising a smaller number, which is a fine thing to do with a budget that has already protected the large one. A store that inverts the order spends the same money against the current.