Shopify

Shopify elimina los script tags: fechas, qué se rompe y cómo migrar

Desde el 1 de octubre de 2026 las apps ya no pueden crear ni actualizar script tags, y el 1 de marzo de 2027 Shopify dejará de cargarlos en las tiendas. Te explico qué hacer si tienes una app, cómo revisar tus script tags y con qué reemplazarlos.

  • Javi Mata
  • 9 min de lectura
Tabla de contenido

Durante años, la forma más rápida de que una app de Shopify cargara JavaScript en una tienda fue un script tag: la app registraba la URL de un archivo .js con la API y Shopify lo inyectaba en las páginas. Eso se acaba. Shopify está quitando los script tags de las tiendas, con fechas concretas, y lo incluyó entre las novedades para desarrolladores de la Fall ‘26 Edition: “Apps can no longer create or update script tags and must migrate to theme app extensions or web pixels”.

Este artículo resume la guía oficial de shopify.dev consultada el 30 de octubre de 2026. Si tienes una app (pública o personalizada para un cliente) que usa script tags, esto te afecta.

Las fechas

FechaQué pasa
1 de octubre de 2026Ya no puedes crear ni actualizar script tags. Los que existen siguen funcionando.
1 de marzo de 2027Shopify deja de inyectar script tags en las tiendas.

Desde el 1 de octubre, las mutaciones scriptTagCreate y scriptTagUpdate devuelven un error de permisos en todas las versiones de la API, y lo mismo pasa con las peticiones POST y PUT al recurso ScriptTag de la REST Admin API. Las operaciones de lectura y borrado siguen funcionando, así que todavía puedes revisar y limpiar.

El 1 de marzo de 2027 tu script dejará de cargarse y cualquier función que dependa de él dejará de funcionar en esa tienda. Los registros que queden no tendrán efecto, así que después de esa fecha no hace falta borrarlos.

Lo que ya se rompió: la página de estado del pedido

La página de estado del pedido (Order status) va por delante, con un calendario propio. Solo aplica a script tags con display_scope igual a order_status o all:

FechaQué pasó
1 de febrero de 2025Las apps ya no pueden crear script tags con ese display_scope.
28 de agosto de 2025Dejan de ejecutarse en la página de estado del pedido en tiendas Plus.
26 de agosto de 2026Dejan de ejecutarse en la página de estado del pedido en el resto de tiendas.

Es decir: si tu app personalizaba la página de estado del pedido con un script tag, eso ya no funciona en ninguna tienda. Ahí los reemplazos son las extensiones de UI de cuentas de cliente (para mostrar contenido) o un web pixel (para medir). Ojo: un script tag con display_scope all sigue ejecutándose en la tienda hasta el 1 de marzo de 2027.

Primero, revisa qué script tags tienes

La consulta scriptTags de la Admin GraphQL API devuelve los script tags de tu app. Este es el ejemplo de la referencia, con paginación y los campos útiles para revisar:

query GetScriptTags($first: Int!, $cursor: String) {
  scriptTags(first: $first, after: $cursor) {
    nodes {
      id
      cache
      createdAt
      displayScope
      src
      updatedAt
    }
    pageInfo {
      startCursor
      endCursor
    }
  }
}

Si mantienes muchas apps, por ejemplo una app personalizada para cada cliente (el caso típico de una agencia), la guía indica revisarlas una por una: ejecuta la consulta con un token que la app ya tenga para una tienda donde esté instalada y repite en cada tienda. Lo que encuentres lo borras con scriptTagDelete, pero no antes de tener el reemplazo funcionando (más abajo explico por qué).

Con qué reemplazarlos

La guía lo resume en dos casos:

Si tu app usa un script tag para…Usa
Cargar JavaScript en las páginas de la tiendaUn app embed block
Medir analítica, conversiones o comportamiento del clienteUn web pixel

App embed block: el reemplazo directo

Un app embed block es parte de una extensión de tema de app (theme app extension), que construyes y despliegas con tu app. Sus ventajas, según la documentación:

  • Funciona en temas vintage y en temas Online Store 2.0, porque no depende de secciones ni de plantillas JSON.
  • Aparece en el editor de temas, en Theme Settings > App embeds, donde el comerciante ve que tu app está activa y puede desactivarla.
  • Shopify lo inyecta antes del cierre de </head> o de </body>, según el target que pongas en su esquema: head, body o compliance_head (este último solo cuando hace falta, por ejemplo para banners de consentimiento de cookies).
  • Puedes cargar el script solo en algunas plantillas con enabled_on o disabled_on, algo que el script tag no permitía.

Si tu script inyecta contenido en la página, un app embed block también te sirve, porque tu JavaScript hace el mismo trabajo que hoy.

Este es el ejemplo mínimo de la documentación (un archivo Liquid en la carpeta blocks de la extensión):

<div style={{position: 'fixed', bottom: '0', right: '0'}}>
    {{ "kitten.jpg" | asset_url | img_tag }}
</div>
{% schema %}
  {
    "name": "App Embed",
    "target": "body",
    "settings": []
  }
{% endschema %}

En el esquema también puedes usar javascript y stylesheet para cargar un archivo de la carpeta assets de la extensión; si varios bloques usan el mismo archivo, se incluye una sola vez.

Una limitación: los app embed blocks solo tienen acceso al ámbito global de Liquid de la página y no pueden usar fuentes dinámicas. Si necesitas contenido que el comerciante coloque dentro de una sección, eso es un app block (target content), pero solo funciona en temas con plantillas JSON.

Web pixel: si solo mides

Si tu script solo recolecta datos, la guía dice que un web pixel es el reemplazo más sencillo: no hay que activarlo en el editor de temas. Tu app lo crea con la mutación webPixelCreate, y el comerciante aprueba los permisos write_pixels y read_customer_events al instalar o actualizar la app.

Los web pixels corren en un sandbox y respetan las señales de consentimiento del cliente. Esto implica que lo que dependa de leer o modificar el DOM no funcionará igual o no funcionará; para eso está la API de web pixels, que pasa los datos de los eventos al sandbox.

Cómo migrar sin dejar un hueco

El detalle que más importa: un app embed block está desactivado hasta que el comerciante lo activa, y tu app no puede activarlo por él. Si borras el script tag antes, la función desaparece hasta que alguien active el bloque. El orden que propone la guía:

  1. Construye la extensión de tema con tu app embed block.

  2. Manda al comerciante al editor de temas con el bloque ya activado mediante un deep link:

    https://<myshopifyDomain>/admin/themes/current/editor?context=apps&template=${template}&activateAppId={api_key}/{handle}

    Donde {api_key} es el client_id de tu app y {handle} es el nombre del archivo Liquid del bloque (por ejemplo, app-embed para blocks/app-embed.liquid). El comerciante ve la vista previa y guarda.

  3. Confirma que el bloque está activo en el tema publicado. Desde tu app en el administrador puedes usar shopify.app.extensions() de la App API: un status igual a active indica que está activado, y available, que tu app lo incluye pero el comerciante no lo ha activado. Desde tu backend, puedes leer config/settings_data.json del tema publicado (requiere el permiso read_themes).

  4. Borra el script tag con scriptTagDelete.

¿Por qué no dejar los dos? Porque mientras convivan, tu script se cargará dos veces, y eso puede duplicar eventos de analítica o mostrar dos veces la interfaz de tu app.

Un detalle más: el app embed block solo está activo en el tema donde se activó. Si la tienda publica otro tema, hay que volver a comprobarlo.

El caso que nadie ve venir: apps personalizadas creadas en el administrador

Las apps personalizadas creadas directamente en el administrador de Shopify (no con Shopify CLI ni con el Dev Dashboard) no pueden usar extensiones de app, así que tampoco extensiones de tema ni web pixels. No tienen un reemplazo basado en extensiones. La guía distingue tres situaciones:

  • Si tú la mantienes: mueve el script al tema, con un bloque de Liquid personalizado si es posible, o desde el editor de código si hace falta. La documentación advierte que un script en el código del tema se queda ahí aunque la app desaparezca, y que editar el código saca al tema de su ruta de actualizaciones automáticas, así que solo conviene cuando la app no puede usar extensiones.
  • Si la mantiene una agencia u otro desarrollador: tienen que mover el script al tema o construir un reemplazo.
  • Si un servicio externo te pidió crear la app y pegar un token de acceso en su panel: ese servicio tiene que publicar una app real que use una extensión de tema o un web pixel.

Si eres comerciante y tienes una app de este tipo instalada por un proveedor, mi recomendación es preguntarle ya qué plan tiene antes del 1 de marzo de 2027.

Mi recomendación

  1. Haz el inventario esta semana. Ejecuta scriptTags en cada app y cada tienda, y anota src y displayScope.
  2. Separa lo que pinta de lo que mide. Lo que solo mide va a un web pixel; lo demás, a un app embed block.
  3. Prepara el deep link y la comprobación de activación antes de borrar nada.
  4. Revisa las apps creadas en el administrador. Son las que no tienen reemplazo directo y las que más fácil se olvidan.
  5. No esperes a marzo. Desde el 1 de octubre de 2026 una instalación nueva ya no puede crear el script tag, así que cualquier tienda que instale hoy tu app sin el reemplazo listo se queda sin esa función.

Conclusión

Los script tags fueron cómodos, pero cargaban JavaScript en toda la tienda sin que el comerciante lo viera. Los app embed blocks y los web pixels hacen lo mismo, pero visibles, controlables y mejor integrados con el tema y el consentimiento. Tienes hasta el 1 de marzo de 2027, pero el cambio ya está en marcha: desde octubre no se pueden crear script tags nuevos.

Fuentes