Preview and staging for stores: testing changes safely
How to test theme changes, apps, campaigns and storefront releases before customers see them, on a theme and on a headless setup.
The short answer
A store changes constantly: theme edits, new apps, campaign pages, checkout settings, storefront releases. Each is a chance to break something in front of customers unless it is tested somewhere safe first. On a theme, that means duplicating the live theme, making the change on the copy and checking it through the preview link before publishing. For apps, data changes, Flow and checkout settings, it means a development store that mirrors the live configuration with test payments. For a headless storefront, it means a preview deployment per change on real infrastructure, approved on a phone, with production receiving only approved builds. Editing the live theme directly is the single most common cause of a self-inflicted store outage, and every one of them was avoidable.
What to test where
| Change | Where to test | How |
|---|---|---|
| Theme edits, sections, styling | A duplicate of the live theme | Preview link on phone and desktop; publish when approved |
| New app | A development store | Install, inspect what it injects, measure speed, check data handling |
| Flow workflows | A development store, then low-impact actions on live | Trigger with test orders |
| Checkout and payment settings | A development store with test payments | Place orders through every method and market |
| Campaign landing pages | Unpublished theme or hidden page | Preview link; publish on schedule |
| Product data changes at scale | Export, test import on a development store | Reconcile before importing live |
| Headless storefront code | Preview deployment per change | Approve on a phone; atomic release; rollback available |
| Integrations | Development store connected to test instances | End-to-end with test orders |
The routine
- Keep a development store synced with the live theme and configuration; refresh it monthly.
- Never edit the live theme: duplicate, change, preview, publish.
- Trial every app on the development store and measure the storefront before and after.
- Test checkout changes with test payments across markets and methods.
- Schedule publishes for quiet hours, never Friday afternoon or the start of a campaign.
- Keep the previous theme unpublished as the rollback.
- For a headless storefront, use preview deployments for every change and release only approved builds.
Why headless makes this better
A theme’s preview is a link to a copy; a headless storefront’s preview is the whole site with exactly the proposed change, built by the same pipeline that builds production, with automated checks already run. Approval is a phone and a tap. Release is atomic and reversible. It is the strongest testing setup a store can have, and it is one of the operational reasons stores move to a storefront they own as software.
What this means for you
Test theme changes on a duplicate with the preview link, apps and behaviour changes on a development store, checkout settings with test payments, and storefront code on preview deployments. Keep the previous theme as the rollback and schedule publishes for quiet hours. A store that never edits its live theme directly avoids the most common outage there is, and one that runs a headless storefront with previews has the strongest safety net available.
Frequently asked questions
Can we test a theme change without affecting customers?
Yes: duplicate the live theme, make the change on the copy, and use the preview link to check it on a phone and a desktop before publishing. Publishing swaps the whole theme atomically. Editing the live theme directly is where store outages come from, and it is entirely avoidable.
How do we test a new app before installing it on the live store?
On a development store that mirrors the live configuration: install the app there, see what it injects into the storefront, measure the speed impact, check its settings and its data handling. Then decide. Apps installed straight onto the live store change it for customers immediately, and some are hard to remove cleanly.
What does staging look like for a headless storefront?
Every change gets its own preview deployment on the real infrastructure: the full storefront with exactly that change, at a link to approve on a phone, connected to the store's data or a development store's. Production receives only approved builds, and any build can be rolled back. It is the same discipline as any well-run website, applied to the store.
Sources
- Shopify Help Center: Themes (accessed 2026-09-12)