What to actually check before launching a store

Launch-day problems are boringly consistent. It is almost never the design. It is a payment method nobody tested with a real card, a confirmation email landing in spam, a tax rule that is right for one country and wrong for the next, or an old URL that now returns a 404 to the only page Google had indexed.

Here is the list we actually work through. Print it, tick it, and do not launch on a Friday.

Payments

• Place a real order with a real card, for a real amount, in live mode. Sandbox testing does not prove your live credentials work.
• Test every enabled payment method, including the ones you expect nobody to use. Wallets and bank redirects fail differently from cards.
• Process a refund end to end. Find out now whether it works, not when a customer is waiting.
• Check the failed-payment path: decline a card deliberately and confirm the customer sees a useful message and keeps their cart.
• Confirm the currency and rounding on the order total match what the gateway captures, especially with multi-currency enabled.

Tax and shipping

• Place test orders to each region you sell to and verify tax rate, tax display (inclusive vs exclusive) and the invoice total.
• Verify digital goods VAT rules if they apply — they are jurisdiction-specific and getting them wrong is expensive retroactively.
• Test shipping thresholds at the boundary: one cent under free shipping, and one cent over.
• Confirm what happens when a customer enters an address you do not ship to. Silence is not an answer.

Email deliverability

This is the one that catches most stores. WordPress’s default mail() function sends from your web server, which has no sending reputation, and modern spam filters treat it accordingly.

• Send transactional email through a proper SMTP provider, not PHP mail.
• Set up SPF, DKIM and DMARC for your sending domain, and verify them with a mail tester.
• Send an order confirmation to a Gmail, an Outlook and a corporate address. Check the spam folder in each.
• Confirm the admin notification arrives too — plenty of stores discover a week later that they were never told about orders.

Redirects and URLs

• Export the URL list from the old site and map every one to its new destination. Anything without a mapping is a 404 you chose.
• Redirect with 301, not 302, and test a sample after go-live.
• Check that canonical tags point at live URLs, not staging.
• Remove the staging noindex. This single line has cost more launches more traffic than any other item on this list.

Analytics and tracking

• Verify purchase events fire once, with the correct value and currency. Double-firing is as damaging as not firing at all.
• Confirm your consent banner actually gates the tags it claims to gate.
• Submit the sitemap in Search Console and check it lists products, categories and pages.

The boring infrastructure checks

• Backups run and restore. An untested backup is a hope, not a backup.
• SSL valid, with no mixed-content warnings anywhere in the checkout.
• Caching excludes cart, checkout and account pages — and nothing else.
• Stock levels are real. Imported catalogues frequently arrive with every product set to a placeholder quantity.
• Someone owns the inbox. Decide who answers the first customer email before there is one.

After launch

Watch order flow and error logs closely for 48 hours. Most genuine problems announce themselves in the first two days, and almost all of them are cheap to fix while the traffic is still small.