Cookies 🍪

Diese Website verwendet Cookies, die Ihre Zustimmung brauchen.

Zum Inhalt springen
Nordalux
Hey 👋
Wir sind für dich da

Vibe Coding bei Schema.org in Shopify: Die typischen Fehler & unser Fix

| Tobias Graeger
Abstrakte Schema.org Structured-Data-Illustration mit JSON-LD Verbindungslinien.
Dieses Bild wurde mit Hilfe
von generativer KI erstellt.

Vibe Coding bei Schema.org in Shopify: Wo es knallt (und wie wir es gelöst haben)

In diesem Beitrag teilen wir eine echte Erfahrung aus einem Kundenprojekt: Wir haben ein bestehendes Schema.org-Setup in einem Shopify-Shop übernommen und festgestellt, wie schnell Vibe Coding (Prompt rein, Code raus) bei Structured Data / JSON-LD gefährlich werden kann.

Nicht, weil KI "schlecht" ist - sondern weil sie bei Preisen, Grundpreisen, Einheiten und Unternehmensdaten gern Dinge "plausibel ergänzt". Und genau das ist im SEO-Kontext brandgefährlich: Der Code kann valide wirken, aber fachlich falsch sein.

Microdata-Fragmente statt sauberem JSON-LD

Im Shop war bereits Schema-Markup vorhanden - allerdings nur bruchstückhaft und verteilt als Microdata in verschiedenen Templates. Typisch für viele ältere Themes: Hier ein itemprop, dort ein paar Daten, aber kein durchgängiges, wartbares System.

Warum fragmentiertes Markup in Shopify schnell instabil wird

  • Du hast keine zentrale Stelle, an der du das Markup "wirklich" kontrollierst.

  • Änderungen am Theme können Markup unbemerkt kaputt machen.

  • Du bekommst schnell Inkonsistenzen (z. B. unterschiedliche Organisationsdaten je Template).

  • Debugging wird teuer, weil Fehler nicht sauber reproduzierbar sind.

Unser Ziel war daher klar: Schema zentral als JSON-LD ausgeben, stabil, wartbar und möglichst automatisiert aus Shopify-Daten gespeist.

Die 3 Fragen, die wir vor dem ersten Prompt klären mussten

Bevor wir auch nur eine Zeile per KI generieren lassen, klären wir im Projekt die fachlichen Leitplanken. Sonst baut dir das Modell "irgendwas", das sich korrekt liest - aber nicht zu Shop/Brand/Compliance passt.

Organization vs. LocalBusiness: Was soll Google wirklich verstehen?

Soll der Shop ausschließlich als Organization ausgezeichnet werden - oder auch als LocalBusiness (z. B. mit Standortdaten, Abholung, lokalen Öffnungszeiten)?

Das ist keine Geschmacksfrage, sondern eine Strukturentscheidung: Entitäten, Felder und Verknüpfungen ändern sich.

Grundpreis & Einheiten: nur aus Shop-Daten, nicht "ausgedacht"

Wenn Grundpreise (Unit Price / Grundpreisangabe) im Shop relevant sind, muss klar sein:

  • Woher kommen referenceQuantity und unitCode?

  • Welche Einheiten sind zulässig (ml, l, g, kg)?

  • Wie wird das bei Varianten abgebildet?

Hier ist "KI rechnet mal eben" genau der Punkt, an dem es später knallt.

Welche Kontaktdaten dürfen ins Markup?

Shopify enthält oft Daten, die intern sinnvoll sind (z. B. Inhaber-Telefonnummer, Admin-Mail). Structured Data ist aber öffentlich - deswegen entscheiden wir bewusst:

  • welche Telefonnummer angezeigt werden soll

  • welche E-Mail-Adresse ins Markup darf

  • welche Daten nicht in Suchmaschinen landen sollen

Unser Motto in solchen Projekten: Es muss einfach funktionieren - aber nicht "blind".

So haben wir Vibe Coding im Projekt eingesetzt

Wir sind nach dem fachlichen Setup bewusst ins Vibe Coding eingestiegen - weil KI bei Structured Data extrem viel Zeit sparen kann:

  • Grundgerüst für JSON-LD

  • saubere Struktur und Felder

  • schnelle Iterationen im Format und Aufbau

KI für Struktur - Review für Wahrheit

Wir nutzen KI als Co-Pilot: Sie liefert Geschwindigkeit und Struktur. Die Wahrheit (Datenquelle, Logik, Einheiten, Varianten) kommt aus Shopify - und wird von uns geprüft.
Und genau da lag in diesem Projekt die entscheidende Erkenntnis:

Der Output war technisch "okay", aber fachlich nicht sicher.

Valid, aber falsch: Diese 3 Schema-Bugs hatten wir im Ergebnis

Der generierte Code war auf den ersten Blick solide. Das Markup ließ sich rendern, wirkte logisch - aber im Detail gab es Fehler, die im SEO-Kontext richtig teuer werden können.

1) Doppelte Organization-Ausgabe (mehrfach, leicht unterschiedlich)

Im Markup wurde die Organization mehrfach ausgespielt - in unterschiedlichen Bereichen, teilweise mit kleinen Abweichungen.

Was das in der Praxis bedeutet:

  • Google bekommt mehrere "Wahrheiten"

  • du verlierst Konsistenz

  • spätere Änderungen sind Chaos, weil du nicht mehr weißt, welche Ausgabe "die richtige" ist

Unsere Regel: Eine Organization. Eine Quelle. Alles andere referenziert diese Entität.

2) Grundpreis wurde berechnet statt übernommen

Die KI hat den Grundpreis "hergeleitet" - im Script berechnet, statt ihn aus den Shopdaten zu ziehen.

Das klingt erstmal smart, ist aber in Shopify gefährlich:

  • Variantenlogik kann abweichen

  • Rundungen/Preisformatierungen führen zu Differenzen

  • Rabatte/Preisregeln machen Berechnungen anfällig

  • du gibst Werte aus, die nicht 1:1 dem Shop entsprechen

Unsere Regel: Grundpreis kommt aus verlässlichen Shopify-Daten - nicht aus spontaner Mathematik.

3) Einheit pauschal als "Stück" geraten

Die Grundeinheit wurde pauschal als "Stück" ausgegeben - unabhängig davon, was das Produkt tatsächlich ist.

Für einen Shop mit Flüssigkeiten ist das der Worst Case:

  • 250 ml wird zu "250 Stück"

  • 1 Liter wird zu "1 Stück"

  • die gesamte Preis-/Grundpreislogik wird unbrauchbar

Unsere Regel: Einheit und referenceQuantity nur ausgeben, wenn Shopify sie sauber liefert - und dann korrekt (ml/l/g/kg).

Unser Fix: einmal richtig - dann wartbar

Nachdem wir die Fehler gesehen hatten, blieb nur eine saubere Lösung: Wir haben den Code nicht "geflickt", sondern strukturiert neu aufgebaut.

Single Source of Truth: Organization & Website nur einmal definieren

Wir definieren Organization/Website zentral, sauber verknüpft und überall referenziert. Kein Duplikat, kein "zweites Objekt", das später abweicht.

Unit Price sauber aus Shopify ziehen (statt rechnen)

Wenn Grundpreise vorhanden sind, werden sie aus den Shopdaten übernommen - inklusive Einheit. Wenn sie nicht sauber vorhanden sind: lieber weglassen als raten.

Zentraler JSON-LD-Output statt Template-Flickenteppich

Das Markup wird an einer Stelle gepflegt und ausgegeben. Dadurch:

  • weniger Risiko bei Theme-Updates

  • schnelleres Debugging

  • klare Verantwortlichkeit

  • skalierbar für neue Templates/Seiten

Unsere Nordalux-Checkliste: Vibe Coding bei Schema.org ohne Risiko

Diese Punkte prüfen wir immer, bevor ein Schema live geht - besonders, wenn KI im Spiel war:

  • Gibt es doppelte Organization/WebSite/WebPage-Entitäten?

  • Kommen Preis/Währung/Availability direkt aus Shopify (nicht geraten/gerechnet)?

  • Sind Grundpreis & Einheiten korrekt (ml/l/g/kg) - oder pauschal "Stück"?

  • Sind Kontaktdaten öffentlich gewollt (nicht Admin/privat)?

  • Ist das Markup zentral wartbar oder verteilt im Theme?

  • Sind Varianten sauber abbildbar (Preis/Verfügbarkeit pro Variante)?

Fazit: Vibe Coding spart Zeit - aber Schema braucht Kontrolle

Vibe Coding ist bei Schema.org in Shopify ein echter Produktivitätsboost.

Aber sobald es um Preislogik, Grundpreis, Einheiten, Verfügbarkeit und Organisationsdaten geht, gilt:

Valider Code ist nicht automatisch korrekter Code.

Unser Learning aus diesem Projekt:

KI liefert Tempo. Shopify liefert Wahrheit. Und wir sorgen dafür, dass beides zusammenpasst.

Weiterführende Services

Strukturierte Daten sind ein zentraler Baustein unseres Agentic-Commerce-Angebots: Wir optimieren deinen Shopify-Shop so, dass KI-Assistenten wie ChatGPT und Perplexity deine Produkte korrekt verstehen und empfehlen. Mehr zu unserer individuellen Shopify-Entwicklung.

T

Tobias Graeger

Inhaber & Shopify-Entwickler

Tobias leitet alle Projekte persönlich. Mit über 50 abgeschlossenen Shopify-Projekten kennt er die Plattform vom Liquid-Template bis zur API-Integration. Sein Fokus: technisch saubere Lösungen, die mit dem Business mitwachsen.

LinkedIn

Beitrag teilen