What one search takes on a real catalogue of 1,859 products.
PRESTASHOP · TYPESENSE
A search engine
you can audit.
See where every result comes from and tune it yourself. It installs like any other module and answers as you type.
no card · uninstalls in one click
- 9 msper search
- 0,6 %of CPU at full load
- 1.7.6 – 9.0PrestaShop
- 7.3 – 8.4PHP
how it sits on a shop · two integrations, on a loop
Of CPU with the server at full load. That copy of your catalogue lives entirely in memory, on our servers: when someone searches, ours is the machine that works. Yours only paints what already comes solved.
What it is built with
Nothing exotic, and nothing your hosting does not already have. The only new piece is the search engine, and we host it.
And it tells you what they searched for and did not find.
Every search with no results is recorded. It is the literal list of what your customers came to buy and was not in the catalogue —or was, under another name.
What it does, plainly
Three things Dropfind does that your shop's search does not do today.
It finds what they meant
It tolerates typos and puts the product ahead of the accessory that mentions it.
It filters without drowning your server
The count for each option comes from the index, not from your database.
It shows you where you lose sales
Every search with no results is someone who wanted to buy and did not find it.
When they misspell it, or call it something else
PrestaShop's native search compares words. Dropfind understands that almost nobody types a product's exact name.
And you can see why each result is there
This is the difference that gives this page its title. Every field —name, reference, EAN, brand, category, description— carries a weight, and you set that weight from the back office. Raise the weight of the reference if the reference is what rules in your shop.
There is no black box deciding for you that you cannot question. If a product shows up where it should not, you can see why and fix it.
HOW IT WORKS
Four steps and it is searching
No migration, no touching your database and no second template to maintain.
-
01
Your catalogue is copied to an index
Names, references, barcodes, prices and photos are copied to an index that lives on our servers, not yours. It keeps itself up to date: every time you change a product, the change travels there.
When someone searches, the question goes to that index. Your database never hears about it, and that is why your shop does not suffer however many searches there are.
-
02
It opens over your shop
Full screen or hooked onto the search box your theme already has. You choose which, and you can change your mind without touching a line of template.
-
03
It answers as you type
No waiting and no page reload. The cache lives on your server, so anything repeated is not queried again —and does not count as a request.
-
04
And you decide the order
Each field's weight is set from the back office. If someone searches a reference, the reference rules. And you can see why each result came up.
And the filters, included
Category filters are your shop's second search engine, and in PrestaShop they are also the usual reason it falls over when a crawler walks through them.
Dropfind Filters does that work in the index. It is in every plan.
See Dropfind Filters68 products · 0 queries to your database
PRICING
Pay for the room you take
A record is one product in one language. That is the only axis, and every feature is in every plan.
- 3,000 records1,500 products in 2 languages
- As many languages as you like
- 100,000 requests/month
- 12,000 records4,000 products in 3 languages
- As many languages as you like
- 250,000 requests/month
- 35,000 records8,750 products in 4 languages
- As many languages as you like
- 600,000 requests/month
- 75,000 records18,750 products in 4 languages
- As many languages as you like
- 1,500,000 requests/month
Above 75,000 records, on your own server or with multistore. It is not one more rung on the ladder: it is another way of setting it up, with a fixed quote.
What counts as a request
A request is each query to the index. And anything served from your own server's cache never travels, so it does not count.
Your catalogue picks the plan
What really costs money to serve a shop is holding it in memory: 13.1 KB measured per record. Searching costs almost nothing —with the server at full load the CPU sits at 0.6%. That is why the ladder has a single axis: records. Charging separately for products and for languages billed the same space in memory twice, and punished whoever translates twice over.
Something useful follows from that: languages are not limited. Spread your records however you like —many products in one language, or fewer in five— and choose which ones you index from the module itself.
What is in the plan does not depend on size: every feature is in every plan. What changes is how much catalogue fits. See every feature →
If you get close to the ceiling you are warned in your back office, before anything happens.
← Back to the plansHow to start
No sales call and no migration. Four steps and the search is running.

