Go-live checklist

Work through this list on the production setup, top to bottom, before you announce the store. Each item links to the page that explains it. Most of it takes minutes; the test order in live mode is the one step you must not skip.

Tip

Run the same list on staging first, with payments in test mode. Then repeat it on production, where only the payment section changes.

WordPress and the Companion plugin

• WooCommerce and the Companion plugin are active and up to date. See Install the Companion plugin.
• RSC_JWT_SECRET is defined in wp-config.php and the Social Login tab shows it as configured.
• RSC_STOREFRONT_SHARED_SECRET is defined and matches the storefront’s STOREFRONT_SHARED_SECRET. No admin notice warns about it.
• RSC_DISABLE_EMAIL_VERIFICATION is not defined. It is for local development only.
• StoreFront → Settings → General → Storefront URL is the production storefront address, with HTTPS.
• Permalinks are set to anything but Plain, and WordPress itself is served over HTTPS.
• WooCommerce’s selling and shipping locations, shipping zones, taxes and currency are final. See WooCommerce settings.
• The Settings → General → Timezone is the store’s real timezone. Sale countdowns and “Today’s deals” follow it.
• WOOCOMMERCE_BIS_ALPHA_ENABLED is not defined. The Companion plugin has its own back-in-stock alerts.

Storefront environment

• COMMERCE_SOURCE=woocommerce, WOO_STORE_URL and RSC_API_URL point at the production WordPress.
• AUTH_SECRET is a fresh value generated for production, not one copied from staging or a laptop.
• SITE_URL is the production address, with HTTPS and no trailing slash.
• STOREFRONT_SHARED_SECRET is set.
• WooCommerce REST keys are a production pair with Read permission.
• STOREFRONT_CUSTOM_SCRIPTS is unset (scripts on), unless you deliberately keep them off.
• WOO_INSECURE_TLS is not set.
• No payment, social sign-in or Turnstile keys are in the storefront’s environment.
• Languages, Home sections and checkout options are what the client signed off. See Configuration.
• The store name, tagline, About page, store profile and Find a Store page no longer show the demo brand or placeholder data. See Store identity.

Domain, DNS and HTTPS

• The storefront’s domain resolves to the storefront and serves a valid certificate.
• WordPress lives on its own host (for example a cms. or admin. subdomain) with a valid certificate.
• The proxy in front of the storefront sets X-Forwarded-For, and AUTH_TRUST_HOST=true is set. See Deployment.
• Opening a published product’s old WordPress address redirects (301) to the same product on the storefront.

Payments in live mode

• Each gateway is switched from test to live mode in WooCommerce → Settings → Payments, with live keys. The storefront picks this up on the next checkout, with no redeploy. See Payments.
• Stripe and PayPal webhooks are configured for live mode, as each gateway plugin’s own documentation describes.
• PayPal uses the Capture intent.
• Apple Pay and Google Pay are switched on only on the pages you want, and the storefront domain shows as registered with Stripe (no admin notice about a refused domain).
• Link is switched off in the Stripe plugin. It has not yet passed real-wallet checks.
• Offline methods you do not offer (bank transfer, cheque, cash on delivery) are disabled.
• No admin notice warns that a payment plugin version is outside the verified range.

A real test order

1. On the live storefront, buy a cheap product with a real card, as a guest.
2. Check the thank-you page, the order in WooCommerce and the customer email.
3. Refund the order from WooCommerce and confirm the refund reaches the card.
4. Repeat with PayPal and with a wallet on a phone, if you offer them.
5. Sign up as a new customer, verify the email, sign in, and check that the order history and invoice download work for an order on that account.

Email and background jobs

• WordPress sends mail through a real SMTP or transactional mail service. Sign-in requires a verified email, so this is not optional.
• Verification, password-reset and back-in-stock emails arrive and link to the storefront, not to WordPress.
• A real system cron calls wp-cron.php, and WP-Cron’s page-view trigger is disabled with DISABLE_WP_CRON. See Emails and background jobs.
• WooCommerce → Status → Scheduled Actions shows no pile of failed or overdue actions.

Sign-in and bot protection

• Google sign-in: the OAuth client’s authorised redirect URI is the production storefront’s /login address, exactly. See Sign-in and security.
• Facebook sign-in: the storefront’s domain is in the app’s allowed domains and the app is switched to Live.
• Cloudflare Turnstile is on, both keys are saved, and the widget’s hostnames include the production storefront domain.
• Test each form that uses Turnstile: a review, a back-in-stock sign-up and the contact form.

SEO

• SITE_URL is correct: view a page’s source and check the canonical address.
• /sitemap.xml and /robots.txt load and use the production address.
• The site is added to Google Search Console (and any other search engine you use) and the sitemap is submitted.
• Site name, default sharing image and SEO patterns are set in StoreFront → Settings → SEO. With Yoast SEO or Rank Math active, Sync SEO has run. See SEO.
• Old non-product URLs that matter for search (categories, pages) have redirects at your DNS or proxy. The Companion plugin only redirects product pages.

Content and tracking

• Every policy page (returns and refunds, shipping, privacy, terms, cookies) is published. A missing one shows a 404 and its links disappear. See Pages and content.
• Header and footer scripts (tag manager, pixel, consent tool) are pasted in WordPress and fire on the live storefront. See Scripts and promo popup.
• In the EU, the consent tool loads in the Head box so tracking waits for consent.
• Contact form messages arrive where expected, and newsletter sign-ups reach the right list.
• The header, footer, mobile tab bar, colours and favicon are final.

Backups and handover

• WordPress has automated, tested backups of its database and uploads. The storefront keeps no data of its own.
• The storefront’s environment variables are recorded somewhere safe. On Cloudflare they live only in the dashboard.
• The client knows where everything is managed: WordPress for content and settings, the storefront deployment for environment changes.
• Someone is named to watch the WooCommerce logs (source retail-store-companion-payment) during launch week.

Next steps

TroubleshootingWhat to do when something on the list fails.

Launch pathThe whole project from kickoff to launch.

FAQAnswers for clients and teams.