Key Takeaways
- 26 August 2026 is the deadline for non-Plus Shopify stores to upgrade their Thank You and Order Status pages. Shopify's own documentation states that stores which miss it are auto-upgraded, and that "any existing customizations on those pages are replaced".
- The date is commonly reported as the end of Additional Scripts. It is not. Per Shopify's developer docs, checkout.liquid and additional scripts were sunset on those pages on 28 August 2025; what ends for non-Plus stores on 26 August 2026 is script tags.
- Script tags ran whether or not a shopper had consented. Their replacement does not: Shopify's pixel manager "will only load your pixel if there is visitor permission for all of the settings that your pixels declares as required".
- That rule cuts both ways. Consent gating is driven by what each pixel declares, so on a literal reading a pixel migrated across without declared purposes has no permission condition left to fail. Shopify does not document the undeclared case.
- The EDPB has already said this class of technology is in scope. Guidelines 2/2023 treat dynamically constructed tracking pixels — "usually a JavaScript code" — as a "gaining of access" under Article 5(3) of the ePrivacy Directive.
Introduction
You have three weeks. If you run a non-Plus Shopify store, 26 August 2026 is the day Shopify rebuilds your Thank You and Order Status pages whether you have prepared or not, and every script tag you left on them stops running.
Most of the coverage frames this as a conversion-tracking problem: migrate your pixels or watch your ad platforms report zeros. That is real, and it is the smaller half of the story. The mechanism replacing your script tags is consent-aware in a way script tags never were — and it takes its instructions from you. Get the migration mechanically right and your consent posture can still come out worse than it went in.
This is informational content, not legal advice.
What Actually Changes on 26 August 2026
Shopify's Help Center is unambiguous about the date: "August 26, 2026 is the deadline for stores on a non-Plus Shopify subscription plan to upgrade their existing Thank you and Order status pages to the new version of those pages."
Miss it and the decision is made for you. "If you don't upgrade your pages again before August 26, 2026, then your Thank you and Order status pages will be auto-upgraded to the new pages" — and on upgrade, "your existing Thank you and Order status pages and any existing customizations on those pages are replaced with the new versions of those pages."
Here is where most of the ranking coverage goes wrong, and it is worth getting right because it changes what you actually need to audit:
| Date | What sunsets on Thank You / Order Status | Which stores |
|---|---|---|
| 28 August 2025 | checkout.liquid and additional scripts | Per Shopify's docs, on those pages generally |
| 28 August 2025 | Script tags | Plus |
| 26 August 2026 | Script tags | Non-Plus |
Shopify's developer documentation states it plainly: "checkout.liquid and additional scripts were sunset for the Thank you and Order status pages on August 28, 2025", and separately that "Script tags were sunset on those pages on August 28, 2025 for Plus stores, and are sunset for non-Plus stores on August 26, 2026."
So if a migration guide tells you Additional Scripts die in August 2026, it is describing something that happened a year earlier. The live exposure for a non-Plus store is script tags — the ones an app installed on your behalf, or a developer added years ago and nobody has looked at since.
The replacement route is set out in the same Help Center page: "Use blocks and web pixels to recreate customizations to the design and functionality of your Thank you and Order status pages. Use app pixels to continue tracking customer events."
Why a Tracking Deadline Is Also a Consent Deadline
Because the thing being switched off and the thing switched on have different relationships with consent. A script tag fired on page load. A web pixel fires when Shopify's pixel manager decides a visitor's consent state permits it — which means the migration silently moves your marketing tags from "always on" to "conditional", and you own the condition.
The legal frame is not new, and it does not depend on a fresh enforcement action — there is none on this migration, and nobody should tell you otherwise. It rests on Article 5(3) of the ePrivacy Directive, which the EDPB renders as covering "the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user", allowed only on the basis of consent or the narrow necessity grounds in that Article.
The EDPB has been explicit that this is not a cookie-only rule. In Guidelines 2/2023 on the technical scope of Article 5(3), paragraph 1 notes that the Article "does not exclusively apply to cookies, but also to 'similar technologies'", while acknowledging "there is currently no comprehensive list of the technical operations covered by Article 5(3) ePD".
Two paragraphs of those Guidelines land directly on what you are about to install. At paragraph 50, the EDPB finds that distributing tracking pixels to a user's device "does constitute storage, at the very least through the caching mechanism of the client-side software. As such, Article 5(3) ePD is applicable, even if this storage is not permanent." At paragraph 51 it goes further, addressing exactly the JavaScript-driven case: "In the case of dynamically constructed tracking pixels, it is the distribution of the applicative logic (usually a JavaScript code) that constitutes the instruction", and the resulting collection of identifiers "constitutes a 'gaining of access' in the meaning of Article 5(3) ePD".
The Guidelines even name the sector. At paragraph 49, discussing tracking links, the EDPB observes they "are very commonly used by eCommerce websites to identify the origin of their inbound source of traffic" — affiliate attribution, described by the regulator, in the regulator's own words.
Our read of what that means operationally: the order confirmation page is not a compliance-free zone because the sale already closed. If a marketing pixel there reaches into the shopper's browser, the same rule applies as on your product pages — and unlike your product pages, this one is being rebuilt on a deadline.
How Shopify's Web Pixel Consent Gating Actually Works
Shopify gates pixels on declared requirements, not on guesswork. The pixel-privacy documentation states the rule in one sentence: "Shopify's pixel manager will only load your pixel if there is visitor permission for all of the settings that your pixels declares as required."
Read that literally, because the load-bearing word is declares. The manager checks permission for the purposes a pixel says it needs, so a pixel that declares nothing as required presents nothing for a visitor's choice to withhold. Shopify's documentation does not spell out that scenario — treat this as a reading of the stated rule rather than documented behaviour. The conservative course either way is to declare purposes explicitly rather than rely on a default nobody has written down.
Declaring is a deliberate step in both directions. App pixels declare their requirements in the extension's configuration file; for custom pixels, Shopify says "you can define the customer privacy settings that your pixel requires directly within the user interface." Nobody fills that in for you.
The four consent purposes
The Customer Privacy API exposes exactly four. Shopify's descriptions of the first three are quoted below; the fourth is named in the API but the current reference gives no equivalent description, so the mapping column is our recommendation, not Shopify's.
| Purpose | Shopify's description | What we'd map to it |
|---|---|---|
| analytics | "Cookies to understand how customers interact with the site." | GA4, analytics-only measurement |
| marketing | "Cookies to provide ads and marketing communications based on customer interests." | Meta, TikTok, Google Ads conversion pixels |
| preferences | "Cookies that remember customer preferences, such as country or language, to personalize visits to the website." | Locale and currency persistence |
| sale_of_data | — (no description in the current reference) | US state-law data-sharing signals |
Most migration errors we would expect to see are a purpose mismatch rather than a missing pixel: an advertising conversion tag declared under analytics passes for a visitor who accepted measurement and refused advertising. The pixel loads. The shopper's actual answer was no.
The default is regional, not global
This is the sentence to take away from Shopify's Customer Privacy API reference: "For regions that are configured to require consent, non-essential purposes are not allowed by default until consent is given. For other regions, the default behavior is to allow all processing purposes."
Consent-first is therefore conditional on region configuration — not a global default. For an EU or UK store the practical consequence is that region configuration is load-bearing infrastructure, and it is worth verifying rather than assuming, particularly if you sell into multiple markets from one storefront.
One more thing before you lean on the platform for your legal position: in the sections of the Customer Privacy API and pixel-privacy references we reviewed, Shopify names no specific regime — no GDPR, no EEA, no UK. The framing throughout is "regions that are configured to require consent". Shopify's separate app privacy page does name GDPR and CPRA, and states it "isn't intended to provide you with legal advice." That is a reasonable position for a platform to take, and it means the compliance conclusion is yours to reach and yours to evidence.
How Do You Migrate Without Breaking Consent?
Work through the pixels before the deadline, not the design. A practical order for the three weeks remaining:
- Inventory every script tag on the two pages. Script tags are the thing sunsetting for non-Plus stores. Include ones installed by apps you no longer actively use — those are the tags nobody remembers and nobody re-declares.
- Assign each survivor a purpose before you rebuild it. Decide whether the tag is analytics, marketing, preferences or sale-of-data first. The rebuild step then has an answer to configure rather than a default to accept.
- Declare the purpose explicitly on every pixel. In the custom-pixel UI or the app extension's configuration, set what the pixel requires. Do not leave requirements blank on the assumption something downstream will catch it.
- Re-verify your CMP's mapping into the Customer Privacy API. If a consent platform sets consent state for you, its categories must line up with the four purposes above after the rebuild — a mapping that was correct against your old setup is not automatically correct against new pixels.
- Test refusal, not just acceptance. Decline marketing on a test order and confirm the marketing pixels stay dark through the Thank You page. Acceptance tests pass in almost any configuration; refusal is the one that tells you the gate exists.
- Record what you concluded. Article 7(1) GDPR requires that "the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data" — which is easier to satisfy when the purpose mapping was written down in August than reconstructed later.
If you only have time for two of these, do 1 and 5. An inventory tells you what you are responsible for, and a refusal test tells you whether the responsibility is met.
Common Mistakes
Treating the auto-upgrade as a fallback. It is the single most expensive misreading of this deadline. Shopify replaces the pages and their customizations; it does not carry your consent intentions forward, because it was never told what they were. Waiting means the platform picks defaults and you inherit them.
Porting a tag without porting the decision. Copying a Meta or TikTok snippet into a custom pixel is a fifteen-minute job. Deciding it is a marketing purpose, declaring it, and testing that a refusal suppresses it is the job that matters — and it is the one that gets skipped when the deadline is close.
Assuming the order confirmation page is post-consent territory. The sale is complete; the ePrivacy analysis is not. On the EDPB's reading in Guidelines 2/2023, the question is whether something is stored on or read from the shopper's device, and a conversion pixel on a Thank You page does exactly that.
Trusting a migration guide's dates. Several of the better-ranking guides conflate the 2025 checkout.liquid sunset with the 2026 script-tag sunset, and at least one folds in an unrelated Shopify Scripts deadline. Check any date you are about to act on against Shopify's own documentation.
Letting the CMP off the hook. Consent tooling that talks to Shopify's API can drift out of alignment with it. On Shopify's own community forum, a developer reported that a consent platform's signal did not sync into the Customer Privacy API until a page reload — the kind of gap that surfaces only when someone tests a refusal. Our guide to OneTrust alternatives for SMB and Shopify stores covers how these integrations diverge in practice.
How PrivacyForge Helps
The hard part of this migration is not the pixel configuration — it is knowing what you had, what you decided, and being able to show it later. PrivacyForge's consent management keeps a record of what each visitor was asked and what they answered, which is the evidence Article 7(1) asks for and the thing a rebuilt Thank You page will not reconstruct for you.
The data mapping side matters just as much this month, because a pixel inventory is a processing inventory: recording which tags run on which pages, under which purpose, and to which recipient gives you a record of processing and a rebuild checklist at once. For the wider picture, start with our complete guide to GDPR compliance or the mechanics in cookie consent best practices.
Frequently Asked Questions
What happens to my Shopify tracking on 26 August 2026?
Script tags on your Thank You and Order Status pages stop running if you are on a non-Plus plan, and any store that has not upgraded those pages is auto-upgraded by Shopify. Shopify's Help Center states that existing customizations on those pages "are replaced with the new versions of those pages". Tracking must be rebuilt using blocks, web pixels and app pixels.
Do Shopify web pixels respect cookie consent automatically?
Only for the purposes each pixel declares. Shopify's documentation states its pixel manager "will only load your pixel if there is visitor permission for all of the settings that your pixels declares as required". Declaring those requirements is a manual step — in the custom-pixel interface, or in an app pixel's extension configuration. On a literal reading of that rule, a pixel migrated across without them presents nothing to be gated on, though Shopify does not document the undeclared case.
Is 26 August 2026 the end of Additional Scripts?
No. Shopify's developer documentation states that "checkout.liquid and additional scripts were sunset for the Thank you and Order status pages on August 28, 2025". What ends for non-Plus stores on 26 August 2026 is script tags: they "were sunset on those pages on August 28, 2025 for Plus stores, and are sunset for non-Plus stores on August 26, 2026". Several migration guides conflate the two.
Does Shopify block non-essential tracking by default in the EU?
Only where the region is configured to require consent. Shopify's Customer Privacy API reference states that "[f]or regions that are configured to require consent, non-essential purposes are not allowed by default until consent is given. For other regions, the default behavior is to allow all processing purposes." The behaviour follows your region configuration, so EU and UK stores should verify it rather than assume it.
Do tracking pixels fall under the ePrivacy rules, or only cookies?
The EDPB's Guidelines 2/2023 state that Article 5(3) "does not exclusively apply to cookies, but also to 'similar technologies'". At paragraph 51 the Guidelines treat dynamically constructed tracking pixels — where "the distribution of the applicative logic (usually a JavaScript code)" is the instruction — as a "gaining of access" under Article 5(3). Pixels are in scope on that reading.
What are the four Shopify consent purposes?
The Customer Privacy API exposes analytics, marketing, preferences and sale_of_data. Shopify describes analytics as "[c]ookies to understand how customers interact with the site", marketing as "[c]ookies to provide ads and marketing communications based on customer interests", and preferences as cookies remembering choices "such as country or language". Each pixel declares which of these it requires.
Conclusion
Three weeks out, the useful reframe is this: 26 August 2026 is not a tracking deadline with a consent footnote. It is a forced rebuild of the page where your marketing tags meet your customers' choices, and the rebuild takes its instructions from what you declare.
The work is small if you start now — inventory the script tags, assign each survivor a purpose, declare it, and test a refusal. It is considerably less small if the auto-upgrade gets there first and you spend September working out what your store is doing and why.
Start with the inventory. Try PrivacyForge free if you want the consent records and processing inventory to come out of it too.
Sources
- Shopify Help Center: Upgrade your Thank you and Order status pages — the 26 August 2026 non-Plus deadline, auto-upgrade, and replacement of existing customizations
- Shopify.dev: checkout.liquid — sunset dates for checkout.liquid, additional scripts and script tags
- Shopify.dev: Web Pixels API — pixel privacy — the pixel manager's declared-requirements loading rule
- Shopify.dev: Customer Privacy API — the four consent purposes and the regional default behaviour
- Shopify.dev: Privacy law compliance for apps — GDPR and CPRA framing, and the not-legal-advice disclaimer
- EDPB Guidelines 2/2023 on the Technical Scope of Art. 5(3) of the ePrivacy Directive — paragraphs 1, 49, 50 and 51 on cookies and "similar technologies", tracking pixels, and JavaScript-driven access
- GDPR Article 7: Conditions for consent — the controller's duty to demonstrate consent