Shopify Store mit Lovable gebaut? Stolpersteine & Lösungen

Von unsichtbaren Analytics über kaputtes SEO bis zur unprofessionellen Checkout-URL — und wie du alles sauber in den Griff bekommst.

Lovable hat sich in kurzer Zeit zu einem der spannendsten Tools für den Bau von React-basierten Webanwendungen entwickelt. Gerade im E-Commerce-Umfeld setzen immer mehr Teams darauf, ihr Shopify-Frontend mit Lovable aufzubauen — schnell, flexibel und visuell ansprechend. Was dabei entsteht, ist im Kern ein klassisches Headless-Setup: ein eigenständiges React-Frontend, das über die Shopify Storefront API mit dem Backend kommuniziert.

Und genau hier beginnen die Probleme, die in keinem Tutorial stehen.

Wir haben in unserer Agentur mittlerweile mehrere Shopify-Projekte mit Lovable umgesetzt und dabei drei zentrale Stolpersteine identifiziert, die ohne Vorwissen schnell zu echten Showstoppern werden:

Shopify Admin Analytics ist leer — keine Sessions, kein Traffic, keine Conversion Rate
SEO funktioniert nicht — Google sieht nur eine leere HTML-Hülle statt echtem Seiteninhalt
Die Checkout-URL läuft über myshopify.com — unprofessionell und vertrauensschädigend

In diesem Artikel zeigen wir, woran das jeweils liegt und wie wir jedes dieser Probleme gelöst haben.

Stolperstein 1: Shopify Admin Analytics zeigt keine Daten

Warum das passiert

Bei einem Headless-Setup ist das Frontend eine komplett eigenständige Anwendung — gehostet auf Cloudflare Pages, Vercel oder Netlify, jedenfalls nicht auf Shopify. Das bedeutet: Alles, was auf dem Custom-Frontend passiert, ist für Shopify unsichtbar. Die Plattform trackt nur, was auf ihrer eigenen Infrastruktur geschieht — also den Checkout.

Konkret fehlt im Shopify Admin unter Analytics:

Sessions und Traffic — komplett bei null
Online Store Conversion Rate — nicht berechenbar, weil die Session-Daten fehlen
Produktansichten und Top-Produkte — nicht vorhanden
Add-to-Cart-Rate — ebenfalls null
Traffic-Quellen und Referrer — keinerlei Daten

Was bleibt, sind die nackten Umsatzzahlen. Für datengetriebene Entscheidungen reicht das bei weitem nicht aus.

Ansätze, die nicht funktionieren

Wer nach „Shopify Headless Analytics" sucht, findet diverse Ansätze — die meisten davon führen in Sackgassen. Wir haben sie durchprobiert:

Shopify.analytics.publish() gehört zur Shopify Theme API und existiert ausschließlich innerhalb von Shopifys eigenem Online Store Renderer. In einem externen React-Frontend ist dieses Objekt nicht verfügbar.
Das shopify-analytics.js Script vom Shopify CDN erwartet Liquid-Template-Variablen und den Shopify-Theme-Kontext. In einer Lovable-App fehlt dieser Kontext vollständig.
Shopify Custom Pixels sind Konsumenten von Events — sie können Ereignisse abonnieren, aber keine erzeugen. Man kann damit keine Daten von einem Headless-Frontend in Shopify Analytics einliefern.
Manuelles Setzen von Shopify-Cookies ist theoretisch möglich, praktisch fragil und unnötig — weil Shopify einen offiziellen Hook dafür bereitstellt.

Die Lösung: @shopify/hydrogen-react

Shopify veröffentlicht ein npm-Paket namens @shopify/hydrogen-react. Trotz des Namens ist es framework-agnostisch und funktioniert in jedem React-Projekt — nicht nur in Hydrogen oder Remix. Das ist die entscheidende Information, die in den meisten Anleitungen fehlt.

Das Paket stellt vier zentrale Bausteine bereit:

useShopifyCookies() verwaltet die _shopify_y (eindeutiger Nutzer) und _shopify_s (Session) Cookies, die Shopify zur Besuchererkennung benötigt.
sendShopifyAnalytics() sendet Events direkt an Shopifys Monorail-Endpoint — dieselbe Infrastruktur, die auch der native Online Store nutzt.
getClientBrowserParameters() sammelt Browser-Daten wie URL, Referrer, User Agent und Cookie-Tokens.
AnalyticsEventName liefert Konstanten für PAGE_VIEW und ADD_TO_CART Events.

Der Datenfluss ist klar strukturiert: Das Frontend setzt die Cookies, sammelt die Browser-Parameter und schickt alles per HTTP POST an Shopifys Monorail-Endpoint. Von dort fließen die Daten ins Admin Dashboard. Checkout-Events trackt Shopify weiterhin automatisch, da der Checkout auf ihrer Infrastruktur läuft.

Implementierung in fünf Schritten

Schritt 1

Paket installieren mit npm install @shopify/hydrogen-react.

Schritt 2

Die numerische Shop-ID über die GraphQL Admin API abfragen. Die Query { shop { id } } liefert ein Ergebnis im Format gid://shopify/Shop/12345678 — relevant ist die Zahl am Ende.

Schritt 3

Ein zentrales Analytics-Modul anlegen (z. B. src/lib/shopifyAnalytics.ts), das die Shop-Konfiguration kapselt und zwei Kernfunktionen bereitstellt: eine für Page Views und eine für Add-to-Cart Events. Beide prüfen den Consent-Status, rufen die Browser-Parameter ab und senden den Event an Shopify.

Schritt 4

Eine unsichtbare Tracker-Komponente erstellen, die useShopifyCookies() für die Session-Verwaltung aufruft und bei jeder Route-Änderung automatisch einen Page View sendet. Die Komponente wird einmal in die App eingebunden und läuft danach im Hintergrund.

Schritt 5

Spezifische Events ergänzen — Produktseiten mit pageType „product" und Produktdaten anreichern, Kollektionsseiten mit pageType „collection", und den ADD_TO_CART Event im Cart-Store auslösen.

Ergebnis

Nach 24 bis 48 Stunden erscheinen im Shopify Admin: Sessions und Traffic, die vollständige Conversion Rate, Produktansichten, Traffic-Quellen sowie die Add-to-Cart-Rate. Die Verifizierung erfolgt über die Browser DevTools — Requests an monorail-edge.shopifysvc.com sollten mit HTTP 200 zurückkommen, und die _shopify_y und _shopify_s Cookies müssen im Application Tab sichtbar sein.

Stolperstein 2: Google sieht nur eine leere Seite

Das Problem mit SPAs und Suchmaschinen

Das ist ein Punkt, den viele erst bemerken, wenn der Store schon live ist: Lovable baut React-Anwendungen als Single Page Applications (SPAs). Das heißt, der Server liefert eine nahezu leere HTML-Datei aus — ein <div> und ein Haufen JavaScript. Der gesamte Seiteninhalt wird erst im Browser durch JavaScript gerendert.

Für Besucher ist das kein Problem — der Browser führt das JavaScript aus und die Seite erscheint. Für Suchmaschinen ist es ein massives Problem. Wenn Google den Quelltext deiner Seite abruft, sieht es im schlimmsten Fall:

Keinen Seitentitel (oder nur den generischen aus index.html)
Keine Meta-Description
Keinen sichtbaren Seiteninhalt — keine Überschriften, keine Texte, keine Produktbeschreibungen
Keine strukturierten Daten

Ja, Google kann JavaScript rendern. Aber es geschieht zeitverzögert, mit begrenztem Budget, und nicht immer vollständig. Bei einem E-Commerce-Store, wo jede Produktseite, Kategorieseite und Landingpage in den Index muss, ist das ein ernsthaftes Ranking-Risiko.

Kurz gesagt: Dein schöner Lovable-Store existiert für Google praktisch nicht.

Warum die Standardlösungen hier nicht greifen

In einem normalen React-Projekt würde man zu Next.js greifen oder Server-Side Rendering einrichten. Beides ist mit Lovable nicht ohne Weiteres möglich, weil Lovable seine eigene Build-Pipeline hat und keine zusätzlichen Build-Schritte unterstützt.

Die Lösung, die wir erfolgreich einsetzen, ist Build-Time Pre-Rendering: Vor dem Deployment wird jede wichtige Route einmal serverseitig gerendert und als vollständige HTML-Datei gespeichert. Das Ergebnis sind statische HTML-Dateien mit echtem Inhalt, echten Titeln und echten Meta-Tags — die trotzdem nach dem Laden als normale React-SPA funktionieren.

So funktioniert das Pre-Rendering

Der Ansatz basiert auf einer Trennung zwischen Client-Entry und Server-Entry. Die React-App bekommt zwei Einstiegspunkte: einen für den Browser (der die fertige HTML-Seite „hydriert" und interaktiv macht) und einen für den Build-Prozess (der jede Route zu statischem HTML rendert).

Die wichtigsten Schritte im Überblick

SEO-Komponente erstellen

Wir verwenden react-helmet-async, um pro Seite individuelle Titel, Meta-Descriptions und Open-Graph-Tags zu definieren. Jede wichtige Seite — Startseite, Produktseiten, Kategorien, Blog — bekommt ihre eigenen SEO-Daten.

Router-Architektur anpassen

Der BrowserRouter muss aus der App-Komponente herausgezogen werden. Die App selbst enthält nur Routes und Route-Definitionen. Der Router-Wrapper kommt in die jeweiligen Entry-Dateien — BrowserRouter für den Client, StaticRouter für den Server.

Zwei Entry-Points erstellen

Der Client-Entry (entry-client.tsx) nutzt hydrateRoot statt createRoot, damit die bereits vorhandene HTML-Struktur nicht neu gerendert, sondern nur interaktiv gemacht wird. Der Server-Entry (entry-server.tsx) rendert die App mit renderToString zu statischem HTML und sammelt dabei die SEO-Tags ein.

Pre-Render-Script schreiben

Ein Node-Script iteriert über alle definierten Routen, rendert jede einzelne, injiziert den HTML-Output und die SEO-Tags in das Template und speichert das Ergebnis als eigenständige HTML-Datei.

Lokal bauen und deployen

Da Lovable die zusätzlichen Build-Schritte nicht unterstützt, erfolgt der Build lokal in VS Code. Zwei Vite-Builds (Client und SSR) plus das Pre-Render-Script erzeugen den fertigen dist-Ordner, der dann auf Cloudflare Pages oder einen anderen Hoster deployed wird.

Was dabei zu beachten ist

Nicht jede Route eignet sich fürs Pre-Rendering. Seiten mit Authentifizierung, Dashboards oder nutzerspezifischen Inhalten sollten als reine SPA-Routen erhalten bleiben. Nur öffentliche, statische Seiten — also genau die, die Google indexieren soll — werden pre-gerendert.

Außerdem wichtig: Jede neue Seite, die indexiert werden soll, muss explizit in die Routenliste des Pre-Render-Scripts aufgenommen werden. Vergisst man eine Route, bekommt sie kein statisches HTML.

Das Ergebnis

Nach dem Pre-Rendering sieht der Quelltext jeder Seite so aus, wie Google es braucht: vollständige Überschriften, Fließtext, Meta-Tags und Open-Graph-Daten — alles direkt im HTML, ohne dass JavaScript ausgeführt werden muss. Gleichzeitig bleibt das SPA-Verhalten nach dem Laden erhalten. Die Seite ist schnell, interaktiv und SEO-tauglich.

Stolperstein 3: Die unprofessionelle myshopify.com Checkout-URL

Warum das ein Problem ist

Standardmäßig landet der Kunde beim Checkout auf einer URL wie yourstore.myshopify.com/checkouts/cn/Z2NwLXV… — mitten in einem ansonsten professionell gebrandeten Shop. Das untergräbt das Vertrauen und kann die Conversion Rate negativ beeinflussen.

Die Lösung: Eigene Checkout-Subdomain

Im DNS-Provider (z. B. Cloudflare) einen CNAME-Record anlegen: Name „checkout", Ziel „shops.myshopify.com". Wichtig bei Cloudflare: Der Proxy muss deaktiviert sein (graue Wolke), sonst schlägt die SSL-Konfiguration und Shopifys Domain-Verifizierung fehl.

Anschließend im Shopify Admin unter Einstellungen → Domains die neue Subdomain hinzufügen. Shopify verifiziert den DNS-Eintrag automatisch und leitet den Checkout danach über die eigene Subdomain aus.

Das Ergebnis: Checkout-URLs wie checkout.deinedomain.com statt der myshopify.com-Variante. Gleiche Domain-Familie, mehr Vertrauen, bessere Conversion — und sauberes Tracking.

Wichtige Hinweise für die Praxis

Cookie Consent richtig integrieren

Wenn der Parameter hasUserConsent auf false steht, versendet sendShopifyAnalytics() keine Daten. Das Cookie-Consent-Banner muss korrekt angebunden sein und den tatsächlichen Consent-Status zuverlässig weitergeben.

Headless Sales Channel aktivieren

Der „Headless" Sales Channel in Shopify Admin liefert eine Storefront-ID, die die Analytics-Attribution verbessert. Wir empfehlen, diesen von Anfang an zu installieren.

Datenschutz-Einstellungen abstimmen

Unter Einstellungen → Kundendatenschutz im Shopify Admin sollten die Datenerhebungseinstellungen zur Consent-Implementierung im Frontend passen. Inkonsistenzen führen dazu, dass Daten serverseitig verworfen werden — ohne Fehlermeldung.

Pre-Rendering Route-Strategie planen

Nicht jede Route sollte pre-gerendert werden. Seiten hinter einem Login, Dashboards und nutzerspezifische Inhalte bleiben als reine SPA-Routen bestehen. Eine saubere Trennung zwischen öffentlichen und geschützten Routen spart später viel Debugging.

Unser Fazit

Lovable ist ein hervorragendes Tool, um schnell ansprechende Shopify-Frontends zu bauen. Aber ein Headless-Setup bringt technische Herausforderungen mit sich, die man kennen muss. Die drei größten — fehlende Analytics, kaputtes SEO und die Checkout-URL — lassen sich mit den richtigen Ansätzen sauber lösen:

@shopify/hydrogen-react für vollständige Analytics-Daten im Shopify Admin
Build-Time Pre-Rendering mit react-helmet-async für echtes, crawlbares HTML
Eine eigene Checkout-Subdomain für professionelles Branding und sauberes Tracking

Wir haben diesen Prozess inzwischen mehrfach erfolgreich umgesetzt und kennen die typischen Fallstricke.

Shopify Store mit Lovable gebaut? Diese Stolpersteine erwarten dich — und so löst du sie