Shopify Thank You and Order Status Pages: What to Check After the Upgrade Deadline

The upgrade deadline for non-Plus stores passed on 26 August 2026. Check the page version actually in use under Settings › Checkout. According to Shopify’s current guide, a remaining upgrade notice indicates deprecated pages. A date passing does not establish that your store has migrated successfully.

Check the result that matters to your business: do purchases still reach your analytics and advertising systems? Do order status, review invitations and custom notices work? A visible thank you page does not answer those questions.

Key takeaways

• The deadline has passed: check the upgrade status and the pages actually published in your own store.
• Non-Plus plans are affected. Plus stores had their own deadline in August 2025.
• What stops working: additional scripts on the Thank you and Order status pages, old script tags, and apps whose developers have not moved them onto the new foundation.
• The most expensive invisible damage is measurement: purchase pixels for Google Ads, Meta and GA4 classically sit on the thank you page.
• Code is replaced by building blocks: blocks in the checkout and accounts editor plus web and app pixels for events.
• The guide is inside your own store: Settings › Checkout lists the customisations found and the apps affected.
• A test order checks the data flow – the page preview shows the layout, not the data flow.

What Shopify is actually changing

The pages after the purchase – the thank you page right after the order and the order status page customers return to later – ran for years on the same old foundation as checkout. Customisations arrived there as injected code: additional scripts in the admin, script tags from apps, and for Plus stores also edits to checkout.liquid.

The new foundation works differently. By Shopify’s description it is more secure and upgrade-safe, and it is customised not with code but with blocks in the checkout and accounts editor plus pixels for event tracking. In the long run that is the better architecture: building blocks survive platform updates, injected code does not – the history of this very migration is the proof. Short term, though, it means every injected snippet needs a new home or falls away.

How deep this rebuild goes is set out in the review of the 2026 Editions – which also covers the evolution of checkout customisation. Available extensions depend on the page and subscription plan.

Where it hurts in practice

First, tracking. The thank you page is the page where a purchase gets reported as a purchase. If a script there holds a conversion tag for Google Ads, the Meta pixel or a GA4 event, you lose the report after the upgrade – not the order. Ad accounts then see clicks without purchases and optimise accordingly. The clean replacement is Shopify’s customer events (custom pixels and app pixels). These run in the browser, inside a sandbox, rather than automatically on a server, as Shopify’s pixel documentation explains. Why solid first-party data is the more stable foundation anyway is covered in first-party data.

Second, apps with post-purchase functions. Review invitations, shipment tracking, loyalty points, post-purchase upsells: they often live on exactly these pages. Shopify’s guide lists the incompatible ones among your installed apps. For each one, the first question is “is there an updated version?” and only then “what do I replace it with?”. How to keep that list short in the first place is covered in the best Shopify apps.

Third, custom builds with business logic. The most unpleasant find is scripts holding real business rules – notices per customer group, return windows per range, delivery-time calculations. They cannot be rebuilt as a block without somebody understanding the rule again. That takes time; allow for this work in your migration plan.

The checklist after the deadline

1. Take inventory: open Settings › Checkout and work through the guide tailored to your store. It names the additional scripts found and the apps affected – the most reliable inventory you will get.
2. Secure measurement before anything else happens: for every ad account and analytics tool, note where the purchase is reported today. Wherever that happens via script, move it to customer events.
3. Note comparison figures: purchases, revenue and reported conversions for a normal week before the change. Without that baseline, a drop afterwards is indistinguishable from a weak week.
4. Work through the app list: install the updated version, find an alternative, or drop the function. Dropping is a legitimate answer – the third audit question is always “what happens if we delete it?”.
5. Check the published configuration: if migration is still pending, publish the tested configuration. If it has already happened, compare the active blocks and pixels with your inventory.
6. Real test order, then check the target systems. The upgrade is only done once the test purchase shows up in Google Ads, Meta, GA4 and your review tool.

One note on timing: putting the change in the middle of a campaign week is the worst option – real fluctuation and measurement error then overlap. A quiet weekday with a clear baseline is worth more than a perfectly planned weekend.

Bottom line

This change is not a project, it is homework: inventory, pixel migration and a test order, plus development work where custom business logic is involved. It only gets expensive for those who leave it lying around – not because something breaks, but because something quietly goes silent. If you check exactly one thing after 26 August, check the conversion report. Everything else surfaces when customers complain; missing measurement surfaces to nobody except the ad budget. How these pages fit the bigger Shopify picture is laid out in the Shopify guide.