Sanity im Headless Commerce: Der Shop verkauft, das CMS erzählt

Das Muster kenne ich aus vielen Erstgesprächen: Der Shop läuft, der Katalog ist gepflegt, der Checkout konvertiert. Dann will das Marketing eine Kampagnen-Landingpage, einen Ratgeber, eine Markenstory. Und plötzlich zeigt sich: Für all das hat das Shopsystem kein Zuhause.

Zur Einordnung, wer hier schreibt: Ich bin Matthias, Ein-Personen-Agentur happycoding.agency in Berlin. Ich baue Commerce-Projekte mit Medusa und Shopify und stelle Sanity als Content-Schicht daneben; auch diese Website läuft auf genau diesem Stack aus Sanity und Next.js.

In diesem Artikel zeige ich dir die Arbeitsteilung, die sich bei mir bewährt hat: Der Shop verkauft, Sanity erzählt, das Frontend führt beides zusammen. Du liest, wie Content auf Produkte zeigt statt sie zu kopieren, was GROQ dabei leistet und wann du dir das ganze Setup besser sparst.

Vorab zu Shopify: Pages und Blog sind an Bord, und für eine Über-uns-Seite reichen sie auch. Aber die Inhalte kleben am Theme. Ein Ratgeber, der drei Produkte vorstellt, entsteht dort als Fließtext mit hineinkopierten Produktbildern und handgesetzten Links. Ändert sich ein Preis oder ein Produkttitel, merkt es niemand.

Ganz strukturlos ist Shopify dabei nicht: Metaobjekte definieren eigene Inhaltstypen mit Feldern, sogar mit Produktreferenzen. Nur bleiben sie Datensätze im Admin, gerendert übers Theme. Für ein FAQ-Modul oder eine Händlerliste reichen sie; eine redaktionelle Strecke mit eigener Dramaturgie, frei kombinierbaren Modulen und Vorschau bekommst du damit nicht modelliert.

Das Ergebnis sehe ich regelmäßig in Audits: Kampagnenseiten entstehen als Pagebuilder-Unikate außerhalb des Shops, der Blog lebt auf einer WordPress-Subdomain, und niemand weiß mehr, wo welcher Inhalt gepflegt wird. Drei Systeme, drei Logins, keine Verbindung zu den Produkten.

Medusa ist noch konsequenter: Es bringt bewusst gar kein CMS mit. Das Framework versteht sich als Commerce-Backend und überlässt die Inhaltsfrage dir; was Medusa grundsätzlich ist, liest du im Medusa-Grundlagenartikel. Für Projekte, wie ich sie auf der MedusaJS-Leistungsseite beschreibe, ist ein Content-System daneben darum keine Kür, sondern Teil der Architektur.

Die Verdichtung: Ein Shopsystem ist eine Kasse mit Katalog, kein Redaktionssystem. Wer beides aus einem Werkzeug pressen will, bekommt von beidem die schwächere Hälfte.

Die Architektur hat drei klar getrennte Zuständigkeiten. Der Shop bleibt die Quelle der Wahrheit für alles, was sich verkauft: Produkte, Varianten, Preise, Lagerbestand, Checkout. Sanity hält alles, was erzählt: Ratgeber, Markenseiten, Kampagnen-Landingpages, SEO-Content. Das Next.js-Frontend fragt beide Systeme ab und fügt sie pro Seite zusammen.

Sanity speichert Inhalte dabei nicht als Seiten, sondern als strukturierte Dokumente im Content Lake: typisierte Felder, abfragbar per API. Was dahintersteckt, erkläre ich im Grundlagenartikel Was ist Sanity?; hier reicht der Kern: Inhalte sind Daten, keine HTML-Seiten.

Das Zusammenfügen übernimmt das Frontend: Beim Rendern holt Next.js den Inhalt per GROQ aus Sanity und die Produktdaten aus der Shop-API. Statische Inhalte lassen sich cachen und bei Änderungen gezielt neu bauen; volatile Werte wie Preis und Lagerbestand fragt die Seite zur Laufzeit ab. So bleibt der Ratgeber schnell und der Preis aktuell.

Für die Redaktion heißt das: Sie arbeitet im Sanity Studio, einer anpassbaren Oberfläche, die ich pro Projekt auf die Inhaltstypen zuschneide. Produktdaten tauchen dort als verknüpfbare Dokumente auf, nicht als Pflegeformular: Den Preis ändert weiterhin der Shop. Diese Grenze diszipliniert, denn sie macht schon im Editor sichtbar, welches System welche Wahrheit besitzt.

Als Beleg dient dir diese Website: Jeder Blogartikel auf happycoding.agency ist ein Sanity-Dokument mit Feldern für Teaser, Kernaussagen, FAQ und Quellen, und das Frontend entscheidet, wie daraus eine Seite wird. Dasselbe Prinzip trägt im Commerce, nur dass dort noch ein Shopsystem mit am Tisch sitzt.

Jetzt zum Kern des Musters. Die häufigste Fehlentscheidung in Content-Commerce-Projekten ist das Kopieren von Produktdaten ins CMS: Titel, Preis und Bild werden eingepflegt und sind drei Wochen später falsch. Die richtige Antwort heißt Referenz: Das Content-Dokument speichert einen Verweis auf das Produkt, niemals dessen Daten.

Referenz heißt dabei ganz konkret: Im Content-Dokument steht die ID des Produktdokuments beziehungsweise die Produkt-ID aus dem Shop. Mehr nicht. Alles Weitere, vom Titel bis zum Lagerbestand, bleibt dort, wo es gepflegt wird.

Für Shopify liefert Sanity das Werkzeug gleich mit: Sanity Connect, die offizielle App aus dem Shopify App Store. Sie synchronisiert Produkte, Varianten und Kollektionen als Dokumente in deinen Content Lake; Änderungen aus Shopify landen dort typischerweise nach wenigen Sekunden (Stand: Oktober 2026). Eine tägliche Drift-Korrektur gleicht Abweichungen automatisch ab und fängt verpasste Webhooks ein.

Seit Juli 2026 importiert Sanity Connect auf Wunsch auch Shopify-Metafelder als Lese-Array auf die Produktdokumente. Zwei Dinge solltest du wissen: Synchronisierte Dokumente zählen zu deinem Sanity-Dokumentenkontingent, ein Dokument je Produkt, Variante und Kollektion. Mit einem Custom-Sync-Handler dampfst du das bei Bedarf ein, etwa indem Varianten als Objekte am Produktdokument landen statt als Einzeldokumente.

Für Medusa gibt es keine fertige App, aber einen offiziell dokumentierten Weg: Medusas Integrationsanleitung beschreibt ein Sanity-Modul im Medusa-Backend, Subscriber auf die Events product.created und product.updated und einen Workflow, der Produkte als Dokumente nach Sanity spiegelt, mit der Produkt-ID als Dokument-ID (Stand: Oktober 2026).

Dein Ratgeber-Dokument referenziert dann diese Produktdokumente, und das Frontend holt Preis und Verfügbarkeit zur Laufzeit frisch aus der Medusa-API. Wie die Gesamtarchitektur aus Medusa, Headless CMS und Frontend zusammenspielt, habe ich im Architekturleitfaden Medusa plus Headless CMS ausführlich beschrieben.

Die Abfragesprache GROQ löst Referenzen direkt in der Query auf. Der Pfeil-Operator -> folgt einer Referenz und liefert das Zieldokument zurück: *[_type == "guide"]{ title, products[]->{ store { title, slug } } } holt einen Ratgeber samt der verknüpften Produktdokumente in einem einzigen Aufruf.

Die Gegenrichtung kann GROQ auch: references() findet jedes Content-Dokument, das auf ein bestimmtes Produkt zeigt. Damit beantwortest du die Frage «Welche Ratgeber erwähnen dieses Produkt?» in einer Zeile und baust daraus den Block «Passende Guides» auf der Produktseite. Und weil GROQ Joins über beliebige Bedingungen erlaubt, funktioniert das Muster notfalls sogar ohne Reference-Felder, etwa über eine gespeicherte Produkt-ID als Zeichenkette.

Für die Aktualität sorgt derselbe Gedanke in Gegenrichtung: Ein Webhook aus Sanity stößt beim Veröffentlichen den gezielten Neuaufbau der betroffenen Seiten an. Publiziert die Redaktion einen Ratgeber um 14:00 Uhr, steht er um 14:01 Uhr im Netz, ohne Deployment und ohne dass jemand einen Entwickler fragen muss.

Bleibt die Frage, wie der Produktverweis mitten in den Ratgebertext kommt. Sanitys Antwort heißt Portable Text: Fließtext wird nicht als HTML gespeichert, sondern als JSON-Array typisierter Blöcke. Absätze, Überschriften und Listen sind Standardblöcke; eigene Blocktypen definierst du selbst.

Genau da liegt der Hebel für Commerce: Du definierst einen Blocktyp «Produktteaser», der nichts enthält außer einer Referenz auf ein Produktdokument. Die Redaktion zieht ihn im Editor zwischen zwei Absätze, und dein Next.js-Renderer entscheidet, wie daraus eine Kaufkachel mit aktuellem Preis wird.

Der zweite Gewinn ist Wiederverwendbarkeit: Weil der Text strukturierte Daten sind, rendert ihn das Web-Frontend als Seite, die App als native Ansicht und der Newsletter als E-Mail-Markup, alles aus derselben Quelle. Portable Text ist dabei kein Sanity-Geheimnis, sondern eine offen dokumentierte Spezifikation mit Bibliotheken für React und weitere Umgebungen.

Merksatz: Ein Ratgeber in Portable Text ist kein HTML-Klumpen, sondern eine Liste von Bausteinen. Produkte sind einer davon.

Warum der Aufwand? Weil Produktseiten allein im Suchmaschinen-Wettbewerb selten gewinnen. Auf Transaktions-Keywords drängen Marktplätze und Preisvergleiche; auf Informationsfragen wie «Mahlgrad einstellen» oder «Welche Regenjacke zum Wandern» ist die Konkurrenz dünner. Genau diese Anfragen fängt der Ratgeber, und der Produktteaser im Text stellt den Kaufanschluss her.

Ein Szenario statt einer erfundenen Fallstudie: Ein D2C-Händler für Espressozubehör schreibt zwölf Ratgeber rund um Zubereitung und Pflege. Jeder verweist per Referenz auf zwei bis drei Produkte. Steigt ein Artikel im Ranking, profitieren die Produktseiten über die internen Links mit, ohne dass jemand Preise nachpflegt: Die zieht das Frontend ja aus dem Shop.

Dazu kommt die Pflege-Rechnung: Zwölf Ratgeber mit kopierten Produktdaten bedeuten bei jeder Preisrunde zwölf Handgriffe und zwölf Fehlerquellen. Mit References kostet dieselbe Preisrunde genau null Content-Arbeit. Je größer dein Katalog und je häufiger deine Preisänderungen, desto schwerer wiegt dieses Argument.

Der zweite Anwendungsfall neben der Suche sind Kampagnen: Für Paid-Traffic braucht das Marketing Landingpages im Wochentakt, nicht im Release-Zyklus. Mit einem Seiten-Baukasten aus vordefinierten Sektionen baut die Redaktion sie selbst zusammen, inklusive Produktteasern per Referenz. Der Entwickler definiert die Bausteine genau einmal; danach entstehen Seiten ohne ihn.

Dass die Mechanik trägt, sehe ich an meinem eigenen Setup: Der Blog auf dieser Website bringt den Großteil der organischen Besucher, und die Artikel verlinken strukturiert auf meine Leistungsseiten. Das Prinzip ist identisch, nur dass bei dir am Ende ein Warenkorb steht statt eines Beratungstermins.

Radikal ehrlich: Es gibt Shops, denen ich von diesem Aufbau abrate. Wenn dein Katalog das Produkt ist und Content-Ambitionen fehlen, kauft dir ein zweites System nichts ein außer Betriebsaufwand. Eine Über-uns-Seite und drei Rechtstexte rechtfertigen kein eigenes Content-Backend.

Drei Prüffragen aus meinen Projektgesprächen:

Zweimal Nein heißt: Bleib bei den Bordmitteln deines Shops, und komm wieder, wenn sich das ändert. Der Wechselpfad läuft dir nicht weg; Sanity lässt sich auch nachträglich neben einen laufenden Shop stellen.

Eine Zwischenstufe gibt es übrigens auch: Fehlt dir zunächst nur der Ratgeber-Bereich, starte mit zwei, drei Dokumenttypen und lass den Seiten-Baukasten weg. Niemand zwingt dich, am ersten Tag das komplette Content-Modell zu bauen; es darf mit deiner Ambition wachsen.

Und rechne nüchtern: Sanity selbst startet mit einem kostenlosen Plan (Stand: Oktober 2026), die eigentlichen Kosten stecken in Modellierung, Sync und Pflege. Was da auf dich zukommt, habe ich im Artikel Was kostet Sanity? aufgeschlüsselt. Ein leeres CMS ist die teuerste Variante: Du bezahlst die Architektur und erntest keinen Traffic.

Wenn dein Shop verkauft, aber nichts erzählt: Geh die drei Prüffragen aus dem letzten Abschnitt durch. Fällt die Antwort zweimal Ja aus, lohnt der Blick auf die Architektur aus diesem Artikel. Wie ich Sanity-Projekte aufsetze, von der Content-Modellierung bis zum Livegang, zeigt dir meine Sanity-Leistungsseite.

Du willst wissen, ob das Muster zu deinem Shop passt? Schick mir deinen Stack und deine Content-Pläne, und ich sage dir in 30 Minuten ehrlich, ob sich der Content-Layer rechnet oder ob die Bordmittel reichen: Buch dir ein unverbindliches Erstgespräch.