Reicht ein Shopify-Rabattcode den Streichpreis ins Google Merchant Center durch?

Nein. Ein Rabattcode (oder automatischer Rabatt) wird erst am Checkout auf den Warenkorb angewendet und verändert weder den Produktpreis noch den Vergleichspreis der Variante. Der Produkt-Feed überträgt aber genau diese Produkt- und Variantendaten. Da der Code diese Felder nie berührt, bleibt der Feed unverändert und in Google Shopping erscheint kein durchgestrichener Preis.

Wie entsteht der durchgestrichene Preis in Google Shopping?

Über das Feldpaar price und sale_price. Setzt man bei Shopify einen Compare-at price über dem aktuellen Verkaufspreis, übergibt der Google-&-YouTube-Channel den höheren Compare-at als regulären price und den niedrigeren aktuellen Preis als sale_price. Google zeigt die Sale-Annotation aber nur, wenn der Rabatt über 5 % und unter 90 % liegt und der Basispreis vorher echt galt — in Deutschland an mindestens 30 der letzten 200 Tage. Eine über Nacht hochgesetzte compare-at allein genügt nicht.

Kann ich pro Markt unterschiedliche Sale-Preise im Feed haben?

Ja, aber nur über Kataloge bzw. Preislisten (Markets / B2B): Dort lässt sich der Compare-at price je Markt separat setzen (Option „Include compare-at price"), nicht nur global je Variante. In multi-market-Setups ist das die häufigste Fehlerquelle: Vergisst man die Per-Markt-Compare-at oder ergibt die Rundung lokal keinen glaubwürdigen Rabatt, fehlt im Feed des Zielmarkts der Streichpreis. Pro Markt prüfen, ob die Differenz lokal überhaupt als Sale ankommt.

Was ist mit Merchant Center Promotions — ist das nicht der Code?

Merchant Center Promotions sind ein eigener Kanal, getrennt vom Produkt-Feed. Sie blenden in der Anzeige einen Aktions- oder Code-Badge ein („Code SOMMER10"), erzeugen aber keinen durchgestrichenen Preis. Wer ein sichtbares Streichpreis-Signal will, braucht den sale_price-Weg über compare-at; wer einen einlösbaren Code in der Anzeige bewerben will, nutzt Promotions. Das sind zwei verschiedene Ziele.

Acquisition / Ads

Rabattcode vs. Streichpreis: warum nur compare-at das Sale-Signal ins Merchant Center trägt

Ein Shopify-Rabattcode senkt den Warenkorb erst am Checkout und lässt Produktpreis und Vergleichspreis unangetastet. Genau deshalb erzeugt er keinen durchgestrichenen Preis auf der Produktseite und — entscheidend — keinen sale_price im Google-Feed. Nur ein echter Vergleichspreis (compare-at über dem aktuellen Preis) trägt die Aktion bis ins Merchant Center, wo Shopping den Streichpreis ausspielen kann. Wer eine sichtbare globale Aktion fahren will, ändert also Preise, nicht Codes — und das ist kein Detail, sondern der Unterschied zwischen einem Sale, den die Anzeige zeigt, und einem, der onsite verpufft.

Drei Mechaniken, die ständig verwechselt werden

„Wir machen 20 % auf alles" ist betriebswirtschaftlich eine Aussage, technisch aber drei völlig verschiedene Dinge. Welche davon man wählt, entscheidet, ob die Aktion im Feed und in der Anzeige ankommt:

Rabattcode / automatischer Rabatt. Wird im Checkout auf den Warenkorb gerechnet. Er verändert weder den price noch den compareAtPrice der Variante. Onsite sieht der Kunde den vollen Preis auf der PDP und den Abzug erst im Warenkorb; im Feed taucht er nie auf, weil der Feed Produktdaten überträgt, keine Checkout-Logik.
Vergleichspreis (compare-at). Ein Variantenfeld. Setzt man den compareAtPrice über den aktuellen price, rendert das Theme einen durchgestrichenen Preis auf der PDP — undder Google-&-YouTube-Channel reicht das Feldpaar an das Merchant Center durch. Das ist der einzige der drei Wege, der das Sale-Signal sowohl onsite als auch im Feed sichtbar macht.
Echte Preisänderung als Aktion. Mechanisch identisch zum compare-at-Fall: Man senkt price und setzt compareAtPrice auf den vorherigen Regulärpreis. Das ist der „ehrliche" Sale — und exakt die Mechanik, die Google und der EU-Rechtsrahmen erwarten.

Die Verwechslung kostet Geld, weil sie spät auffällt: Die Aktion ist intern als „Code" gebaut, das Theme zeigt im Warenkorb brav den Rabatt, alle sind zufrieden — und niemand merkt, dass die teuer eingekauften Shopping-Impressions weiter den vollen Preis ohne Streichpreis ausspielen, während der Wettbewerber daneben mit durchgestrichenem Preis und „Sale"-Label klickt.

Welches Shopify-Feld in welches Google-Feld läuft

Hier liegt die eigentliche Begriffsfalle — und sie ist kontraintuitiv. Der höhere Shopify Compare-at price (der durchgestrichene Originalpreis) wird im Feed zum regulären Google-price. Der niedrigere, aktuell gültige Shopify Price (der reduzierte Verkaufspreis) wird zum Google-sale_price. Wer das einmal verinnerlicht, versteht sofort, warum ein Rabattcode hier nichts ausrichtet: Er schreibt in keines der beiden Felder, weil er konzeptionell gar kein Produktpreis ist. Shopify dokumentiert das Verhalten — ein Sale entsteht nur, wenn Compare-at price über dem aktuellen Preis liegt — und Google die korrespondierende Feldsemantik von price und sale_price.

Effekt	Rabattcode	Compare-at / echte Preisänderung
Streichpreis auf der PDP	Nein (voller Preis, Abzug erst im Cart)	Ja (Theme rendert price < compare-at)
Rabatt im Warenkorb / Checkout	Ja	Schon im Preis enthalten
`price` / `sale_price` im Google-Feed	Unverändert (kein sale_price)	Compare-at → price, aktueller Preis → sale_price
Streichpreis / Sale-Label in Shopping	Nein	Ja, wenn Rabatt- und Historie-Regeln erfüllt
Pro Markt sauber steuerbar	Teils (Code-Bedingungen)	Ja, über Kataloge/Preislisten je Markt
Bedingte Logik (ab 100 €, gated, gestaffelt)	Ja — die Stärke des Codes	Nein

Die Zeile, um die es geht, ist das Feldpaar price/sale_price. Der Produkt-Feed kennt genau diese zwei Preisfelder; erst wenn der Compare-at den höheren price und der aktuelle Preis den niedrigeren sale_price liefert, kann Google die durchgestrichene Darstellung überhaupt rendern. Ein Rabattcode füllt keines der beiden Felder.

Warum selbst der echte Streichpreis nicht automatisch in der Anzeige steht

Hier liegt die zweite Falle, und sie trifft genau die Teams, die alles „richtig" gemacht haben. Ein sale_price im Feed ist notwendig, aber nicht hinreichend für den durchgestrichenen Preis in Shopping. Google zeigt die Sale-Annotation nur, wenn der Rabatt über 5 % und unter 90 % liegt und der Basispreis vorher tatsächlich galt — in Deutschland an mindestens 30 der letzten 200 Tage. Die Annotation selbst läuft dann maximal rund 30 Tage. Google nennt diese Schwellen ausdrücklich.

Wer also eine compare-at über Nacht künstlich hochsetzt, um einen fetten Rabatt vorzutäuschen, bekommt im besten Fall keine Annotation. Der EU-Rahmen verlangt onsite ohnehin etwas Vergleichbares, aber sauber davon zu trennen: Nach § 11 PAngV muss sich der durchgestrichene Referenzpreis am niedrigsten Gesamtpreis der letzten 30 Tage orientieren, nicht an einer frei erfundenen UVP (bestätigt durch EuGH C-330/23). Das ist eine andere Schwelle als die Google-Anzeigeregel — beide gelten unabhängig nebeneinander, zeigen aber in dieselbe Richtung: Der Streichpreis ist nur so viel wert wie die Preis-Historie, die ihn trägt. Das ist kein Hindernis, sondern die eigentliche Disziplin einer sauberen Aktion.

Der teure Sonderfall: multi-market

In einem Ein-Markt-Shop ist die compare-at-Mechanik geradlinig. Sobald Shopify Markets mit eigenen Länderpreisen im Spiel ist, wird es heikler. Die gute Nachricht: Der Compare-at price ist je Markt setzbar — über Kataloge bzw. Preislisten (Markets / B2B) mit der Option „Include compare-at price", nicht nur global je Variante. Die schlechte: Genau hier entstehen die typischen Schäden, weil die Per-Markt-Compare-at leicht übersehen wird oder die Feed-Durchreichung Edge-Cases hat:

Sale sichtbar in DE, unsichtbar im UK-Feed. Die compare-at greift im Heimatmarkt, aber im Feed eines Marktes ohne gepflegte Per-Markt-Compare-at fehlt die saubere Differenz — der Streichpreis erscheint dort nicht.
Rundung frisst den Rabatt. Konvertierte und gerundete Preise je Währung können dazu führen, dass die Differenz zwischen Preis und compare-at nach Rundung zu klein wird, um als Sale durchzugehen — oder optisch unsinnig aussieht.

Hinzu kommt die Anzeige-Ebene: Ob „Sale" oder „Angebot" in der jeweiligen Sub-Locale korrekt erscheint und die Währung sauber formatiert ist, gehört zum selben Aktions-Setup. Ein global gedrehter Sale ist also nie ein einzelner Schalter, sondern eine pro Markt geprüfte Kette.

Die Operator-Reihenfolge für eine globale Aktion ohne Code

Wer eine sichtbare Aktion will, baut sie in dieser Reihenfolge — jeder Schritt ist Voraussetzung für den nächsten:

1. Umfang als Collection/Tag definieren, nicht ad hoc je Produkt. Das macht Start, Ende und Rollback überhaupt erst steuerbar.
2. price senken, compareAtPrice = vorheriger Regulärpreis — per Variante, bulk über CSV oder die Admin-API. Niemals compare-at unter den aktuellen Preis setzen; dann rendert Shopify keinen oder einen widersinnigen Streichpreis.
3. Je Markt prüfen, ob Preislisten/Kataloge eine Per-Markt-compare-at tragen und ob die Rundung lokal eine glaubwürdige Differenz ergibt — bevor die Aktion live geht, nicht danach.
4. Channel-Resync abwarten und im Merchant Center diagnostizieren: Steht sale_price je Variante? Greift die Sale-Annotation, oder blockiert die Preis-Historie bzw. der 5–90-%-Rabattkorridor?
5. Preis-Historie respektieren (Google wie PAngV): Der Referenzpreis muss real gegolten haben. Eine Aktion plant man deshalb mit Vorlauf, nicht über Nacht.
6. Aktionsende sauber zurückbauen: price zurück, compareAtPrice leeren. Vergisst man Schritt 6, bleibt ein Phantom-Sale stehen — und ein Dauer-Streichpreis wird entwertet oder geflaggt.

Wann der Code trotzdem das richtige Werkzeug ist

Das ist kein Plädoyer gegen Rabattcodes — es ist eines gegen ihren Fehleinsatz. Der Code ist überlegen, wo compare-at nichts ausrichtet: beim Newsletter- oder Gated-Incentive, im B2B, bei Warenkorb-Schwellen („ab 100 € versandkostenfrei"), bei gestaffelter oder bedingter Logik. Diese Konversionshebel am Checkout kann ein Vergleichspreis schlicht nicht abbilden.

Die saubere Trennlinie lautet deshalb: Der Code ist ein Konversionshebel am Checkout; der Vergleichspreis ist ein Sichtbarkeitshebel im Feed. Wer Reichweite und einen sichtbaren Streichpreis in Shopping will, greift mit dem Code zum falschen Werkzeug — egal wie gut der Code onsite konvertiert. Und wer beides gleichzeitig stapelt (compare-at-Sale plus Code obendrauf), verschenkt Marge an einen Rabatt, den der Kunde gar nicht erwartet hat.

Die kurze Version

Ein Rabattcode wirkt am Checkout und berührt den Produktpreis nicht — deshalb erzeugt er weder einen Streichpreis auf der PDP noch einen sale_price im Google-Feed. Das Sale-Signal bis ins Merchant Center trägt allein der echte Vergleichspreis: Compare-at wird zum price, der reduzierte aktuelle Preis zum sale_price. Sichtbar wird das in der Anzeige nur, wenn der Rabatt im 5–90-%-Korridor liegt und die Preis-Historie ihn trägt. In multi-market-Setups ist die compare-at je Markt über Kataloge/Preislisten zu pflegen und zu prüfen. Der Code bleibt das richtige Werkzeug für bedingte Checkout-Incentives — nur eben nicht für sichtbare Sales in Shopping.

Ihr plant eine globale Aktion, die in den Anzeigen auch wirklich als Sale erscheinen soll — oder ärgert euch, dass eure Rabatte onsite greifen, im Shopping-Feed aber unsichtbar bleiben? Wir richten das Promo-Setup so ein, dass compare-at, Feed und Preis-Historie je Markt zusammenpassen, und prüfen es gegen euer Markets-Setup. Gespräch anfragen. Weiter im Kontext: warum Markets-Preise im Merchant Center verloren gehen und hreflang je Sub-Locale.