My Blog
Shopify Theme Update Checklist: Test the Draft Before Publishing
Updating a Shopify theme can affect more than its appearance. A section may move, a product option may behave differently, or an app feature may be…

Updating a Shopify theme can affect more than its appearance. A section may move, a product option may behave differently, or an app feature may be absent. Treat the updated theme as a draft to compare with the live store. Record the starting point, test the pages customers use, and keep a clear route back if the published result has a serious fault.
1. Record the starting point
In Shopify admin, open Online Store and record the published theme's name and version. Check the update notification and read the release notes. Note any changed feature that deserves a focused test. Shopify’s theme update guide explains where to check the version and add an update.
Make a short inventory of the live storefront before changing it. Capture the home page's section order, header, footer, collection layout, product template, cart and mobile menu. Include any market-specific presentation and special templates. Label screenshots with the page, device or viewport, and date, so that comparisons with the draft are possible.
Separate theme-editor customisations from code edits. Editor changes include settings, sections, blocks, templates and app embed settings. Code edits include changes made directly to theme files, whether by a person or an app. Shopify says editor customisations are copied into an updated theme; code edits transfer only when they do not conflict with the update. Record the purpose and affected page of each known code change, and save a copy of customised code. An unexplained modification needs investigation before anyone removes it.
Duplicate the live theme as a backup and give the copy an identifiable name in your notes. This helps distinguish the backup from the updated draft. Shopify’s duplication instructions cover the backup step. List customer-facing app blocks, app embeds and features added through code, including where each appears. The app list alone does not show whether a feature works on a particular page.
2. Add and inspect the updated draft
Open the update notification and select Add to draft themes. Adding the update there does not change the published theme. Shopify names the result with an “Updated copy of” prefix and provides a Review action. Confirm you are inspecting that draft rather than the live theme or backup.
Read the code-edit status on the draft's theme card. “Theme added: code edits successfully included” means Shopify included the edits; it does not prove that the affected features still work. “Theme added: code edits could not be included” means you need to identify which edits are required, copy those into the draft where appropriate, and test them. Record the status and each resulting decision in the regression sheet.
Compare editor settings, templates, section order, blocks and wording with the live-theme inventory. For custom CSS, check that the selectors still target the intended elements and that the styles apply. Inspect modified files and exercise the behaviour each change was intended to provide. A visual match on the home page cannot establish that product or cart changes survived.
If Add to draft themes is unavailable, stop this procedure at the update step. Shopify says some themes cannot use the standard process. Installing a fresh copy and applying customisations manually is a different migration; do not assume the existing settings or code will transfer.
3. Build a useful regression sheet
For each check, record the page or feature, expected result, observed result, and whether it depends on editor settings, code or an app. Mark it pass, fail or not tested. Add the draft version, a screenshot or note where useful, and enough detail to reproduce a failure. Adapt the following checks to features your store actually uses:
- Home page: Compare section order, text, featured products, links and layout at desktop and mobile widths.
- Collections: Open a representative collection. Check product cards, sorting, filters and pagination where present; record the selections and visible results.
- Products: Use a product with variants. Change an option and check the selected variant, displayed details and the item added to the cart.
- Cart: Add an item, change its quantity and remove it. Check displayed totals and any cart drawer or app-controlled component.
- Mobile navigation: Open and close the menu, follow nested links and check that controls remain usable at a narrow width.
- Apps and code: Check each required block, embed, Custom Liquid section or modified file on the page where its output should appear.
Give a special product template, search feature or other important storefront function its own row. Write observable expectations such as “changing the size selects the corresponding variant”, rather than “product page looks fine”. Mark an unused feature as not applicable instead of passing it without a test. A reviewer should be able to see exactly what was checked and what remains open.
Choose test cases that expose differences within your own catalogue. A product with one option may miss a variant-selection fault; use one with several options if customers can buy it. If collections use different filters or templates, sample each type instead of testing the same layout twice. Record the exact product and collection URLs in the sheet so another reviewer can repeat the checks. If a feature depends on a particular market, test it in that market's view and label the result accordingly.
4. Test a complete customer journey
Preview the draft and follow a short route through the store: open the home page, enter a collection, select a product, change a variant and add it to the cart. Confirm the result after each action. Repeat at a mobile width, including navigation and any cart drawer. Test a second product template or market view if it differs materially from the first.
Check apps in both the theme editor and the preview. App blocks occupy positions in compatible sections or templates; app embeds may appear as overlays or add code without a visible element. Some apps also add code directly to theme files. Shopify notes that apps may need reactivation after a change of published theme. A copied setting is therefore a starting point for inspection, not a pass result. Shopify’s app integration guide explains blocks, embeds and code-based additions.
For each failure, record the page, device or viewport, steps taken, expected result and actual result. Correct the draft and repeat the failed check plus any connected journey. After a cart fix, for example, repeat the product-to-cart path. Leave unresolved failures marked as failures; a page loading successfully does not show that its controls work.
5. Publish and check the live result
Before publishing, make sure the sheet identifies the tested draft, its code-transfer status, completed checks and any accepted exceptions. Have the person responsible for the store review the record. Choose a time when someone can inspect the live storefront soon after publication. The draft preview is the main preparation, but it cannot replace a check of the published result.
After publishing, repeat the key journey on the live store and check the app features that matter to customers. Keep the former published theme identifiable: Shopify moves it to Draft themes when a new theme is published. If a serious regression appears, that retained version is a concrete rollback candidate while the new theme is investigated. Shopify’s publishing guide describes what happens to the previous theme.
Keep the regression sheet with the theme versions and final live-check results. It should show which version was tested, what transferred, which failures were fixed, and which checks were completed after publication.