Bots and PrestaShop faceted search: 100 % CPU and downtime

Saturday afternoon. An email arrives from your host warning that your account has been at 100 % CPU for hours. You open your stats expecting a flood of customers and find the opposite: forty thousand page views and zero orders.

It is not an attack, not a broken module, not your shop doing something odd. Somebody has started walking through every single filter in your catalogue, one by one.

What is actually happening

Your shop has faceted search: size, colour, brand, price, availability, plus the sort order on top. It is what makes it comfortable to use.

The problem is that every combination of those filters is a different web address. Size M in blue from one brand sorted by price is one. Size M in blue from that brand sorted by newest is another. And so on through every possible combination: on a mid-sized shop that runs into hundreds of thousands; on a large one, millions.

The crawlers of the social networks and of the AI services —Facebook's, TikTok's, half a dozen companies you have never heard of— have decided they need to see all of them. And they request all of them, at once, without pausing.

Each of those addresses is not a page you have stored: it is a fresh search against your database.

The module behind it: PrestaShop's Faceted search

Your shop's filters are drawn by one specific module, Faceted search (ps_facetedsearch), the one shipped with PrestaShop since 1.7 that replaced the old Layered navigation. If you have filters on your category pages, you have it enabled.

Spotting it in your logs is easy: every combination travels in the q parameter of the address, looking like this.

/12-tshirts?q=Size-M/Colour-Blue/Brand-Adidas

If your access log shows thousands of lines with ?q=, all different and back to back, you know what is eating the machine.

And here is why it is so expensive. When one of those requests arrives, the module does not only look for the products matching the filter: it also recalculates the counters for every other filter —that «Blue (12)», «Green (5)» next to each checkbox— and to do so it fires several counting queries against its index tables. Multiply that by a large catalogue and by thousands of requests a minute.

Two levers that live in the module itself and almost nobody touches, under Catalogue → Faceted search:

• Turn off the product count next to each filter. It is the most expensive part of every request and, in most shops, the one nobody misses.
• Review the filter templates per category. Every filter you leave in multiplies the possible combinations. Eight filters in a category are not eight addresses: they are thousands.

Neither fixes the problem on its own, but both lower the cost of each hit before you touch anything else.

Why it hurts so much

A filtered search is one of the most expensive things a shop does: it has to go through the whole catalogue, cross-reference attributes, count how many products are left under each filter and sort the result. A customer runs three or four in an entire visit. A crawler runs three or four a second.

And here is the part that throws everyone: caching does not save you. Caching helps when many visitors ask for the same thing. Here nothing repeats: every combination is unique, so they are all «first visits» and they all go through to the database.

The outcome is always the same. Requests pile up, the server runs out of room and the shop stops responding — to the robot and to the customer who was about to pay. If it lands mid-campaign, you have paid for ads pointing at a site that would not open.

How to tell whether this is you

Four signs, and any two together make it near certain:

• High usage with no sales. Enormous page views, no baskets. Visits and orders do not match, not even close.
• Your host warns you that you are consuming too much, or suspends the account for a while «to protect other customers».
• It goes down at odd hours: in the small hours, on a Sunday, in random bursts with no commercial pattern.
• The access log shows thousands of consecutive addresses with filter parameters, all different, requested within seconds.

If the admin panel is slow while it happens, that is your confirmation: it is not the public side, the machine is saturated. We covered it in when slowness is the shop and when it is the server.

What you will be told to do, and why it falls short

This problem attracts a lot of popular fixes that do not hold up in practice:

1. «Block them in robots.txt». That file is a polite request, not a door. The crawlers that respect it are not your problem; the ones bringing you down do not read it. And if you overdo it, the one that obeys is Google, and you have wiped yourself off the results.
2. «Block Facebook and TikTok by name». It works for a week. They change identity, come in from thousands of different addresses, and three new ones appear every month. It is a list you never finish maintaining.
3. «Just mark them as noindex». A page carrying a noindex tag still costs you: the robot has to request it to read that tag in the first place. It helps the search engine, not your CPU.
4. «Get a bigger server». Paying twice as much to serve your catalogue to a robot for free is a bad deal: the next spike will be larger, because the better you respond, the faster they ask.
5. «Turn off faceted search». It fixes the load and breaks the shop: filters are how people find what they are going to buy. You see it in conversion the next day.
6. «Put a CDN in front and be done». A CDN speeds up what repeats. Here nothing repeats: every combination is unique and reaches your database anyway.
7. «Switch on under-attack mode». Either you make it hard for your customers and for Google too, or the robots keep coming through. It gets you through an afternoon, it is not a way to live.

They all share the same flaw: they treat the symptom, which is the traffic, instead of the cause, which is that your shop is willing to manufacture millions of different pages for anyone who asks.

Where the real fix lies

What actually holds is built in three layers, and none of them means switching filters off:

• Decide which combinations exist. Of all the ones your shop could generate, only a handful make sense to a customer or to Google. The rest do not need addresses of their own, and taking that away shrinks the playing field from millions to a few thousand.
• Keep the expensive stuff from reaching the bottom. Requests that are noise get answered before they touch the database, and there is a limit on how many searches a minute one source can fire. A customer runs three; whoever runs three hundred is not a customer, whatever they call themselves.
• Separate who competes for resources. Crawling should never fight for the same CPU as somebody's checkout. Built properly, the robot can wait; the customer cannot.

With that, usage normally drops sharply on day one and the shop stops falling over, without touching a single filter as far as customers are concerned and without losing ground on Google. Quite the opposite: once you stop spending Google's time on four hundred thousand repeated pages, it starts looking at the ones you care about — which is exactly what we covered in where to start when you do not show up.

If you have been fighting this for months

It is a nasty problem because it never shows its face: there is no error to look at, just a shop that works some days and not others, and a host telling you it is your fault.

If you have already tried a couple of the fixes on that list and you are still where you started, write to us. We go through your logs, tell you how many of those requests are real and how many are noise, and leave the filtering in place and measured. We have done it a fair few times and it shows on day one.

Tell us about your case