Start free

DROPFIND FILTERS · PRESTASHOP

Your filters should not be able
to bring the shop down.

Category filters are your shop's second search engine: plenty of people type nothing at all and reach the product by ticking options. But in PrestaShop that feature is expensive — and the bill does not arrive as slowness, it arrives as a shop that is down on an ordinary Tuesday without anyone having touched a thing.

Dropfind Filters does the same job without asking your database for it.

included in every plan · installs alongside the search

It never touches your databaseThe count on each option comes out of the search index, which is built for exactly that.
It keeps crawlers awayIt marks filtered addresses as non-indexable and adds the rules to robots.txt by itself.
And it does not move the resultsOpening a filter does not push the list down the page: you see the effect as you apply it.
Find out why

Why it falls over, exactly

You do not need to know databases. Every time somebody ticks a filter, your shop does not just look for the products that match: it also recounts how many would be left under each of the other options, so it can show those numbers in brackets. That recount is the expensive work and it happens all over again on every click. With few products you do not notice; the problem is that the possible combinations do not grow gently, they explode.

3filters with 5 values each
215combinations, picking a single value per filter
× 40categories with filters in an ordinary catalogue
8.600distinct addresses a crawler can ask for
every oneforces the whole thing to be recounted from scratch
32.767and that figure was the optimistic one: with multiple selection, those three filters alone

How Dropfind Filters solves it

Four decisions, and none of them is magic: it is moving the expensive work to where it is cheap.

Somebody else does the counting

The numbers on each option are computed by a dedicated search engine that keeps its own index ready for exactly that. Your database never finds out that anyone is filtering, so it stays whole for what matters: the cart and the checkout.

One query per page, not one per product

The product-card data —name, photo, price— does come from your shop, because it has to be exact. But in one single query for the whole page, instead of one per product as the native listing does. On a page of 24 products, that is 24 times less work.

Crawlers stop coming in

Addresses with filters are marked non-indexable, and when you generate the robots.txt from your back office the module adds, on its own, just the rules that keep search engines out of that maze. It is not hiding anything: those pages add nothing to Google's index and they do cost you server.

And what repeats is not recomputed

One and the same filter state always returns the same thing until your catalogue changes, so the answer is kept on your own server. Measured in a real shop: from three queries to the engine down to zero as soon as somebody repeats the combination. And it clears itself when you reindex.

None of this demands touching your theme or giving up your design: the filters anchor wherever you decide and the product cards are rendered with the same template your shop already uses.

Try it right here

A made-up catalogue, real filters. Watch the numbers on each option: they change by themselves and never leave a dead end.

12 of 12 products 0 queries to your database

Filters (12)

The small delay when you tick an option is simulated on purpose: it reproduces the trip to the search engine, which in a real shop does exist.

Your shopper wins too

Removing the technical problem was half of it. The other half is making filtering stop being awkward — because a filter nobody uses saves no server, but it does not sell anything either. Most shop filters push the results off the screen just when you want to see the effect of what you have ticked.

0 jumpsthe results do not move when you open a filter
in a roweach group is a button; its options open on top, pushing nothing
mobilea panel that slides up from the bottom, with the result count on the button
your colourit inherits whatever colour you configure: it looks like part of your shop, not of ours
And an honest warning. The cache saves on repeated traffic, but a crawler walking new combinations pays for every one of them. That is why the rules in robots.txt matter as much as the performance — and why the module also recommends a request limit on your server, which is the only thing that stops whoever ignores those rules.

It is included. It is not an add-on.

Filters comes with every plan, alongside the search: same index, same account, same bill. We do not charge for it separately because it does not cost us separately — it shares the index your search already maintains, so its marginal cost to us is zero.

And because charging separately for precisely the thing that stops your shop falling over would strike us as an odd way to do business.

See the plans Read about search in ecommerce

Ask us anything

If you are unsure whether this fits your shop, write to us. We answer in hours, not days.

We only use what you write to answer you. If you prefer, hola@dropfind.es.

And nobody has to be attacking you

Search engines send out programs that open, one by one, every link on your site. If every filter combination has its own address —and by default it does— they are going to open all of them.

It is not an attack: it is Google doing its job. But your server takes thousands of recounts in a row, and that is why the shop goes down on a Tuesday morning without anyone having done anything odd.

Worse still: that effort gives you nothing back. Those pages add nothing to Google's index —they are variants of a category that is already indexed— so you are paying for server on traffic that does not bring you a single customer.

The technical detail

Every facet count is resolved with aggregate queries —GROUP BY with JOIN— over product_attribute, feature_value and their link tables. They do not cache easily because the result depends on which filters are set, which is exactly what changes on every visit.

On top of that the count has to be disjunctive: within one group the values add up, so that group's numbers have to be computed with every filter applied except its own. That multiplies the queries by the number of groups with a selection.

And the listing that goes with them is usually resolved with one query per product instead of one for the whole page — the pattern known as N+1. On a page of 24 products that is 24 trips to the database where one would have done.