The online store launch checklist: 48 checks we run on every build

The core list runs on every build we do. It dates from September 2026, so we do not offer the stores on our work page as proof of it. This post goes through it group by group, in the list’s own words, with most of the reasons we wrote beside the checks. Use it to test your own store, or to ask whoever builds yours which of these they will sign off. The whole list is on our checklist page.

The short answer

The core list sits under these headings. Each group proves one thing about the live store.

How the list works

Each check is a state, not a task

A task says what someone will do: “set up the redirects”. A state says what must be true afterwards, so anyone can test it. Our redirect check ends: after launch “each one opens, or redirects in one step, to its matching page, not to the home page.” You can test that with a browser and the list of old addresses.

Every core check is one plain sentence about the state the store must be in, with a line under it saying why it is on the list. Core checks name no platform feature. Where a platform cannot do what a check says, the check is marked not needed, with the platform’s limit as the reason.

Done, not needed, or left to you with a note

Every check that applies ends in one of three states: done, not needed for this store, or left to you with a note saying why. The third covers a check that “depends on your decision, your content or your access, and it was still open at launch.” It is written down as waiting, not ticked.

You see the list for your project before work starts. At launch you get it back with every check marked done, not needed, or left to you. The checks that run after launch are marked at day 30. The checklist page shows how the marked copy works.

The core list and the packs

The core list is the floor. 7 packs add 151 more checks when a project needs them, such as a platform move or a full redesign.

Pack checks are written as working instructions, and some name a platform feature. A check tagged Shopify is marked not needed on another platform, unless your scope names an equivalent.

Prices, discounts and payments

The first group has 10 checks. It starts on the product page, runs through real orders placed and refunded on the live store, and ends with tax and shipping zones.

What the product page promises

• “Delivery cost, dispatch time and return window shown on product pages and in the cart match the shipping settings and policies.”
• “No sold-out product keeps taking orders, unless you can really backorder it and its page says when it ships.”
• “A test order is placed for each kind of discount in use, and the sale price shown matches the total charged.”

The reason under the first is an example of how it happens: “An old placeholder promises free shipping over 50 while the rate clears at 75, and the shopper finds out at checkout.” The setting behind the second arrives switched on through CSV imports and apps. And because sale badges come from tags or compare-at prices, “a page can advertise 30 percent off while the rule takes nothing off the total.”

Taking money: each provider, each express button, a declined card

A test order in a preview proves the pages work. It does not prove the money moves. So the core list asks for real orders:

• “A real card order is placed and refunded on the live store through each payment provider, and both appear in its report.”
• “A real order is placed and refunded on a phone through each express button switched on, such as Apple Pay or PayPal.”
• “A declined card and a card needing a bank check are tried: the cart survives and no order or double charge results, or the platform’s own behaviour is written down.”

The reason under the first: “Credentials that pass the admin connection check still fail on the first live charge when the merchant account is unverified.” Express buttons skip the cart and use their own address and shipping steps, so a wallet can look live and still fail. A declined payment leaves no paid order behind, so a checkout that drops the cart on a bank check passes every test that looks only at successful orders.

Two more checks: only the payment methods you agreed to are switched on, “with test mode off and no test gateway left behind”, and if payments are held for approval, the handover document names who approves. If nobody is named, authorizations expire “so you ship orders that were never charged.”

Tax and shipping zones

We do not decide your tax. The check is that “Tax settings (prices with or without tax, tax on shipping, tax per product type) follow written instruction from you or your accountant.” Shipping gets one check: “Every country you sell to is inside a shipping zone, and a test checkout in each zone shows a working rate.” A weight bracket that stops short leaves the shopper with a checkout they cannot finish.

Phones, browsers and speed

This group has 6 checks.

A real iPhone, a real Android phone, four browsers

“The buy path, from home page to order confirmation, is run on a real iPhone and a real Android phone.” Then the same path, “with a filter used and an option changed, is run in current Safari, Chrome, Firefox and Edge.” The phones are real for this reason: “Emulation does not reproduce Android font boosting, real touch scrolling or the Safari toolbar, so breakage first appears on customer hardware.” An older Android and an iPad sit in the Speed and access pack.

Two more checks are about thumbs and small screens. Buttons on the product, category and cart pages must be big enough for a thumb and far enough apart to hit the right one (our working minimum is 44 by 44 pixels, with 8 pixels between them). And those pages and the home page must not scroll sideways on a small phone, checked at 320 and 360 pixels wide.

One purchase with the keyboard only

“One purchase is completed using only the keyboard, and every blocker found is fixed or written down.” Automated scans pass pages where the focus order is scrambled, so the failures that stop an order only show when someone places one. It is one basic access check, not an audit. Even the Speed and access pack, which adds the checks beyond the basics, says of itself: “It is not a WCAG audit.”

Speed measured with the apps on and the cookie banner showing

The check: “Speed is measured on the finished store, apps on and cookie banner showing; you get the results, slow spots fixed or explained.” The timing is the point. A store measured before its apps are on looks faster than it will be: “for example, an unpublished theme can score in the nineties and the same theme in the fifties the day after launch.”

For what “good” means, web.dev’s Core Web Vitals set three targets: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, at the 75th percentile of page loads, mobile and desktop counted separately. The same page says a lab test “is not a substitute for field measurement”, and a test before launch is a lab test. Speed data from real visitors is in the 30 days after pack.

If apps are what slow your store down, why your Shopify store is slow goes through the scripts they add.

Search, the old addresses and the pages themselves

This group has 8 checks: whether search engines can reach the new store, whether old links still work, and what a shopper finds on arrival.

Old addresses redirect in one step to their matching page

The check in full: “The old store’s addresses that had visits or links in the last year are saved before the build, and after launch each one opens, or redirects in one step, to its matching page, not to the home page.”

The reason: “Bulk redirect imports drop rows without warning and mistyped targets fail quietly, so breakage stays invisible until the traffic is gone.” Addresses nobody visited or linked to in a year are left out, which keeps the list one that can be checked line by line.

Google’s guide to site moves points the same way. It advises redirecting to the final destination directly, not through a chain, and warns that sending many old addresses to one irrelevant page, such as the home page, “might be treated as a soft 404 error.”

This is a core check, so it runs on every build, not only on a move. On a move between platforms the Moving platforms pack adds more: customers, balances, reviews and every old address brought across. Moving from WooCommerce to Shopify without losing search traffic goes through that move step by step.

The platform’s own address and the leftover password page

The check: “Every other form of the store’s address (http, www, platform or staging) redirects to the main one or is switched off.” Otherwise the same pages can be reached at two addresses, and Google picks one of them to show, which may not be the address you want. Google’s page on redirects gives the fix: pick one preferred address and redirect the others to it, with a permanent server-side redirect whenever possible.

Then the leftovers: “Nothing left over from development hides the live store from search engines: no password page and no leftover blocking setting.” Either leftover is enough: a global noindex in an SEO app makes Google drop each page from its results once it crawls it, and a leftover Disallow line stops Google reading the pages.

Two more checks: every product and category meant to be live is in the sitemap, with no address in it broken, redirected or hidden, and “The live site is verified in Google Search Console under your own account, and its sitemap is submitted.” A store nobody verified has no report of crawl errors, so an indexing problem after launch goes unseen.

Neither step changes what Google does by itself: a Search Console property only lets you track how the site performs, and a submitted sitemap is “merely a hint”, though its report shows when Google read it and any errors.

No empty category, no demo product, real policy pages

• “No category page is empty, and every product on sale can be reached from the main menu.”
• “The shipping, returns, privacy and terms pages carry your real details, with no placeholder text left and no wrong links.”
• “No demo, test or sample product is published, and no published product has a price of zero unless it is meant to be free.”

A product in no category “can only be found by search or a direct link, so it quietly stops selling.” Generated policy templates ship with bracketed placeholders and go live that way unless someone reads them. A published test product at zero price can be ordered by a real customer. The policy check is about your real details being there, not about the wording in law: the list says it is not legal advice.

Email and what happens after an order

This group has 6 checks. The order now has to reach you, the customer and whoever packs it.

The awkward test order

“An awkward test order (two items, a discount, a second address line, non-Latin letters) arrives complete where orders are packed.” A test with one item and a plain address proves little: “Field mapping breaks on the second address line or accented characters, and engraving text missing from the packer’s paperwork ships as wrong goods.”

Order emails are “signed as coming from your domain where the platform allows, test-sent to Gmail, Outlook and iCloud Mail, and where each landed is recorded.” Every order, shipping and account email also carries your logo, name and support address, and replies reach an inbox someone monitors.

Since 1 February 2024, Google’s email sender guidelines have required everyone sending to Gmail accounts to set up SPF or DKIM, and anyone sending more than 5,000 messages a day to Gmail accounts to set up SPF, DKIM and DMARC. Mail without them may be marked as spam or rejected. Google says to set these up at your domain provider, which is why our reason says the records “live in your domain’s settings rather than in the email tool.”

Every contact form is tested too, and each message has to reach a mailbox your team reads. A form pointing at a mailbox nobody opens “swallows pre-purchase questions and return requests for months.”

Following an order as a customer would

“A test order is followed as a customer would, from confirmation email to tracking to the returns route, and each step works.” The reason is your support inbox: “Where is my order and how do I return this are among the most common support messages a store gets.” Where customer accounts are switched on, a new customer must be able to sign up, sign in and reset a password on the live store.

Launch day

This group has 7 checks, for the launch itself and the hours around it.

A written plan with a way back

“The launch runs from a written plan with a named owner for each step and a way back, outside your busiest hours and campaigns.” The reason: “Improvised cutovers skip steps under pressure, and launching during a promotion puts the busiest hours inside the riskiest window.”

The way back is concrete: “the saved copy from the version check and the written steps in the handover document”. Before the new version goes live, the one live now is saved as a dated copy that can be put back (that check sits in the ownership group). On Shopify, for one, a theme you replace is kept as a draft, but edits to the live theme itself can be undone only one file at a time, and Shopify’s own advice is to duplicate the theme first as a backup.

If launch changes where your domain points, the old DNS records are saved first and checked after, and a test email is sent and received: “A switch that drops the mail record stops your company email, including the inbox your customers reply to.” HTTPS gets its own check on the main address, the www address and a product page. On Shopify, for one, the certificate is issued once the domain’s records point to Shopify, and that can take up to 48 hours.

One check is yours to run. “We give your team a written script for the buy path; named people on your team run it before launch, and each problem is fixed or accepted in writing.” The reason: “Every other test is us checking our own work, so without this there is no moment where you accept the build.”

A real paid order from a phone, then refunded

“Straight after launch, a real paid order is placed on the live domain from a phone, checked end to end, and refunded.” Checkout behaves differently on the live domain than in preview, and a gateway left in test mode loses every real order.

The analytics get the same treatment. One real order is “recorded exactly once in analytics, with the right order number, currency and value”, since broken value mapping can send 0.00 and a leftover pixel can count the order twice. Within an hour of launch, page views, add to cart and purchase must show in your live analytics, not a development copy. Ad pixels come with the Tracking and ads pack.

Ownership, handover and the first 30 days

This group has 11 checks. If you read one group before you hire anyone, read this one.

In your name: owner account, domain, billing, code

“The store’s owner account, domain, subscriptions and billing card are in your name, and we hold only a login you can remove.” The reason: “A store or a domain registered to an agency’s account is hard for you to get back if the relationship ends.”

The rest follows from it:

• the launched code is kept in your own repository, such as GitHub, or in a named backup where the platform keeps no code;
• products, categories, customers, discount codes and redirects are exported to files you can reach without asking us;
• every account opened during the build, such as analytics, the email platform and review tools, has your email as owner by day 30;
• logins with access to orders or the store are reviewed, two-step sign-in is on, and access keys are listed;
• no password or secret key is left in the store’s code or in the page source, since a key pasted into the theme’s scripts during the build stays in the published theme, readable by anyone who views source.

Seven days of daily checks, 30 days of fixes

“For seven days after launch, orders, failed payments and broken pages are checked daily, and each issue is fixed or reported to you by day 30.” The reason: “The first week surfaces what no test catches, and an issue nobody wrote down falls between you and us.” Nothing in the core list is checked daily past day 7. The recrawls on day 1, day 7 and day 30, and the uptime monitor, belong to the 30 days after pack.

The window is written down: “A support note you confirm by reply sets the 30 days of fixes, one reporting channel, a one-business-day first reply and what counts as a defect.” You also get a recorded walkthrough of editing each custom section, adding a product, publishing and going back, and a handover document listing every app and its monthly cost, every outside account and owner, where the code lives and how to roll back.

The redesigns page lists what a build includes and what happens after launch.

When the core is not enough: the packs

A pack is a fixed set of checks, added when a project needs it. Your scope names the packs that apply.

Large builds run the core list and every pack: 199 checks. Some pack checks also carry a condition of their own, such as “migrating from an existing store”, and run only when it holds.

The packs in your scope are priced with it, so they are part of what a quote covers. What a Shopify redesign costs goes through the rest of what moves a price, and our prices are on the pricing page.

What the checklist does not promise

The list describes work performed and verified. It draws a line between what we control and what we do not.

• “Nothing here promises a business result.” The list checks that the store works. It does not promise that it sells.
• It is not legal advice and not an accessibility certificate.
• Rankings are the search engine’s decision. In the words of our redesigns page, “nobody can promise them.” What we control is checked.
• Where an email lands is the mailbox provider’s decision. The check records it.
• Where the checkout is the platform’s own, its behaviour is written down, not changed.
• Post-launch checks cover 30 days from go-live. Work after that is monthly work, agreed separately.

The list was built on 4 September 2026, split into the core list and the packs on 6 October 2026, and last updated on 23 October 2026.

Use it on your store

1. Read the full list, with the reason under every check, and run the core list on your own store.
2. Run the free store checkup. It is an automated first look at one page: it reads the HTML the store sends, its robots.txt, its llms.txt and its sitemap, the way a crawler does, and links its findings to the groups of the full list that cover them, such as Launch day or Search visibility and safe migration. It gives no score and runs no speed test.
3. Book a store review: a free 15-minute call, then written notes on what is costing you orders and what to fix first.

If we build or rebuild your store, the core list is in the scope before work starts, and the packs your scope names are priced with it.