Shopify Checkout Extensibility

Am 26. August 2026 ist für die letzte Gruppe von Shopify-Shops eine Frist verstrichen, von der die meisten nie eine E-Mail bekommen haben, die sie tatsächlich gelesen haben. Heute, am 10. September 2026, sind seit diesem Stichtag gut zwei Wochen vergangen – und ein beträchtlicher Teil der betroffenen Shops weiß bis jetzt nicht, dass er betroffen ist. Der Checkout selbst läuft weiter, Kund:innen können weiterhin bestellen, bezahlen, eine Bestellbestätigung bekommen. Genau das macht diese Abschaltung so tückisch: Sie zeigt sich nicht als Fehlermeldung, sondern als Lücke, die erst auffällt, wenn jemand die Zahlen genauer anschaut.

Was tatsächlich passiert ist, lässt sich in zwei getrennte, aber verwandte Vorgänge aufteilen. Laut Shopifys eigener Entwicklerdokumentation wurden checkout.liquid und die sogenannten Additional Scripts für die Thank-you- und die Order-Status-Seite – die Seite, die ein Kunde nach dem Kaufabschluss sieht – am 28. August 2025 abgeschaltet. checkout.liquid war dabei ohnehin ein Feature, das laut Shopify „available only to Shopify Plus merchants" war – reines Plus-Terrain, mit dem sich Agenturen und interne Teams die Bestellstatus-Seite frei mit eigenem Liquid-Code gestalten konnten.

Für die zweite, breitere Kategorie – die sogenannten Script Tags, mit denen sich Tracking-Pixel, Chat-Widgets oder andere externe Skripte unabhängig vom Liquid-Code in die Bestellstatus-Seite einschleusen ließen – galt eine gestaffelte Abschaltung: 28. August 2025 für Plus-Shops, 26. August 2026 für alle übrigen Shops. Diese zweite Frist ist die, um die es in diesem Text geht. Sie betrifft die große Mehrheit der Shopify-Shops weltweit, die auf Basic-, Shopify- oder Advanced-Plänen laufen – und sie ist, während du das hier liest, bereits abgelaufen.

Unabhängig von diesen beiden Terminen gilt außerdem, seit längerem: checkout.liquid ist für die Schritte Information, Versand und Zahlung – also den eigentlichen Kaufabschluss vor der Bestellbestätigung – nicht mehr unterstützt. Was Shopify an die Stelle all dessen setzt, sind Shopify Extensions in Checkout: ein neues System aus UI-Extensions, Functions, Web-Pixel-Extensions und Payment-Extensions, das dieser Leitfaden ab Abschnitt 04 im Detail durchgeht.

Warum die Frist so leicht durchrutscht

Der Grund, warum ausgerechnet die Nicht-Plus-Frist so oft übersehen wird, liegt in der Reihenfolge selbst: 2025 betraf die erste Abschaltung ausschließlich Plus-Shops – größere Konten, häufig mit fester Agentur oder eigenem Entwicklerteam im Hintergrund, das Shopify-Ankündigungen aktiv verfolgt. Alle anderen Shops hatten zu diesem Zeitpunkt schlicht keinen Grund, genauer hinzuschauen; für sie änderte sich nichts. Genau dieses „betrifft mich nicht"-Gefühl aus dem Sommer 2025 überträgt sich ein Jahr später unverändert – nur dass die zweite Frist inzwischen für die eigene Shop-Gruppe gilt und ohne dieselbe mediale Aufmerksamkeit verstrichen ist, mit der die erste Abschaltung 2025 unter Plus-Händlern diskutiert wurde.

Die Grafik direkt im Anschluss zeigt beide Stichtage im Zeitverlauf – und macht sichtbar, warum ein Shop, der die erste Abschaltung 2025 gar nicht mitbekommen musste, weil er kein Plus-Shop war, jetzt trotzdem an der Reihe ist.

Du brauchst für diesen Check keinen Entwickler und keinen Zugriff auf Code – nur deinen Shopify-Adminbereich, eine Testbestellung und zehn Minuten Zeit. Die fünf Punkte unten sind bewusst so sortiert, dass du zuerst die Fragen beantwortest, die am schnellsten gehen, und erst danach die, die etwas mehr Geduld brauchen.

1. Deinen Plan prüfen

Öffne im Adminbereich deine Abo- und Plan-Übersicht. Läuft dein Shop auf Basic, Shopify oder Advanced, gehörst du automatisch zu der Gruppe, für die Script Tags am 26. August 2026 abgeschaltet wurden – unabhängig davon, wie groß dein Shop ist. Nur auf Shopify Plus galt eine andere, bereits 2025 abgelaufene Zeitschiene.

2. Die Bestellstatus-Seite selbst ansehen

Schließe eine kleine Testbestellung ab – notfalls im Anschluss storniert – und öffne die Bestellstatus-Seite in einem privaten Browserfenster. Läuft dort noch ein Chat-Widget, ein Empfehlungs-Banner, ein Treuepunkte-Hinweis oder irgendetwas anderes, das früher sichtbar war und jetzt fehlt? Ein plötzlich leeres Feld an gewohnter Stelle ist meist das erste sichtbare Indiz.

3. Die Entwicklertools bemühen

Öffne auf derselben Bestellstatus-Seite die Entwicklertools deines Browsers und wechsle in den Netzwerk-Tab. Lade die Seite neu und sieh nach, ob die Aufrufe, die du erwarten würdest – an Google, Meta, dein Analytics-Tool – tatsächlich noch feuern. Fehlen sie komplett, ist das ein starkes Signal, dass hier bisher über Script Tags getrackt wurde und dieser Weg jetzt ins Leere läuft.

4. Zahlen gegeneinander halten

Vergleiche die Conversion-Zahlen in Google Ads oder Meta Ads seit Ende August 2026 mit den tatsächlichen Bestellungen in deinem Shopify-Adminbereich im selben Zeitraum. Eine Lücke, die es vorher nicht gab, ist kein Zufall – gerade wenn sie genau um den 26. August herum beginnt.

5. Bei App- und Agentur-Partnern nachfragen

Frag gezielt nach: Wurde irgendeine Tracking-, Personalisierungs- oder Upsell-App über Zusatzskripte auf der Bestellstatus-Seite eingebunden? Wenn ja, lief sie vermutlich über genau den jetzt abgeschalteten Mechanismus – und die Verantwortung, sie zu migrieren, liegt am Ende bei dir als Shop-Betreiber, nicht automatisch beim App-Anbieter.

6. In den eigenen Checkout-Einstellungen nachsehen

Wirf abschließend einen Blick in die Checkout-Einstellungen deines Adminbereichs selbst: Findest du dort noch Einträge, Hinweise oder Verweise auf Zusatzskripte, die als „veraltet" oder „nicht mehr aktiv" markiert sind, ist das eine direkte Bestätigung, dass an dieser Stelle früher etwas lief, das heute nicht mehr greift.

Für keinen dieser sechs Punkte brauchst du länger als ein, zwei Minuten – zusammen ergeben sie ein belastbares Bild, ob und wo bei dir eine Lücke entstanden ist. Wichtig ist nur, sie tatsächlich alle durchzugehen: Ein einzelner unauffälliger Punkt reicht selten, um Klarheit zu schaffen, die Kombination aus mehreren schon.

„Kaputt" ist hier das falsche Bild, wenn man an eine Fehlermeldung denkt – nichts an deinem Checkout zeigt einen Fehler. Treffender ist: Eine ganze Kategorie von Zusatzfunktionen, die bisher über Script Tags auf der Bestellstatus-Seite liefen, verstummt einfach, ohne dass irgendwo ein Alarm losgeht. Vier Bereiche sind in der Praxis am häufigsten betroffen.

Conversion-Tracking

Der größte und teuerste blinde Fleck: Tracking-Pixel für Google Ads, Meta Ads oder ein eigenes Analytics-Setup, die bislang per Script Tag auf der Bestellstatus-Seite ausgelöst wurden, feuern nicht mehr. Deine Kampagnen laufen weiter, dein Budget wird weiter ausgegeben – aber ein Teil der Conversions, die diese Kampagnen tatsächlich erzielen, taucht in deinen Auswertungen nicht mehr auf. Die Optimierung deiner Kampagnen beginnt dann, auf einer unvollständigen Datenbasis zu entscheiden.

Post-Purchase-Upsells und Cross-Selling

Apps, die nach dem Kaufabschluss ein weiteres Angebot einblenden – „Kund:innen, die das gekauft haben, kauften auch" –, nutzten dafür häufig genau diesen Injektionsweg. Fällt er weg, verschwindet ein Umsatzkanal, der in vielen Shops direkt nach der Kaufentscheidung besonders gut konvertiert, weil die Kaufbereitschaft in diesem Moment am höchsten ist.

Treue-, Bewertungs- und Empfehlungshinweise

Punkte-Sammelhinweise, Aufforderungen zu einer Produktbewertung, „Empfiehl uns weiter"-Banner – auch diese kleinen, aber wirksamen Bausteine liefen bei vielen Shops über Zusatzskripte auf der Bestellstatus-Seite und sind seit dem jeweiligen Stichtag ebenso verstummt.

Individuelle Inhalte und Support-Widgets

Chat-Widgets, individuelle Dankestexte, saisonale Hinweise oder Rücksendeinformationen, die über Skripte statt über den offiziellen Checkout-Editor eingebunden wurden, fallen in dieselbe Kategorie. Sie waren nie Teil des eigentlichen Checkouts, sondern eine nachträgliche Ebene darüber – und genau diese Ebene ist jetzt weg.

Warum niemand es sofort merkt

Der eigentliche Grund, warum diese vier Bereiche so lange unbemerkt bleiben, liegt an der Trennung von Zuständigkeiten in den meisten Teams. Wer den Checkout betreut, schaut auf Bestellzahlen und Zahlungsabwicklung – die funktionieren weiter, also gibt es dort keinen Anlass zur Sorge. Wer Kampagnen betreut, schaut auf Klicks, Impressionen und Kosten in der jeweiligen Werbeplattform – die laufen ebenfalls unverändert weiter, nur die Zuordnung zu tatsächlichen Käufen wird lückenhafter. Erst wenn beide Perspektiven zusammengeführt werden – Bestellungen aus Shopify gegen Conversions aus der Werbeplattform –, wird die Lücke überhaupt sichtbar. In vielen Teams passiert dieser Abgleich aber nur unregelmäßig, wodurch sich der stille Datenausfall über Wochen fortsetzen kann, ohne dass jemand aktiv danach sucht.

Wie du diese Lücken technisch sauber schließt – erst für Tracking, dann für Funktionen –, zeigen die beiden folgenden Abschnitte.

Für alles, was mit Tracking und Kundenereignissen zu tun hat, ist die Web Pixels API der von Shopify vorgesehene Nachfolger für Script Tags. Shopify beschreibt sie als kontrollierten Zugriff auf Browser-Funktionen und Kundenereignisse, ausgeführt in isolierten Sandboxen – ein bewusster Unterschied zum alten Modell, in dem ein Script Tag praktisch beliebigen JavaScript-Code ungefiltert ausführen konnte.

Zwei Wege, ein Pixel zu registrieren

Ein App-Pixel läuft in der strengsten Sandbox-Stufe und wird über ein eigenes Shopify-Paket registriert – typischerweise der Weg für Agenturen und App-Anbieter, die eine wiederverwendbare Lösung bauen. Ein Custom Pixel lässt sich dagegen direkt im Adminbereich konfigurieren, mit vereinfachter Syntax und ohne zusätzliches Entwickler-Tooling – für ein einzelnes Tracking-Pixel oft der schnellere Weg, auch wenn die Einrichtung weiterhin technisches Verständnis braucht.

Was ein Pixel sehen darf

Beide Pixel-Typen erhalten Zugriff auf standardisierte Kundenereignisse – etwa wenn eine Seite aufgerufen wird, ein Produkt angesehen wird oder ein Kunde im Checkout einen Schritt weiterkommt – sowie auf selbst definierbare eigene Ereignisse. Ergänzend liefert die Schnittstelle einen Zustands-Schnappschuss beim Laden der Seite und kontrollierten Zugriff auf Cookies und Speicher im Browser, statt der früher üblichen freien Hand.

Die Consent-Falle, die niemand erwartet

Der wichtigste Unterschied zum alten Modell betrifft die Einwilligung: Shopifys Pixel-Manager lädt ein Pixel laut eigener Dokumentation nur dann, wenn für alle vom Pixel als erforderlich deklarierten Einwilligungskategorien – etwa Analyse- oder Marketing-Zwecke – tatsächlich eine Zustimmung der besuchenden Person vorliegt. Praktisch heißt das: Selbst ein technisch korrekt eingerichtetes Pixel bleibt stumm, wenn dein Cookie-Banner die passende Einwilligung nicht sauber einholt oder weiterreicht. Ein fehlendes Tracking-Signal ist danach nicht zwingend ein Migrationsfehler – es kann ebenso gut ein Zeichen sein, dass das System genau so arbeitet, wie es soll.

Wie du prüfst, ob dein Pixel überhaupt feuert

Der ehrlichste Test läuft nicht über eine Konfigurationsseite im Adminbereich, sondern über eine echte Testbestellung mit geöffnetem Netzwerk-Tab, wie schon in Abschnitt 02 beschrieben: Erst wenn dort tatsächlich Aufrufe an die erwartete Zielplattform sichtbar werden, ist das Pixel wirksam eingerichtet. Bleiben die Aufrufe aus, obwohl das Pixel im Adminbereich als aktiv angezeigt wird, liegt die Ursache in aller Regel entweder an den erforderlichen Consent-Kategorien, die nicht erfüllt werden, oder an einem Fehler in der Pixel-Konfiguration selbst – beides lässt sich nur durch diesen praktischen Test unterscheiden, nicht durch einen Blick auf den Aktivierungsstatus allein.

Was die Web Pixels API für Tracking ist, sind Checkout-UI-Extensions für alles, was der Checkout sichtbar oder funktional zusätzlich tun soll. Shopify beschreibt das Prinzip unmissverständlich: Um den Checkout um neue Funktionalität zu erweitern, baut man eine App mit Extensions – nicht mehr, wie früher, eine Liquid-Datei direkt an.

Vier Bausteine, ein System

Konkret unterscheidet Shopify vier Typen von Extension-Points: UI-Extensions für alles, was im Checkout sichtbar wird – Felder, Banner, Hinweise; Functions für serverseitige Geschäftslogik, etwa individuelle Rabattregeln; Web-Pixel-Extensions für Tracking, wie in Abschnitt 04 beschrieben; und Payment-Extensions für zusätzliche Zahlungsoptionen. Alle vier greifen ineinander, statt – wie früher bei checkout.liquid – in einer einzigen, unübersichtlichen Datei nebeneinanderzustehen.

Was sich damit konkret bauen lässt

Laut Shopifys eigener Dokumentation reicht das Einsatzspektrum von Rabatten und Sonderangeboten über Pre- und Post-Purchase-Angebote bis zu individuellen Feldern, Bannern, Adress-Autovervollständigung und angepassten Dankes- sowie Bestellstatus-Seiten. Technisch bauen die UI-Extensions auf Shopifys eigenem Polaris-Designsystem auf und laufen, ebenso wie die Pixel, in einer eigenen Sandbox – Änderungen an Warenkorb-Attributen oder Metafeldern laufen über klar definierte Funktionsaufrufe statt über freien Zugriff auf die Seite. Für viele der Funktionen, die vorher per Script Tag auf der Bestellstatus-Seite liefen – Bewertungs-Hinweise, Treuepunkte-Anzeigen, kleine Cross-Selling-Banner –, ist genau dieses Einsatzspektrum die direkte, offizielle Entsprechung.

Der Unterschied zur alten Arbeitsweise

Wer früher checkout.liquid direkt bearbeitet hat, hat im Grunde eine eigene Kopie der gesamten Checkout-Seite verwaltet – mit dem Risiko, bei jedem neuen Shopify-Checkout-Feature selbst nachziehen zu müssen. Extensions docken sich dagegen an definierten Stellen in Shopifys eigenen, laufend aktualisierten Checkout an. Ein neues Zahlungsverfahren wie Shop Pay oder eine neue Sicherheitsfunktion kommt dadurch automatisch bei allen Extensions an, ohne dass jemand die eigene Implementierung händisch nachpflegen muss.

Ein Beispiel, das den Unterschied greifbar macht

Nimm eine Funktion wie „Bestellhinweis für den Zusteller hinterlassen" – ein zusätzliches Textfeld, das früher händisch in checkout.liquid ergänzt wurde. Als Checkout-UI-Extension gebaut, erscheint dasselbe Feld an einer klar definierten Stelle im Checkout, der eingegebene Text landet über eine kontrollierte Funktion als Attribut an der Bestellung – sichtbar für dich im Adminbereich, ohne dass irgendwo eine Kopie der Checkout-Seite gepflegt werden muss. Ändert Shopify später das Layout der Checkout-Seite selbst, bleibt das Feld an seiner Extension-Position einfach bestehen, statt bei der nächsten Shopify-Aktualisierung zu verschwinden oder zu verrutschen.

An dieser Stelle lohnt sich Ehrlichkeit, weil sie viele Missverständnisse in Beratungsgesprächen vorwegnimmt: Nicht jede Checkout-Anpassung steht jedem Shop offen, und der Plan, auf dem du läufst, entscheidet direkt darüber, wie weit du gehen kannst.

Was jeder Plan kann

Unabhängig davon, ob du auf Basic, Shopify oder Advanced läufst, hast du Zugriff auf den Checkout- und Konten-Editor mit grundlegendem Branding – Logo, Hintergrundfarben und -bilder, Schriftanpassungen. Ebenso stehen dir Apps offen, die speziell für die Dankes- und Bestellstatus-Seite gebaut sind: Shopify listet diese ausdrücklich als für alle Pläne zugängliche Kategorie. Für die in diesem Text im Zentrum stehende Aufgabe – Tracking und Post-Purchase-Funktionen auf der Bestellstatus-Seite wiederherzustellen – reicht dieser Zugriff in aller Regel vollständig aus, ganz gleich auf welchem Standard-Plan dein Shop läuft.

Was Shopify Plus vorbehalten ist

Zwei Dinge bleiben nach unserer Recherche Plus-exklusiv. Erstens der tiefere Eingriff in die eigentlichen Kaufabschluss-Schritte: Laut Shopifys eigener Dokumentation sind Checkout-UI-Extensions für die Schritte Information, Versand und Zahlung „available only to stores on a Shopify Plus plan" – ausschließlich Plus-Shops können hier also eigene Apps und Extensions andocken. Zweitens die Checkout-Branding-API für weitergehende, über das Standard-Branding hinausgehende visuelle Anpassungen, die ebenfalls Plus vorbehalten ist.

Was das für deine Entscheidung bedeutet

Bist du kein Plus-Shop, heißt das nicht, dass dir die Migration verwehrt ist – die in Abschnitt 04 beschriebene Web-Pixels-API und Apps für die Bestellstatus-Seite stehen dir vollständig offen. Was dir fehlt, ist die Möglichkeit, eigene Funktionen mitten in den Kaufabschluss selbst – vor der Bestellbestätigung – einzubauen. Für die reine Wiederherstellung von Tracking und Post-Purchase-Funktionen auf der Bestellstatus-Seite, um die es in diesem Text in erster Linie geht, ist das in aller Regel kein Hindernis.

Der Unterschied zwischen „verfügbar" und „für jede App verfügbar"

Eine Feinheit lohnt sich, bevor du dich auf eine bestimmte App verlässt: Shopify spricht bei der Thank-you- und Order-Status-Seite ausdrücklich von „eligible apps" – also Apps, die die Anforderungen für diese Kategorie erfüllen, nicht automatisch jede beliebige App im Store. Ob eine konkrete App, die du im Blick hast, tatsächlich zu dieser Kategorie zählt, klärst du am zuverlässigsten direkt mit dem Anbieter, nicht über eine allgemeine Plan-Regel.

Die Reihenfolge entscheidet hier über den Aufwand. Wer sofort versucht, jede alte Funktion eins zu eins nachzubauen, verliert Zeit an Dingen, die es vielleicht gar nicht mehr braucht. Vier Schritte haben sich in der Praxis bewährt.

1. Bestandsaufnahme

Bevor irgendetwas neu gebaut wird, steht die Frage: Was lief bisher überhaupt über Script Tags oder checkout.liquid auf der Bestellstatus-Seite? Der Selbsttest aus Abschnitt 02 liefert dafür die Rohdaten – ergänzt um ein Gespräch mit jeder App, die im Verdacht steht, dort mitgemischt zu haben. Am Ende dieses Schritts steht eine konkrete Liste statt eines vagen Gefühls: Welche Funktion lief wo, wer hat sie ursprünglich eingerichtet, und ist sie überhaupt noch geschäftlich relevant – manche Altlasten stellen sich bei genauerem Hinsehen als längst überflüssig heraus und müssen gar nicht erst nachgebaut werden.

2. Tracking zuerst, über Web Pixels

Tracking hat Priorität, weil jeder verstrichene Tag verlorene Daten bedeutet, die sich später nicht rückwirkend heilen lassen. Ob App-Pixel oder Custom Pixel die passende Wahl ist, hängt davon ab, ob eine wiederverwendbare Lösung für mehrere Shops entstehen soll oder ein einzelnes, shop-spezifisches Tracking-Pixel genügt – Details dazu in Abschnitt 04.

3. Funktionen über Checkout-UI-Extensions

Erst danach folgen die sichtbaren und funktionalen Bausteine – Upsell-Angebote, individuelle Banner, Treuehinweise –, jetzt als eigene Extensions statt als Skript-Injektion. Ob das auf der Bestellstatus-Seite bleibt oder, bei einem Plus-Shop, auch in die Schritte davor wandert, entscheidet sich anhand der Plan-Frage aus Abschnitt 06.

4. Mit einer echten Bestellung testen, dann aufräumen

Am Ende steht ein Test, der über die Admin-Vorschau hinausgeht: eine tatsächliche Testbestellung, durchlaufen wie eine echte Kundin es tun würde, mit Blick auf Netzwerk-Tab und sichtbares Ergebnis. Erst wenn dieser Test sauber durchläuft, werden die alten, längst wirkungslosen Zusatzskripte endgültig entfernt – sie liegenzulassen bringt keinen Vorteil, macht die Fehlersuche beim nächsten Problem aber unnötig kompliziert.

Wer welchen Schritt übernimmt

Nicht jeder dieser vier Schritte braucht dieselbe Kompetenz. Die Bestandsaufnahme aus Schritt 1 kannst du als Betreiber:in größtenteils selbst leisten, gestützt auf den Selbsttest aus Abschnitt 02. Die Einrichtung eines einzelnen Custom Pixels in Schritt 2 ist für technisch versierte Teams oft noch machbar. Spätestens bei eigenen Checkout-UI-Extensions in Schritt 3 braucht es Entwicklungskompetenz – wo genau diese Grenze in deinem konkreten Fall verläuft, ordnet Abschnitt 10 noch einmal ein.

Die Grafik im Anschluss fasst diese vier Schritte noch einmal als Pfad zusammen.

Fünf Fehler begegnen uns in Migrationsgesprächen immer wieder – jeder für sich unauffällig, in Summe aber genau der Grund, warum Shops Monate nach der eigentlichen Migration noch immer mit Datenlücken kämpfen.

Consent-Kategorien nicht sauber gesetzt

Wie in Abschnitt 04 beschrieben, lädt Shopify ein Pixel nur, wenn die passende Einwilligung tatsächlich vorliegt. Wird bei der Einrichtung eine falsche oder zu eng gefasste Kategorie hinterlegt, bleibt das Pixel bei einem Teil der Besucher:innen stumm – technisch korrekt eingerichtet, aber praktisch wirkungslos, ohne dass eine Fehlermeldung darauf hinweist.

Darauf vertrauen, dass eine App „das schon regelt"

Nicht jede installierte App hat ihre eigene Migration bereits abgeschlossen, nur weil sie weiterhin im App-Store gelistet ist. Wer nicht aktiv nachfragt, ob eine bestimmte Tracking- oder Upsell-App inzwischen auf Web Pixels beziehungsweise Checkout-Extensions umgestellt hat, verlässt sich auf eine Annahme, die sich beim eigenen Shop als falsch herausstellen kann.

Nur in der Admin-Vorschau statt mit einer echten Bestellung testen

Die Vorschau im Adminbereich zeigt oft nicht dieselben Bedingungen wie eine echte Bestellung im Browser einer Kundin – etwa unterschiedliche Consent-Zustände oder Caching-Effekte. Ein Test gilt erst dann als abgeschlossen, wenn eine tatsächliche Bestellung, in einem echten Browser, mit Blick auf die Netzwerk-Aufrufe durchlaufen wurde.

Plus-exklusive Funktionen ohne Plus-Plan versuchen

Gerade wenn ein Team oder eine Agentur mit Plus-Projekten Erfahrung hat, passiert es, dass eine Lösung geplant wird, die technisch nur auf Plus funktioniert – bis der eigene Plan das schlicht nicht hergibt. Die Prüfung aus Abschnitt 06 gehört deshalb an den Anfang der Planung, nicht ans Ende – nachträglich umzuplanen kostet in der Praxis mehr Zeit, als die Plan-Frage vorab einmal sauber zu klären.

Die Migration einmalig durchführen und dann vergessen

Eine funktionierende Migration ist kein abgeschlossenes Projekt, sondern ein neuer Zustand, der weiterbeobachtet werden muss. Ändert sich später der Cookie-Banner, kommt eine neue Tracking-Plattform hinzu oder wechselt eine App ihren Anbieter, kann genau dieselbe stille Lücke erneut entstehen – nur dass dann niemand mehr aktiv nach einer Abschaltungsfrist sucht, die es augenscheinlich schon gegeben hat. Ein kurzer Blick in den Netzwerk-Tab der Bestellstatus-Seite gehört deshalb nach jeder größeren Änderung am Checkout oder an den eingesetzten Apps dazu, nicht nur einmal direkt nach der Migration.

Die Abschaltung von Script Tags trifft nicht nur individuell programmierte Lösungen, sondern auch einen Teil des Shopify-App-Ökosystems selbst – und zwar früher, als vielen bewusst ist.

Der breitere Kontext: Script Tags als Ganzes

Unabhängig von den checkout-spezifischen Terminen aus Abschnitt 01 gilt für die Script-Tag-Technik generell: Seit dem 1. April 2025 müssen neue öffentliche Apps im Shopify-App-Store laut Shopify ausschließlich mit der GraphQL-Admin-API entwickelt werden. Für Apps, die sich in ein Theme integrieren und im App-Store gelistet sein wollen, gilt zusätzlich: Sie müssen Theme-App-Extensions statt Script Tags verwenden. Script Tags bleiben in diesem breiteren Sinn nur noch für sogenannte „vintage themes" verfügbar – ein auslaufendes Modell, kein Fundament für neue Projekte.

Was das für installierte Apps in deinem Shop bedeutet

Für dich als Betreiber heißt das: Jede App, die Funktionen auf deiner Bestellstatus-Seite oder im Checkout bereitstellt – Reviews, Upsells, Personalisierung, Treueprogramme –, hat diesen Umbau ebenfalls vor sich, unabhängig von deinem eigenen Plan. Seriöse Anbieter haben ihre Apps längst auf Web-Pixel-Extensions und Checkout-UI-Extensions umgestellt; andere, kleinere oder nicht mehr aktiv gepflegte Apps womöglich nicht. Gerade bei Nischen-Apps mit kleinem Anbieter-Team lohnt sich ein zweiter Blick, weil dort die Migration seltener mit derselben Priorität behandelt wird wie bei den großen, breit genutzten App-Store-Einträgen.

Die Frage, die du jeder Checkout-App stellen solltest

Bevor du eine bestehende Funktion verlierst oder Geld für eine App ausgibst, die schon in wenigen Monaten wieder migriert werden muss, lohnt sich eine einzige, direkte Frage an den Anbieter: „Läuft eure Integration über Checkout-Extensions und Web Pixels, oder noch über Script Tags?" Anbieter, die diese Frage nicht klar beantworten können, stecken selbst noch mitten in derselben Umstellung, die dieser Text für deinen eigenen Shop beschreibt.

Woran du eine bereits migrierte App erkennst

Ein indirekter, aber praktischer Hinweis: Apps, die ihre Integration bereits umgestellt haben, verweisen in ihrer eigenen Dokumentation oder ihren Update-Hinweisen in aller Regel explizit auf Checkout-Extensions, Web-Pixel-Extensions oder die Shopify-Extension-Technologien – Begriffe, die es vor der Umstellung so nicht gab. Findest du in der Beschreibung einer installierten App ausschließlich ältere Formulierungen rund um Script Tags oder checkout.liquid, ist das ein Grund, gezielt nachzufragen, statt automatisch von einer bereits abgeschlossenen Migration auszugehen.

Der Selbsttest aus Abschnitt 02 schaffst du allein, in zehn Minuten, ohne eine Zeile Code zu sehen. Das Registrieren eines Custom Pixels im Adminbereich für ein einzelnes, unkompliziertes Tracking-Signal liegt für viele Betreiber:innen mit etwas technischem Grundverständnis ebenfalls noch im machbaren Bereich. Ab hier verschiebt sich die Rechnung.

Ein App-Pixel mit dem offiziellen Shopify-Paket zu registrieren, eine Checkout-UI-Extension zu bauen und über die Shopify-CLI auszuliefern, oder eine Function für individuelle Rabattlogik zu schreiben, verlangt Entwicklungsumgebung, Versionierung und ein Verständnis der Extension-Points aus Abschnitt 05 – das ist reguläre Softwareentwicklung, kein Konfigurationsklick im Adminbereich. Wer hier ohne Erfahrung selbst Hand anlegt, riskiert am ehesten genau die Fallstricke aus Abschnitt 08: technisch halb fertige Lösungen, die erst Monate später als Datenlücke auffallen.

Ob dein Shop dabei auf einem klassischen Theme oder auf einer Hydrogen-Storefront läuft, ändert an dieser Aufgabe grundsätzlich nichts – der Checkout selbst bleibt, wie unser Vergleich der beiden Shopify-Architekturen zeigt, in beiden Fällen vollständig bei Shopify und damit von derselben Umstellung betroffen.

Auch die Größe deines Shops verschiebt diese Grenze kaum. Ein kleiner Shop mit einem einzelnen Tracking-Pixel braucht am Ende dieselbe saubere Einrichtung wie ein großer – nur dass der Aufwand dafür überschaubarer bleibt, wenn tatsächlich nur eine einzelne Funktion betroffen ist. Umgekehrt wächst der Entwicklungsaufwand nicht automatisch mit dem Umsatz, sondern mit der Zahl der Funktionen, die früher über Script Tags liefen: Ein Shop mit fünf verschiedenen Zusatzskripten hat schlicht mehr zu migrieren als einer mit einem einzigen Tracking-Pixel, unabhängig davon, wie viele Bestellungen er täglich abwickelt.

Wenn du beim Selbsttest aus Abschnitt 02 tatsächlich eine Lücke gefunden hast, ist der nächste sinnvolle Schritt kein Großprojekt: Eine kurze, ehrliche Bestandsaufnahme reicht meist, um zu sehen, ob ein einzelnes Custom Pixel genügt oder ob mehrere Extensions gebaut werden müssen. Genau diesen Übergang übernehmen wir bei EINSHOCH im Rahmen unserer laufenden Shopify-Entwicklung – von der ersten Bestandsaufnahme bis zur fertig ausgelieferten Extension.