Shopify zu Headless Migration: Next.js, Hydrogen & Remix Guide
Ich habe in den letzten drei Jahren über ein Dutzend Shopify-Stores zu Headless-Architekturen migriert. Einige liefen reibungslos. Einige waren ein Albtraum. Der Unterschied lag fast immer an der Planung — konkret daran, ob das Team verstand, worauf es sich einließ, bevor die erste Zeile Code geschrieben wurde.
Dieser Guide behandelt alles, das ich mir vor meiner ersten Headless-Shopify-Migration hätte sagen lassen: Welches Frontend-Framework man wählt, wie man SEO-Rankings bewahrt, wie man Zero Downtime beim Cutover erreicht, was es wirklich kostet und realistische Timelines basierend auf Store-Komplexität. Keine vagen Aussagen. Kein "es kommt darauf an" ohne Erklärung, worauf es ankommt.
Inhaltsverzeichnis
- Warum von Shopify zu Headless migrieren?
- Headless-Shopify-Architektur erklärt
- Frontend-Wahl: Next.js vs Hydrogen vs Remix
- Der Migrationsprozess Schritt für Schritt
- SEO-Erhaltung während der Migration
- Zero-Downtime-Migrationsstrategie
- Preisgestaltung und Zeitplan-Übersicht
- Häufige Migrationsprobleme
- Wann Headless nicht die richtige Wahl ist
- Häufig gestellte Fragen

Warum von Shopify zu Headless migrieren?
Lasst mich das klarsagen: Standard-Shopify ist für die meisten Stores großartig. Wenn ihr unter $2M/Jahr macht und euer Theme tut, was es soll, braucht ihr wahrscheinlich kein Headless. Ernsthaft. Ich habe mehr Leute von dieser Migration abgeraten als sie überredet.
Aber es gibt legitime Gründe, zu Headless zu wechseln:
- Performance-Decke: Liquid-Themes haben einen Rendering-Bottleneck. Selbst mit Online Store 2.0 und Dawn seid ihr durch Shopifys Server-Side-Rendering-Pipeline begrenzt. Headless-Stores erreichen durchweg Sub-1-Sekunden-LCP-Scores.
- Custom Experiences: Produkt-Konfiguratoren, AR Try-ons, komplexe Filterung, Personalisierungs-Engines — das sind schwierig zu bauen in Liquid.
- Multi-Storefront: Ein Backend, das euer DTC-Site, Wholesale-Portal, Mobile-App und internationale Stores antreibt.
- Content-reiche Marken: Wenn eure Marke stark auf Editorial Content, Lookbooks und Storytelling setzt, bringt die Koppelung eines Headless CMS mit Shopifys Commerce-Engine das Beste aus beiden Welten.
- Developer Experience: Euer Team möchte in React/TypeScript arbeiten, nicht in Liquid. Das ist wichtiger als viele zugeben.
Die Performance-Gewinne sind real und messbar. 2025 beeinflussen Googles Core Web Vitals direkt eure Suchrankings. Stores, die ich zu Headless migriert habe, sehen typischerweise eine 30-50%ige Verbesserung bei LCP und eine 40-60%ige Verbesserung bei Total Blocking Time. Das führt zu messbaren Conversion-Rate-Verbesserungen — Shopifys eigene Daten deuten darauf hin, dass eine 1%ige Verbesserung der Seitenschwindigkeit Conversions um bis zu 0,7% erhöhen kann.
Headless-Shopify-Architektur erklärt
Wenn Leute "Headless Shopify" sagen, meinen sie die Entkopplung des Frontends (was Kunden sehen) vom Backend (Shopifys Commerce-Engine). Ihr behaltet Shopify für Produkte, Inventar, Bestellungen, Checkout und Zahlungen. Ihr baut ein Custom Frontend, das über die Storefront API mit Shopify spricht.
Hier ist die typische Architektur:
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐
│ Custom Frontend│────▶│ Storefront API │────▶│ Shopify Backend │
│ (Next.js/H2/Remix)│ │ (GraphQL) │ │ (Produkte, Cart, │
│ │ │ │ │ Bestellungen) │
└─────────────────┘ └──────────────────┘ └─────────────────┘
│
▼
┌─────────────────┐
│ Headless CMS │
│ (Sanity, Contentful,│
│ Storyblok) │
└─────────────────┘
Shopify-Plus-Kunden bekommen Zugriff auf die Checkout Extensibility API, mit der ihr den Checkout anpassen könnt, ohne zu Shopifys gehosteter Checkout weiterzuleiten. Für Nicht-Plus-Stores werden Kunden immer noch zu checkout.shopify.com für den tatsächlichen Kauf weitergeleitet — was ehrlich gesagt nicht schrecklich ist, aber eine UX-Unterbrechung darstellt.
Die Storefront API
Alles läuft über Shopifys Storefront API, einen GraphQL-Endpoint, der folgendes handhabt:
- Product Queries und Collections
- Cart Management (erstellen, aktualisieren, Line Items entfernen)
- Customer Authentication
- Content (Metafelder, Metaobjekte)
- Shop Localization und Currency
Die API hat Rate Limits — 50 Cost Points pro Sekunde für eine Single App. In der Praxis ist das selten ein Problem, wenn ihr richtig cachert, aber es kann euch während Flash Sales beißen, wenn ihr das nicht geplant habt.
# Beispiel: Ein Produkt mit Varianten abrufen
query ProductQuery($handle: String!) {
product(handle: $handle) {
id
title
descriptionHtml
priceRange {
minVariantPrice {
amount
currencyCode
}
}
variants(first: 100) {
edges {
node {
id
title
availableForSale
price {
amount
}
selectedOptions {
name
value
}
}
}
}
images(first: 10) {
edges {
node {
url
altText
width
height
}
}
}
}
}
Frontend-Wahl: Next.js vs Hydrogen vs Remix
Hier bleiben die meisten Teams stecken. Hier ist meine ehrliche Bewertung nach dem Bau von Production Stores mit allen drei.
| Feature | Next.js 15 | Hydrogen 2024.10+ | Remix (Shopify) |
|---|---|---|---|
| Framework Reife | Sehr reif, massives Ökosystem | Wird reif, Shopify-spezifisch | Reif (in React Router 7 zusammengeführt) |
| Shopify Integration | Manual via Storefront API | First-party, eingebaute Hooks | Gut via Hydrogen UI |
| Hosting | Vercel, Netlify, selbst gehostet | Oxygen (Shopify) oder selbst gehostet | Überall, aber optimiert für Oxygen |
| Lernkurve | Moderat | Moderat-Hoch | Moderat |
| Community/Hiring | Massive | Klein aber wachsend | Mittel |
| SSR/SSG Flexibilität | Exzellent (App Router) | SSR-fokussiert (Streaming) | SSR-fokussiert (Loaders) |
| Caching-Kontrolle | ISR, On-Demand Revalidation | Oxygen Sub-Request Caching | Standard HTTP Caching |
| Beste Wahl für | Teams mit React-Erfahrung, komplexe Content-Anforderungen | Shopify-native Teams, einfache bis mittlere Stores | Teams, die Shopifys empfohlenen Weg gehen möchten |
Next.js: Die sichere Wahl
Next.js ist meine Empfehlung für die meisten Teams, besonders wenn ihr Shopify mit einem Headless CMS wie Sanity oder Contentful paart. Das Ökosystem ist riesig, Hiring ist einfacher, und ihr bekommt unglaubliche Flexibilität mit den Server Components des App Routers.
Der Nachteil? Ihr müsst die Shopify-Integration selbst verdrahten. Es gibt kein offizielles Shopify SDK für Next.js (obwohl Community-Pakete wie @shopify/hydrogen-react euch Cart Hooks und Utilities geben). Ihr verbringt mehr Zeit mit Boilerplate.
Wir bauen viele Headless-Shopify-Stores mit Next.js bei Social Animal — es ist unser meistangeforderter Stack für eCommerce-Projekte.
Hydrogen: Shopifys eigenes Framework
Hydrogen ist Shopifys offizielles Headless-Framework, gebaut auf Remix (jetzt React Router 7). Es kommt mit vorgebauten Components für Produkte, Carts und SEO — plus enger Integration mit Oxygen, Shopifys Edge-Hosting-Plattform.
Die Anziehungskraft ist klar: weniger Boilerplate, Shopify-optimiertes Caching, und eine Deployment-Story, die auf Oxygen einfach funktioniert. Das Release 2024.10 brachte bedeutende Verbesserungen einschließlich besserer TypeScript-Unterstützung und optimistischer UI-Updates für Cart-Operationen.
Die Nachteile? Kleinere Community, weniger Ressourcen wenn ihr steckenbleibt, und ihr seid einigermaßen in Shopifys Ökosystem eingesperrt. Wenn ihr jemals Commerce-Backends wechseln möchtet, schreibt ihr viel mehr Code neu als mit Next.js.
Remix / React Router 7
Hier ist der verwirrende Teil: Remix wurde in React Router 7 zusammengeführt. Hydrogen ist auf Remix gebaut. Also "Remix für Shopify" bedeutet in den meisten Kontexten effektiv Hydrogen.
Wenn ihr React Router 7 ohne Shopifys Shopify-spezifische Abstraktionen nutzen möchtet, könnt ihr das. Ihr bekommt die gleichen Loader/Action-Patterns, das gleiche Streaming SSR, und vollständige Kontrolle über eure Shopify-Integration. Das ist sinnvoll, wenn ihr bereits ein Remix-Team seid und maximale Flexibilität wollt.
Meine Empfehlung
Für content-reiche Marken mit komplexen Page Layouts: Next.js + Headless CMS. Für unkomplizierte DTC-Stores, die den schnellsten Weg zur Production wollen: Hydrogen auf Oxygen. Für Teams, die bereits in das Remix-Ökosystem investiert haben: React Router 7 mit Hydrogen UI Components.

Der Migrationsprozess Schritt für Schritt
Hier ist der Prozess, den ich für jede Migration folge. Er ist langweilig. Er funktioniert.
Phase 1: Audit und Planung (2-3 Wochen)
- Die bestehende Site crawlen — Nutzt Screaming Frog oder Sitebulb um jede URL, Weiterleitung, Canonical Tag und Structured Data Block zu katalogisieren. Exportiert das. Ihr werdet es später brauchen.
- Alle Integrationen dokumentieren — Klaviyo, Yotpo Reviews, Loyalty Programs, Subscription Apps (Recharge, Loop), Payment Gateways. Jede einzelne.
- URL-Strukturen mappen — Werden eure neuen URLs den alten entsprechen? Shopify nutzt
/products/product-handleund/collections/collection-handle. Wenn ihr das ändert, braucht ihr Redirects. - Custom Functionality identifizieren — Alles außer Standard Browse-and-Buy. Gift Cards, Bundles, Wholesale Pricing, Multi-Currency, B2B.
- Stack wählen — Frontend Framework, CMS, Hosting, CDN.
Phase 2: Das Frontend bauen (6-12 Wochen)
Hier passiert die eigentliche Entwicklung. Schlüsselbereiche:
- Product Pages mit Variant Selection, Image Galleries, Reviews Integration
- Collection Pages mit Filtering, Sorting, Pagination
- Cart mit Real-Time Inventory Checks und Upsells
- Search — Shopifys Predictive Search API oder ein Third-Party wie Algolia
- Customer Accounts — Login, Order History, Address Management
- CMS-driven Pages — Homepage, About, Landing Pages
- Checkout Redirect — Umgang mit dem Handoff zu Shopify Checkout
// Beispiel: Next.js Product Page mit ISR
import { getProduct } from '@/lib/shopify'
import { ProductDetails } from '@/components/product-details'
export async function generateStaticParams() {
const products = await getAllProductHandles()
return products.map((handle) => ({ handle }))
}
export default async function ProductPage({
params
}: {
params: { handle: string }
}) {
const product = await getProduct(params.handle)
if (!product) notFound()
return (
<>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: JSON.stringify(generateProductJsonLd(product)),
}}
/>
<ProductDetails product={product} />
</>
)
}
export const revalidate = 60 // ISR: alle 60 Sekunden revalidieren
Phase 3: Integration und QA (2-4 Wochen)
Verbindet alle Third-Party Services. Testet alles. Und ich meine wirklich alles:
- Platziert Test Orders über alle Payment Methods
- Testet Discount Codes, Gift Cards, Automatic Discounts
- Verifiziert Analytics Tracking (GA4, Meta Pixel, TikTok Pixel)
- Load testet die Storefront API Calls unter erwarteter Lastverteilung
- Testet auf echten Devices, nicht nur Chrome DevTools
Phase 4: Cutover (1-2 Tage)
Der eigentliche Switch. Mehr über Zero-Downtime unten.
SEO-Erhaltung während der Migration
Hier gehen Migrationen schief. Ich habe Stores gesehen, die 40% ihres organischen Traffics verloren, weil jemand URL-Redirects vergessen hatte. Seid nicht dieses Team.
URL-Mapping
Erstellt ein vollständiges URL-Mapping-Dokument, bevor ihr eine einzige Redirect-Regel schreibt. Jede URL auf der alten Site braucht ein Ziel auf der neuen Site.
ALT: /collections/summer-2024
NEU: /collections/summer-2024 ← Gleich? Großartig, kein Redirect nötig.
ALT: /blogs/news/our-story
NEU: /journal/our-story ← Anders? 301 Redirect erforderlich.
ALT: /pages/about-us
NEU: /about ← Anders? 301 Redirect erforderlich.
Structured Data
Shopify Themes beinhalten Basic Structured Data. Wenn ihr zu Headless geht, seid ihr verantwortlich dafür, es selbst zu implementieren. Mindestens:
ProductSchema mitoffers,aggregateRatingBreadcrumbListfür NavigationOrganizationfür eure MarkeWebSitemitSearchActionfür Sitelinks SearchFAQPagewo anwendbar
Meta Tags und Canonicals
Jede Page braucht proper <title>, <meta description>, Canonical URL, und Open Graph Tags. In Next.js nutzt die Metadata API:
export async function generateMetadata({ params }): Promise<Metadata> {
const product = await getProduct(params.handle)
return {
title: product.seo.title || product.title,
description: product.seo.description || product.description,
openGraph: {
images: [product.featuredImage?.url],
},
alternates: {
canonical: `https://yourstore.com/products/${params.handle}`,
},
}
}
XML Sitemap
Generiert eure Sitemap dynamisch aus Shopify-Daten. Berücksichtigt Produkte, Collections und CMS Pages. Reicht sie sofort nach der Migration bei Google Search Console ein.
Pre-Migration SEO Checkliste
- Vollständiges URL-Mapping Dokument
- 301 Redirects konfiguriert und getestet
- Structured Data implementiert und validiert
- Meta Tags ziehen aus Shopify SEO Feldern
- XML Sitemap wird dynamisch generiert
- robots.txt richtig konfiguriert
- Google Search Console über Domain Change notifiziert (falls zutreffend)
- Internal Links auf neue URL-Struktur aktualisiert
- Image Alt Texts aus Shopify bewahrt
Zero-Downtime-Migrationsstrategie
Zero Downtime ist keine Magie. Das ist DNS Management und Vorbereitung.
Der Blue-Green Deployment Approach
- Baut und deployed die neue Site auf einer Staging Domain (z.B.
new.yourstore.com) - Lauft beide Sites gleichzeitig für mindestens eine Woche, testet die neue Site gründlich
- Konfiguriert euren CDN/DNS um sofortigen Switch zu unterstützen (Cloudflare, Vercel oder Netlify unterstützen alle das)
- Switcht DNS um auf das neue Frontend zu zeigen — TTL sollte längere Zeit vorher auf 60 Sekunden gesetzt werden
- Monitort alles: Error Rates, 404s, Conversion Rates, Core Web Vitals
Der Proxy Approach (Noch sicherer)
Für Stores über $1M/Monat bevorzuge ich eine proxy-basierte Migration:
- Stellt einen Reverse Proxy (Cloudflare Workers, Vercel Edge Middleware) vor beide alte und neue Sites
- Routet Traffic Seite für Seite — startet mit einer Low-Risk Page wie
/about - Verschiebe schrittweise Pages zum neuen Frontend über 2-4 Wochen
- Monitort jede Page's Performance bevor die nächste verschoben wird
- Product und Collection Pages kommen zuletzt (höchstes Revenue-Risiko)
Dieser Approach fügt Komplexität hinzu, lässt aber euch Probleme fangen, bevor sie euren gesamten Store beeinflussen.
// Vercel Edge Middleware Beispiel für graduelle Migration
import { NextResponse } from 'next/server'
export function middleware(request: NextRequest) {
const { pathname } = request.nextUrl
// Pages bereits zum neuen Frontend migriert
const migratedPaths = ['/about', '/contact', '/journal']
if (migratedPaths.some(path => pathname.startsWith(path))) {
return NextResponse.next() // Serve vom neuen Frontend
}
// Alles andere proxied zum alten Shopify Store
return NextResponse.rewrite(
new URL(pathname, 'https://old-store.myshopify.com')
)
}
Preisgestaltung und Zeitplan-Übersicht
Lasst uns von echten Zahlen reden. Das sind Zahlen von Projekten, die ich 2025 gesehen habe, von einfachen DTC-Stores bis zu komplexen Multi-Market Operationen.
| Store Komplexität | Timeline | Agentur Kosten | Freelancer Kosten |
|---|---|---|---|
| Einfach (< 50 Produkte, Basic Pages, Standard Checkout) | 8-12 Wochen | $40,000 - $75,000 | $20,000 - $40,000 |
| Mittel (50-500 Produkte, CMS, Subscriptions, Multi-Currency) | 12-20 Wochen | $75,000 - $150,000 | $40,000 - $80,000 |
| Komplex (500+ Produkte, B2B+DTC, Custom Checkout, mehrere Integrationen) | 20-32 Wochen | $150,000 - $300,000+ | $80,000 - $150,000 |
Laufende Kosten
Vergesst nicht die wiederkehrenden Ausgaben:
- Shopify Plus: $2,300/Monat (erforderlich für Checkout Extensibility, empfohlen für Headless)
- Hosting: $20-500/Monat (Vercel Pro kostet $20/Benutzer, Oxygen ist mit Shopify enthalten)
- Headless CMS: $0-500/Monat (Sanity, Contentful, Storyblok haben alle kostenlose Tiers)
- Search: $0-500/Monat wenn Algolia oder ähnliches nutzen
- Wartung: Budget 10-15% der initiale Build-Kosten jährlich
Für Teams, die erkunden, was eine Headless-Shopify-Migration für ihre spezifische Situation kosten würde, erklären wir unseren Pricing-Ansatz hier. Wir sind auch glücklich, Dinge über einen schnellen Call einzugrenzen.
Häufige Migrationsprobleme
1. Den Cart Unterschätzen
Der Cart sieht einfach aus, bis ihr berücksichtigt: Discount Codes, Automatic Discounts, Gift Cards, Line Item Properties, Cart Notes, geschätzte Shipping, Tax Calculations, und Cart-Level Metafields. Budget das Doppelte der Zeit, die ihr dafür denkt, dass Cart Functionality braucht.
2. Apps Vergessen
Das Shopify App-Ökosystem, auf das ihr abhängig seid? Die meisten Apps injizieren JavaScript in euer Liquid Theme. Mit Headless bedeutet das, ihr braucht API-basierte Alternativen oder Custom Implementations für Reviews, Wishlists, Loyalty Programs, und mehr.
3. Checkout Customization
Ohne Shopify Plus ($2,300/Monat), könnt ihr die Checkout Experience nicht anpassen. Kunden werden zu Shopifys gehosteter Checkout weitergeleitet, das erzeugt eine visuelle Diskontinuität. Plus Merchants können Checkout Extensibility nutzen, aber es ist immer noch mehr limitiert als ein vollständig Custom Checkout.
4. Nicht Early Performance Testing
Die Storefront API fügt Latenz hinzu. Wenn ihr 8 API Calls macht um eine Product Page zu rendern, werdet ihr das spüren. Cachert aggressiv, nutzt GraphQL Fragments um Over-Fetching zu minimieren, und implementiert Streaming SSR wo möglich.
5. Content Team ignorieren
Euer Marketing Team hat Content im Shopify Admin verwaltet. Jetzt brauchen sie ein Headless CMS. Budget Zeit für Training und das Bauen einer Content Editing Experience, die tatsächlich angenehm zu verwenden ist. Hier ist wo Headless CMS Development Expertise wirklich zählt.
Wann Headless nicht die richtige Wahl ist
Ich werde euch direkt sagen: Headless Shopify ist nicht für jeden. Migriert nicht wenn:
- Euer Store unter $1M/Jahr macht und ihr keine komplexen Customization-Anforderungen habt
- Ihr kein Budget für laufende Entwicklung und Wartung habt
- Euer Team keine React Developer hat (oder Budget um sie zu mieten/kontraktieren)
- Ihr mit eurer derzeitigen Theme's Performance und Features glücklich seid
- Ihr primär eine "coole Tech" Story sucht statt echte Business-Probleme zu lösen
Shopifys Online Store 2.0 mit einem well-optimized Theme kann 90+ auf Lighthouse erreichen. Manchmal ist die richtige Antwort das zu optimieren, das ihr habt, statt von scratch neu zu bauen.
Wenn ihr unsicher seid, betrachtet einen Hybrid Approach: Behaltet euer Shopify Theme aber baut spezifische high-impact Pages (wie eure Homepage oder Landing Pages) als Headless. Ihr könnt Shopifys Storefront API neben eurem bestehenden Theme nutzen. Das lässt euch Value beweisen, bevor ihr zu einer vollständigen Migration committet.
Häufig gestellte Fragen
Wie lange dauert eine Migration von Shopify zu Headless? Für einen typischen Store mit mittlerer Komplexität erwartet 12-20 Wochen vom Kickoff zum Launch. Einfache Stores mit weniger Produkten und Basic Functionality können in 8-12 Wochen shipped werden. Komplexe Multi-Market Stores mit Custom Checkout und umfassenden Integrationen dauern oft 20-32 Wochen. Die Audit- und Planungsphase sollte allein 2-3 Wochen dauern — überspringt das nicht.
Verliere ich meine SEO-Rankings, wenn ich zu Headless Shopify migriere? Nicht wenn ihr es richtig macht. Die Schlüssel sind: Behält die gleiche URL-Struktur (oder setzt proper 301 Redirects ein), implementiert Structured Data auf jedem Page Type, bewahrt Meta Tags und Canonical URLs, und reicht ein aktualisiertes Sitemap bei Google Search Console unmittelbar nach dem Launch ein. Ich sehe typischerweise eine 1-2 Wochen Fluktuation in Rankings Post-Migration, gefolgt von Verbesserung, sobald Google die besseren Core Web Vitals Scores erkennt.
Brauche ich Shopify Plus für Headless? Technisch nein. Die Storefront API ist auf allen Shopify Plans verfügbar. Allerdings gibt Shopify Plus euch Checkout Extensibility (die Checkout Experience anpassen), höhere API Rate Limits, und Zugriff auf Oxygen Hosting. Für ernsthaft Headless Projekte ist Plus bei $2,300/Monat fast immer es wert.
Was ist der Unterschied zwischen Hydrogen und Next.js mit Shopify? Hydrogen ist Shopifys offizielles Headless Framework, gebaut auf Remix/React Router 7. Es beinhaltet Shopify-spezifische Components, Hooks, und Utilities out of the Box, plus optimiertes Deployment auf Oxygen. Next.js erfordert dass ihr die Shopify-Integration selbst baut, gibt euch aber ein größeres Ökosystem, mehr Hosting Optionen, und bessere Unterstützung für komplexe Content Architekturen. Die meisten Agenturen, inklusive unserer, haben starke Meinungen hier basierend auf den spezifischen Projekt-Anforderungen.
Kann ich zu Headless Shopify mit Zero Downtime migrieren? Ja, indem ihr entweder einen Blue-Green Deployment (DNS Switch) oder eine graduelle Proxy-basierte Migration nutzt. Der Blue-Green Approach switched den gesamten Traffic auf einmal via DNS, während der Proxy Approach Pages schrittweise über Wochen migriert. Beides funktioniert. Der Proxy Approach ist sicherer für High-Revenue Stores, aber fügt Komplexität hinzu.
Wie viel kostet eine Headless-Shopify-Migration? Agentur-Kosten reichen typischerweise von $40,000 für einen einfachen Store bis zu $300,000+ für komplexe Multi-Market Operationen. Freelancer Raten sind grob 50-60% von Agentur-Kosten, könnten aber mit weniger Project Management Struktur und weniger Spezialisten kommen. Laufende Kosten beinhalten Shopify Plus ($2,300/Monat), Hosting ($20-500/Monat), CMS ($0-500/Monat), und Wartung (10-15% der Build-Kosten jährlich).
Sollte ich Astro statt Next.js oder Hydrogen für Headless Shopify nutzen? Astro ist eine großartige Wahl für content-reiche Sites mit Islands der Interaktivität, und wir haben mehrere Astro-powered Storefronts gebaut. Es funktioniert gut für Catalog-Style Stores, wo die meisten Pages statisch sind und ihr nur React (oder Svelte, Vue) für interaktive Components wie den Cart braucht. Allerdings für Stores mit schwerer Client-Side Interaktivität — Real-Time Inventory, komplexe Filterung, Instant Search — sind Next.js oder Hydrogens Full React Runtime üblicherweise eine bessere Wahl.
Was passiert mit meinen Shopify Apps nach der Headless Migration? Die meisten Shopify Apps, die Frontend Code injizieren (Popups, Widgets, Review Displays) funktionieren nicht out of the Box. Ihr müsst entweder die App API direkt nutzen, eine Headless-compatible Alternative finden, oder Custom Implementations bauen. Apps, die nur auf dem Backend operieren (Inventory Management, Shipping, ERP Integrationen) funktionieren üblicherweise weiter ohne Änderungen. Auditet immer euer App Stack während der Planungsphase.