Shopify now shows compare-at prices to AI agents. Is yours right?
Shopify Catalog shares eligible compare-at prices with AI shopping agents as a list price. What makes one eligible, and how a sale app should set it.
By Beacon Wave Studio · · 7 min read
On 9 October 2026 Shopify's changelog carried a short entry with a long tail: compare-at prices are now shared with agentic channels through Shopify Catalog. In plain terms, when an AI shopping agent asks Shopify about one of your products, it can now be told not only what the product costs but what it used to cost, or is supposed to cost, as a list price. That is the number you type into the Compare-at price field.
We wrote earlier about whether agents see your sale price or your full price. This is the other half of the same question. The agent now gets two numbers, and the gap between them is how it decides whether to tell a shopper "this is on sale". For a sale app like SafeSale, which writes that second number, it is worth being precise about what it does and when.
What Shopify shares, and when
The developer-facing side of the change, documented in the Catalog API changelog, maps compare-at to a field called list_price on each variant, and gives products a list_price_range across their variants. Three conditions apply before an agent is shown it:
- The mapping is on. It is a toggle in the Shopify Catalog product data mapping, under Sales channels. Shopify says it is on by default for most stores and off by default for stores that appear to use compare-at as a manufacturer's suggested price rather than a sale marker.
- Compare-at is higher than the price. A compare-at equal to or below the selling price is not shared. Shopify does not want to tell a shopper "was 20, now 20".
- The buyer's region allows it. Shopify mentions hiding the field for buyers in the European Economic Area, where reference price rules are stricter.
Only the second condition is about your data. The first is a setting, the third is Shopify's. So the practical question for a merchant becomes: is every compare-at price on the store either empty or honestly higher than the price? On a catalogue that has been through a few years of sales, imports and theme changes, the answer is usually "mostly".
What SafeSale writes to compare-at
SafeSale has two ways to run a sale, and they treat compare-at differently.
In price rewrite mode, the app changes the variant itself. When the sale starts, each selected variant's price becomes the discounted price and its compare-at becomes the price it was selling at a moment earlier. The pair that Shopify Catalog now reads is therefore always "was X, now less than X", which satisfies the higher-than-price condition by construction. There is no way for the app to produce a compare-at equal to the price, because the compare-at is the pre-sale price and the price is strictly lower.
In automatic discount mode, SafeSale creates a Shopify discount with a Function and does not touch the variant at all. Price and compare-at stay exactly as you left them. If your compare-at values are blank, agents reading the catalogue see a single price and no list price. The earlier comparison of the two modes goes into when each is the right choice; the new wrinkle is that the price rewrite mode is the one that gives agents a visible before and after.
Variants that already have a compare-at
This is where most stores have something to look at. Say a variant sells at 40 and already carries a compare-at of 50 from last season. You put it on a 25 percent sale in price rewrite mode. The price becomes 30. What should compare-at say?
SafeSale sets it to 40, the price the variant was actually selling at when the sale began, not to 50. The old 50 is saved in the sale snapshot, and when the sale ends the variant goes back to price 40 and compare-at 50, exactly as it was. The confirm step lists each variant where an existing compare-at will be replaced, and separately flags any variant whose existing compare-at is already lower than its price, because that is a data problem the sale would otherwise paper over for a week and then put back.
Why 40 and not 50? Because 50 was not the price anyone paid last month. A compare-at of 50 next to a sale price of 30 tells a shopper, and now an agent, that the discount is 40 percent when the real reduction from the going price is 25. Reference pricing rules in several countries define the "was" price as the lowest price charged recently, and an agent that quotes your discount percentage to a shopper is repeating your claim on your behalf. Keeping compare-at tied to the real pre-sale price is the conservative choice.
When the sale ends
Restoring is as important as setting. A sale that writes compare-at and never clears it leaves a permanent "was" price on the variant. Before this month that was a storefront problem; now it is also a line in every agent's view of your catalogue. SafeSale's end-of-sale job restores price and compare-at from the snapshot, including restoring compare-at to empty where it was empty before. The snapshot CSV has a column for the original compare-at of every variant, so if you ever need to audit what the store looked like before a sale, it is one file.
A short checklist
- Open Sales channels, find the Shopify Catalog mapping and see whether the compare-at field is switched on for your store. Decide deliberately. If compare-at means MSRP on your store, you may want it off, and you should run sales as automatic discounts so a sale never rewrites it.
- Find variants where compare-at is equal to or lower than price. Shopify will not share them, which is harmless, but they are also wrong on your storefront. SafeSale's confirm warnings catch the ones inside a sale; a product export sorted by the two columns catches the rest.
- For stores that run price rewrite sales, check that the last sale restored compare-at properly. A variant that shows a compare-at with no sale running is the sign.
- Going forward, let the sale app own compare-at during a sale and nothing else. The fewer hands that touch the field, the more the "was" price an agent repeats is one you can stand behind.
None of this is new advice. What is new is the audience: a compare-at price used to be read by people looking at your product page, and now it is read by software that summarises your store to people who may never see the page. The number should be one you would be happy to have read out loud. If you want a sale app that sets it from the real price and puts it back afterwards, that is what SafeSale was built to do.
Frequently asked questions
Does SafeSale set the compare-at price when it starts a sale?
Yes, in price rewrite mode. Each variant's selling price becomes the sale price and its compare-at becomes the original selling price, so the pair reads as was and now. In automatic discount mode nothing on the variant is written at all, so price and compare-at stay exactly as they were.
My variants already have a compare-at price. What happens to it during a SafeSale sale?
The original compare-at is kept in the sale snapshot, replaced for the length of the sale by the pre-sale selling price, and written back when the sale ends. The confirm step shows a warning for every variant where that happens so you can decide before anything changes.
Shopify says compare-at is only shared with agents when it is higher than the price. Why would it not be?
Usually because of a leftover: a manual markdown that was reverted on price but not on compare-at, or a CSV import that put the same number in both columns. SafeSale flags compare-at values that are lower than or equal to the price at confirm time, and its snapshot CSV lists every compare-at so you can find the odd ones.
We use compare-at as the manufacturer's suggested price, not as a sale marker. Should we change anything?
Shopify's announcement says the mapping is switched off by default for stores it identifies as using compare-at that way, and the toggle lives in the Shopify Catalog product data mapping. Check it. If you keep compare-at as MSRP, run sales as automatic discounts so a sale never overwrites that figure.