Shopify Set Deadlines for Storefront Script Tags. Hydrogen Teams Need an App-by-App Plan.

Shopify storefront script tag deprecation and Hydrogen migration planning

Shopify has put two hard dates on storefront script tags.

On October 1, 2026, apps lose the ability to create or update them. On March 1, 2027, Shopify stops injecting existing script tags into storefronts.

Changing Admin API versions will not buy more time. Shopify says the restriction applies across all API versions.

For extension-capable apps on Liquid themes, Shopify's migration path is clear: move storefront behavior to theme app extensions and analytics to web pixels. For Hydrogen, that answer is incomplete. A theme app extension does not become a React component, and a sandboxed web pixel cannot replace JavaScript that reads or changes the DOM.

Hydrogen teams therefore need an app-by-app plan, not a global search-and-replace.

The two deadlines affect different parts of the migration

Date	What changes	What still works
October 1, 2026	`scriptTagCreate` and `scriptTagUpdate` return permission errors. REST requests that create or update script tags fail.	Existing tags continue to run. Apps can still query and delete them.
March 1, 2027	Shopify stops injecting storefront script tags.	Audit and cleanup remain possible through the read and delete operations Shopify keeps available.

The first date freezes the old integration surface. The second turns it off.

That makes October 1 the practical deadline for app developers. After it passes, an app cannot repair a legacy script tag by changing its source URL or scope. It must already have a replacement path.

Order status page script tags are already gone. Shopify's final Order status deadline passed on August 26, 2026, one day before this article was published. Tags with an ORDER_STATUS or ALL scope no longer run there. An ALL tag can still run on the Online Store until March 1, 2027.

App developers should audit their own script tags now

The Admin GraphQL API keeps the scriptTags query available. It requires the read_script_tags scope and returns only the tags owned by the app making the request. The scriptTagDelete mutation separately requires write_script_tags.

query ExistingScriptTags($cursor: String) {
  scriptTags(first: 100, after: $cursor) {
    nodes {
      id
      src
      displayScope
      createdAt
      updatedAt
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

graphql

Run the query until hasNextPage is false. For every result, identify:

Which feature or internal service inside your app owns the src URL.
What the script does in the browser.
Which storefronts and page types depend on it.
Whether the same behavior already has a headless integration.
Who can test and approve its replacement.

The source URL is only a starting point. A script might render a widget, alter product-page behavior, collect analytics, synchronize consent, or combine several of those jobs. The correct replacement depends on the behavior, not the tag itself.

A merchant cannot use one app's credentials to enumerate every vendor's tags. Hydrogen teams should start with their installed-app inventory and require each vendor to audit and report the script tags it owns.

Shopify's replacements for extension-capable apps are not interchangeable

For apps that can ship extensions, Shopify names theme app extensions and web pixels as the migration paths. Each serves a different job.

App embed blocks cover theme-integrated storefront behavior

An app embed block is part of a theme app extension. Shopify injects it into a theme near the closing head or body tag. The merchant enables it in the theme editor, and activation is specific to that theme.

This is a better model than a remote script silently appearing on every page. The extension is declared, reviewable, and controlled through the theme.

It is also a Liquid theme mechanism. It does not install a component into a Hydrogen React application.

Web pixels cover customer-event collection

Web pixel app extensions are the intended path for analytics, conversion tracking, and customer-behavior events. They run in Shopify's strict Web Worker sandbox and receive customer events through Shopify's pixel APIs. Merchant-added custom pixels use a separate lax sandboxed iframe.

Neither pixel model restores unrestricted access to the rendered storefront. A web pixel app extension cannot use window.document, and a custom pixel cannot access the top frame. A script that opens a modal, inserts a review widget, changes a product form, or reads arbitrary DOM state cannot move into a web pixel unchanged.

That restriction applies to the pixel path. JavaScript shipped through an app embed can continue doing storefront DOM work.

Admin-created custom apps are an important exception. Shopify says these apps cannot use app extensions, which means they cannot ship a theme app extension or web pixel as the replacement. Their maintainers need to move the behavior into the storefront or release a proper app with an extension-based integration.

Hydrogen storefronts need a third path

A ScriptTag injects remote JavaScript into Shopify's Online Store pages. A Hydrogen storefront is a separate application, so it never had that automatic theme injection as a valid headless integration path.

The deprecation does not suddenly remove working script tags from Hydrogen. It exposes a compatibility question that headless teams should already be asking: how does each app integrate without assuming a Shopify theme owns the page?

For Hydrogen storefront analytics, Shopify documents Analytics.Provider and useAnalytics, with custom components forwarding events to third-party services when needed. Current Hydrogen documentation does not present an installed app pixel as a drop-in way to execute storefront code inside the Hydrogen application.

Shopify-hosted checkout and post-purchase surfaces are separate from the Hydrogen storefront and are covered by web pixels. Test them independently rather than treating "headless" as one surface.

The resulting migration map is straightforward:

Existing behavior	Liquid replacement	Hydrogen question
Storefront widget or visual UI	App embed block	Does the vendor provide a React component, SDK, or API?
DOM-dependent personalization	Theme app extension	Can the behavior be implemented explicitly in the Hydrogen app?
Analytics and conversion events	Web pixel	Which events come from Hydrogen Analytics, and which require a custom third-party integration?
Back-office synchronization	Usually no storefront replacement	Does the app work entirely through Admin APIs, webhooks, or Shopify Events?

If a vendor answers only with "we have an app embed," it has answered the Liquid question. It has not answered the Hydrogen one.

The vendor checklist Hydrogen teams should use

Send each affected vendor the same questions:

Does your app create or update Shopify storefront script tags today?
Which customer-facing features depend on those tags?
What replaces each feature before October 1, 2026?
Is the replacement a theme app extension, web pixel, API, SDK, or React package?
Does your headless integration require manual code in the Hydrogen app?
Does any feature require DOM access that a web pixel cannot provide?
Which events are collected on the Hydrogen storefront versus Shopify-hosted checkout and post-purchase surfaces?
How should consent and duplicate-event prevention be tested?
What happens during uninstall or rollback?
Can you provide a Hydrogen-specific test plan rather than a theme setup guide?

Do not accept "headless compatible" as the answer. Ask for the integration surface and the test path.

Migrate without double-loading the old and new paths

The safest sequence is boring:

Ask each app or vendor to inventory the storefront script tags it owns, then reconcile the responses against the installed-app list.
Map each tag to its owner and browser behavior.
Confirm the replacement contract with the vendor.
Implement the replacement in a development or staging storefront.
Test consent, attribution, page navigation, cart behavior, and checkout handoff.
Verify that the old and new integrations do not both send events or render UI.
Remove the legacy tag only after the replacement passes.
Monitor the production result and keep rollback inside the replacement implementation.

After October 1, deleting a legacy tag is irreversible through the ScriptTag API because creation and updates are blocked. Rollback must disable or revert the replacement. It cannot depend on recreating or repairing the old tag.

Duplicate analytics are the easiest failure to miss. If a web pixel starts sending events before the old script is removed, conversion data can look healthy while being wrong.

The same caution applies to widgets on a Liquid storefront. Running a legacy script and its replacement app embed on the same rendered theme can produce duplicate UI or conflicting listeners. A Liquid app embed and a separate Hydrogen renderer do not share that document.

Where Weaverse fits, and where it does not

Weaverse can make a developer-built Hydrogen integration composable. A team can wrap a vendor SDK or API in a schema-backed component, then let merchants control approved settings and placement in Studio.

Weaverse does not turn a Liquid app embed into a Hydrogen component, and it does not make an app's storefront script or pixel execute automatically. The vendor still needs a real headless integration surface. The developer still owns the code boundary.

That distinction is the broader lesson in Shopify's deprecation. Arbitrary injected JavaScript is being replaced by explicit contracts. Hydrogen already requires that explicitness. The work now is making sure every app in the stack has a contract that actually reaches the headless storefront.

If you are evaluating that split more broadly, see Hydrogen vs Online Store 2.0 and what Shopify rollouts mean for headless merchants. For event-driven integrations that avoid storefront injection entirely, see Shopify's next-generation Events platform.