Mass Price Updates: Changing Hundreds of Prices Without Losing Your Mind

Your supplier sends the email every store owner dreads: prices up 8% from the first of the month. You have 400 products. Opening each one in the PrestaShop back office, retyping the price, hitting save, and waiting for the page to reload is a full day of work — and a day in which one mistyped figure quietly ships a €269 product at €26.90. The good news is that PrestaShop gives you several genuine ways to change hundreds of prices at once. The bad news is that each one touches your data differently, and the wrong choice can corrupt your margins, your tax display, or your product feed faster than you can say "undo." This guide is about doing it at scale safely — which method fits which job, and the PrestaShop-specific traps that turn a quick update into a weekend of cleanup.

One thing to get straight before you start: there are two completely different jobs hiding under "change my prices." Permanently raising your base prices (the supplier-increase scenario) is a different operation from running a temporary sale or promotion. The methods below are sorted by which job they're built for — mixing them up is the single most common way merchants make a mess.

The four routes — and which job each one is for

Before any clicking, get the map straight. PrestaShop offers four practical ways to move many prices at once, and they are not interchangeable:

So what? If you reach for a cart rule when you meant to raise base prices permanently, your catalogue still shows the old price everywhere — listings, feeds, comparison sites — and the discount only appears at the very last step. If you edit base prices when you meant to run a two-week sale, you've thrown away the original numbers and have nothing to revert to. Picking the right row first is half the safety.

Method 1: CSV import/export — the workhorse for permanent changes

For a genuine, permanent base-price change across hundreds of products, CSV is the method built for it. The import path is Advanced Parameters → Import on PrestaShop 1.7, 8 and 9. Getting a starting CSV out is less uniform: a product-list Export button exists on some versions and back-office grids but not all, so if your grid doesn't offer it, fall back to a database export, the webservice, or a dedicated export module. The flow:

• Export your catalogue first. From Catalog → Products, use the Export button if your version's product grid offers one; if it doesn't, pull the data via a database export, the webservice, or an export module. Either way you want a CSV of every product as your before-image — save it untouched. If anything goes wrong, re-importing this file restores your old prices.
• Edit in a spreadsheet. The columns that matter are ID (or Reference as the match key), Price tax excluded, and optionally Wholesale price if you track margin. To raise everything 8%, a single formula column — =B2*1.08 — does the whole catalogue. PrestaShop stores and expects the tax-excluded price; the tax-included figure customers see is calculated from the tax rule, so always work in tax-excluded and let PrestaShop add tax.
• Re-import with "update existing." Back in Advanced Parameters → Import, choose entity type Products, map your columns, and crucially tick "Update existing products" and match on ID or Reference. If you skip that checkbox, then depending on how your identifiers map, PrestaShop can create duplicate products instead of updating the existing ones (or simply fail the rows) — a genuinely painful mistake to unwind, which is exactly why you test with a small file first.

Critical safety step: never run the full import first. Cut your CSV down to 5–10 products, import those, then open them in the back office and confirm the prices landed exactly right — including the tax-included display. Only when that test batch is correct do you run the full file. A misplaced decimal or a formula that grabbed the wrong column can set hundreds of prices to €0 or €999999 in the time it takes to read this sentence, and CSV import does it without a second confirmation screen.

One PrestaShop-specific gotcha: the standard product import updates the base price but does not touch combination price impacts or specific prices. If your variants carry their own price adjustments, see the combinations note below.

Method 2: Specific prices — for sales, not permanent changes

If what you actually want is a temporary promotion — a spring sale, a clearance, B2B-only pricing — do not touch base prices at all. PrestaShop's specific price feature exists for exactly this. You can apply it in bulk via Catalog → Discounts (catalogue price rules), or per product under the product's Pricing tab:

• Apply a percentage or fixed discount across a whole category, manufacturer, or supplier in one rule.
• Set a from/to date range so the price reverts automatically — no diary reminder, no "did I forget to put prices back?" the Monday after a sale.
• Target a specific customer group (wholesale, loyalty tier) so the discount is invisible to everyone else.

The payoff is that your base prices stay intact. You never have to remember what the original number was, your margin and cost calculations stay honest, and the product page shows the proper crossed-out "was/now" treatment that signals a real deal. Multiple overlapping specific prices can coexist without you tracking any of it by hand. The discount on whether and how to display that crossed-out price ties straight into pricing psychology — covered separately here.

Method 3: Cart rules — for "X% off everything"

For a blunt store-wide promo ("20% off the whole shop this weekend"), a single cart rule under Catalog → Discounts → Cart Rules is simpler than touching any product:

• Create one rule, with or without a promo code (leave the code blank for an automatic discount).
• Set the percentage and a date range; optionally restrict it to certain categories or products.

The advantage is that it's a single object — no product records change, and you switch the whole promo off by disabling one rule. The trade-off, which catches merchants out: a cart rule applies at the cart/checkout, so the discount does not show on product listings or the product page. Customers see full price right up until the basket. If you want the reduced price visible on the product page itself, that's a specific price (Method 2), not a cart rule.

Method 4: Direct SQL — fast, powerful, unforgiving

Editing the database directly is the fastest possible way to move prices and the easiest way to wreck a store. Under Advanced Parameters → Database → SQL Manager (or straight in the database for the brave), a single statement does the work of a thousand clicks:

UPDATE ps_product SET price = price * 1.08 WHERE id_category_default = 5;

That raises every product whose default category is 5 by 8% in roughly one second — and there is no undo button anywhere. Before you run anything that writes to the database:

• Take a full database backup. This is your only path back. The SQL Manager itself won't save you — use Advanced Parameters → Database → DB Backup (or a real dump from your host) before you write anything.
• Run the SELECT first. Swap UPDATE...SET for SELECT id_product, price with the same WHERE clause and read the result — confirm you're hitting the products you think you are, and only those.
• Don't forget ps_product_shop. This is the classic PrestaShop trap: price is stored in both ps_product and ps_product_shop. On a multi-shop install the front office reads from ps_product_shop, so an update to ps_product alone changes nothing your customers see. Update both tables.
• Clear the cache afterwards. PrestaShop caches product data heavily; old prices linger in Smarty and full page cache until you flush them (see the checklist below).

This route is genuinely for developers comfortable with PrestaShop's data model. If "ps_product_shop" was news to you, use CSV instead — it's nearly as fast and it can't silently desync your tables.

The combinations trap most bulk updates miss

Products sold in variants — sizes, colours, models — store their price impacts separately, in ps_product_attribute (and ps_product_attribute_shop on multi-shop). When you raise a base price, the combination impact stays fixed: bump the base 8% and the "XL is +€2" surcharge is still a flat +€2, not +€2.16. Whether that's correct depends on your pricing, but it's a decision you have to make deliberately — a base-price CSV import will not scale those impacts for you, and forgetting them is how a "finished" price update leaves half your variants wrong. If you're still deciding whether your catalogue should even use combinations versus separate products, that's its own choice — we cover it here.

Rounding: decide before you import, not after

A percentage increase produces ugly numbers — €24.99 × 1.08 = €26.9892 — and PrestaShop will store more precision than a shopper ever sees (the displayed price is constrained by your currency's precision and rounding settings, so customers won't normally be shown the raw "26.9892"). Even so, settle your rounding rule in the spreadsheet, before import, to control the final displayed price yourself rather than hoping the platform tidies up: round to .99 for psychological price points, to the nearest .50 for clean tickets, or to a whole number. The reason this matters beyond tidiness is that the specific price point you land on measurably affects conversion — the psychology of pricing is a topic in its own right, and "26.9892" helps nobody.

Watch the tax direction too. Because you edit tax-excluded prices but customers see tax-included ones, an 8% rise on the base shows up as a slightly different visible jump depending on the tax rule attached to each product. After any bulk change, eyeball the customer-facing tax-included price on a few products, not just the back-office figure.

Timing and communicating a price rise

Mechanics aside, a price increase is a customer-relations moment, and a few habits keep it from costing goodwill:

• Give B2B customers and subscribers advance notice — "prices rise on the 1st, order now at current rates" both softens the change and pulls some orders forward.
• Run the update in low-traffic hours so the fewest possible customers are mid-browse while prices shift under them.
• Honour carts already in flight for a short grace period — a customer who added an item at the old price and comes back to a higher one at checkout is a likely abandonment.
• Refresh your comparison feeds immediately. Stale prices in Google Shopping or comparison engines mean customers click an old low price and arrive at a higher one — a trust hit and, increasingly, a feed-disapproval risk. The same data discipline applies to the stats you surface on-site, like live sales and views counters.

Post-update checklist

Whatever method you used, never call a mass price change "done" until you've walked this list:

• Manually verify 10–15 products spread across different categories, manufacturers and price bands.
• Check both the tax-excluded (back office) and tax-included (front office) figures.
• Confirm combination prices are still correct — the trap above.
• Clear the caches in play: PrestaShop's cache and Smarty cache, plus any theme, module, server, CDN, or full page cache layer you run — old prices survive in cache until you do.
• Regenerate your product feeds (Google Shopping and any comparison engines).
• A few days later, review your financial reports to confirm margins landed where you intended.

When you do this every month

The CSV and SQL routes are fine for an annual catalogue-wide rise. They get tiresome fast if you re-price constantly — seasonal supplier changes, currency swings, margin tuning by supplier. That repetition, and the combination/rounding/tax traps that make each run risky, are exactly what our Mass Price Updater module is built to remove. So what does it actually do for you? It applies percentage or fixed changes, your chosen rounding rule, and selective targeting by category, manufacturer or supplier — from one screen in the back office, with the combination and multi-shop tables handled for you rather than left as a gotcha. The point isn't speed for its own sake: it's that the operation that could set 400 prices to zero becomes one you can run on a coffee break without holding your breath.

Whichever route fits, the principle is the same on PrestaShop specifically: know which job you're doing (permanent base price versus temporary discount), know that price lives in more tables than you'd expect, test on a handful before you commit, and keep the before-image so "undo" always exists. Do that, and changing hundreds of prices stops being the day you dread and becomes a ten-minute task you trust.