Shopify Hydrogen oder Online Store 2.0?

Irgendwo hast du den Begriff „Hydrogen" aufgeschnappt – in einem Shopify-Webinar, von einer Agentur, in einem Artikel über „Headless Commerce". Die naheliegende Frage danach: Brauchst du das auch? Die ehrliche Antwort beginnt mit einer Klarstellung, die in den meisten Erklärungen fehlt: Ganz gleich, für welchen Weg du dich entscheidest, dein Shopify-Shop bleibt im Kern derselbe. Produkte, Lagerbestand, Bestellungen, Zahlungsabwicklung und der Checkout selbst laufen weiterhin über dasselbe Shopify-Backend, mit demselben Adminbereich, in dem dein Team heute schon arbeitet.

Was sich unterscheidet, ist ausschließlich die Storefront-Schicht – also das, was ein Besucher tatsächlich im Browser sieht und anklickt. Bei Online Store 2.0, der Standard-Architektur, für die praktisch jedes moderne Shopify-Theme heute gebaut ist, übernimmt Shopify selbst das Rendern dieser Storefront: ein Theme aus dem Theme-Store oder eines, das eine Agentur für dich gebaut hat, mit Abschnitten, die du im Theme-Editor per Drag-and-drop anordnest. Bei Hydrogen baust du – beziehungsweise dein Entwicklerteam – diese Storefront dagegen komplett selbst, als eigene React-Anwendung, die sich die Produktdaten nur noch über eine Schnittstelle bei Shopify abholt. Zwei fundamental unterschiedliche Bauweisen, ein gemeinsames Fundament darunter.

Für wen ist dieser Text gedacht? Für dich als Shop-Betreiber oder Entscheider, der wissen will, ob „Headless" oder „Hydrogen" für den eigenen Shop überhaupt relevant ist, was es kostet, wer es bauen und pflegen kann – und was in beiden Fällen unverändert bleibt. Suchst du dagegen eine technische Schritt-für-Schritt-Anleitung zum Aufsetzen eines Hydrogen-Projekts, ist die offizielle Shopify-Entwicklerdokumentation die richtige Adresse, nicht dieser Leitfaden.

Kern-Unterscheidung vorab, direkt und ohne Fachjargon: Die Frage ist nicht, ob du Entwickler brauchst, sondern wer an deiner Seite steht. Online Store 2.0 ist der richtige Weg, wenn du ohne eigenes Entwicklerteam oder Agentur-Partner arbeitest und der Standard-Rahmen eines Themes reicht – Kaufstrecke, Design und Funktionen kommen dann aus einem Theme, das Shopify selbst betreibt und aktualisiert. Hydrogen ist der Weg, den wir als Agentur, die beide Architekturen selbst baut, für viele Kundenprojekte bewusst wählen, sobald ein Team oder Partner mit React-Kompetenz an Bord ist: ein freies Frontend statt Template-Korsett.

Die folgenden Abschnitte gehen beide Wege im Detail durch – aus unserer eigenen Projektpraxis heraus, in der wir beide Architekturen bauen: was Online Store 2.0 heute tatsächlich kann, was Hydrogen technisch bedeutet, wo die Unterschiede in der Praxis zählen – und vor allem, wann welcher Weg der richtige für deinen Shop ist.

Online Store 2.0 ist die technische Grundlage, auf der praktisch jedes aktuelle Shopify-Theme aufgebaut ist – ein kostenloses Theme aus dem Theme-Store ebenso wie ein individuell für dich entwickeltes. Der Name stammt aus der Umstellung, mit der Shopify die alte, rein Liquid-basierte Theme-Generation abgelöst hat. In Shopifys aktueller Entwicklerdokumentation taucht die Bezeichnung „Online Store 2.0"-Theme nach wie vor auf – etwa im Zusammenhang mit App-Blocks –, während Shopifys Merchant-Hilfeseiten die Funktionen heute meist einfach als das beschreiben, was ein modernes Theme kann, ohne die Versionsnummer eigens zu betonen. Für dich als Betreiber ändert das nichts an der Funktion, nur daran, wie oft du die Zahl „2.0" noch explizit liest.

Drei Bausteine machen den praktischen Unterschied zur alten Theme-Generation aus.

Sections everywhere

Früher waren die anpassbaren Abschnitte eines Themes auf die Startseite beschränkt, jede andere Seite war starrer Liquid-Code. Heute besteht laut Shopifys eigener Architektur-Dokumentation jede Seite – Produktseite, Kollektionsseite, Über-uns-Seite – aus denselben flexiblen Abschnitten, die du im Theme-Editor per Drag-and-drop verschiebst, ein- und ausblendest, ohne eine Zeile Code anzufassen.

JSON-Templates

Jede Seitenvorlage ist als JSON-Datei hinterlegt, die im Kern nur eine Liste der verwendeten Abschnitte ist – Shopify beschreibt es so: JSON-Templates dienen ausschließlich als Hülle für Abschnitte, während der eigentliche Code in den Abschnitten selbst steckt. Praktisch heißt das: Du kannst eine komplett neue Seitenvariante, etwa eine besondere Kampagnen-Landingpage, erstellen, indem du bestehende Abschnitte neu kombinierst, statt neuen Code zu brauchen.

App-Blocks

Viele Shopify-Apps – Produktbewertungen, Cross-Selling-Widgets, Größentabellen – bringen heute eigene App-Blocks mit, die du direkt als Baustein in einen Abschnitt hineinziehst, exakt an die Stelle, an der er erscheinen soll. Laut Shopify ist genau das der Sinn dieser Technik: Händler sollen ihren Theme-Code nicht manuell bearbeiten müssen, um App-Funktionen präzise zu platzieren.

Was du damit ohne Agentur änderst, an einem konkreten Beispiel: Du willst auf deiner Startseite unter dem Hero-Bild ein Bewertungs-Widget einer neu installierten App einfügen, dahinter eine Bestseller-Kollektion und ganz unten ein Newsletter-Formular – alles ohne einen Entwickler zu brauchen, weil jeder dieser drei Bausteine ein Abschnitt oder App-Block ist, den du im Theme-Editor per Drag-and-drop an die gewünschte Stelle ziehst.

Ergänzend erlauben Metafelder strukturierte Zusatzinformationen pro Produkt – etwa Materialangaben, Pflegehinweise oder technische Daten –, die sich im Theme gezielt an der richtigen Stelle ausgeben lassen, ohne dass jedes einzelne Feld hart in den Theme-Code programmiert werden muss.

Dawn als Referenz, nicht als Pflicht

Wie ernst Shopify diese Architektur nimmt, zeigt sich am eigenen Referenz-Theme Dawn: Shopify beschreibt es selbst als sein „erstes quelloffen verfügbares Theme mit Performance, Flexibilität und Online-Store-2.0-Funktionen von Grund auf eingebaut", gedacht als Vorlage für die eigene Theme-Entwicklung. Du musst Dawn nicht selbst verwenden – die allermeisten Shops laufen auf einem gekauften oder individuell gestalteten Theme –, aber die Existenz eines solchen offiziellen Referenz-Themes zeigt, dass Sections, JSON-Templates und App-Blocks kein Nischen-Feature sind, sondern die Basis, auf die Shopify selbst seine gesamte Theme-Landschaft ausrichtet.

Hydrogen ist Shopifys eigener Baukasten für den entgegengesetzten Weg: Statt eines fertigen Themes bekommt dein Entwicklerteam ein Gerüst, mit dem es eine komplett eigenständige Storefront-Anwendung baut. Shopify selbst beschreibt Hydrogen offiziell als „opinionated stack for headless commerce, built on React Router" – auf Deutsch: ein Technologie-Baukasten mit klaren Vorgaben, auf Basis des JavaScript-Frameworks React Router. Wer sich noch an die Bezeichnung „React und Remix" erinnert: Remix ist inzwischen technisch in React Router aufgegangen, weshalb die aktuelle Shopify-Dokumentation heute React Router als Grundlage nennt – inhaltlich bleibt es dieselbe Idee aus komponentenbasiertem React-Code mit serverseitigem Rendering.

Übersetzt in Betreiber-Sprache: Dein Frontend – alles, was ein Besucher sieht und anklickt – ist nicht länger ein Shopify-Theme, sondern eine eigenständige Software-Anwendung, die dein Entwicklerteam wie jede andere Web-Applikation baut, versioniert und weiterentwickelt. Diese Anwendung nutzt Shopify nur noch als das, was im Hintergrund tatsächlich zählt: eine Daten- und Kaufmaschine. Produktkatalog, Lagerbestände, Preise, Kundenkonten und der Bestellabschluss laufen weiterhin vollständig über Shopify – deine Hydrogen-Anwendung holt sich diese Informationen aber aktiv über eine Programmierschnittstelle ab, statt dass Shopify sie dir fertig in ein Theme rendert.

Storefront-API und Customer-Account-API

Diese Schnittstelle heißt Storefront-API und ist laut Shopifys Dokumentation die zentrale Verbindung zwischen einer Hydrogen-Anwendung und deinem Shop-Backend: Sie liefert Produktdaten, Preise, Warenkorb-Funktionen und mehr in einem strukturierten Format, das die eigene Anwendung dann selbst zu Seiten zusammenbaut. Für Kundenkonten kommt ergänzend die Customer-Account-API zum Einsatz. Praktisch für den Projektstart: Shopify stellt eine eigene Hydrogen-Kommandozeilen-Anwendung bereit, mit der ein Entwicklerteam ein neues Projekt aufsetzt, lokal gegen deinen echten Shop-Katalog entwickelt und anschließend direkt zum Deployment verbindet – der Bau selbst beginnt also nicht bei einer leeren Codebasis ohne jede Shopify-Anbindung, sondern mit einem vorbereiteten Grundgerüst.

Oxygen: Hosting speziell für Hydrogen

Wo läuft dieses selbstgebaute Frontend dann? Hier kommt Oxygen ins Spiel – laut Shopify „Shopify's global edge hosting platform", also eine eigene, weltweit verteilte Hosting-Infrastruktur speziell für Hydrogen-Anwendungen, erreichbar über den sogenannten Hydrogen-Vertriebskanal im Shopify-Adminbereich. Wichtig für die Kostenfrage, soweit unsere Recherche in offiziellen Quellen zeigt: Der Zugang zu Headless-Storefronts ist heute Teil der regulären Shopify-Pläne – mit Basic, Grow und Advanced steht dir laut Shopifys eigener Preisseite jeweils ein Headless-Storefront zu, mit Plus sogar 25 gleichzeitig, ganz ohne separate Zusatzbuchung. Eine gesonderte Preisliste für Oxygen selbst weist Shopify öffentlich nicht aus; wer exakte Kosten für sein Projekt braucht, sollte das direkt mit Shopify oder einem Partner klären, statt sich auf kursierende Pauschalzahlen zu verlassen. Alternativ lässt sich eine Hydrogen-Anwendung laut Shopify auch unabhängig von Oxygen betreiben, etwa auf einer anderen Hosting-Plattform, über den separaten „Headless"-Vertriebskanal.

Der Direktvergleich lohnt sich entlang der Kriterien, die in der Praxis tatsächlich über die Entscheidung entscheiden – nicht entlang technischer Buzzwords.

Team

Ein Online-Store-2.0-Theme kannst du mit deinem bestehenden Marketing- oder E-Commerce-Team pflegen, ergänzt durch punktuelle Unterstützung einer Agentur für tiefere Anpassungen. Eine Hydrogen-Anwendung braucht dauerhaft mindestens ein Frontend-Entwicklerteam mit React-Kenntnissen – nicht nur für den Bau, sondern auch für den laufenden Betrieb, denn Abhängigkeiten, Sicherheitsupdates und Browser-Kompatibilität verwalten sich bei einer eigenen Anwendung nicht von selbst.

Startzeit

Ein Theme-basierter Shop lässt sich mit einem passenden Theme aus dem Theme-Store binnen Tagen bis weniger Wochen live schalten, auch mit individuellen Anpassungen meist innerhalb weniger Monate. Eine Hydrogen-Storefront beginnt bei null: Jede Seite, jede Komponente, jedes Interaktionsdetail, das ein Theme bereits mitbringt, muss im Projekt erst gebaut werden – realistisch ein Projekt von mehreren Monaten, nicht Wochen.

Freiheitsgrade

Hier dreht sich das Bild um: Ein Theme gibt dir innerhalb seiner Architektur sehr viel Gestaltungsspielraum, bleibt aber an das gebunden, was Abschnitte, Liquid und die Theme-Engine grundsätzlich hergeben. Eine Hydrogen-Anwendung ist letztlich normaler React-Code – jede Interaktion, jedes Layout, jede Logik, die sich in einer Web-Anwendung irgendwie umsetzen lässt, ist grundsätzlich möglich, begrenzt nur durch Entwicklungszeit und Budget.

Pflege

Ein Theme erhält Updates von seinem Entwickler oder aus dem Theme-Store, Sicherheits- und Kompatibilitätsfragen liegen größtenteils bei Shopify und dem Theme-Anbieter. Bei Hydrogen trägt dein Team die volle Verantwortung für Deployments, Abhängigkeits-Updates und das Beheben von Fehlern, die nach einem Update irgendwo in der eigenen Codebasis auftauchen – ein laufender technischer Betrieb wie bei jeder eigenen Software. Shopify koppelt Hydrogen-Versionen zudem an die vierteljährlichen Storefront-API-Versionen; dein Team muss diese Kompatibilität aktiv im Blick behalten, während ein Theme diese Anbindung intern verwaltet, ohne dass du dich als Betreiber je damit befasst.

Apps und Ecosystem

Der Theme-Store und der App-Store sind für Online Store 2.0 aufeinander abgestimmt: Die allermeisten Apps rendern per App-Block direkt ins Theme, ohne Zusatzaufwand. Bei Hydrogen ist das nicht automatisch der Fall – viele Apps sind für das klassische Theme-Rendering gebaut und müssen für eine headless Storefront erst über die Storefront-API neu angebunden oder in eigenem Code nachgebaut werden.

Vorschau- und Editor-Erlebnis für Redakteure

Im Theme-Editor sieht dein Marketing-Team Änderungen sofort in einer Live-Vorschau und kann Texte, Bilder und Reihenfolgen selbst anpassen. Bei einer Hydrogen-Anwendung gibt es keinen vergleichbaren visuellen Editor von Hause aus – Inhaltsänderungen laufen entweder über ein separat angebundenes Content-System oder über eine neue Code-Änderung durch das Entwicklerteam, je nachdem, wie die Anwendung aufgebaut wurde.

Die Grafik direkt im Anschluss fasst diese sechs Kriterien noch einmal nebeneinander zusammen.

Die Begriffe rund um Shopify-Architektur werden in Gesprächen und Suchanfragen munter durcheinandergeworfen. Zeit, sie einmal sauber zu trennen.

Von 1.0 zu 2.0

Vor der Umstellung auf Online Store 2.0 bestand ein Shopify-Theme aus starrem Liquid-Code, individuelle Anpassungen über die Startseite hinaus erforderten fast immer einen Entwickler. Mit Online Store 2.0 kamen Abschnitte auf jeder Seite, JSON-Templates und App-Blocks hinzu – im Kern die Funktionen aus Abschnitt 02 dieses Leitfadens. Diese Umstellung liegt inzwischen einige Jahre zurück; praktisch jedes aktuelle Theme aus dem Theme-Store ist heute auf dieser Architektur aufgebaut.

Gibt es ein „3.0"?

Nein – jedenfalls nicht als offiziell benannte, nächste Theme-Generation. Unsere Recherche in Shopifys eigener Entwickler- und Merchant-Dokumentation sowie in öffentlich zugänglichen Quellen findet keinen Hinweis auf eine „Online Store 3.0" oder „Shopify 3.0" getaufte Architektur. Woher die Suche danach trotzdem kommt, lässt sich nur einordnen, nicht abschließend belegen: Shopify veröffentlicht regelmäßig große, jeweils eigens benannte Produkt-Updates unter dem Namen „Shopify Editions" – eine Flut neuer Funktionen und Namen, aus der leicht der Eindruck einer neuen „Versionsnummer" entstehen kann, obwohl keine dieser Editions die Theme-Architektur selbst neu nummeriert. Wer „3.0" sucht, meint in aller Regel entweder Hydrogen als „das, was nach 2.0 kommt", oder schlicht: „Was ist gerade aktuell bei Shopify?" – beides beantwortet dieser Leitfaden, ohne dass du dabei ein „3.0" abwarten musst, das nicht existiert.

Headless ist nicht gleich Hydrogen

„Headless Commerce" ist der allgemeine Fachbegriff dafür, Frontend und Backend eines Shops voneinander zu trennen – theoretisch mit jedem beliebigen Technologie-Stack umsetzbar, der sich über eine Programmierschnittstelle mit Shopify verbindet. Hydrogen ist Shopifys eigener, offiziell unterstützter Weg dorthin, aber nicht der einzig denkbare. Manche Unternehmen bauen headless Storefronts auch mit anderen Frontend-Technologien direkt gegen die Storefront-API, ohne Hydrogen als Baukasten zu nutzen. Für die meisten Shopify-Shops, die headless in Betracht ziehen, ist Hydrogen trotzdem der naheliegende Einstieg, weil es von Shopify selbst gepflegt wird und eng mit Oxygen sowie der Storefront-API zusammenspielt.

Hydrogen heißt nicht „weg von Shopify"

Ein verbreitetes Missverständnis: Wer Hydrogen nutzt, verlässt Shopify nicht – im Gegenteil. Produktverwaltung, Bestellungen, Zahlungsabwicklung und Checkout bleiben, wie in Abschnitt 01 beschrieben, vollständig im Shopify-Backend. Hydrogen ersetzt ausschließlich die Storefront-Schicht, nicht den Shop dahinter.

Für die überwältigende Mehrheit der Shopify-Shops ist Online Store 2.0 nicht die zweitbeste, sondern schlicht die richtige Wahl – das ist auch unsere Grundhaltung als Agentur, die beide Wege baut und beide ehrlich einschätzen kann, nicht nur den lukrativeren. Vier Kriterien helfen bei der Selbsteinschätzung.

Deine Kaufstrecke ist im Kern Standard

Produktseite, Warenkorb, Checkout, Bestellbestätigung – läuft dein Verkaufsprozess entlang dieser klassischen Stationen, ohne radikal andere Interaktionsmuster, deckt ein gut konfiguriertes Theme das zuverlässig ab. Individuelle Anpassungen an Layout, Farben, Struktur und Content sind über Abschnitte und App-Blocks möglich, ohne dass du dafür die Architektur wechseln musst.

Dein Team hat keinen eigenen Entwickler

Pflegst du deinen Shop mit einem Marketing- oder E-Commerce-Team, das im Theme-Editor arbeitet, Kampagnen-Seiten baut und Inhalte selbst aktualisiert, ist Online Store 2.0 genau darauf ausgelegt. Eine Hydrogen-Anwendung ohne dauerhaften Entwicklerzugriff im Haus oder bei einer Agentur zu betreiben, führt fast zwangsläufig zu Stillstand, sobald die erste tiefere Anpassung ansteht.

Dein Budgetrahmen ist überschaubar

Ein Theme-Projekt – ob Standard-Theme mit Anpassungen oder ein individuell entwickeltes Shopify-Theme – bewegt sich in einer deutlich kleineren Größenordnung als ein Hydrogen-Projekt, weil ein Großteil der Grundfunktionen bereits mitgeliefert wird, statt komplett neu gebaut werden zu müssen. Details dazu in der Kostenrechnung weiter unten.

Du brauchst den vollen App-Store

Die meisten der tausenden Apps im Shopify-App-Store sind für Online Store 2.0 gebaut und lassen sich per App-Block ohne Zusatzaufwand einbinden. Setzt dein Geschäftsmodell auf mehrere solcher Apps – Bewertungen, Bundle-Angebote, Abo-Funktionen, Cross-Selling –, ist die reibungslose Kompatibilität mit einem Theme ein handfester praktischer Vorteil, den du bei Hydrogen erst mühsam nachbauen müsstest.

Ein Praxisbeispiel, das die vier Kriterien zusammen zeigt: Ein Mode- oder Lifestyle-Shop mit klassischem Produktkatalog, einem kleinen Marketing-Team ohne eigene Entwickler, einem mittleren Wachstumsbudget und drei bis vier laufenden Apps für Bewertungen, Upselling und Retourenmanagement – das ist exakt das Profil, für das Online Store 2.0 gebaut wurde. Kein einziges der vier Kriterien spricht hier für Hydrogen, und genau das ist bei der großen Mehrheit der Shopify-Shops der Fall.

Der stille Preis, den kaum jemand vorher nennt

Ehrlich gehört auch der stille Preis dazu: Mit wachsender App-Zahl geraten sich Funktionen ins Gehege, ein angepasstes Theme bricht beim nächsten Update oft genau an der von Hand bearbeiteten Stelle, und jede Anforderung abseits des Standards endet im Liquid-Gefrickel. Das macht Online Store 2.0 nicht falsch – es zeigt nur den Unterschied zwischen „günstig am Anfang" und „günstig auf Dauer".

Der größere Hebel für mehr Umsatz liegt bei den meisten Shops ohnehin nicht in der Architektur, sondern in Content, Conversion-Optimierung und einer sauberen technischen Basis innerhalb des bestehenden Themes.

Lange war die Standard-Erzählung: Hydrogen ist der seltene Sonderfall für Konzerne mit Sonderwünschen. Aus unserer Projektpraxis sehen wir das anders – wir ziehen viele unserer Kunden bewusst auf Hydrogen, sobald ein Entwicklerteam oder Partner an Bord ist. Vier Gründe, warum das für uns kein Ausnahmefall, sondern ein bevorzugter Weg ist.

Freies Frontend statt Template-Korsett

Ein Theme denkt in Abschnitten und dem, was der Theme-Store hergibt – eine gute Grundlage, aber mit Rand. Sobald eine individuelle Produktdarstellung, ein Konfigurator mit eigener Logik oder ein Content-Commerce-Erlebnis gefragt ist, das Magazin-Artikel, Lookbooks und Produktseiten nahtlos verschmilzt, stößt dieses Modell an seine Grenze. Mit Hydrogen bauen wir das Frontend als eigene Software-Anwendung, ohne Umweg über Theme-Grenzen. Tauchst du gerade in die Wahl eines passenden Content-Systems für genau dieses Szenario ein, findest du im Vergleich gängiger Headless-CMS-Systeme die Einordnung der einzelnen Anbieter.

Der Entwickler-Workflow ist der eigentliche Effizienzgewinn

Das unterschätzte Argument für Hydrogen ist nicht nur die Gestaltungsfreiheit, sondern der Workflow dahinter. Statt im Theme-Editor mit Copy-Paste-Snippets zu hantieren und live am produktiven Shop zu experimentieren, arbeitet unser Team in VS Code, mit Git-Branches, Code-Review vor jedem Merge und wiederverwendbaren Komponenten für weitere Projekte. Jede Änderung läuft zuerst in einer lokalen Vorschau, bevor sie live geht. Für ein eingespieltes Entwicklerteam ist das schlicht der schnellere, sicherere Weg zu arbeiten als die Theme-Oberfläche.

Gezielter Eigenbau statt App-Stapel mit Nebenwirkungen

Wo ein Theme-Shop eine Anforderung oft mit der nächsten App löst, bauen wir sie bei Hydrogen gezielt in eigenem Code – zugeschnitten, ohne die Konflikte, die zehn übereinandergestapelte Apps im selben Theme miteinander eingehen können. Weniger laufende App-Abos, weniger Update-Überraschungen aus fremdem Code, dafür ein Frontend, das nur trägt, was der Shop tatsächlich braucht.

Performance vollständig in eigener Hand

Ladezeit, Caching und Rendering liegen bei Hydrogen nicht teilweise bei Shopifys Theme-Engine, sondern vollständig in der eigenen Codebasis – jede Optimierung, die technisch möglich ist, lässt sich auch tatsächlich umsetzen, statt an eine Theme-Grenze zu stoßen.

Diese Rechnung gilt allerdings nicht pauschal, sondern für eine bestimmte Konstellation: mit eigenem Entwicklerteam oder einer Agentur mit eigenen Entwicklern als Partner. Ohne beides bleibt Hydrogen der falsche Weg – dann ist ein gut konfiguriertes Theme die einzig praktikable Antwort, siehe Abschnitt 06.

Konkrete Eurobeträge wären an dieser Stelle unseriös – jedes Projekt hat einen eigenen Zuschnitt, und wer dir ohne Detailkenntnis deines Vorhabens eine feste Zahl nennt, rät. Was sich seriös sagen lässt, ist die Größenordnung im Verhältnis zueinander.

Aufbau

Ein Online-Store-2.0-Projekt – von der Theme-Auswahl über Anpassungen bis zum individuellen Design auf Theme-Basis – bewegt sich in einer Bandbreite, die stark vom gewünschten Individualisierungsgrad abhängt, bleibt aber grundsätzlich überschaubar, weil Navigation, Warenkorb, Checkout-Anbindung und Kernfunktionen bereits von Shopify und dem Theme mitgeliefert werden. Ein Hydrogen-Projekt beginnt dagegen bei null: Jede dieser Grundfunktionen muss erst gebaut werden, bevor überhaupt die eigentliche Individualisierung beginnt. Als grobe Faustregel aus unserer Projekterfahrung mit beiden Architekturen: Ein vergleichbar umfangreiches Hydrogen-Projekt bewegt sich eher im mehrfachen, nicht im gleichen Vielfachen eines Theme-Projekts – der genaue Faktor hängt stark vom Funktionsumfang ab.

Team während des Aufbaus

Für ein Theme-Projekt reichen in der Regel ein Shopify-erfahrener Entwickler oder eine kleine Agentur, ergänzt um Design und Content – überschaubare Rollen, oft in Teilzeit über das Projekt verteilt. Ein Hydrogen-Projekt braucht durchgehend mindestens einen Frontend-Entwickler mit React-Erfahrung, häufig ergänzt um eine zweite Person für Backend-Integration, Testing und Deployment-Infrastruktur – ein Team, kein Einzelposten.

Laufender Betrieb

Hier liegt der oft unterschätzte Unterschied. Ein Theme aktualisiert sich weitgehend selbst: Sicherheitsupdates und Kompatibilitätsanpassungen kommen vom Theme-Anbieter oder aus dem Theme-Store, dein Team pflegt vor allem Inhalte. Eine Hydrogen-Anwendung ist eigene Software und verlangt eigenen, dauerhaften Betrieb: Abhängigkeiten aktualisieren, Deployments überwachen, Fehler beheben, die nach einem Update in der eigenen Codebasis auftauchen. Das ist keine einmalige Investition, sondern eine wiederkehrende Personalkapazität, die für die gesamte Lebensdauer der Storefront eingeplant werden muss – nicht nur für den Launch-Monat.

Aus unserer Betriebspraxis relativiert sich das ein Stück: Eine Änderung im eigenen Code ist ein normaler Pull-Request, kein Update-Roulette mit fremder App-Logik – planbarer, weil ausschließlich eigener Code betroffen ist.

Wer im Team gebraucht wird

Bei Online Store 2.0 reichen für die meisten laufenden Aufgaben Marketing- oder E-Commerce-Rollen ohne Programmierkenntnisse, ergänzt um punktuelle externe Entwicklerunterstützung für tiefere Eingriffe. Bei Hydrogen ist mindestens eine feste Entwicklerkapazität kein optionales Extra, sondern Grundvoraussetzung, um den Betrieb über den Launch-Tag hinaus abzusichern – eine Rolle, die bei den meisten kleineren und mittleren Shops schlicht nicht vorhanden ist und erst aufgebaut oder dauerhaft eingekauft werden müsste.

Rechne die Entscheidung deshalb nicht als einmaligen Projektpreis, sondern als Gesamtkosten über die Lebensdauer der Storefront: Ein Theme-Projekt hat hohe Fixkosten beim Bau und danach überschaubare, planbare Pflegekosten. Ein Hydrogen-Projekt hat höhere Fixkosten beim Bau und danach eine laufende Personalkostenlinie, die im Zweifel jedes Jahr genauso hoch bleibt wie im ersten – dieser Unterschied entscheidet in der Praxis öfter über die Wirtschaftlichkeit als der reine Bau-Preis.

Bevor du in Richtung Hydrogen springst, gehören vier Risikofelder ehrlich auf den Tisch.

Was garantiert bei Shopify bleibt

Der Checkout ist der wichtigste Punkt, und die Faktenlage ist eindeutig: Auch eine Hydrogen-Storefront führt den Kaufabschluss über Shopifys eigenen, gehosteten Checkout. Shopifys eigene API-Dokumentation zum Warenkorb-Objekt beschreibt es so: Das Feld checkoutUrl dient explizit dazu, „Käufer zu Shopifys Web-Checkout zu leiten, um ihren Kauf abzuschließen". Zahlungsabwicklung, PCI-Konformität und die eigentliche Bezahllogik bleiben damit vollständig in Shopifys Verantwortung – ein entscheidender Unterschied zu einem komplett eigenen, selbstgebauten Checkout-System, das du bei Hydrogen in der Standard-Konfiguration weder bauen musst noch bauen kannst.

Was zu deinem eigenen Problem wird

Alles, was vor dem Checkout passiert, liegt jetzt bei deinem Entwicklerteam. Das Routing zwischen Seiten, technische SEO-Grundlagen der Storefront wie Ladezeit, sauberes HTML und Meta-Angaben, und jedes Fehlerbild, das ein Besucher sieht, wenn irgendwo etwas nicht lädt – all das war bei einem Theme großteils Shopifys oder des Theme-Anbieters Aufgabe, ist bei Hydrogen jetzt Teil deiner eigenen Codebasis. Vertiefend zur SEO-Seite technischer Shopify-Fragen lohnt sich, unabhängig von der Architektur, ein Blick in unseren Leitfaden zu Shopify SEO – die dort beschriebenen Grundprinzipien gelten für eine headless Storefront genauso, nur dass du sie bei Hydrogen selbst technisch umsetzt statt sie im Theme vorzufinden.

Der Rückweg ist möglich, aber kein Klick

Entscheidest du dich nach einiger Zeit wieder für ein Theme, bleiben dein Produktkatalog, deine Kundendaten und deine Bestellhistorie im Shopify-Backend vollständig erhalten – insofern gibt es keinen Daten-Lock-in im eigentlichen Sinn. Was du dagegen nicht einfach zurückschaltest, ist die Storefront selbst: Der Wechsel zurück zu einem Theme bedeutet faktisch einen Neubau der gesamten Frontend-Schicht, nicht das Deaktivieren einer Funktion.

App-Kompatibilität ist kein Selbstläufer

Viele Shopify-Apps sind so gebaut, dass sie ihre Funktion direkt ins Theme rendern – ein Bewertungs-Widget, das automatisch auf der Produktseite erscheint, sobald die App installiert ist. Bei einer headless Storefront funktioniert dieser automatische Weg in aller Regel nicht: Entweder bietet die App eine eigene Anbindung über die Storefront-API, oder dein Team muss die Funktion selbst nachbauen. Prüfe deshalb vor einer Hydrogen-Entscheidung konkret, welche deiner geschäftskritischen Apps eine headless-taugliche Anbindung mitbringen – pauschal „irgendwie wird das schon gehen" ist an dieser Stelle das teuerste Wort im ganzen Projekt.

Ein realistisches Fehlerbild, das genau daraus entsteht: Eine App für Produktbewertungen funktioniert im alten Theme-Shop einwandfrei, weil sie ihren App-Block einfach in die Produktseite einhängt. Nach dem Wechsel zu Hydrogen fehlen die Bewertungen auf der neuen Storefront komplett, weil die App keine Storefront-API-Anbindung anbietet und niemand das vor dem Umzug geprüft hat. Die Lösung ist danach kein Konfigurations-Klick, sondern ein zusätzliches Stück Individualentwicklung, das im ursprünglichen Projektplan nicht eingepreist war.

Rund um Headless und Hydrogen kursieren fünf Fehleinschätzungen, die uns in Gesprächen mit Shop-Betreibern immer wieder begegnen – meist entstanden aus einem einzelnen Halbsatz, der aus dem Zusammenhang gerissen weitergegeben wurde. Jede davon klingt für sich genommen plausibel, hält der Prüfung gegen die Fakten aus den Abschnitten oben aber nicht stand.

„Headless ist automatisch schneller"

Eine eigene React-Anwendung kann schneller sein als ein Theme – muss es aber nicht. Geschwindigkeit hängt von der Qualität der Umsetzung ab, nicht von der Architektur selbst: Ein schlecht gebautes Hydrogen-Frontend mit unoptimierten Bildern und aufgeblähtem Code lädt genauso zäh wie ein vernachlässigtes Theme. Ein sauber konfiguriertes, aktuelles Theme erreicht in der Praxis regelmäßig gute Ladezeiten. Headless verschafft dir zusätzliche technische Stellschrauben – es garantiert dir keine automatisch bessere Performance.

„Online Store 2.0 ist veraltet"

Online Store 2.0 ist die aktuelle, aktiv weiterentwickelte Standard-Architektur für Shopify-Themes, kein Auslaufmodell. Neue Theme-Store-Einträge, neue App-Block-Funktionen und Shopifys eigene, regelmäßige Editions-Updates bauen genau auf dieser Architektur auf. „Veraltet" wäre höchstens ein Shop, der noch auf der alten, rein Liquid-basierten Vorgänger-Generation läuft – nicht die Architektur selbst.

„Mit Hydrogen verlasse ich Shopify"

Das Gegenteil ist der Fall: Hydrogen ist Shopifys eigenes, offiziell gepflegtes Werkzeug für headless Storefronts, keine Abwanderung zu einem anderen Anbieter. Produktverwaltung, Bestellungen, Zahlungen und Checkout laufen unverändert über dein bestehendes Shopify-Backend weiter. Du wechselst die Bauweise deiner Storefront, nicht deinen E-Commerce-Anbieter.

„Shopify 3.0 steht vor der Tür"

Unsere Recherche findet dafür keinen Beleg – weder in Shopifys Entwickler- noch in der Merchant-Dokumentation taucht eine für die Zukunft angekündigte „Version 3.0" auf. Was tatsächlich regelmäßig kommt, sind Shopifys benannte „Editions"-Updates mit neuen Funktionen – keine neue Architektur-Generation. Wer auf eine „3.0" wartet, bevor er sich entscheidet, wartet auf etwas, das derzeit nicht angekündigt ist.

„Headless lohnt sich, weil es moderner wirkt"

„Moderner wirken" ist kein Geschäftsziel und keine tragfähige Entscheidungsgrundlage. Die Gründe, die in Abschnitt 07 tatsächlich für Hydrogen sprechen, sind andere: freies Frontend statt Template-Korsett, ein effizienterer Entwickler-Workflow, leichtere Wartbarkeit als ein gewachsener App-Stapel. „Wirkt zeitgemäßer" ist keiner dieser Gründe – ein teures Projekt allein aus Image-Gründen zu starten, ist der teuerste Weg, ein Statement zu setzen.

Der gemeinsame Nenner aller fünf Fehleinschätzungen: Sie behandeln die Architektur als Statussymbol statt als technische Entscheidung mit echten Konsequenzen für Team, Budget und laufenden Betrieb. Wer die vier Kriterien aus Abschnitt 06 und die vier Gründe aus Abschnitt 07 stattdessen nüchtern durchgeht, braucht keine dieser fünf Halbwahrheiten mehr, um zu einer belastbaren Antwort zu kommen.

Die Entscheidung lässt sich auf eine kurze Logik herunterbrechen – die entscheidende Variable ist nicht dein Sortiment, sondern wer dein Frontend baut. Ohne eigenes Entwicklerteam und ohne Agentur-Partner ist Online Store 2.0 die richtige Wahl – Abschnitt 06 zeigt die stillen Kosten dabei. Mit Team oder Entwicklungspartner und echtem Anspruch ans Frontend ist Hydrogen aus unserer Praxis die Empfehlung, zu der wir immer wieder kommen – die Gründe dafür stehen in Abschnitt 07.

Die Grafik unter Abschnitt 07 fasst diesen Weg noch einmal als Entscheidungs-Pfad zusammen – wenige Fragen, mit denen du dich in wenigen Minuten selbst grob einordnen kannst, bevor du überhaupt ein Beratungsgespräch brauchst.

Unsere ehrliche Selbsteinordnung als Agentur: Wir ziehen viele unserer Kunden bewusst auf Hydrogen, weil wir die Kombination aus freiem Frontend und eigenem Entwickler-Workflow für die bessere Arbeitsweise halten – das ist unsere Praxis, keine erfundene Zahl. Genauso ehrlich gilt: Ohne Entwicklerteam oder Partner an deiner Seite ist Hydrogen für dich der falsche Weg, ganz gleich wie sehr wir selbst von der Architektur überzeugt sind. Die Empfehlung hängt an der Konstellation, nicht an unserer Vorliebe.

Genau diese Einschätzung – und danach die Umsetzung, ganz gleich für welche Architektur – übernehmen wir bei EINSHOCH im Rahmen unserer laufenden Shopify-Entwicklung – vom Theme bis zur Hydrogen-Storefront, mit Entwicklern, die beide Wege aus eigener Projekterfahrung kennen.

Am Ende ist die Architektur-Frage kein Statement, sondern eine Rechnung: Team, Budget, Zeit und laufender Betrieb gegen den Anspruch an dein Frontend. Ohne Entwicklerteam oder Partner ist Online Store 2.0 die einzig praktikable Antwort. Mit Team oder Partner an deiner Seite verschiebt sich diese Rechnung spürbar zugunsten von Hydrogen – und genau dort setzen wir mit unseren Kundenprojekten an.

Und falls sich deine Antwort im Lauf der Zeit ändert – weil dein Shop wächst, du ein eigenes Team aufbaust oder dir einen Entwicklungspartner an die Seite holst –, ist das kein Rückschlag, sondern der Normalfall einer wachsenden Architektur-Entscheidung: Du triffst sie nicht einmal für immer, sondern immer wieder neu, auf Basis dessen, was dein Shop gerade braucht und wer gerade daran baut.