Running a sale on ten products is straightforward. Running one across thousands of variants is a data-management project.
The difficult part is not entering a lower price. It is preserving original prices, handling products already on sale, avoiding accidental extra discounts, and restoring the correct values afterward.
The most reliable workflow is to treat a promotion as a controlled pricing change: export a baseline, calculate the intended values, test a small batch, apply the update, verify the results, and restore from the saved baseline.
Here is how to build that process without turning every sale into hours of manual editing.
- Understand what creates strikethrough pricing
Shopify separates the actual selling price from the reference price.
Price is the amount the product sells for before any applicable additional discounts. Compare-at price is the higher reference amount used to display the price comparison.
For a product reduced from $100 to $80:
Price: 80.00
Compare-at price: 100.00
The compare-at price must be higher than the price to display a sale comparison. Your theme controls how that comparison appears on product and collection pages.
Setting only the compare-at price does not lower the selling price. Likewise, creating a discount code is not the same as changing these two fields.
Choose the mechanism that matches the promotion: use sale prices for an explicitly reduced catalog price, or discounts for offers governed by discount eligibility and checkout rules.
- Define how existing sale prices should behave
Before calculating anything, decide what happens to variants already discounted.
Consider this starting point:
Current price: 80.00
Compare-at price: 100.00
Campaign: 20% off
“20% off” could mean reducing the current selling price to $64, keeping the existing $80 sale price, or excluding the variant entirely.
Those are different campaigns.
For a straightforward first workflow, exclude already-discounted variants unless the promotion specifically includes them. It reduces ambiguity and makes rollback easier.
Also define the eligible products, discount rate, rounding method, minimum permitted price, start and end times, and treatment of other active offers.
Do not automatically overwrite an existing compare-at price with the current selling price. That can change the meaning of an existing price comparison.
- Create an immutable pre-sale snapshot
Export the relevant product data before editing it. Keep that original export untouched.
Maintain a separate working document with the original values and planned changes. A planning sheet might contain:
Product identifier
Variant identifier or option combination
SKU
Original price
Original compare-at price
Campaign price
Campaign compare-at price
Include in campaign?
Validation result
This is a planning structure, not a Shopify import template.
For a native product CSV, retain the identifiers and option columns required by Shopify’s current format. SKU is useful for review, but native product CSV updates should not be treated as SKU-only updates.
Preserve blank compare-at prices accurately. A blank value and 0.00 are not interchangeable.
The snapshot gives you the exact starting state, including products that were already discounted before the campaign.
- Calculate prices in a spreadsheet, not one variant at a time
For a percentage reduction, calculate the campaign price from the saved baseline.
If the original selling price is in cell D2 and the discount rate is in H1:
=ROUND(D2*(1-$H$1),2)
For a 20% discount on $100, the result is $80.
This example assumes a currency using two decimal places. Adapt rounding to the currency and your merchandising rules.
For an eligible variant with no existing sale:
Campaign price = original price × (1 − discount rate)
Campaign compare-at price = original price
Keep the source columns separate from calculated columns. Otherwise, it is easy to apply the same discount twice.
For example:
Baseline: 100.00
First run: 80.00
Accidental rerun: 64.00
A repeatable process always calculates from the immutable baseline, not from whichever price happens to be live.
- Choose the right bulk-editing method
The native bulk editor works well for a manageable selection or a small correction. It supports editing product and variant properties, including price and compare-at price.
For thousands of variants with different calculated values, a spreadsheet and CSV workflow is generally easier to audit.
Keep the bulk editor for exceptions. Use a prepared import for the main campaign.
If your team uses a bulk-import tool, follow that tool’s own identifier, update, and blank-value rules. Do not assume its spreadsheet format behaves like Shopify’s native product CSV.
Scheduling is another separate requirement. A CSV containing prices is not itself a timed campaign or an automatic rollback mechanism.
- Prepare a narrowly scoped import
The safest import changes only the intended pricing fields while retaining the required product and variant matching information.
Start from a fresh Shopify export and preserve its supported headers. Do not add planning columns such as “Discount percentage” or “Rollback status” to the upload file.
Keep that analysis in a separate worksheet.
For native CSV updates, Shopify documents several important behaviors:
A blank included field can overwrite an existing value as blank. An omitted optional column generally leaves that field unchanged, subject to required dependencies. Variant-related fields depend on the correct option data.
Changing option values can recreate variant IDs and break integrations that depend on them. Do not rename sizes, reorder options, or clean up variant structures during a price-only import.
Exclude unrelated image and inventory fields where the format permits. An unnecessary column creates another opportunity for an unintended change.
Save the final CSV with UTF-8 encoding, then review it independently from the calculation sheet.
- Test representative products before the full import
Choose a small pilot group that includes different pricing situations: a single-variant product, a multi-variant product, an already-discounted item, and a product excluded from the campaign.
Apply the pilot and verify the actual stored values.
Then inspect the customer experience. A correct import does not guarantee that every theme component displays the comparison correctly.
Check the product page, variant selector, collection card, search result, cart, and checkout.
Collection cards deserve particular attention. Inconsistent compare-at pricing across variants can prevent a product-level sale display even when an individual variant displays correctly.
Do not force every variant to the same price just to produce a consistent badge. Fix the presentation or campaign eligibility without introducing inaccurate pricing.
Native product CSV imports cannot be canceled once they begin, which makes the pilot especially important.
- Check additional discounts before launch
A sale price is not automatically protected from further discounts.
Suppose a product has:
Compare-at price: 100.00
Sale price: 80.00
Eligible code: 10% off
The code can reduce the $80 selling price to $72.
This is not simply a question of whether two discount codes can combine. The reduced product price is already the selling price before the eligible code is applied.
Test actual checkout scenarios with active codes and automatic discounts. If further reductions are not intended, adjust discount eligibility or the campaign design.
Also inspect any fixed market prices relevant to the campaign. Fixed prices can override the base price and compare-at price, so a base-catalog update is not proof that every market shows the intended sale.
- Apply the full update and reconcile the results
After the pilot passes, apply the production update and review import errors.
Do not assume the whole catalog changed successfully because the import started or a few products look correct.
Re-export the affected products and compare actual values with the campaign plan:
Expected campaign price = actual price
Expected compare-at price = actual compare-at price
Investigate mismatches before promoting the sale heavily.
Avoid overlapping price writes from staff, supplier feeds, ERP systems, or other integrations during the update window. Otherwise, one system can overwrite another and leave you with a partially applied campaign.
For a large catalog, allow an operational window for updates and verification rather than assuming every variant changes at exactly the same second.
- Restore original values without overwriting later decisions
Prepare the rollback before the sale starts.
Do not calculate the original price by dividing the sale price by the discount factor. Rounding can make that inaccurate, and the method cannot reconstruct an originally blank compare-at price.
Restore the exact saved values for both fields.
For example:
Before sale:
Price: 100.00
Compare-at price: blank
During sale:
Price: 80.00
Compare-at price: 100.00
After rollback:
Price: 100.00
Compare-at price: blank
For additional safety, compare the current values with the campaign values before restoring:
If current values match campaign values:
Restore the saved baseline
Otherwise:
Flag the variant for review
This avoids blindly overwriting a legitimate price change made during the promotion. In a spreadsheet workflow, perform that comparison against a fresh export before preparing the rollback file.
Restore only the intended pricing fields. Reimporting the entire old product snapshot can also overwrite unrelated catalog changes made during the sale.
The recommended workflow
Use the native bulk editor for small changes and a validated spreadsheet-driven import for large campaigns.
The repeatable process is:
Define campaign rules
→ Export and preserve the baseline
→ Calculate prices
→ Validate the import
→ Test representative variants
→ Apply the campaign
→ Reconcile stored prices and storefront behavior
→ Restore the saved baseline with conflict checks
Strikethrough pricing becomes much easier to manage when it is treated as a controlled data operation rather than a long editing session. The biggest time saver is not faster typing. It is having an accurate launch file, a tested rollback, and a clear record of what should change.