Before launching a Magento 2 store, verify seven things: the site runs in production mode with full-page cache enabled, all indexers are on Update by Schedule, cron is running, tax and shipping rules match real orders, checkout completes end to end with live payment credentials, SEO basics and redirects are in place, and a tested backup and rollback plan exists.
The sequence matters: configuration problems are cheap to fix on staging and expensive to fix while customers watch a broken checkout. Bad launches almost never fail on something exotic — they fail because cron was never enabled, a tax rule was left at a test value, or nobody placed a real order with a real card before the store went public.
What has to be true before a Magento 2 store goes live?
Use this as the master pass. Each item is a yes/no you can verify, not a judgement call.
| Area | What to verify | How you check it |
|---|---|---|
| Application mode | Store runs in production mode, not developer or default | bin/magento deploy:mode:show |
| Caching | All caches enabled; full-page cache active (Varnish if you use it) | bin/magento cache:status |
| Indexers | Every indexer set to Update by Schedule, none invalid | bin/magento indexer:show-mode and indexer:status |
| Cron | Magento cron jobs running on the production server | bin/magento cron:run scheduled in crontab; check cron_schedule |
| Base URLs | Secure and unsecure base URLs point at the live domain | Admin > Stores > Configuration > Web |
| HTTPS | HTTPS forced on both storefront and admin, valid certificate | Load the site over http and confirm the redirect |
| Transactional email sends and arrives (order, invoice, password reset) | Place a test order, check inbox and spam | |
| Payments | Live credentials in place, gateway tested in sandbox first | One real low-value order, then refund it |
| Tax & shipping | Rates match real destinations and real order totals | Quote several addresses against expected totals |
| SEO | Robots directive set to index, sitemap generated and submitted | Admin > Design > Search Engine Robots; sitemap URL loads |
| Redirects | Every old URL from the previous site maps to a live URL | Crawl the old URL list, confirm 301s, no 404s |
| Backups | Database and file backup taken, restore actually tested | Restore into a scratch environment before launch day |
If any row is a "no", it is a launch blocker, not a post-launch task — the cost of each one lands on a customer.
Which technical settings break stores most often?
Three settings cause a disproportionate share of bad launches, and all three are invisible from the storefront until something goes wrong.
Application mode. Developer mode disables caching layers and generates files on the fly. A store left in developer or default mode on launch day will feel slow no matter how well the theme is built. Switch deliberately before go-live:
bin/magento deploy:mode:set production
bin/magento setup:static-content:deploy
bin/magento cache:flush
Indexer mode. On a live catalog, Update on Save means a bulk product import can lock the store while it rebuilds. Update by Schedule keeps writes cheap and defers the work to cron:
bin/magento indexer:set-mode schedule
bin/magento indexer:reindex
Cron. Cron is not optional in Magento 2 — it drives reindexing, transactional email queues, sitemap generation, and scheduled price rules. Stores launch every week with cron unconfigured on the production host, and the symptoms are confusing: prices that do not update, emails that never send, indexers stuck as invalid. Confirm the crontab is installed for the correct web user and that jobs are completing, not just queued.
Once those three are right, the remaining performance work is covered in the Magento performance guide. Do that tuning before launch, not after — it is easier to measure against a stable baseline than to debug a slow live store.
How do you test checkout before real customers do?
Checkout is the one flow where a defect converts directly into lost revenue, so it gets tested twice: once in sandbox, once for real.
- Sandbox pass. Put your payment gateway in test mode and place orders covering guest checkout, logged-in checkout, a virtual/downloadable product if you sell one, a multi-item cart, and at least one deliberate failure (declined card) to confirm the error is handled gracefully.
- Shipping matrix. Quote every shipping method against a domestic address, a remote or island address, and an international address if you ship abroad. Confirm free-shipping thresholds trigger at the right cart subtotal.
- Tax check. Verify tax on the same set of addresses, including a tax-exempt customer group if you have one. Compare against what your accountant expects, not against what the config screen shows.
- Live low-value order. Switch the gateway to live credentials and buy something cheap with a real card. This is the only test that proves the merchant account, currency, and settlement path are all wired correctly.
- Full order lifecycle. Take that real order through invoice, shipment, and refund in the admin. Confirm each step sends the right email and that stock returns correctly on refund.
- Mobile repeat. Run the whole sequence again on a real phone. Mobile checkout regressions — an unreachable button, a keyboard covering a field — are common and rarely visible in desktop testing.
Only after step 6 passes is checkout genuinely launch-ready. If your theme changed during the build, re-run this after the final design freeze — template edits and checkout behavior interact more than people expect. The decisions behind those templates are covered in the store design guide.
What should you check on the content and SEO side?
Technical correctness gets the store working; this part decides whether anyone finds it.
- Robots directive. Staging sites are usually set to NOINDEX, NOFOLLOW. Flipping this to INDEX, FOLLOW at launch is the single most-forgotten setting in Magento.
- Redirect map. If you are replacing an existing site, every indexed URL needs a 301 to its closest live equivalent. Category and product URLs rarely map one-to-one across platforms, so build the map from a crawl of the old site rather than from memory.
- Metadata. Confirm titles and meta descriptions render on category, product, and CMS pages, and that no default placeholder text survived from the build.
- Sitemap and search console. Generate the XML sitemap, confirm it loads at its public URL, and submit it once the site is indexable.
- Structured data. Check that product pages emit valid product markup, including price and availability.
- Placeholder content. Search the catalog and CMS blocks for lorem ipsum, sample data, and test products — Magento's sample data has a habit of surviving to production.
What is the safe go-live sequence on launch day?
Work in this order, and keep the previous environment intact until you are certain:
- Freeze content and configuration changes on staging.
- Take a full database and file backup, and verify the restore.
- Put the store in maintenance mode for the cutover window.
- Deploy code, run
setup:upgrade,setup:di:compile, andsetup:static-content:deploy. - Switch base URLs to the live domain and flush all caches.
- Reindex and confirm cron is running on the production host.
- Take the store out of maintenance mode.
- Place one real order immediately, end to end.
- Set the robots directive to index and submit the sitemap.
- Monitor error logs, checkout completion, and server load for the first 48 hours.
The order is deliberate: nothing is made public until a real order has succeeded, and nothing is indexed until the public store is confirmed working.
FAQ
Do I need to reindex manually after launching a Magento 2 store?
Run a full reindex once as part of the cutover, after setup:upgrade and the base URL switch. After that, with indexers set to Update by Schedule and cron running, Magento handles reindexing itself. If indexers keep showing as invalid post-launch, the usual cause is cron not running rather than the indexers themselves.
Can I launch a Magento 2 store without Varnish?
Yes. Magento's built-in full-page cache works and many stores launch on it. Varnish generally handles higher traffic more efficiently, which is why it is the common choice for busy catalogs, but the launch blocker is having some full-page cache enabled and working — not which one.
Should I still be running Magento 1?
No. Magento 1 reached end of life and no longer receives official security patches, so running it means carrying unpatched risk on a store that handles payments. Anything covered in this checklist assumes Magento 2, on either Magento Open Source or Adobe Commerce.
What should I check first if the live store is slow on day one?
Confirm the store is in production mode, that all caches are enabled, and that static content was deployed. Those three account for most launch-day slowness. If they are all correct, look at recently added modules next — a single extension shipping render-blocking assets can dominate page load, which is why it is worth vetting extensions before they reach production.
Next step
Work the checklist in order rather than sampling it: mode and caching, indexers and cron, tax and shipping, checkout twice, SEO and redirects, then a tested backup before you touch DNS. Explore Magetique to launch a Magento storefront that is fast and stable from its first real order.
