Somewhere around mid-June, the dashboard that looked so healthy in spring starts to feel uncomfortably quiet. Traffic thins, orders slow, and the instinct kicks in: cut prices, fire off another email, do something. This guide is about that exact moment. What to actually do in your PrestaShop back office when summer sales drop, and, just as importantly, what not to do. It is deliberately practical: real settings, real SQL, real tasks you can knock out while the store is quiet. For the bigger-picture case that a slow season is an opportunity rather than a threat, see our companion piece, turning low season into opportunity.

First, confirm it's actually the slump. Not a bug

A sunny beach scene with an umbrella and sunglasses beside a downward-stepping bar chart on the sand, illustrating a seasonal summer dip in online store sales
A summer dip is usually the season, not a broken store - confirm which before you react.

Before you react to a sales drop, rule out the unglamorous possibility that something is broken. A summer dip arrives gradually and broadly; a technical fault arrives suddenly and narrowly. Spend ten minutes confirming which one you have:

  • Check the order trend, not a single bad day. In the back office, open Stats (or Sell → Stats on 1.7+) and look at the Sales and orders graph over the last 90 days. A clean downward slope from late spring is the slump. A cliff edge on one date is a problem to fix.
  • Verify checkout still works. Place a real test order end to end. A silently broken payment module looks identical to a slump on the dashboard. While you're there, confirm your carrier prices still calculate. A misconfigured weight range can zero out shipping options and kill conversion without an error message.
  • Look at the funnel, not just the total. If traffic is steady but orders fell, the leak is on-site (checkout, stock, a price glitch). If traffic itself fell, it's genuinely fewer people shopping, the real seasonal pattern. If you're not sure where customers drop off, start with the diagnosis in why your checkout page is losing you sales.

Once you've confirmed nothing is broken, you can stop treating the dip as an emergency. Almost every store that isn't selling swimwear, outdoor gear, or travel kit sees softer summer numbers as customers spend on holidays and experiences instead of online orders. The size of that dip varies a lot by niche, don't anchor on a number you read somewhere; measure your own store year over year (more on that at the end).

The biggest mistake: panic discounting

When orders slow, the loudest temptation is to slash prices. It feels like action. But reflexive discounting during a naturally quiet period is one of the more expensive habits in e-commerce, and the damage compounds:

  • It trains customers to wait. Run a deep summer sale every year and your regulars learn to postpone purchases until July. You've converted full-price buyers into discount-waiters, permanently.
  • It erodes margin when you can least afford it. You're selling cheaper across fewer orders, so each fixed cost (hosting, staff, rent) is spread thinner. The math is worse than it looks.
  • It attracts deal-seekers, not loyalty. Discount-driven buyers rarely return at full price. You pay to acquire your least valuable customers.

None of this means "never discount in summer." A small, deliberate, time-boxed promotion is fine. The difference is intent. A planned campaign is a decision; a desperate price cut on a slow Tuesday is a reflex. If you do run something, do it properly with the tools PrestaShop gives you rather than blanket-slashing the catalogue, the mechanics (cart rules vs. specific prices, when to use each) are covered in running a sale in PrestaShop. And protect your margin-critical and premium lines from any sale at all, discount exclusion explains how to fence them off.

The better play: use the quiet to fix the store

Here's the reframe that separates the merchants who come out of summer stronger. Low traffic is the one thing you can't buy: a window where you can change your store without disrupting many customers, and where a botched deploy costs you ten orders instead of a thousand. Treat the slow weeks as your maintenance window. The list below is the work that's genuinely hard to do in Q4, and genuinely PrestaShop-specific.

Clean the database that's quietly slowing you down

PrestaShop accumulates cruft. Guest carts that never converted, expired cart rules, stale connection logs and orphaned guest rows pile up in tables that every page query touches. By summer they're often the single biggest drag on admin speed and a real one on the front end. The quiet season is when you can prune safely. Take a full database backup first, work on staging if you can, then address the usual offenders:

  • Abandoned guest carts. The ps_cart table fills with carts that were created and never ordered. A guest cart from eight months ago has no value. Clearing old, order-less carts (and their ps_cart_product rows) is one of the highest-impact cleanups.
  • Expired cart rules. Last year's promo codes still sit in ps_cart_rule, cluttering the admin and the database even though PrestaShop filters them out by their validity dates and active status. Review the dead ones in Catalog → Discounts (or Cart rules) and archive or clean up the ones you no longer need rather than just leaving them disabled to pile up.
  • Stats and connection logs. ps_connections, ps_connections_page, ps_guest and ps_statssearch grow without bound on a busy store. If you don't lean on PrestaShop's built-in stats, these are safe to trim hard.
  • Old search and log tables. ps_log (the admin log) and search index tables rarely get pruned. Truncating old log rows is harmless and frees space.

If you're comfortable in phpMyAdmin or Adminer, this is an afternoon. If you'd rather not write SQL by hand, a database-cleanup module that targets exactly these tables, with a backup-first, preview-the-rows workflow, turns it into a few clicks from the back office: that's what our Database Cleanup module is built for, and the quiet season is the right time to run it. The benefit is concrete: faster admin pages, smaller backups, and queries that don't drag a year of dead carts behind them every time someone loads a category.

Fix what's slow before the autumn traffic arrives

A speed problem you tolerate at summer volumes becomes a conversion problem at Q4 volumes. Use the slow weeks to find and fix the root causes while a botched cache rebuild only inconveniences a handful of visitors:

  • Turn the production caches back on, properly. Stores often run all summer with Smarty caching, the filesystem combine/minify, and the production environment half-configured because someone was "just testing." Confirm Advanced Parameters → Performance has Smarty set to Never recompile, caching on, and CCC (Combine, Compress and Cache) enabled for CSS/JS. If you run PHP with OPcache, make sure it isn't being blown away on every deploy.
  • Profile the real bottleneck. Enable the Debug profiling view (config/defines.inc.php, _PS_DEBUG_PROFILING_) on a staging copy and load a product and a category page. It shows you which hooks, modules and SQL queries actually cost the time, usually it's one or two modules running unindexed queries, not "PrestaShop being slow."
  • Audit your modules. Every installed module hooks into page rendering whether you use it or not. Summer is the time to uninstall the ones you abandoned and update the rest. On staging first, never live during a season you can't afford to break.

Build the content you never have time for

When you're not firefighting daily orders, you finally have hours for the work that pays off slowly: product descriptions that sell rather than list specs, buying guides that help customers choose between similar SKUs, proper product photography, and FAQ pages that cut your support load before the busy season. Blog content written in July is indexed and earning organic traffic by the time autumn demand returns. The lag is the whole point of doing it now.

Revenue moves that fit a slow season, without a fire sale

Avoiding panic discounting doesn't mean sitting on your hands. There are ways to lift summer revenue that don't train your customers to wait or torch your margins:

  • Bundle slow-moving stock instead of marking it down. Grouping a slow product with a popular one moves inventory and raises average order value without publishing a lower price on either item, so you protect the perceived value of both. The PrestaShop mechanics (and where bundling beats a straight discount) are in product bundling.
  • Sell gift cards. Holiday-makers and gift-givers buy ahead. A digital voucher is revenue collected now against a purchase made later, and it brings a new customer to you when it's redeemed. Gift cards for PrestaShop covers adding them to your store.
  • Court the gift-giver, not the holidaymaker. Your core customer may be on a beach, but the person buying for them isn't. Reposition relevant products as gifts for upcoming summer occasions, weddings, birthdays, Father's Day in some markets.
  • Run a B2B or pre-order push. Business buyers planning Q4 are deciding now; a well-timed outreach can lock in large orders for autumn delivery. Pre-orders for autumn lines turn quiet-season interest into committed revenue.

Get your Q4 promotions built now, while you have the calm

The single most valuable use of the slump is preparation. The stores that win Black Friday and the holidays are the ones that built their campaigns in July, not the ones improvising in November. Crucially, PrestaShop lets you create promotions in advance and have them activate on a schedule, so "build now, launch later" is a real workflow, not a metaphor: a cart rule has valid-from and valid-to dates, and specific prices carry their own date range. Set them up now and they sit dormant until their start date.

Rather than re-explain those mechanics here, they each deserve a full treatment, here's the map to the relevant playbooks so you can build your autumn calendar this week:

If you'd rather not hand-build and date every promotion, an automated flash-deals module lets you queue summer and autumn campaigns from the back office and have them run on schedule. We built one for exactly this kind of "set it in July, let it fire in November" planning: Sales Revolution. And the banners those campaigns need don't require a designer, see creating promotions without a designer.

Measure the slump correctly, or you'll panic over nothing

The way most merchants read summer numbers is the way that creates the panic in the first place: they compare July to June, see the drop, and react. That comparison is meaningless, because June-to-July is supposed to fall. The only comparison that tells you anything is year over year.

  • Compare like seasons. Ask whether this July beat last July, not whether it beat this June. That single change tells you if the business is actually growing, slump and all.
  • Use enough data to mean something. A bad three days is noise. Look at trends over weeks before drawing any conclusion, especially before reverting a change you just made.
  • Check weekly, not daily. Refreshing the dashboard every morning of a naturally slow period generates anxiety, not insight. Set up a clean view of the handful of metrics that matter, orders, conversion rate, average order value, traffic source, and look at it once a week. Constant monitoring of a quiet season produces nothing actionable; it just makes the slump feel worse than it is.

Summer slump FAQ

How much should sales actually drop in summer?

There's no universal figure, and any number you read online is someone else's niche. The dip ranges from barely noticeable to 30%+ depending on what you sell. A swimwear store may peak in summer while a B2B office-supplies store goes quiet. The only honest answer is your own: compare this July to last July, not this July to this June. If you don't have a year of history yet, note this season's pattern now so next year's comparison means something.

Is it ever right to discount during the summer slump?

Yes, when it's a planned, time-boxed campaign rather than a reflex. A scheduled three-day promotion with start and end dates is a decision; slashing prices on a slow Tuesday because the dashboard looks grim is panic, and it trains your regulars to wait. If you do run something, fence off your margin-critical and premium lines first, and prefer bundles or free-shipping thresholds over blanket percentage cuts.

Which database tables are safe to clean during the quiet season?

Take a full backup first, then the usual safe targets are old order-less guest carts (ps_cart / ps_cart_product), expired cart rules you'll never reuse (ps_cart_rule), and stats/connection logs (ps_connections, ps_connections_page, ps_guest, ps_statssearch, ps_log). Never truncate orders, customers, products or configuration. Work on staging if you can, and preview the rows before deleting. Which is exactly the backup-first workflow a cleanup module enforces for you.

When should I build my Q4 promotions?

During the slump, that's the single highest-value use of the quiet weeks. PrestaShop cart rules carry valid-from / valid-to dates and specific prices have their own date ranges, so you can build a Black Friday or holiday campaign in July and have it sit dormant until its start date. The stores that win the year's heaviest traffic are the ones that built calmly in summer, not the ones improvising in November.

How often should I check my numbers during a slow season?

Weekly, not daily. Refreshing the dashboard every morning of a naturally quiet period produces anxiety, not insight. A bad three days is noise. Set up a clean view of orders, conversion rate, average order value and traffic source, look at it once a week, and judge trends over weeks before reverting any change you just made.

The summer slump ends. It always does. The merchants who come out of it strongest are the ones who spent the quiet weeks shipping a faster store, a cleaner database, fresh content, and a fully built Q4 calendar, instead of refreshing the dashboard and reaching for the discount button. The dip isn't the problem to solve. What you build during it is the whole point.

David Miller

David Miller

Founder, mypresta.rocks
About the author

David Miller is a PrestaShop specialist with over a decade of hands-on experience and the founder of mypresta.rocks, a software studio in Tychy, Poland. He builds and maintains a catalogue of 159 PrestaShop modules, including 21 "Revolution" suites spanning SEO, checkout, security, performance, marketing, search, support, and warehouse operations, that improve real stores every day, all tested against PrestaShop 1.7.8, 8.x, and 9.x. He also looks after live production stores, so his work is judged on real sales, not demos. His experience runs the full breadth of ecommerce, performance, security, SEO, and marketing, and reaches beyond PrestaShop to WooCommerce, Shopify, and custom-built systems. On the blog he writes about the code-aware side of PrestaShop: what the platform really does under the hood, what breaks in production, and which fixes hold up.

Share this post:

Comments

No comments yet. Be the first!

Enjoyed this article?

Get our latest tips, guides and module updates delivered to your inbox.

You may unsubscribe at any moment. For that purpose, please find our contact info in the legal notice.

Loading...
Back to top