The WooCommerce Store Launch Checklist: Sell From Day One

A WooCommerce launch checklist is the difference between a store that sells from day one and a store that spends its first three weeks apologising to customers. I have launched and rescued a lot of WooCommerce stores over 12 years, and the pattern is remarkably consistent: launches almost never fail on design. They fail on operations – a payment method that errors for half the visitors, tax rates that are wrong for one country, shipping costs that quietly lose money on every parcel, order emails landing in spam, or a missing withdrawal policy that turns into a legal letter. All of it is checkable before launch, and none of it is glamorous, which is exactly why it gets skipped.

This guide is the checklist I actually run before a store goes live for a client – organised around the three areas that decide whether the first real order works: money, legal and logistics. We will go through products and inventory, the money path end-to-end (test orders, refunds, payouts), taxes and invoices, shipping, transactional emails, EU legal requirements, accounts and guest checkout, performance and security, analytics, and then the launch itself: soft launch, launch-day runbook and what to watch in the first month. Work through it top to bottom and your launch day becomes boring – which is the goal.

Table of contents

• Why store launches fail on operations, not design
• Products: data completeness before anything else
• The money path: test every way money moves
• Taxes and invoices: configured, not assumed
• Shipping: zones, rates and real packaging costs
• Transactional emails: firing, branded, not in spam
• Legal for EU stores: the non-negotiables
• Accounts, guest checkout and the buying journey
• Performance, backups and the security baseline
• Analytics: verify tracking before you need it
• Soft launch, launch day and the first month
• Frequently asked questions

Why store launches fail on operations, not design

By the time a store is ready to launch, the design has been reviewed a dozen times. Everyone has opinions about the homepage hero and the product grid. Almost nobody has placed a real order with a real card, requested a refund, checked whether the invoice shows the right VAT rate, or looked at the order confirmation email on a phone. The visible 20% of the store gets 80% of the attention, and the operational 80% – the part that takes money and gets products to customers – gets whatever time is left.

The consequences are not cosmetic. A broken payment method does not look broken; it just silently turns away every customer who preferred it. Wrong tax settings do not crash the site; they produce invoices your accountant rejects three months later. A shipping rate that ignores packaging costs loses you EUR 2 per order until someone does the maths. And in the EU, a missing terms checkbox or withdrawal policy is not a style issue – it is an invitation for a formal warning letter, which in Germany arrives with a bill attached.

So the checklist below deliberately spends most of its time on things a screenshot cannot show. The mental model is three pillars, and a store is launchable only when all three stand:

• Money: every payment method takes a real order, refunds work, payouts arrive, taxes and invoices are correct.
• Legal: the store meets the rules of the countries it sells to – for EU stores that means imprint, withdrawal rights, terms consent and GDPR.
• Logistics: products are complete and countable, shipping zones and rates match reality, and every transactional email reaches the inbox.

Products: data completeness before anything else

Product data problems multiply after launch, because every fix then happens on a live store with real orders attached. Before launch, audit the catalogue as a spreadsheet problem, not a design problem:

• Every product has complete data. Title, description, price, SKU, weight and dimensions (shipping calculations need them), categories, and at least one image. Export the catalogue to CSV and scan the columns – empty cells jump out in a spreadsheet in a way they never do in the admin.
• Images are consistent and optimised. Same aspect ratio, similar backgrounds, compressed to WebP. One 4 MB PNG on a bestseller will drag your product page speed down for months.
• Variations actually work. Click through every variable product and select every combination. Missing variation prices, out-of-stock combinations that still show, and attribute combinations that were never created are the most common catalogue bugs I find in launch reviews. If a product has 24 combinations, test 24 combinations – or at minimum every attribute value at least once.
• Inventory counts are loaded and honest. Enable stock management, enter real counts, set the low-stock threshold to something that gives you reorder time, and decide the backorder policy per product, deliberately. “Allow backorders” left on by accident sells stock you do not have.
• Prices have been double-checked against the source. Read every price against the supplier sheet or the old store. A misplaced decimal on one product is a launch-week story you do not want.

Also decide the catalogue structure now: categories a first-time visitor understands, attributes used consistently (one “Colour” attribute, not “Colour” and “color”), and no “Uncategorised” products. Restructuring categories after launch changes URLs and burns redirects.

The money path: test every way money moves

This is the heart of the checklist. The money path is the sequence from “customer clicks pay” to “money is in your bank account”, and every segment of it must be tested on the live site, with real payment methods, before launch. Test mode proves the plumbing exists; only live orders prove it works.

My routine: create a EUR 1 test product (hidden from the catalogue, direct link only), and buy it repeatedly:

• One live order per payment method. Card, PayPal, and whatever local methods you offer – each one, as a real customer would, on a phone at least once. Different gateways fail independently; testing one proves nothing about the others.
• The refund flow, fully. Refund one of the test orders from the WooCommerce order screen and confirm the money actually returns and the customer gets a refund email. Some gateway configurations accept payments happily but cannot refund through the API – you want to learn that now, not during your first dispute.
• The failure path. Use a declining card (gateways document test decline numbers, and most banks let you trigger a failed 3D Secure). The customer must get a clear error, keep their cart, and no order or stock deduction should occur. A store that creates “pending” orders on every failed attempt buries real orders in noise.
• Payout account verified, and one payout received. Gateways hold money until identity and bank verification are complete, and they will happily let you take orders while payouts are frozen. Finish the gateway’s onboarding entirely – documents, bank confirmation, the lot – and wait until the first test payout lands in the bank account before launch. Stores have run for weeks on frozen payouts without noticing.
• Currency and amounts reconcile. Check the gateway dashboard against WooCommerce: same amounts, same currency, fees visible. If numbers disagree on order three, they will disagree on order three thousand.

While you are placing these orders, watch the checkout itself with a customer’s eyes – required fields that are not needed, error messages that do not say what is wrong, a coupon field inviting everyone to leave and search for codes. I cover that side in detail in my guide to checkout optimisation and cart abandonment; for launch, the bar is simpler: a stranger with a phone can pay you without asking for help.

Taxes and invoices: configured, not assumed

Tax mistakes are invisible at launch and expensive at accounting time. WooCommerce can handle EU VAT correctly, but only if you configure it deliberately:

• Decide how entered prices work. “Prices entered with tax included” is the usual choice for EU B2C stores – customers see final prices, as the law expects. Whichever you pick, verify a product’s price on the product page, in the cart and on the final invoice: same gross number everywhere.
• Set up real rates, not guesses. Standard and reduced rates for every country you sell to. If you sell across the EU above the distance-selling threshold, you charge the customer’s country rate, not yours – the OSS scheme exists for exactly this, and your accountant should confirm which side of the threshold you start on.
• Display settings are consistent. Tax display in cart and checkout, the “incl. VAT” suffix on prices where your market expects it (Germany also expects a shipping-costs note on product pages), and totals that add up visibly.
• Invoices generate correctly. Install an invoice plugin (I usually use a PDF invoice plugin on EU stores), set the numbering format your accountant wants, and check a test invoice line by line: your company details, sequential number, correct VAT rate and amount, customer address. Then send one to your accountant and ask “would you accept this?” – a five-minute email that prevents a quarter-end mess.
• B2B, if relevant. If you sell to businesses in other EU countries, decide now how VAT-ID validation and reverse charge will work; bolting it on after launch means correcting issued invoices.

One honest note: I configure tax settings, but I am not a tax advisor – the rates and thresholds themselves should come from your accountant. The checklist item is “accountant has seen a test invoice and the rate table”, not “developer guessed the rates”.

Shipping: zones, rates and real packaging costs

Shipping settings are where stores quietly lose money. The configuration in WooCommerce – zones, methods, rates, classes – has to match two realities: what carriers actually charge you, and what it actually costs to pack a box.

• Zones match where you really ship. A zone per pricing region (e.g. domestic, EU neighbours, rest of EU), and nothing else. If a country is not in any zone, customers there reach checkout and hit “no shipping options available” – the most abandonment-prone message in commerce. Decide country coverage deliberately and test an address in each zone, plus one in a country you do not ship to.
• Rates are based on carrier price lists, not optimism. Open the actual carrier tariff, weigh a typical parcel, and set rates from that. Use shipping classes for products that break the average – bulky, heavy, or letter-sized items – rather than pricing everything for the mid-sized box.
• Packaging is part of the cost. Box, filler, tape, label – typically EUR 0.50 to EUR 1.50 per parcel that the carrier invoice never shows. Either build it into shipping rates or into product margins, but build it in somewhere, on purpose.
• Free shipping has a deliberate threshold. If you offer it, set the threshold above your average order value so it lifts orders instead of just deleting your shipping revenue. And check the classic bug: a free-shipping coupon or threshold that also applies to the 30 kg product.
• The estimate matches the promise. Whatever delivery time the store implies, your handling time plus carrier time must actually achieve. “Ships within 24 hours” is a promise you will be held to on day one.

Place test orders to addresses in each zone and check the charged shipping against the carrier tariff. Ten minutes with a spreadsheet here routinely finds a rate that is wrong by a few euros – in either direction, and both directions cost you.

Transactional emails: firing, branded, not in spam

Order emails are the most-read messages your store will ever send, and on a default WooCommerce install they are plain, purple and quite likely to land in spam. Three checks, in order of importance:

• They fire at all. Trigger every template with test orders: new order (to you), processing and completed order (to the customer), refund, cancelled order, customer note, password reset, account created. The admin “new order” email is the one shop owners rely on most and the one most often broken.
• They reach the inbox. PHP mail from a shared server is a spam magnet. Send through SMTP or a transactional email service, set up SPF, DKIM and DMARC for your domain, and then test deliverability to Gmail and Outlook accounts – not just your own address on the same server, which proves nothing. A mail-tester score of 9 or 10 out of 10 is a reasonable launch bar.
• They look like your store. Logo, brand colours, sensible sender name (“Store Name”, not “wordpress@server”), a reply-to address a human reads, and the practical details customers look for: what they ordered, what it cost, where it is going, and who to contact when something is wrong.

Read every email on a phone as well – that is where most of them are opened. The full test matrix I run before launch covers payments, refunds, failures and emails together, because they are one system from the customer’s point of view:

Legal for EU stores: the non-negotiables

If you sell to consumers in the EU – and especially from or into Germany – the legal checklist is short, specific, and enforced by competitors’ lawyers, not just regulators. The usual disclaimer applies: I am a developer, not a lawyer, and the texts themselves should come from a legal source. But I can tell you what has to exist and how it must behave technically:

• Imprint (Impressum). A page with your legal identity – company name, address, contact, registration and VAT details – reachable from every page. In Germany this is mandatory and its absence is the classic warning-letter trigger.
• Withdrawal and returns policy. EU consumers have a 14-day right of withdrawal for most goods. The policy must be stated correctly (a wrong or missing text can extend the withdrawal period dramatically), linked at checkout, and matched by an actual returns process on your side: who pays return shipping, how refunds are issued, what is excluded.
• Terms accepted at checkout. A checkbox linking to terms, withdrawal policy and privacy policy – unticked by default – and an order button that says what it does (“Buy now” / “Zahlungspflichtig bestellen” in Germany, where the button wording is itself a legal requirement).
• GDPR basics. Privacy policy covering the store’s actual data flows (orders, payment providers, analytics, email), a consent banner that genuinely blocks non-essential cookies until accepted, and data-processing agreements with your processors. The full detail is in my GDPR compliance guide for WordPress – for launch, the store must not load marketing scripts before consent, and a placed order must not depend on marketing consent.
• Price transparency. Final prices with VAT included for consumers, shipping costs disclosed before checkout, and unit prices (per litre, per kilogram) where the product type requires them.

This is one area where WooCommerce asks more of you than hosted platforms do – Shopify ships some of this packaged, WooCommerce leaves it to you, which is part of the honest trade-off I walk through in WooCommerce vs Shopify. The flexibility is worth it, but only if this section of the checklist actually gets done.

Accounts, guest checkout and the buying journey

Decide the account policy deliberately, then test both paths. My default recommendation for most stores: allow guest checkout, offer optional account creation during checkout (one checkbox, no extra form), and never force registration before payment – forced registration is one of the most reliable ways to lose a first-time buyer.

• Guest flow: a stranger can go from product page to paid order with only the fields a shop genuinely needs. Count the fields; every one you can remove, remove.
• Account flow: registration works, the confirmation email arrives, login works, and the account area shows orders, addresses and a working password reset. Test the reset – it is the most-used account feature and the most commonly broken.
• The full journey on a phone: search or browse to a product, read it, add to cart, check out, pay. Do it on a real phone over mobile data, not a desktop browser shrunk to 375 pixels. Most of your customers will meet the store exactly this way.
• Edge pages exist and behave: empty cart page, “no results” search page, 404 page pointing back to the shop, out-of-stock product page. Customers find these pages in the first week whether you styled them or not.

If the store replaces an older site, the SEO side of launch – redirects, indexing, search console – follows the same rules as any WordPress go-live; my general WordPress website launch checklist covers that layer, and everything in it applies to a store too. This post adds the commerce layer on top.

Performance, backups and the security baseline

A store does not need to survive a stampede on day one, but it does need three boring guarantees: it stays fast enough to sell, it can be restored if something breaks, and it is not trivially attackable. The launch bar I use:

• Performance under normal load. Product and category pages under 2.5 seconds LCP on mobile, caching configured with cart, checkout and account pages correctly excluded (a cached checkout showing someone else’s session is a real and horrible bug), and images in WebP. Then a basic load sanity check: a simple load-testing tool sending a few dozen concurrent users at the homepage and a product page. You are not simulating a viral hit; you are confirming the cheapest hosting assumption (“it worked with one visitor”) survives twenty.
• Hosting that fits commerce. Enough PHP workers that checkout does not queue behind page views, a persistent object cache (Redis) if the catalogue is non-trivial, and PHP and database versions that are current. If the host struggles during testing, it will not improve with customers.
• Backups that include orders and restore. Daily automated off-site backups at minimum – and once orders flow, understand that a backup from last night does not contain this morning’s orders, so real recovery on a busy store means more frequent database snapshots. Do one test restore to a staging environment before launch. An unrestored backup is a hope, not a backup.
• Security baseline. Unique strong passwords with two-factor authentication for every admin, no “admin” username, limited login attempts, up-to-date core, theme and plugins with no abandoned plugins installed, security headers, and file editing disabled in the dashboard. A store is a more attractive target than a brochure site – it has customer data and a payment flow worth attacking.

Analytics: verify tracking before you need it

The first month of a store generates the data you will use to fix it – unless tracking is broken, in which case that month is simply lost. Analytics is on the launch checklist because it cannot be added retroactively.

• Ecommerce tracking is verified, not just installed. Place a test order and watch it appear in your analytics as a purchase event with the right value and currency. “The tag is on the page” and “purchases are recorded correctly” are very different statements; the funnel events (view item, add to cart, begin checkout, purchase) should all fire, in order, once each.
• Consent and tracking coexist correctly. With the cookie banner declined, marketing tags must not fire; with it accepted, they must. Test both states in a private window. Expect a gap between orders in WooCommerce and purchases in analytics – consent declines make analytics undercount, and you should know your gap rather than distrust both numbers.
• Search Console and sitemaps. The XML sitemap submitted, the staging noindex flag removed (check this twice – a live store with a site-wide noindex is a classic launch defect), and the domain verified so crawl errors reach you.
• WooCommerce’s own reports have a baseline. Know where orders, top products and stock reports live before launch day, so the first week’s questions (“are we selling? what? to where?”) take seconds to answer.
• Uptime and error monitoring. An uptime monitor pointed at the checkout page (not just the homepage) and PHP error logging going somewhere a human looks. Checkout being down is the outage that matters.

Soft launch, launch day and the first month

With the checklist green, resist the big-bang launch. The stores that “sell from day one” almost always launched twice: quietly, then loudly.

Soft launch first. Open the store without announcement and invite ten to twenty friendly customers – people who will tolerate a rough edge and tell you about it. Give them a small discount code as thanks, ask three questions (was anything confusing? did the emails arrive? would you have paid full price for that experience?), and fix what they find. A week of soft launch converts unknown risks into a short snag list. It also seeds real orders, so your analytics, emails and payout cycle are proven with strangers’ money before the marketing spend starts.

Launch day is a runbook, not a mood. Mine, roughly in order: fresh full backup before anything; DNS or visibility switch in the morning, never on a Friday evening; the EUR 1 test purchase on the live domain immediately after; caches purged and one manual browse-and-buy on a phone; monitoring dashboards open (orders, uptime, error log, gateway dashboard); ads and announcements only switched on after the test purchase succeeds; and one named person watching the shop inbox all day. Nothing on the list is clever – the value is that nobody is inventing the plan at 9 am.

The first month is part of the launch. Three habits, fifteen minutes a day:

• Watch abandonment, not just sales. Where do people leave the funnel? A spike at the payment step points at a gateway problem; at the shipping step, at your rates or delivery promise.
• Read the on-site search terms. They tell you what customers call your products and what they wanted that you do not stock – free product strategy, and free vocabulary for titles and descriptions.
• Check 404s and errors weekly. Broken links from ads, old URLs that need redirects, and PHP notices that predict tomorrow’s bug. Small, boring, decisive.

After the first month you will have real data, real customer emails and a short list of genuine improvements – which is when optimisation work (checkout tweaks, page speed, merchandising) actually pays, because it is aimed at observed behaviour instead of guesses.

Launching a WooCommerce store and want it done right?

I build and launch WooCommerce stores for small businesses and agencies in Germany, the UK, the US and Australia – setup, payments, taxes, shipping, emails and the whole checklist above, at EUR 15 per hour or a fixed price quoted within 24 hours. See my WooCommerce development services and portfolio, or send me your launch date – I reply within 24 hours.

Frequently asked questions

What should a WooCommerce launch checklist cover?

Three areas: money (test orders on every payment method, refunds, payouts, taxes, invoices), legal (imprint, withdrawal policy, terms consent, GDPR for EU stores) and logistics (complete product data, shipping zones and rates that match reality, transactional emails that reach the inbox).

How long does it take to launch a WooCommerce store properly?

The operational checklist itself takes two to four focused days on a finished store, plus a week of soft launch with friendly customers. Rushing those days is how stores spend their first month firefighting instead of selling.

Should I test payments with real money before launch?

Yes. Test mode proves configuration; only a live order per payment method, plus a real refund, proves the money path. A hidden EUR 1 test product makes this cheap, and gateway fees on a few tiny orders are the best insurance you will ever buy.

Do I need guest checkout on a new store?

Almost always yes. Forced registration before payment measurably increases abandonment; offer guest checkout with optional account creation at the end of checkout instead.

What legal pages does an EU WooCommerce store need?

An imprint, a privacy policy, a correct withdrawal/returns policy and terms accepted via checkbox at checkout, with final prices shown including VAT. Get the texts from a legal source – the technical checklist is that they exist, are linked at checkout and the consent behaviour works.

What is a soft launch and is it worth it?

Opening the store quietly to ten to twenty friendly customers before any announcement. It converts unknown risks into a fixable snag list and proves payments, emails and payouts with real orders – a week that regularly saves a month.

What should I monitor in the first month after launch?

Funnel abandonment by step, on-site search terms, 404s and error logs, email deliverability, and the gap between WooCommerce orders and analytics purchases. Fifteen minutes a day is enough to catch every early problem while it is still small.